R2. Runbook Respons Incident Pricing & Execution¶

Hanya untuk Penggunaan Internal – Referensi Operasional

Materi ini ditujukan untuk pelatihan internal, Handover, dan referensi operasional yang diotorisasi. Membaca materi ini tidak memberikan kewenangan untuk melakukan tindakan terkendali.

Runbook ini menggunakan bahasa netral sistem. Path sistem, parameter, kode produk, dan langkah Execution yang berlaku harus mengikuti SOP terbaru yang telah disetujui, control sheet, dan sistem produksi yang diotorisasi.

Jika tindakan sistem diperlukan, gunakan rumusan netral sistem: Dealer memverifikasi status yang telah disetujui, menyimpan bukti, mengeskalasi pengecualian, mengonfirmasi hasil, dan menyelesaikan Handover. Kontrol sistem hanya boleh diterapkan atau dihapus oleh personel berwenang melalui sistem resmi yang berlaku. Eskalasikan jika hasil sistem berbeda dari instruksi yang telah disetujui.

Batas Kewenangan Operasional¶

Dealer dapat mengidentifikasi masalah, melakukan verifikasi, menyimpan bukti, melakukan eskalasi, monitoring, dan menyelesaikan Handover.
Tindakan terkendali hanya boleh dilakukan oleh personel yang secara eksplisit diberi kewenangan untuk tindakan tersebut.
Dealer tidak boleh secara mandiri mengubah Order, menyesuaikan status Risk Client, menerapkan kontrol event, memulihkan akun, menambahkan atau menghapus Credit, maupun mengomunikasikan logika kontrol internal kepada Client.

1. Tujuan & Batas Otoritas¶

R2 adalah Runbook respons Incident dan koordinasi untuk situasi abnormal terkait Pricing, Execution, Order, dan sengketa Client. Runbook ini menetapkan hal yang harus diidentifikasi, dijaga, diklasifikasikan, dieskalasikan, disetujui, dieksekusi oleh operator berwenang, divalidasi, dan diserahterimakan.

R2 tidak memberikan kewenangan kepada Dealer untuk menghapus, memulihkan, mengubah, atau melakukan penyesuaian finansial pada Order. Penghapusan Order, pemulihan Order, koreksi Order, perbaikan balance, penambahan atau penarikan Credit, dan pemulihan akses trading Client adalah tindakan back-office Admin / Manager yang memerlukan approval dan Execution oleh pihak berwenang.

2. Klasifikasi Incident¶

Klasifikasikan Incident berdasarkan dampak yang dapat diamati sebelum mengusulkan tindakan apa pun:

Jenis Incident	Contoh	Bukti utama
Abnormalitas Pricing	Spike abnormal, Quote stale, Quote yang tidak konsisten antar-Quote Source	Timestamp Quote, screenshot chart, pasar referensi, Symbol terdampak
Abnormalitas Execution	Keterlambatan, penolakan, timeout, urutan fill abnormal	Laporan Order, timestamp Execution, status sistem, konteks event
Sengketa Order	Client mempertanyakan trigger, fill, close-out, atau koreksi	Order ID, akun, waktu server, siklus Order, pernyataan Client
Dampak sistem	Beberapa Symbol, akun, atau platform terdampak	Bukti kondisi sistem, daftar cakupan, timeline Incident
Tindakan pemulihan diperlukan	Penyesuaian Order, balance, Credit, atau akses trading mungkin diperlukan	Catatan keputusan yang disetujui, klasifikasi Order terdampak, catatan sebelum/sesudah tindakan

Klasifikasi bersifat faktual. Klasifikasi tidak menentukan kompensasi, komunikasi kepada Client, atau metode pemulihan.

3. Matriks Peran & Otoritas¶

