Banks should test against the standards and trust model first, not the final government app. The useful work is validating issuance, verification, data mapping, user journeys and exception handling in a sandbox so compliance, lending and onboarding logic can be tuned before production dependency appears.
What banks are really testing before a national EUDI Wallet exists
Banks should treat pre-go-live work as a standards and trust-model exercise, not as a test of a particular government app build. The question is whether the bank can reliably issue, verify, map, and consume wallet credentials under the future rules, while keeping onboarding, lending, and fraud decisions stable when the national wallet eventually becomes the dependency.
The most useful test cases are the ones that prove the bank’s own flows survive change: credential issuance and presentation, schema and attribute mapping, consent handling, step-up checks, and fallback paths when the wallet is absent, delayed, or returns unexpected data. That lets teams validate the business journey before production wallets introduce hard coupling.
For a bank, the wallet is part of a wider identity and assurance chain, so the sandbox should exercise the same trust assumptions the production flow will later rely on. NHIMG’s Digital Identity, eID and Identity Wallets Guide is a useful reference point for the wallet model, verifiable credentials, and relying-party preparation, while Identity Proofing and KYC Guide helps anchor the onboarding and assurance side of the flow.
What to validate in the sandbox, not in production
Test the bank-controlled parts first: whether the relying party can accept the credential, interpret the claims correctly, and make the right risk decision from them. If the same customer journey needs to support onboarding, lending, age checks, or account recovery, each branch should be exercised separately because the acceptance logic and failure tolerance are rarely identical.
A good test plan also covers negative and ambiguous cases. That includes missing attributes, expired credentials, mismatched data fields, cancelled consent, partial disclosure, wallet unavailability, and users who abandon or retry the journey. Those are the conditions that usually break production designs, not the happy path.
National rollout timing matters because the legal and technical baseline is already being set at European level. The eIDAS 2.0 EU Digital Identity Framework is the authoritative source for the broader wallet and trust framework, so banks should align test assumptions to the regulation rather than to any one vendor or member-state implementation.
How banks should prepare operationally for wallet dependency
Preparation is mostly about decoupling. The bank should define a clean test interface for wallet-driven identity evidence, so product teams can change logic, mapping, and policy without waiting for the live government app. That includes versioning, error handling, logging, reconciliation of attributes, and a clear decision on when to step up to another verification method.
Testing should also expose where the wallet changes downstream operations. If a process depends on a credential attribute being available in a specific format, or on the wallet completing a flow within a short time, the bank needs to know that before launch. Otherwise the organisation ends up discovering policy gaps during live onboarding, which is the wrong time to find out a trust path is too brittle.
For banks operating under regulated resilience expectations, pre-production testing should mirror the kind of controlled change and dependency testing expected in financial services. The EU Digital Operational Resilience Act (DORA) is relevant because it reinforces disciplined testing of ICT-dependent journeys, including third-party and resilience considerations that affect production readiness.
Risk and Threat Considerations
Wallet integration risk is usually not that the wallet fails once, but that a bank hard-codes assumptions about the first implementation and then inherits that dependency across onboarding, fraud controls, and customer servicing. If the trust model, data schema, or UX changes late, the bank can end up with inconsistent acceptance rules, broken exception handling, and avoidable customer friction.
Failure mechanism: The bank validates against a vendor-specific or incomplete flow instead of the standards-based trust model, so production later breaks where claims, consent, or presentation behaviour differ.
Impact: Onboarding delays, false rejects, manual overrides, and policy drift can follow, and those failures become more expensive once live customers and regulatory commitments depend on the wallet path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Banks must verify external wallet users before accepting credentialed flows. |
| IA-5 — Authenticator Management | Wallet credentials and presentation evidence require lifecycle and handling controls. | |
| CA-2 — Control Assessments | Pre-go-live sandbox testing is an assessment activity for a new identity-dependent flow. | |
| Recommendation — Validate wallet-facing identity proofing and authentication strength before production. Define handling, rotation, and revocation rules for wallet-related authenticators. Assess the wallet flow in a sandbox before depending on it in production. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The topic centers on trust, verification, and access decisions in wallet-enabled journeys. |
| Recommendation — Map wallet acceptance rules to identity, authentication, and access-control requirements. | ||
Practitioner Guidance
What to prioritise: Start with the relying-party decision logic, not the user interface. If the bank cannot explain how each credential attribute affects onboarding or verification, the testing scope is too shallow.
What to verify: Confirm that every wallet-dependent decision has a documented fallback when the wallet is unavailable, incomplete, or returns a different data shape than expected. The best test evidence is a set of recorded journeys that show both success and controlled failure handling.
Practitioner takeaway: The goal is not to prove a specific national wallet works on day one, but to prove the bank’s identity and business logic remain correct when the wallet becomes a new trust dependency.
Related resources from NHI Mgmt Group
- How should teams test LDAP queries before they go live?
- How should security teams test AI chatbots that connect to sensitive data before they go live?
- How should IAM teams test authentication policy changes before they go live?
- How should security teams test AI and LLM applications for real-world attack paths before they go live?