The EU Wallet is a customer-onboarding unlock for banks, PSPs, insurers and fintechs.
Under eIDAS 2.0 Article 5f, every regulated EU financial-services provider is legally required to accept the EU Digital Identity Wallet as a customer identity by December 2027. That deadline is closer than it looks — getting the verifier stack right, plus the KYC pipeline, the SCA hooks and the DORA-compliant audit trail, is a project that starts eighteen months out, not eighteen weeks. This is what our platform ships for the finance sector today.
What ships today
OID4VP verifier
OpenID Foundation OID4VP-1.0-FINAL + HAIP-1.0-FINAL alpha conformance passed. See evidence.
OIDC provider
Sign in with EU Wallet on top of standard OIDC. PSD2-compatible SCA hooks via RFC 7523 JWT-bearer.
OpenID4VCI issuer
Issue account-holder attestations, LEI-linked business credentials, KYC-checkpoint proofs to customer wallets.
LOTL trust check
Live pull of the EU List of Trusted Lists so PID x5c chains verify against notified issuers only.
Verifier audit log
Every presentation, every claim disclosed, every reject reason — CSV-exportable for DORA operational-resilience audits.
Aloaha in-house
No eudi-lib-* SDK in the tree. CISO can audit the EUDI protocol layer line by line. Proof of work.
Use cases
Retail-bank customer onboarding
Customer taps Sign in with EU Wallet in your app, presents PID (given_name, family_name, birth_date, country, address). DCQL query returns just what your KYC policy requires — not the whole PID. Verifier logs the presentation to the audit trail with a signed timestamp. Downstream KYC processor gets a cryptographically-signed claim set instead of a photo-of-passport upload.
PSP Strong Customer Authentication
PSD2 SCA transaction binding: the wallet signs the transaction amount + payee (dynamic linking per RTS Article 5). The signed VP presentation carries the transaction_data as an unforgeable proof-of-consent. Our verifier validates the SD-JWT, checks the KB-JWT holder binding, and returns the signed authorisation to your payment rail.
Insurance quote + bind
Insurer requests DOB, address, driving-licence claims from the wallet; verifier presents a single consent screen; policy issuance runs on cryptographically-signed identity instead of self-declared form fields. Fraud rate drops. Underwriting time collapses.
Compliance angles you can point your CISO / DPO at
- eIDAS 2.0 Article 5f — corporate acceptance mandate from Dec 2027 for regulated private-sector RPs (Article 5f-corporate).
- DORA (Regulation 2022/2554) — identity provider is a critical ICT service; audit trail + incident reporting + third-party risk register apply. Our audit-log export is designed for DORA reporting.
- NIS2 (Directive 2022/2555) — essential-entity obligations for financial services include identity infrastructure. Multi-tenant isolation, tenant-scoped audit trails, and per-tenant crypto keys are documented on the sovereign SBC page.
- PSD2 SCA (RTS 2018/389) — dynamic linking supported through signed transaction_data in the VP presentation.
- GDPR — the wallet presents claims (not full PID) per DCQL query; data minimisation is enforced at protocol level, not retrofitted at application level.
Why Aloaha for finance
Every EUDI-protocol layer is written by the Aloaha Limited team on Malta — no eudi-lib-*, no third-party EUDI SDK in the dependency tree. Generic infrastructure libraries (JWT/JWS, HTTP, .NET BCL crypto primitives) are widely-used open-source components; the EUDI-protocol layer itself is 100% Aloaha-written. Your CISO gets an EUDI stack under a single legal entity, on our own release cadence — not gated on a consortium’s next SDK version. Deployed as isolated per-tenant IIS sites with tenant-scoped keys, audit trails and configuration.