Generic UX requirements

Cross-cutting minimum UX requirements from src-user-journeys-ux-requirements §2 (pages 7–12) — apply to every journey across all three domains (access-management-flows, liquidity-management-flows, transaction-management-flows), unlike the per-journey UX requirement bullets already captured on each of those pages. This is the last piece of that source document not yet digested — everything else in it (journeys, wireframes, per-flow requirements) is already covered by the three domain pages above.

Convention (per source §1 “Content overview”): every rule below is mandatory (“shall”) unless marked [optional]. Only “happy flows” are covered by the journeys; these generic rules, however, do include explicit error-handling requirements.

Sanity check: the source’s own domain/journey table (page 6) was cross-checked against the three domain pages above — all 10 AM journeys, 8 TM journeys, and 1 LM journey listed there match exactly what’s already documented. No missed journey.

Authentication

• Methods and step-count equivalent to other means of payment; multi-modal, including on request a method that doesn’t require a smartphone (unless the payment instrument is the smartphone); EUDI Wallet support if the payment instrument supports it.
• Retry or alternative method offered after a failed attempt; secure fallback (e.g. PIN) if the primary method (e.g. biometrics) is unavailable.
• No logout while actively interacting with the frontend; session-timeout warning with the action needed to stay logged in, and a re-authenticate prompt if it times out anyway.
• Redirected authentication must let the end user choose their default beta digital euro frontend solution.
• New authentication is required on any change to amount or payee — no silent re-use of a prior auth for a modified transaction.
• Personal data (balances, transaction history, identifiers) may never be shown before successful authentication; PSPs must indicate identity verification is required before access.
• Resuming a session on a different device forces re-authentication and an explicit notice that the prior session was auto-logged-out for security.
• Authentication result (success/failure) must always be displayed.

Cross-reference: this is the UX-layer rulebook for the same authentication mechanics detailed at the process level in access-management-flows’s sAM-17.1/.17.2/.17.3/ .17.4 sub-flows and in authentication’s seamless/redirect/proprietary split.

Accessibility, branding and controllability

• Accessibility: full compliance with the European Accessibility Act.
• Branding: full compliance with the (Eurosystem) Style Guide.
• Controllability:
  • End user can pick a default beta digital euro frontend solution.
  • Payer can cancel or step back at any point before authentication starts (a recurring boundary across this whole requirement set — see Transactions below too).
  • [optional] Payee may block payers by DEAN/alias to refuse incoming requests.
  • Logout must be available at any time and must fully terminate the session (re-authentication required afterward).
  • Every button/link must carry a descriptive action label matching what it actually does (example given: “Confirm Payment”, “Cancel”).

Error handling

• State the high-level functional reason where possible (e.g. “Insufficient funds”) and actionable next steps (retry, correct input, contact support).
• Never expose internal system details or technical diagnostics.
• Fraud/risk/security-related errors use neutral, non-specific language — this exact rule already appears independently at the process level (e.g. access-management-flows’s AM 3.B PSP-initiated offboarding requirement) — this generic rule is evidently the source of that specific instance.
• Plain language, no jargon; critical errors displayed prominently (unmissable); retry without re-entering all data where feasible; errors shown as soon as detected.
• [optional] structure: what went wrong → why (if known) → what to do next; visual indicators (red text/icons); keep under 200 characters; skip error codes unless needed for support; sentence case; acknowledge inconvenience.

Feedback, information and positioning

• Notification options equivalent to other means of payment; explicit notice when redirected to another frontend solution.
• Field validation (if performed) happens before allowing the next screen, and must name which field failed. [optional] validate immediately on field completion.
• All information needed for the current step must be on that single screen — no requiring the end user to recall details from a previous screen.
• Language complexity capped at CEFR B2 (upper-intermediate) — a concrete, checkable bar for all copy in the frontend.
• [optional] progress indicator on multi-step flows.
• Tactile feedback where appropriate (e.g. NFC interactions).
• End user can set a nickname/account identifier per account, shown alongside the account or offline device identifier.
• Any displayed amount must show its currency.

Transactions and end user support

• End user can set a default online/offline payment mode; PSP must show which mode a transaction is using before authentication and, where applicable, offer a switch.
• [optional] shortcut to fund if a payment fails on insufficient funds.
• Reverse-waterfall transactions: the amount funded via reverse waterfall must be shown to the payer.
• Origin account must be shown before authentication starts.
• Holding-limit breach warning: if a transaction would push balance over the holding limit, PSP must display the limit and explain the consequence (failed incoming payments, automated defunding) — the UX-level counterpart to the sTM-32/sTM-33 holding-limit checks in transaction-management-flows.
• End user support: help/documentation as accessible as for other payment means; equivalent customer support, offered through multiple accessible channels (visual + auditory); contextual help (tooltips/info icons) specifically for beta-digital-euro-only concepts (DEAN, alias, waterfall, holding limit, etc. — anything without an equivalent in existing payment methods).

Related

access-management-flows · liquidity-management-flows · transaction-management-flows · authentication · funding-and-defunding · pilot-psp · src-user-journeys-ux-requirements