Peran	Bertanggung jawab untuk	Tidak boleh dilakukan
Dealer	Mengidentifikasi sinyal abnormal pada Pricing, Execution, Order, atau sengketa; menyimpan bukti; mengekstrak Laporan Order, Laporan Closed Trade, atau laporan resmi setara; menentukan cakupan akun, waktu, dan Symbol terdampak; mengklasifikasikan Order; mengajukan eskalasi; menindaklanjuti hasil Execution yang disetujui; menyelesaikan Handover dan catatan Incident	Menghapus, memulihkan, atau mengubah Order; memperbaiki balance; menambahkan atau menarik Credit; memulihkan akses trading; memutuskan kompensasi atau hasil penanganan; menjelaskan logika penanganan Order internal kepada pihak eksternal
Operator Admin / Manager	Setelah approval yang jelas, mengeksekusi tindakan back-office yang diotorisasi melalui sistem Admin / Manager resmi yang berlaku; menjaga catatan sebelum dan sesudah; melaporkan hasil dan pengecualian kepada Shift Leader / Manager	Memutuskan cakupan, kompensasi, pesan kepada Client, atau kesimpulan risiko
Shift Leader / Manager	Mengonfirmasi cakupan dampak; menentukan prioritas; me-review bukti dan klasifikasi Order; mengonfirmasi status approval; menghentikan sementara tindakan lebih lanjut bila diperlukan; menyetujui atau menolak penanganan berdampak tinggi; menunjuk reviewer, owner Handover, dan owner tindak lanjut	Mengizinkan tindakan terkendali tanpa bukti, approval, dan catatan
IT	Menyelidiki abnormalitas Quote, data source, server, log, network, environment, atau rantai Execution; memberikan temuan teknis; membantu konfirmasi pemulihan	Memutuskan kesimpulan terkait Order Client, kompensasi, atau penanganan Risk
Pemilik Komunikasi Client	Menangani pengumuman kepada Client, penjelasan, komunikasi kompensasi, atau susunan kata eksternal dengan menggunakan bahasa yang telah disetujui	Mengungkapkan logika kontrol internal, metode back-office, detail sistem, atau atribusi kesalahan

4. Tindakan Stabilisasi Segera¶

Hentikan kesimpulan spekulatif dan pertahankan kondisi saat ini.
Konfirmasikan apakah masalah masih aktif, sedang pulih, atau sudah terselesaikan.
Identifikasi Symbol, akun, rentang waktu, jenis Order, dan platform yang terdampak.
Beri tahu Shift Leader / Manager jika terdapat kemungkinan dampak terhadap Client, dampak finansial, dampak Order berulang, atau dampak pada seluruh sistem.
Jika kontrol Execution sementara disetujui, Dealer mengonfirmasi cakupan yang disetujui dan operator berwenang yang bertanggung jawab; kontrol sistem hanya boleh diterapkan oleh personel berwenang melalui sistem resmi yang berlaku.
Jika hasil sistem berbeda dari instruksi yang telah disetujui, hentikan tindakan lebih lanjut dan segera eskalasikan.

5. Penjagaan Bukti¶

Jaga bukti sebelum tindakan pemulihan apa pun:

laporan Order atau laporan Closed Trade;
akun, Symbol, Order ID, arah, volume, waktu open, waktu close, dan kondisi trigger;
bukti Quote, chart, dan timestamp;
bukti status sistem dan status Execution yang tersedia dari tool resmi;
keluhan Client atau catatan observasi internal;
kalender event dan konteks pasar;
catatan approval, handler, reviewer, dan pemilik Handover.

Bukti harus memadai agar reviewer dapat merekonstruksi kejadian di kemudian hari tanpa mengandalkan ingatan.

6. Matriks Eskalasi dan Approval¶

Situasi	Eskalasi diperlukan	Approval diperlukan sebelum tindakan
Satu Order hanya memerlukan peninjauan faktual	Shift Leader jika terdapat ketidakpastian	Tidak diperlukan untuk pengumpulan bukti
Beberapa Order atau akun terdampak	Shift Leader / Manager	Diperlukan sebelum tindakan pemulihan apa pun
Pemulihan balance, Credit, atau akses trading	Manager	Diperlukan
Potensi kompensasi kepada Client atau penjelasan eksternal	Manager dan Pemilik Komunikasi Client	Diperlukan
Hasil sistem berbeda dari instruksi yang telah disetujui	Shift Leader / Manager dan IT	Diperlukan sebelum melanjutkan
Perluasan cakupan melampaui peninjauan awal	Manager	Diperlukan

7. Ekstraksi dan Klasifikasi Order Terdampak¶

Dealer menyiapkan daftar Order terdampak menggunakan laporan yang disetujui atau data resmi setara.

Minimal, klasifikasikan:

Order opening dengan harga yang salah;
Order closing dengan harga yang salah;
trigger Stop Loss / Take Profit dengan harga yang salah;
stop-out dengan harga yang salah;
trigger pending Order yang abnormal;
Order yang melibatkan opening dan closing yang keduanya salah;
Order yang disengketakan akibat abnormalitas Pricing, Execution, atau sistem.

Setiap baris harus mencantumkan akun, Order ID, Symbol, arah, volume, timestamp yang relevan, masalah yang diamati, referensi bukti, dan kategori peninjauan yang diusulkan.

