Open Banking Explained: How Account-to-Account Payments Work

Open banking is a system that lets a customer give a licensed third party permission to read their bank account or move money from it, using secure interfaces the bank is required to expose. At the center of it sits the account-to-account payment: money moves straight from the payer's bank account to the merchant's, without a card network in the middle.

That definition matters less than what it changes. When a payment can be triggered from inside a banking app, a merchant can be paid in seconds, on a rail it already trusts, and often at a lower cost than card acceptance. The rest of this guide covers how the flow works, what the key terms mean, where the model is live, and what to check before you build it into checkout.

What open banking means in practice

Open banking is a set of rules plus a set of technical standards. The rules say who can access account data and payment initiation, under what license, and with what customer consent. The standards say how the data and the payment instruction actually travel between systems.

Three things follow from that split, and they are useful to keep separate:

• Access is consented. The customer approves a specific provider for a specific purpose, and that approval can be withdrawn.
• Access is licensed. Only regulated entities can act as the intermediary, which is why a merchant integrates with a provider rather than connecting to banks directly.
• Access is scoped. Reading a balance and moving money are different permissions, and a provider may be approved for one and not the other.

Two laws are worth knowing because they shaped the model. In the European Union, the revised Payment Services Directive (PSD2) created the legal category of payment initiation service provider. In the United Kingdom, the Open Banking Standard was built on top of that framework and is administered by Open Banking Limited. Both are official sources you should verify current requirements against, because the details change.

How open banking payments work, step by step

An open banking payment is an instruction to the payer's bank to move funds to a named recipient. The steps below describe the common flow; exact screens and timing vary by provider and country.

1. Selection at checkout. The customer chooses the bank-payment option and picks their bank from a list.
2. Consent. The merchant's provider asks the customer to approve a one-off payment request, stating the amount, the recipient and the purpose.
3. Redirect and authentication. The customer is sent to their own bank, or to the bank's app on the same device, and authenticates there. In most markets strong customer authentication applies, which usually means something the customer knows plus something they hold.
4. Authorisation. The bank checks funds, applies its own controls, and the customer confirms the payment.
5. Confirmation. The provider receives a payment status, and the merchant is told whether the payment succeeded or failed.
6. Settlement. Funds move between banks on the domestic or regional clearing rail and reach the merchant's account.
7. Reconciliation. The merchant matches the confirmation to the order, ideally using a unique reference generated at the start.

The confirmation step is what separates this from a bank transfer with a screenshot attached. The merchant gets an authenticated signal, not a promise, which is why some providers can issue an instant payment guarantee on top of the rail.

Key terms, defined plainly

Reading that table, one distinction does most of the work. A payment initiation service is the thing that starts a payment. The open banking standard is the plumbing underneath. Merchants buy one, not the other.

The difference between open banking and account to account payments

These two terms get used as if they were the same. They overlap, but they describe different things.

Account to account payments are a transfer method. The money moves from one bank account to another, and that has been possible for as long as banks have existed. Open banking is a regulatory and technical framework for granting access to that movement and to account data. An A2A payment can be manual, initiated by the customer typing a sort code into a banking app. An open banking payment is initiated by software, on the customer's instruction, within a licensed framework.

That difference has practical consequences for a merchant:

• A manual transfer gives you no reliable signal that the money is coming, so you carry the risk until it arrives.
• An open banking payment returns an authenticated status, so your order system can act on it immediately.
• Both need the same bank-side reference to reconcile properly, which is why the reference field matters more than it looks.

The secondary keyword hides a useful rule: whatever the label, the quality of an A2A payment to a merchant depends on the confirmation, not the transfer itself.

A worked example (illustrative figures)

A UK-based subscription business sells a £120 annual plan to a customer who banks domestically. These numbers are illustrative and not a quote from any provider.

1. The customer selects pay by bank at checkout and picks their bank.
2. The provider requests a one-off payment of £120, with the order reference attached.
3. The customer authenticates with their bank and approves the payment.
4. The bank confirms the instruction and returns a success status to the provider within the session.
5. The provider tells the merchant the payment succeeded and passes the reference.
6. Funds settle shortly after, subject to the provider's settlement schedule.

Now compare the failure path. Suppose the customer has insufficient funds. The bank declines, the provider reports a failure, and the merchant can retry or show another method before the customer leaves the page. With a manual transfer, that failure mode surfaces days later, as a missing payment and a dunning email.

The cost comparison is where merchants often look first, but fees vary too widely by country, provider and volume to put a number on. Ask any provider two questions: what you pay per transaction, and who carries the risk when a confirmed payment is later reversed.

Common misconceptions

"Open banking gives access to the whole account." Consent is scoped. A payment initiation grants one instruction; an account information grant covers stated data, for a stated period, and the customer can revoke it.

"It replaces bank transfers." It formalises them. The underlying rail is the same domestic clearing system; what changes is who can initiate and confirm the payment.

"It is a single global system." The opposite. The EU and UK have the most developed frameworks, with mandated interfaces and a licensing regime. Other markets have grown differently, often through national instant-payment schemes and bank-built APIs, and some rely on voluntary market standards rather than statute. Some US progress runs through API agreements between banks and aggregators, with open banking rulemaking still being implemented. Legal status, availability and timing differ by jurisdiction, and you should check the rule with the national regulator before you build.

"One certification covers every country." Licensing is per jurisdiction. A provider live in the EU may need separate arrangements to serve UK customers, and vice versa.

"Cost is always lower than cards." The per-transaction fees may be, but total cost also includes integration, failed-payment recovery and the value of cardholder protections you give up. UK consumer protections for open banking payments have moved toward parity for some cases, via a voluntary reimbursement scheme, but the scope is narrower than chargeback rights on cards. Verify the current terms with the scheme operator.

Why open banking payments matter for merchants selling abroad

Cross-border selling is the point where the model earns its keep. If you sell into a market with a mature A2A rail, offering it at checkout can reach customers who prefer paying from a bank account, and it can reduce your dependence on a single card acquirer.

Three practical reasons to look at it:

• Acceptance. Bank-based payment is the default in some European markets, and card decline rates are higher for some customer segments than merchants expect.
• Settlement speed. Instant rails shorten the time between an order and available funds, which helps cash planning on thin margins.
• Price structure. Where per-transaction pricing undercuts card acquiring at your volumes, the saving is real. Where it doesn't, it isn't.

The trade-offs are just as real. Refunds and disputes are less standardised than card chargebacks. Recurring billing support varies by provider and market, so subscription businesses need to check that specifically. And your checkout has to handle a redirect, a returning customer, and a fallback method when the bank declines.

The practical takeaway: open banking is a licensed framework for letting software move money between bank accounts with the customer's consent. An A2A payment is the transaction it enables. Before you add it, confirm the market is live, confirm your provider's license and settlement terms in writing, check refund and recurring support, and make sure the payment status, not the customer's word, drives your order flow. This is general information, not financial, legal or tax advice.