FinTech

Digital Euro Integration: What PSPs Must Build Before 2029

Europe’s payment infrastructure is about to add a new rail built and backed by the European Central Bank. The Digital Euro is not a fintech product, a crypto experiment, or another wallet competing for screen time. It is a public monetary infrastructure, designed to sit alongside physical cash and existing digital payments, and mandated to be accepted across the entire eurozone as legal tender.

The ECB makes its launch decision in 2026. A live pilot with real money runs by mid-2027. The earliest full launch window is 2029. For payment service providers operating in the eurozone, the implication is straightforward: most supervised institutions will be required to distribute the Digital Euro once it achieves legal tender status. The question is not whether to integrate. It is whether you will own your Digital Euro integration or negotiate one under deadline pressure.

This article covers what the architecture actually demands, what the pilot tests, where the unresolved technical risks sit, and why 2025 is the right moment to start, not 2027.

Why the Digital Euro Is a Bigger Infrastructure Shift Than PSD2

PSD2 required PSPs to open APIs to third parties and implement Strong Customer Authentication. Complex but bounded: the existing payment infrastructure remained intact, and the obligation was largely additive.

The Digital Euro is structurally different. The rulebook, already at version 0.9 and over 1,000 pages, defines an entirely new intermediary layer. PSPs don’t interface with the Digital Euro as they do with card schemes or open banking APIs. They become the distribution infrastructure for a central bank-issued currency, operating a full wallet and transaction platform on behalf of both individuals and businesses.

PSD2’s obligations were known, vendor tooling existed on day one, and regulatory guidance was iterative. The Digital Euro arrives with a defined architecture, a published (if evolving) rulebook, and, per the assessment of Ville Sointu, Chief Strategist at Nordea, speaking at the MoneyLIVE Summit, no production-ready vendor ecosystem to support implementation.

PSPs Don’t “Accept” the Digital Euro. They Become Intermediaries.

This distinction matters enormously from an engineering perspective. The rulebook defines two distinct intermediary roles:

  • Distributing PSP (Payer PSP): manages the end-user wallet, funding/defunding, onboarding, and the customer-facing Digital Euro experience.
  • Acquiring PSP (Payee PSP): manages merchant acceptance, payment initiation on the payee side, dispute handling, and transaction monitoring.

One institution can hold both roles.

Each intermediary connects via A2A (Application-to-Application) APIs built on ISO 20022 and RESTful architecture to the Digital Euro Service Platform (DESP) run by EuroFIDIS. The Eurosystem domain exposes ten-plus distinct services, all of which intermediaries must integrate:

  • Settlement services (A2A)
  • Alias lookup services (A2A)
  • Onboarding services (A2A)
  • Dispute management services (A2A)
  • Fraud management services (A2A)
  • Offline issuance services (A2A)
  • Reporting services (A2A)
  • Tokenisation services (A2A)
  • Fee calculation services (A2A)
  • U2A interfaces

And within your own intermediary domain, you’re building: transaction initiation, recurring payments, pre-authorization, refund flows, dispute handling, transaction monitoring, liquidity funding and defunding, onboarding, offboarding, user lifecycle management, and portability. For both payer and payee sides.

This is not a compliance checkbox. It is a platform rebuild.

What Building a Digital Euro Stack Actually Requires

A realistic Digital Euro intermediary platform spans multiple engineering domains. This is what needs to be built or deeply adapted:

  • Digital euro wallet orchestration (consumer and merchant-facing)
  • API gateway for Eurosystem A2A services (ISO 20022 / RESTful)
  • Liquidity management engine (funding, defunding, waterfall logic)
  • Transaction lifecycle management (initiation, pre-auth, recurring, refunds)
  • Compliance and monitoring layer (AML, transaction monitoring, reporting)
  • Merchant and consumer onboarding (KYC, alias registration)
  • Offline secure element integration (where Apple allows)
  • Dispute management workflows
  • Tokenisation support for privacy-preserving transactions

Two specific technical features deserve attention because almost no existing coverage addresses them.

Waterfall and Reverse Waterfall: The Logic Nobody Talks About

