Open Banking and the Digital Euro: how far does the shared standards layer actually reach?

The Digital Euro reuses existing open technical standards, but its trust, liability, and access rules stay separate. UniCredit's Ajay Krishna maps where interoperability really stands.

Ajay, could you please introduce yourself and share more details about your professional background and your role at UniCredit?

I'm a Product Manager in Digital - Open Banking Operations at UniCredit in Munich, with around 15 years in banking IT and payments, most of it in Europe. I have worked both sides of the payments world: hands-on with card rails early on, building card scheme-compliance systems on ISO 8583, and today running UniCredit's Open Banking platform across 9 European markets, which connects licensed third-party providers to the bank. I work alongside engineering, security, compliance, and business stakeholders, and I support our PSD2 regulatory audits from the IT side, providing the technical evidence and drafting the responses.

That combination of card-rail engineering and live Open Banking operations is the lens I bring to PSD3 and the Digital Euro. I look at them as a practitioner who has to make these systems run in production, under real regulatory constraints.

The ECB has said it will reuse existing open technical standards from ECPC, nexo standards, and the Berlin Group for Digital Euro online payments. How far does that actually create interoperability with existing bank and Open Banking infrastructure, and where would a separate integration layer still be needed?

Reusing ISO 20022, Berlin Group API patterns, nexo for the acquiring and POS estate, and the European Card Payment Cooperation's CPACE standard (Common Payment Application Contactless Extension) for contactless acceptance brings familiar message formats, request and response shapes developers already know, and tooling that does not need rebuilding. For online Digital Euro payments specifically, a bank can extend its existing API gateway, developer portal, consent capture, and online SCA orchestration, with no parallel channel to stand up. Two things stay outside that reuse: the privacy and data-minimisation overlay, which limits what a PSP may see about the holder and the transaction in a way PSD2 never did, and offline authorisation, which clears on the device with no server-side SCA call. The surface reuse is real and valuable within those limits.

Standards reuse cannot supply the trust framework underneath. The scheme rulebook, the liability framework for unauthorised and erroneous transactions, settlement finality, and the legal binding to central-bank money are properties of the scheme and the law. A bank does not build them. They exist around it regardless.

The integration layer is the engineering on top: connection to the Eurosystem settlement platform, the holding-limit and waterfall logic against the linked commercial account, and the funding and defunding flows. None of those have an Open Banking analogue.

Open Banking interoperability needs a sharper distinction. The standards being reused here, such as the Berlin Group patterns for balance and transaction-history access, sit at the consumer-app and reconciliation layer. Reusing them lowers integration cost for a distributor's own app and acceptance. They are not a third-party access interface. In practice, for Open Banking interoperability in the AISP and PISP sense, the gap is wider than a missing right: there is no defined TPP access surface, because the reuse targets the app layer.

Put together, the realistic picture is reuse at the online API and SCA surface, a privacy overlay and an offline mode and a money-movement and settlement core that are all net-new, and Open Banking interoperability still waiting on an access decision and an access specification.

PSD3/PSR and eIDAS 2.0 are strengthening identity and authentication, and the Digital Euro is expected to reference similar mechanisms, but the final operating model is still evolving. Is there a realistic path to one authentication event being reusable across a PSD3 Open Banking flow and a Digital Euro transaction, or will each system still need its own authorisation step?

Separate authentication from authorisation.

Authentication, proving identity, can partly converge. With eIDAS 2.0 and the EU Digital Identity Wallet, a single strong credential and one identity ceremony can plausibly be reused across a PSD3 Open Banking flow and a Digital Euro transaction. That holds for the identity factor. It does not extend to the per-payment binding: the dynamically-linked confirmation of amount and payee is itself part of strong customer authentication, and the RTS makes it per-transaction by design, so it recurs on every payment. This depends on the wallet reaching real ubiquity, which is not yet certain, so a bank still needs a conventional SCA fallback for users without it.

