Bank Accounts - As a Service
Monetary Accounts
A monetary account is the core object in the bunq data model. It's a real euro bank account with its own IBAN, capable of sending and receiving SEPA payments, holding a balance, and being linked to one or more cards.
With bunq BaaS, you can open monetary accounts programmatically on behalf of your verified sub-users. Each account is a fully functional bank account — not a virtual ledger or a pre-paid balance, but a real account at a regulated Dutch bank.
The paradigm
Every monetary account belongs to a user. Before you can create an account for someone, that user must be KYC-verified (see KYC as a Service).
A single user can hold multiple monetary accounts — for example, a main account and a savings pot, or accounts in different currencies. Each account has its own IBAN and tracks its own transaction history.
The main account type you'll use for BaaS is MonetaryAccountBank — a standard IBAN-bearing euro account.
Key things to understand:
IBANs are real. Every
MonetaryAccountBankgets a dedicated IBAN that works on all SEPA payment rails. Third parties can send money directly to your user's IBAN.Account status. Accounts move through
PENDING,ACTIVE,CANCELLED, andCANCELLED_PENDING_SETTLEMENTstates. Most of your logic will act onACTIVEaccounts.Balance and transactions. The balance and full transaction history are queryable at any time via the account ID.
Limits. Account limits (transaction volume, balance caps) are set at the BaaS agreement level. Contact your account manager to adjust them.
Flow overview
Your platform bunq API
───────────── ────────
(KYC verified sub-user exists)
POST /monetary-account-bank → Opens account, returns IBAN
GET /monetary-account/{id} → Fetch balance and status
GET /payment → List transactions on accountRelevant API endpoints
Create a bank account (IBAN)
List all accounts for a user
Get a specific account
Close / cancel an account
PUT /v1/user/{userID}/monetary-account-bank/{itemID} (set status to CANCELLED)
Get account balance
Included in the account object — see balance field
List transactions
Account object highlights
When you GET a monetary account, the response includes:
iban— the account's full IBAN (share this with your user or third parties for incoming payments)balance— current balance object withvalueandcurrencystatus— account lifecycle statedisplay_name— human-readable label you set at creationalias— additional payment aliases (e.g. phone number, email) if configured
Common integration patterns
Pattern 1 — One account per user. The simplest model. Create one MonetaryAccountBank per verified sub-user. Works well for platforms where each user has a single wallet or balance.
Pattern 2 — Multiple accounts per user. Create separate accounts for different purposes (e.g. "spending" vs "savings", or separate accounts per project/invoice). Users and your platform can move money between these accounts using internal transfers.
Pattern 3 — Shared or pooled accounts. For marketplaces or escrow-like flows, a single account can receive funds from many parties. Use transaction metadata and callbacks to reconcile incoming payments to the correct source.
Last updated
Was this helpful?