Open Banking & Request to Pay / Learning brief
Open-banking payment initiation, explained
Your notes
In simple terms / 01
What this means in plain language
How a payment-initiation service moves money: with the payer's consent, a licensed third party asks the payer's own bank to send a normal credit transfer. Follows one checkout end to end — consent, the bank's strong customer authentication, the debit, and a SEPA credit transfer that settles the way any other transfer does.
A payment initiation service (PIS) lets a licensed third party, with the payer's explicit consent, ask the payer's own bank to make a payment from their account. The third party — a payment initiation service provider, or PISP — never holds the money; it triggers a normal bank transfer that the bank executes after applying strong customer authentication (SCA). In the euro area that transfer is typically a SEPA credit transfer, which then clears and settles the way any other credit transfer does. For a merchant this is a bank-to-bank alternative to cards with no card credentials to store. The steps follow one checkout end to end: the payer consents, the PISP initiates through the bank's access interface, the bank authenticates the payer and debits the account, and a credit transfer carries the money to the payee's bank.
Key takeaways / 03
Three things to remember
- 01
A PISP initiates a payment on the payer's consent but never holds the funds; the payer's bank debits the account and moves the money.
- 02
The bank applies strong customer authentication before it executes, commonly through a redirect to its own app or a decoupled push.
- 03
Settlement is an ordinary SEPA credit transfer, so it clears and settles like any other transfer — no card rails, no chargeback.
Practical use cases / 04
Where you would use this
A merchant offers open-banking payment at checkout to avoid storing card credentials and to receive bank-to-bank funds.
A support agent explains to a payer that the redirect to their bank app is the SCA step, not a separate charge.
A reconciliation team matches an incoming credit transfer to an initiated payment using the PISP's reference.
Worked example / 05
Put the idea into a real situation
(SYNTHETIC / TRAINING ONLY) Maya Chen checks out and chooses to pay from her bank account. Larkpay, a fictional PISP, initiates the payment through Bank Alfa's access interface on Maya's consent. Bank Alfa applies strong customer authentication — Maya approves in her banking app — then debits her account and sends a SEPA credit transfer to Northstar Bank, the payee's bank, which credits the payee once the transfer settles. Larkpay never touched the money; it only asked Bank Alfa to move it. Had Maya not completed the authentication, no debit and no transfer would have occurred, and the checkout would simply show the payment as not made.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
Read the steps as text
- 01MessageMaya consents at the merchant checkoutMaya Chen (payer) → Larkpay (PISP)
Instead of typing card details, Maya chooses to pay by bank. She gives Larkpay consent to start a single payment of EUR 42.50 from her account — consent is for this one payment, not open-ended access.
- 02MessageLarkpay initiates the payment via Bank Alfa's APILarkpay (PISP) → Bank Alfa (ASPSP) · Payment-initiation API request
As a payment initiation service provider, Larkpay does not hold Maya's money. It calls Bank Alfa's open-banking API — the account servicer, or ASPSP — to set up the credit transfer Maya consented to.
- 03ProcessingBank Alfa applies strong customer authenticationBank Alfa (ASPSP)
Bank Alfa, not Larkpay, authenticates Maya. It applies strong customer authentication (SCA) — typically a redirect or app check with two independent factors — because only the account-holding bank may authorise moving her money.
- 04MessageMaya authenticates with her bankMaya Chen (payer) → Bank Alfa (ASPSP)
Maya approves the payment directly with Bank Alfa — in its app or via a redirect — proving it is really her. Larkpay never sees her banking credentials; it only learns whether authentication succeeded.
- 05PostingBank Alfa validates and debits MayaBank Alfa (ASPSP)
With SCA passed, Bank Alfa checks funds and books the EUR 42.50 debit against Maya's account. Her money has left her account, but nothing has yet moved between the banks.
- DR Maya Chen's current account at Bank Alfa — EUR 42.50
- 06MessageBank Alfa sends a SEPA credit transferBank Alfa (ASPSP) → Clearing & settlement mechanism · pacs.008
The initiated payment becomes an ordinary interbank SEPA Instant credit transfer. Bank Alfa submits a pacs.008 to the clearing and settlement mechanism, addressed to Northstar Bank. Open banking started the payment; the SEPA rails carry it.
- 07Clearing obligationThe CSM clears the transferBank Alfa (ASPSP) → Northstar Bank (creditor agent)
The clearing and settlement mechanism validates the pacs.008 and calculates the obligation between the two banks — who owes whom — before any money moves.
Clearing produces an obligation. The banks do not have their money yet — that happens at settlement.
- 08SettlementThe transfer settles between the banksBank Alfa (ASPSP) → Northstar Bank (creditor agent)
The obligation settles across the banks' settlement accounts in central bank money. Only now has EUR 42.50 truly moved from Bank Alfa to Northstar Bank.
- DR Bank Alfa settlement account — EUR 42.50
- CR Northstar Bank settlement account — EUR 42.50
- 09PostingNorthstar Bank credits the merchantNorthstar Bank (creditor agent)
Northstar Bank credits the merchant's account and confirms receipt. The checkout completes: Maya consented, her bank authenticated and debited her, and the money settled over the SEPA rails.
- CR Merchant's account at Northstar Bank — EUR 42.50
Evidence & review / 07
Evidence & review
Payment-initiation services under a PSD2-style open-banking regime settling over SEPA credit transfer; the roles generalise, but access rules and settlement rails differ by jurisdiction.
What this brief simplifies: Shows one consented, single-payment initiation over a SEPA credit transfer. Real deployments add variable recurring payments, bulk files, refunds, and differing bank authentication journeys. Exact SCA thresholds and exemptions live in regulatory technical standards and are not quoted here.
Sources for this brief3
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
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.