Integrasi LOS dengan core banking BPR menghubungkan proses pengajuan kredit dengan sistem inti perbankan melalui pertukaran data yang disepakati. Rancangannya perlu menetapkan sumber data, kewenangan persetujuan, status pengiriman, dan cara menangani perbedaan. Tujuannya agar petugas dapat mengetahui pengajuan mana yang sudah diterima sistem tujuan dan mana yang masih perlu ditindaklanjuti.
Masalah dapat muncul ketika layar LOS menampilkan “terkirim”, sementara petugas belum menemukan pencatatannya di core banking. Jika pengiriman diulang tanpa pemeriksaan, data berpotensi terbentuk dua kali. Contoh ilustratif ini menunjukkan bahwa koneksi antar-aplikasi perlu disertai kontrol proses dan rekonsiliasi.
Artikel ini membahas keputusan implementasi yang perlu disepakati bank bersama pengelola kedua sistem. LOS merupakan pilihan aplikasi pendukung proses kredit, bukan pembelian yang secara khusus diwajibkan POJK 34 Tahun 2025.
Tentukan Batas Fungsi LOS Dan Core Banking
Loan Origination System atau LOS dapat mengelola pengumpulan data, dokumen, pemeriksaan, dan persetujuan pengajuan. Core banking menjalankan fungsi inti sesuai cakupan sistem bank. Pembagian peran keduanya harus ditetapkan sebelum menentukan data yang dipertukarkan.
Sebagai contoh, LOS dapat menjadi tempat penyusunan pengajuan, sedangkan pencatatan fasilitas yang telah diterima dilakukan melalui proses resmi core banking. Bank perlu menentukan kapan suatu pengajuan boleh diteruskan dan siapa yang berwenang memicu proses tersebut.
Jangan membiarkan dua aplikasi sama-sama menjadi pemilik nilai yang identik tanpa aturan. Untuk landasan kebutuhan aplikasi internal, lihat panduan pengembangan aplikasi BPR. Untuk cakupan regulasinya, gunakan panduan POJK 34 Tahun 2025 untuk BPR.
Periksa Jalur Integrasi Yang Diizinkan
Minta dokumentasi integrasi dari pengelola core banking: antarmuka yang tersedia, format data, mekanisme autentikasi, pembatasan akses, dan lingkungan uji. Konfirmasikan pula proses persetujuan serta biaya pihak ketiga yang mungkin diperlukan.
Jalur yang tersedia dapat berupa API atau pertukaran berkas terkontrol. Pilih berdasarkan kemampuan sistem dan kebutuhan proses. Akses database langsung tidak boleh dianggap sebagai izin untuk menulis data transaksi. Perubahan melalui jalur yang tidak disepakati dapat melewati validasi dan kontrol aplikasi tujuan.
Pastikan penawaran pengembang menyebut ketergantungan tersebut. Komitmen integrasi yang dibuat sebelum dokumentasi diperiksa perlu disertai asumsi yang terlihat. Bank dapat meninjau pembagian pekerjaan melalui panduan memilih vendor TI BPR.
Susun Kontrak Data Untuk Integrasi LOS Dengan Core Banking BPR
Kontrak data menjelaskan informasi yang dikirim, arti setiap kolom, serta aturan pemeriksaannya. Istilah ini merujuk pada spesifikasi pertukaran data, bukan jenis perjanjian yang diwajibkan dengan nama tertentu oleh POJK.
Sepakati pengenal nasabah, nomor pengajuan, nilai, tanggal, kode produk, status, dan referensi dokumen yang memang diperlukan. Jelaskan satuan serta formatnya. Data kosong, nilai nol, dan informasi yang belum diketahui dapat memiliki arti berbeda sehingga tidak boleh dipertukarkan sembarangan.
Sertakan aturan pembaruan: kolom mana yang dapat direvisi, sistem mana yang memutuskan nilai final, dan kapan perubahan harus melalui pemeriksaan ulang. Dokumentasi yang rinci membantu kedua vendor menangani perubahan tanpa menebak makna data.
Kaitkan Pengiriman Dengan Versi Yang Disetujui
Data yang dikirim harus dapat dihubungkan dengan keputusan persetujuannya. Jika pengajuan direvisi setelah disetujui, tentukan apakah persetujuan perlu diulang. Jangan sampai sistem menampilkan nama pemberi persetujuan lama untuk nilai baru yang belum diperiksanya.
Gunakan pengenal versi atau mekanisme setara sesuai rancangan. Catat tindakan pengguna dan proses otomatis yang memicu pengiriman. Pembatasan kewenangan perlu diterapkan pada jalur pemrosesan, bukan hanya pada tombol di layar.
Untuk BPR Syariah, pemetaan produk dan aturan proses perlu mengikuti kebijakan serta ketentuan terkait yang ditelaah pihak berwenang. Pengembang tidak menetapkan sendiri kesesuaian akad. Pemilik proses bank harus menyetujui aturan bisnis sebelum aturan itu diterapkan dalam aplikasi.
Bedakan Status Permintaan Dan Hasil Pencatatan
Pengiriman permintaan, penerimaan pesan, dan penyelesaian proses merupakan kejadian berbeda. Tampilan aplikasi perlu memakai status yang menjelaskan perbedaan tersebut. Petugas harus mengetahui kapan proses selesai dan kapan hasilnya masih belum dapat dipastikan.
| Status Ilustratif | Arti Untuk Petugas | Tindak Lanjut |
|---|---|---|
| Menunggu pengiriman | Data siap, belum dikirim | Periksa antrean sesuai kewenangan |
| Diterima sistem tujuan | Pesan diterima, proses belum tentu selesai | Tunggu hasil atau periksa status |
| Selesai | Hasil tujuan dan referensinya terkonfirmasi | Lanjutkan proses yang diizinkan |
| Ditolak | Validasi tujuan gagal | Perbaiki berdasarkan alasan yang tersedia |
| Belum terkonfirmasi | Balasan tidak cukup untuk memastikan hasil | Lakukan pengecekan sebelum mengulang |
Nama dan jumlah status disesuaikan dengan kemampuan sistem. Yang penting, informasi di layar tidak menyamarkan ketidakpastian menjadi keberhasilan.
Cegah Pengulangan Menghasilkan Data Ganda
Koneksi dapat terputus setelah sistem tujuan menerima data tetapi sebelum balasannya sampai. Karena itu, pengiriman ulang perlu memiliki identitas permintaan yang dapat dikenali atau mekanisme pemeriksaan hasil yang setara.
Tanyakan apakah antarmuka tujuan mendukung pengulangan yang aman. Jika tidak, susun aturan pencocokan dan penyelesaian yang realistis. Fitur pada satu sisi tidak otomatis membuat seluruh alur bebas duplikasi; kemampuan kedua sistem harus diperiksa.
Tentukan siapa yang boleh mengulang proses dan bukti apa yang diperiksa terlebih dahulu. Hindari penyelesaian rutin melalui perubahan database manual. Jika penanganan khusus diperlukan, gunakan kewenangan, persetujuan, dan pencatatan yang telah ditentukan bank.
Sediakan Rekonsiliasi Dan Penanggung Jawab Selisih
Rekonsiliasi membandingkan hasil pada LOS dengan data yang diterima sistem tujuan. Mulailah dari pengenal, jumlah pengajuan, status, serta nilai yang relevan. Perbandingan total saja dapat melewatkan satu objek hilang dan satu objek ganda yang kebetulan saling menutup.
Laporan selisih perlu menunjukkan objek yang harus ditelusuri, sumber perbedaan yang telah diketahui, dan pihak yang menanganinya. Pisahkan fakta dari dugaan. Status “menunggu pemeriksaan” lebih tepat daripada menyatakan data hilang sebelum kedua sisi diperiksa.
Tetapkan jadwal dan pemilik tindak lanjut sesuai risiko operasional. Keberadaan laporan belum membuktikan kontrol berjalan jika selisih terus terbuka tanpa keputusan. Bukti penyelesaian perlu terhubung dengan pengajuan dan catatan perbaikannya.
Simpan Jejak Yang Menghubungkan Kedua Sistem
Catat pengenal proses, aktor, waktu, versi data, hasil, dan referensi tujuan yang diperlukan. Jangan menyalin seluruh dokumen nasabah ke log hanya untuk memudahkan pencarian. Pengelolaan akses dan masa simpan catatan tetap perlu mengikuti kebijakan bank.
Pasal 40 ayat (4) pada POJK 34 Tahun 2025 mengatur ketersediaan jejak audit. Pasal 31 juga mengatur kemampuan aplikasi inti, termasuk pembukuan antarjaringan kantor dengan kondisi yang dibedakan dalam pasalnya dan log aktivitas sistem.
Ketentuan tersebut tidak boleh disederhanakan menjadi klaim bahwa semua integrasi LOS harus memakai satu teknologi tertentu. Gunakan panduan audit trail sistem BPR untuk merinci catatan sesuai kebutuhan pemeriksaan.
Uji Kondisi Gagal Sebelum Peralihan
Siapkan data sintetis dan lingkungan uji yang disepakati. Periksa pengiriman valid, data tidak lengkap, pengajuan yang direvisi, pengulangan, koneksi putus, serta balasan terlambat. Hasil yang diharapkan harus ditetapkan sebelum uji dijalankan.
Libatkan petugas pengguna agar mereka dapat mencoba tindak lanjutnya. Sistem yang memberi pesan kesalahan teknis tanpa langkah operasional masih menyisakan pekerjaan. Pastikan petugas mengetahui kapan harus menunggu, memperbaiki, atau menghubungi pengelola.
Catat cakupan yang belum bisa diuji karena keterbatasan antarmuka vendor. Jangan melaporkan integrasi selesai hanya karena koneksi berhasil. Untuk perpindahan sistem, siapkan batas peralihan dan rencana kembali yang mempertimbangkan data baru yang sudah tercatat.
Menyiapkan Pembahasan Integrasi Bersama Layana.id
Bahan awal yang berguna adalah alur pengajuan, diagram aplikasi, dokumentasi antarmuka, dan daftar masalah aktual. Pisahkan kebutuhan membenahi integrasi dari kebutuhan mengganti core banking. Jika arah perubahan belum jelas, mulai dengan assessment TI BPR.
Layana.id dapat diajak membahas kebutuhan melalui layanan custom development. Ruang lingkup perlu mencakup pembagian tanggung jawab dengan vendor core banking, mekanisme rekonsiliasi, pengujian, dan serah terima operasional.
Diskusikan integrasi LOS dan core banking BPR bersama Layana.id dengan membawa contoh alur tanpa data nasabah sensitif. Hasil pembahasan yang dibutuhkan adalah rancangan pertukaran data serta kriteria penerimaan yang dapat diperiksa kedua pihak, sehingga integrasi dapat digunakan dan diawasi setelah berjalan.
Aplikasi Finance Karya Layana
Aplikasi nasabah, alur pengajuan kredit, dan web admin untuk KB Bukopin Finance, BPR CMA, serta BPR MSA.
KB Bukopin Finance
Dari Simulasi Ke Pengajuan Pembiayaan
Aplikasi Android dan web admin untuk informasi produk, simulasi pembiayaan, serta pengumpulan pengajuan calon nasabah. Lingkup proyek mencakup perancangan integrasi e-KYC Privy.ID, skor kredit pihak ketiga CLIK, dan pengembangan skoring berbasis data internal.
BPR CMA
Alur Kredit Dalam Genggaman Tim
Aplikasi mobile dan web admin untuk pengajuan serta survei kredit. Cakupannya membantu marketing dan komite kredit mengelola pengecekan data, exposure, serta analisis jaminan. Pengajuan dan status pekerjaan menjadi bagian dari alur yang dapat ditelusuri tim.
MSA On Hand
Layanan Nasabah Dan Komunitas UMKM
Aplikasi BPR Madani Sejahtera Abadi untuk pengajuan kredit, pembukaan rekening dan deposito, pembayaran, serta forum komunitas. Lingkup proyek Layana juga mencakup web admin, pengelolaan pengajuan oleh marketing dan notaris, serta laporan operasional.
MSA on Hand tersedia di Google Play dengan PT. Layana Computindo Sentratama tercantum sebagai developer.
Contoh tersebut menunjukkan konteks alur pengajuan dan penilaian kredit, bukan bukti bahwa integrasi dengan core banking tertentu sudah tersedia. Untuk proyek baru, antarmuka resmi, pemilik data, status pengiriman, dan mekanisme rekonsiliasi perlu diperiksa bersama pengelola sistem inti.
Bicarakan Aplikasi BPR Anda
Ceritakan proses yang masih manual, sistem yang digunakan, dan fitur yang ingin dibuat. Tim Layana dapat membantu membahas kebutuhan, batas integrasi, dan tahapan pengembangan.
Referensi
- POJK Nomor 34 Tahun 2025, terutama Pasal 15, 31, 35–36, dan 40.
- Halaman Regulasi Dan FAQ OJK.