R1 Runbook Pengendalian Risiko Client¶

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.

Jangan salin materi ini ke chat tanpa kontrol, grup sales, komunikasi Client, atau penyimpanan tanpa kontrol.

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 pengendalian peristiwa, memulihkan akun, memasukkan atau menghapus Credit, maupun mengomunikasikan logika pengendalian internal kepada Client.

1. Tujuan¶

Runbook ini memandu tim dalam proses permintaan, approval, penerapan, verifikasi, Handover, review, penurunan tingkat, dan penghapusan status pengendalian risiko Client.

Dokumen ini bukan dokumen klasifikasi Client untuk publik dan tidak boleh digunakan untuk komunikasi dengan Client, tim sales, introducer, atau mitra.

2. Cakupan Pengendalian¶

2.1 Pengendalian Tingkat Akun di Manager¶

Pengendalian yang dikonfigurasi di Manager hanya berlaku untuk akun trading yang ditentukan.

Gunakan untuk:

pengendalian sementara pada satu akun;
kasus ketika review identitas tertaut belum selesai;
penanganan risiko tingkat akun yang telah disetujui;
kasus ketika cakupan dampak yang sempit harus dipertahankan.

2.2 Pengendalian Tingkat Identitas Tertaut di RiskTool¶

Pengendalian yang dikonfigurasi di RiskTool berdasarkan UID / identitas tertaut dapat berlaku untuk akun yang sudah ada dan akun mendatang di bawah identitas tertaut yang sama.

Sebelum digunakan, konfirmasikan bahwa:

identifikasi UID / identitas tertaut telah benar;
cakupan terkait telah melalui review yang diwajibkan;
approval yang sesuai telah diperoleh;
cakupan dampak, batas komunikasi, dan tanggung jawab tindak lanjut sudah jelas;
pewarisan ke akun yang sudah ada dan akun mendatang akan diverifikasi setelah implementasi.

Penting: Pengendalian tingkat UID / identitas tertaut berdampak lintas akun. Jangan memperluas pengendalian dari satu akun ke identitas tertaut tanpa approval.

3. Warna Tingkat Kedalaman Pengendalian Risiko¶

Warna berikut menunjukkan peningkatan tingkat kedalaman pengendalian risiko internal:

Black
Red
Yellow
DarkOrange
DarkTurquoise
Brown
MediumSpringGreen

Warna digunakan untuk Execution internal, Handover, dan review. Warna tersebut bukan label Client untuk publik dan tidak boleh dijelaskan secara eksternal.

3.1 MediumSpringGreen¶

MediumSpringGreen adalah tingkat pengendalian risiko tertinggi. Status ini digunakan ketika perusahaan tidak lagi bermaksud menerima order flow trading risiko terkait.

Konfigurasi Execution live, parameter, dan kriteria aktivasi harus mengikuti strategi sistem dan instruksi Manager yang saat ini telah disetujui. Jangan membahasnya dalam file atau chat tanpa kontrol.

3.2 SandyBrown¶

SandyBrown bukan bagian dari urutan kedalaman pengendalian Risk.

SandyBrown berarti: Tidak Ada Position Baru.

Sebelum menerapkan SandyBrown, personel yang berwenang harus mengonfirmasi dan mencatat kebijakan perusahaan mengenai:

apakah Position yang sudah ada dapat ditutup atau ditutup sebagian;
apakah pending Order dipertahankan, dibatalkan, atau dicegah agar tidak terpicu;
dampaknya terhadap mekanisme Stop Loss, Take Profit, atau stop-out;
apakah CRM wallet, transfer internal, deposit/withdrawal, atau fungsi akun lainnya juga dibatasi;
cakupan di seluruh platform, akun terkait, dan akun mendatang;
penanggung jawab komunikasi Client, komunikasi sales, dan approval risiko.

Jangan mengasumsikan dampak SandyBrown terhadap Position terbuka, pending Order, atau fungsi pendanaan tanpa kebijakan yang sudah dikonfirmasi.

4. Kriteria Pengajuan Status Pengendalian¶

Permintaan harus didukung oleh setidaknya salah satu hal berikut:

aktivitas holding singkat yang tidak lazim dan telah diverifikasi, order flow tidak lazim, atau perilaku yang berpotensi mengeksploitasi kondisi Execution;
hedging akun tertaut, pairing, penghindaran pengendalian, atau perilaku terkoordinasi abnormal yang telah diverifikasi;
risiko Execution yang material, risiko event, atau risiko berkelanjutan yang telah dikonfirmasi;
instruksi risiko yang jelas dari Manager, Risk Owner, atau Shift Leader;
situasi lain yang, setelah review, memenuhi standar tata kelola risiko perusahaan saat ini.

Setiap permintaan harus mencakup:

cakupan akun / UID / identitas tertaut;
status pengendalian saat ini;
status pengendalian usulan;
alasan pemicu;
Order, laporan, screenshot, log, atau bukti lainnya;
penjelasan dampak risiko;
urgensi;
waktu efektif yang diusulkan;
pemohon, approver, dan tanggal review.

5. Persetujuan dan Execution¶

5.1 Prinsip Kewenangan¶

