US regulators have answered the question banks were waiting on. The build guide has been sitting there for months.
Earlier this week, the US Treasury's Financial Crimes Enforcement Network (FinCEN) published new guidance jointly with staff from the four agencies that supervise American banks and credit unions: the Federal Reserve, the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA) and the Office of the Comptroller of the Currency (OCC).
The publication states that a bank or credit union may accept a state-issued mobile driver's licence (mDL), or another government-issued verifiable digital credential, to verify a customer's identity when they open an account, whether that happens in a branch, over the internet, or through any other digital channel. It confirms that such a credential counts as government-issued identification under the Customer Identification Program (CIP) Rule, the US requirement that a bank form a reasonable belief it knows who its customer really is.
Five regulators, one document, one clear answer. For anyone who has spent the past few years trying to get a digital credential programme past a compliance committee, this is the sentence you have been waiting for.
Why this was the blocker
Every regulated industry runs into this wall eventually. Financial services just got there first, and hit it hardest, because it is the most heavily supervised of them all.
The technology was never the problem. mDLs are already in millions of wallets across a growing number of US states. They can be verified cryptographically in under a second. Most large banks have looked at them, and many have run internal assessments and reached favourable conclusions.
Then the work stopped, and it usually stopped in the same place.
Picture the conversation. A digital team proposes accepting mDLs at account opening. Risk and compliance ask a reasonable question: when an examiner reviews our CIP programme in two years, how do we explain that we accepted a digital credential held on a mobile device instead of a physical document? The rule described government-issued identification, written back when identification meant a peeling plastic card with a photo you had to squint at. No supervisor had said in writing that a digital equivalent counted.
That uncertainty is expensive in a way that is easy to underestimate. It is not a technical risk that can be tested and closed out. It is an open-ended exposure sitting on a named compliance officer, and no amount of engineering confidence makes it go away.
So institutions waited. Not because they doubted the technology, or the standards, or the feasibility of the build. Not because they disputed the fraud reduction, the drop in manual review cost, or the abandonment rates they would recover at onboarding. They waited because none of that helps you in an examination room if the regulator has never said the credential counts.
Those benefits are exactly what this publication puts back on the table.
What we can learn from the publication
Three elements do the work here.
It is worth being equally clear about what the publication does not do. It does not require anyone to accept digital credentials, and it does not certify any particular implementation as compliant. It changes no existing rules and creates no new supervisory expectations. If a credential shows signs of fraud, a bank still has to weigh that, exactly as it would with a suspicious physical licence.
So this is not permission to skip diligence. It is something more valuable than that. A bank can now build mDL acceptance into its customer journeys, and take the full benefit of what these credentials offer, cryptographic proof of authenticity, tamper-evidence, sharing only the attributes a transaction actually needs, without carrying an unresolved regulatory question through the entire programme. The category question is settled. Everything left is ordinary implementation work.
That implementation work is where digital credential infrastructure matters. Banks need a way to verify credential presentations, evaluate issuer trust, check status, apply policy, integrate results into existing onboarding and fraud systems, and preserve the evidence needed for governance and audit.
But guidance that clears a barrier only helps if there is something ready on the other side of it. It turns out there is, and it has been there for a while.
The other half of the answer
NIST's National Cybersecurity Center of Excellence published a practice guide, SP 1800-42, on using mDLs in financial services. It was built with 29 industry and government collaborators, MATTR among them, and it is not a think piece. It documents a working build: a reference architecture, a threat model, and integration patterns demonstrated end to end across customer onboarding, digital enrolment, and step-up authorisation for high-risk transactions. It uses established standards and off-the-shelf components, and it runs alongside existing banking systems rather than replacing them.
Working through that build with issuers, banks and other providers in the same room made one thing obvious. The hard part was never the cryptography. It was integration, governance, and the unglamorous business of deciding how trust gets configured. All of which is now documented rather than theoretical.
NIST was careful about one thing, though. It mapped its demonstration against CIP requirements, then stated plainly that a technical mapping does not guarantee regulatory acceptance. It could not speak for the regulators.
That is precisely the gap this week's publication fills, and it is why the two documents belong together rather than one after the other. NIST's key findings said mDLs improve existing CIP processes rather than replacing them, which was a technical claim from an engineering exercise. FinCEN and the agencies have now placed those same credentials in the same category as the identification banks already use. After years of the two conversations running past each other, the engineering view and the regulatory view are finally saying the same thing. For anyone who has sat in those meetings, that is a significant moment.
Between them, the two documents settle the questions institutions have been raising for years. The regulators answered whether. NIST answered how. Which leaves only when.
The reason the timing isn't neutral
NIST was blunt that the real constraint is ecosystem maturity, not technology: uneven issuance across states, variation in wallets and presentation protocols, trust frameworks still being built. Underneath it sits the familiar deadlock, where institutions hesitate without adoption and adoption stalls without institutions.
None of that has been solved. But NIST's own key findings are direct on the point, and this is the part worth sitting with. NIST states that institutions should begin assessing adoption early, because integrating credential verification into CIP and authentication is not a project but a multi-year sequence covering architecture, compliance positions, vendor selection and customer experience.
Our experience matches that, repeatedly. Across deployments in Australia, the US, Canada and Asia, the pattern holds: the technical integration is rarely what determines the timeline. Internal alignment, policy sign-off, procurement and customer experience decisions consume most of the calendar. Organisations that treat this as a procurement exercise to begin once the market settles consistently discover they have underestimated the runway by years.
Which means ecosystem maturity is not something you wait for. It is something you position into.
By the time coverage, wallets and trust frameworks settle, the institutions that started earlier will have verification embedded in live flows, internal risk positions agreed, and real operational familiarity. Those beginning at that point will not be adopting into a neutral market. They will be catching up inside one, doing implementation, regulatory interpretation and operational change simultaneously, under competitive pressure, while explaining to their board why a competitor is three years ahead.
Waiting does not remove complexity. It compresses it.
And the case for moving is strengthening on its own. Document upload, selfie matching and knowledge-based checks were designed for a world before synthetic identities, deepfakes and AI-generated documents could be produced cheaply and at scale. Cryptographic verification is not a nicer version of that model. It is a replacement for one that is being outrun. The properties that make it different, verification that is deterministic rather than probabilistic, tampering that invalidates a credential outright, and disclosure limited to what a transaction actually requires, are worth understanding on their own terms.
Where to start
None of the first steps are transformation programmes, and none of them require a budget cycle.
Map where mDLs fit in your existing onboarding and authentication flows, and identify which journeys would benefit first. Get security, risk, compliance and digital into one room and agree a position now that the categorical question is answered, because that alignment is usually the longest lead item. Review what your CIP currently permits and what a policy update would involve. Then run a targeted pilot on a contained journey, with the explicit goal of building operational familiarity rather than proving the technology, which NIST has already done for you.
Here is the uncomfortable part. The technology works. The architecture is published. Five federal regulators have addressed the category in writing. Every external condition institutions cited for waiting has now been met, which means the reasons for standing still are internal, and they are now visible as such.
Your competitors read the same guidance this week. Some of them started moving before it landed. The window where "we're monitoring developments" was a defensible position closed on Tuesday, and in eighteen months the question in your board papers will not be whether digital credentials were the right call. It will be why your institution was late to something the regulators had already cleared.
What remains is a decision about timing, and timing is the one variable still fully within your control. Nobody is going to hand you a better moment than this one. It determines whether you arrive with this ecosystem, help shape how it works, and set the customer expectations others have to meet, or spend years catching up to a standard someone else defined.
If you are working out where your first move sits, our paper From Reverification to Reusable Trust is built for exactly that decision. It covers the workflows where reverification costs banks the most, and gives you a five-step path for choosing your first trust handoff, including the formulas to size the value before you build.
