Payments - Introduction / Learning brief
Open banking, PSD2, and payment APIs
Your notes
In simple terms / 01
What this means in plain language
Open banking lets licensed third parties access bank accounts, with the account holder's consent, through standard interfaces. This article explains PSD2, payment initiation and account information services, and the security rules that govern them.
Open banking is the idea that a bank account holder can permit a licensed company, other than their own bank, to see account data or to start a payment on their behalf. In the European Union, the legal basis for this is PSD2 (the revised Payment Services Directive), which required banks to open access to authorised third-party providers through APIs (application programming interfaces, the technical connections that let software talk to software). Two services matter most. Account information services read balances and transactions so an app can show a combined view or assess affordability. Payment initiation services start a transfer directly from the account, without a card. Every access needs the customer's explicit consent, and payments generally need strong customer authentication. The important shift is from screen-scraping, where an app logged in as the customer, to supervised interfaces with clear permissions.
Complete lesson / 02
Understand the full idea, step by step
If you have ever wondered how a budgeting app shows balances from three different banks on one screen — without working at any of them — you have met open banking. The interesting part is not the app; it is the supervised doorway the banks were required to build.
Open banking — regulated third-party access to payment accounts, with the account holder's consent
Open banking lets licensed third parties either read account data or initiate payments from a customer's bank account — always with the customer's explicit consent, and through interfaces the bank provides for the purpose. In the European Union the framework is PSD2, the revised Payment Services Directive, which created the licensed category of third-party providers (TPPs) and required banks to give them a supervised way in.
What the regulated doorway replaced
Before this framework, some services asked customers for their online-banking passwords and logged in pretending to be them — a practice called screen-scraping. The bank could not tell customer from third party, and the third party held credentials it should never have seen. Under PSD2, banks publish APIs (application programming interfaces) that a TPP calls using its own identity. The bank always knows who is asking and on whose behalf; the customer authenticates directly with the bank; the third party never touches the password. Access became a regulated activity with consent records and audit trails instead of a workaround.
| AISP — account information | PISP — payment initiation | |
|---|---|---|
| What it does | Reads balances and transactions | Instructs the customer's bank to make a transfer |
| Touches the money? | Never — read-only | Initiates it, but never holds it |
| Typical consent | Repeated reads over a defined period, then renewal | One payment: specific amount, specific payee |
| Riya's example | The budgeting app | Pay-by-bank at Asha Traders' checkout |
Riya's pay-by-bank checkout, step by step
- CUSTOMER
Riya chooses "pay by bank" for EUR 84.00 and picks Bank Alfa. The checkout hands her to the payment initiation flow.
- INSTRUCTION
The PISP — the payment initiation service provider — sends Bank Alfa a payment initiation request over the API, identifying itself with its own credentials, never Riya's.
- VALIDATION
Bank Alfa requires strong customer authentication: Riya proves it is her, directly to her bank, with two independent factors — say her banking app plus a fingerprint.
- LEDGER
Bank Alfa accepts the instruction and debits Riya's account EUR 84.00 — an ordinary credit transfer toward Asha Traders' bank begins on the normal rails.
- NOTIFICATION
Bank Alfa returns the initiation status to the PISP, which tells Asha Traders' shop the payment is on its way. The PISP itself held no money at any point.
SCA — strong customer authentication
SCA requires the customer to prove identity with at least two independent factors drawn from three families: something they know (a PIN), something they have (a registered phone), something they are (a fingerprint). It generally applies when payments are initiated and when sensitive account data is accessed, with limited, defined exemptions — and crucially, it happens between the customer and their own bank, not with the third party.
You may be wondering: so the budgeting app can read my account forever once I say yes?
No — consent has edges. It records what may be accessed, by whom, and for how long; information access runs for a defined period before it must be renewed, and Riya can withdraw it at any time, at the app or at Bank Alfa. Payment consent is narrower still: typically one transfer, one amount, one payee. A third party acting outside its recorded consent is not a grey area — it is a breach.
WHAT IF — Riya's authentication fails at checkout, or the app's information consent has expired
What happens: The bank refuses the access or the initiation and returns a clear status. No payment starts; no data flows. Nothing is half-done.
How it is handled: Riya retries the authentication or renews the consent — both are hers to give. For the merchant the PISP shows a failed initiation, and the shop offers another way to pay. A refusal here is the control working, exactly like a declined card.
STRICTLY SPEAKING
Strictly speaking, this lesson describes the PSD2-style model, and the details are jurisdiction-specific: the United Kingdom runs its own open-banking regime, other countries have adopted different frameworks or none, and role names, consent durations, and interface standards vary. The European Union has also proposed successor legislation (PSD3 and an accompanying regulation) to refine these rules. Check the regime that actually governs the accounts in question.
FOR NOW, REMEMBER
- Open banking is regulated third-party access to payment accounts, resting on the customer's explicit consent.
- AISPs read account information; PISPs initiate payments from the customer's own bank account — neither holds the money.
- The third party identifies itself over the bank's API and never handles the customer's credentials; SCA happens between customer and bank.
- Consent is scoped and withdrawable, and the exact rules vary by jurisdiction — PSD2 is the model here, not a universal law.
TRY IT YOURSELF
A new app tells Riya: "To connect your Bank Alfa account, just type your Bank Alfa username and password into this form and we'll log in for you." Under the PSD2-style model, how should Riya read this?
AISPs and PISPs are two members of a larger family of licensed non-banks that move money without being banks. Next: payment institutions, e-money issuers, money transfer operators — and how they reach clearing.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
PSD2 obliged banks to give authorised third-party providers access to accounts through defined interfaces.
- 02
Account information services read data; payment initiation services start transfers directly from the account.
- 03
Access always requires explicit customer consent, and most payments require strong customer authentication.
Practical use cases / 04
Where you would use this
A budgeting app uses account information services to gather balances from several banks into one dashboard.
An online merchant uses a payment initiation service so a shopper can pay by bank transfer instead of by card.
A lender uses consented transaction data to assess affordability faster during a loan application.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional shopper, Lena Ortega, buys goods for EUR 240.00 from an online store. Instead of entering card details, she chooses a payment initiation service. The service redirects her to her bank, where she approves the EUR 240.00 payment using strong customer authentication with two factors. Her consent covers this single payment only, and it expires once the transfer completes. The merchant receives confirmation within 10 seconds, and the shopper's account number is never shared with the store.
Evidence & review / 07
Evidence & review
European Union PSD2 framework; explicitly flagged as jurisdiction-specific, with the UK and others running their own regimes
What this brief simplifies: API technical standards, exemption details, and consent-duration parameters are described qualitatively rather than as numbers. The checkout flow omits the interbank leg, covered in earlier lessons. PSD3 is noted only as proposed successor legislation.
Sources for this brief2
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · TPP access, AIS/PIS definitions, strong customer authentication
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 · Riya checkout scenario; simplified consent and API flow
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.