Junior Dealer: mengidentifikasi sinyal risiko, memverifikasi fakta, menyimpan bukti, mengeskalasi isu, menindaklanjuti progres, memvalidasi hasil tindakan yang telah disetujui, dan menyelesaikan Handover.
Senior Dealer / Shift Leader: me-review bukti, merekomendasikan penanganan, menilai cakupan, mengonfirmasi persyaratan approval, mengoordinasikan Execution yang diotorisasi, dan memverifikasi hasilnya.
Admin Berwenang / Operator Manager: melakukan tindakan sistem terkendali dalam cakupan yang secara eksplisit disetujui dan dalam kewenangan operasional khusus individu tersebut.
Manager / Risk Owner yang Ditunjuk: menyetujui, menyesuaikan, memperluas, menurunkan tingkat, atau menghapus pengendalian risiko berdampak tinggi dan pengendalian risiko identitas tertaut.
IT / Pemilik Teknis: menyelidiki masalah sistem, konektivitas, data, atau teknis serta menyediakan bukti teknis dan hasil penyelesaian.

Jabatan tidak otomatis memberikan kewenangan operasional pada sistem. Tindakan terkendali memerlukan approval formal dan hanya boleh dilakukan oleh personel yang secara eksplisit diberi kewenangan untuk tindakan tersebut.

5.2 Pemeriksaan Pra-Execution¶

Sebelum Execution, konfirmasikan bahwa:

sumber instruksi jelas dan dapat ditelusuri;
akun / UID / platform / Group sudah benar;
permintaan dan status approval sesuai;
tidak ada rencana sementara, pengendalian peristiwa, atau pembatasan yang bertentangan dan sedang aktif;
cakupan yang dimaksud sama persis dengan persetujuan;
penanggung jawab Handover dan review telah ditetapkan.

5.3 Verifikasi Pasca-Execution¶

Setelah Execution, verifikasikan bahwa:

akun atau UID target menampilkan status pengendalian yang benar;
akun existing yang diwajibkan telah tercakup;
jika berlaku, pewarisan ke akun terkait mendatang berjalan sebagaimana yang diharapkan;
cakupan tidak diperluas secara keliru ke akun yang tidak terkait;
Handover, catatan Incident, dan kolom Audit yang diwajibkan telah lengkap.

6. Template Catatan Audit¶

Catat setiap penambahan, peningkatan, penurunan tingkat, atau penghapusan:

Kolom	Konten wajib
Tanggal & waktu	Waktu Execution dan zona waktu sistem
Platform	Platform yang terdampak
Akun / UID	Pengidentifikasi akun atau identitas tertaut
Cakupan tertaut	Cakupan akun terkait yang telah dikonfirmasi
Status lama → status baru	Sebelum dan sesudah
Alasan pemicu	Sinyal risiko atau alasan approval
Bukti	Laporan, screenshot, Order, log, referensi Incident
Pemohon	Orang yang mengajukan
Approver	Orang yang menyetujui
Pelaksana	Orang yang menerapkan tindakan
Hasil verifikasi	Dampak dan pengecualian yang telah dikonfirmasi
Tanggal review	Waktu atau pemicu review berikutnya
Kriteria penghapusan / penurunan tingkat	Standar review yang ditetapkan
Catatan	Handover atau catatan khusus

7. Peninjauan, Penurunan Tingkat, dan Penghapusan¶

Status pengendalian risiko tidak otomatis bersifat permanen.

Dalam review, pertimbangkan:

apakah perilaku risiko awal masih berlanjut;
apakah akun tertaut baru atau perilaku penghindaran pengendalian telah muncul;
apakah pengendalian saat ini tetap efektif dan proporsional;
apakah terjadi penerapan yang keliru, cakupan yang terlewat, atau perluasan yang tidak diperlukan;
apakah kriteria penurunan tingkat atau penghapusan yang telah disetujui telah terpenuhi;
apakah SandyBrown atau pembatasan lainnya juga memerlukan penyesuaian.

Setiap penurunan tingkat, penghapusan, perluasan, atau perubahan cakupan tertaut memerlukan approval, dasar pertimbangan yang terdokumentasi, dan catatan yang dapat ditelusuri.

8. Batas Kerahasiaan dan Komunikasi¶

Jangan:

menjelaskan warna, tingkat pengendalian, parameter internal, atau strategi Execution kepada Client;
mengungkapkan status pengendalian backend kepada tim sales, introducer, atau personel tanpa kewenangan;
membahas UID, warna, atau strategi penanganan tertentu dalam grup yang tidak berwenang;
menyalin atau mengunggah Runbook ini ke channel eksternal, grup tanpa kewenangan, atau lokasi penyimpanan yang tidak disetujui;
menggunakan status pengendalian internal sebagai dasar untuk penjelasan atau negosiasi sengketa Client.

Setiap komunikasi eksternal harus ditangani oleh owner yang berwenang dengan menggunakan redaksi yang telah disetujui.

9. Persyaratan Handover¶

Setiap Handover yang melibatkan status pengendalian risiko Client harus mencakup:

akun / UID yang terdampak;
status pengendalian saat ini;
tindakan yang telah diselesaikan;
lokasi bukti;
apakah SandyBrown atau pembatasan tambahan lainnya terlibat;
item yang menunggu review;
penanggung jawab berikutnya;
waktu review berikutnya / pemicu event;
apakah tindak lanjut Client, sales, atau IT masih tertunda.