Open banking, PSD2, and payment APIs
How customers let regulated third parties see their accounts or start payments through consented, authenticated bank APIs instead of screen-scraping.
L0 Explain simply
Imagine your bank account is a locked room, and only you hold the key. For years, if you wanted a budgeting app to see what was inside, you handed it your key and let it walk in pretending to be you. That is roughly what screen-scraping did: the app logged in with your password and copied whatever it could see. It worked, but nobody could tell the app apart from you, and your password was now in someone else's hands. Open banking replaces that arrangement. Instead of handing over your key, you tell the bank at the door: this named, licensed helper may look at my balance, or may start one specific payment, and nothing more. The bank checks it is really you asking, lets the helper in through a proper side entrance, and keeps a record. You can withdraw permission whenever you like. The helper never learns your password, and the bank always knows exactly who came in and what they were allowed to do.
L1 Core concepts
Open banking is a way for a customer to let a regulated outside firm either read their account information or start a payment on their behalf, using a controlled connection the bank provides. Two services sit at its heart. Payment initiation lets a trusted app tell your bank to send a payment straight from your account, so an online shop can be paid directly rather than through a card. Account information lets an app read your balances and transactions, for example to show all your accounts in one place. Both rest on your explicit consent: you decide who is allowed, for what, and for how long. The connections use application programming interfaces (APIs), which are agreed, structured doorways that let one system ask another for something in a predictable way. Because the bank builds these doorways, it can identify the outside firm, confirm it is you approving, and log every request. This is safer and clearer than the older habit of sharing your login and letting software copy your screen.
L2 Practitioner view
In the European Union, open banking was mandated by PSD2 (the Second Payment Services Directive). PSD2 requires banks to open access to accounts, with customer consent, to licensed outside firms called third-party providers (TPPs). A TPP comes in two flavours. A payment initiation service provider starts payments from the customer's account. An account information service provider reads account data to offer aggregation or insight. Both must be authorized by a regulator and must connect through the bank's regulated interface, not by impersonating the customer. PSD2 also requires strong customer authentication (SCA): confirming the payer with at least two independent factors, drawn from something they know, something they have, and something they are, so that stealing one factor is not enough. A successor framework, often called PSD3, is under development to refine these rules. Together, licensing, consent, APIs, and SCA turn account access into something a bank can supervise rather than something that happens behind its back.
L3 Technical details
It helps to follow a consent through its life. Say a fictional budgeting app, LedgerLamp, wants to show a customer their balances. As an account information service provider it is a third-party provider (TPP) licensed by a regulator, and it holds a certificate that identifies it to banks. When the customer chooses to connect, the bank redirects them to its own authentication and applies strong customer authentication (SCA), so the customer proves who they are with two independent factors directly to the bank, never to LedgerLamp. The customer then sees exactly what they are granting: read access to two named accounts, for ninety days. The bank records that consent and, from then on, LedgerLamp's requests through the account information application programming interface (API) carry a token tied to it. The bank checks the token, confirms the consent still stands and has not expired, returns only the data in scope, and logs the call. The customer can revoke consent at the bank at any time, after which the token stops working. For payment initiation the shape is the same, except the customer authorizes one specific payment, with its amount and payee, and the bank executes it.
L4 Standards & sources
The rules matter because they set who carries which risk. Under PSD2 (the Second Payment Services Directive) and its regulatory technical standards, the account-servicing bank must provide access to authorized third-party providers (TPPs) and cannot demand a contract as a precondition; access follows from the customer's consent and the firm's licence. Strong customer authentication (SCA) is performed by the bank, so the TPP never handles the customer's credentials, which contains the damage if a TPP is compromised. The standards also allow limited exemptions from SCA, for instance for low-value or certain recurring payments, balancing security against friction. Screen-scraping is discouraged precisely because it blurs these lines: it forces credential sharing and makes the bank unable to tell customer from software. A practical caution for readers: this describes the European framework, and other jurisdictions reach similar ends through different routes, some by regulation and some by market-led standards. The direction of travel is shared, but the legal detail is local, so always check the regime that applies.
Sources & standards1
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · PSD2 and the RTS on strong customer authentication and secure communication
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
Sources for this topic2
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · PSD2 and the RTS on strong customer authentication and secure communication
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The locked-room analogy and the fictional LedgerLamp app compress consent, tokens, and API scopes into a single readable narrative; real implementations vary by bank and jurisdiction.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L4 — Standards & sources. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.