On September 8, 2026, FinCEN and the staffs of four federal banking regulators published joint FAQs confirming that banks and credit unions can use government-issued verifiable digital credentials, including state-issued mobile driver's licenses, to verify customer identity under the Customer Identification Program (CIP) Rule. The guidance, issued jointly with the Board of Governors of the Federal Reserve System, the FDIC, the NCUA, and the OCC, is only two pages. But it resolves a question that had kept many compliance teams on the sidelines.
The new FAQs align closely with recommendations SpruceID submitted to Treasury in October 2025, in response to its Request for Comment on Innovative Methods to Detect Illicit Activity Involving Digital Assets. Our submission argued that 31 C.F.R. § 1020.220 is technology-neutral, that VDCs issued by trusted authorities provide higher assurance against forgery than physical documents, and that FinCEN should clarify how both documentary and non-documentary verification methods apply to digital credentials. The joint FAQ addresses both points.
The regulatory answer is now straightforward: an unexpired, government-issued VDC qualifies as "government-issued identification" under § 1020.220(a)(2)(ii)(A)(1), the same provision that has long covered physical driver's licenses and passports. Resolving that question, though, exposes a more practical one. Most banks can scan a physical ID card. Far fewer can cryptographically verify a digital credential, confirm it was issued by the claimed authority, and validate that it remains bound to the device presenting it.
The FAQs start by defining what counts as a verifiable digital credential: a data structure containing information about an individual that is digitally signed by the issuing source, cryptographically bound to a device, and protected by an activation factor such as a PIN, password, or biometric. This definition draws a clear line between VDCs and static data files, photos of IDs, or self-asserted digital profiles. The cryptographic binding and activation factor requirements establish a baseline that mere digital copies of documents do not meet. (For a deeper explanation of how these credentials work, see How Do Verifiable Digital Credentials Work?)
With that definition in place, the FAQs confirm that a government-issued VDC satisfies the CIP Rule's requirement for "government-issued identification evidencing nationality or residence and bearing a photograph or similar safeguard." An mDL issued by a state DMV qualifies. Banks and credit unions can include these credentials in their CIP as a documentary verification method for in-person, remote, and digital channel account opening. The same fraud-awareness obligation that applies to physical IDs carries over: if a VDC shows indications of fraud, the institution must factor that into its assessment of the customer's identity.
The agencies also updated a previously published FAQ to address VDCs as a non-documentary verification method, which opens the door to credentials issued by non-government third parties. For those, the bank bears responsibility for ensuring the issuer "uses the same level of authentication as the bank or credit union itself would use." That distinction between government-issued and non-government VDCs carries different implementation implications, which we return to below.
The FAQs state that the CIP Rule "neither requires nor prohibits reliance on such government-issued VDCs." Read quickly, this might seem like a non-event. Regulators aren't mandating anything. But for financial institutions, permissive clarity issued jointly by five agencies is significant.
Before this guidance, the question of whether a digital credential counted as a "government-issued identification" under the CIP Rule lacked a definitive answer. Individual institutions and their counsel had to interpret the regulation independently. Some concluded that mDLs likely qualified. Others, particularly larger institutions with conservative compliance cultures, treated the ambiguity as a reason to wait. The joint FAQ resolves that interpretive question directly, with a citation to the specific regulatory provision.
The five-agency format reinforces the point. FinCEN issued the FAQs jointly with the staffs of the agencies that supervise the vast majority of U.S. banks and credit unions. A compliance officer at a nationally chartered bank, a state-chartered Fed member, an FDIC-supervised community bank, or a federally insured credit union can now point to the same document. That cross-agency alignment reduces the risk that examiners from different regulators interpret the rule differently during supervision.
Meanwhile, the credential supply is growing. At least 22 U.S. states and territories now operate active mDL programs, issuing credentials that conform to the ISO/IEC 18013-5 standard. The gap between credential availability and financial-sector acceptance was not primarily a technology problem or a consumer demand problem. It was a regulatory certainty problem, and this guidance addresses it. (For broader context on how mDLs fit into financial services identity verification, see How Mobile Driver's Licenses Can Transform Identity Verification in Financial Services.)
Regulatory permission to accept a VDC is necessary for adoption, but it is not sufficient. Banks also need the technical capability to verify one, and the gap between those two things is wider than it might appear.
When a teller accepts a physical driver's license, the verification process is largely visual: check the photo, confirm the license is not expired, look for obvious signs of tampering. For remote account opening, the process is even weaker. Customers photograph their physical ID, upload the image, and sometimes complete a selfie or liveness check. The bank's vendor then applies optical character recognition, image analysis, and biometric comparison to assess the document's authenticity. This pipeline is expensive, slow, and increasingly vulnerable to deepfakes and synthetic identity fraud. A skilled counterfeit can pass visual inspection in a branch, and a manipulated image can fool an upload workflow.
A verifiable digital credential works differently. The credential's integrity depends on a digital signature from the issuing authority, typically a state DMV. Verifying that signature requires the bank's system to obtain and validate the issuer's public key, confirm the credential has not been revoked, check the cryptographic binding between the credential and the device presenting it, and validate the activation factor. Under ISO/IEC 18013-5, these steps happen in milliseconds. But they require software, key management, and trust infrastructure that most banks do not yet operate.
The security improvement is substantial when this infrastructure exists. Instead of interpreting an image of a document, the bank's system receives a cryptographically signed data structure directly from the credential holder's device. The evidence of authenticity is mathematical rather than visual, which is a level of assurance that no amount of image analysis can replicate. For the customer, the experience is faster and less intrusive. For the bank, the confidence level is higher and the compliance foundation is stronger.
But skipping cryptographic verification and simply reading the data fields from a VDC would defeat the purpose entirely. Without that verification, a VDC offers no more assurance than a photograph of an ID card. The FAQ explicitly covers remote and digital channels, which means banks designing digital onboarding flows now have regulatory backing to build VDC verification in. The question is whether they'll invest in doing it properly.
The guidance draws a clear distinction between government-issued and non-government VDCs. For a state-issued mDL, a bank can reasonably rely on the fact that a credential bearing a state DMV's digital signature reflects an established identity proofing event. The trust model is straightforward, and the FAQ confirms these credentials qualify as documentary evidence.
For VDCs issued by non-government third parties, the picture is more complex. Updated FAQ 3 permits their use as a non-documentary verification method, but the bank bears responsibility for ensuring the issuer "uses the same level of authentication as the bank or credit union itself would use," with reference to FFIEC authentication guidance. Evaluating that for every private employer, university, or health system that might issue a credential is a harder problem. The infrastructure to answer it at scale, through machine-readable trust registries, standardized issuer metadata, and published assurance levels, is not yet widely deployed in financial services. Until it matures, most institutions will likely focus their VDC-based KYC on government-issued credentials.
The FAQ removes the interpretive barrier. Several structural questions remain.
SpruceID's RFC response to Treasury recommended measures beyond interpretive guidance: trust registries for the financial sector that recognize approved digital credential issuers, joint FinCEN-NIST pilot programs building on the NCCoE's mDL project to test CIP-compliant verification workflows, recognition of privacy-enhancing technologies like selective disclosure for meeting CDD obligations, and exceptive relief for institutions that adopt accredited credential frameworks. None of these are addressed in the FAQ, but all of them become more tractable now that the documentary-status question is settled.
For individual institutions, the practical next step is evaluating whether their systems can cryptographically verify a VDC, or whether they would simply be reading data fields and losing the security properties that make digital credentials worth accepting in the first place. The institutions that treat this FAQ as a reason to build verification infrastructure, rather than a reason to add mDLs to a checklist, will see the larger benefit.
The full FAQ document is available on FinCEN's website. SpruceID's complete response to Treasury's RFC is available on Regulations.gov.
About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.