Authorisation is a separate matter, action-specific and legally scoped. An account-information consent is a different legal object from authorising a payment against central-bank money under the Digital Euro rulebook. The liability regime, the data in scope, and the revocation rules all differ. PSR, whose text was finalised in April 2026 with the technical standards still to follow, keeps the 180-day re-authentication cycle for account information and adds a mandatory permissions dashboard for managing and revoking access. Even with shared identity, the authorisation steps stay distinct, because the underlying legal objects do not collapse into one.

Therefore, the realistic model is one identity authentication, a fresh transaction authentication per payment, and separate authorisations per rail. It can still feel like a single experience: prove identity once, confirm each payment, and grant scopes granularly. Architecturally that is a common identity and SCA layer, with separate consent and authorisation services per legal basis on top.

Industry groups have raised concerns that Digital Euro rules may limit PISP/AISP participation. If Digital Euro access rights and PSD3 access rights diverge, how should banks design for both without creating two incompatible TPP integration regimes?

It is a fair point to design for. The Digital Euro distribution model is built around supervised intermediaries, and the role of third-party PISPs is now actively contested, while account information access is preserved in the Council text. The Council and Parliament positions, which entered trilogue in July 2026, propose that PISPs hold no automatic right of access to Digital Euro accounts, a line ETPPA is challenging, so third-party access may sit very differently from PSD2 and PSD3 rights.

The way to avoid two incompatible integration tracks is one front door for third parties, independent of which rail sits behind it. Build a single TPP integration model: a shared developer portal, onboarding and eligibility process, consent pattern, and gateway, with each grant a distinct object per legal basis. Then treat Open Banking account access and Digital Euro access as two product capabilities behind that door, each gated by whatever access rights its rail grants. The entitlement layer has to express the full range, including one rail being intermediary-only with no third-party surface at all, rather than assuming both rails expose programmatic access that differs only by scope. The provider integrates once, the divergence in rights lives in the authorisation and eligibility layer, and the infrastructure stays single.

PSD3 assumes ASPSPs expose APIs in a bank-account context, while the Digital Euro introduces central-bank money and a different liability structure. In a Digital Euro flow, how should the ASPSP role be mapped, if at all, and who should own the customer-facing API and consent interface?

Under PSD2 and PSD3 the ASPSP holds the account and exposes the API. In a Digital Euro flow the roles split. The holding itself is a central-bank liability, so the Eurosystem sits at the issuance and settlement layer, effectively the rail operator. The bank or PSP is the distributor: it owns onboarding and KYC, the wallet, holding-limit enforcement, funding and defunding against a linked commercial account, and the customer relationship. That funding account may sit at a different institution than the distributor, so the funding link can itself ride PSD2 rails, an Open Banking dependency inside the Digital Euro.

So, the ASPSP role does not map whole. It maps on the servicing side, intermediary, distributor, and funding-account provider, and the customer-facing API and consent interface should sit there, with the distributing bank or PSP, because it owns the identity, the relationship, the linked account, and the SCA. The ECB owns the scheme and the rulebook; the user experience sits with the distributor.

What does not map automatically is the ASPSP's third-party access obligation. Owning the wallet API does not by itself oblige the distributor to open it to AISPs and PISPs, because whether the Digital Euro grants TPP access at all is still unsettled. So the role maps on servicing and stays open on access.

The trap to avoid is treating the Digital Euro as just another account behind the existing API. It is a distinct product with the bank acting as distributor, reusing the bank's identity and consent surface, while the full ASPSP model does not carry over.

If a customer uses one interface to manage both bank accounts and a Digital Euro wallet, how should consent, re-authentication, and data-sharing boundaries be separated so the experience stays coherent while the legal bases remain distinct?

Separate the experience from the legal basis. The customer can log in once, authenticate identity once, and manage everything from a single dashboard, while the consent records, audit trails, retention rules, and revocation paths stay segregated by legal basis. Each payment still confirms itself, as the rules require.

