Pukul 17.30, cabang A mengirim laporan kas dan transfer antar-cabang. Di kantor pusat, angka yang masuk berbeda Rp12.500.000. Cabang mengatakan dana sudah dikirim. Kantor pusat mengatakan dana belum diterima. Sementara itu, saldo pada satu laporan sudah berkurang, tetapi saldo pada laporan lawannya belum bertambah.
Tim operasional mulai mencari. Mereka membuka pesan grup, mencetak mutasi rekening, memeriksa spreadsheet, lalu bertanya kepada petugas yang bertugas sore itu. Tidak ada satu daftar selisih yang bisa langsung menunjukkan transaksi mana yang belum berpasangan. Besok pagi, masalah yang sama masih terbawa ke laporan harian.
Semakin banyak kantor yang dimiliki, akan semakin kompleks masalah yang dihadapi. Pola seperti ini mudah terjadi ketika BPR atau BPRS memiliki beberapa cabang yang koneksinya tidak selalu stabil, dan kurang kuatnya SOP proses antar-cabang.
Rekonsiliasi antar-cabang adalah proses membandingkan catatan dua pihak yang seharusnya menunjukkan transaksi yang sama. Pihaknya bisa berupa dua cabang, cabang dan kantor pusat, atau sistem transaksi dan buku besar. Tujuannya bukan sekadar menemukan angka yang berbeda, tetapi menjelaskan penyebabnya dan memastikan selisih ditutup dengan cara yang benar.
Artikel ini membahas rekonsiliasi antar-cabang untuk BPR (Bank Perekonomian Rakyat) dan BPRS (Bank Perekonomian Rakyat Syariah), mulai dari konsep dasar, penyebab selisih, format kerja, sampai rencana 30/60/90 hari. Fokusnya adalah pekerjaan yang bisa dilakukan oleh operasional, akuntansi, TI, dan audit intern tanpa saling melempar tanggung jawab.
1. Rekonsiliasi Antar-Cabang Bukan Sekadar Mencocokkan Total
Rekonsiliasi sering dianggap selesai ketika total debit dan kredit terlihat sama. Padahal, dua total yang sama belum tentu berasal dari transaksi yang sama. Satu transaksi bisa hilang di satu sisi dan tertutup oleh transaksi lain yang kebetulan nilainya sama.
Karena itu, rekonsiliasi yang baik mencocokkan baris transaksi, bukan hanya jumlah akhir. Setiap transaksi perlu memiliki pasangan yang jelas: nomor referensi, tanggal, cabang asal, cabang tujuan, nominal, jenis transaksi, dan status penyelesaian.
Contohnya, cabang A mengirim dana Rp50.000.000 ke kantor pusat. Di catatan cabang A, transaksi itu tercatat sebagai pengurangan kas. Di catatan kantor pusat, transaksi yang sama harus muncul sebagai penerimaan. Kalau penerimaan belum muncul, selisihnya bukan langsung berarti uang hilang. Bisa saja transaksi masih dalam perjalanan, batch (kelompok transaksi) belum diproses, atau kode cabang tujuan salah.
Namun, selisih juga tidak boleh dibiarkan dengan alasan “mungkin masih dalam proses”. Setiap selisih perlu diberi status, pemilik, batas waktu, dan bukti. Inilah perbedaan antara rekonsiliasi dan sekadar melihat laporan.
Ada tiga hasil dasar dari pencocokan.
- Matched, yaitu transaksi di kedua sisi cocok dan tidak memerlukan tindakan tambahan.
- In transit, yaitu transaksi sudah tercatat di satu sisi, tetapi pasangan di sisi lain belum muncul karena masih diproses.
- Exception, yaitu transaksi tidak cocok atau tidak punya pasangan yang dapat dijelaskan.
Istilah exception berarti pengecualian atau item yang keluar dari pola normal. Daftar exception inilah yang harus dikelola sampai selesai. Tanpa daftar tersebut, selisih mudah berulang dan sulit dibuktikan saat pemeriksaan. Untuk konteks pemeriksaan sistem dan TI, cara menyiapkan bukti dapat dilihat di artikel persiapan pemeriksaan OJK dari sisi sistem dan IT.
2. Data Apa yang Harus Dicocokkan?
Sebelum mencari penyebab selisih, tentukan dulu sumber data yang dibandingkan. Banyak rekonsiliasi gagal bukan karena orangnya tidak teliti, tetapi karena dua laporan memakai definisi dan waktu yang berbeda.
2.1 Tentukan dua sisi dan periode
Tulis dengan jelas siapa melawan siapa. Contohnya:
- Cabang A melawan kantor pusat.
- Cabang A melawan cabang B.
- Buku besar kantor pusat melawan rekening antar-cabang.
- Laporan transaksi aplikasi inti perbankan melawan mutasi rekening bank koresponden.
- Kas fisik cabang melawan saldo kas pada sistem.
Lalu tetapkan periode. Apakah rekonsiliasi dilakukan untuk satu hari, satu minggu, atau satu bulan? Gunakan batas waktu yang sama pada kedua sisi. Jika cabang memakai transaksi sampai pukul 17.00, tetapi kantor pusat memakai transaksi sampai pukul 16.00, selisih satu jam bisa terlihat seperti kesalahan padahal hanya berbeda cutoff.
Cutoff adalah batas waktu yang menentukan transaksi masuk ke periode laporan mana. Contoh sederhananya, transaksi yang dibuat pukul 16.59 masuk laporan hari Senin, sedangkan transaksi pukul 17.01 masuk laporan hari Selasa. Aturannya harus jelas dan dipakai oleh semua cabang.
2.2 Pakai kunci pencocokan yang konsisten
Kunci pencocokan adalah informasi yang dipakai untuk menemukan pasangan transaksi. Prioritaskan kunci yang paling kuat.
- Nomor referensi atau ID transaksi yang unik.
- Tanggal dan waktu transaksi.
- Cabang asal dan cabang tujuan.
- Nominal dan jenis transaksi.
- Nomor rekening atau akun antar-cabang.
- Nomor batch jika transaksi dikirim secara berkelompok.
Nominal saja adalah kunci yang lemah. Dua transaksi berbeda bisa memiliki nominal Rp10.000.000. Jika sistem mencocokkan hanya berdasarkan nominal, transaksi yang salah bisa dianggap sudah berpasangan.
2.3 Pisahkan transaksi otomatis dan manual
Transaksi otomatis biasanya memiliki ID, waktu proses, dan status sistem. Transaksi manual sering memakai jurnal, spreadsheet, atau formulir. Keduanya perlu direkonsiliasi, tetapi bukti dan risikonya berbeda.
Untuk transaksi manual, simpan alasan, pembuat, pemeriksa, dokumen pendukung, serta waktu pencatatan. Jangan menghapus baris lama saat koreksi. Buat pembalikan atau jurnal koreksi yang memiliki hubungan jelas dengan transaksi awal.
Prinsip ini juga membantu saat bank menelusuri transaksi pada jejak audit dan kontrol sistem. Catatan perubahan yang lengkap membuat tim bisa membedakan kesalahan input, gangguan proses, dan perubahan yang tidak berwenang.
3. Enam Penyebab Selisih yang Paling Sering Terjadi
Selisih tidak selalu berarti fraud. Banyak selisih berasal dari proses normal yang tidak punya status jelas. Meski begitu, setiap selisih tetap perlu ditelusuri karena kesalahan kecil yang dibiarkan bisa menjadi temuan berulang.
3.1 Cutoff berbeda
Cabang sudah menutup hari pada pukul 17.00, sedangkan kantor pusat masih menerima transaksi sampai pukul 18.00. Atau cabang memasukkan tanggal transaksi berdasarkan waktu input, sementara kantor pusat memakai tanggal penyelesaian transaksi (settlement).
Gejalanya adalah selisih yang muncul pada akhir hari dan hilang pada rekonsiliasi hari berikutnya. Cara menutupnya bukan dengan jurnal langsung, melainkan dengan menyamakan definisi cutoff, mencatat transaksi setelah cutoff sebagai transaksi periode berikutnya, dan memantau item yang memang masih dalam perjalanan.
3.2 Transaksi gagal, tertunda, atau masuk antrean
Koneksi terputus ketika transaksi dikirim dari cabang. Cabang sudah menerima nomor transaksi, tetapi server pusat belum menyelesaikan posting. Pada kondisi lain, server pusat sudah memproses transaksi, tetapi respons tidak kembali ke cabang.
Inilah yang disebut mismatch status: dua sistem memiliki status berbeda untuk transaksi yang sama. Satu sisi menulis berhasil, sisi lain menulis gagal atau menunggu. Periksa log aplikasi, nomor batch, antrean transaksi, dan waktu pengiriman sebelum membuat koreksi.
3.3 Kode cabang atau akun tujuan salah
Transaksi bisa berhasil diproses, tetapi masuk ke cabang atau akun antar-cabang yang keliru. Kesalahan ini sering terjadi ketika kode cabang ditulis manual atau daftar kode tidak diperbarui setelah perubahan organisasi.
Tanda-tandanya adalah satu cabang memiliki saldo lebih besar dari seharusnya, sementara cabang lain memiliki item tanpa pasangan. Telusuri kode asal, kode tujuan, dan mapping akun. Setelah diperbaiki, uji beberapa transaksi dari awal sampai laporan akhir.
3.4 Transaksi ganda atau reversal tidak lengkap
Transaksi ganda terjadi ketika pengguna menekan kirim dua kali, sistem mengulang batch, atau petugas memasukkan ulang transaksi setelah mengira transaksi pertama gagal. Kebalikannya adalah reversal, yaitu pembalikan transaksi yang semestinya menghapus dampak transaksi awal.
Reversal yang hanya terjadi di satu sisi akan menimbulkan selisih baru. Karena itu, pasangan transaksi dan pasangan reversal perlu dilihat bersama. Jangan menghapus transaksi awal untuk membuat total terlihat sama; simpan hubungan antara transaksi asli dan pembalikannya.
3.5 Transfer kas dan penyelesaian transaksi belum selesai
Transfer fisik antar-cabang memiliki jeda. Cabang pengirim sudah mengurangi kas, tetapi cabang penerima belum menghitung dan mencatat kas yang datang. Pada transaksi melalui bank, dana bisa masih berada di rekening perantara atau menunggu konfirmasi bank koresponden.
Gunakan akun in transit atau akun dalam perjalanan jika memang dibutuhkan oleh desain akuntansi. Akun ini bukan tempat menyembunyikan selisih. Setiap saldo harus memiliki daftar transaksi, tanggal kirim, estimasi tiba, bukti serah terima, dan pemilik yang menindaklanjuti.
3.6 Jurnal manual, parameter, atau mapping yang keliru
Jurnal manual bisa memakai akun, cabang, atau tanggal yang salah. Parameter produk juga dapat berubah sehingga transaksi baru masuk ke akun berbeda dari transaksi lama. Misalnya, kode biaya administrasi di cabang A sudah diperbarui, tetapi cabang B masih memakai kode lama.
Untuk penyebab ini, periksa siapa yang mengubah parameter, kapan perubahan berlaku, apakah ada persetujuan, dan transaksi mana yang terdampak. Perbaiki sumber masalahnya terlebih dahulu. Jurnal koreksi hanya menutup dampak, bukan akar penyebab.
4. Cara Menutup Selisih Tanpa Menebak
Menutup selisih tidak berarti membuat dua total terlihat sama secepat mungkin. Selisih dianggap tertutup jika penyebabnya diketahui, koreksinya disetujui, hasilnya diuji, dan bukti tersimpan.
4.1 Buat daftar exception dengan nomor kasus
Jangan menyimpan selisih hanya di spreadsheet tanpa nomor kasus. Beri ID seperti REC-2026-10-001. Satu ID untuk satu masalah atau satu kelompok transaksi yang memiliki penyebab sama.
Minimal, daftar exception berisi:
| Kolom | Isi yang perlu dicatat |
|---|---|
| ID kasus | Nomor unik dan tanggal dibuka |
| Pasangan transaksi | ID asal, ID tujuan, batch, atau nomor jurnal |
| Selisih | Nominal, akun, cabang, dan periode |
| Status | Baru, ditelusuri, menunggu, dikoreksi, atau selesai |
| Pemilik | Orang atau unit yang wajib menindaklanjuti |
| Akar masalah | Cutoff, gagal proses, mapping, duplikasi, atau lainnya |
| Tindakan | Koreksi sistem, jurnal, reprocess, atau konfirmasi |
| Bukti | Log, mutasi, formulir, persetujuan, atau screenshot |
| Tenggat | Tanggal penyelesaian dan tanggal verifikasi |
Daftar ini membuat pekerjaan terlihat. Manajer tidak perlu bertanya kepada lima orang untuk mengetahui selisih mana yang masih terbuka.
4.2 Cocokkan dari ID, lalu turun ke nominal
Mulai dengan ID transaksi. Jika ID tidak tersedia, gunakan kombinasi tanggal, cabang, rekening, jenis transaksi, dan nominal. Jangan langsung mengubah nominal atau membuat jurnal penyeimbang.
Jika transaksi tidak ditemukan, telusuri urutannya: dibuat di cabang, dikirim ke server, diproses di pusat, diposting ke buku besar, lalu muncul di laporan. Di setiap tahap, cari bukti waktu dan status.
4.3 Bedakan selisih waktu dan selisih nyata
Selisih waktu biasanya memiliki pola: muncul setelah cutoff, punya nomor transaksi, dan hilang setelah batch selesai. Selisih nyata tidak hilang setelah periode berikutnya dan biasanya tidak memiliki pasangan atau memiliki nilai yang berbeda.
Buat aturan aging. Aging adalah umur item sejak pertama kali muncul. Contohnya:
- 0–1 hari: masih dalam pemantauan proses normal.
- 2–3 hari: wajib ditinjau oleh supervisor.
- Lebih dari 3 hari: harus punya analisis akar masalah dan rencana penutupan.
- Melewati akhir bulan: dilaporkan kepada kepala operasional dan akuntansi.
Angka hari di atas adalah contoh aturan internal, bukan batas regulasi universal. Bank perlu menyesuaikannya dengan jenis transaksi, kesepakatan tingkat layanan (SLA) sistem, jam operasional, dan risiko.
4.4 Koreksi dengan jalur yang bisa diaudit
Koreksi dapat berupa reprocess transaksi, jurnal pembalik, jurnal koreksi, perbaikan mapping, atau pembaruan parameter. Pilih tindakan berdasarkan penyebabnya.
Setiap koreksi harus punya pembuat dan pemeriksa yang berbeda jika risikonya memungkinkan. Simpan nilai sebelum, nilai sesudah, alasan, persetujuan, tanggal, dan nomor kasus. Jangan memakai akun sementara tanpa batas waktu dan tanpa daftar saldo yang harus dibersihkan.
4.5 Uji ulang setelah koreksi
Setelah koreksi dilakukan, jalankan rekonsiliasi ulang. Pastikan transaksi yang diperbaiki tidak menciptakan selisih baru pada cabang lain, akun lain, atau periode berikutnya.
Uji juga transaksi yang serupa. Kalau satu transaksi salah karena mapping kode cabang, periksa transaksi lain yang memakai mapping tersebut. Menutup satu baris tanpa memeriksa pola bisa membuat masalah yang sama muncul lagi besok.
5. Contoh Satu Selisih dari Awal sampai Selesai
Misalkan cabang A mencatat pengiriman kas Rp25.000.000 ke kantor pusat pada 26 Oktober 2026 pukul 16.50. Di catatan cabang A, kas sudah berkurang. Di kantor pusat, penerimaan belum tercatat sampai pukul 17.00.
Tim tidak langsung membuat jurnal penerimaan. Mereka membuka nomor referensi dan menemukan bahwa transaksi masuk ke antrean karena koneksi terputus. Log menunjukkan transaksi diterima server pukul 17.08 dan diposting ke buku besar pukul 17.10.
Kasus tersebut diberi status in transit, bukan selisih tidak terjelaskan. Setelah batch selesai, rekonsiliasi ulang menunjukkan kedua sisi sudah cocok. Bukti yang disimpan adalah nomor referensi, log antrean, waktu posting, laporan rekonsiliasi sebelum dan sesudah, serta nama petugas yang memverifikasi.
Bandingkan dengan kasus lain. Cabang B mencatat pengiriman Rp40.000.000, tetapi kantor pusat menerima Rp4.000.000. Nomor referensi sama, tanggal sama, dan tidak ada gangguan sistem. Ini bukan selisih waktu. Tim perlu memeriksa input nominal, persetujuan, dokumen pengiriman, dan jurnal yang terbentuk. Koreksi baru dilakukan setelah sumber kesalahan disepakati.
Dua contoh ini menunjukkan mengapa status dan bukti penting. Nominal yang sama-sama berbeda bisa membutuhkan tindakan yang berbeda.
6. Siapa Melakukan Apa?
Rekonsiliasi mudah macet jika semua orang merasa hanya membantu, tetapi tidak ada yang memiliki kasus. Bagi tanggung jawab sejak awal.
Operasional cabang
- Memastikan transaksi sumber memiliki nomor referensi dan dokumen pendukung.
- Menjelaskan transaksi yang hanya muncul di catatan cabang.
- Mengonfirmasi kas fisik, bukti pengiriman, dan penerimaan.
- Menutup kasus yang memang menjadi tanggung jawab cabang.
Akuntansi atau operasional kantor pusat
- Menetapkan format dan jadwal rekonsiliasi.
- Menjaga daftar exception dan aging.
- Memeriksa jurnal koreksi serta saldo akun in transit.
- Menyusun ringkasan selisih untuk Direksi atau komite terkait.
TI dan vendor sistem
- Menyediakan log proses, status antrean, dan histori perubahan.
- Menganalisis kegagalan batch, waktu tunggu habis (timeout), duplikasi, dan pemetaan (mapping).
- Memperbaiki akar masalah tanpa menghapus jejak transaksi.
- Menguji perubahan di lingkungan yang sesuai sebelum dipakai.
Supervisor dan audit intern
- Memeriksa kasus melewati tenggat.
- Menguji sampel transaksi yang sudah dinyatakan selesai.
- Melihat apakah koreksi menyelesaikan akar masalah atau hanya menyeimbangkan angka.
- Memastikan temuan berulang mendapat pemilik dan tenggat.
Pembagian ini sejalan dengan prinsip pengendalian internal: orang yang membuat transaksi tidak seharusnya menjadi satu-satunya orang yang menyetujui koreksi. Untuk pembahasan lebih luas mengenai kesiapan bukti, lihat panduan pemeriksaan OJK dari sisi sistem dan TI.
7. Checklist Rekonsiliasi Harian dan Bulanan
Gunakan checklist yang pendek, tetapi wajib menghasilkan bukti.
Checklist harian
- Periode dan cutoff kedua sisi sudah sama.
- Semua transaksi antar-cabang memiliki nomor referensi.
- Daftar matched, in transit, dan exception sudah terbentuk.
- Selisih kas fisik dan saldo sistem sudah dijelaskan.
- Item baru memiliki pemilik dan tenggat.
- Item lama tidak ditutup hanya dengan komentar “sedang dicek”.
Checklist akhir bulan
- Saldo akun antar-cabang sudah memiliki rincian per transaksi.
- Tidak ada item tanpa pemilik atau tanpa tanggal pembukaan.
- Item melewati tenggat sudah dilaporkan kepada pejabat yang berwenang.
- Jurnal koreksi memiliki persetujuan dan dokumen pendukung.
- Perubahan parameter selama bulan berjalan sudah ditinjau.
- Rekonsiliasi ditandatangani atau disetujui secara elektronik oleh pembuat dan pemeriksa.
- Bukti disimpan di lokasi yang dapat ditemukan kembali.
Checklist ini bukan pengganti analisis. Ia hanya memastikan langkah dasar tidak terlewat. Jika jumlah cabang bertambah, bank mungkin perlu memakai aplikasi inti perbankan yang dapat menyimpan ID transaksi, status, log, dan laporan per cabang secara konsisten. Tetap sesuaikan klaim kemampuan dengan fitur yang benar-benar tersedia pada sistem yang dipakai.
8. Rencana Perbaikan 30/60/90 Hari
Jika selisih sudah menumpuk, jangan mencoba menyelesaikan semuanya sekaligus tanpa prioritas. Mulai dari transaksi yang paling berisiko dan paling sering berulang.
| Waktu | Fokus | Keluaran |
|---|---|---|
| 0–30 hari | Inventaris sumber data, akun antar-cabang, cutoff, dan selisih terbuka | Daftar rekening, peta alur transaksi, register exception, serta pemilik tiap kasus |
| 31–60 hari | Menutup item lama dan memperbaiki penyebab berulang | Saldo in transit bersih, mapping diperbaiki, aturan cutoff disepakati, dan laporan aging berjalan |
| 61–90 hari | Menguji keberlanjutan dan memperkuat sistem | Rekonsiliasi otomatis atau semi-otomatis, sampel uji audit, prosedur operasional standar (SOP) final, dan laporan kepada Direksi |
Pada 30 hari pertama, jangan mengejar otomatisasi sebelum definisi transaksi jelas. Sistem yang otomatis mencocokkan data yang salah hanya akan menghasilkan kesalahan dengan lebih cepat.
Pada 60 hari berikutnya, lihat pola. Jika selisih selalu muncul di satu cabang setelah koneksi putus, perbaiki proses antrean dan prosedur retry. Jika selisih selalu muncul saat pergantian petugas, perbaiki serah terima dan pemisahan tugas.
Pada 90 hari, uji proses seperti pemeriksa atau auditor. Ambil sampel dari laporan akhir bulan, minta tim menemukan pasangan transaksinya, lalu lihat apakah bukti bisa ditemukan tanpa bertanya kepada orang yang membuatnya.
9. Kesimpulan
Rekonsiliasi antar-cabang bukan lomba membuat total terlihat sama. Pekerjaan intinya adalah menemukan pasangan transaksi, menjelaskan item yang belum cocok, lalu menutupnya dengan koreksi dan bukti yang bisa ditelusuri.
Mulailah dari definisi dua sisi, periode, cutoff, dan kunci pencocokan. Setelah itu, pisahkan transaksi yang sudah cocok, masih dalam perjalanan, dan benar-benar menjadi exception. Selisih yang tidak memiliki pemilik akan terus kembali ke laporan berikutnya.
Perbaikan paling kuat biasanya bukan jurnal tambahan, tetapi akar masalah yang ditutup: kode cabang yang benar, status transaksi yang konsisten, log yang tersedia, prosedur serah terima yang jelas, dan pemeriksaan yang dilakukan oleh orang berbeda.
Jika rekonsiliasi sudah memiliki nomor kasus, aging, pemilik, tenggat, serta bukti penutupan, cabang dan kantor pusat tidak lagi bekerja berdasarkan ingatan. Mereka bekerja dari catatan yang sama.
Referensi
- OJK — “POJK Nomor 9 Tahun 2024 tentang Penerapan Tata Kelola bagi Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/POJK-9-2024-Penerapan-Tata-Kelola-bagi-BPR-dan-BPRS.aspx
- OJK — “POJK Nomor 41/POJK.03/2017 tentang Persyaratan dan Tata Cara Pemeriksaan Bank”. https://ojk.go.id/id/regulasi/Pages/Persyaratan-dan-Tata-Cara-Pemeriksaan-Bank-.aspx
- OJK — “POJK Nomor 75/POJK.03/2016 tentang Standar Penyelenggaraan Teknologi Informasi bagi Bank Perkreditan Rakyat dan Bank Pembiayaan Rakyat Syariah”. https://peraturan.bpk.go.id/Details/129781/peraturan-ojk-no-75-pojk032016-tahun-2016
- OJK — “SEOJK Nomor 15/SEOJK.03/2017 tentang Standar Penyelenggaraan Teknologi Informasi bagi Bank Perkreditan Rakyat dan Bank Pembiayaan Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/SEOJK-tentang-Standar-Penyelenggaraan-Teknologi-Informasi-bagi-Bank-Perkreditan-Rakyat-dan-Bank-Pembiayaan-Rakyat-Syariah.aspx
- OJK — “POJK Nomor 34 Tahun 2025 tentang Penyelenggaraan Teknologi Informasi oleh Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/POJK-34-Tahun-2025-Penyelenggaraan-Teknologi-Informasi-oleh-Bank-Perekonomian-Rakyat-dan-Bank-Perekonomian-Rakyat-Syariah.aspx
- OJK — “PADK Nomor 43/PADK.03/2025 tentang Penyelenggaraan Teknologi Informasi oleh Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/PADK-43-PADK03-2025-Penyelenggaraan-Teknologi-Informasi-oleh-BPR-BPRS.aspx
- OJK — “POJK Nomor 12 Tahun 2024 tentang Penerapan Strategi Anti Fraud bagi Lembaga Jasa Keuangan”. https://peraturan.bpk.go.id/Details/301737/peraturan-ojk-no-12-tahun-2024