The Digital Euro introduces two automated balance management mechanisms that PSPs must implement:

  • Reverse Waterfall: When a user’s Digital Euro wallet doesn’t have sufficient balance for a purchase, the system automatically tops it up from their linked commercial bank account in real time.
  • Waterfall: When a user’s Digital Euro balance exceeds the regulatory holding limit, the surplus is automatically swept back to their commercial bank account.

Both mechanisms are mandatory. Both require real-time integration between the Digital Euro wallet infrastructure and the commercial bank account layer. This is complex transaction orchestration logic, not a feature that gets bolted on at the end of an integration project.

One Account Per Individual: The Data Management Challenge

The ECB’s design specifies that each eurozone individual can hold only one Digital Euro account across the entire system, managed through holding limits enforced at the infrastructure level. Business users have no holding limit and may have multiple accounts. This creates a specific data management and identity verification challenge: PSPs must confirm uniqueness at onboarding, coordinate with the Eurosystem’s alias lookup service, and handle portability when users switch providers.

Standards Layer: CPACE, EPC QR, and the Technical Specs That Matter

CTOs evaluating implementation paths should note the standards layer embedded in the rulebook:

  • CPACE: the required standard for proximity payments at POS terminals and ATMs.
  • EPC QR Code: the standard for QR-based payment initiation.
  • ISO 20022: the messaging standard underpinning all A2A communication with the Eurosystem.

Teams that haven’t already scoped implementation against these standards – not just the high-level architecture – are behind on the technical planning.

The Architecture Is Defined. The Vendor Ecosystem Isn’t.

Sointu’s statement at MoneyLIVE was direct: “There are no technology platforms today that can help banks deploy the Digital Euro. If you are a technology vendor, please start developing something immediately.”

He said this in 2025. With a mid-2027 pilot and a 2029 launch window. The rulebook runs to over 1,000 pages, the architecture is specified, and still no production-ready intermediary platform exists.

This creates a specific risk that is easy to underestimate. When PSD2 arrived, institutions scrambled, but vendor tooling was available. When the Digital Euro goes live, PSPs that waited will negotiate vendor contracts from the weakest possible position: compressed timelines, limited alternatives, and zero leverage.

One additional point that cuts against common assumptions: the Digital Euro architecture is entirely blockchain-free. This is a deliberate ECB design decision confirmed in both the rulebook and the Nordea presentation. Institutions that have been mentally filing Digital Euro under “crypto infrastructure” or waiting to see where DLT fits need to recalibrate. The stack is conventional. The specs are public. The clock is running.

The Engineering Timeline Is Already Short

If the ECB confirms the launch decision in 2026, which the European Parliament vote has already anticipated, the engineering timeline looks like this:

DECISION → PILOT → PRODUCTION → LAUNCH

2026: Launch decision confirmed, architecture finalised, pilot scoping opens.

Mid-2027: Live pilot with real money, one distributing and one acquiring PSP per country.

2028: Production readiness window spec stabilisation, final regulatory text, mandatory integration.

2029: Earliest live launch with legal tender status.

That gives most PSPs roughly 24 to 30 months to design, build, test, and integrate a platform they have never built before against a standard that doesn’t yet have a final production spec.

The pilot’s 12-month development window is the practical entry point for institutions serious about owning their integration. Pilot participation serves a longer-term purpose: ensuring engineers have meaningful Eurosystem domain experience well before 2029, regardless of where production readiness stands.

What the Pilot Actually Tests

The Digital Euro pilot, targeting mid-2027, is not a sandbox exercise. The ECB’s central infrastructure will operate exactly as it would in production. Payments will be real commercial bank money recorded on the ECB’s balance sheet, though not yet legally classified as Digital Euro pending final legislation.

Per country: one distributing bank or PSP, one merchant-acquiring PSP or bank. One institution can hold both roles. The pilot tests four payment flows:

  • P2P via alias or access number: the payer transfers to another individual by entering a eurozone identifier in the app; no IBAN is required.
  • P2P via NFC (offline): both devices are offline; settlement occurs instantly on-device at the moment of tap.
  • P2B via NFC SoftPOS: the individual pays the merchant by tapping on a SoftPOS device.
  • P2B via e-/m-commerce: the individual pays online using a unique identifier, authenticating in-app.

