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.

The person who gets pulled into every serious incidents, knows which service is actually failing just looking at the dashboards, or who can SSH at 2am and somehow stabilises the system before leadership and stakeholders wake up.

Most organisations aim to build resilient systems, while they actually reward the resilient engineer.

Hero-driven reliability

Some systems are not reliable because they are well-designed, but because one person refuses to let them fail. That person knows the edge cases not in any documentation, possess a mental model of production system that exists nowhere else, and get paged more often as they're the only one who can interpret the incident.

In a regulated industry like fintech, this is alarming; not just operationally, but also regulatory. A system whose resilience depends on one person's availability or attention is not an operationally stable system.

What happens to the team around the hero?

Teams with permanent hero-on-demand eventually lose their investigative capabilities and depth. And it will not happen at once, or immediately, but by small decisions that each would make sense and reasonable at the time.

Someone starts to defer to the hero before fully investigating a problem themselves, someone else stops reading the architecture documentation because they know they can just ask.

The hero, to their credit, usually continues helping. They are often generous people who genuinely want to solve problems. But the accumulation of these small deferrals creates something structural: the team quietly replaces documentation with a person.

And then there is another team dynamics, nobody likes talking about - the quiet resentment building up in competent engineers who aren't hero, but know that with better system, planning, and knowledge distribution, the team and the system won't even need the constant saving. This rarely surfaces as direct conflict, but disengagement, and eventually them deciding that the team is not a place for them to grow.

Hero identity - the psychological angle

Not every hero engineer is protecting knowledge intentionally. In fact, it usually starts from a healthy space - they care deeply, move quickly, feel personally responsible for outcomes and genuinely want the system and team to succeed.

The organisation starts rewarding behaviour repeatedly, visibility increases, leadership trust increases, and their opinions start carrying more weight. After some time -

Some engineers stop experiencing it as a burden, and start experiencing it as an identity.

The act of sharing knowledge is treated as an act of sharing status and relevance, because once someone becomes professionally recognised as “the person who saves things,” distributing knowledge can start to feel strangely threatening.

Organisations that do not recognise this dynamic will keep treating it as a knowledge management problem. While it is a status and recognition problem, that cannot be solved with just better documentation tooling.

A version darker than individual psychology

Some companies are structured in a way, that certain systems are genuinely under-resourced for the load they expect to carry. The technical debt is real, but the team is too small. The incident rates are high, and so is the gap between "what the system needs" vs "what the organisation has allocated".

In these environments, heroism is not a cultural problem, but a resource problem. The arrangement works until it doesn't. Because people leave, or just quietly stops caring.

Another major structural issue is creating a prestige system around operational sufferings, because calm systems do not generate enough visibility, or nobody applauds a migration where nothing interesting happened. Once the organisation starts emotionally rewarding firefighting than prevention, it is one step closer to permanent operational chaos.

It's not always a RED FLAG

In an early-stage startups, some degree of heroism is unavoidable, or required. For the first 2-3 years of a company, the systems are immature, teams are small, well-defined processes do not exist yet, and the company is still trying to capture the maximum of market.

In such environments, someone stepping up, to hold things together through force of will, is not dysfunction, it is survival and necessary.

Problem arises when some companies never evolve beyond that stage psychologically, even after they evolve operationally.

And even in mature systems, genuine crises warrant genuine recognition. An extraordinary incident handled with extraordinary effort deserves public acknowledgment. The problem is not the recognition.

The moment heroism shifts from exceptional to expected, from "this person did something remarkable" to "this is how we operate", something has gone wrong.

What mature engineering culture and organisations look like?

Good engineering organisations still recognise heroic effort, and they should.

Real incidents happen, system unexpectedly fails, and these are the moments where intervention is genuinely protects customers and business. But the mature culture treats heroism as -

An exception to defend business, and not a cultural identity.

As system grows, the incidents become less, recovery become predictable, operational knowledge is distributed, and perhaps, more importantly, people preventing or putting out the fire are equally valued as much as the people building the system.

