Bank-in-a-Box Talk to us

Digital banking channel · self-hosted

Keep your core. Replace the app your customers see.

Bank-in-a-Box is web banking software for banks and credit unions. The app talks to one canonical Banking API; an adapter translates each call to the core you already run. You install it in your own Kubernetes cluster. We sell the software. You run it.

See two banks on one build How the adapters work
One request from the appapps/web
GET /api/v1/accounts/{accountId}/balance
  1. Kesef Bank Fictional bank adapter mambu-v2 GET /deposits?accountHolderType=CLIENT&accountHolderId={clientId}
  2. Riverbank Fictional bank adapter cdr-banking GET /cds-au/v1/banking/accounts/balances
Same response shape either way 
{ "currency": "AUD",
  "currentBalance": "1250.30",
  "availableBalance": "1250.30",
  "asOf": "2026-09-12T01:54:23Z" }

The showcase

Two fictional banks. One build. Two unrelated cores.

Same container images, same web app. Each bank is a tenant config: a name, a logo, a color, a typeface and an adapterId. The features each bank shows follow what its core can actually do.

Fictional bank Signal look Core Mambu

Kesef Bank

Your money, clearly.

Kesef’s home screen in the demo app. “Move money” and Quick move appear because the Mambu adapter declares transfers.
Adapter
mambu-v2 → Mambu v2 API
In the app
Accounts and balances · Transactions · Loans · Transfers between own accounts
Voice
Confident and direct. Deep navy, one electric-lime highlight and heavy grotesk type.
Try the live demo

Hosted sandbox with synthetic customers. If it’s offline, you’ll see screenshots of the running app instead.

Fictional bank Meadow look Core CDR

Riverbank

Good banking, no fuss.

Riverbank’s home screen in the demo app. No “Move money” and no cards: CDR Banking is read-only, so the app leaves those out instead of greying them out.
Adapter
cdr-banking → Australian CDR Banking API
In the app
Accounts and balances · Transactions · Loans
Voice
Plain, warm, first-name terms. A bright spring-green hero, a slim icon rail and big friendly type.
Try the live demo

Hosted sandbox with synthetic customers. If it’s offline, you’ll see screenshots of the running app instead.

Your core next. Every adapter implements the same Go interface, so adding a core doesn’t touch the app. Tell us which core you run and we’ll walk through the mapping with you.

Name your core 

What changes, what doesn’t

Brand and core are configuration. Everything else is the product.

Set per bank

  • Brand. Name, logo, primary color, support and privacy links.
  • Core. integration.adapterId picks the adapter at startup. An unknown value stops startup rather than guessing.
  • Capabilities. The adapter declares what the core supports. Features it doesn’t declare are hidden, not shown disabled.

Identical everywhere

  • The app. Accounts, balances with source freshness, transactions, statements, loans, and own-account transfers where the core supports them.
  • Sign-in. Email link plus passkeys. A sign-in link alone can’t approve a transfer.
  • Money movement safety. One stable reference per transfer. After a crash or timeout the worker looks up the original instead of resubmitting.
  • Audit. Access denials and transfer decisions are written to the audit trail in your database.

What you license

Software you install. Not a hosted service.

Licensing is scoped per institution. We don’t publish prices; we’ll talk through packaging once we understand your core and your volumes.

  1. 01

    The channel

    Web banking app, canonical Banking API and background worker, as container images.

  2. 02

    An adapter for your core

    Mambu v2 and Australian CDR Banking. The Mambu adapter is built and tested against a contract mock from Mambu’s published v2 API specification; validation against a live Mambu sandbox is in progress. Other cores are scoped per engagement.

  3. 03

    A Helm chart

    Installs into your cluster against your PostgreSQL (or DynamoDB). Secrets stay in your Kubernetes Secrets.

  4. 04

    Signed images and an SBOM

    Every release is signed with cosign and ships an SPDX SBOM, so you can verify both before anything runs. How to verify

What we don’t do: host your channel, hold your customers’ data, or keep a connection into your cluster. What stays with you

Quick answers

The questions buyers ask first.

Short answers, each one also on this page in full.

What is Bank-in-a-Box?
Bank-in-a-Box is a customer-facing web banking channel a bank runs itself. The app talks to one canonical Banking API; an adapter translates each call to the core the bank already uses. It ships as a Helm chart and signed container images for the bank's own Kubernetes cluster.
Is it self-hosted or a hosted service?
Self-hosted. You install it in your own Kubernetes cluster against your own PostgreSQL or DynamoDB. We sell the software only: we never operate your channel, hold your customers' data, or keep a connection into your cluster.
Which core systems does it support?
Today the adapters are Mambu v2 and the Australian Consumer Data Right (CDR) Banking API. The Mambu adapter is built against Mambu's published v2 API specification; validation against a live Mambu sandbox is in progress. Other cores are scoped per engagement.
What happens when a core can't do something?
There are no disabled buttons. Each adapter declares the capabilities its core supports, and features it doesn't declare are simply absent. Riverbank has no “Move money” and no cards because the CDR Banking adapter is read-only.
Is it production-ready?
Not yet. Bank-in-a-Box is in early access and runs in evaluation mode against contract mocks and test doubles, with fictional banks and synthetic customers. Production mode, which adds bank identity proofing and production issuer registration, is in progress and due with general availability.

Bring your core. We’ll show you the mapping.

Talk to us Or see the demo walkthrough