NIST SP 1800-42A, the OpenID identity proofing extension, and the FinCEN FAQs

By Juliana Cafik, Identity Standards & Solutions Architect and independent expert contributing to the OpenID Foundation’s eKYC & IDA Working Group.  

On the heels of the National Cybersecurity Center of Excellence Phase 1 results, NIST has published draft SP 1800-42A, a practice guide that documents a tested architecture for accepting mobile driver’s licenses when opening a financial account. The OpenID Foundation’s eKYC & IDA Working Group is specifying an identity proofing extension that informs relying parties, such as financial institutions, how a person’s identity was proofed, and to what assurance level, before a credential was issued. On 8 September 2026, FinCEN, the Federal Reserve, FDIC, NCUA, and OCC published FAQs confirming that a government-issued verifiable digital credential may qualify as documentary identification under the Customer Identification Program rule.

Read together, they are an implementation path: a reference architecture, a way to express the assurance behind the credential, and a compliance position for using it. None of the three is enough on its own. The architecture does not say how the holder was proofed. The proofing claims do not, by themselves, satisfy the CIP rule. The FAQs do not tell an institution how to verify an issuer, or which protocol to present over.

That is the gap the OpenID Foundation took to the Global Digital Collaboration conference in Geneva, 1–3 September 2026. In the session Closing the Assurance Gap: Securing Financial Account Opening with Verifiable Digital Credentials, OpenID Foundation Liaison Juliana Cafik presented alongside Ryan Galluzzo (NIST), Loffie Jordaan (AAMVA), and Mark Verstege (Austroads). The panel was built around the dependency those three developments expose: credentials have to be issued, proofing rigor has to be expressed, and the result has to map to a financial institution’s regulatory obligations. Remove any one and the chain stops short of meeting financial institution requirements.

Why inference is not enough

Know Your Customer rests on a financial institution’s ability to form a reasonable belief that it knows who its customer is. In remote account opening, that belief is inferred from a photograph of an identity document, a selfie, a liveness check, and correlation of personal data. Each is a heuristic, and each is now being compromised.

The figures presented in Geneva were stark: digital document forgeries up 244% year on year (Entrust, 2025); roughly one in five biometric verification attempts were fraudulent, and injection attacks up 40% (Entrust, 2026); US lender exposure to synthetic identities at $3.3 billion as of the end of 2024 (TransUnion). Hardening these controls does not change what they are. No amount of additional checking turns an inference into a proof.

Raising assurance means replacing inference with evidence. A credential issued by a trusted authority, cryptographically signed and bound to the holder’s device, is verified rather than interpreted. Where the issuer also conveys identity assurance claims and values, the institution holds machine-readable evidence of both the identity and the proofing behind it. That is what SP 1800-42A, the identity proofing extension, and the FinCEN FAQs each address from a different point on the chain. The Geneva session set out what we can do to make them actionable.

NIST SP 1800-42A: the reference architecture

Ryan Galluzzo presented the NIST National Cybersecurity Center of Excellence mDL project, whose practice guide NIST SP 1800-42A was published as an initial public draft in March 2026. For financial institutions it is the closest thing available to a reference implementation, an architecture for mobile driver’s license acceptance at account opening, documented and tested rather than proposed.

Phase 1 of the NIST NCCoE project addresses the financial sector: demonstrating a secure, interoperable, and privacy-preserving method for institutions to accept mDLs online using established standards, in order to meet CIP requirements. Developed with 29 partners across 11 interoperability events, it covers reference architecture, threat models, privacy considerations, and trust establishment, built around an “NCCoE Bank” demonstrating how verification would operate at a real institution. The Foundation’s response to the draft sets out the related eKYC work item.

The project identified five constraints on adoption: issuance visibility, standards maturity, regulatory treatment under CIP and AML rules, confidence in wallet security, and protocol consolidation. Three are addressed below. A later phase applies the same architecture to citizen-to-government verification, including work with Login.gov.

AAMVA and Austroads: the trust layer

Loffie Jordaan and Mark Verstege presented the regional trust services that let a bank confirm a credential’s issuer is a licensing authority without bilateral agreements between every bank and every licensing authority.

AAMVA’s mDL Digital Trust Service publishes the VICAL, a signed list of trusted issuer certificate authorities, giving North American relying parties a single source for issuer keys. Participating authorities must also adhere to ISO/IEC 18013-5 and AAMVA’s mDL Implementation Guidelines, giving relying parties additional confidence in - among others - the issuers’ security practices. The takeaway for financial institutions was that mDLs are rolling out at scale and ready to leverage today, with recognition extending beyond North America.