The uncomfortable part

Organisations that want to fix this usually start by talking about documentation, runbooks, on-call rotations etc. While these things definitely matter majorly, there is another question to think about - how does your reward system look like?

If the engineer who quietly prevented three incidents last quarter received less visibility than the engineer who dramatically resolved one, company is already setting up a precedent of behaviour they prefer incentivising.

Some organisations subconsciously prefer heroes because fixing systems structurally is expensive, politically difficult, and invisible.

PSD2 is not just a regulatory document, it shapes what the system is allowed to do, who can touch funds, who can access account data, who authenticates the customer, who owns consent, who keeps evidence, & and who is liable if (or when) something goes wrong.

NOTE: This article is a practical engineering overview, not legal advice. PSD2 remains the current EU framework. PSD3 and PSR reached political agreement in November 2025 but are not yet in force. For actual authorisation decisions, firms should work with counsel and the relevant national competent authority.

Core distinction

"We help users pay merchants." "We connect to bank accounts." "We aggregate balances." "We route payments." "We help businesses collect money." "We provide payment infrastructure."

All these are product-language, and not regulatory activities. The main question is whether the product is doing, or causing another party to do any of the following:

• Accessing payment account information

• Initiating payments from a user's account

• Executing credit transfers or direct debits

• Issuing payment instruments

• Acquiring payment transactions

• Transmitting money

• Issuing or managing electronic money

• Holding or safeguarding customer funds

The closer your product gets to account access, payment initiation, fund movement, or stored value, the more likely you are entering regulated territory.

Three common models of startup

Technical service provider

In this model, the system provides the technology to a regulated entity, but do not provide the regulated payment service itself. Examples like fraud tooling, payment analytics, workflow automation, merchant reporting tools, etc.

To avoid this system to cross into regulated activities, following points are to consider -

• Do we ever enter into possession or control of funds?

• Do we initiate the payment instruction ourselves?

• Do we access user's account data?

• Are we customer-facing as the provider of the payment service?

• Are we makign decisions effecting the payment execution?

From engineering view, such systems are designed as a support layer, not regulated execution layer.

Operating under a licensed partner

It's a common model for startups to launch fast. Instead of becoming authorized directly, the startup/organisation partner with a licensed payment institution, e-money institution, bank, or, a regulated provider. The product operates on top of their licence.

It can reduce the 'time-to-market', but does not remove engineering responsibility, only splits them between partner and product.

Licensed partner usually cares about -

• how the onboarding works

• how customers are authenticated

• what data the product collects

• what funds flow through the system

• how transactions are monitored

• how incidents are reported

• what audit evidence you can produce

• how quickly they can shut down or control risky activity

Even if you don't own the licence, engineering implication is building the system to satisfy the licensed partner's compliance and operational requirements, which typically includes -

• partner approval workflows

• role-based access controls

• event logs and audit trails

• operational dashboards

• transaction monitoring feeds

• reconciliation support

• incident escalation hooks

• customer-data controls

Becoming directly authorised or registered

This is the heavier route, you become the regulated entity yourself: a payment institution, e-money institution, account information service provider, or payment initiation service provider.

This model gives more control, but also more responsibilities. You should be able to demonstrate that business can safely provide the payment service, not just as a legal exercise but an engineering evidence exercise as well.

This includes following -

• secure system architecture

• customer authentication controls

• incident management process

• operational resilience

• data protection controls

• outsourcing controls

• safeguarding arrangements where relevant

• financial crime and fraud controls

• governance and auditability

Registering as PI, EMI, AISP or PISP: The practical difference

You have decided to go with model 3 and register yourself directly as a regulated entity. The exact authorisation or registration model depends on what your product does.

Payment institution (PI)

A Payment Institution provides payment services such as executing payment transactions, money remittance, payment initiation, or acquiring, depending on the permissions granted.

