Open Banking Reshaping Payments

You met open banking in ch26 and in the deep dive in ch65. This lesson does not re-explain it. It is about what open banking changes: for merchants, for banks, and for the business analyst who has to design around it. The change starts at checkout, where a shopper buying a 180 pound jacket online can choose pay by bank, approve the payment in their banking app, and send the money straight from their current account to the merchant. No card number is shared, no card fee is charged, and the merchant receives the funds faster than a card settlement cycle. Consent is the foundation of open banking. The customer must approve the payment, know the amount and the payee, and be able to withdraw consent for future access. A third party cannot take money without that approval, and the bank must check the consent before it releases funds. For a business analyst, this means the payment flow has extra steps that a normal transfer does not have, including consent capture, consent storage and consent expiry. A design that hides those steps from the customer will fail a regulatory review, even if the payment itself works perfectly. Open banking also changes the data a bank sees. The third party passes structured payment details through the interface, so the bank receives a clean instruction with the payee, amount and reference already validated. That reduces keying errors and makes reconciliation easier for the merchant, who can match each payment to an order without manual work. A merchant receiving 400 payments a day can reconcile them automatically, which is a real saving compared with matching card settlements that arrive in batches days later. The risks are different from card payments, and banks must manage them. Fraud can move faster when a payment is instant and irreversible, so banks need strong customer authentication, transaction monitoring and clear liability rules. If a customer is tricked into approving a 5,000 pound payment to a fraudster, the bank, the third party and the merchant must know who bears the loss and how the customer is protected. A good open banking service therefore pairs a smooth checkout with visible warnings, payment limits and a fast route to report a problem. For banks, open banking is both a threat and an opportunity. It threatens card fee income and the control banks once had over the payment journey, but it also lets banks offer new services, such as payment initiation for corporate clients, account aggregation and smarter cash management. A bank that builds reliable interfaces, clear consent journeys and strong fraud controls can become the trusted account behind many third party services. A bank that treats open banking as a compliance burden will watch its customers pay through someone else interface while its own channels fall quiet. Worked example with numbers: a shopper buys a GBP 180 jacket online and chooses pay by bank, and the merchant PISP sends the instruction through the bank API. The customer approves GBP 180 to the merchant in the banking app, the bank debits the account immediately, and the merchant receives the funds the same day, instead of waiting two days for a card settlement and paying a card fee of around 1.5 percent, about GBP 2.70. The merchant saves the fee and gets the money faster, but takes on a new duty, because if the customer is tricked into approving the payment, the merchant must show that the consent was genuine and the payee was correctly named. Failure and recovery: open banking fails when consent expires, when the customer revokes access, or when the bank API is unavailable at the moment of payment. If consent has expired, the PISP must ask the customer to re approve, and the payment cannot proceed until that happens. If the API is down, the merchant must offer another payment method, such as a card, and must not retry the bank payment silently, because a retry after the customer has left the checkout can debit the account without the customer seeing it. The recovery for a failed payment is a clear message to the customer, a record of what was attempted, and a route to complete the purchase by another method, because a customer who sees only an error will abandon the purchase. For a business analyst, product owner or subject matter expert, the open banking requirement must map the consent journey step by step, including the consent request, the authentication, the approval, the payment initiation and the status update, and must state what happens at each step when the customer says no or the system fails. The requirement must also state the liability rule, who bears the loss when a customer is tricked, and must name the data the bank passes to the third party and the data it withholds. A design that shows the consent clearly, names the amount and the payee before approval, and gives the customer a way to withdraw consent, will pass its tests and keep its customers. Source: PSD2; UK Open Banking standards; last reviewed 7 November 2026.