A bank teller photographs a physical driver's license and files the image. A bouncer glances at the screen of a phone showing a state-issued mobile driver's license. A government benefits portal accepts an uploaded screenshot of a digital credential. In each case, the organization has accepted a credential. In none of these cases has it verified one.
The distinction between acceptance and verification is the most consequential idea in the September 8, 2026 FAQs published jointly by FinCEN and four federal banking regulators. The ruling confirms that government-issued verifiable digital credentials (VDCs), including mobile driver's licenses, qualify as documentary identification under the CIP Rule (31 CFR 1020.220). But the guidance also makes clear that the credential must be what the regulators describe as a verifiable digital credential: a data structure that is digitally signed by the issuer, cryptographically bound to a device, and protected by activation factors such as a PIN or biometric. An institution that reads data fields from a credential without performing cryptographic validation has not met that standard.
This distinction matters far beyond banking. It applies to any relying party that receives a digital credential: government agencies processing benefits applications, age-gated service providers, healthcare organizations, employers verifying professional licenses, and airports checking traveler identities. The principle is the same everywhere. If you accept a digital credential without verifying its cryptographic properties, you have added complexity to your workflow without adding trust.
Acceptance without verification takes several forms, and each carries different risks.
The most visible form is simple visual inspection of a screen. A person presents their phone with a digital credential displayed. The relying party looks at the screen, reads the name and date of birth, and perhaps compares the photo to the person standing in front of them. This is functionally equivalent to looking at a photocopy. The data on screen could have been generated by anyone with basic design tools. No issuer signature has been checked, no device binding confirmed, and no revocation status queried. The remote equivalent is a screenshot or file upload: a customer uploads an image of their credential, and the system performs OCR or manual review. The data extracted carries no cryptographic assurance either way. A sophisticated forger does not need to counterfeit a physical card; they only need to produce a convincing image file.
The most subtle and arguably most dangerous form is data field extraction without signature validation. Here, a system receives a credential in its structured digital format, extracts the relevant data fields (name, date of birth, address, credential number), and stores them for CIP or identity proofing purposes. The system has correctly parsed the credential format but has skipped the step that gives digital credentials their security advantage: validating the issuer's digital signature against a trusted public key. Because the data arrived in the right structure, the gap is easy to overlook, but it is just as real as looking at a photo on a phone screen.
In each of these scenarios, the relying party has obtained identity information. But that information carries no more assurance than a scanned document or a self-reported form field. The digital credential has been reduced to a data transport mechanism without its trust properties.
Cryptographic verification of a verifiable digital credential involves a chain of checks that, taken together, provide assurance no visual inspection can match.
Issuer signature validation. The verifier obtains the issuer's public key from a trusted source, such as the AAMVA Digital Trust Service for mobile driver's licenses, and uses it to validate the digital signature on the credential. A valid signature confirms that the data was signed by the claimed issuer and has not been modified since issuance. For mDLs conforming to ISO/IEC 18013-5, this means checking the signature against the Issuing Authority Certificate Authority (IACA) certificate.
Revocation status. A credential may have been validly issued but subsequently revoked because the underlying document was reported lost or stolen, the holder's status changed, or the issuing authority discovered an error. Verification should include a check of the credential's revocation status where the issuer provides that capability.
Device binding. A properly issued mDL is cryptographically bound to the device on which it was provisioned. During presentation, the verifier challenges the device to prove possession of the private key associated with the credential. This confirms that the credential is being presented from the original device, not copied to another phone, forwarded as a file, or replayed from a recording. Device binding is what makes a digital credential fundamentally different from a PDF or an image.
Freshness and expiration. The verifier confirms that the credential has not expired and that the presentation is current, not a replay of a previously captured session.
Each of these checks is machine-executable. When implemented correctly, they complete in seconds and produce a deterministic result: the credential either passes all checks or it does not. Compare this to the subjective judgment involved in examining a physical document for signs of tampering, where the reliability depends on the training and attention of the human reviewer.
Organizations sometimes treat digital credential acceptance as an incremental improvement over physical documents, even when they skip verification. The reasoning is that a digital credential is at least "more modern" and that the structured data is easier to process. This reasoning is mistaken.
A physical driver's license has embedded security features: holograms, microprinting, UV-reactive inks, polycarbonate layers. These features are difficult and expensive to counterfeit. A trained examiner can detect many forgeries through physical inspection. The security model of a physical ID depends on the difficulty of manufacturing a convincing physical artifact.
A digital credential presented without cryptographic verification has none of these protections. The data is trivially reproducible. A valid-looking mDL screen, a well-formatted data payload, or a convincing screenshot can be created without access to the issuing authority's systems. The security model of a digital credential depends entirely on cryptography, not on the difficulty of reproducing the data. An organization that skips the cryptographic checks has abandoned the security model that makes the credential trustworthy in the first place.
As we noted in our analysis of the FinCEN ruling, this is not a theoretical concern. The ruling itself draws the distinction between credentials that are cryptographically verifiable and those that are merely digital representations of identity data.
The accept-vs-verify distinction maps directly onto a principle that information security practitioners recognize from zero trust architecture: never trust, always verify. In a zero trust model, access decisions are based on verified claims, not on the channel through which those claims arrive or the apparent authority of the presenter.
Applied to digital credentials, zero trust means that the format of the credential (whether it looks like a credential, arrives through an expected channel, or contains plausible data) is not evidence of its authenticity. Only cryptographic validation of the issuer's signature, combined with device binding and revocation checks, establishes that the credential is what it claims to be.
This principle extends to every context where digital credentials are presented. A state benefits agency accepting a VDC to verify residency, an employer checking a professional license, a healthcare provider confirming insurance coverage, an age-gated service validating that a customer is over 21: each of these relying parties faces the same question. Are you verifying the credential, or are you accepting a data structure on faith?
Most organizations that skip verification do not do so because they believe visual inspection is adequate. They do so because they lack the infrastructure to verify. Cryptographic verification requires access to issuer public keys, integration with trust services, support for credential presentation protocols, and software capable of performing signature validation and device-binding checks.
For mobile driver's licenses, verification infrastructure includes NFC or BLE readers for in-person presentation, integration with the AAMVA Digital Trust Service for cross-state issuer certificate retrieval, and support for ISO/IEC 18013-7 or OID4VP for remote presentation. For W3C Verifiable Credentials, it requires resolver infrastructure for decentralized identifiers and the ability to process the relevant proof formats.
The FinCEN ruling makes the policy case for acceptance. It does not provide the verification infrastructure. That infrastructure is the work that banks, government agencies, and other relying parties need to invest in now, before digital credentials arrive at scale at their front doors.
Organizations planning to accept digital credentials should treat verification as a first-class requirement, not an optimization for later. Several principles apply.
Verification should be automated and deterministic. The point of cryptographic verification is to remove subjective human judgment from the process. If a credential passes all checks, it is accepted. If it fails any check, it is flagged or rejected. The system should log the outcome for audit purposes.
Fallback procedures must exist. Not every customer will have a digital credential, and not every credential will be verifiable (for example, if the issuing state's keys are not yet available through a trust service). The verification workflow needs a clean path to documentary or non-documentary alternatives without requiring the customer to start over.
Data minimization should follow verification. Once a credential is verified, the relying party should retain only the data elements required for its purpose. Selective disclosure, a feature supported by both ISO/IEC 18013-5 and W3C credential formats, allows the holder to share only the specific attributes the verifier needs. Verified data that is minimized at the point of collection reduces both privacy risk and data-breach liability.
The organizations that build verification into their credential acceptance workflows from the start will be positioned for a landscape where digital credentials become routine. Those that treat acceptance as a checkbox and defer verification will find themselves managing a growing security gap between what their systems claim to check and what they actually confirm.
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.
