Liquidity
What happens if you're paid over your digital euro limit?
The payment still goes through — the excess moves to your linked bank account automatically. How waterfall and reverse waterfall actually work.
On this page
The digital euro has a holding limit. Users will be capped on how much they can hold.
Now ask the obvious question: what happens when someone pays you and it would push you over the cap?
If the answer were "the payment is rejected", the digital euro would be unusable. Imagine a payment method that stops accepting money when you have too much of it. Nobody would touch it.
The answer is not rejection. It is automatic conversion, in both directions — and those two mechanisms are where most of the real engineering in a digital euro integration lives.
The two mechanisms
Waterfall — money flowing out
Waterfall is a functionality that facilitates settlement by automatically converting digital euro exceeding the holding limit into commercial bank money on a linked non-digital euro account nominated by the user.
Someone pays you €500, that would put you over your limit, so the excess lands in your ordinary bank account instead. The payment settles. You do nothing.
Reverse waterfall — money flowing in
Reverse waterfall is the mirror: commercial bank money from the linked account is automatically converted into digital euro when your holdings are not sufficient to execute a payment.
You want to pay €200 and hold €30. The missing €170 is pulled from your linked account and the payment goes through.
Why this pairing is the whole design
Here is the insight worth carrying away:
The holding limit constrains the stock of digital euro you hold. It does not constrain the flow of payments you can make.
A digital euro account can sit at zero and still work perfectly. Money arrives, overflow waterfalls out. Money is needed, reverse waterfall pulls it in. The balance is almost incidental.
That is what makes a holding limit politically possible at all. The limit exists for financial stability — it is the dial governing how much deposit funding could migrate from commercial banks to central bank money. Without waterfalls, that dial would be paid for directly in user experience, every day, by everyone. With them, most users would rarely notice the limit exists.
Nobody knows the number
The holding limit amount has not been decided. The rulebook explicitly leaves its functioning and enforcement to be detailed in later iterations. Any figure quoted today is speculation.
Combined transactions
A payment bundled with one of these liquidity movements is a combined transaction: a digital euro transaction involving payment with funding (reverse waterfall), or payment with defunding (waterfall).
The design decision hiding here is important. It would be possible to model "top up, then pay" as two independent operations that a PSP sequences itself. The scheme does not.
Why that matters: if funding and payment were separate, you would have to handle the case where the top-up succeeds and the payment then fails — leaving the user with a balance they never asked for and a purchase that did not happen. Bundling them into one transaction deletes that entire failure mode.
If you are building the PSP side: do not orchestrate this yourself. The scheme defines the combined operation and the end-to-end flows describe how it settles. Implement the flow. Do not invent your own choreography on top of two primitives.
The concurrency trap
This is the part that will bite you, so read it twice.
Waterfall is not always triggered by the up-front validation check. Consider two incoming payments arriving close together:
- Transaction 1 arrives. The check asks: would this breach the holding limit? No. Waterfall is not triggered.
- Transaction 2 arrives while transaction 1 has not yet settled. The check runs again: would this breach the limit? At this instant, no. But after transaction 1 settles, transaction 2 would.
Neither check individually sees a breach. Together they produce one.
The resolution: an additional waterfall step is performed after settlement to ensure the holding limit holds.
The lesson generalises beyond this one case. A pre-settlement check is a check against the state you can see, and under concurrency the state you can see is not the state that will exist. If your implementation assumes a single validation is sufficient, you have a bug that appears only under load, only sometimes — the worst kind to diagnose in production.
The end-to-end flows in the rulebook annexes are authoritative here. Where the prose and the flows disagree, implement the flows.
The dependency everything rests on
Both mechanisms need a linked non-digital euro account. No linked account, no waterfalls.
And the rules differ sharply by user type:
| Individual | Business | |
|---|---|---|
| Holding limit | An amount, still to be decided | Zero |
| Linked account | Optional | Mandatory |
| Waterfall in practice | Only if a linked account is nominated | Every incoming payment |
| Reverse waterfall | Only with a linked account | Every outgoing payment |
| Number of accounts | One | Unlimited |
For an individual, the linked account is optional — so an individual who never nominates one has no reverse waterfall, and their payments genuinely are capped by their current balance. That user exists, and your UX has to handle them.
For a business, this is not an edge case. It is every transaction. Holding limit of zero plus a mandatory linked account means digital euro never rests in a merchant account — it arrives and waterfalls onward continuously. A merchant with a holding limit of zero could not accept a single payment without a linked account, which is exactly why it is mandatory.
Funding and defunding are the layer underneath
Waterfall and reverse waterfall are automatic, limit-triggered mechanisms. Underneath them sit the ordinary operations:
- Funding — adding digital euro, from a non-digital euro payment account or from cash at an ATM or branch.
- Defunding — the reverse.
Two details worth designing for:
Availability. Funding and defunding to and from a non-digital euro payment account must work 24 hours a day, on all calendar days of the year. No weekends, no cut-offs, no batch windows. Cash routes follow ATM and branch service hours, which is simply physics.
Two PSPs. A funding or defunding operation may involve a different PSP, because the institution providing the digital euro account and the one providing the non-digital euro account need not be the same. Do not assume both legs live inside your own bank.
And keep the trigger types straight — they look similar and are not:
| Trigger | Mechanism |
|---|---|
| User-defined threshold ("keep me above €50") | Ordinary automated funding/defunding — a user preference |
| Holding limit breached | Waterfall / reverse waterfall — scheme mechanics |
Funding and defunding can be manual, or automatic at a pre-defined time, or on a user-defined threshold that is explicitly other than the holding limit.
What this means for your estimate
If you are scoping a digital euro integration and your estimate is dominated by the happy-path payment, your estimate is wrong.
The happy path is a REST call. The work is here:
- Combined transactions, implemented as the scheme defines them rather than as your own sequencing.
- The post-settlement waterfall step, and everything else concurrency does to a limit check.
- 24/7/365 funding and defunding, including the cross-PSP case.
- Two genuinely different rule sets behind one indicator digit in the DEAN.
- A UX for individuals with no linked account.
None of this is exotic. All of it is fiddly, and it is precisely the kind of thing that is underestimated by teams who have read the architecture diagram and not the end-to-end flows.
Sources
Related reading
36 PSPs selected for the digital euro pilot — what it means
On 14 July 2026 the ECB selected 36 PSPs from 57 applications across 19 countries for the digital euro pilot. What it signals — and what it doesn't.
Digital euro — should your bank build or buy?
The digital euro is mandatory for credit institutions and free for individuals. That makes build vs buy a cost problem, not a product decision.