Pengembangan aplikasi BPR perlu dimulai dari proses bisnis dan kontrol yang harus dijalankan. Aplikasi pengajuan kredit, CRM, atau portal internal dapat membantu pekerjaan bank, tetapi daftar menu saja belum menjelaskan siapa yang boleh mengubah data, bagaimana keputusan disetujui, dan apakah pertukaran data dapat diperiksa.
Misalnya, petugas mengubah nilai pengajuan setelah analis memberikan persetujuan. Apa yang seharusnya terjadi? Sistem dapat meminta pemeriksaan ulang, mempertahankan versi yang sudah disetujui, atau menolak perubahan tertentu sesuai kebijakan bank. Keputusan ini harus menjadi bagian spesifikasi sebelum pengembang membuat antarmuka.
Dalam konteks POJK 34 Tahun 2025, software merupakan salah satu alat untuk melaksanakan pengendalian. Artikel ini membahas rancangan dan kriteria penerimaan aplikasi internal, bukan menyatakan bahwa BPR wajib membeli LOS atau mengganti core banking.
Tentukan Peran Aplikasi Dalam Sistem Bank
Mulailah dengan menetapkan fungsi aplikasi. Apakah aplikasi mengelola pengajuan sebelum pencatatan di core banking, menyimpan dokumen pendukung, atau menampilkan status proses? Batas tersebut menentukan sumber data utama dan pihak yang bertanggung jawab atas setiap perubahan.
Loan Origination System atau LOS, misalnya, dapat dipakai untuk mengelola tahapan pengajuan kredit. Sementara itu, aplikasi inti perbankan memiliki cakupan yang didefinisikan pada Pasal 1 POJK. Menambah LOS tidak otomatis menggantikan fungsi inti atau menjadikannya sumber pembukuan bank. Untuk menentukan bagian yang layak dipertahankan atau dibenahi, lihat pilihan modernisasi sistem BPR.
Gambarkan hubungan antar-aplikasi sebelum menetapkan fitur. Untuk konteks regulasinya, lihat kewajiban TI dalam POJK 34 Tahun 2025. Jika kebutuhan awal belum jelas, gunakan checklist kesiapan TI BPR untuk menemukan masalah yang paling mendesak.
Ubah Alur Kerja Menjadi Aturan Yang Bisa Diuji
Dokumentasikan tahapan dari pembuatan data hingga penyelesaian proses. Setiap tahap membutuhkan pelaku, input, keputusan, hasil, dan kondisi gagal. Jangan membiarkan pengembang menebak aturan persetujuan hanya dari contoh layar aplikasi lama.
Contoh kebutuhan yang jelas adalah: “Petugas pembuat pengajuan tidak dapat menyetujui pengajuan yang dibuatnya sendiri.” Contoh lainnya: “Perubahan nilai setelah persetujuan mengembalikan proses ke tahap pemeriksaan.” Keduanya lebih mudah diuji daripada permintaan “approval harus aman”.
Bank perlu menentukan kebijakan dan pengecualiannya. Pengembang menerjemahkan keputusan itu menjadi perilaku sistem. Jika ada delegasi atau pejabat pengganti, tetapkan batas waktu, kewenangan, dan pencatatannya agar pengecualian tidak menjadi jalan pintas permanen.
Rancang Hak Akses Berdasarkan Tindakan Dan Cakupan Data
Hak akses sebaiknya menjelaskan tindakan yang diperbolehkan sekaligus data yang dapat dijangkau. Peran analis di satu cabang belum tentu boleh melihat seluruh cabang. Pengguna yang boleh membaca dokumen juga belum tentu boleh mengekspornya.
Susun matriks yang mencakup pembuatan, pembacaan, perubahan, persetujuan, pembatalan, ekspor, dan pengelolaan akses. Pasal 15 pada naskah POJK mengatur pengendalian otorisasi. Detail matriks merupakan keputusan implementasi yang perlu mengikuti kewenangan bank.
Pembatasan tidak boleh hanya menyembunyikan tombol. Jalur akses data di sisi server juga perlu memeriksa kewenangan. Saat pengujian, coba akses objek di luar cakupan menggunakan akun uji berizin. Hasil yang diterima harus mengikuti matriks, termasuk ketika pengguna mengakses tautan objek secara langsung.
Jadikan Audit Trail Bagian Dari Desain Awal
Pasal 40 ayat (4) mengatur ketersediaan jejak audit. Untuk aplikasi, terjemahkan kebutuhan itu menjadi daftar aktivitas penting yang dapat ditelusuri. Contohnya pembuatan pengajuan, revisi data, persetujuan, perubahan hak akses, dan ekspor dokumen.
Catatan perlu cukup untuk menjawab siapa melakukan apa, pada objek mana, kapan, dan bagaimana hasilnya. Untuk perubahan tertentu, riwayat versi atau nilai sebelum dan sesudah dapat membantu. Namun, penyimpanan nilai sensitif harus dibatasi sesuai kebutuhan dan kebijakan data.
Jangan menambahkan audit trail setelah seluruh fitur selesai tanpa memeriksa alur. Beberapa aktivitas mungkin sudah tidak meninggalkan bukti yang diperlukan. Pembahasan rinci tentang isi, perlindungan, dan pengujian catatan tersedia dalam panduan audit trail sistem BPR.
Integrasi Harus Menjelaskan Sumber Data Dan Status Pengiriman
Sebelum menghubungkan aplikasi baru ke core banking, sepakati sistem pemilik data dan cara pembaruannya. Tetapkan pengenal pengajuan, pengenal nasabah yang relevan, format nilai, serta aturan perubahan status. Hindari dua aplikasi mengubah data yang sama tanpa aturan penyelesaian perbedaan.
Periksa ketersediaan jalur integrasi resmi bersama pengelola core banking. Dokumentasi API, izin akses, biaya, serta lingkungan uji dapat menjadi ketergantungan proyek. Pengembang baru tidak boleh menjanjikan integrasi hanya berdasarkan dugaan bahwa database bisa diakses.
Jika jalur yang tersedia berupa pertukaran berkas, dokumentasikan format, jadwal, pemeriksaan kelengkapan, dan rekonsiliasinya. Pilihan teknis mengikuti kebutuhan serta izin bank. Jangan menyebut setiap pertukaran data sebagai real time bila masih memiliki jeda atau proses manual.
Antisipasi Pengiriman Gagal Dan Data Ganda
Sebagai ilustrasi, aplikasi mengirim pengajuan, tetapi koneksi terputus sebelum balasan diterima. Sistem tujuan mungkin sudah menyimpannya. Jika petugas menekan kirim kembali, pengembang perlu memastikan proses tidak menghasilkan pengajuan kedua tanpa sengaja.
Salah satu pendekatan adalah memberi pengenal permintaan yang konsisten dan mekanisme pengecekan hasil. Rancang pula status yang membedakan menunggu, berhasil, gagal, dan belum dapat dipastikan. Detail teknisnya disepakati bersama kemampuan sistem tujuan; bukan fitur yang boleh diasumsikan tersedia.
Sediakan rekonsiliasi untuk membandingkan data pada kedua sisi. Uji bukan hanya keberhasilan pengiriman, tetapi juga pengulangan, keterlambatan, balasan tidak lengkap, dan proses yang terhenti. Petugas perlu mengetahui tindakan berikutnya tanpa mengubah database secara manual. Perincian status, pengiriman ulang, dan rekonsiliasi tersedia pada integrasi LOS dengan core banking BPR.
Batasi Penyimpanan Dokumen Dan Data Uji
Dokumen pengajuan dapat berisi informasi pribadi. Tentukan siapa yang boleh membuka, mengunduh, mengganti, dan membagikannya. Tautan dokumen perlu tetap memeriksa hak akses, bukan hanya mengandalkan alamat yang sulit ditebak. Batas pembacaan, unduhan, dan ekspor dibahas pada keamanan data nasabah BPR.
Pisahkan lingkungan pengembangan, pengujian, dan produksi. Gunakan data sintetis atau data yang telah disamarkan untuk pekerjaan yang tidak memerlukan identitas sebenarnya. Akses dukungan teknis juga perlu persetujuan dan pencatatan sesuai kebijakan bank.
Enkripsi, masking, serta pengelolaan persetujuan dapat menjadi bagian rancangan. Akan tetapi, pilihan fitur harus mengikuti kebutuhan pemrosesan dan evaluasi hukum. Pasal 35–36 menjadi rujukan pengelolaan data serta pelindungan data pribadi; pemasangan fitur tunggal tidak membuktikan seluruh kewajiban terpenuhi.
Tentukan Kriteria Penerimaan Sebelum Pembangunan
Kriteria penerimaan menghubungkan kebutuhan dengan hasil yang harus diperlihatkan vendor. Tabel berikut merupakan contoh untuk aplikasi internal; bank dapat mengubahnya sesuai proses dan risiko.
| Kebutuhan | Contoh Hasil Yang Harus Dibuktikan |
|---|---|
| Pemisahan pembuat dan pemeriksa | Pembuat pengajuan ditolak ketika mencoba menyetujui pengajuan sendiri |
| Pembatasan cabang | Akun uji tidak dapat membaca objek di luar cakupannya |
| Riwayat perubahan | Revisi terhubung dengan aktor, waktu, alasan, serta versi terkait |
| Pengiriman ulang | Permintaan yang diulang tidak membentuk objek ganda pada skenario uji |
| Penanganan gangguan | Status gagal terlihat dan dapat ditindaklanjuti petugas berwenang |
| Serah terima | Dokumentasi, akses pengelolaan, dan panduan operasi tersedia sesuai kontrak |
Catat data uji dan hasil aktualnya. Jika sebuah skenario belum bisa diuji karena menunggu vendor core banking, laporkan sebagai belum terverifikasi. Jangan mengubahnya menjadi lulus hanya karena tampilan aplikasi telah selesai.
Terapkan Perubahan Secara Bertahap
Pilih satu proses dengan batas yang jelas untuk tahap awal. Setelah fungsi, akses, integrasi, dan bukti pengendaliannya diperiksa, bank dapat mempertimbangkan perluasan. Pendekatan ini membantu menemukan masalah sebelum seluruh unit bergantung pada aplikasi baru.
Untuk perpindahan dari aplikasi lama, sepakati pemetaan data, pemeriksaan hasil migrasi, waktu peralihan, serta rencana kembali jika diperlukan. Jelaskan pula siapa yang mendukung pengguna setelah aplikasi mulai dipakai. Kebutuhan backup dan disaster recovery BPR juga perlu dipetakan sebelum peralihan. Pelatihan dan panduan kerja perlu mengikuti alur final, bukan versi demo.
Pekerjaan tersebut harus masuk lingkup penawaran. Gunakan panduan memilih vendor TI BPR untuk memeriksa tanggung jawab, dukungan, dan ketergantungan pihak ketiga sebelum pembangunan dimulai.
Brief Pengembangan Aplikasi BPR Bersama Layana.id
Melalui layanan custom development, Layana.id dapat diajak membahas kebutuhan aplikasi dan integrasi sesuai proses bank. Bahan awal yang paling berguna adalah alur kerja, daftar sistem terkait, kendala aktual, serta kontrol yang ingin diterapkan.
Mulailah dengan satu masalah konkret, seperti persetujuan yang sulit ditelusuri atau status integrasi yang tidak jelas. Pembahasan perlu menghasilkan ruang lingkup, ketergantungan, keluaran, dan skenario penerimaan. Kebutuhan spesialis keamanan, infrastruktur, atau evaluasi kepatuhan juga harus terlihat dalam pembagian pekerjaan.
Diskusikan pengembangan aplikasi BPR bersama Layana.id untuk memetakan solusi yang relevan. Keputusan membangun sistem sebaiknya ditopang kebutuhan yang jelas dan hasil yang dapat diuji, sehingga bank memperoleh alat kerja yang dapat digunakan sekaligus diawasi.
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.
Dalam catatan portofolio Layana, proyek BPR CMA dilaporkan membantu perubahan proses kredit dari tiga hari menjadi satu hari cair. Hasil tersebut merupakan catatan pada proyek tertentu; waktu pencairan bank lain tetap bergantung pada kelengkapan data, analisis, persetujuan, dan kebijakan kreditnya.
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, khususnya Pasal 1, 15, 31, 35–36, dan 40.
- FAQ Dan Naskah Resmi OJK.