The September 2026 FinCEN FAQ confirmed that government-issued verifiable digital credentials (VDCs), including mobile driver's licenses, qualify as documentary identification under the CIP rule. Banks can now accept them for customer identification at account opening, whether in a branch, online, or through a mobile app.
But accepting a credential and verifying one are different operations. Most banks can scan a physical driver's license and run it through an identity verification vendor. Far fewer can perform the cryptographic verification that gives a digital credential its security value. The gap between regulatory permission and implementation readiness is where the real work begins.
A physical ID is verified primarily by visual inspection: checking the photograph, examining security features, and confirming that the document has not visibly been tampered with. The CIP rule has long permitted this as documentary verification.
A verifiable digital credential operates on a fundamentally different trust model. An mDL conforming to ISO/IEC 18013-5 is a digitally signed data structure. It contains identity attributes (name, date of birth, address, photograph) that have been cryptographically signed by the issuing DMV. The credential is bound to the holder's device through hardware-backed keys and protected by an activation factor such as a biometric or PIN.
As we have previously explained, verifying this credential properly means confirming four things: the digital signature is valid and was produced by the claimed issuing authority, the credential has not been revoked, it is being presented from the device it was bound to, and the holder has satisfied the activation factor.
Skip any of these steps, and the bank is not getting more assurance than it would from a photograph of a physical ID.
The first verification step, validating the digital signature, requires the issuer's public key. For an mDL, that means the bank needs the public key certificate of the state DMV that issued the credential.
There is no single national registry of DMV issuer certificates that banks can query today. States publish their certificates through different mechanisms. The AAMVA Digital Trust Service provides a distribution channel for mDL issuer certificates across participating states, but not every state participates, and not every bank knows how to connect to it.
For a bank building mDL verification, the practical question is: where do I get a trustworthy copy of each state's signing certificate, and how do I keep it current? This is a trust infrastructure problem, not a coding problem. The bank needs a reliable source of issuer certificates and a process for updating them when states rotate keys or add new signing authorities.
A valid signature confirms that the credential was authentic at the time of issuance. It does not confirm that the credential is still valid. The holder may have reported the device lost or stolen, the DMV may have suspended or revoked the underlying license, or the credential may have expired.
Revocation checking for mDLs is not standardized in the same way that certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) work for TLS certificates. Some implementations use status lists; others require the verifier to contact an issuer-maintained endpoint. The bank needs to know which mechanism each state supports and build the integration to check it.
In practice, many early mDL acceptance implementations skip revocation checking entirely, treating the credential as valid if the signature checks out and the expiration date has not passed. For a regulated CIP transaction, this is a risk decision that a bank's compliance team will need to evaluate carefully.
The FinCEN FAQ defines a VDC as "cryptographically bound to a device, and protected by an activation factor." These are not decorative requirements. Device binding ensures that the credential is being presented from the specific phone it was provisioned to, not copied or replayed from another device. The activation factor (a PIN, password, or biometric) confirms that the person presenting the credential has authenticated to it.
For in-person verification at a branch, device binding and activation are handled through the mDL presentation protocol. The customer presents the credential from their device using NFC or a QR code, and the device confirms that the holder has unlocked the credential with their biometric or PIN. The bank's reader captures the credential data along with cryptographic proof of device binding.
Remote and online verification is more complex. Online mDL presentation under ISO/IEC 18013-7 defines how a credential can be presented through a browser or app interaction while maintaining device binding properties. But bank onboarding systems were not designed for this protocol. Integrating it requires changes to the account opening flow, not just the identity verification step.
Bringing this together, a bank that wants to properly verify an mDL for CIP compliance needs:
Most banks have none of this today. Their identity verification infrastructure is built around document scanning, optical character recognition, and database lookups. VDC verification is a different technology stack.
Banks do not need to build all of this from scratch. Verification service providers, including companies that build digital credential verification infrastructure, can provide the cryptographic verification layer as a service. The bank's integration point shifts from scanning a physical document to calling a verification API that handles signature validation, revocation checking, and device binding confirmation.
But even with a service provider, the bank still faces decisions: which states' mDLs to accept initially, what fallback procedures to use when verification fails, how to handle the transition period when some customers have mDLs and most do not, and how to document the verification process for examination purposes.
The FinCEN ruling opened the door. Walking through it requires verification infrastructure that most of the financial services industry has not yet built. The banks that invest in this infrastructure early will be positioned to offer faster, more secure account opening. Those that wait will eventually face the same integration work, with less time to get it right.
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.