Concretely, PSD3 already mandates permission dashboards, so use a single dashboard that surfaces both, but make each grant a distinct object with its own scope, expiry, and revocation. An account-information consent runs on the 180-day re-authentication cycle, which PSR keeps while adding dashboard-managed access. A Digital Euro authorisation is per-transaction or per-mandate under its own rules. On data boundaries, the offline Digital Euro is designed to be close to cash, and even online the privacy bar is set high, with the Eurosystem receiving only pseudonymised data it cannot link to individuals. The intermediary does see online Digital Euro transactions, so keeping that data out of Open Banking enrichment or marketing has to be an explicit choice. It should not be pooled with Open Banking account data unless separately and explicitly consented. Tagging a shared store by purpose is too weak to rely on here, because it depends on every downstream process reading the tag correctly. Two legal bases this distinct warrant architectural separation, distinct consent stores and data domains with enforced access controls between them, and a segregation an auditor can verify directly.

A single dashboard and a shared consent pattern give the customer one coherent experience, while the consent stores, data, and legal bases stay segregated underneath.

PSD3 allows banks to charge for premium enriched APIs beyond baseline Open Banking. The Digital Euro caps merchant fees and makes basic services free. If both products are running in the same bank, the Digital Euro undercuts the premium API revenue model that PSD3 is designed to enable. How does a bank price its data and payment services across the two regimes without one cannibalising the other?

First, a precision on the premise. Premium enriched APIs are monetisable today as a commercial layer on top of the free PSD2 and PSD3 baseline. The charging comes from that commercial layer, which PSD3 makes room for.

I would not claim the two never overlap. They do, in payment initiation: a free Digital Euro rail compresses what a bank can charge to initiate a like-for-like payment. But the compression hits only bare initiation, the act of moving the money, which instant A2A under the IPR was already driving toward free. It does not touch the orchestration fee on top: guaranteed payment, one-click, multi-bank reach, conversion.

The layer above the rail stays untouched: enriched data and affordability, identity, guarantees, programmability, reconciliation, and the dispute and protection model. The Digital Euro carries no purchase protection and no enriched data, so that revenue is untouched and arguably grows as A2A volume rises. The merchant fee cap covers the payment only; the services wrapped around it stay chargeable. It removes rail margin that was already eroding and leaves the bank free to charge for protection and data on the same flow. This is the Visa and Mastercard playbook, Mastercard's A2A Protect and Visa A2A Protect, applied at the bank level: own the underwriting, the guarantee and the relationship, and buy the cross-party arbitration framework from the scheme. It holds even if the Digital Euro stays marginal, since the IPR, instant A2A and Wero commoditise the rail regardless.

The practical rule, then: price by risk and by position in the flow, treating the rail itself as the commodity. For the long tail of low-value payments, the free baseline wins, and a wrapper does not belong there. Concentrate the priced wrapper where risk is high and asymmetric: high-value purchases, goods-not-received, marketplaces, B2B with reconciliation pain, where the merchant already pays for protection and will pay explicitly tomorrow.

The honest open question is the attach rate, empirical until volumes are live. A second caveat sits next to it: a regulator will look closely at any wrapper that could act as a charge on the mandated-free basic service under another name. The defensible wrapper prices genuinely separable value, the risk underwriting, the enrichment, the orchestration a customer or merchant can decline while still completing a basic payment. A fee that merely re-prices the basic transfer would not survive that test, so a bank should draw and document that line deliberately before pricing.

The direction is still clear, and the same on both sides of Open Banking. Account data is free under PSD2 and PSD3, yet an affordability decision derived from it is a product a lender will pay for. The value is in the judgement applied to the data. The rail commoditises, and the raw data with it; the protection, enrichment and decisioning layer does not, and a bank should put its pricing power into that layer.

Open Banking TPPs are excluded from the ECB's 2027 Digital Euro pilot. That means AISPs and PISPs won't have tested their integrations before the regulation goes live. From a delivery risk perspective, how does a bank plan for a Digital Euro rollout that's interoperable with its Open Banking stack when the two were never piloted together?

