Open-source core banking.

Whether you're building a bank or embedding banking into your product, Queenswood runs the banking behind it. You bring the banking licence, the payments provider and the identity provider.

Register and open a sandbox bank Source on GitHub
A tour of what your bank can do, in the operator consoleWatch the console tour
What you bring
1

A banking licence

Or a partner who holds one.

2

A payments provider

Your account with one, such as Modulr. We connect to it for you.

3

An identity provider

Your account with one, such as Zyphe. Same again.

4

Somewhere to run it

Your own infrastructure, Google Cloud, or wait for our managed offering.

Bring nothing while you test.

Our sandbox simulates your choice of payments and identity providers, and no licence is needed for simulated money.

For decision-makers

Why run your bank on Queenswood

Open source

The code is yours to read, run and change under the MIT licence, on infrastructure you choose. No licence fee, and you decide when to take each release.

Audit trail

Everyone on your team signs in as themselves with a role, and an audit log records every change to who may act for your bank, with who made it and why.

Pluggable providers

Payments and identity verification each connect through an adapter, and a simulator stands in for each provider, so you can build and test before a contract is signed.

Fine-grained policies

Policies are records checked on every request, from simple limits to rules over rolling windows of activity, and your bank's tier sets the capabilities it works within. Changing either ships no code.

Configurable products

Rates, fees, limits and rewards are configuration, published as versions and migrated on your schedule. A new product line needs no code change.

Sandbox

Your bank starts in test, where you try everything with simulated money on the same software your customers will use, and moves to live when you're ready.

Test suite

Generated tests check its answers against a model of how a bank should behave, and scenarios drive the live API end to end.

Documentation

Every decision, design and procedure is written down, and all of it says what's done and what's not.

For product

Configurable products

Change a rate, add a welcome reward or launch a new product line, and move existing customers to the new terms only when you plan and approve it, with no need to ship code.

Your product team publishes each product version in the console, and plans the migrations that move holders onto a new one.

A migration moving holders onto a new product version, in the console

Products

Configure rates, fees, limits and rewards per product, and publish each change as a new version. No code to ship.

Onboarding

Every new customer is identity-checked as they sign up, and can't open an account until the check clears.

Payments

Customers pay and are paid by UK Faster Payments in seconds, with Confirmation of Payee first.

Interest

You decide when interest is accrued and paid: daily, monthly or yearly.

Migrations

Move holders onto a new product version as a planned campaign: choose who moves, notify them, set the schedule, and approve it before it runs.

Product specs

Every capability has a spec saying what it's for and who uses it, in product language.

For finance

General ledger and trial balance

Your finance team reads the general ledger in the console, checks the trial balance ties, and sees what waits in suspense.

Every movement is recorded as matching debits and credits, so the books always balance, down to fractions of a penny of interest.

Trial balance in the console

For compliance

Audit trail

The access log, the policies in force and the ledger say who did what, and under which rules.

Everyone on your team signs in as themselves, as owner, admin, developer or viewer. An audit log records every change to who may act for your bank (invitations, role changes, removals and the operator's own acts) with who made it and why.

People and access in the console

For engineering

One API

One base URL, not a service per domain, described by a single OpenAPI 3.x spec. The spec is generated from the routes themselves, so it can't drift from what the API does.

Idempotent writes

Every write takes an idempotency key, so a retried request replays the first answer rather than paying twice.

Webhooks

Deliveries are retried until acknowledged, up to a limit, and each is recorded, so a missed one can be found and sent again.

Simulators

A simulator stands in for the payments and identity providers, so you build and test with no network dependencies.

A worked example

The demo digital bank is a retail banking app built entirely on the API, and the reference for building yours.

# The platform, as one process with its containers.
just monolith-start

# The console, on http://localhost:5173.
just console-start

# The demo digital bank: seed it, then start its
# backend and its app, on http://localhost:5174.
just demo-digital-bank-seed
just demo-digital-bank-start
just demo-digital-bank-app-start

Sandbox

Your bank starts in test

Register, name your bank and choose its providers. You try everything with simulated money on the same software your customers will use, and move to live when you're ready.

The test console is offline for now.