Digital Euro Wiki

liquidity-management-flows

9 min read

Liquidity Management — detailed flows

Step-by-step detail for the Liquidity Management (LM) domain: manual funding and defunding between a beta digital euro account and a commercial bank money account, plus the shared sLM-* check sub-flows. Same treatment as access-management-flows — full coverage of source §2 “Liquidity management” in src-end-to-end-process-flows, step IDs kept traceable to source.

Scope: all of source §2 is covered — 3 funding flows (§2.1), 3 defunding flows (§2.2), and all 5 “Liquidity management sub-flows” (§2.3). Unlike access-management-flows, LM’s flow numbering only goes up to LM-2.11 but individual flow IDs are non-consecutive (LM-1.1, LM-1.8, LM-1.9; LM-2.1, LM-2.10, LM-2.11) — this source document only details 3 funding + 3 defunding scenarios; LM-1.2–.7 and other gaps aren’t defined anywhere in it (same kind of gap as access-management-flows’s sAM-18/21/22/etc. — referenced-but-undetailed IDs are a recurring pattern in this doc, not unique to LM).

Wireframes: only one UX journey exists for this whole domain — LM 1.A, covering all 6 funding/defunding flows generically (“manual transfer” between accounts, direction and channel selected within the flow). Extracted as PNG, raw/ecb-pilot/docs/img/user-journey-ux-requirements/lm-page-NN.png (pages 71–75, 200dpi); the linked page (lm-page-73) is duplicated into wiki/assets/img/user-journey-ux-requirements/ (2026-07-22, same treatment as access-management-flows) so it syncs with the publish mirror. Confirmed by inspecting the wireframe image (not just text) that the “Liquidity settings” screen shown here is the same screen as AM 4.A’s liquidity settings screen in access-management-flows — LM 1.A’s UX requirements text partly repeats AM-4.1.2’s (IBAN, waterfall toggle) because it’s genuinely the same screen, entered from two different journeys, not a text-extraction artifact.

Quick reference

UX journeyUnderlying flowsWireframe
LM 1.A – Manual funding and defunding between accounts or with IBANLM-1.1, LM-1.8, LM-1.9 (funding), LM-2.1, LM-2.10, LM-2.11 (defunding)lm-page-73

Minimum UX requirements (LM 1.A): end user enters a manual transfer amount, choosing origin and destination account (own online/offline holding or linked IBAN); PSP must warn if the transfer would exceed the holding limit; end user can cancel before authentication starts; authentication required before the backend call; confirmation shows the updated balance immediately; liquidity transactions are included in transaction history. (Waterfall/IBAN-display bullets on this journey’s UX page duplicate AM-4.1.2’s — same screen, see note above.)

Wireframe screens: Liquidity settings (balance, linked IBAN, waterfall toggle) → Manual transfer (amount, From/To account picker) → Authentication → Confirmation (amount

  • direction) → updated Liquidity settings (new balance).

§2.1 — Funding

LM-1.1 — Online manual funding from commercial bank money account (same pilot PSP)

Actors: Individual end user, Pilot PSP, DESP. 12 steps, LM-1.1.01–.12.

  1. End user selects online funding, specifies amount + source commercial bank money account — capped below the holding limit (.01).
  2. Authentication [sAM-17.1] (.02), funding checks [sLM-34] (.03).
  3. PSP sends the funding instruction to DESP (.04); DESP runs settlement funding online [sTM-56] (.05); reject path releases the blocked commercial-bank funds and notifies the end user (.06–.08).
  4. Success: PSP confirms to the end user (.09–.10), debits the commercial bank money account (.11) and increases the online digital euro balance (.12).

LM-1.8 — Offline manual funding from commercial bank money account via app (same pilot PSP)

