mDL Integration for CIP/KYC: Reference Architecture for Financial Institutions

Scope

This guide helps financial institutions evaluate and integrate mobile driver's licenses (mDLs) into Customer Identification Program (CIP) and Know Your Customer (KYC) workflows. It focuses on the National Cybersecurity Center of Excellence's reference implementation for financial account opening, covering remote identity proofing, authentication, and step-up verification use cases.

If you're responsible for CIP compliance under the USA PATRIOT Act Section 326, managing identity verification technology, or evaluating fraud prevention controls, this guide is for you.

Key Concepts and Definitions

Mobile Driver's License (mDL): A digital credential stored in a mobile app that carries the same identity attributes as a physical driver's license but uses public key cryptography for authenticity and selective disclosure.

Remote Identity Proofing: Verifying an individual's claimed identity from a distance, typically during account opening. Under CIP requirements, verify customer identity using documents, non-documentary methods, or both.

Selective Disclosure: Sharing specific attributes from a credential without exposing the entire document. For example, proving you're over 18 without revealing your exact birthdate or full address.

Cross-Device Flow: Authentication or verification that starts on one device and completes on another, such as a laptop and smartphone.

Step-Up Verification: Additional identity checks triggered by high-risk transactions or suspected fraud.

Requirements Breakdown

CIP Obligations (USA PATRIOT Act Section 326)

Your Customer Identification Program must obtain four core identity elements:

• Name
• Date of birth
• Address
• Identification number (SSN or other government-issued identifier)

You must verify the customer's identity using documents, non-documentary methods, or both, forming a reasonable belief that you know the true identity of the customer.

mDL Capabilities Mapped to CIP

Remote Presentment: The mDL serves as identity evidence during account opening. The cryptographic signature proves the credential was issued by a legitimate state authority, meeting the documentary verification requirement.

Attribute Verification: The mDL provides verifiable attributes (name, DOB, address) that satisfy the four core elements, with cryptographic proof of authenticity.

Biometric Authentication: The mDL binds to the user through biometric authentication on the smartphone, ensuring the presenter is the legitimate holder.

Integration Points

The NCCoE reference architecture identifies three integration scenarios:

1. Account Opening: mDL as primary identity evidence during remote account creation.
2. Post-Issuance Authentication: mDL or bound authenticator for returning customer login.
3. High-Risk Transaction Verification: mDL presentment when fraud indicators trigger additional checks.

Implementation Guidance

Evaluating Your Current Stack

Before integrating mDL support, map your existing identity verification flow:

Front-End Components: Most institutions use document scanning libraries that capture license images and extract text via OCR. You'll need to add mDL wallet interaction capabilities to your mobile app or web flow.

Back-End Verification: You're likely using third-party verification services that check government databases or credit bureau records. With mDLs, verify the cryptographic signature instead of relying solely on document appearance.

Core Banking Integration: Your account opening system needs to accept identity attributes from the mDL verification service and record the verification method for audit purposes.

Technical Architecture Considerations

Wallet Interaction Protocol: The mDL lives in a digital wallet app on the customer's smartphone. Your application needs to request specific attributes using standardized protocols. Plan for:

• QR code-based cross-device flows.
• App-to-app flows.
• Consent screens showing exactly what you're requesting.

Cryptographic Verification: Your verification service must:

• Validate the issuing authority's signature.
• Check certificate revocation status.
• Confirm the mDL hasn't expired.
• Verify the binding to the current user.

Selective Disclosure Implementation: Request only necessary attributes to reduce data handling obligations under the GLBA Safeguards Rule.

Regulatory Considerations

Risk-Based Approach: Document how mDL verification fits your risk assessment. For low-risk accounts, cryptographic verification of the mDL might suffice. For higher-risk scenarios, combine mDL presentment with non-documentary methods.

Recordkeeping: Maintain records of the information used to verify identity. With mDLs, record:

• The verification method used.
• The issuing state.
• The verification timestamp.
• The cryptographic verification result.
• Which attributes were disclosed.

Customer Notice: Update your account opening disclosures to explain that mDL presentment is an available verification method.

Common Pitfalls

Assuming mDL Replaces All Verification: The mDL proves the credential is authentic and the presenter is the legitimate holder. It doesn't prove the person isn't on sanctions lists or that the identity hasn't been synthetically constructed. Continue running standard checks against OFAC lists and verify the identity exists in authoritative databases.

Ignoring Accessibility: Not all customers will have mDL-capable smartphones or state-issued mDLs. Maintain alternative verification methods for customers who can't use mDLs.

Overlooking Privacy Controls: Request only necessary attributes. Your GLBA privacy obligations don't change because the delivery mechanism is different.

Skipping Fraud Pattern Analysis: mDLs reduce certain fraud vectors but don't eliminate fraud risk. Maintain your fraud detection controls and behavioral analytics.

Treating All mDLs Equally: Implementation quality varies by issuing state. Account for these differences in your risk-based approach.

Quick Reference Table

Next Steps: If your institution wants to participate in the NCCoE reference implementation, request a letter of interest from [email protected]. Your feedback on technology architectures, account opening processes, and balancing fraud prevention with CIP requirements is valuable.

The mDL ecosystem is still maturing. Standards bodies, state issuers, and technology providers are working through interoperability challenges. Your early engagement helps shape implementations that work for financial institutions rather than creating compliance headaches.