Digital euro — should your bank build or buy?

Most technology decisions at a bank start with a business case. This one does not, and getting that wrong is the most expensive mistake available here.

Start from the two facts that define the problem:

• 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.

Mandatory to offer. No fee income from the basic service. There is no revenue line to model, no adoption curve that changes the answer, no growth story that justifies a bigger team.

This is not a product decision. It is a cost-minimisation problem with a compliance deadline attached. Every serious question that follows is downstream of that.

What "build" actually means#

Teams routinely scope this as an API integration. It is not. Here is the honest list of what a distributing PSP owns:

• Access management — user registration and lifecycle management.
• Aliases — registration and management, strictly 1:1 with the account.
• Switching — supporting a user moving to another PSP while keeping the same account identifier. Including emergency switching, using the technical proof, when the Eurosystem declares a PSP has failed.
• Liquidity — funding and defunding, 24 hours a day, every calendar day of the year, including the case where the non-digital euro account sits at a different PSP.
• Waterfall mechanics — including the post-settlement waterfall step, because a single pre-settlement check cannot catch concurrent incoming payments.
• Combined transactions — payment with funding or defunding, as one operation.
• A front end — your app or web pages.
• Certification, testing and onboarding — a phase with a duration, not a formality.
• Reporting — an obligation that outlives the build.

And the part nobody costs: absorbing specification churn. Rulebook v0.91 is explicitly a draft. Sections are unfinished — the functioning and enforcement of the holding limit among them. Offline specifications are expected in future versions. Every revision between now and launch is rework you pay for.

What "buy" actually means#

PSPs may outsource digital euro development and operations to a technical service provider (TSP).

And then the line that never moves: the PSP retains regulatory responsibility.

Read that as the load-bearing sentence of this entire article. You can outsource the code, the running, the on-call rota and the certification effort. You cannot outsource being the regulated entity. If your TSP gets it wrong, your regulator does not call your TSP.

This reframes vendor selection completely. The question is not "can they build it?" Several can. The questions are:

• Can I supervise them — do I have visibility into what they actually do?
• Can I audit them, and evidence it to my regulator on demand?
• What happens if they fail? Prolonged disruption or data loss at a PSP is a scenario the scheme explicitly contemplates — the Eurosystem can declare an emergency situation. Where does that leave you?
• Am I one of many clients, or the experiment?

The trade-off, honestly#

	Build in-house	Use a TSP
Fits when	You have a real payments engineering team and the digital euro is strategic to you	The digital euro is an obligation you want met at the lowest sane cost
Specification churn	You absorb every rulebook revision alone	The provider absorbs it once, across all clients
Certification	Your problem, first time, no prior attempts	Done repeatedly by people who have done it before
Cost shape	Large fixed cost, mostly people, mostly permanent	Recurring fee, contractually bounded
Regulatory responsibility	Yours	Still yours — this never transfers
Control	Total	Bounded by the contract and their roadmap
Main risk	Cost and schedule against a moving draft	Vendor dependency, and whether you can genuinely supervise them

The argument for building#

It is not nothing, and anyone selling you a TSP who says otherwise is selling.

You may already have the capability. The technology is not exotic — JSON REST APIs, an ISO 20022 data dictionary, Berlin Group patterns, CPACE for NFC. If you have done PSD2 work, you have done a harder version of the unfamiliar parts. There is no skills chasm.

The specifications are public. The pilot's technical documentation is on the ECB website, including back-end API specifications in YAML. Nobody has privileged access to the contract.

Strategy may demand it. If digital euro services are where you intend to differentiate — value- added services on top of the free basic service — owning the stack has an argument.

The argument for buying#

The economics are unusual. Mandatory plus free means the build competes for budget against projects that generate revenue, forever. It will lose that argument every year, which is exactly how you end up with an under-resourced compliance system — the worst of both outcomes.

Churn is amortised. A TSP absorbs each rulebook revision once and spreads it. You absorb it once, alone, for one institution.

Certification is a repeat game. Their second certification is cheaper than your first. So is their tenth.

Capacity is the real constraint. Every credit institution in the euro area needs an integration in roughly the same window, drawing on the same small pool of people who have done this before. Building means competing for those people precisely when everyone else is.

A decision framework#

Four questions, in order:

1. Are you a credit institution? If no, you have a real business case — evaluate it as one. If yes, continue.

2. Do you have a payments engineering team that has shipped and certified against a scheme before? Not "developers". Not "we did a PSD2 project with a consultancy". If no, buying is probably right, and the rest of this is confirmation.

3. Is the digital euro strategic, or is it compliance? Be honest. Almost everyone answers "strategic" in the meeting and "compliance" in the budget. The budget is telling the truth.

4. Can you supervise a TSP properly? If you cannot audit and evidence a provider to your regulator, buying does not remove your risk — it hides it, which is worse.

The thing to actually do now#

Whatever you decide, decide now and build later.

Rulebook v0.91 is a draft. Writing code against it today is writing code twice. But the build-vs-buy call has the longest lead time of anything on your plate — procurement, due diligence, contracting and integration planning are measured in quarters, not sprints — and it gets more expensive the later you make it.

The institutions that handle this well will not be the ones that started coding earliest. They will be the ones that decided earliest and built once, against a specification that had stopped moving.

You have roughly until the rulebook stabilises to make a decision in a calm market. After that, every institution that deferred is in the market at the same time.