8. Tindakan Pemulihan Order oleh Admin / Manager yang Berwenang¶

Dealer tidak melakukan tindakan pemulihan Order secara mandiri.

Jika penghapusan, pemulihan, koreksi, atau penanganan back-office lain terhadap Order disetujui, tindakan tersebut harus dilakukan oleh Operator Admin / Manager berwenang melalui sistem back-office resmi yang berlaku, sesuai rencana penanganan yang disetujui.

Sebelum tindakan:

konfirmasikan catatan approval dan cakupan yang tepat;
konfirmasikan bahwa Order dan akun terdampak sesuai dengan daftar yang telah disetujui;
simpan laporan atau status sebelum tindakan;
konfirmasikan pemilik peninjauan rollback atau koreksi, jika berlaku.

Setelah tindakan:

simpan catatan setelah tindakan;
bandingkan hasil dengan instruksi yang disetujui;
segera laporkan pengecualian;
perbarui catatan Incident dan Handover.

9. Kontrol Pemulihan Balance, Credit, dan Akses Trading¶

Perbaikan balance, penambahan atau penarikan Credit, dan pemulihan akses trading Client merupakan kontrol back-office berdampak tinggi.

Tindakan tersebut memerlukan:

keputusan finansial atau akses yang telah disetujui;
akun terdampak dan jumlah atau cakupan izin;
bukti sebelum dan sesudah;
catatan operator yang berwenang;
konfirmasi reviewer;
batas komunikasi kepada Client yang jelas.

Dealer tidak boleh secara mandiri memutuskan atau mengeksekusi tindakan tersebut tanpa approval.

10. Batas Komunikasi kepada Client¶

Jangan mengungkapkan logika sistem internal, logika kontrol Risk, metode pemulihan, operasi back-office, detail abnormalitas sistem, atau atribusi kesalahan kepada Client, tim sales, atau personel yang tidak berwenang.

Semua penjelasan kepada Client, susunan kata kompensasi, pengumuman, atau tanggapan sengketa harus ditangani oleh Pemilik Komunikasi Client dengan menggunakan bahasa yang telah disetujui.

11. Validasi Pemulihan¶

Validasi mengonfirmasi bahwa hasil yang disetujui telah tercapai, bukan sekadar bahwa tindakan sistem telah dilakukan.

Periksa:

daftar Order terdampak sesuai dengan cakupan yang telah disetujui;
laporan setelah tindakan mencerminkan hasil yang dimaksud;
tidak ada akun atau Order yang tidak terkait yang diubah;
status balance, Credit, dan akses trading sesuai dengan approval;
kontrol sementara telah dihapus, dipulihkan, atau dipertahankan sesuai instruksi;
pengecualian dieskalasikan dan ditetapkan penanggung jawabnya.

12. Laporan Incident dan Peninjauan Pasca-Incident¶

Laporan Incident harus mencakup:

ringkasan dan timeline Incident;
Symbol, akun, Order, dan rentang waktu yang terdampak;
bukti yang dikumpulkan;
klasifikasi faktual;
approval yang diperoleh;
tindakan yang dieksekusi oleh operator yang berwenang;
hasil validasi;
status komunikasi kepada Client;
item yang masih terbuka dan rekomendasi perbaikan.

Review pasca-Incident berfokus pada kualitas kontrol: kelengkapan bukti, disiplin approval, urutan tindakan, validasi, dan Handover.

13. Persyaratan Handover¶

Handover harus menyatakan:

status Incident saat ini;
cakupan terdampak dan ketidakpastian yang tersisa;
tindakan yang telah diselesaikan dan hasil validasi;
approval yang masih tertunda atau tindakan pemulihan yang masih tertunda;
pemilik yang ditugaskan untuk setiap item yang masih terbuka;
waktu atau trigger peninjauan berikutnya;
apakah tindak lanjut dari IT, Risk, Manager, atau Pemilik Komunikasi Client masih tertunda.

14. Checklist Penyelesaian¶

Incident diklasifikasikan berdasarkan bukti faktual.
Order, akun, Symbol, dan rentang waktu terdampak telah diekstrak.
Bukti yang diperlukan telah dijaga sebelum tindakan pemulihan.
Catatan approval dilampirkan untuk setiap tindakan berdampak tinggi.
Hasil Execution oleh Operator Admin / Manager dicatat jika berlaku.
Validasi pemulihan telah diselesaikan.
Batas komunikasi kepada Client dipatuhi.
Pemilik Handover dan pemilik tindak lanjut telah ditetapkan.