The PSD2 participants map
Who does what (and why it matters in engineering)
A single payment flow, like customer paying at an outlet, can involve five different types of participants; each with different system boundary, security requirements, data obligations, and liability exposure.
Who are you in that flow determines what needs to be build, what regulatory evidence is required, and what is your responsibility when something goes wrong.
The primer introduced the taxonomy, extended to a depth in this article.
Accuracy note: This article covers PSD2 as currently in force. PSD3 and PSR are not yet published in the EU Official Journal.
Ecosystem as a glance
Before we dive into the breakdown of each role, it helps to understand to see how the participants relate to each other in a typical open banking flow.
Each arrow in the diagram represents an engineering interface, like a consent flow, authenticated API call, a payment instruction, or a status callback.
ASPSP (Account Servicing Payment Service Provider)
The institution that holds the customer’s payment account, like banks, licensed payment institutions, etc. Under PSD2, ASPSPs must give licensed TPPs (explained below) access to account data and payment initiation via a dedicated API, & with customer consent.
What ASPSPs must build?
Dedicated TPP-API: separate from customer facing interface, exposed API with equivalent data quality and availability.
SCA & consent handoff: the ASPSP owns the customer authentication, and a TPP cannot perform SCA on its behalf.
Account data exposure: Expose to the TPP via API the balances & transaction history, current and consistent with what customer sees directly at ASPSP’s platform/app.
Fallback & contingency mechanism: a defined path for TPPs when the primary interface is unavailable.
***System boundaries
***ASPSP owns the accounts, the authentication, and the API. What the TPP does with the data and/or the initiated payment is outside it’s boundary.
AISP (Account Information Service Provider)
A licensed TPP that reads the payment account data from ASPSP’s API on customer’s behalf, like personal finance apps, credit decisioning tools, accounting integrations, etc. AISPs never initiate payments or touch the funds.
What AISPs must build?
Consent lifecycle: From grant, scope, expiry to renewal and revocation, all status-flow of consent are handled and should be auditable.
eIDAS certificate management: Secure API connectivity via QWAC for TLS & QSeal for request signing. Certificate provisioning, renewal, revocation & monitoring is all AISPs responsibility.
Data minimisation: Only allowed to retrieve and store data that is necessary for the stated purpose.
90-days re-authentication flow: Requires re-authentication every 90 days for ongoing data access, manage the prompting before expiry, and stop access is customer doesn’t re-authenticate.
Access revocation: If customer revokes consent, data access must stop immediately, and any cached data outside the consented scope must be deleted or quarantined.
***System boundaries
***The AISP owns consent, data retrieval, and storage. The ASPSP owns authentication and the data source.
PISP (Payment Initiation Service Provider)
A licensed TPP that initiates payments from a customer account (without ever holding the funds). PISP creates and sends the payment instruction to ASPSP for execution.
What PISPs must build?
Payment initiation flow: a technical flow involving customer consenting to payment, sending signed payment initiation request to ASPSP, SCA handoff, and status callback handling.
Payment status tracking: after initiation, status is tracked through to completion or failure via status model to handle and communicate received, pending, executed, rejected, and error states clearly to customers.
Redirect & decoupled: different ASPSPs can implement different authentication mode, redirect to ASPSPs interface and/or authenticate via separate channel/device. PISP needs to support both.
Non-repudiation: PISP requests must be signed using a QSeal so the ASPSP can prove the instruction came from a licensed entity. This creates a non-repudiation record, if a payment is disputed, the signed request is the evidence that the PISP sent a legitimate instruction.
***System boundaries
***The PISP owns the initiation request, status tracking, and consent evidence. The ASPSP owns authentication and execution. If the PISP initiates without valid consent, the liability sits with the PISP.
EMI (Electronic Money Institution)
A licensed entity that issues electronic money, i.e., a stored monetary value representating a claim on the issuer. Examples are prepaid wallets, stored value accounts, multi-currency wallets etc.
What EMIs must build?
Double-entry ledger: accurate to the last unit of currency, reconciled in real time, and auditable at any point in history.
Safeguarding evidence: 100% coverage ratio, real time reconciliation of customer balances and producible on demand.
Redemption flow: customers can redeem e-money at par at any time, the flow must be reliable, auditable, and independent of systems that might be failing.
Concurrency control: wallet balances under concurrent load require pessimistic locking or equivalent, race conditions that result in negative balances, phantom credits, or double debits are regulatory failures, not just system defects.
***System boundaries
***The EMI owns the ledger, safeguarding, and balance integrity of the e-money issued. An EMI providing payment initiation additionally owns all PISP obligations.
PI (Payment Institution)
It is a licence category, not a functional role. A non-banking entity, authorised to provide payment services, like executing transactions, money remittances, acquiring, payment initiation etc.
PI licence is a legal wrapper, many PISPs are authorised PIs. What PIs must build depends on the payment service they provide, but there are certain common obligations across all PIs.
What all PIs must build?
Safeguarding: PIs holding customers funds must safeguard them separately than firm’s own funds, in a designated account. The ledger must be able to produce real time reconciliations at any given time.
Incident detection & reporting: PIs must report major operational or security incidents to their NCA. Proper incident report involving detection, classification, evidence packaging needs to be generated within EBA-defined timelines.
Fraud monitoring & reporting: transaction monitoring, fraud classification, and reporting pipelines are regulatory obligations, and statistical fraud data report is annual submission to NCA.
Operational control evidence: access management, change management, business continuity, and outsourcing oversight, should be documented and demonstrable
Expected changes in PSR
Two participant-level changes are confirmed in November 2025 agreement.
For ASPSPs: Performance parity between the TPP interface and the customer-facing interface becomes a hard obligation, not a principle. The fallback to screen scraping is removed. ASPSPs must also provide a customer-facing dashboard of which TPPs have active consent and the ability to revoke them.
For PISPs: The Verification of Payee obligation means PISPs initiating credit transfers must check payee name against IBAN before executing. If a mismatch is detected and not flagged to the customer, the PISP bears liability for any resulting misdirected payment.