The pilot also covers the full customer lifecycle onboarding, account management, the waterfall mechanism and explicitly includes offline capability, which is where the most significant unresolved technical challenge lives.

The Offline Mode Problem Nobody Is Ready to Solve

The Digital Euro’s offline capability is architecturally sound and practically unresolved. When a user downloads money to their offline balance, those funds transfer from their Digital Euro account into the secure element embedded in their device. From that moment, the money exists nowhere else. No account. No ledger entry. Just the chip.

Offline transfers happen device-to-device via NFC. Two phones, both offline, complete a secure value transfer between secure elements without any central infrastructure. If the device is destroyed, the money is gone; there is no recovery mechanism because, by design, no central record of that offline balance exists.

This is correct by design. It is the digital equivalent of handing someone a banknote: genuinely bearer-instrument behaviour. It also introduces liability and recovery frameworks that don’t exist in any current payment method.

The hardware dependency makes this significantly more complex. Android access to secure elements is achievable but technically non-trivial. Apple has not opened the iPhone’s secure element to third parties anywhere in Europe – not for the Digital Euro pilot, not for any scheme. This means a core use case of the Digital Euro cannot currently be implemented on the most widely used smartphone platform in several eurozone markets.

Regulatory intervention against Apple before 2029 is possible. It is not confirmed. Any pilot strategy that depends on iOS offline capability is currently building on an assumption, not a specification.

The Infrastructure Question Behind Europe’s Payment Rail

Europe processes trillions of euros in electronic payments every year. The Digital Euro introduces a parallel public payment rail operated by the Eurosystem and distributed by private PSPs. It doesn’t route through card schemes. It doesn’t use SEPA in the conventional sense. It is a new distribution channel for central bank money, sitting alongside everything that already exists.

For banks and PSPs, this raises a structural question that goes beyond compliance: Will you own the infrastructure layer wallet, transaction orchestration, liquidity logic or become a thin distribution layer on top of someone else’s platform?

Institutions that integrate early and own their stack enter 2029 with distribution leverage and architectural control. Those that arrive in 2028 under deadline pressure will negotiate from the weakest position in the vendor market. And PSPs that fail to recognise what the intermediary model means for their current distribution role risk finding that their customers can bypass them entirely using a central bank-backed wallet.

Three Types of Players in European Payments After 2029

The competitive divergence created by the Digital Euro will not arrive as a single cliff. It will separate institutions over the 2026-2029 window.

Infrastructure-native players

Move early. Participate in or closely track the pilot. Build their intermediary platform against the actual spec, and enter 2029 with a production-grade Digital Euro stack they own. Integration costs are amortised across a longer development cycle. Their engineers understand the Eurosystem A2A quirks. When the spec evolves, they iterate, not rebuild.

Banks and PSPs under deadline pressure

Wait until 2027 or later, discover the vendor market is constrained, and sign contracts under pressure. They accept architectural decisions made by vendors. Their technical debt accumulates from day one of production.

PSPs who lose distribution leverage

Fail to recognise that the Digital Euro intermediary model is not an extension of their existing acquiring or issuing flows. The Digital Euro doesn’t go through card schemes. Distribution leverage has to be rebuilt in the new architecture, not assumed to carry over from the old one.

1,000+

pages in the ECB’s Digital Euro Scheme Rulebook (v0.9) — already published and defining the full intermediary architecture

10+

distinct Eurosystem A2A services every PSP intermediary must integrate — from settlement and onboarding to tokenisation and fraud management

4

payment flows tested in the mid-2027 pilot — P2P alias, P2P NFC offline, P2B SoftPOS, and P2B e-/m-commerce

24–30mo

is the effective engineering window most PSPs have to design, build, test and integrate a platform they have never built before

2029

earliest full launch window — when the Digital Euro achieves legal tender status and distribution becomes mandatory for supervised PSPs

What Kindgeek Is Watching and Building Against

We build payment infrastructure for PSPs, EMIs, neobanks, and digital banks across Europe. We’ve built PSD2-compliant architectures, card-issuing platforms, core banking systems, and multi-rail payment orchestration layers. The Digital Euro integration challenge maps directly onto what we do: A2A connectivity, transaction lifecycle management, liquidity engine design, and compliant onboarding infrastructure.