Actors: Individual end user, App, Offline secure application, Pilot PSP - distribution component, Pilot PSP - backend, DESP. 27 steps, LM-1.8.01–.27. Precondition: device must be online (the funding request itself needs connectivity even though the resulting balance is offline).

  1. Opens app, authentication [sAM-17.1] (.01–.02); selects offline funding + amount
    • source account (.03).
  2. App → offline secure application: sends funding data (.04), runs online integrity check and transaction counter reset [sTM-14] (.05), submits the funding request (.06).
  3. Offline secure application checks the new balance against the holding limit (.07–.08); reject path (.09–.11); else sends the request on to the pilot PSP’s distribution component, which forwards it to the PSP backend (.12–.13).
  4. Backend runs funding commercial bank money checks [sLM-32] (.14, reject path .15) → distribution component sends the offline funding instruction to DESP (.16), which runs settlement funding offline [sTM-58] (.17); reject path unlocks the commercial-bank funds (.18–.21).
  5. Success propagates back through distribution component to the offline secure application, which increases the offline balance (.22–.23); app confirms to the end user (.24–.25); backend debits the commercial bank money account (.26) and registers the operation for AML/CFT monitoring (.27).

LM-1.9 — Offline manual funding from own online beta digital euro account via app

Actors: Individual end user, App, Offline secure application, Pilot PSP - distribution component, Pilot PSP - backend, DESP. 30 steps, LM-1.9.01–.30. (Source note: the raw table repeats step label .29 for both “Funding completed” and “Register operation for AML/CFT monitoring” — the flow diagram uses .29/.30 correctly, used below.) Distinct from LM-1.8: the source account here is the end user’s own online balance, not a commercial bank account, so this flow internally chains a defunding-online followed by a funding-offline:

  1. Steps .01–.13 mirror LM-1.8’s app/offline-secure-application setup (open app, authenticate, select amount + online-account source, integrity check, holding-limit check, reject path) but sends the request to distribution → backend instead of doing a commercial-bank check.
  2. Backend runs defunding checks [sLM-35] (.14, reject path .15), sends an online defunding instruction to DESP (.16), which runs settlement defunding online [sTM-57] (.17); reject path restores the online balance and notifies the end user (.18–.21).
  3. On success, backend receives the online defunding confirmation (.22) and the distribution component sends an offline funding instruction to DESP (.23), which runs settlement funding offline [sTM-58] (.24) and settlement funding online [sTM-56] (.25, redeeming what was just defunded into the offline settlement).
  4. Confirmation propagates back; offline secure application increases the offline balance (.26–.27); app confirms to the end user (.28–.29); backend registers the operation for AML/CFT monitoring (.30).

§2.2 — Defunding

LM-2.1 — Online manual defunding to commercial bank money account (same pilot PSP)

Actors: Individual end user, Pilot PSP, DESP. 11 steps, LM-2.1.01–.11. Mirror image of LM-1.1:

  1. Selects online defunding + amount + destination account (.01); authentication [sAM-17.1] (.02); defunding checks [sLM-35] (.03).
  2. PSP sends the defunding request to DESP (.04); DESP runs settlement defunding online [sTM-57] (.05); reject path restores the online balance and notifies the end user (.06–.08).
  3. Success: confirms to the end user (.09–.10), PSP credits the commercial bank money account (.11, business rule LM-040-003).

LM-2.10 — Offline manual defunding to commercial bank money account via app (same pilot PSP)

Actors: same as LM-1.8. 26 steps, LM-2.10.01–.26. Mirror image of LM-1.8:

  1. Opens app, auth [sAM-17.1] (.01–.02); selects offline defunding + amount + destination account (.03).
  2. Sends defunding data → offline secure application (.04); online integrity check and transaction counter reset [sTM-14] (.05); submits the request (.06).
  3. Offline secure application checks sufficient offline balance (.07–.08, reject path .09–.11, distinct from LM-1.8’s holding-limit check — this is a balance-floor check, not a ceiling check); blocks the offline amount and forwards to distribution → backend (.12–.13).
  4. Backend runs defunding commercial bank money checks [sLM-33] (.14), sends the validated request back to distribution (.15), which sends the offline defunding instruction to DESP (.16); DESP runs settlement defunding offline [sTM-59] (.17); reject path releases the blocked offline amount (.18–.20).
  5. Success: offline secure application decreases the offline balance (.21–.22); app confirms (.23–.24); backend credits the commercial bank money account (.25, business rule LM-040-003) and registers for AML/CFT monitoring (.26).