The pilot runs through directly participating PSPs and merchants from the second half of 2027, and the ECB named its 36 pilot providers in July 2026, with development work starting in the third quarter. Those providers are banks, payment processors and fintechs, several of which hold TPP licences in their own right. What the pilot does not cover is third-party AISP or PISP access to Digital Euro accounts, a gap the European Third Party Providers Association (ETPPA) has flagged, so the access layer and the scheme are validated on separate tracks.

Interoperability breaks where the two systems touch, so be specific about those points. There are three areas. The funding coupling is certain: the Digital Euro draws from the linked commercial account through the reverse waterfall and pushes overflow back, a live two-way link to the very account the bank's Open Banking APIs expose. The other two depend on whether TPPs get access at all: the consent and SCA boundary, and whether an AISP can surface the wallet and its holding limit without drift.

Build the funding coupling now. Its external interface, which the ECB's Digital Euro Scheme Rulebook version 0.91 sets out in its implementation specifications along RESTful API patterns, is still draft, so build the part that holds regardless: the bank-side logic for dual-ledger consistency and holding-limit enforcement, with the rulebook as a versioned input. The coupling writes to the same account the live AIS and PIS APIs already serve under PSD2 availability obligations, so the biggest risk is the new flow degrading the live one.

Leave the two contingent areas unbuilt while their consent model is undefined, but keep the architecture open: make the wallet an account object the consent and aggregation layers can reference, with any TPP path pluggable behind a clean boundary. Stage the rollout behind feature flags, internal channels first.

Version 0.91 also adds a delivery risk the Open Banking stack never carried. For person-to-person and ecommerce payments, the bank has to fetch a central risk score from the platform before it can finalise the payment, with point-of-sale exempt. That blocking call sits on the critical path. The rulebook already fixes the fallback direction: past a maximum time limit the bank settles without the score. It leaves only the value of that limit to a later stage, so the coupling can be built now and calibrated once the number lands.

This does not need a big upfront programme. The funding coupling has to be built either way, so doing it now buys time the deadline will not give later, and the tooling around it serves instant payments and other A2A work anyway. The regulation sets the go-live date, so banks cannot wait to see whether adoption takes off before getting ready.

PSD3/PSR requires approximately 6,000 ASPSPs across the EU to offer a dedicated interface that works as quickly and reliably as the bank's own customer-facing interface, with enforceable KPIs from the EBA. If the ECB requires similar performance standards for Digital Euro access, does its infrastructure (which has never been subject to Open Banking SLAs) actually meet that bar?

The premise needs one correction first. The question blends two layers, the ECB's central platform and the distributor's access interface, so it is worth separating them. A parity KPI applies to whoever exposes the interface. Under PSD2 and PSR that is the ASPSP, the bank, and its dedicated interface is held against its own customer channel. For the Digital Euro the interface owner is the distributor, the bank or PSP running the wallet, the consent, and the customer-facing access. That means parity KPIs for Digital Euro access would land where Open Banking KPIs already land today, on the institution running the interface.

That makes the real question whether banks, and especially smaller PSPs, can hold a brand-new product's access interface to a parity bar. Open Banking is the precedent: it took years of regulatory pressure to get uptime, latency, and parity acceptable across thousands of providers. The Digital Euro will have the same distributed edge, the same long tail of smaller PSPs exposing access, so expect a similar multi-year climb concentrated there.

One thing works in its favour. Open Banking fragmented because roughly 6,000 banks each built a bespoke interface. The Digital Euro runs off one central, conformance-tested access specification, which should shorten the integration ramp. What a shared specification cannot standardise is operational performance on each distributor's own infrastructure, so the remaining gap sits in operational maturity, concentrated at smaller PSPs.

Accountability also splits in a way Open Banking never faced. The ECB owns the central platform and the distributor owns the customer experience, so a parity KPI decomposes into platform availability for the Eurosystem and consumer-facing parity for the PSP. The Eurosystem's existing rails, TARGET and TIPS, are robust, but the retail Digital Euro settles on a new central platform, the DESP, which is itself unproven, and that platform sits behind the access layer and is not what a parity KPI measures. The genuinely new problem is end-to-end accountability across two owners, where the central platform can be up while a distributor's app is slow.

