Sector · Financial services

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, and what’s on the roadmap for the six-quarter run-up.

Compliance clock. eIDAS 2.0 Article 5f (large-platform + regulated-sector acceptance): binding from Q4 2026 in phased rollout, mandatory across all in-scope private sector by Dec 2027. PSD3 is following. DORA and NIS2 already apply to your identity infrastructure. Every claim on this page is either shipped today or explicitly labelled roadmap.

What ships today

OID4VP verifier

OpenID Foundation OID4VP-1.0-FINAL + HAIP-1.0-FINAL alpha conformance passed. See evidence.

OIDC provider

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. Roadmap Q3-Q4 2026: full SCA payment flow per EUDI §2.6.4 with initiate → respond → settle → receipt state machine.

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.

Corporate banking (European Business Wallet)

Business onboarding via LPID + Company Attestation + Powers of Representation credentials from the forthcoming European Business Wallet. Directors and authorised signatories present mandate credentials; the bank verifies the delegation chain cryptographically. Roadmap: EUBW verifier-side support parallel with EUDI wallet work; see the roadmap task registered.

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.