u/Shufti-Global

There seems to be a lot of talk about the European Digital Identity Wallet as if it will simply replace the way everything works today.

But the reality seems more nuanced. The wallet is voluntary for users, while certain public and private services will need to accept it when the relevant conditions apply.
That raises an interesting question: what actually changes for businesses, platforms, and users once the wallet becomes part of everyday digital services?
What do you think the biggest challenge will be?

Curious how others are looking at it.

There seems to be a lot of talk about the European Digital Identity Wallet as if it will simply replace the way everything works today.

But the reality seems more nuanced. The wallet is voluntary for users, while certain public and private services will need to accept it when the relevant conditions apply.

That raises an interesting question: what actually changes for businesses, platforms, and users once the wallet becomes part of everyday digital services?

What do you think the biggest challenge will be?
Curious how others are looking at it.

Spanish National Police announced this on 11 August, and the effort involved is what makes it worth a read.

He held forged Spanish IDs up to the webcam while a live face swap changed his appearance to match the photo on the document. A static image would not survive that, so he handled the rest by hand. He tilted the documents to imitate hologram movement, and used coloured lights to fake the reflections real security features throw off. Behind it all sat VPNs and over 320 phone lines across 24 devices, most registered to stolen identities.

What he wanted was digital signature certificates, which is the part I keep coming back to. Those carry legal weight. A certificate in someone else's name is a durable instrument, not a one-off account takeover.

38 attempts. More than 30 real people's identities.

And here is how it ended. Mid-call, the deepfake dropped for about a second. His real face appeared. That is what investigators used to identify him.

So nothing detected the method. The tooling just crashed.

Two things I would like other people's read on.

1. If what caught him was the software failing rather than a check working, what happens once the software stops failing? These tools leave fewer artifacts with every release.
2. Does anything short of reading the document chip and proving the camera feed is unmodified actually help here? Everything else seems to assume the image arriving is real, and this attack breaks that assumption before any check runs.

Spanish National Police announced this on 11 August, and the effort involved is what makes it worth a read.

He held forged Spanish IDs up to the webcam while a live face swap changed his appearance to match the photo on the document. A static image would not survive that, so he handled the rest by hand. He tilted the documents to imitate hologram movement, and used coloured lights to fake the reflections real security features throw off. Behind it all sat VPNs and over 320 phone lines across 24 devices, most registered to stolen identities.

What he wanted was digital signature certificates, which is the part I keep coming back to. Those carry legal weight. A certificate in someone else's name is a durable instrument, not a one-off account takeover.

38 attempts. More than 30 real people's identities.

And here is how it ended. Mid-call, the deepfake dropped for about a second. His real face appeared. That is what investigators used to identify him.

So nothing detected the method. The tooling just crashed.

Two things I would like other people's read on.

1. If what caught him was the software failing rather than a check working, what happens once the software stops failing? These tools leave fewer artifacts with every release?
2. Does anything short of reading the document chip and proving the camera feed is unmodified actually help here? Everything else seems to assume the image arriving is real, and this attack breaks that assumption before any check runs?

Spanish National Police announced this on 11 August, and the effort involved is what makes it worth a read.

He held forged Spanish IDs up to the webcam while a live face swap changed his appearance to match the photo on the document. A static image would not survive that, so he handled the rest by hand. He tilted the documents to imitate hologram movement, and used coloured lights to fake the reflections real security features throw off. Behind it all sat VPNs and over 320 phone lines across 24 devices, most registered to stolen identities.

What he wanted was digital signature certificates, which is the part I keep coming back to. Those carry legal weight. A certificate in someone else's name is a durable instrument, not a one-off account takeover.

38 attempts. More than 30 real people's identities.

And here is how it ended. Mid-call, the deepfake dropped for about a second. His real face appeared. That is what investigators used to identify him.

So nothing detected the method. The tooling just crashed.

Two things I would like other people's read on.

1. If what caught him was the software failing rather than a check working, what happens once the software stops failing? These tools leave fewer artifacts with every release.
2. Does anything short of reading the document chip and proving the camera feed is unmodified actually help here? Everything else seems to assume the image arriving is real, and this attack breaks that assumption before any check runs.

There is a small provision in AMLA's customer due diligence standards with an awkward edge to it.
If you onboard EU customers remotely and you do not use face to face verification or an eIDAS compliant method, you will need to justify why neither was available or could reasonably be expected. Nothing about how you verify people changes. You just have to be able to explain the choice.
The problem is that nobody has defined what a good justification looks like. Is a one line note enough? Is it per customer, or once per type of customer? Does "the customer did not have one" count on its own? And what makes a method "not reasonably expected" when a wallet technically exists in that country but almost nobody has one?
The consultation closed in May and the final draft is now with the European Commission, so the shape is fairly settled even though the answers to those questions are not.

Is anyone writing something down already, or is the plan to wait for the final next?

This is a decent example of a rule changing the default without technically banning anything. EU firms used to have a lot of flexibility in how they verified someone remotely. Now, if you use anything other than a government-backed digital ID, you have to justify it and keep that on file.