LM-2.11 — Offline manual defunding to own online beta digital euro account via app

Actors: same as LM-1.9. 31 steps, LM-2.11.01–.31. Mirror image of LM-1.9 — chains a defunding-offline followed by a funding-online:

  1. Steps .01–.13 mirror LM-2.10’s setup (open app, authenticate, select amount + destination = own online account, integrity check, sufficient-offline-balance check, reject path, block offline amount) but the distribution component validates the request itself (.13–.14) rather than routing through a commercial-bank check.
  2. Distribution component sends the offline defunding instruction to DESP (.15), which runs settlement defunding offline [sTM-59] (.16); reject path releases the blocked offline amount (.17–.18).
  3. On success, backend runs funding checks [sLM-34] (.20) and sends an online funding instruction to DESP (.22), which runs settlement funding online [sTM-56] (.23) and settlement funding offline [sTM-58] (.24, symmetric to LM-1.9’s double-settlement pattern).
  4. Confirmation propagates back; offline secure application decreases the offline balance (.27); app confirms (.28–.29); backend increases the online balance (.30) and registers for AML/CFT monitoring (.31).

§2.3 — Liquidity management sub-flows

The reusable [sLM-*] subprocesses called from the funding/defunding flows above (and, for sLM-24, from AM-3.1 offboarding).

sLM-32 — Funding commercial bank money checks sub-flow

6 steps, sLM-32.01–.06. Called from LM-1.8: validate the funding request (.01–.02, reject path); check the commercial bank money account’s status and balance (.03–.04, reject path .05); if sufficient, block the funds on that account (.06).

sLM-33 — Defunding commercial bank money checks sub-flow

5 steps, sLM-33.01–.05. Called from LM-2.10: validate the defunding request (.01–.02, reject path); check the commercial bank money account’s status only — no balance check, since this is a destination for incoming funds, not a source (.03–.04, reject path .05).

sLM-34 — Funding checks sub-flow

10 steps, sLM-34.01–.10. Called from LM-1.1 and LM-2.11: validate the request (.01–.02, reject path); check digital euro account status/balance (.03, business rules LM-010-001, LM-011-001/.002); check against the holding limit and for a concurrent transaction in flight (.04–.06, reject path — rejected wholesale, never partially executed); check the commercial bank money account status/balance (.07–.08, reject path .09); block the funds (.10).

sLM-35 — Defunding checks sub-flow

9 steps, sLM-35.01–.09. Called from LM-1.9 and LM-2.1: validate the request (.01–.02, reject path .03); check digital euro status/balance (.04, business rule TM-000-007) — reject if beta digital euro balance is insufficient (.05); check the commercial bank money account status (.06–.07, reject path .08); decrease the online digital euro balance (.09).

sLM-24 — Defunding sub-flow

6 steps, sLM-24.01–.06. The dispatcher referenced by AM-3.1 offboarding’s “checks destination account status” step — routes to whichever concrete defunding flow applies:

  1. If the end user holds offline beta digital euro (.01), requests defunding and amount (.02), then runs LM-2.10 starting from its 4th step (.03).
  2. If the end user (also) holds online beta digital euro (.04), requests defunding and amount (.05), then runs LM-2.1 starting from its 2nd step (.06).

The LM 1.A journey also inherits generic-ux-requirements (authentication, error handling, feedback/positioning, accessibility — applies across all domains).

funding-and-defunding · access-management-flows · online-and-offline-payments · pilot-psp · desp · dca · generic-ux-requirements · src-end-to-end-process-flows · src-user-journeys-ux-requirements

Graph View

Backlinks