From KYC to continuous trust: designing for the digital wallet era
Digital wallets may transform KYC from a one-off verification into a continuous relationship, but organisations will need to bet on design to make that shift work.

The Internet has had a big problem since the World Wide Web became mainstream: the ability to trust information shared across parties and domains. And thirty years later what’s looking like a viable solution is about to go mainstream too: verifiable credentials, stored and shared via digital wallets.
This is hardly a prediction: legislation and technical foundations are largely in place. The EU's Data Act and Digital Markets Act, Switzerland's E-ID Act, and a maturing stack of standards covering data models, exchange protocols, hardware and cryptography have moved this from a research problem to an engineering one. Implementation is already well underway: ID Austria has close to 7 million users and already supports credential issuance, verification and qualified electronic signatures; Belgium's itsme, with a similar footprint and over a thousand relying parties, is now open to all EU citizens. The EU mandate requires all member states to provide citizens with a digital identity wallet by the end of 2026. In the UK, GOV.UK Wallet is in active development alongside the Digital Services and Verification Act, which establishes the legal basis for the DVS Trust Framework, an ecosystem of trusted digital identities that are being developed by the private sector.
The infrastructure is arriving on a schedule. What that schedule is missing is the experience layer built on top of it.
The missing experience layer
Most of what's been written about wallet-based interactions so far describes a seamless, frictionless future: tap, share, done. The reality is considerably less plug-and-play, and the gap between the two is where financial services will be judged. This is a complex technology, and understanding how it works requires some shift in mental models. That’s the reason why most conversations about wallet adoption focus on users and whether they'll understand, trust and use a credential on their phone. These are crucial questions, but there’s one question that’s equally pressing, yet seldom asked: are service providers (“relying parties”) ready to provide the journeys that will make understanding, trust and usability an integral part of the experience? Banks, lenders, insurers and payment providers will be on the other end of credential presentations, deciding what to request, when, and what to do with the result. The technical requirement to accept a wallet-based credential is absorbing the majority of the thinking and effort. Designing that interaction in a way that doesn't undermine the trust it's supposed to establish is a different problem, and most organisations haven't started working on it outside of proofs of concept based on linear journeys. This is an even more pressing concern if the prediction of a future dominated by AI agents comes to fruition: the guardrails required to make those interactions compliant and recoverable demand painstaking design and content work.
Complying or redesigning for trust: two different challenges
The EU mandate includes the obligation for service providers to accept digital wallets as a suitable means of identification by the end of 2027. While the UK won't have the same mandate, it's easy to predict that UK providers might decide to adopt the same standards, to minimise the amount of compliance work required – this is the main driver keeping the UK Data Protection Act aligned with GDPR.
As the deadline approaches, there will be the obligatory rush to comply with this new framework, set the systems and processes that will allow service providers to accept the credential format, and move on. The organisations that treat this as the objective will find they've solved a compliance problem while creating an experience one – and, even more frustratingly, missing some great opportunities. Wallet interactions will need to become familiar to be trusted, but sharing data through a wallet will feel different from more traditional ways of submitting claims, and the validation and verification happening in the background need to be made legible through the interface. This is a design challenge, and in financial services, where verification decisions carry material consequences, getting design wrong isn’t an option.
Know Your Customer becomes Enable Your Customer
I mentioned the risk of missed opportunities before: the biggest one will be treating the rollout of new KYC checks as a purely technical exercise, without redesigning the experience around them. Heather Flanagan's recent piece for The Identity Salon makes the case that identity verification is no longer an onboarding event: it transforms the entire architecture, expanding it across the entire customer lifecycle. Organisations that overlook this point will not make full use of the interaction patterns this architecture enables, way beyond simple identity checks.
The risk is to realise only a fraction of the possible value for customers and businesses. Wallets won’t just be there to verify the identity of customers. They will transform the paradigm of verification from a one-way hand-off into a bilateral, ongoing data verification relationship. Institutions can verify claims from customers at any point in the relationship: their income, their address, any eligibility claim. But they can also issue verifiable credentials back: proof of account, consent records, decision history. The question the infrastructure enables is no longer "who are you?" but "what is currently true, for both of us?"
That reframes KYC entirely. Not a one-off threshold event, but an ongoing exchange, one that can underpin more meaningful interactions across all channels. We chased personalisation for decades: here’s the personal data foundation we were missing.
What financial services will be judged on
Data was always the thorniest problem behind failed personalisation projects: inferred, stale, incomplete or siloed. Wallets change the underlying conditions: verified data, subject to consent, flowing in both directions. But this switch will only work if the experience of this exchange is designed well enough to make the users understand what’s happening with each interaction.
That's what digital products and channels will increasingly be judged on: how well they balance friction and visibility across the full customer journey. Not just at onboarding, but across the entire relationship.
There’s a calibration challenge that needs to be solved in both directions. Too little friction at the wrong moment creates risk: a lending decision based on income data backed by a credential that has since been revoked, a fraud attempt that goes undetected because re-verification wasn't triggered. Too much, and you're asking a customer who's held the same address for eight years to prove it again without a clear reason. Each verification will need to be legible to the customer, and proportionate to the risk at stake.
Omnichannel makes this significantly more complex. A verification journey that works on a mobile app behaves differently in a branch or on a call. The friction that's invisible in one context can be a genuine barrier in another, and consistency across channels is where poorly designed experiences can break a journey. This is also where edge cases concentrate: expired credentials, claims that don't match internal records or customers with limited or intermittent digital access. These are the moments where regulations don't provide answers and experience design must lead.
The capability that's currently missing
Most financial institutions manage KYC as a compliance function, with a single rulebook dominating the industry. That model was built for a world where comprehensive verification was only possible at the beginning of a relationship.
But that model doesn’t support the entire customer lifecycle, and it wasn’t built for the bilateral exchange that wallets enable. The capability gap isn't just about knowing when to invoke verification, it's about designing the full exchange: what to request, how to scope it to what's genuinely necessary, how to explain it in a way the customer can act on, what to issue back, and how to handle failure on both sides in a way that preserves the relationship, rather than just creating an audit trail.
That requires bringing different disciplines into a conversation that has historically been owned by compliance and technology. Journey design, content design, interaction and service design all have a structural role, not as a coat of paint applied at the end, but as inputs into how verification moments are conceived from the start.
The organisations that build this capability earliest won't just be better placed for compliance. They'll be the ones that actually deliver on the personalisation promise that wallets make possible, and realise the full value of introducing verifiable credentials, because they'll have the matching experience infrastructure in place.
If your organisation is starting to face these questions, trying to join the dots between compliance and product development, get in touch: we’d be glad to share our thinking on the design affordances and the service patterns we are seeing emerge, and our approach to futures design.