Austroads’ Digital Trust Service is the equivalent for Australia and New Zealand, following a June 2024 agreement by states, territories, and the Commonwealth to adopt ISO 18013 and 23220 for credentials requiring cross-border verification. Nine jurisdictions are issuing to more than 30 million people, with over 90% of license holders expected to have mDL access by mid-2027.

Austroads framed the KYC contribution as three kinds of trust: in the person, through proofing and biometric binding at issuance; in the data, through tamper-evident cryptographic protection; and in the verifier, through accreditation and defined obligations on who may receive what.

A valid credential isn’t a KYC decision

The session’s central technical point was that cryptographic verification is not, by itself, a risk decision. A valid signature proves a credential is genuine and unaltered, and on its own may satisfy CIP requirements. But meeting a requirement isn’t the same as managing the risk. When a bank accepts a credential, it is relying on the identity check the licensing authority performed instead of doing its own. To manage that risk, the bank needs evidence, proof of how rigorously the authority checks the person’s identity and signals it can rely on for fraud analysis. Standards like NIST SP 800-63-4 and ETSI TS 119 461 define that rigor as levels of identity proofing, and there is often more than one acceptable way to reach the same level. In the US, mDLs already carry one useful signal: the REAL ID flag, which shows the holder’s identity was verified to a federal standard. A signal like that works when the bank knows what it means. If the bank understands what REAL ID, or a given assurance level, requires, it can tell whether the identity proofing, and the claims and values the credential conveys, are strong enough to open an everyday checking account or a USD 2 million mortgage.

The eKYC & IDA Working Group addresses this. Its Identity Proofing Extension defines jurisdictional, credential format and protocol independent issuer-asserted claims, proofing level, check method, and presence equivalence, and separates issuer-asserted proofing metadata from verifier-asserted metadata at presentment.

So what should a bank actually do with an mDL? Rather than treating the credential as the answer, or repeating the identity check the licensing authority already did, it can look at two things together: the identity information in the credential, and the details about how strongly that identity was checked. Together, they give the bank what the CIP rule asks for: who the customer is, and the strength of the identity verification behind it. 

The FinCEN FAQs: the regulatory position

One week after the Geneva session, on 8 September 2026, FinCEN and staff of the Federal Reserve, FDIC, NCUA, and OCC published FAQs on verifiable digital credentials under the CIP rule. This is the development that changes what institutions can put into production. It answers the third of the five constraints the NCCoE identified, resolving the documentary status of a government-issued digital credential.

An unexpired, government-issued verifiable digital credential may qualify as documentary “government-issued identification” under 31 C.F.R. § 1020.220. It must evidence nationality or residence and bear a photograph or similar safeguard; the institution must maintain the technology to extract the relevant information; and its written CIP must permit the method. Use is permitted in person, remotely over the internet, or through another digital channel.

Read together, SP 1800-42A and the FAQs are the pivot. The practice guide establishes that mDL acceptance at onboarding is technically tractable, and documents how. The FAQs establish that it is regulatorily permissible, and on what conditions. A US financial institution now has both a reference architecture and a compliance position for the same flow, which was not true a year ago.

With the regional trust services and the proofing claims work alongside them, three of the five constraints the NCCoE identified now have concrete answers. Standards maturity and confidence in wallet security remain active areas.

Continuing the conversation

The profiling work described here continues in the eKYC & IDA Working Group. The contributions most needed now are from relying parties writing CIP procedures, and from issuing authorities already publishing to a trust list.

The OpenID Foundation will continue to engage with the financial sector, issuing authorities, and standards bodies as verifiable credential deployments scale. The Foundation’s work is open to participation through working groups, community groups, and conformance program.

Those wishing to engage are encouraged to get in touch: help@oidf.org.

About the OpenID Foundation

The OpenID Foundation (OIDF) is a global open standards body committed to helping people assert their identity wherever they choose. Founded in 2007, we are a community of technical experts leading the creation of open identity standards that are secure, interoperable, and privacy preserving. The Foundation’s OpenID Connect standard is now used by billions of people across millions of applications. In the last five years, OAuth2 — the FAPI standard for interoperable, high security — has become the standard of choice for Open Banking and Open Data implementations, allowing people to access and share data across entities. Today, the OpenID Foundation’s standards are the connective tissue that enable people to assert their identity and access their data at scale, the scale of the internet, enabling “networks of networks” to interoperate globally. Individuals, companies, governments and non-profits are encouraged to join or participate. Find out more at openid.net.

To learn more about conformance testing and self-certification, please visit the OpenID Foundation’s FAQ section.