This may be relevant if your product is directly involved in moving money but does not issue e-money or take deposits like a bank.

Engineering focus areas typically include:

• transaction lifecycle management

• reconciliation

• safeguarding support where applicable

• fraud monitoring

• customer authentication

• incident evidence

• operational controls

Electronic money institution (EMI)

An Electronic Money Institution issues electronic money: stored monetary value representing a claim on the issuer. This may be relevant if your product involves customer balances, wallets, stored value, prepaid-style accounts, or funds held for future payment use.

Engineering focus areas typically include:

• wallet ledger design

• balance integrity

• safeguarding evidence

• redemption flows

• transaction history

• reconciliation

• access controls

• customer-money reporting

If the product has anything that looks like a customer balance, stored value, or wallet, you should examine the EMI question very early.

Account information service provider (AISP)

An Account Information Service Provider accesses account information from payment accounts, with the customer's permission.

This may be relevant if the product reads balances, transaction history, income data, or account details from banks to provide insights, dashboards, affordability checks, or aggregation.

Engineering focus areas typically include:

• consent lifecycle

• account-data retrieval

• data minimisation

• refresh logic

• secure storage

• access audit trails

• API error handling

• customer revocation flows

AISP doesn't move the money, but the data is sensitive, and the consent and security model matters.

Payment initiation service provider (PISP)

A Payment Initiation Service Provider initiates a payment from the customer's account held at an ASPSP.

This may be relevant if your product allows a user to pay a merchant, move money, or trigger a bank transfer without using card rails.

Engineering focus areas typically include:

• payment initiation flow

• customer authentication handoff

• payment status tracking

• failure handling

• redirect or decoupled flow support

• reconciliation touchpoints

• fraud and risk controls

• customer messaging

PIS is operationally more sensitive than AIS because a payment instruction is being initiated. That makes status handling, traceability, and failure handling much more important.

Many early-stage products start as PISP-style flows and later evolve into PI-style systems as they take on more control over money movement.

Build vs Partner decision

Before you decide which licence to get for, the question to ask yourself is:

"Under which regulatory model can we build, launch, learn, and control the right things at the right time?"

A direct licence gives control, but takes time and operational maturity. A partner model gives speed, but reduces control and introduces dependency. A technical-service-provider model can work well, but only if the regulated boundary is genuinely outside your product.

The right answer depends on the product, the funding stage, the market, and how close the product is to regulated activity.

Common mistakes to avoid

1. Assuming "we do not hold funds" means PSD2 does not matter: Not holding funds may reduce some obligations, but PSD2 also covers account information and payment initiation services. A product can be in scope without holding customer money.

2. Treating the licence as a legal wrapper: The licence model is not just a document to attach to the product, it changes what the system must prove, log, secure, and control.

3. Choosing a partner without understanding technical dependency: A licensed partner can accelerate launch, but it can also define your product constraints. Their APIs, controls, approval process, incident requirements, and reporting expectations become part of your architecture.

4. Designing the MVP before defining the regulated boundary: A payment MVP is not just a thin product experiment. If it touches payment initiation, funds, account data, or stored value, the MVP already contains regulated-system decisions, without boundary-settings.

5. Assuming PSD3/PSR is a reason to wait: PSD2 is still the current framework. PSD3/PSR matters for future readiness, but startups building now still need to understand PSD2 first.

Before you lock the architecture

These five things should happen before serious architecture decisions are made.

1. Draw the money flow: Show where and how funds move, who controls them, where they settle, and whether your system ever has possession or control of them.

2. Draw the data flow: Show which account data your system access, where it comes from, where and how is it stored, who can see/access it, and how the consent is captured and revoked.

3. Draw the control flow: Show who initiates the payments, who authenticates the customer, who can block the transactions, who monitors fraud, and who handles failure or refunds.

4. Map your regulatory role: Identify whether you are acting as a technical service provider, partner of a licensed firm, AISP/PISP/EMI. If you're not sure, this lack of clarity is itself a finding.

