mDL to CIP Regulatory Mapping New

Note

The mapping below has been replicated from NIST Special Publication (SP) 1800-42A Initial Public Draft, Digital Identities - Mobile Driver’s License (mDL): Accelerating Development and Adoption of Digital Identity for Financial Institutions. It is an effort to illustrate the alignment of mDL and the process implemented as part of the NCCoE build with the requirements defined in the CIP. It does not guarantee regulatory acceptance or compliance.

The primary outcome from this demonstration is to ensure that digital credentials and associated relying party workflows align with the Bank Secrecy Act. To support this outcome, the core project team along with project collaborators, Federal agency and NIST subject matter experts have developed a mapping in the table below between the technical implementation capabilities and Title 31 Code of Federal Regulations 1020.220 commonly referred to as the customer identification program (CIP) for banks.

CIP Requirement	Demonstrated Capability or Process	Capability Relationship to CIP Requirement	Relationship Explanation
31 CFR 1020.220(a)(2) Identity verification procedures. The CIP must include risk-based procedures for verifying the identity of each customer to the extent reasonable and practicable. The procedures must enable the bank to form a reasonable belief that it knows the true identity of each customer. These procedures must be based on the bank’s assessment of the relevant risks, including those presented by the various types of accounts maintained by the bank, the various methods of opening accounts provided by the bank, the various types of identifying information available, and the bank’s size, location, and customer base. At a minimum, these procedures must contain the elements described in this paragraph (a)(2).	Customer Identification with mDL Verification and TIN Validation	Aligned to CIP general requirement.	This requirement defines the general expectation that financial services organizations apply a risk-based approach to determine the “true identity” of each customer. mDL verification provides means to mitigate risk associated with identity theft or fraudulent account opening by leveraging cryptographic security features embedded within the digital credential. Coupled with holder verification to the mobile device through biometrics and other local authentication factors, this provides financial institutions with an increased degree of confidence over existing methods that 1) the evidence is real and not forged, and 2) in the possession of the individual who is represented by the credential. See 1800-42A Section 6.2.8 for discussion of local v. server-side verification of holders.
31 CFR 1020.220(a)(2)(i)(A)(1) – 31 CFR (a)(2)(i)(A)(3)(iii) In general. The CIP must contain procedures for opening an account that specify the identifying information that will be obtained from each customer. Except as permitted by paragraphs (a)(2)(i)(B) and (C) of this section, the bank must obtain, at a minimum, the following information from the customer prior to opening an account: (1) Name; (2) Date of birth, for an individual; (3) Address, which shall be: (i) For an individual, a residential or business street address; (ii) For an individual who does not have a residential or business street address, an Army Post Office (APO) or Fleet Post Office (FPO) box number, or the residential or business street address of next of kin or of another contact individual; or (iii) For a person other than an individual (such as a corporation, partnership, or trust), a principal place of business, local office, or other physical location; and	Verifiable mDL Attributes.	Aligned to CIP Requirements for identity and address attributes.	The following attributes are mandatory and encoded and signed into all mDL presentations. Family Name Given Name Date of Birth Address Each of these elements is mandatory in the AAMVA Implementation Guidelines and necessary to meet CIP requirements. The presence of these attributes within the Mobile Security Object (MSO) ensures their integrity and accuracy. Additionally, these attributes are compared against access policy requirements in the financial services IDMS – meaning if the credential did not contain the necessary data an enrollment attempt would not be successful. APO/FPO may be available on an mDL in addition to a physical address depending on the state policy, though this was not tested or observed during the project. At this time, mDL’s are for individuals only and would not support clause (ii) which allows for next of kin/contact individuals, or clause (iii) which refers to corporations.
31 CFR 1020.220(a)(2)(i)(A)(4)(i) (4) Identification number, which shall be: (i) For a U.S. person, a taxpayer identification number;	Tax Identification Number (e.g., Social Security Number) Applicant Identifier Request and validation	Aligned to requirements for an identification, specifically a Tax Identification Number for U.S. persons	A TIN attribute is not included in US State issued mDLs. The demonstration collects TIN (social security number) as part of the account opening web workflow and validates this information against a mock third-party data source [1].
31 CFR 1020.220(a)(2)(i)(A)(4)(B) & (C) Exception for persons applying for a taxpayer identification number… Credit card accounts…	Not Addressed	Not Addressed	These two clauses related to those without a TIN and allowances for credit card accounts to be opened with third party data. The build is not intended to address risk-based decisions on those who do not have TINs or processes for extending credit. As such they are out of scope for the build, and in NIST’s view do not impact the ability for an mDL based process to support compliance with CIP requirements.
31 CFR 1020.220 (a)(2)(ii) Customer verification. The CIP must contain procedures for verifying the identity of the customer, using information obtained in accordance with paragraph (a)(2)(i) of this section, within a reasonable time after the account is opened. The procedures must describe when the bank will use documents, non-documentary methods, or a combination of both methods as described in this paragraph (a)(2)(ii).	mDL Verification with TIN Validation	Aligned to requirements in both documentary (mDL) and non-documentary (TIN) verification processes	The mDL process as defined in this demonstration uses both documentary and non-documentary processes to verify the identity of an individual applying for an account. The mDL itself conforms to documentary verification processes, proving identity based on the existence of a verifiable digital credential (mDL) signed by the issuing state, while the non-documentary process validates the existence of a TIN. These are discussed in more detail below.
31 CFR 1020.220 (a)(2)(ii)(A)(1) & (2) Verification through documents. For a bank relying on documents, the CIP must contain procedures that set forth the documents that the bank will use. These documents may include: (1) For an individual, unexpired government-issued identification evidencing nationality or residence and bearing a photograph or similar safeguard, such as a driver’s license or passport; and (2) For a person other than an individual (such as a corporation, partnership, or trust), documents showing the existence of the entity, such as certified articles of incorporation, a government-issued business license, a partnership agreement, or trust instrument.	mDL Verification including verifiable attributes and holder authentication	Aligned to documentary verification processes.	An mDL is a digital document issued to an individual by a state government authority (e.g., DMV) through an identity proofing process. It contains attributes and data elements which have been signed using public key cryptography ensuring the integrity and accuracy of the data. They are also signed by a unique device key preventing them from being shared to other devices and are protected during online presentation through local authentication mechanisms (often biometrics). In addition to the user’s personal attributes an mDL also contains signed attributes such as the License Expiration date and the holder’s portrait, and physical address as mandated by this requirement. While nationality is not indicated on driver’s license (mDL or otherwise), DLs and mDL do serve as proof of residence. This is further supported by the inclusion of a realID compliance flag which has elevated expectations for residency status. The portrait can be used to 1) augment local authentication by enabling a bank biometric verification at the time of account opening and 2) physical verification in branches. This project only focused on identification of individuals and therefore does not cover example (2) at this time. It is NIST’s view that this does not impact the ability of an mDL to be used as part of a compliant CIP process.
31 CFR 1020.220 (a)(3)(i)(A) – (D) Recordkeeping. The CIP must include procedures for making and maintaining a record of all information obtained under the procedures implementing paragraph (a) of this section. Required records. At a minimum, the record must include: All identifying information about a customer obtained under paragraph (a)(2)(i) of this section; A description of any document that was relied on under paragraph (a)(2)(ii)(A) of this section noting the type of document, any identification number contained in the document, the place of issuance and, if any, the date of issuance and expiration date; A description of the methods and the results of any measures undertaken to verify the identity of the customer under paragraph (a)(2)(ii)(B) or (C) of this section; and A description of the resolution of any substantive discrepancy discovered when verifying the identifying information obtained.	CIP record establishment with representative financial institution	Representative of record keeping requirements	The NIST Bank of NCCoE is not a real financial institution. The demonstration records are established to represent a real-world architecture and process but are not as robust as real-world record systems. Attributes collected during the customer identity verification process in this demonstration were stored in an encrypted structured token within a database accessible to the banking system. The following information is captured in these tokens for all mDL related test transactions: Verified user attributes (see above for details) Document Identification Number (i.e., license number) Identification Expiration Date Issuing Entity (i.e., issuing state) Issuance Date A value of “mDL” stored in the token indicating the CIP method used. Other methods were not included as values since they were not tested, though FIs should expand and include values for all of their supported CIP methods. Existence of a token was provided as an indication of successful identity verification – Financial Institutions should expand on the token or an associated supplementary record to include more detailed information related to the CIP processes used.
31 CFR 1020.220 (a)(3)(ii) Retention of records. The bank must retain the information in paragraph (a)(3)(i)(A) of this section for five years after the date the account is closed or, in the case of credit card accounts, five years after the account is closed or becomes dormant. The bank must retain the information in paragraphs (a)(3)(i)(B), (C), and (D) of this section for five years after the record is made.	Not Addressed	Not Addressed	Since the project is demonstration only, no information is being retained. However, the demonstrated records maybe retained for as long as an FI is required. It is NISTs view that this does not impact the ability of the project to demonstrate conformity of mDL based process to CIP requirements.
31 CFR 1020.220 (a)(4) Comparison with government lists. The CIP must include procedures for determining whether the customer appears on any list of known or suspected terrorists or terrorist organizations issued by any Federal government agency and designated as such by Treasury in consultation with the Federal functional regulators. The procedures must require the bank to make such a determination within a reasonable period of time after the account is opened, or earlier, if required by another Federal law or regulation or Federal directive issued in connection with the applicable list. The procedures must also require the bank to follow all Federal directives issued in connection with such lists.	Mocked government identifier check	Aligned to Requirement for Government Records Check	The representative financial service application runs the applicant provided SSN against a mocked service for external checks. This is not however, an external service check as such checks cannot be done with against test SSNs. OFC and other sanctions checks where out of scope for our effort. Financial Institutions have existing processes for checking government restrictions that will continue to operate alongside mDL based CIP processes. Its NIST’s view that mocking this service has no impact on the ability of mDL based CIP to conform to regulatory requirements.
31 CFR 1020.220 (a)(5)(i) – (iii) Customer notice. The CIP must include procedures for providing bank customers with adequate notice that the bank is requesting information to verify their identities. Adequate notice. Notice is adequate if the bank generally describes the identification requirements of this section and provides the notice in a manner reasonably designed to ensure that a customer is able to view the notice, or is otherwise given notice, before opening an account. For example, depending upon the manner in which the account is opened, a bank may post a notice in the lobby or on its Web site, include the notice on its account applications, or use any other form of written or oral notice. Sample notice. If appropriate, a bank may use the following sample language to provide notice to its customers…	Notice and consent collection – prior to starting the CIP process and prior to collection of identity attributes	Aligned to notice requirements	The demonstration includes notice and consent throughout the CIP process. This includes: General notice to the customer of the reasons for conducting CIP processes, the data to be collected, and information on why data collection is required. Specific notice with respect to mDL verification process and consent to collect specific attributes from the user’s mDL is presented prior to a request being sent to the users mobile device for the attributes. This also includes a link to more detailed information on mDL’s. Specific consent at the wallet prior to the release of the attributes to the financial institution. Note: This consent is presented and managed by the wallet itself not the FI. Our language is available at our supporting resources website. It is similar but not the same as the sample language. It was developed with UX experts and collaborators from FIs.
31 CFR 1020.220 (a)(6) (6) Reliance on another financial institution. The CIP may include procedures specifying when a bank will rely on the performance by another financial institution (including an affiliate) of any procedures of the bank’s CIP, with respect to any customer of the bank that is opening, or has opened, an account or has established a similar formal banking or business relationship with the other financial institution to provide or engage in services, dealings, or other financial transactions, provided that: Such reliance is reasonable under the circumstances; The other financial institution is subject to a rule implementing 31 U.S.C. 5318(h) and is regulated by a Federal functional regulator; and The other financial institution enters into a contract requiring it to certify annually to the bank that it has implemented its anti-money laundering program, and that it will perform (or its agent will perform) the specified requirements of the bank’s CIP.	Not Addressed	Not Addressed	This project does not demonstrate processes that rely on other Financial Institutions. It’s NIST’s view that this does not impact on the project’s ability to demonstrate the use of mDL to comply with CIP requirements.
(b) Exemptions. The appropriate Federal functional regulator, with the concurrence of the Secretary, may, by order or regulation, exempt any bank or type of account from the requirements of this section. The Federal functional regulator and the Secretary shall consider whether the exemption is consistent with the purposes of the Bank Secrecy Act and with safe and sound banking, and may consider other appropriate factors. The Secretary will make these determinations for any bank or type of account that is not subject to the authority of a Federal functional regulator.	N/A	N/A	This clause is not relevant to the project as it focuses on overall exemptions from CIP compliance.
Other requirements unaffected. Nothing in this section relieves a bank of its obligation to comply with any other provision in this chapter, including provisions concerning information that must be obtained, verified, or maintained in connection with any account or transaction.	N/A	N/A	This clause is not relevant to the project as it addresses the regulation’s impact on other aspects of the regulation.