What Open Banking Is and Why Regulators Forced It

Open banking is a regulated way for a customer to give a licensed third party access to a bank account, either to read information or to start a payment. The third party connects to the bank through an application programming interface, known as an API, and the customer gives explicit consent for each access. The third party never sees the customer bank password, and the bank checks the third party licence before it shares anything. A customer might let a budgeting app read transactions from three accounts in one view, or let a retailer start a payment straight from a bank account at checkout. The bank stays the holder of the account, and the third party acts only within the consent the customer gave. Paying by bank can be cheaper for a merchant than a card and can settle faster. Before open banking, customers who wanted a combined view of their money often gave their bank login details to an app, a practice called screen scraping. The app logged in as the customer and copied the screen contents, which meant the customer password sat outside the bank and the bank could not tell the app from the real customer. If the app was breached, the password could be stolen, and if the bank changed its website the app broke. Regulators saw this as unsafe and unfair, because it pushed risk onto customers while banks kept control of the data. Open banking replaced that fragile workaround with a standard, auditable API route. In Europe, the Second Payment Services Directive, known as PSD2, forced banks to open their accounts to licensed third parties from 2019. PSD2 said that a bank could not block a licensed provider, that access had to be free of charge for the provider, and that the customer consent and strong authentication rules had to be followed. The aim was competition, new firms could build payment and account services without becoming a bank, and customers could choose services that suited them. Banks had to publish API interfaces, run a testing environment, and support the new providers, which turned account access from a bank privilege into a regulated right. The third payment services directive, PSD3, together with the Payment Services Regulation, is the agreed successor to PSD2 and would fix its weak points. PSD3 is not law yet: political agreement was reached on 27 November 2025, final compromise texts were published on 23 April 2026, and formal adoption and Official Journal publication are expected in December 2026 or January 2027, with most PSR obligations applying about 21 months later, around the second half of 2028. Until then PSD2 remains the law in force. As agreed, PSD3 would tighten fraud rules, improve the way banks and third parties share fraud information, strengthen refund rights when fraud happens, and clarifies how payment verification should work. It also improves accessibility, so authentication must work for customers who cannot use a phone app or a fingerprint. For a business analyst, the point is that PSD3 is not a new idea, it is PSD2 made stronger, clearer and fairer, once it becomes law, and the work it creates is in fraud controls, verification, consent screens and accessible authentication journeys. For example, a customer who banks with one bank and holds a savings account with another can let a budgeting app read both accounts, so the app shows a single balance of EUR 5,000 across the two accounts and lists the monthly spending in one place. The customer gives consent for 90 days, the app reads the transactions through the bank APIs, and the customer can revoke the consent at any time. No password changes hands, and the banks check the app licence on every call. A worked example shows open banking in practice. A customer of Bank A wants to use a budgeting app to see all their accounts in one place. The customer selects Bank A in the app, is redirected to Bank A to authenticate with strong customer authentication, and consents to the app reading their account information. The app, acting as an account information service provider, calls Bank A's account information API and receives the customer's balances and transactions. The customer never gives their Bank A password to the app, and the app cannot move money, because it only has a read scope. The customer can revoke the consent at any time from Bank A's app, and the budgeting app immediately loses access. For a business analyst, the requirement is to define the consent flow, the scopes, the revocation behaviour, and the liability if the app accesses data after the consent is revoked. A failure scenario tests the consent. A budgeting app continues to call Bank A's API after the customer has revoked its consent, because the app cached the access token and did not check whether it was still valid. Bank A's API must reject the call with a 401 Unauthorized response, because the token was revoked when the consent was revoked. The bank must also log the attempt and may suspend the app's access if it repeatedly calls with a revoked token. The consent is not a one time check; it is enforced on every call, and a token that was valid yesterday is invalid today if the consent has been revoked. PSD3, which is agreed but not yet law as of 7 November 2026, strengthens these controls, but PSD2 remains the law in force. Last reviewed 7 November 2026. Further reading: PSD2 Directive (EU) 2015/2366; Berlin Group NextGenPSD2 API framework. Worked example with numbers: a customer banks with one bank and holds a savings account with another, and lets a budgeting app read both accounts, so the app shows a single balance of EUR 5,000 across the two accounts and lists the monthly spending in one place. Before open banking the customer would have given the app the bank login details, a practice called screen scraping, which meant the customer password sat on the app servers and the bank could not tell whether the login came from the customer or the app. With open banking the customer gives consent through the bank, the app receives a token that lets it read the accounts, and the customer can withdraw that consent at any time, so the password never leaves the bank. Failure and recovery: open banking fails when consent expires, when the third party loses its licence, or when the bank API is unavailable. If consent expires, the app must ask the customer to approve again, and it cannot read the accounts until that happens. If the third party loses its licence, the bank must block its access immediately, and the customer must be told why the app stopped working. If the API is down, the app must show a clear message, not a blank screen, and must retry later, because a customer who sees only an error will assume the app is broken and delete it. The recovery for each failure is a clear message and a route to fix it, because a failure that cannot be explained cannot be fixed. For a business analyst, product owner or subject matter expert, the open banking requirement must state the consent model, what the customer approves, how long it lasts, and how it is withdrawn, and must state that PSD2 is the law in force while PSD3 and the Payment Services Regulation are agreed but not yet law. The requirement must also state that the bank cannot block a licensed provider, that access is free of charge for the provider, and that the bank must check the provider licence on every call. The test pack must include a consent that expires, a provider that loses its licence, and an API that is unavailable, because each case exercises a different part of the consent model. Source: PSD2; European Banking Authority; last reviewed 7 November 2026.