When a customer presents a mobile driver's license (mDL) at a bank branch in Texas, the credential may have been issued by the California DMV. The bank's system needs to confirm that the credential's digital signature was produced by a legitimate state authority, that the data has not been tampered with, and that the credential is bound to the device in front of the teller. That confirmation requires the bank to obtain and trust California's public key, a step that most financial institutions have never had to perform before.
The joint FAQs published on September 8, 2026 by FinCEN and four federal banking regulators confirm that government-issued verifiable digital credentials (VDCs), including mDLs, qualify as documentary identification under the CIP Rule (31 CFR 1020.220). But the ruling does not tell banks how to build the trust infrastructure they need to verify those credentials across state lines. That is the plumbing problem this post explains.
An mDL issued under ISO/IEC 18013-5 is a signed data structure. The issuing state's DMV holds a private signing key. When it issues a credential, it signs the holder's data elements (name, date of birth, address, portrait, and others) with that key. The corresponding public key is anchored in an Issuing Authority Certificate Authority (IACA) certificate, which serves as proof that the signing key belongs to a legitimate government authority.
When a verifier, in this case a bank, receives a presented mDL, it must do three things:
If the bank cannot complete step one, the remaining steps are impossible. The entire verification chain depends on the bank having a trustworthy source for each state's public key.
This is where the AAMVA Digital Trust Service (DTS) enters the picture. AAMVA, the American Association of Motor Vehicle Administrators, operates a centralized trust service that aggregates the IACA certificates from participating state DMVs into a single Verified Issuer Certificate Authority List (VICAL). A bank or other relying party that connects to the DTS can retrieve the public keys for every participating jurisdiction from one source, rather than establishing a bilateral relationship with each state's DMV individually.
The DTS was designed around this exact use case. Participating states submit their IACA certificates to AAMVA, which validates the keys, ensures compliance with ISO/IEC 18013-5 and AAMVA's own implementation guidelines, and publishes the aggregated trust list to registered relying parties. Critically, the DTS handles only cryptographic keys. AAMVA states that the service does not receive, store, share, or otherwise interact with the personally identifiable information of any mDL holder.
For banks, this is an important privacy property. Connecting to the DTS does not create a new data-sharing relationship with state DMVs. The bank downloads issuer certificates, uses them to verify credentials locally, and retains only the CIP data elements required by regulation.
The DTS solves the cross-state trust problem cleanly, but only for jurisdictions that participate. As of mid-2026, approximately 11 jurisdictions are fully participating in the DTS, even though more than 22 states and territories have active mDL programs. The gap between mDL issuance and DTS participation means that a bank integrating mDL verification today will encounter credentials from states whose public keys are not available through the DTS.
What does the bank do in that case? The options are limited and none are ideal.
A bank could attempt to contact individual state DMVs to obtain their IACA certificates through direct bilateral agreements. This is technically possible but operationally impractical for a national bank that may serve customers from dozens of jurisdictions, each with different distribution mechanisms, update schedules, and terms of use. Alternatively, the bank could fall back to non-documentary verification methods permitted by the CIP Rule -- credit bureau checks, knowledge-based verification, or other third-party corroboration -- accepting the mDL data fields while verifying identity through separate channels. That approach is compliant but defeats the purpose of cryptographic credential verification. The simplest path is to decline the credential entirely and require those customers to present a physical ID, though this creates an inconsistent customer experience and may frustrate adoption.
None of these alternatives scale well. The practical consequence is that DTS participation by issuing states is the bottleneck for bank-side adoption of mDL verification.
Financial institutions evaluating mDL acceptance should plan for a phased adoption that tracks DTS coverage. Several practical considerations apply.
Reader and verification infrastructure. In-person mDL presentation under ISO/IEC 18013-5 requires NFC or BLE-capable reader devices at branches and the software to validate credential signatures against IACA certificates. For remote presentation, ISO/IEC 18013-7 and OpenID for Verifiable Presentations (OID4VP) define how credentials can be presented online through a browser or mobile app.
DTS integration. Banks need a mechanism to retrieve and cache IACA certificates from the DTS, keep them updated as states rotate keys, and match incoming credentials against the correct issuer certificate. This is not a one-time integration; it requires ongoing certificate lifecycle management.
Fallback handling. Until DTS coverage reaches all mDL-issuing states, banks need clear policies for credentials that cannot be cryptographically verified. As we discussed in our analysis of the FinCEN ruling, accepting credential data fields without verifying the issuer's signature introduces risk rather than reducing it.
Regulatory examination readiness. Banks should document their mDL verification procedures, including which states they can verify cryptographically, how they handle non-DTS credentials, and how they log verification outcomes for CIP compliance records.
The FinCEN ruling opens the door for banks to accept mDLs. But the ruling addresses the policy question (whether mDLs count as acceptable identification) without resolving the infrastructure question (how a bank in one state verifies a credential issued by another). That infrastructure depends on a functioning trust relationship between issuers and verifiers, mediated by services like the AAMVA DTS.
For banks, this means that mDL acceptance is not purely a compliance decision. It is an infrastructure investment that requires connectivity to trust services, credential verification software, and operational procedures for a landscape where coverage is still expanding. The NIST NCCoE mDL project provides a reference architecture for financial institutions working through these questions, and AAMVA continues to onboard new jurisdictions into the DTS.
The states are building the credentials. The regulators have confirmed acceptance. The remaining work is connecting the plumbing between issuers and the institutions that need to verify what they receive.
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.