The problem is what counts as a good enough justification isn't spelled out anywhere yet. Has anyone else dealt with a "prove the negative" type requirement before? How did you build something defensible before the regulator actually clarified the line, and how much did you end up redoing once they did?

The 85% to 95% range turns up in every deck and on every panel, almost always without a source. It ends conversations instead of starting them, and the longer i sit with it the less it seems to say.

Here is what bothers me. The same rate describes two opposite situations.

• 90% in high-volume retail is roughly what you would expect. Enormous volumes of low-risk activity throw off near-matches.
• 90% in a boutique wealth book, fifty clients, every one of them closely known, is a system that isn't working.

Same number. Opposite verdict. So the number on its own tells you nothing.

And honestly, we are not even convinced most of this is a screening problem. Half the time it's a data problem wearing costume. A record missing a date of birth gives the engine nothing to rule a near-match out with, so it just widens the net. One typo entered at onboarding generates alerts for that customer for the rest of their life.

So here's my actual question: has anyone ever heard a peer state what a good false-positive rate looks like for their book? Not the scary industry range, an actual "this is healthy for us, because X" number?

Or are we all just quoting the same unsourced stat back at each other and calling it a benchmark?

The Wallets do not really start appearing until late 2026, and each member state is moving at it's own speed. Some will be ready. Some will not be close. So for a good while you will have a rule that says treat the wallet as the normal way to verify someone, sitting next to a reality where most of your customers cannot use one even if they want to.

The gap is where it gets strange.

If the wallet is the default and everything else is an exception, but 90% of your signups have to be the exceptions because no wallet exists in their country yet, then the exception is the normal thing. Writing a justification for each one is pointless paperwork. Writing nothing feels like ignoring the rule.

It also means the same customer gets treated differently depending on where they live, and that difference will keep shifting as countries switch theirs on at different times. A method that is fine in one market this month becomes the unusual choice in that same market next year.

Two things that seem unsettled:

Does the default only apply once a wallet is actually available to that particular customer, or does it apply from the day the rules bite regardless? Those two reading lead to completely different amounts of work, and the answer changes what you build.

And how do you keep track of which countries are live without turning it into a full time job? Somebody has to notice when a member state goes live, work out what that changes, and update the flow. Is anyone treating this as an ongoing thing to monitor, or is the plan to deal with it when it happens?

Interested in how people are actually planning for the in between period rather than the end state.

Quick background for anyone who has not followed this. The EU is rolling out a digital identity wallet. A citizen holds their verified identity on their phone and hands over only the piece a business actually needs. Large platforms will be required to accept it.

The interesting part is not the wallet itself. It is what happens to everything else.

Today a firm can verify someone however it likes, as long as the method works and it can explain the choice. If the wallet becomes the assumed way to do it, that flips. The wallet becomes the answer, and any other method becomes an exception. Every time you check someone with a document scan or a database lookup instead, you are doing the unusual thing, and you have to be able to say why.

That is a big change in who has to explain themselves.

Two things that seem unresolved:

What does a record like that actually need to contain to hold up? Presumably more than a tick box saying the customer did not have a wallet. But how much more? The reason it was not used, whether the customer was offered it, what you used instead, why that was good enough? Somebody has to decide how much detail is enough, and nobody seems to have said what that looks like.

And how does this work at volume without drowning the team? Plenty of people will not have a wallet for years. Tourists, older customers, anyone outside the EU, anyone whose phone cannot run it. If that is a large share of your signups, writing a fresh justification for each one is not realistic. So is this a per customer record, or one justification per category of customer that you point at? Would that survive an inspection?

For remote onboarding, the draft CDD RTS puts eIDAS electronic ID and qualified trust services first. Everything else, including video checks, is a backup. You can only use the backup if the first option is not available or cannot reasonably be expected.

Neither phrase is explained anywhere in the draft. Article 7 still expects firms to justify using the backup, so you have to meet a standard that nobody has written down.

>Strict reading: not available means the customer's country has no scheme, or the customer has no eID.

>Loose reading: it also covers patchy coverage, customers dropping off halfway, and a flow that just does not work in real life.

Strict is easier to defend on the wording. Loose is what most firms will actually need.

This is not only a bank problem either. The rules cover non-financial obliged entities too, and many of them have no eID setup at all today.

So where do you think supervisors will land, and what are firms writing down now so the reasoning still holds in two years?

Most remote onboarding in the EU today runs on document capture plus a liveness check, and eIDAS-compliant electronic identification tends to be available as an option rather than set as the default. The draft language flips the burden, so the non-eIDAS route becomes the one that needs explaining.

How much of a change that is in practice seems to depend entirely on where a firm already sits. For those offering an eID path alongside document checks, it may come down to documentation. For firms operating in markets where eID coverage is thin, it could mean rebuilding the flow.

Interested in how others are reading it. Where does remote onboarding sit for you today, and does the justification requirement look like a real obstacle or a paperwork one?