We’re already working through v0.9 of the ECB rulebook, analysing the API specifications, the CPACE and EPC QR standard requirements, and the waterfall logic, and building flexibility into the payment architectures we deliver to clients now. When v1.0 becomes law, our partners will need to update modules, not rewrite architecture.

The open questions we’re tracking closely:

  • Offline secure element access on iOS: Whether the EU takes regulatory action against Apple’s closed secure element will determine whether the offline use case is viable at scale before 2029.
  • Specification stability: The rulebook is v0.9. Final legislative confirmation will trigger revision cycles. Architectural flexibility for amendments is a core design requirement now, not a post-launch concern.
  • Vendor ecosystem development: The first production-ready middleware to emerge for Digital Euro intermediary integration will define the competitive landscape for 2027-2029.

The Digital Euro is the next PSD2 in terms of regulatory forcing function. Unlike PSD2, the architecture is this detailed this far from launch. That is both a warning and an opportunity, and institutions that move now will negotiate their stack from a position of strength.

Building your Digital Euro integration strategy?

We’ve architected payment infrastructure for 100+ fintech projects across Europe including PSD2-compliant systems, card issuing platforms, and A2A connectivity for regulated payment institutions. If you’re mapping your intermediary scope, evaluating pilot participation, or stress-testing your current stack against the Digital Euro spec, contact us to discuss your technical roadmap.

Contact us

When exactly will PSPs need to be Digital Euro compliant?

The ECB is scheduled to make its launch decision in 2026. A live pilot with real money runs from mid-2027. The earliest full launch window is 2029. Once the Digital Euro achieves legal tender status, most supervised PSPs in the eurozone will be required to distribute it as part of their payment services. Final obligations will be defined by the Digital Euro Regulation, currently moving through the legislative process.

Is the Digital Euro built on blockchain?

No. The Digital Euro architecture is explicitly blockchain-free, a deliberate ECB design decision confirmed in both the rulebook and the Nordea architecture presentation at MoneyLIVE. The system uses conventional A2A API infrastructure (ISO 20022 / RESTful) connecting intermediary domains to the Eurosystem’s central service platform.

What’s the difference between online and offline Digital Euro?

Online Digital Euro operates like a standard account-linked wallet; funds live in an account, and transactions route through Eurosystem infrastructure. Offline Digital Euro downloads a balance to a secure element on the user’s device; that money exists only on the chip, transfers device-to-device via NFC, and cannot be recovered if the device is lost. Apple’s closed secure element in Europe currently blocks iOS implementation of offline capability.

Can PSPs reuse their existing PSD2 open banking infrastructure for Digital Euro?

Partially. The A2A connectivity model shares conceptual similarities with open banking API integration and ISO 20022 expertise transfers. However, the Digital Euro introduces ten-plus new Eurosystem services, mandatory waterfall and reverse waterfall logic, offline issuance requirements, and a full wallet orchestration layer that has no equivalent in PSD2. Treating it as an extension of existing open banking work will produce architectural gaps that are expensive to close post-launch.

Yura Gnatyuk

Tech entrepreneur. Founder and CEO at Kindgeek.

Recent Posts

Automation-First: Why We Write Tests Before Code Ships (and Why It Saves Weeks)

The traditional sequence — develop, then test, then automate — is one of the most…

1 day ago

New CTO’s First 90 Days: Why a Cloud Cost Audit Belongs on Your Checklist

Most onboarding playbooks skip infrastructure economics. In fintech, that oversight costs six figures.

1 week ago

The 900-Endpoint Problem: Why Starting Automation Late Costs You Double

Your fintech platform will outgrow manual testing. The question is whether you'll invest in automation…

2 weeks ago

How to Choose an AI Implementation Partner for Your Bank: A CTO’s Checklist

The AI market for banking will reach $368 billion by 2032. But the majority of…

3 weeks ago

5 AI Use Cases That Actually Drive Revenue in Banking (Not Just Cost Savings)

Industry estimates project the global AI in the BFSI market will grow from roughly $35…

4 weeks ago

Enterprise Chatbots: How They Operate and Serve

Pursuing digital transformation, responding to market pressures, working on customer retention – modern businesses have…

5 months ago