Yang ditawarkan kebanyakan software perbankan
Fitur, proyek implementasi, dan kontrak pemeliharaan.
Setiap perubahan setelah sistem berjalan menjadi permintaan baru, penawaran harga baru, dan antrean baru.
Platform perbankan
Bank in a BoxLima belas produk perbankan, satu bidang kendali.
Core banking, switching kartu dan ATM, serta tiga belas modul mandiri, dengan bidang kendali yang membangun dan terus mengubahnya — software white-label yang dipasang di pusat data milik bank.
Masalahnya
Biaya sesungguhnya datang setelah tanda tangan.
Bank tidak membeli software yang membeku. Bank membeli kemampuan untuk mengubahnya — produk baru, regulasi baru, kanal baru.
Hari ini setiap perubahan adalah negosiasi. Akhirnya bank berhenti meminta, dan sistemnya membeku.
Apa yang terjadi pada satu permintaan perubahan
- 01 Permintaan perubahan
- 02 SOW
- 03 Negosiasi
- 04 Berbulan-bulan menunggu
- 05 Bank berhenti meminta
Yang ditawarkan Bank in a Box
Kecepatan perubahan
Kemampuan mengubah sistem perbankan dengan aman, kapan pun bank membutuhkannya. Di situlah Bank in a Box dibangun.
Lisensi dibayar sekali. Perubahan dibayar seumur hidup sistem.
Forge, bidang kendali
Bidang kendali yang membuat perubahan aman.
Forge bukan pabrik kode. Setiap permintaan perubahan berjalan dalam pipeline: disiapkan di salinan, dikompilasi dan diuji otomatis, dan baru masuk ke sumber jika lolos.
-
Langkah 1
Lead
Membaca permintaan perubahan dan merencanakan pekerjaannya, tetap dalam lingkup yang diminta.
-
Langkah 2
Arsitek
Menentukan letak perubahan di sistem yang ada dan bagian mana yang boleh disentuh.
-
Langkah 3 · bila perlu
Database
Menyiapkan perubahan database, hanya bila permintaan membutuhkannya.
-
Langkah 4
Backend
Menulis kode perubahan, mengikuti pola sistem yang sudah ada.
-
Langkah 5
Verifikasi
Mengompilasi sungguhan dan menjalankan pengujian otomatis. Jika build gagal, pesan galat compiler dikirim ke Perbaikan dan hasilnya kembali ke sini.
Loop dengan Verifikasi
Perbaikan
Menerima pesan galat compiler yang sebenarnya, memperbaiki kode, dan mengirimnya kembali ke Verifikasi sampai build berhasil dan pengujian lolos.
-
Langkah 6
Peninjau
Meninjau perubahan sebelum diterima, termasuk apakah dokumentasinya ikut diperbarui.
-
Hasil
Kode siap
Perubahan dipromosikan ke sumber dan paket rilis disiapkan.
Empat sifat pengaman
-
Kegagalan tidak meninggalkan jejak
Pekerjaan dilakukan di salinan. Jika perubahan gagal, sumbernya tetap persis seperti semula.
-
Masalah lama dicatat lebih dulu
Baseline diambil sebelum perubahan, sehingga hanya masalah yang dibawa perubahan itu yang bisa menahannya.
-
Belajar juga dari kegagalan
Apa yang salah di satu perubahan disimpan dan dipakai di perubahan berikutnya.
-
Dokumentasi tetap hidup
Perubahan logika inti ditolak jika dokumentasinya tidak ikut diperbarui.
Satu perubahan, dari awal sampai akhir
Satu perubahan kecil yang nyata, dari pengecekan awal hingga paket rilis siap dalam sekitar satu menit.
Delapan teknologi yang didukung
- Spring Boot
- Go
- Node / Express
- FastAPI
- Web
- React Native
- Flutter
- Android
Forge berjalan sepenuhnya di dalam bank, termasuk model bahasanya — tidak ada yang keluar dari pusat data.
- 01 Kondisi awal dicatat Selesai
- 02 Disiapkan di salinan Selesai
- 03 Kompilasi Berhasil
- 04 Pengujian otomatis Lolos
- 05 Diterapkan ke sistem Selesai
- 06 Paket rilis Siap
Tiga file berubah, tidak ada yang di luar lingkup permintaan. Bandingkan dengan berbulan-bulan.
Portofolionya
Tiga lapisan, lima belas produk.
Lapisan inti, modul-modul mandiri di sekitarnya, dan bidang kendali yang membangun serta mengubah semuanya. Setiap produk bisa dibeli dan dijalankan sendiri.
Bidang kendali
Forge
Membangun dan mengubah setiap produk
Produk perbankan, terpasang di pusat data bank
Lapisan modul — masing-masing mandiri
- Originate
- Lend
- Collect
- Shield
- Guard
- Report
- Treasury
- Insight
- Engage
- Identity
- Gateway
- Enterprise
Lapisan inti
- Core Core banking, konvensional dan syariah
- Switch Kartu, ATM, dan jaringan pembayaran
Tiga aturan untuk setiap produk
-
Satu produk, satu sistem
Setiap produk punya database, rilis, dan pipeline sendiri, sehingga satu bisa berubah tanpa menyentuh yang lain.
-
Terhubung hanya lewat API
Saat Shield membekukan rekening, ia memanggil core lewat API — dan jika panggilan itu gagal, rekening tetap beku.
-
Tinggal di pusat data bank
Dibangun untuk berjalan on-premise, bahkan tanpa koneksi internet.
Lima belas produknya
Setiap produk, dan apa yang dikerjakannya.
Buka produk mana pun untuk melihat masalah yang diselesaikan, apa yang sudah bisa dikerjakan, dan untuk siapa.
Core
Core banking
Core banking konvensional dan syariah di atas satu buku besar double-entry: teller, tabungan dan deposito, serta pembiayaan.
Masalah yang diselesaikan
- Pembukuan konvensional dan syariah tersimpan di sistem yang terpisah.
- Kolektibilitas dan CKPN dihitung di luar core.
- Proses akhir hari yang sulit ditelusuri atau diulang.
Yang dikerjakan
- Konvensional dan syariah memakai satu buku besar dan satu proses akhir hari.
- Kolektibilitas lima tingkat OJK dan CKPN IFRS 9 dihitung oleh mesin.
- Tabungan, giro, dan deposito dengan ARO, serta virtual account.
- Pembiayaan anuitas, menurun, flat, dan bullet; Murabahah, Ijarah, Mudharabah, Musyarakah Mutanaqisah, dan Wadiah sesuai fatwa DSN-MUI.
- Multi-mata uang dengan kurs Bank Indonesia, konsol web operator, dan Open API.
Untuk siapa
Bank yang mengganti core: bank umum, BPR dan BPRS, serta bank digital baru.
Dibangun dengan
- Microservice Go
- REST · gRPC · event
- Konvensional + syariah
- Siap Kubernetes, on-premise
Switch
Switching kartu & ATM
Switching untuk kartu dan ATM: ISO 8583, jalur data chip EMV, ATM NDC, dan manajemen kunci HSM.
Masalah yang diselesaikan
- Nomor kartu bocor ke log dan aliran event.
- Data chip berubah saat melewati switch.
- Pemrosesan kartu dan ATM terikat platform vendor yang tertutup.
Yang dikerjakan
- Nomor kartu ditokenisasi dan disamarkan; hanya event yang sudah dibersihkan yang keluar dari switch.
- Data chip EMV diteruskan apa adanya, byte demi byte.
- Codec ISO 8583 berbasis tabel yang cepat, dengan dukungan BER-TLV.
- Pipeline yang men-decode, mencegah duplikasi, menokenisasi, dan mencari rentang kartu untuk setiap pesan.
- Otentikasi chip melalui HSM (ARQC masuk, ARPC keluar), layanan PIN dan token, serta tarik tunai ATM.
Untuk siapa
Penerbit dan acquirer dengan jaringan kartu dan ATM, serta penyedia switching.
Dibangun dengan
- Inti Rust + layanan Go
- ISO 8583 · EMV · NDC
- GPN · Visa · Mastercard
- Pemetaan PCI DSS 4.0.1
Originate
Originasi kredit
Originasi kredit menyeluruh, dari pengajuan dan dokumen hingga keputusan dan akad.
Masalah yang diselesaikan
- Kebijakan kredit diterapkan berbeda-beda antar petugas.
- Keputusan tanpa alasan tercatat, padahal aturan perlindungan konsumen mewajibkannya.
- Dokumen diketik ulang secara manual.
Yang dikerjakan
- Kebijakan kredit sebagai kode (DBR, LTV, tenor), hanya bisa diubah dengan persetujuan ganda.
- Setiap keputusan membawa kode dan alasannya, untuk transparansi POJK 22.
- Persetujuan otomatis (STP), atau diteruskan ke review manual dan komite.
- KTA, KPR, KKB, kartu kredit, dan KMK, ditambah Murabahah, Musyarakah, Ijarah, dan Qardh.
- Pipeline dokumen dengan OCR on-premise, agunan, e-Akad, analisis rekening koran, dan masa jeda POJK 22.
Untuk siapa
Bank dan perusahaan multifinance.
Dibangun dengan
- 9 produk kredit
- Alur 15 tahap
- OCR on-premise, 19 jenis dokumen
- POJK 22
Lend
Pengelolaan pinjaman
Pengelolaan pinjaman setelah pencairan: jadwal, pembayaran, kolektibilitas, dan restrukturisasi.
Masalah yang diselesaikan
- Restrukturisasi dipakai untuk menutupi kredit bermasalah (evergreening).
- Kolektibilitas terlambat diperbarui.
- Denda syariah tercampur ke pendapatan.
Yang dikerjakan
- Kolektibilitas dihitung ulang setiap hari.
- Pagar pengaman restrukturisasi yang mencegah evergreening.
- Ta’zir syariah dipisahkan.
- Sepuluh metode amortisasi dan batch harian yang aman diulang.
- API real-time untuk pembayaran, pelunasan dipercepat, dan restrukturisasi; pinjaman terdaftar langsung dari originasi.
Untuk siapa
Bank dengan portofolio pinjaman yang terus tumbuh.
Dibangun dengan
- 10 metode amortisasi
- Batch harian, aman diulang
- API real-time
Collect
Penagihan
Penagihan yang memeriksa setiap kontak terhadap aturan sebelum dilakukan.
Masalah yang diselesaikan
- Penagih menghubungi debitur di luar jam yang diizinkan, terlalu sering, atau dengan intimidasi.
- Pembayaran yang disepakati di penagihan tidak sampai ke sistem pinjaman.
- Kasus dibuka manual dari spreadsheet.
Yang dikerjakan
- Pemeriksaan kepatuhan sebelum setiap kontak: jam telepon POJK 22, frekuensi, dan tanpa intimidasi.
- Template pesan yang sudah disetujui per kanal dan tahap.
- Tautan pembayaran dan penyelesaian tercatat kembali ke Lend.
- Eskalasi ke jalur hukum.
- Kasus terbuka otomatis saat Lend menyerahkan rekening.
Untuk siapa
Bank dan multifinance yang ingin menekan NPL tanpa menambah penagih.
Dibangun dengan
- Cek kepatuhan per kontak
- Template disetujui per kanal
- Terhubung ke Lend
Shield
APU-PPT & KYC
Anti pencucian uang dan kenali nasabah: screening, uji tuntas, pemantauan, dan pelaporan.
Masalah yang diselesaikan
- Screening nama yang melewatkan variasi ejaan.
- Pemblokiran diputuskan di kepatuhan tetapi tidak dijalankan di core.
- Laporan transaksi mencurigakan disusun manual.
Yang dikerjakan
- Screening fuzzy terhadap DTTOT, OFAC, daftar PBB, PEP, dan berita negatif.
- Pemblokiran sampai ke core melalui API dan gagal-tertutup (fail-closed).
- Uji tuntas nasabah perorangan dan korporasi, dengan peringkat risiko rendah, sedang, tinggi, dan tersanksi.
- Pemantauan transaksi untuk tipologi PPATK.
- Laporan CTR, STR, dan IFTI untuk GRIPS, ditandatangani dengan HSM.
Untuk siapa
Setiap bank — APU-PPT adalah belanja wajib.
Dibangun dengan
- Daftar DTTOT · OFAC · PBB
- Tipologi PPATK
- Laporan GRIPS, ditandatangani HSM
Guard
Skoring fraud
Skoring fraud transaksi berbasis aturan yang bisa dijelaskan, lengkap dengan manajemen kasus.
Masalah yang diselesaikan
- Penolakan yang tidak bisa dijelaskan ke nasabah atau regulator.
- Perubahan aturan berlaku tanpa ditinjau.
- Semua transaksi mencurigakan diperlakukan sama.
Yang dikerjakan
- Mencakup 13 jenis fraud.
- Skor 0 sampai 1000: setujui di bawah 300, otentikasi tambahan 300–699, tolak mulai 700.
- Allowlist didahulukan atas blocklist.
- Perubahan aturan butuh persetujuan empat mata dan berjalan dalam mode bayangan lebih dulu.
- Fail-safe berbasis nilai transaksi dan manajemen kasus untuk investigator.
Untuk siapa
Bank dengan volume digital yang naik dan butuh penolakan yang bisa dijelaskan.
Dibangun dengan
- 13 jenis fraud
- Skor 0–1000
- 15 aturan awal
- Feature store 11 fitur
Report
Pelaporan regulator
Pelaporan ke OJK, BI, PPATK, LPS, DJP, dan DSN-MUI, dari data hingga laporan bertanda tangan.
Masalah yang diselesaikan
- Laporan regulator disusun di spreadsheet.
- Tidak ada catatan asal setiap angka.
- Versi yang sudah dikirim tidak bisa dibuat ulang.
Yang dikerjakan
- Kumpulkan, susun, validasi, persetujuan ganda, tanda tangan HSM, kirim, arsipkan — dan berhenti bila satu langkah gagal.
- Catatan asal-usul untuk setiap angka, dan versi yang bisa dibuat ulang persis sama.
- Arsip sekali-tulis dengan rantai hash, disimpan sepuluh tahun.
- Katalog 24 laporan untuk enam regulator, didefinisikan sebagai kode dengan query baca-saja.
- Keluaran XBRL, CSV, dan XML, dengan tanda tangan per regulator dan persetujuan ganda berbasis peran.
Untuk siapa
Bank yang masih menyusun laporan regulator di spreadsheet.
Dibangun dengan
- 24 laporan, 6 regulator
- XBRL · CSV · XML
- Tanda tangan HSM
- Arsip 10 tahun
Treasury
Treasury & ALM
Treasury dan manajemen aset-liabilitas: likuiditas, CKPN, valas, pasar uang, SBN, dan batas risiko.
Masalah yang diselesaikan
- Rasio likuiditas dan permodalan baru diketahui di akhir hari.
- Model CKPN dijalankan di spreadsheet.
- Batas diperiksa setelah transaksi, bukan sebelumnya.
Yang dikerjakan
- LCR, CAR, dan PDN dipantau sepanjang hari.
- CKPN/ECL IFRS 9 (PSAK 71) dengan PD, LGD, CCF, dan skenario berbobot, dijalankan harian.
- Selisih CKPN langsung dibukukan ke buku besar core.
- Meja valas, PUAB, dan SBN, dengan IRRBB dan uji tekanan.
- Selera risiko, BMPK, dan batas PDN sebagai kode dengan peringatan; keputusan tetap di tangan manusia dengan kontrol empat mata.
Untuk siapa
Tim treasury yang masih bekerja di spreadsheet.
Dibangun dengan
- LCR · CAR · PDN intraday
- IFRS 9 / PSAK 71
- Valas · PUAB · SBN
- IRRBB
Enterprise
ERP & HRIS bank
ERP dan SDM untuk bank itu sendiri: buku besar korporat, pengadaan, payroll, dan konsolidasi.
Masalah yang diselesaikan
- Sistem ERP dan SDM yang tidak terhubung ke core.
- Vendor dibayar tanpa di-screening.
- Payroll disetujui di luar sistem.
Yang dikerjakan
- Buku besar korporat double-entry dengan bagan akun yang terhubung ke core dan autoposting.
- Procure-to-pay dengan KYB vendor, screening sanksi, dan pencocokan tiga arah.
- Payroll dengan persetujuan CFO dan CHRO, PPh 21, dan BPJS.
- Konsolidasi antar entitas.
- Pencatatan biaya untuk agen AI.
Untuk siapa
Bank dan grup keuangan yang menjalankan ERP dan HRIS terpisah dari core.
Dibangun dengan
- GL korporat
- Procure-to-pay
- Payroll: PPh 21 · BPJS
- Multi-entitas
Insight
Data warehouse & BI
Data warehouse dan business intelligence yang menjawab pertanyaan berbahasa Indonesia.
Masalah yang diselesaikan
- Laporan manajemen disusun manual.
- Angka terbit sebelum datanya diperiksa.
- Data warehouse cloud tidak bisa dipakai karena aturan lokasi data.
Yang dikerjakan
- Data dimurnikan dalam tiga tahap, dari mentah, terkurasi, hingga siap terbit.
- Gerbang kualitas dengan sepuluh jenis aturan yang menahan publikasi bila data gagal.
- Lapisan pengaman di setiap query: baca-saja, tabel yang disetujui, batas waktu, dan batas baris.
- Pertanyaan dalam bahasa Indonesia, ditambah feature store.
- Ringkasan harian per peran — CEO, COO, CRO, CFO, CCO, dan direksi — yang konsisten setiap kali.
Untuk siapa
Bank yang menyusun laporan manajemen secara manual dan tidak bisa memakai data warehouse cloud.
Dibangun dengan
- Bronze → silver → gold
- 10 jenis aturan kualitas data
- Pertanyaan berbahasa Indonesia
- On-premise
Engage
Mesin keputusan mobile
Lapisan keputusan di balik kanal mobile bank — bukan aplikasi mobile banking.
Masalah yang diselesaikan
- Keputusan tertanam di aplikasi, sehingga setiap perubahan butuh rilis baru.
- Tantangan login yang sama untuk semua situasi, apa pun risikonya.
- Catatan persetujuan tersebar di banyak sistem.
Yang dikerjakan
- Otentikasi berbasis risiko.
- Konten yang dipersonalisasi per segmen nasabah.
- Eksperimen terkendali: uji A/B dan bandit dengan persetujuan empat mata dan pengaman berhenti otomatis.
- Catatan persetujuan sesuai UU PDP.
- Preferensi notifikasi, dengan peringatan keamanan yang selalu terkirim.
Untuk siapa
Bank dengan aplikasi yang keputusannya masih tertanam di kode.
Dibangun dengan
- Otentikasi berbasis risiko
- Uji A/B dan bandit
- Persetujuan UU PDP
Identity
Identitas, akses & kriptografi
Identitas, akses, dan kriptografi yang dipakai bersama oleh produk Bank in a Box lainnya.
Masalah yang diselesaikan
- Setiap sistem punya login dan aturan hak aksesnya sendiri.
- Kunci disimpan di software, bukan di HSM.
Yang dikerjakan
- Penerbitan dan pencabutan token (JWT dan JWKS).
- Kebijakan akses yang menolak secara bawaan dan gagal-tertutup.
- HSM software sebagai acuan, diganti PKCS#11 ke HSM sungguhan di produksi.
- Domain akses terpisah untuk setiap produk.
- Dipakai oleh Shield, Report, Gateway, dan Originate.
Untuk siapa
Biasanya hadir bersama produk Bank in a Box lain, jarang dibeli sendiri.
Dibangun dengan
- JWT + JWKS
- Kebijakan default-deny
- PKCS#11 ke HSM fisik
Gateway
API gateway & kontrak
API gateway dan registri kontrak untuk SNAP BI dan Open API bank.
Masalah yang diselesaikan
- Perubahan API yang diam-diam merusak integrasi mitra.
- Memenuhi mandat SNAP BI satu per satu di setiap sistem.
- Data pribadi terbuka di respons API.
Yang dikerjakan
- Registri kontrak dengan pemeriksaan kompatibilitas; perubahan yang merusak butuh tinjauan empat mata.
- Gateway dengan rantai plugin dan rilis canary.
- Gateway SNAP BI: tanda tangan HMAC-SHA512, perlindungan replay, idempotensi, token B2B, dan penandatanganan HSM.
- Zero trust antar layanan.
- Data pribadi disamarkan sesuai tujuan penggunaan, mengikuti UU PDP.
Untuk siapa
Bank yang memenuhi mandat SNAP BI atau membuka Open API.
Dibangun dengan
- SNAP BI
- JSON Schema · Avro · Protobuf · OpenAPI
- Zero trust
- Masking UU PDP
Forge
Control plane
Bidang kendali yang membangun dan mengubah produk lainnya — dan bisa melakukan hal yang sama untuk sistem milik bank.
Masalah yang diselesaikan
- Setiap permintaan perubahan menjadi SOW, negosiasi, dan berbulan-bulan menunggu.
- Perubahan yang merusak bagian lain.
- Dokumentasi yang makin jauh dari kodenya.
Yang dikerjakan
- Permintaan perubahan berjalan dalam pipeline, disiapkan di salinan, dikompilasi dan diuji otomatis.
- Perubahan masuk ke sumber hanya setelah lolos; kegagalan tidak meninggalkan jejak.
- Loop kompilasi dan perbaikan untuk delapan stack teknologi.
- Basis pengetahuan dari kode dan dokumen milik bank.
- Berjalan sepenuhnya di dalam bank, termasuk model bahasanya.
Untuk siapa
Bank atau vendor yang ingin punya kapasitas perubahan sendiri di lingkungan tertutup.
Dibangun dengan
- Python · LangGraph · FastAPI
- Control center berbasis web
- Model bahasa lokal
- 8 stack target
Lapisan inti
Core Core banking
Core banking konvensional dan syariah di atas satu buku besar double-entry: teller, tabungan dan deposito, serta pembiayaan.
Masalah yang diselesaikan
- Pembukuan konvensional dan syariah tersimpan di sistem yang terpisah.
- Kolektibilitas dan CKPN dihitung di luar core.
- Proses akhir hari yang sulit ditelusuri atau diulang.
Yang dikerjakan
- Konvensional dan syariah memakai satu buku besar dan satu proses akhir hari.
- Kolektibilitas lima tingkat OJK dan CKPN IFRS 9 dihitung oleh mesin.
- Tabungan, giro, dan deposito dengan ARO, serta virtual account.
- Pembiayaan anuitas, menurun, flat, dan bullet; Murabahah, Ijarah, Mudharabah, Musyarakah Mutanaqisah, dan Wadiah sesuai fatwa DSN-MUI.
- Multi-mata uang dengan kurs Bank Indonesia, konsol web operator, dan Open API.
Untuk siapa
Bank yang mengganti core: bank umum, BPR dan BPRS, serta bank digital baru.
Dibangun dengan
- Microservice Go
- REST · gRPC · event
- Konvensional + syariah
- Siap Kubernetes, on-premise
Switch Switching kartu & ATM
Switching untuk kartu dan ATM: ISO 8583, jalur data chip EMV, ATM NDC, dan manajemen kunci HSM.
Masalah yang diselesaikan
- Nomor kartu bocor ke log dan aliran event.
- Data chip berubah saat melewati switch.
- Pemrosesan kartu dan ATM terikat platform vendor yang tertutup.
Yang dikerjakan
- Nomor kartu ditokenisasi dan disamarkan; hanya event yang sudah dibersihkan yang keluar dari switch.
- Data chip EMV diteruskan apa adanya, byte demi byte.
- Codec ISO 8583 berbasis tabel yang cepat, dengan dukungan BER-TLV.
- Pipeline yang men-decode, mencegah duplikasi, menokenisasi, dan mencari rentang kartu untuk setiap pesan.
- Otentikasi chip melalui HSM (ARQC masuk, ARPC keluar), layanan PIN dan token, serta tarik tunai ATM.
Untuk siapa
Penerbit dan acquirer dengan jaringan kartu dan ATM, serta penyedia switching.
Dibangun dengan
- Inti Rust + layanan Go
- ISO 8583 · EMV · NDC
- GPN · Visa · Mastercard
- Pemetaan PCI DSS 4.0.1
Kredit
Originate Originasi kredit
Originasi kredit menyeluruh, dari pengajuan dan dokumen hingga keputusan dan akad.
Masalah yang diselesaikan
- Kebijakan kredit diterapkan berbeda-beda antar petugas.
- Keputusan tanpa alasan tercatat, padahal aturan perlindungan konsumen mewajibkannya.
- Dokumen diketik ulang secara manual.
Yang dikerjakan
- Kebijakan kredit sebagai kode (DBR, LTV, tenor), hanya bisa diubah dengan persetujuan ganda.
- Setiap keputusan membawa kode dan alasannya, untuk transparansi POJK 22.
- Persetujuan otomatis (STP), atau diteruskan ke review manual dan komite.
- KTA, KPR, KKB, kartu kredit, dan KMK, ditambah Murabahah, Musyarakah, Ijarah, dan Qardh.
- Pipeline dokumen dengan OCR on-premise, agunan, e-Akad, analisis rekening koran, dan masa jeda POJK 22.
Untuk siapa
Bank dan perusahaan multifinance.
Dibangun dengan
- 9 produk kredit
- Alur 15 tahap
- OCR on-premise, 19 jenis dokumen
- POJK 22
Lend Pengelolaan pinjaman
Pengelolaan pinjaman setelah pencairan: jadwal, pembayaran, kolektibilitas, dan restrukturisasi.
Masalah yang diselesaikan
- Restrukturisasi dipakai untuk menutupi kredit bermasalah (evergreening).
- Kolektibilitas terlambat diperbarui.
- Denda syariah tercampur ke pendapatan.
Yang dikerjakan
- Kolektibilitas dihitung ulang setiap hari.
- Pagar pengaman restrukturisasi yang mencegah evergreening.
- Ta’zir syariah dipisahkan.
- Sepuluh metode amortisasi dan batch harian yang aman diulang.
- API real-time untuk pembayaran, pelunasan dipercepat, dan restrukturisasi; pinjaman terdaftar langsung dari originasi.
Untuk siapa
Bank dengan portofolio pinjaman yang terus tumbuh.
Dibangun dengan
- 10 metode amortisasi
- Batch harian, aman diulang
- API real-time
Collect Penagihan
Penagihan yang memeriksa setiap kontak terhadap aturan sebelum dilakukan.
Masalah yang diselesaikan
- Penagih menghubungi debitur di luar jam yang diizinkan, terlalu sering, atau dengan intimidasi.
- Pembayaran yang disepakati di penagihan tidak sampai ke sistem pinjaman.
- Kasus dibuka manual dari spreadsheet.
Yang dikerjakan
- Pemeriksaan kepatuhan sebelum setiap kontak: jam telepon POJK 22, frekuensi, dan tanpa intimidasi.
- Template pesan yang sudah disetujui per kanal dan tahap.
- Tautan pembayaran dan penyelesaian tercatat kembali ke Lend.
- Eskalasi ke jalur hukum.
- Kasus terbuka otomatis saat Lend menyerahkan rekening.
Untuk siapa
Bank dan multifinance yang ingin menekan NPL tanpa menambah penagih.
Dibangun dengan
- Cek kepatuhan per kontak
- Template disetujui per kanal
- Terhubung ke Lend
Risiko & kepatuhan
Shield APU-PPT & KYC
Anti pencucian uang dan kenali nasabah: screening, uji tuntas, pemantauan, dan pelaporan.
Masalah yang diselesaikan
- Screening nama yang melewatkan variasi ejaan.
- Pemblokiran diputuskan di kepatuhan tetapi tidak dijalankan di core.
- Laporan transaksi mencurigakan disusun manual.
Yang dikerjakan
- Screening fuzzy terhadap DTTOT, OFAC, daftar PBB, PEP, dan berita negatif.
- Pemblokiran sampai ke core melalui API dan gagal-tertutup (fail-closed).
- Uji tuntas nasabah perorangan dan korporasi, dengan peringkat risiko rendah, sedang, tinggi, dan tersanksi.
- Pemantauan transaksi untuk tipologi PPATK.
- Laporan CTR, STR, dan IFTI untuk GRIPS, ditandatangani dengan HSM.
Untuk siapa
Setiap bank — APU-PPT adalah belanja wajib.
Dibangun dengan
- Daftar DTTOT · OFAC · PBB
- Tipologi PPATK
- Laporan GRIPS, ditandatangani HSM
Guard Skoring fraud
Skoring fraud transaksi berbasis aturan yang bisa dijelaskan, lengkap dengan manajemen kasus.
Masalah yang diselesaikan
- Penolakan yang tidak bisa dijelaskan ke nasabah atau regulator.
- Perubahan aturan berlaku tanpa ditinjau.
- Semua transaksi mencurigakan diperlakukan sama.
Yang dikerjakan
- Mencakup 13 jenis fraud.
- Skor 0 sampai 1000: setujui di bawah 300, otentikasi tambahan 300–699, tolak mulai 700.
- Allowlist didahulukan atas blocklist.
- Perubahan aturan butuh persetujuan empat mata dan berjalan dalam mode bayangan lebih dulu.
- Fail-safe berbasis nilai transaksi dan manajemen kasus untuk investigator.
Untuk siapa
Bank dengan volume digital yang naik dan butuh penolakan yang bisa dijelaskan.
Dibangun dengan
- 13 jenis fraud
- Skor 0–1000
- 15 aturan awal
- Feature store 11 fitur
Report Pelaporan regulator
Pelaporan ke OJK, BI, PPATK, LPS, DJP, dan DSN-MUI, dari data hingga laporan bertanda tangan.
Masalah yang diselesaikan
- Laporan regulator disusun di spreadsheet.
- Tidak ada catatan asal setiap angka.
- Versi yang sudah dikirim tidak bisa dibuat ulang.
Yang dikerjakan
- Kumpulkan, susun, validasi, persetujuan ganda, tanda tangan HSM, kirim, arsipkan — dan berhenti bila satu langkah gagal.
- Catatan asal-usul untuk setiap angka, dan versi yang bisa dibuat ulang persis sama.
- Arsip sekali-tulis dengan rantai hash, disimpan sepuluh tahun.
- Katalog 24 laporan untuk enam regulator, didefinisikan sebagai kode dengan query baca-saja.
- Keluaran XBRL, CSV, dan XML, dengan tanda tangan per regulator dan persetujuan ganda berbasis peran.
Untuk siapa
Bank yang masih menyusun laporan regulator di spreadsheet.
Dibangun dengan
- 24 laporan, 6 regulator
- XBRL · CSV · XML
- Tanda tangan HSM
- Arsip 10 tahun
Keuangan
Treasury Treasury & ALM
Treasury dan manajemen aset-liabilitas: likuiditas, CKPN, valas, pasar uang, SBN, dan batas risiko.
Masalah yang diselesaikan
- Rasio likuiditas dan permodalan baru diketahui di akhir hari.
- Model CKPN dijalankan di spreadsheet.
- Batas diperiksa setelah transaksi, bukan sebelumnya.
Yang dikerjakan
- LCR, CAR, dan PDN dipantau sepanjang hari.
- CKPN/ECL IFRS 9 (PSAK 71) dengan PD, LGD, CCF, dan skenario berbobot, dijalankan harian.
- Selisih CKPN langsung dibukukan ke buku besar core.
- Meja valas, PUAB, dan SBN, dengan IRRBB dan uji tekanan.
- Selera risiko, BMPK, dan batas PDN sebagai kode dengan peringatan; keputusan tetap di tangan manusia dengan kontrol empat mata.
Untuk siapa
Tim treasury yang masih bekerja di spreadsheet.
Dibangun dengan
- LCR · CAR · PDN intraday
- IFRS 9 / PSAK 71
- Valas · PUAB · SBN
- IRRBB
Enterprise ERP & HRIS bank
ERP dan SDM untuk bank itu sendiri: buku besar korporat, pengadaan, payroll, dan konsolidasi.
Masalah yang diselesaikan
- Sistem ERP dan SDM yang tidak terhubung ke core.
- Vendor dibayar tanpa di-screening.
- Payroll disetujui di luar sistem.
Yang dikerjakan
- Buku besar korporat double-entry dengan bagan akun yang terhubung ke core dan autoposting.
- Procure-to-pay dengan KYB vendor, screening sanksi, dan pencocokan tiga arah.
- Payroll dengan persetujuan CFO dan CHRO, PPh 21, dan BPJS.
- Konsolidasi antar entitas.
- Pencatatan biaya untuk agen AI.
Untuk siapa
Bank dan grup keuangan yang menjalankan ERP dan HRIS terpisah dari core.
Dibangun dengan
- GL korporat
- Procure-to-pay
- Payroll: PPh 21 · BPJS
- Multi-entitas
Data & kanal
Insight Data warehouse & BI
Data warehouse dan business intelligence yang menjawab pertanyaan berbahasa Indonesia.
Masalah yang diselesaikan
- Laporan manajemen disusun manual.
- Angka terbit sebelum datanya diperiksa.
- Data warehouse cloud tidak bisa dipakai karena aturan lokasi data.
Yang dikerjakan
- Data dimurnikan dalam tiga tahap, dari mentah, terkurasi, hingga siap terbit.
- Gerbang kualitas dengan sepuluh jenis aturan yang menahan publikasi bila data gagal.
- Lapisan pengaman di setiap query: baca-saja, tabel yang disetujui, batas waktu, dan batas baris.
- Pertanyaan dalam bahasa Indonesia, ditambah feature store.
- Ringkasan harian per peran — CEO, COO, CRO, CFO, CCO, dan direksi — yang konsisten setiap kali.
Untuk siapa
Bank yang menyusun laporan manajemen secara manual dan tidak bisa memakai data warehouse cloud.
Dibangun dengan
- Bronze → silver → gold
- 10 jenis aturan kualitas data
- Pertanyaan berbahasa Indonesia
- On-premise
Engage Mesin keputusan mobile
Lapisan keputusan di balik kanal mobile bank — bukan aplikasi mobile banking.
Masalah yang diselesaikan
- Keputusan tertanam di aplikasi, sehingga setiap perubahan butuh rilis baru.
- Tantangan login yang sama untuk semua situasi, apa pun risikonya.
- Catatan persetujuan tersebar di banyak sistem.
Yang dikerjakan
- Otentikasi berbasis risiko.
- Konten yang dipersonalisasi per segmen nasabah.
- Eksperimen terkendali: uji A/B dan bandit dengan persetujuan empat mata dan pengaman berhenti otomatis.
- Catatan persetujuan sesuai UU PDP.
- Preferensi notifikasi, dengan peringatan keamanan yang selalu terkirim.
Untuk siapa
Bank dengan aplikasi yang keputusannya masih tertanam di kode.
Dibangun dengan
- Otentikasi berbasis risiko
- Uji A/B dan bandit
- Persetujuan UU PDP
Fondasi
Identity Identitas, akses & kriptografi
Identitas, akses, dan kriptografi yang dipakai bersama oleh produk Bank in a Box lainnya.
Masalah yang diselesaikan
- Setiap sistem punya login dan aturan hak aksesnya sendiri.
- Kunci disimpan di software, bukan di HSM.
Yang dikerjakan
- Penerbitan dan pencabutan token (JWT dan JWKS).
- Kebijakan akses yang menolak secara bawaan dan gagal-tertutup.
- HSM software sebagai acuan, diganti PKCS#11 ke HSM sungguhan di produksi.
- Domain akses terpisah untuk setiap produk.
- Dipakai oleh Shield, Report, Gateway, dan Originate.
Untuk siapa
Biasanya hadir bersama produk Bank in a Box lain, jarang dibeli sendiri.
Dibangun dengan
- JWT + JWKS
- Kebijakan default-deny
- PKCS#11 ke HSM fisik
Gateway API gateway & kontrak
API gateway dan registri kontrak untuk SNAP BI dan Open API bank.
Masalah yang diselesaikan
- Perubahan API yang diam-diam merusak integrasi mitra.
- Memenuhi mandat SNAP BI satu per satu di setiap sistem.
- Data pribadi terbuka di respons API.
Yang dikerjakan
- Registri kontrak dengan pemeriksaan kompatibilitas; perubahan yang merusak butuh tinjauan empat mata.
- Gateway dengan rantai plugin dan rilis canary.
- Gateway SNAP BI: tanda tangan HMAC-SHA512, perlindungan replay, idempotensi, token B2B, dan penandatanganan HSM.
- Zero trust antar layanan.
- Data pribadi disamarkan sesuai tujuan penggunaan, mengikuti UU PDP.
Untuk siapa
Bank yang memenuhi mandat SNAP BI atau membuka Open API.
Dibangun dengan
- SNAP BI
- JSON Schema · Avro · Protobuf · OpenAPI
- Zero trust
- Masking UU PDP
Bidang kendali
Forge Control plane
Bidang kendali yang membangun dan mengubah produk lainnya — dan bisa melakukan hal yang sama untuk sistem milik bank.
Masalah yang diselesaikan
- Setiap permintaan perubahan menjadi SOW, negosiasi, dan berbulan-bulan menunggu.
- Perubahan yang merusak bagian lain.
- Dokumentasi yang makin jauh dari kodenya.
Yang dikerjakan
- Permintaan perubahan berjalan dalam pipeline, disiapkan di salinan, dikompilasi dan diuji otomatis.
- Perubahan masuk ke sumber hanya setelah lolos; kegagalan tidak meninggalkan jejak.
- Loop kompilasi dan perbaikan untuk delapan stack teknologi.
- Basis pengetahuan dari kode dan dokumen milik bank.
- Berjalan sepenuhnya di dalam bank, termasuk model bahasanya.
Untuk siapa
Bank atau vendor yang ingin punya kapasitas perubahan sendiri di lingkungan tertutup.
Dibangun dengan
- Python · LangGraph · FastAPI
- Control center berbasis web
- Model bahasa lokal
- 8 stack target
Dua cara memulai
Ganti core, atau lengkapi core Anda.
Kedua jalur tidak saling bersaing. Bank bisa mulai dengan satu modul di core yang ada, lalu melangkah lebih jauh nanti.
Jalur A
Ganti core
Core dan Switch menjadi fondasi bank, dengan modul-modul pilihan di atasnya.
- Platform lengkap dari satu vendor
- Cocok untuk bank yang memperbarui sistem inti
Jalur B
Tambahkan modul ke core Anda
Pertahankan core yang ada dan pasang modul yang dibutuhkan — Report, Shield, Collect, Treasury, dan lainnya — lewat API.
- Langkah awal yang lebih kecil dan cepat
- Tanpa mengubah core yang sudah berjalan
Di balik layar
Dibangun di atas bagian tersulit perbankan.
Menulis kode bukan lagi bagian tersulit. Menjalankan perubahan dengan aman di sistem yang memegang uang orang, itulah yang sulit.
-
Domain perbankan yang tidak bisa diimprovisasi
Pesan kartu, kriptografi chip, manajemen kunci perangkat keras, akuntansi double-entry, dan kepatuhan OJK dibangun sejak awal.
-
Rekayasa keamanan, bukan prompt
Salinan kerja, kompilasi sungguhan, baseline, dan rollback otomatis yang menentukan apakah perubahan diterima — bukan keyakinan sebuah model.
-
Lima belas produk sebagai ajang pembuktian
Forge membangun dan mengubah setiap produk lain di portofolio, sehingga setiap perubahan yang dibuatnya menjadi masukan bagi cara kerjanya.
-
On-premise sejak dirancang
Semuanya, termasuk model bahasa di balik Forge, berjalan di dalam pusat data milik bank.
Model bahasa hari ini bisa menulis kode perbankan. Yang tidak dimiliki siapa pun adalah lapisan yang membuat perubahan itu aman dijalankan di sistem yang memegang uang orang.
Pertanyaan Umum
Hal-hal yang perlu Anda ketahui tentang Bank in a Box.
Bank in a Box adalah platform perbankan Matajari: lima belas produk perbankan — core banking, switching kartu dan ATM, serta tiga belas modul mandiri — bersama Forge, bidang kendali yang membangun dan mengubahnya.
Tidak. Bank bisa mengganti core dengan Core dan Switch dari Bank in a Box, atau mempertahankan core yang ada dan menambahkan modul seperti Report, Shield, Collect, atau Treasury lewat API.
Di pusat data milik bank. Bank in a Box adalah software white-label yang diserahkan kepada bank dan dirancang untuk berjalan on-premise, termasuk di lingkungan tanpa akses internet.
Ya. Core menjalankan produk konvensional dan syariah di satu buku besar, dengan pembiayaan Murabahah, Ijarah, Mudharabah, Musyarakah Mutanaqisah, dan Wadiah sesuai fatwa DSN-MUI.
Forge mengubah permintaan perubahan menjadi kode yang sudah diuji. Setiap perubahan disiapkan di salinan, dikompilasi dan diuji otomatis, dan baru masuk ke sumber jika lolos. Perubahan yang gagal tidak meninggalkan jejak.
OJK, Bank Indonesia, PPATK, LPS, DJP, dan DSN-MUI, dengan katalog 24 laporan.