Path A
Replace the core
Core and Switch become the bank’s foundation, with the modules it chooses on top.
- A complete platform from one vendor
- Suits banks renewing their core system
Banking platform
Bank in a BoxFifteen banking products, one control plane.
Core banking, card and ATM switching and thirteen standalone modules, with a control plane that builds them and keeps changing them — white-label software installed in the bank’s own data centre.
The problem
The real cost arrives after signing.
A bank doesn’t buy software that stays frozen. It buys the ability to change it — new products, new regulations, new channels.
Today every change is a negotiation. So banks stop asking, and their systems freeze.
What one change request turns into
- 01 Change request
- 02 Statement of work
- 03 Negotiation
- 04 Months of waiting
- 05 The bank stops asking
What most banking software offers
Features, an implementation project and a maintenance contract.
Every change after go-live becomes a new request, a new quote and a new wait.
What Bank in a Box offers
Speed of change
The ability to change a banking system safely, whenever the bank needs to. That is what Bank in a Box is built around.
The licence is paid once. Change is paid for the life of the system.
Forge, the control plane
A control plane that makes change safe.
Forge is not a code factory. Every change request runs through a pipeline: it is staged on a copy, compiled and tested automatically, and reaches the source only if it passes.
-
Step 1
Lead
Reads the change request and plans the work, keeping it within the scope that was asked for.
-
Step 2
Architect
Decides where the change belongs in the existing system and which parts it may touch.
-
Step 3 · only when needed
Database
Prepares database changes, only when the request needs them.
-
Step 4
Backend
Writes the code for the change, following the system’s existing patterns.
-
Step 5
Verify
Compiles for real and runs the automated tests. If the build fails, the compiler errors go to Repair and the result comes back here.
Loop with Verify
Repair
Receives the real compiler errors, fixes the code and sends it back to Verify until it builds and the tests pass.
-
Step 6
Reviewer
Reviews the change before it is accepted, including whether the documentation was updated.
-
Result
Code ready
The change is promoted to the source and a release package is prepared.
Four safety properties
- 01
A failure leaves no trace
Work happens on a copy. If a change fails, the source is exactly as it was.
- 02
Existing issues are recorded first
A baseline is taken before any change, so only problems the change introduces can block it.
- 03
It learns from failures too
What went wrong in one change is kept and used in the next.
- 04
Documentation stays current
A change to core logic is rejected if the documentation was not updated with it.
01 A failure leaves no trace
Work happens on a copy. If a change fails, the source is exactly as it was.
02 Existing issues are recorded first
A baseline is taken before any change, so only problems the change introduces can block it.
03 It learns from failures too
What went wrong in one change is kept and used in the next.
04 Documentation stays current
A change to core logic is rejected if the documentation was not updated with it.
One change, end to end
A small, real change, from the first check to a ready release package in about a minute.
Eight supported technologies
Spring Boot · Go · Node / Express · FastAPI · Web · React Native · Flutter · Android
Forge runs entirely inside the bank, language model included — nothing leaves the data centre.
| 01 | Starting state recorded | Done |
|---|---|---|
| 02 | Prepared on a copy | Done |
| 03 | Compile | Succeeded |
| 04 | Automated tests | Passed |
| 05 | Applied to the system | Done |
| 06 | Release package | Ready |
Three files changed, none outside the request’s scope. Compare that with months.
The portfolio
Three layers, fifteen products.
A core layer, standalone modules around it, and the control plane that builds and changes all of them. Each product can be bought and run on its own.
Control plane
Forge Builds and changes every product
Banking products, installed in the bank’s data centre
Module layer — each one standalone
- Originate
- Lend
- Collect
- Shield
- Guard
- Report
- Treasury
- Insight
- Engage
- Identity
- Gateway
- Enterprise
Core layer
- Core Core banking, conventional and sharia
- Switch Cards, ATMs and payment networks
Three rules every product follows
- 01
One product, one system
Each product has its own database, its own release and its own pipeline, so one can change without touching another.
- 02
Connected only through APIs
When Shield freezes an account, it calls the core over its API — and if that call fails, the account stays frozen.
- 03
Lives in the bank’s data centre
Built to run on-premise, even without an internet connection.
The fifteen products
Every product, and what it does.
Open any product to see the problems it solves, what it already does and who it is for.
Core layer
Core Core banking Conventional and sharia core banking on one double-entry ledger: teller, savings and deposits, and financing.
Problems it solves
- Conventional and sharia books kept on separate systems.
- Collectibility and loan-loss provisioning worked out outside the core.
- End-of-day processing that is hard to trace or rerun.
What it does
- Conventional and sharia share one ledger and one end-of-day run.
- OJK five-tier collectibility and IFRS 9 provisioning (CKPN) computed by the engine.
- Savings, current accounts and deposits with automatic rollover, plus virtual accounts.
- Financing on annuity, declining, flat and bullet schedules; Murabahah, Ijarah, Mudharabah, Musyarakah Mutanaqisah and Wadiah under DSN-MUI fatwa.
- Multi-currency with a Bank Indonesia rate book, an operator web console and an Open API.
Who it’s for
Banks replacing their core: commercial banks, BPR and BPRS, and new digital banks.
Built with
Go microservices · REST · gRPC · events · Conventional + sharia · Kubernetes-ready, on-premise
Switch Card & ATM switching Switching for cards and ATMs: ISO 8583, the EMV chip data path, ATM NDC and HSM key management.
Problems it solves
- Card numbers leaking into logs and event streams.
- Chip data altered on its way through the switch.
- Card and ATM processing tied to a closed vendor platform.
What it does
- Card numbers are tokenised and redacted; only sanitised events leave the switch.
- EMV chip data is passed through byte for byte.
- A fast, table-driven ISO 8583 codec with BER-TLV support.
- A pipeline that decodes, checks for duplicates, tokenises and looks up the card range for every message.
- Chip authentication through the HSM (ARQC in, ARPC out), PIN and token services, and ATM cash withdrawal.
Who it’s for
Issuers and acquirers with card and ATM estates, and switching providers.
Built with
Rust core + Go services · ISO 8583 · EMV · NDC · GPN · Visa · Mastercard · PCI DSS 4.0.1 mapping
Credit
Originate Credit origination End-to-end credit origination, from application and documents to decision and signed contract.
Problems it solves
- Credit policy applied inconsistently from one officer to the next.
- Decisions without recorded reasons, which consumer-protection rules require.
- Documents re-keyed by hand.
What it does
- Credit policy as code (debt-to-income, loan-to-value, tenor), changed only with dual approval.
- Every decision carries a code and its reasons, for POJK 22 transparency.
- Straight-through approval, or routing to manual review and committee.
- KTA, KPR, KKB, credit cards and working-capital loans, plus Murabahah, Musyarakah, Ijarah and Qardh.
- Document pipeline with on-premise OCR, collateral, e-contracts, a bank-statement analyser and the POJK 22 cooling-off period.
Who it’s for
Banks and multifinance companies.
Built with
9 credit products · 15-stage workflow · On-premise OCR, 19 document types · POJK 22
Lend Loan servicing Loan servicing after disbursement: schedules, payments, collectibility and restructuring.
Problems it solves
- Restructuring used to hide bad loans (evergreening).
- Collectibility updated late.
- Sharia late-payment charges mixed into income.
What it does
- Collectibility recalculated daily.
- Restructuring guardrails that stop evergreening.
- Sharia late-payment charges (ta’zir) kept separate.
- Ten amortisation methods and a daily batch that is safe to rerun.
- Real-time APIs for payments, early payoff and restructuring; loans are registered straight from origination.
Who it’s for
Banks with a growing loan book.
Built with
10 amortisation methods · Daily batch, safe to rerun · Real-time APIs
Collect Collections Collections that check every contact against the rules before it happens.
Problems it solves
- Collectors contacting borrowers outside permitted hours, too often or with intimidation.
- Payments agreed in collections not reaching the loan system.
- Cases opened by hand from spreadsheets.
What it does
- A compliance check before every contact: POJK 22 call hours, frequency and no intimidation.
- Approved message templates per channel and stage.
- Payment links and settlements recorded back to Lend.
- Escalation to legal.
- Cases opened automatically when Lend hands an account over.
Who it’s for
Banks and multifinance companies reducing bad loans without adding collectors.
Built with
Per-contact compliance check · Approved templates per channel · Linked to Lend
Risk & compliance
Shield AML & KYC Anti-money-laundering and know-your-customer: screening, due diligence, monitoring and reporting.
Problems it solves
- Name screening that misses spelling variations.
- A freeze decided in compliance but not enforced in the core.
- Suspicious-transaction reports assembled by hand.
What it does
- Fuzzy screening against DTTOT, OFAC and UN lists, politically exposed persons and adverse media.
- A freeze reaches the core through its API and fails closed.
- Due diligence for individuals and companies, with low, medium, high and sanctioned risk ratings.
- Transaction monitoring for PPATK typologies.
- CTR, STR and IFTI reports for GRIPS, signed with the HSM.
Who it’s for
Every bank — AML is mandatory spend.
Built with
DTTOT · OFAC · UN lists · PPATK typologies · GRIPS reports, HSM-signed
Guard Fraud scoring Explainable, rule-based transaction fraud scoring with case management.
Problems it solves
- Declines nobody can explain to the customer or the regulator.
- Rule changes going live without review.
- Every suspicious transaction treated the same way.
What it does
- Covers 13 fraud types.
- Scores from 0 to 1000: approve below 300, step-up authentication from 300 to 699, decline from 700.
- Allowlists take precedence over blocklists.
- Rule changes need four-eyes approval and run in shadow mode first.
- Value-based fail-safe and case management for investigators.
Who it’s for
Banks with rising digital volume that need declines they can explain.
Built with
13 fraud types · Score 0–1000 · 15 starter rules · 11-feature store
Report Regulatory reporting Regulatory reporting to OJK, BI, PPATK, LPS, DJP and DSN-MUI, from data to signed submission.
Problems it solves
- Regulatory reports built in spreadsheets.
- No record of where each figure came from.
- Submitted versions that cannot be reproduced later.
What it does
- Gather, compose, validate, dual sign-off, HSM signature, send, archive — and stop if any step fails.
- A lineage record for every figure, and versions that can be regenerated exactly.
- A hash-chained, write-once archive kept for ten years.
- A catalogue of 24 reports across six regulators, defined as code with read-only queries.
- XBRL, CSV and XML output, with a signature per regulator and role-based dual approval.
Who it’s for
Banks still preparing regulatory reports in spreadsheets.
Built with
24 reports, 6 regulators · XBRL · CSV · XML · HSM signature · 10-year archive
Finance
Treasury Treasury & ALM Treasury and asset-liability management: liquidity, provisioning, FX, money market, government bonds and risk limits.
Problems it solves
- Liquidity and capital ratios known only at the end of the day.
- Provisioning models run in spreadsheets.
- Limits checked after the deal, not before.
What it does
- LCR, CAR and net open position monitored during the day.
- IFRS 9 (PSAK 71) expected credit loss with PD, LGD and CCF and weighted scenarios, run daily.
- Provision changes posted straight to the core ledger.
- FX desk, interbank money market and government bonds, with IRRBB and stress overlays.
- Risk appetite and exposure limits as code with alerts; decisions stay with people under four-eyes control.
Who it’s for
Treasury teams working from spreadsheets.
Built with
LCR · CAR · NOP intraday · IFRS 9 / PSAK 71 · FX · PUAB · SBN · IRRBB
Enterprise Bank ERP & HRIS ERP and HR for the bank itself: corporate ledger, purchasing, payroll and consolidation.
Problems it solves
- ERP and HR systems that don’t talk to the core.
- Vendors paid without being screened.
- Payroll approved outside the system.
What it does
- Double-entry corporate ledger with a chart of accounts linked to the core and automatic posting.
- Procure-to-pay with vendor due diligence, sanctions screening and three-way matching.
- Payroll with CFO and CHRO approval, PPh 21 and BPJS.
- Consolidation across entities.
- Cost metering for AI agents.
Who it’s for
Banks and financial groups running ERP and HRIS separately from the core.
Built with
Corporate GL · Procure-to-pay · Payroll: PPh 21 · BPJS · Multi-entity
Data & channels
Insight Data warehouse & BI A data warehouse and business intelligence that answers questions asked in Indonesian.
Problems it solves
- Management reports assembled by hand.
- Figures published before the data has been checked.
- Cloud warehouses ruled out by data-residency rules.
What it does
- Data refined in three stages, from raw to curated to published.
- Quality gates with ten rule types that block publishing when data fails.
- A safety layer on every query: read-only, approved tables, time limits and row limits.
- Questions asked in Indonesian, plus a feature store.
- Daily briefs for each role — CEO, COO, CRO, CFO, CCO and the board — that read the same every time.
Who it’s for
Banks assembling management reports by hand that cannot use a cloud warehouse.
Built with
Bronze → silver → gold · 10 data-quality rule types · Questions in Indonesian · On-premise
Engage Mobile decision engine The decision layer behind a bank’s mobile channel — not a mobile banking app.
Problems it solves
- Decisions hard-coded into the app, so every change needs a new release.
- The same login challenge for every situation, whatever the risk.
- Consent records scattered across systems.
What it does
- Risk-based authentication.
- Content personalised per customer segment.
- Governed experiments: A/B and bandit tests with four-eyes approval and automatic stop guardrails.
- Consent records under the Personal Data Protection Law (UU PDP).
- Notification preferences, with security alerts always delivered.
Who it’s for
Banks with an app whose decisions are hard-coded.
Built with
Risk-based authentication · A/B and bandit tests · UU PDP consent
Foundation
Identity Identity, access & cryptography Identity, access and cryptography shared by the other Bank in a Box products.
Problems it solves
- Each system with its own logins and its own idea of who may do what.
- Keys kept in software instead of a hardware security module.
What it does
- Token issuance and revocation (JWT and JWKS).
- Access policies that deny by default and fail closed.
- A reference software HSM, replaced by PKCS#11 to a real HSM in production.
- A separate access domain for each product.
- Used by Shield, Report, Gateway and Originate.
Who it’s for
Usually comes with other Bank in a Box products rather than bought on its own.
Built with
JWT + JWKS · Default-deny policies · PKCS#11 to a hardware HSM
Gateway API gateway & contracts An API gateway and contract registry for SNAP BI and the bank’s Open APIs.
Problems it solves
- API changes that silently break partners.
- Meeting the SNAP BI mandate system by system.
- Personal data exposed in API responses.
What it does
- A contract registry with compatibility checks; breaking changes need four-eyes review.
- A gateway with a plugin chain and canary releases.
- A SNAP BI gateway: HMAC-SHA512 signatures, replay protection, idempotency, B2B tokens and HSM signing.
- Zero trust between services.
- Personal data masked according to purpose, under UU PDP.
Who it’s for
Banks meeting the SNAP BI mandate or opening Open APIs.
Built with
SNAP BI · JSON Schema · Avro · Protobuf · OpenAPI · Zero trust · UU PDP masking
Control plane
Forge Control plane The control plane that builds and changes the other products — and can do the same for the bank’s own systems.
Problems it solves
- Every change request becomes a statement of work, a negotiation and months of waiting.
- Changes that break something elsewhere.
- Documentation that drifts away from the code.
What it does
- Change requests run through a pipeline, staged on a copy, compiled and tested automatically.
- Changes reach the source only after passing; a failure leaves no trace.
- A compile-and-repair loop across eight technology stacks.
- A knowledge base built from the bank’s own code and documents.
- Runs entirely inside the bank, including the language model.
Who it’s for
Banks or vendors that want their own capacity for change in a closed environment.
Built with
Python · LangGraph · FastAPI · Web control centre · Local language model · 8 target stacks
Two ways to start
Replace the core, or add to it.
The two paths don’t compete. A bank can start with one module on its current core and move further later.
Path B
Add modules to your core
Keep the existing core and attach the modules you need — Report, Shield, Collect, Treasury and others — through APIs.
- A smaller, quicker first step
- No change to the core you already run
Under the hood
Built on the hard parts of banking.
Writing code is no longer the hard part. Running change safely in systems that hold people’s money is.
- 01
Banking domain that can’t be improvised
Card messaging, chip cryptography, hardware key management, double-entry accounting and OJK compliance are built in from the start.
- 02
Safety engineering, not prompts
Staging on a copy, real compilation, baselines and automatic rollback decide whether a change is accepted — not a model’s confidence.
- 03
Fifteen products as a proving ground
Forge builds and changes every other product in the portfolio, so each change it makes feeds back into how it works.
- 04
On-premise by design
Everything, including the language model behind Forge, runs inside the bank’s own data centre.
01 Banking domain that can’t be improvised
Card messaging, chip cryptography, hardware key management, double-entry accounting and OJK compliance are built in from the start. ISO 8583 · EMV · HSM · Double-entry · OJK.
02 Safety engineering, not prompts
Staging on a copy, real compilation, baselines and automatic rollback decide whether a change is accepted — not a model’s confidence.
03 Fifteen products as a proving ground
Forge builds and changes every other product in the portfolio, so each change it makes feeds back into how it works.
04 On-premise by design
Everything, including the language model behind Forge, runs inside the bank’s own data centre.
Today’s language models can write banking code. What nobody has is the layer that makes those changes safe to run in systems that hold people’s money.
Frequently Asked Questions
Everything you need to know about Bank in a Box.
Bank in a Box is Matajari’s banking platform: fifteen banking products — core banking, card and ATM switching and thirteen standalone modules — together with Forge, the control plane that builds and changes them.
No. A bank can replace its core with Core and Switch from Bank in a Box, or keep its current core and add individual modules such as Report, Shield, Collect or Treasury through APIs.
In the bank’s own data centre. Bank in a Box is white-label software delivered to the bank and is designed to run on-premise, including environments without internet access.
Yes. Core runs conventional and sharia products on one ledger, with Murabahah, Ijarah, Mudharabah, Musyarakah Mutanaqisah and Wadiah financing under DSN-MUI fatwa.
Forge turns a change request into tested code. Each change is staged on a copy, compiled and tested automatically, and reaches the source only if it passes. A failed change leaves no trace.
OJK, Bank Indonesia, PPATK, LPS, DJP and DSN-MUI, with a catalogue of 24 reports.