Banking as a service in practice: the API layer, ledgering and control

Banking as a service is the platform that makes embedded finance possible. It is a set of APIs provided by a regulated entity, usually an electronic money institution or a sponsor bank, that lets a non-financial company offer accounts, cards and payments. The APIs cover account creation, balance enquiry, payment initiation, payment status, card issuance, and transaction history. The brand calls the APIs, the provider executes the payments, and the sponsor bank holds the money. The brand never sees the payment rails, and the customer never sees the bank. The API layer is the product. It must be well documented, versioned, and tested, because the brand's developers build against it, and a breaking change will break every brand. The API must support idempotency, so a retried request does not create a duplicate payment. It must support webhooks, so the brand is told when a payment settles or fails, without polling. It must support pagination, so a transaction history with ten thousand entries can be retrieved in pages. And it must be secure, with OAuth 2.0 for authentication and mutual TLS for the connection. The API specification is the contract between the provider and the brand. Ledgering is the discipline that makes banking as a service work. Every payment must be recorded in a ledger, with a debit and a credit, a value date, and a reference. The ledger must balance at all times, and the balance must be reconcilable to the sponsor bank's account. The ledger is the source of truth for the customer's balance, and if the ledger is wrong, the balance is wrong, and the customer will see money that is not there, or will not see money that is. The requirements must state the ledger structure, the posting rules, and the reconciliation. Reconciliation in banking as a service has an extra layer, because there are two ledgers: the provider's ledger, which records what the brand's customers did, and the sponsor bank's ledger, which records what the bank did. The two must agree, and the reconciliation must run daily, with breaks investigated the same day. A break where the provider's ledger shows a payment the bank did not make is a serious defect, because the customer has been told the payment was made. The reconciliation must be automated, and the breaks must be visible to the operations team. Control is the sponsor bank's non-negotiable requirement. The bank must be able to see every payment in real time, must be able to stop a payment before it is sent, must be able to freeze an account, and must be able to audit the provider's systems. The bank must also be able to take over the operation if the provider fails, which means the bank must hold the data, the ledger, and the customer records, not just the money. A sponsor bank that cannot take over is a sponsor bank that is dependent on a single provider, and that is a concentration risk. The onboarding of a brand is a due diligence exercise. The provider must assess the brand's business model, its customer base, its risk appetite, and its compliance capability. A brand that serves high-risk customers, or that operates in a high-risk jurisdiction, will be rejected, or will be accepted with limits. The onboarding must be documented, and the risk assessment must be reviewed annually, because the brand's business changes, and the risk changes with it. The requirements must state the onboarding checklist, the risk criteria, and the review frequency. For a business analyst, banking as a service is an API and a ledger specification. The API specification must state every endpoint, every field, every error code, and every webhook. The ledger specification must state every posting rule, every reconciliation, and every control. The acceptance criteria must include a test where a payment is made through the API, the ledger is checked, the reconciliation is run, and the sponsor bank's view is verified. Last reviewed 7 November 2026. Further reading: the European Banking Authority opinion on banking as a service; the Financial Conduct Authority guidance on banking as a service; the Bank for International Settlements work on embedded finance; the OpenAPI specification documentation.