Funding, defunding & holding limits
How an end user’s beta digital euro balance is topped up (funding) or drawn down to a commercial bank account (defunding), and the limit mechanics around it.
Modes
- Online funding/defunding — manual, between a commercial bank money account and the online beta digital euro balance, same pilot-psp.
- Offline funding/defunding — via app, between a commercial bank money account (or the online balance) and the Offline Wallet on-device — see offline-payments.
- Waterfall / reverse waterfall — automatic funding from the linked commercial bank account when a transaction would exceed available online holdings (“waterfall”), and automatic defunding back to the commercial bank account when a holding limit is exceeded because of an incoming payment (“reverse waterfall”). Also applies to business end user balances (waterfall only, no reverse — see end-users).
Checks (sLM-32 – sLM-35 sub-flows, src-end-to-end-process-flows)
Every funding/defunding request runs through: request validation → commercial bank account status/balance check → (for funding) holding-limit and concurrent-transaction check → funds blocked/moved → rejection sent with an error type if any check fails. These sub-flow step IDs are the precise contract to implement against.
Full step-by-step detail for all 6 manual funding/defunding flows (LM-1.1, LM-1.8,
LM-1.9, LM-2.1, LM-2.10, LM-2.11) plus the 5 sLM-* check sub-flows and the
sLM-24 defunding dispatcher (called from access-management-flows’s offboarding
flow) is in liquidity-management-flows, including the matching LM 1.A wireframe and
minimum UX requirements.
Related
dca · end-users · online-and-offline-payments · spec-settlementpsp · spec-settlementdesp · liquidity-management-flows