The bank-MFS bridge
A Digital Payment Switch
that lives inside your bank.
FinBridge connects a Bangladeshi commercial bank's core banking system to bKash, Nagad, Rocket, Upay, and the Bangla QR scheme, without taking a single byte of CBS data off-premises. Bank-owned binary, bank-owned data, mapped to the Bangladesh Bank Cyber Security Framework before line one was written.
- Runs entirely inside the bank data centre
- ISO 8583, ISO 20022, and REST in one switch
- Mapped to BB-CSF, BFIU, Bangla QR rules
- Optional Aegis fraud score on every transaction
Diagram represents the target architecture. FinBridge is a vision-stage product with no production deployment today. Pilot bank engagement opens Q3 2026.
01 / What is FinBridge?
FinBridge is KaritKarma's planned on-premises Digital Payment Switch for Bangladeshi commercial banks.
It connects a bank's core banking system to the country's mobile financial service rails (bKash, Nagad, Rocket, Upay) and to the Bangla QR interoperability scheme. The switch is bank-owned, deployed inside the bank's data centre, and it never holds customer funds. Core banking remains the system of record; FinBridge translates protocols (ISO 8583, ISO 20022, REST), enforces velocity and AML/CFT controls inline, emits a hash-chained audit trail to the bank's SIEM, and authorises each transaction against CBS through the vendor's documented third-party switch contract.
FinBridge is in design phase today. The first pilot-bank deployment is targeted for Q4 2026. The product description on this page is the target architecture; nothing on this page should be read as a claim of shipped production capability.
02 / Four design pillars
Built to be the switch
a bank can sign off on.
FinBridge is opinionated about four things. The opinions are the product. Each pillar maps to a class of question that bank CTOs, CISOs, and BB examiners ask in the first hour.
On-premises, bank-owned, no foreign cloud
FinBridge runs inside the bank data centre. Containers and bare metal, both supported. No transaction data leaves the bank perimeter. Configuration ships as code, not as a SaaS dependency.
CBS-safe by design
FinBridge is a switch, never a ledger. It does not hold funds, does not duplicate balances, and never modifies CBS data outside the documented authorisation endpoints supplied by the CBS vendor.
Mapped to BB-CSF, BFIU, and Bangla QR
Designed clause-by-clause against the Bangladesh Bank Cyber Security Framework, BFIU AML/CFT guideline, and Bangla QR interoperability rules. Audit evidence packages target the same clauses your examiners cite.
ISO 8583, ISO 20022, REST in one switch
Card-rail ISO 8583, modern ISO 20022 pacs/pain messages, and per-MFS REST or SOAP callbacks all terminate in the same engine. Routing, retries, and idempotency are protocol-aware.
03 / Transaction flow
One message,
five well-defined hops.
The bridge is deliberately short. Every hop has a documented contract, a documented timeout, and a documented audit event, so the bank can reason about behaviour without reading source.
Target figures. Validated against the pilot bank's workload before any GA-readiness claim.
- 01
Customer initiates
Wallet-to-account or account-to-wallet request originates from a bKash, Nagad, Rocket, or Upay app, or from the bank's own digital channel.
- 02
FinBridge accepts
Inbound message terminated inside the bank's DMZ. ISO 8583 from card rails, ISO 20022 from MFS partners, REST callback from bank channels.
- 03
Policy, AML, fraud
Idempotency check, BFIU velocity rules, optional Aegis fraud score, per-MFS limits, BB-CSF audit hook fires before any CBS call.
- 04
CBS authorises
FinBridge calls the bank's CBS authorisation endpoint inside the LAN. CBS remains the system of record; FinBridge never holds funds.
- 05
Switch settles
On CBS authorisation, FinBridge confirms to the MFS rail, posts the settlement record, and emits a hash-chained audit event to the bank's SIEM.
04 / Target rails and adapters
Designed for Bangladesh-specific rails, not retro-fitted.
Every MFS provider and every CBS vendor below is on the design roadmap. Each one will ship as a separately versioned adapter, so the bank can roll out one rail at a time without forking the switch core.
- MFS-01DesignbKashISO 20022 + REST
- MFS-02DesignNagadREST API + callbacks
- MFS-03Roadmap Q4 2026Rocket (DBBL)ISO 8583 + REST
- MFS-04Roadmap Q4 2026Upay (UCB)REST API
- MFS-05Roadmap Q4 2026Tap (Trust Bank)REST API
- MFS-06DesignBangla QR schemeISO 20022 + EMVCo QR
- CBS-01DesignTemenos T24Temenos
- CBS-02Roadmap Q4 2026Finacle 10Infosys
- CBS-03Roadmap Q4 2026FlexCubeOracle
- CBS-04Roadmap Q4 2026Bank UltimusLEADS
Adapter availability follows the pilot bank's CBS first. Other vendors enter the queue as banks engage.
05 / CBS-safe controls
The four controls every CBS owner asks about, on day one.
CBS is the bank's most sensitive system. A switch that talks to it has to behave like a polite tenant, not a roommate with the keys to everything.
Read-and-authorise-only contract
FinBridge talks to CBS through the authorisation endpoints the CBS vendor publishes for third-party switches. No direct SQL, no schema reads, no batch posting back into ledgers.
Circuit breaker on CBS dependency
If the CBS endpoint degrades, FinBridge fails closed within the rate-limit envelope, queues retries with jitter, and surfaces a structured CBS-DEGRADED alert before queueing pressure can backpressure CBS itself.
Hash-chained audit before authorisation
Every inbound message receives a SHA-256 chained record before CBS is touched. The audit chain ships to the bank's SIEM, satisfying BB-CSF Section 5 monitoring without retro-fitting log shippers.
Operator change-management built in
Limit changes, rule changes, MFS partner toggles are versioned with maker-checker approval. No SSH-into-prod for normal operator tasks. Every change leaves a signed trail in the audit chain.
06 / How FinBridge compares
FinBridge vs. in-house build, vs. SmartCash, vs. generic ESB.
The honest comparison. In-house builds dominate today, generic switches and ESBs are present in some banks, and SmartCash variants exist. None of them combine Bangladesh-rail focus, CBS-safe contracts, and the BB-CSF audit story by default. That is the FinBridge wedge.
| Capability | FinBridge | In-house | SmartCash | Generic ESB |
|---|---|---|---|---|
| Runs on the bank's own data centre, no foreign cloud dependency | Target by design | Vendor-hosted variants | ||
| Purpose-built for Bangladesh MFS rails (bKash, Nagad, Rocket, Upay) | Target by design | Per integration | ||
| ISO 8583 + ISO 20022 + REST in a single switch | Roadmap Q4 2026 | Usually one protocol | Custom build per rail | |
| Hash-chained audit ready for BB-CSF Section 5 | Target by design | |||
| Bank owns the source, can self-host without vendor lock | Source-available to bank under partnership | |||
| Optional Aegis fraud-score hook on every MFS transaction | Roadmap, native integration | Per integration | Bring-your-own | Bring-your-own |
Capability claims for SmartCash variants and ESB products are based on public documentation as of 2026 Q2. FinBridge claims are target capabilities at first GA. Speak to KaritKarma for the current design-phase status and to other vendors for their shipped matrices.
07 / Pilot integration plan
Four phases from kickoff to first BB examination.
The integration plan is the product, almost as much as the binary. FinBridge is co-developed with the pilot bank, not dropped in. Every phase has a defined exit criterion that the bank's IT-ops and risk teams sign off on.
- P1Weeks 1-2
Discovery and CBS interface workshop
Pin down the CBS vendor's authorisation contract, the MFS contracts in scope, and the bank's audit and SIEM destinations. Output: signed integration design.
- P2Weeks 3-6
Install in a parallel-prod environment
Bare metal or container install inside the bank data centre. Shadow-mode reads against CBS without authorisation calls. Soak tests on the bank's SIEM pipeline.
- P3Weeks 7-12
Per-MFS go-live, one rail at a time
Bring up bKash first, then Nagad, then the rest. Per-rail kill-switch, per-MFS rate envelope, per-MFS rollback plan. No big-bang cutovers.
- P4Weeks 13-14
Audit handover and BB examination prep
Evidence pack mapped clause-by-clause to BB-CSF, BFIU, and BRPD-2 expectations. Run-book and operator drills handed to the bank's IT-ops team.
08 / Regulatory mapping
Mapped clause-by-clause to Bangladesh Bank, before line one.
FinBridge isn't a generic switch with compliance bolted on. The design starts from the BB-CSF, BFIU, and Bangla QR clauses and works backwards into architecture, so the audit evidence package is a by-product, not a re-write.
Continuous monitoring
Every FinBridge message flows into the hash-chained audit and the bank's SIEM. The control is structural, not a bolt-on log shipper.
Velocity, structuring, beneficiary scoring
Per-customer, per-MFS, per-corridor velocity ceilings evaluated inline. Auto-trigger thresholds for CTR and STR/SAR triage handoff.
Issuer-acquirer messaging
FinBridge designed as a bank-side acquiring switch for the Bangla QR scheme, with the same engine handling issuer-side authorisations.
Maker-checker + audit isolation
All operator actions captured in a tamper-evident chain, satisfying BRPD-2 expectations for vendor-supplied switching software inside the bank.
09 / Planned stack
A small, opinionated stack.
Go for the switch core, Postgres for state, OpenTelemetry to the bank's SIEM. Wenme and Darwan handle operator login and policy, both deployed inside the bank perimeter. No off-prem dependency in the data path.
- Switch coreGo, gRPC, NATS JetStream, pgx
- AdaptersPer-CBS + per-MFS plugin contract, hot-reloadable
- DatastorePostgreSQL 18 inside bank DC, no off-prem replica
- Identity + RBACWenme operator login, Darwan policy decisions
- CommsBitsPath for operator notifications, no customer comms
- TelemetryOpenTelemetry to the bank's SIEM, hash-chained audit
10 / Frequently asked
The questions bank CTOs ask in the first hour.
Every answer below mirrors the wording in our structured-data payload, so AI answer engines and regulatory reviewers see the same text. Honest about vision-stage status throughout.
- 01What is FinBridge?
- FinBridge is KaritKarma's planned on-premises Digital Payment Switch for Bangladeshi commercial banks. It connects a bank's core banking system to mobile financial service rails like bKash, Nagad, Rocket, and Upay, plus the Bangla QR interoperability scheme. The switch terminates inside the bank's data centre, never holds customer funds, and never moves CBS data off-premises. FinBridge is a vision-stage product today, with Q4 2026 as the target window for the first pilot bank deployment.
- 02Is FinBridge production-ready?
- No. FinBridge is in design phase. There is no shipping codebase yet. The product page on karitkarma.com describes the target architecture, the target deployment model, and the regulatory clauses the design is aligned to, so that banks evaluating their Bangla QR and MFS-rail roadmap can engage early. The first pilot deployment target is Q4 2026, with a single pilot bank, before any broader rollout.
- 03Does FinBridge talk directly to my core banking system?
- Yes, but only through the third-party authorisation endpoints the CBS vendor publishes for switches. FinBridge does not perform direct SQL, does not duplicate the ledger, and does not modify CBS records outside the documented authorisation contract. The initial design targets Temenos T24 authorisation callbacks, with Finacle, FlexCube, and Bank Ultimus on the roadmap as adapter implementations.
- 04Which MFS providers does FinBridge connect to?
- The first design pass covers bKash and Nagad as primary, with the Bangla QR interoperability scheme as a parallel rail. Rocket (DBBL), Upay (UCB), and Tap (Trust Bank) are on the roadmap to follow. Each MFS rail ships as a separately versioned adapter so that a contract change at one provider never forces a redeploy of the entire switch.
- 05Is FinBridge on-prem or cloud?
- On-prem only, by design. Bangladesh Bank does not permit core banking systems to be hosted off-premises, and FinBridge sits directly in the CBS authorisation path. FinBridge ships as containers or bare-metal binaries to the bank's own data centre. There is no SaaS variant and there is no off-prem mirror of transaction data. The only thing that ever leaves the bank perimeter is operational telemetry to the bank's chosen SIEM, on the bank's own pipeline.
- 06How does FinBridge compare to building this in-house or to a generic ESB?
- In-house builds are common in Bangladesh and they work, but every new MFS rail or CBS upgrade restarts the integration effort. A generic enterprise service bus can carry the messages, but it has no opinion on ISO 8583, no opinion on Bangla QR, no built-in audit chain for BB-CSF Section 5, and no native fraud hook. FinBridge is the opinionated middle ground: a single switch that already knows the Bangladesh MFS rails, ships the audit story by default, and is co-developed with a pilot bank rather than reverse-engineered from generic middleware.
Become a pilot-bank design partner
Help define the switch
your bank actually wants.
FinBridge is being designed with one Bangladeshi scheduled commercial bank in the room from day one. If your bank is planning a Bangla QR rollout or rebuilding its MFS rails for BB-CSF compliance by December 2026, we want to talk.