5. Decide what you own now vs later: Be explicit about which regulated capabilities are owned internally and/or by a partner, what are deferred for now, and what capabilities are not applicable. A partner model to permanently outsource the ledger, SCA etc is a different long-term position than the one that defers them temporarily.

This series is focusing on PSD2, PSD3 and PSR; and this primer is a starting point for engineers working around open banking, payment initiations, regulated APIs, and payment systems in EU/UK.

The short version

The simplest way to think about the landscape is this:

• PSD2: Current regulatory framework (in force since 2018)

• PSD3: Next directive, mainly focused on licensing, supervision, and the institutional structure (agreed Nov 2025)

• PSR: Sits alongside PSD3 for day-to-day conduct around access, authentication, & user-protection rules.

This split is one of the first things engineers need to understand.

The detailed landscape: what exists and what’s coming

PSD2: The second payment services directive (2018)

It is the current law, a revised and extended verion for PSD1 with following two major additions:

1. Open Banking: PSD2 enabled licensed third parties to access payment-related information or initiate a payment, subject to customer’s permissions and regulatory controls.

2. Strong Customer Authentication (SCA): PSD2 introduced mandatory multi-factor authentication for electronic payments above certain thresholds, aiming to reduce fraud in card-not-present and online payment contexts.

PSD2 is a directive, meaning each member state transposed it into national law separately, some strictly and some loosely. Post Brexit, UK now operates under its own version (UK PSD2), diverging from EU framework overtime. This inconsistency is one of the primary problems PSD3 + PSR aims to fix.

PSD3 & PSR: A combined package

PSD3 in itself is not a replacement of PSD2, it is narrower in space. It primarily covers licensing and prudential framework for payments and e-money institutions, reauthorisation obligations for existing licensed entities, supervisory arrangements between member states, & integration of EMIs into PI category.

PSR is more significant in a way that it is a regulation, and not a directive; which means it is applied directly and uniformly across all member states. It governs transparency obligations around fees, exchange rates etc, strong customer authentication, standardized API requirements, consent dashboards under open banking, & operational and security requirements for PSPs.

The participation map that matters

Understanding who each participant is, determines which regulatory obligations apply to a given system; because not every player is ‘just a payments company’.

• ASPSP (Account Servicing Payment Service Provider): the institution holding the customer’s payment account. Banks, building societies, EMIs. Must provide dedicated APIs to licensed TPPs with customer consent.

• AISP (Account Information Service Provider): licensed entity that reads account data from one or more ASPSPs with customer consent. Read-only, and cannot initiate payments.

• PISP (Payment Initiation Service Provider): licensed entity that initiates a payment from a customer’s account at an ASPSP. Does not hold funds, only instructs the ASPSP to execute.

• CBPII (Card-Based Payment Instrument Issuer): issues a payment card linked to an account at an ASPSP. Can check available funds before authorising a transaction.

• TPP (Third Party Provider): umbrella term for AISP, PISP, and CBPII. Engineering obligations include NCA registration, SCA implementation, eIDAS certificate management, and consent lifecycle management.

• PI (Payment Institution): non-bank entity licensed to provide payment services. Can hold customer funds for payment purposes.

• EMI (Electronic Money Institution): licensed to issue electronic money. Under PSD3, becomes a sub-category of PI, so existing EMI licences might require re-application during the transition period.

The other frameworks that cannot be ignored

PSD2/3/PSR are only a part of a ‘payment ecosystem’, which usually sits at the intersection of following frameworks -

• PSD2/3/PSR: Payment service rules

• DORA: Digital operational resilience act

• GDPR: General data protection regulation

• eIDAS: Electronic identification, authentication and trust service regulation

Why this series

A technical series for people trying to understand what these frameworks means, in their current and expected legislature. This article is a starting points, that aims to extend into -

• Understanding PSD2 before building

• Building PSD2-compliant systems

• Prepare for PSD3/PSR migration