What PSPs and banks must do about the digital euro

If you work at a bank, a payment institution or an EMI in the euro area, this is the page that matters. The digital euro is not a market you choose to enter. For most of you, it is a requirement arriving on a date you do not control.

Start with the obligation#

Distribution happens only through supervised PSPs. But the crucial fact is narrower than that:

Credit institutions will be obliged to offer basic digital euro services to customers on request once the digital euro launches. Basic services are free for individuals.

Sit with the shape of that for a moment. You must offer it. You cannot charge individuals for the basic service. And you must build or buy an integration to a platform that does not exist in production yet, against a rulebook that is still a draft.

This is not a business case. It is a cost-minimisation problem with a compliance deadline attached. Treating it as a product initiative — with a revenue model, a growth target and a roadmap — is the single most common way to overspend on this.

Work out which role you are#

The scheme splits along user type, and the two roles are different builds:

	Distributing PSP	Acquiring PSP
Serves	Individual users	Business users
Core services	Registration and lifecycle, alias registration, switching, front end	Account management for businesses, acceptance solutions
Acceptance work	—	E-commerce, point-of-sale
Holding limit to handle	The individual's limit, plus waterfall and reverse waterfall	Zero — everything waterfalls through

Most retail banks will be distributing PSPs. Institutions with merchant relationships will also need the acquiring side. They are not the same integration, and scoping both when you need one is a classic and expensive mistake.

What you are actually building#

Strip away the novelty and the distributing PSP's job is recognisable:

• Access management — user registration and lifecycle management for individuals.
• Aliases — the option to register an alias for payments, in a strict 1:1 relationship with the account.
• Switching — supporting a user moving their account to another PSP while keeping the same account identifier.
• Liquidity — funding and defunding, which must work 24 hours a day, every calendar day of the year when moving to and from a non-digital euro payment account.
• The waterfall mechanics — including the subtlety that an additional waterfall step runs after settlement, because a single pre-settlement check cannot catch concurrent incoming payments.
• A front end — your app or web pages, through which users actually consume the service.

What you are not building: settlement, or identifier issuance. Settlement happens on the DESP. Every DEAN is generated by the Eurosystem. You are a distribution and servicing layer over a platform you do not operate.

Certification and testing#

The rulebook carries an annex covering certification, testing and onboarding. That is the gate between "we wrote some code" and "we are a scheme participant".

Plan for it as a phase with its own duration, not as a formality at the end of the build. Every scheme in payments works this way, and every team that treats certification as a rubber stamp discovers otherwise at the worst possible moment.

The build-vs-buy decision#

This is the decision with the longest lead time, so make it first.

PSPs may outsource digital euro development and operations to a TSP — a technical service provider. The line that never moves: the PSP retains regulatory responsibility. You can outsource the work; you cannot outsource being the regulated entity.

	Build in-house	Use a TSP
Best when	You have a payments engineering team and the digital euro is strategic to you	The digital euro is a compliance obligation you want met at low cost
Specification churn	You absorb every rulebook revision yourself	The provider absorbs it across all its clients
Certification	Your problem, first time, alone	Done repeatedly by someone who has done it before
Regulatory responsibility	Yours	Still yours — this does not transfer
Main risk	Cost and schedule against a moving draft	Vendor dependency and your ability to supervise them

The questions that actually decide it are not "can they build it?" They are: can I supervise, audit and evidence this to my regulator? What happens if the provider fails? Am I one of many clients, or the experiment?

We work through this properly in Build vs buy: the digital euro integration decision for small PSPs.

What to do in the next twelve months#

1. Confirm whether the obligation applies to you. Credit institution or not — this changes everything downstream.
2. Decide your role. Distributing, acquiring, or both.
3. Make the build-vs-buy call. Not the build. The call.
4. Read the pilot documentation. It is public, including back-end API specifications in YAML. You do not need to be one of the 36 pilot PSPs to understand what you will implement.
5. Do not build against v0.91. It is a draft with unfinished sections. Code written against it now is code you will write twice.

The institutions that will handle this well are not the ones that start coding earliest. They are the ones that decide earliest and build once.