Dalam era digital dan ekonomi data, informasi adalah aset paling berharga. Bank Indonesia memahami ini dengan baik. Oleh karena itu, PBI 10/2025 menetapkan rezim pelaporan data yang komprehensif dan ketat kepada setiap Penyelenggara Sistem Pembayaran (PSP). Kewajiban pelaporan ini bukan hanya tentang transparansi regulatory; ia adalah fondasi bagi pengawasan prudensial, analisis makroekonomi, dan kebijakan moneter yang informed.
Infrastruktur Data Sistem Pembayaran (IDSP): Apa dan Mengapa Penting
Bank Indonesia telah membangun apa yang disebut Infrastruktur Data Sistem Pembayaran (IDSP), sebuah platform terpusat yang mengumpulkan, menyimpan, dan menganalisis data dari semua PSP yang beroperasi di Indonesia. IDSP bukan sekadar database administratif; ia adalah sistem intelligence yang memungkinkan BI untuk memantau kesehatan sistem pembayaran secara real-time, mengidentifikasi risiko sistemik, dan mengambil tindakan preventif sebelum krisis berkembang.
Mengapa IDSP penting? Pertama, karena fragmentasi data membuat pengawasan sistemik menjadi mustahil. Jika setiap PSP melaporkan data dengan format dan standar berbeda, BI tidak dapat membuat gambaran holistik tentang kesehatan sistem pembayaran nasional. Kedua, karena sistem pembayaran modern berjalan 24/7 dan bergerak dengan kecepatan kilat; pengawasan berbasis laporan bulanan atau tahunan sudah tidak cukup. IDSP memungkinkan pengawasan berbasis real-time atau near-real-time, sehingga BI dapat mendeteksi anomali dan mengambil tindakan dengan cepat.
Jenis Data yang Wajib Dilaporkan
PBI 10/2025 mewajibkan PSP untuk melaporkan berbagai jenis data, masing-masing dengan standar format, kelengkapan, dan frekuensi spesifik:
Data Transaksi Rinci: Untuk setiap transaksi pembayaran (dalam threshold tertentu), PSP harus melaporkan detail seperti nominal transaksi, waktu, pihak yang terlibat (dalam format anonymized), jenis transaksi (transfer, pembayaran merchant, withdrawal, dll.), dan status transaksi (success atau failed).
Data Volume dan Nilai Agregat: Data berkumpul tentang total volume dan nilai transaksi per hari, per jenis produk, per channel, dan per segmen pelanggan, yang memungkinkan BI untuk memantau dinamika pasar.
Data Keluhan dan Disputa (Complaint Data): Setiap keluhan pelanggan, disputa transaksi, atau klaim yang diterima PSP harus dilaporkan ke IDSP dengan kategori keluhan (fraud, technical error, lost transaction, dll.), status resolusi, dan waktu resolusi.
Data Kepatuhan dan Risiko: Laporan tentang insiden keamanan cyber, pelanggaran data, fraud cases yang detected dan remediated, incident response times, dan metrik kepatuhan lainnya.
Data Pelanggan dan Akun: Statistik tentang jumlah akun aktif, dormant, closed, breakdown demografis, dan geographic distribution pelanggan.
Laporan Rutin vs Laporan Insidentil
PBI 10/2025 membedakan antara dua jenis laporan: laporan rutin dan laporan insidentil. Laporan rutin adalah laporan yang dijadwalkan dengan frekuensi tetap (harian, mingguan, bulanan, atau tahunan), diprediksi, dan direncanakan. Laporan insidentil adalah laporan yang dipicu oleh event khusus atau anomali yang memerlukan notifikasi immediate kepada BI.
Contoh laporan rutin: laporan agregat transaksi harian, laporan bulanan tentang revenue dan operating cost, laporan tahunan tentang risk assessment dan compliance. Contoh laporan insidentil: laporan tentang uptime kritis sistem yang turun di bawah threshold (misalnya 99.5%), laporan tentang fraud attack yang detected, laporan tentang data breach atau security incident yang material.
Frekuensi Pelaporan: Harian, Mingguan, Bulanan, Tahunan
Frekuensi pelaporan bervariasi tergantung jenis data dan risiko yang ingin dipantau BI. Data transaksi rinci umumnya dilaporkan secara harian atau real-time. Data agregat transaksi dapat dilaporkan harian atau mingguan. Data keluhan dapat dilaporkan mingguan atau bulanan. Data kepatuhan dan risk assessment dilaporkan bulanan atau tahunan. Pentingnya adalah bahwa PSP harus memiliki sistem internal yang dapat mengekstrak, mengvalidasi, dan mengirimkan data dengan frekuensi yang ditentukan, tanpa delay dan tanpa error.
Format Pelaporan: API Electronic Reporting
PBI 10/2025 mewajibkan pelaporan dalam format elektronik melalui API yang ditetapkan BI, bukan melalui spreadsheet manual atau email. Ini adalah critical requirement karena manual reporting memperkenalkan human error, tidak scalable, dan tidak memungkinkan real-time atau near-real-time monitoring.
BI telah menyediakan technical specifications untuk API reporting, termasuk authentication mechanism, data format standard (umumnya JSON atau XML), compression standards, error handling protocols, dan retry logic. Setiap PSP harus mengintegrasikan sistem internal mereka (core banking system, payment engine, risk analytics platform) dengan IDSP API.
Ini bukanlah task sepele. Bagi PSP besar dengan infrastruktur legacy yang kompleks, integrasi API dapat memerlukan engineering effort yang signifikan, testing yang extensive, dan koordinasi internal lintas departemen. Namun, untuk PSP startup atau yang sudah cloud-native, integrasi ini relatif straightforward.
Kewajiban Keakuratan dan Ketepatan Waktu
Dua aspek critical dari pelaporan adalah keakuratan (accuracy) dan ketepatan waktu (timeliness). Keakuratan berarti bahwa data yang dilaporkan harus representatif dari kondisi aktual di sistem PSP, tanpa distorsi, manipulasi, atau omission yang material. Ketepatan waktu berarti bahwa data harus dikirimkan dalam window yang ditentukan BI—misalnya laporan harian harus dikirimkan sebelum 11:00 AM hari berikutnya, laporan mingguan harus dikirimkan sebelum akhir hari Senin minggu berikutnya.
PSP harus memiliki kontrol internal yang ketat untuk memastikan keakuratan data. Ini termasuk data validation rules pada sumber data (contoh: nominal transaksi harus positif, timestamp harus valid), reconciliation rutin antara source system dan data yang dilaporkan, dan audit trail yang comprehensive untuk memungkinkan traceability.
| PENTING | Pelaporan tidak akurat atau tidak lengkap dianggap lebih serius daripada pelaporan terlambat. Jika PSP melaporkan data yang salah kepada BI, ini tidak hanya adalah pelanggaran prosedural; ia adalah pelanggaran substansial karena data yang salah dapat membuat BI membuat keputusan kebijakan yang salah dan mengalokasikan sumber daya pengawasan secara misdirected. |
Koordinasi Pelaporan dengan OJK dan PPATK
Landscape regulatoris PSP melibatkan tidak hanya BI, tetapi juga OJK (untuk aspek investasi dan fintech tertentu) dan PPATK (untuk AML/CFT). Ini menciptakan tanggung jawab pelaporan yang multiplikatif. Sebuah e-money issuer, misalnya, mungkin harus melaporkan data transaksi ke BI, data investasi produk ke OJK, dan laporan suspicious transaction ke PPATK, masing-masing dengan format, frekuensi, dan timeline berbeda.
Tantangan koordinasi ini adalah bahwa meskipun data underlying sama (misalnya transaksi pelanggan), format dan granularitas laporan berbeda. BI mungkin ingin data pada level transaksi individual, OJK pada level agregat produk, dan PPATK pada level customer behavior pattern. PSP harus membangun data pipeline yang dapat ekstrak data sekali, validate, dan kemudian distribute ke berbagai regulator dalam format masing-masing.
Data Lokalisasi: Di Mana Data Harus Disimpan
PBI 10/2025, sejalan dengan kebijakan data sovereignty nasional, mewajibkan bahwa data sistem pembayaran harus disimpan secara fisik di Indonesia. Ini berarti bahwa server atau data center tempat data disimpan harus berlokasi di wilayah Indonesia, atau minimal bahwa backup dan disaster recovery sites harus tersedia di dalam negeri.
Persyaratan ini memiliki implikasi infrastruktur yang signifikan, terutama untuk PSP yang menggunakan cloud computing global. PSP tidak dapat hanya menggunakan AWS region di Singapore atau Google Cloud region di Tokyo untuk menyimpan data transaksi Indonesia. Mereka harus menggunakan regional data centers yang tersedia di Indonesia, atau bernegosiasi dengan cloud providers untuk membuka regional services di Indonesia.
Retention Period: Berapa Lama Data Harus Disimpan
PBI 10/2025 menetapkan retention period untuk berbagai jenis data. Data transaksi detail umumnya harus disimpan minimal 5 tahun untuk memungkinkan audit trail yang lengkap dan investigation mendalam jika terjadi fraud atau dispute. Data agregat dapat disimpan lebih lama (7-10 tahun) untuk analisis historis dan trend analysis. Data keluhan harus disimpan sampai resolusi complete plus 2 tahun.
Retention period yang panjang ini memiliki implikasi cost yang signifikan, terutama untuk data storage dan backup. PSP besar dengan volume transaksi ratusan juta per hari dapat mengakumulasi terabytes atau petabytes data per tahun. Mengelola storage jangka panjang ini memerlukan infrastructure planning yang sophisticated, including data tiering (hot storage untuk data recent, cold storage untuk data lama), compression algorithms, dan disaster recovery strategies.
Sanksi Keterlambatan dan Ketidakakuratan Pelaporan
Kewajiban pelaporan bukanlah anjuran; ia adalah mandatory requirement yang dienkforcement dengan sanksi. Jika PSP melaporkan terlambat atau tidak lengkap, PSP dapat dikenakan denda administratif, warning letter, atau dalam kasus ekstrem, administrative action lebih serius seperti temporary suspension atau revocation lisensi.
Penalti keterlambatan minimal dan dapat ditoleransi hingga batas tertentu (misalnya 1-2 hari), tetapi penalti accumulative jika keterlambatan berulang. Penalti ketidakakuratan lebih serius dan dapat tanpa batas waktu grace period, karena data yang salah dapat merugikan kepentingan publik.
Automated Regulatory Reporting: Imperatif Teknologi
Mengingat complexity dan volume data yang harus dilaporkan, manual reporting sudah tidak feasible. PSP modern harus mengotomasi proses pelaporan end-to-end: dari ekstraksi data dari system operasional, validation, transformation ke format yang diminta BI, hingga submission otomatis ke IDSP API.
Ini memerlukan investasi dalam RegTech infrastructure, termasuk data warehousing, ETL (Extract-Transform-Load) pipelines, data governance, dan monitoring dashboards. Bagi startup PSP dengan resource terbatas, tanpa automation ini menjadi very costly operational burden.
| WAWASAN BITLION | Platform GRC Bitlion menyediakan modul automated regulatory reporting yang mengintegrasikan dengan berbagai format API BI, meng-otomasi ekstraksi data dari core system, validation rules, dan submission. Modul ini mengurangi operational burden pelaporan dan meminimalkan risiko errors atau delays. |
Tabel: Kewajiban Pelaporan PSP
| Jenis Laporan | Frekuensi | Kepada | Sanksi Keterlambatan |
|---|---|---|---|
| Data Transaksi Detail (Real-Time atau Harian) | Setiap hari atau real-time | BI (IDSP) | Warning letter; jika berulang: denda Rp 10-50 juta per insiden |
| Laporan Agregat Transaksi | Harian atau mingguan | BI (IDSP) | Warning letter; denda progresif jika berulang |
| Laporan Keluhan dan Dispute | Mingguan atau bulanan | BI + OJK | Denda Rp 5-25 juta + order untuk backfill data |
| Laporan Incident Keamanan/Cyber | Insidentil (immediate) atau bulanan | BI + BSSN | Administrative action; potential suspension jika incident material tidak dilaporkan |
| Laporan Kepatuhan dan Risk Assessment | Bulanan atau tahunan | BI | Warning letter; denda Rp 25-100 juta jika laporan tidak reliable |
| Laporan Statistik Pelanggan | Kuartalan atau tahunan | BI | Denda Rp 5-15 juta + reputational impact |
Kesimpulan: Data Sebagai Fondasi Pengawasan
Kewajiban pelaporan data kepada BI adalah manifestasi dari filosofi regulatory BI yang modern: real-time monitoring, data-driven decision making, dan preventive supervision. Bagi PSP, memahami dan memenuhi kewajiban ini bukan hanya tentang compliance; ini tentang membangun organizational capability yang fundamental untuk beroperasi di ekosistem payment modern.
PSP yang mengotomasi pelaporan data dan membangun infrastruktur data yang robust akan menemukan diri mereka tidak hanya compliant, tetapi juga lebih operationally efficient, lebih capable untuk detect fraud dan risiko internal, dan lebih attractive kepada investors yang menghargai governance dan transparency.