TIKMI Aspek Manajemen Risiko: Lima Sub-Aspek Ketahanan Operasional
Pasal 45 huruf d PBI 10/2025 menetapkan persyaratan TIKMI aspek Manajemen Risiko dalam proses perizinan PSP. Aspek ini terdiri dari lima sub-aspek yang semuanya berkontribusi pada ketahanan operasional sistem pembayaran:
| KONSEP KUNCI | Ketahanan operasional (operational resilience) adalah kemampuan PSP untuk mengidentifikasi, merencanakan, dan dengan cepat pulih dari gangguan atau crisis yang dapat mengganggu layanan pembayaran. Lima sub-aspek TIKMI Manajemen Risiko adalah: (1) tata kelola organisasi; (2) manajemen tingkat ketergantungan dengan pihak yang melakukan kerja sama (third-party risk); (3) manajemen keberlangsungan tugas (business continuity); (4) manajemen penanganan insiden dan pengelolaan fraud; (5) interkoneksi dan interdependensi penyelenggaraan operasional kritikal. |
Pemetaan Detail Lima Sub-Aspek TIKMI Manajemen Risiko
| Sub-Aspek | Definisi | Implementasi Praktis | Bukti Kepatuhan Minimal |
|---|---|---|---|
| (1) Tata Kelola Organisasi | Struktur organisasi, peran, tanggung jawab, dan mekanisme pengambilan keputusan yang memungkinkan pengelolaan risiko yang efektif dan responsif terhadap perubahan kondisi operasional | Struktur organisasi tertulis dengan role dan responsibility matrix; clear escalation path untuk keputusan operasional; committee structure (risk committee, crisis management committee); regular board review atas risk landscape | Organizational chart; role description documents; committee charters; meeting minutes showing active oversight |
| (2) Manajemen Tingkat Ketergantungan dengan Pihak Kerja Sama (Third-Party Risk) | Kemampuan PSP untuk mengidentifikasi, menilai, dan mengelola risiko yang timbul dari ketergantungan PSP terhadap pihak ketiga (vendor teknologi, cloud provider, clearing house, bank partner) | Inventory pihak kerja sama dengan risk rating; due diligence process sebelum kerjasama; SLA dengan kriteria keamanan dan availability; regular vendor performance monitoring; escalation procedure jika vendor underperform; exit strategy / vendor backup plan | Third-party register dengan risk assessment; SLA contracts; vendor performance scorecards; evidence of vendor monitoring; breach notification logs |
| (3) Manajemen Keberlangsungan Tugas (Business Continuity Management) | Kemampuan PSP untuk merencanakan, menguji, dan melaksanakan recovery dari gangguan operasional agar layanan pembayaran dapat terus berlangsung dalam kondisi normal maupun abnormal (disaster, outage, capacity surge) | Business Continuity Plan (BCP) yang mencakup recovery time objective (RTO) dan recovery point objective (RPO); Disaster Recovery Plan (DRP) dengan data center backup; regular BCP testing (tabletop exercise, simulation); documented lessons learned; backup procedures dan backup testing | BCP dan DRP documents dengan RTO/RPO defined; BCM policy; testing records (quarterly minimum); evidence of backup data center functionality; disaster recovery test results; continuity planning for critical functions |
| (4) Manajemen Penanganan Insiden dan Pengelolaan Fraud | Kemampuan PSP untuk mengidentifikasi, merespons, dan pulih dari insiden operasional (system failure, data breach, fraud) dengan cepat dan efektif | Incident response plan dengan roles dan responsibilities; incident severity classification; escalation procedure; communication protocol; root cause analysis process; corrective action tracking; fraud detection and investigation procedures; anti-fraud training | Incident response policy; incident log dengan RCA dan remediation; fraud detection rule documentation; fraud case files; evidence of management review of incidents; anti-fraud awareness training certificates |
| (5) Interkoneksi dan Interdependensi Operasional Kritikal | Pemahaman dan manajemen atas ketergantungan antar-komponen infrastruktur pembayaran — yaitu bagaimana disruption pada satu komponen dapat menyebar (cascading failure) ke komponen lain dan ke ekosistem pembayaran luas | Mapping infrastruktur operasional dengan dependence diagram; identification of single points of failure; contingency planning untuk critical dependencies; stress testing untuk scenario cascading failure; communication protocol dengan peserta dan regulator jika terjadi system-wide disruption | Infrastructure dependency map; critical infrastructure documentation; contingency plans for critical dependencies; stress test results; evidence of coordination dengan peserta untuk crisis communication |
Business Continuity Plan (BCP): Standar dan Persyaratan Detail
BCP adalah dokumen yang menetapkan strategi, prosedur, dan resource untuk memastikan bahwa fungsi-fungsi kritikal PSP dapat terus beroperasi atau dengan cepat dipulihkan jika terjadi gangguan major. Pasal 69 dan 70 PBI 10/2025 menetapkan persyaratan BCP khususnya untuk Penyelenggara Penunjang kritical dan important, namun best practice adalah semua PSP harus memiliki BCP yang proportional dengan ukuran dan kompleksitas operasional mereka.
Komponen Utama BCP:
1. Business Impact Analysis (BIA)
Identifikasi fungsi bisnis kritikal dan dampak finansial serta operasional jika fungsi tersebut terganggu selama durasi tertentu (1 jam, 4 jam, 1 hari, dll.). BIA membantu prioritisasi recovery efforts.
2. Recovery Time Objective (RTO) dan Recovery Point Objective (RPO)
RTO adalah target waktu maksimal untuk memulihkan fungsi kritikal setelah terjadi gangguan. RPO adalah target maksimal data loss yang dapat ditolerir (misalnya, data loss maksimal 1 jam terakhir).
3. Disaster Recovery Plan (DRP)
Rencana teknis untuk recovery dari disaster besar (data center failure, major infrastructure damage). DRP mencakup backup data center, data backup schedule, recovery procedure, dan testing schedule.
4. Alternate Processing Site dan Data Backup
PSP harus memiliki lokasi alternate untuk memproses transaksi jika data center utama tidak dapat beroperasi. Lokasi ini harus berada di lokasi geografis yang berbeda (minimal 100 km atau pulau berbeda) dan dengan infrastruktur yang independent.
5. Crisis Communication Plan
Rencana untuk komunikasi internal dan eksternal (peserta, regulator, media, publik) jika terjadi insiden major. Komunikasi yang transparan dan cepat adalah kunci untuk menjaga kepercayaan stakeholder.
6. BCP Testing dan Maintenance
BCP harus diuji minimal setiap 6 bulan-1 tahun melalui tabletop exercise (diskusi skenario) atau full simulation (actual recovery test). Hasil testing harus didokumentasikan dan lessons learned harus diintegrasikan ke dalam update BCP.
| PENTING | BCP bukan dokumen yang dibuat sekali lalu disimpan di lemari. BCP adalah living document yang harus diperbarui secara berkala seiring dengan perubahan infrastruktur, business processes, atau threat landscape. Minimum setiap tahun, PSP harus melakukan review dan update BCP. Ketika ada perubahan sistem signifikan, BCP harus diupdate dan ditest ulang sebelum perubahan diimplementasikan ke production. |
Ketahanan Operasional dan BCP untuk Penyelenggara Penunjang
Pasal 69 PBI 10/2025 secara spesifik mengatur ketahanan operasional Penyelenggara Penunjang (third-party vendors seperti cloud provider, fraud detection vendor, payment processor). Persyaratan ini signifikan karena sebelumnya vendor teknologi tidak memiliki persyaratan regulasi langsung dari BI.
Pasal 69 ayat 1: Kewajiban Penyelenggara Penunjang
Penyelenggara Penunjang wajib menjamin ketahanan operasional melalui penerapan manajemen risiko yang comprehensive, mencakup:
(a) SDM yang kompeten dalam mengelola operasional dan risiko
(b) Proses operasional yang terstandar dan teruji
(c) Teknologi yang memadai dan reliability-tested
Pasal 69 ayat 2: Asesmen Berkala
Penyelenggara Penunjang wajib melakukan asesmen berkala (minimal tahunan) untuk memverifikasi bahwa ketahanan operasional mereka tetap terjaga. Asesmen dapat berupa self-assessment atau audit eksternal.
Pasal 69 ayat 3: Pembatasan Subcontracting
Jika Penyelenggara Penunjang memiliki subcontractor untuk layanan tertentu, maka:
(a) Subcontracting hanya dapat dilakukan untuk sebagian dari layanan, bukan seluruh layanan
(b) Subcontractor harus mematuhi ketentuan PBI 10/2025 (transitively apply)
(c) Penyelenggara Penunjang tetap bertanggung jawab penuh atas kinerja subcontractor kepada PSP
Pasal 70: Klausul BCP dan DRP dalam Perjanjian Kerja Sama
Untuk Penyelenggara Penunjang yang bersifat KRITIKAL atau PENTING, perjanjian kerja sama antara PSP dan Penyelenggara Penunjang HARUS mencakup:
(1) Kewajiban Penyelenggara Penunjang memiliki BCP dan DRP yang terstandar
(2) Kewajiban melakukan testing BCP/DRP secara berkala
(3) Kewajiban melaporkan hasil testing dan lessons learned kepada PSP
(4) Komitmen time-to-recovery (RTO dan RPO) yang selaras dengan kebutuhan PSP
(5) Mekanisme escalation jika terjadi insiden pada Penyelenggara Penunjang
| WAWASAN BITLION | Regulasi BCP untuk Penyelenggara Penunjang mencerminkan pemahaman BI bahwa sistem pembayaran modern adalah ekosistem yang highly interconnected: kegagalan satu vendor teknologi dapat dengan cepat menyebar ke seluruh jaringan pembayaran. Dengan mewajibkan BCP bagi Penyelenggara Penunjang, BI secara efektif memperpanjang standar ketahanan operasional ke supply chain pembayaran. Bagi PSP, ini membawa implikasi praktis: due diligence terhadap vendor teknologi harus mencakup verifikasi BCP dan DRP mereka sebelum kerjasama dimulai. |
Framework Manajemen Insiden dan Fraud Management
Insiden operasional (system failure, service outage, data breach) dan fraud adalah ancaman nyata terhadap ketahanan operasional. PBI 10/2025 mewajibkan PSP memiliki framework khusus untuk penanganan keduanya.
Incident Management Framework:
1. Incident Detection dan Reporting
Sistem monitoring automated harus mendeteksi anomali dan alert tim operations. SDM juga harus dapat melaporkan insiden yang terdeteksi secara manual. Semua insiden harus dilaporkan ke incident management system dalam timeframe yang ditentukan.
2. Incident Severity Classification
Insiden diklasifikasikan berdasarkan severity (critical, major, minor) dengan kriteria jelas. Severity determination mempengaruhi response time dan escalation path.
3. Incident Response Team Activation
Sesuai severity, incident response team diaktivasi dengan composition yang sesuai (on-call basis untuk minor, immediate activation untuk critical).
4. Root Cause Analysis (RCA)
Untuk semua insiden yang signifikan, RCA harus dilakukan untuk mengidentifikasi akar cause, bukan hanya gejala. RCA harus didokumentasikan dan lessons learned harus diintegrasikan ke dalam update kebijakan/prosedur.
5. Corrective Action Tracking
Tindakan perbaikan untuk mencegah insiden serupa harus didefinisikan, di-assign dengan deadline yang jelas, dan di-track sampai close.
Fraud Management:
Fraud detection harus dilakukan melalui kombinasi tools (rules-based dan machine learning) dan manual investigation. Setiap fraud case harus diinvestigasi, dan findings harus digunakan untuk update fraud detection rules dan staff training.