On September 8, 2026, FinCEN and the staffs of the Federal Reserve, the FDIC, the NCUA, and the OCC answered a question the identity industry has been asking banks for five years. Can a mobile driver's license satisfy KYC? Yes. Two new frequently asked questions under the Customer Identification Program Rule, plus an amendment to a third, and the ambiguity is gone.

The agencies defined a credential by its security properties

A verifiable digital credential, or VDC, is a data structure that contains information about an individual, is digitally signed by the issuing source of the information, is cryptographically bound to a device, and is protected by an activation factor. An activation factor is something the user knows, like a PIN, or a unique attribute they possess, like a face or a fingerprint.

Both public and private wallets now have a written path

The FAQs cover both halves of the wallet market at once, which is the most useful thing about them. A state-issued mDL sitting in Apple Wallet and a private reusable ID from a third-party provider each have a documented route through CIP now.

Government-issued credentials come in as documentary evidence. An unexpired, government-issued VDC qualifies as a "government-issued identification" under 31 C.F.R. § 1020.220(a)(2)(ii)(A)(1), provided it also evidences nationality or residence and bears a photograph or similar safeguard. A state-issued mDL contains all the same information as the plastic license, so it clears that bar. That puts an mDL in the same bucket as a passport or a physical driver's license, which is the friendliest outcome available: no new category, no bespoke risk framework, nothing to wait for. The CIP Rule, in the agencies' words, neither requires nor prohibits reliance on government-issued VDCs. You may treat one as one of the documentary methods you use to verify a customer's identity. Your CIP has to allow it, and you have to maintain the appropriate technology or systems to extract the relevant information from the credential.

Private reusable IDs come in through the non-documentary door. The amended FAQ covers using an electronic credential, a digital certificate, or a VDC as a non-documentary means of verification, and it now says "verifiable digital credential" out loud. For credentials issued and maintained by a non-government third party, the bank or credit union is responsible for ensuring that the third party uses the same level of authentication as the bank or credit union itself would use, measured against the FFIEC guidance on authentication in an electronic banking environment.

The FAQs tell you exactly what to build

Reading a credential is not a single integration. A customer presenting an mDL might present from Apple Wallet, Google Wallet, or Samsung Wallet, or from a state-run app like LA Wallet or CA DMV Wallet. In-person presentment runs on ISO/IEC 18013-5. Remote presentment runs on ISO/IEC 18013-7. Each issuing jurisdiction runs its own program, timeline, and trust infrastructure, and the list of live jurisdictions grows every quarter. You can see the current state of that coverage on our coverage page, and it will look better in six months.

The verification work itself is well defined: validate the issuer signature against a current trust list, confirm device binding and activation, check revocation. Do that and you get something a document scan has never been able to give you, which is cryptographic proof that the issuing authority signed this credential and nobody altered it in transit.

How Trinsic fits

Trinsic is digital ID acceptance infrastructure. Through one integration you accept the digital IDs your customers already carry, including mobile driver's licenses, government eIDs, private reusable IDs, EUDI wallets, and verifiable credentials, across many providers and countries.

For a bank working through these FAQs, that means the capability condition stops being a roadmap item. We track which jurisdictions are live, which wallets a given customer can present from, and how each presentation flow works, and we keep it current as coverage expands. You specify the attributes and assurance level your CIP requires, and we route each customer to a credential that satisfies them, with your existing IDV provider as the fallback for everyone else.

Talk to our team if you are turning these FAQs into a CIP amendment and want to see what acceptance looks like in production.