That split is cleaner on paper than in practice. When a payment fails, the customer and the national authority turn to the institution holding the direct relationship, the distributor, whatever the underlying fault. The distributor carries the regulatory and reputational exposure even when the central platform caused the incident. A parity KPI would set the performance bar without assigning liability, and the v0.91 draft goes further by leaving its liability regime a placeholder, deferring loss allocation for unauthorised and manipulated payments to a Payment Services Regulation not yet applicable. So the model needs a contractual mechanism that allocates responsibility with the Eurosystem, rather than letting a central-platform failure settle by default on whoever sits closest to the customer.

So, the honest verdict is that this is a distributor problem, the same one banks already face under PSR. The central infrastructure is not the constraint. Readiness will be decided by whether the long tail of PSPs can run a new product's interface to parity, proven only once it is built and measured.

The ECB's Digital Euro Scheme Rulebook version 0.91 puts fraud detection on a shared central platform: a bank must request a risk score from the Eurosystem on every online payment, yet stays free to act on it or set it aside. How should a bank fit that central score into the fraud controls it already runs for Open Banking and cards, and what has to be true for the shared signal to be worth acting on?

This follows the pattern running through the rest of this interview: familiar standards reused at the edge, and a net-new core behind them. The design splits fraud detection from the fraud decision. That split is the right one, and one piece of it is still missing. Detection moves to a shared central component inside the platform, the Risk and Fraud Management service, while the decision stays with each bank. The bank must request a score on every online payment and feed confirmed fraud back daily, and it remains free to act on the score or set it aside. Shared detection sees patterns no single institution can, and local decisioning keeps each bank in control of its own customer.

At the interface layer, fitting it in is mostly extension. The score arrives over a REST call, the messages align to ISO 20022, and the payee-name check reuses the Verification of Payee work already done for SEPA instant payments. A bank routes the central score into its existing fraud-decisioning as one more input alongside its own signals. The operational layer is the real build. A synchronous call on the payment path brings latency budgets, failure handling, and reconciliation of the central score against local controls, and none of that is reuse.

The open question is incentive. A score a bank must fetch but may ignore is worth only as much as its reason to act on it. The bank carries the loss on any payment it approves whether or not it follows the central score, so it will lean on its own controls and treat the shared signal with caution. That is rational, and it also thins the shared network the design depends on. Clarifying who pays does not fix this by itself. What would give the score weight is a mechanism that ties exposure to using it, a safe harbour for acting on the score or a consequence for ignoring it. In v0.91 this sits in a liability section still marked placeholder, with loss allocation deferred to the Payment Services Regulation. This reads off the current draft, and the incentive question would outlast even a shift from encouraged to required, since a duty to consult the score still leaves a bank free to rely on its own controls. Until acting on the shared signal moves the loss, the score stays advisory in practice as well as in the rulebook.

The failure path is set in outline, though the number that governs it is not. For person-to-person and ecommerce the score sits on the critical path: the bank must not settle before the score arrives, unless the response exceeds a maximum time limit, in which case it settles without it. The direction is already fixed, and it fails open. Point-of-sale sits outside this and can settle before the score returns. What the draft leaves open is the value of that time limit, deferred to a later stage, and the detailed interface, left to an annex still to be written. That threshold is not a detail: it sets how long a customer waits on a bad day and trades fraud coverage against payment completion, so a bank can build the fail-open path now but cannot size that tradeoff until the number lands.

About the author

Ajay Krishna is Product Manager in Digital - Open Banking Operations at UniCredit, based in Munich. He runs the bank's Open Banking platform across 9 European markets, which connects licensed third-party providers to customer accounts. His 15 years in banking IT and payments span card-scheme compliance through live PSD2 operations. He writes on the Digital Euro from an operator's perspective, and on what its implementation will require of banks.