Regulation \u00b7 Customer identification program

Customer Identification Program: Section 326 Compliance

A practical breakdown of Section 326 CIP obligations and how fintech platforms can automate compliant identity verification at scale.

Updated 2026-05-04·12 min read

Section 326 of the USA PATRIOT Act established the statutory foundation for the Customer Identification Program, a mandatory framework requiring covered financial institutions to verify the identity of every customer who opens an account. The implementing regulations, codified at 31 C.F.R. § 1020.220 for banks and parallel rules for other covered institutions, define the minimum data elements, verification methods, recordkeeping standards, and government-list screening obligations that constitute a compliant CIP. Failure to maintain a written, board-approved program exposes institutions to enforcement action under the Bank Secrecy Act.

This guide is written for compliance officers, BSA/AML program managers, and fintech product teams who need a precise, examiner-grade understanding of Section 326 obligations—including how those obligations apply when identity verification is handled through automated workflows, third-party vendors, or sponsor bank arrangements.

What is Section 326 of the USA PATRIOT Act

Section 326 of the Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001 (USA PATRIOT Act) directed the Secretary of the Treasury, jointly with the relevant federal functional regulators, to prescribe minimum standards for financial institutions regarding the identity of customers opening accounts. Congress enacted Section 326 in direct response to the recognition that anonymous account opening was a key vulnerability exploited in terrorist financing and money laundering schemes.

The resulting regulations took effect in 2003 and were incorporated into the Bank Secrecy Act's implementing framework administered by the Financial Crimes Enforcement Network (FinCEN). Each covered institution type—banks, savings associations, credit unions, broker-dealers, mutual funds, and futures commission merchants—received a sector-specific rule that mirrors the same core requirements while accommodating differences in account structure and customer base.

At its core, Section 326 mandates that a covered institution must: collect prescribed identifying information before account opening, verify that information using documentary or non-documentary methods, maintain records of what was collected and how it was verified, and check customers against government-issued lists of known or suspected terrorists. These four pillars define the structural minimum of any compliant Customer Identification Program.

Who must comply with CIP rules

The Customer Identification Program obligation applies to "banks" as broadly defined under the BSA, a category that encompasses commercial banks, savings banks, credit unions, and trust companies. Beyond deposit institutions, broker-dealers registered with the SEC, registered investment companies that are mutual funds, and futures commission merchants and introducing brokers registered with the CFTC all have separate but substantially parallel CIP rules issued by their respective regulators.

For the fintech sector, the critical compliance question turns on charter status. A fintech company that holds its own bank charter is directly subject to the banking CIP rule. Far more commonly, fintechs operate under a sponsor bank's charter as a bank service company or agent. In that model, the sponsor bank bears the primary regulatory obligation, but examiners expect the bank to have contracted CIP responsibilities to the fintech program in a written agreement and to actively oversee performance. The fintech is therefore functionally required to maintain a CIP that satisfies the bank's regulatory standards.

Money services businesses, including money transmitters and prepaid card issuers not operating under a bank charter, are subject to FinCEN's MSB rules rather than the bank CIP rule, but those rules impose substantively similar identity verification obligations. Any fintech operating a prepaid access program, payment application, or lending product should map its regulatory status carefully before determining which CIP rule governs its program.

Minimum requirements of a compliant CIP

The regulations specify four mandatory data elements that must be collected from every individual customer prior to account opening: full legal name, date of birth, residential or business address, and an identification number (a U.S. person's Social Security Number or ITIN, or for non-U.S. persons, a passport number, alien identification card number, or other government-issued document number). These elements are a floor, not a ceiling—a risk-based program may collect additional information for higher-risk customer segments.

Beyond data collection, a compliant CIP must include four programmatic elements:

  • Written program: The CIP must be reduced to writing and approved by the institution's board of directors or an equivalent governing body before implementation.
  • Verification procedures: The program must describe the methods—documentary, non-documentary, or a combination—that will be used to verify identity within a reasonable time of account opening.
  • Recordkeeping: The institution must retain copies of any documents relied upon, a description of non-documentary methods used, and the results of each verification.
  • Government list checks: The CIP must include procedures for checking customer names against any government-provided list of known or suspected terrorist organizations, most practically the OFAC SDN list and any FinCEN-issued section 314(a) requests.

The written program must also address customer notice requirements (informing customers that identity information is being requested to verify their identity), procedures for opening accounts before verification is complete where reasonable, and steps to take when a customer cannot be verified.

Documentary vs. non-documentary verification methods

Documentary verification involves reviewing an unexpired government-issued identification document that bears a photograph or similar safeguard, such as a driver's license, passport, or state-issued identification card. For entity customers, documentary verification typically means reviewing formation documents such as articles of incorporation or a certified partnership agreement. The key regulatory requirement is that the institution must have procedures for situations where the document cannot be authenticated or appears altered.

Non-documentary methods do not rely on physical or digital document presentation. Instead, they use data sources independent of the customer to corroborate the identity information provided. Common non-documentary methods include:

  • Credit bureau header data checks against name, address, date of birth, and SSN
  • Knowledge-based authentication (KBA) using out-of-wallet questions derived from public and commercial data sources
  • Third-party identity verification services that cross-reference government records, utility data, and proprietary identity graphs
  • Database checks against commercial identity aggregators
  • Verification of account numbers at other financial institutions

Most fintech programs rely primarily on non-documentary methods because their onboarding is entirely digital and customers cannot present a physical document in person. The regulations permit this approach, provided the institution's written CIP describes the specific methods used and the program addresses how discrepancies between submitted information and verification results will be resolved. A layered approach—combining a database check with document capture for higher-risk applicants—generally produces the most defensible audit record.

CIP recordkeeping and retention obligations

The regulations require covered institutions to retain CIP-related records for a minimum of five years after the date the account is closed, or in the case of credit card accounts, five years after the record is made. This retention window applies to two categories of records: the identifying information obtained from the customer (name, date of birth, address, identification number) and the verification records, meaning copies of documents reviewed, descriptions of non-documentary methods used, and the resolution of any identity discrepancies.

Examiners conducting a BSA/AML examination expect to find structured, retrievable records that demonstrate the institution can reconstruct the verification decision for any account. A bare assertion that a customer was verified is insufficient—the record must show what data was collected, which method was used, what the method returned, and how any discrepancies were resolved or escalated.

For fintech programs processing high onboarding volumes through automated workflows, recordkeeping architecture is a material compliance risk. Each vendor API call, decision output, and exception disposition should be logged in a format that can be exported and presented to an examiner on demand. Retention policies must account for the five-year clock starting from account closure, not account opening, which means active accounts require indefinite retention of CIP records until closure triggers the countdown.

How CIP relates to the FinCEN CDD Rule

The Customer Identification Program and the Customer Due Diligence Rule operate as sequential layers of the same AML framework rather than as independent obligations. CIP is the threshold step: before any relationship begins, the institution must collect and verify the customer's identity. The CDD Rule, which FinCEN finalized in 2016 and which applies to the same categories of covered financial institutions, builds on that verified identity to require ongoing risk assessment, beneficial ownership identification for legal entity customers, and the establishment of a customer risk profile used to monitor for suspicious activity.

Practically, a gap in CIP creates a gap in CDD. If an institution cannot confirm who a customer is, it cannot meaningfully assess that customer's risk profile, understand the nature of expected account activity, or identify the natural persons who own or control a legal entity customer. Examiners treat the two programs as interdependent, and a CIP deficiency identified during an examination will typically trigger enhanced scrutiny of the institution's broader CDD and suspicious activity monitoring controls.

FinQub's compliance resources treat CIP and CDD as a unified onboarding risk framework precisely because the regulatory expectation is that a verified identity feeds directly and automatically into risk scoring, beneficial ownership collection, and ongoing monitoring logic—not that they operate as siloed checkboxes.

Common CIP compliance challenges for fintechs

Fintech companies face a distinct set of operational challenges when implementing a CIP that satisfies both the letter of Section 326 and the practical expectations of a sponsor bank's BSA officer. These challenges are structural rather than incidental, arising from the combination of digital-only onboarding, high application volumes, diverse customer demographics, and multi-vendor technology stacks.

  • Vendor fragmentation: Most fintechs use multiple identity verification vendors for redundancy or to optimize pass rates across demographic segments, creating inconsistent data formats and gaps in the audit trail.
  • Inconsistent data quality: Thin-file customers, recently relocated individuals, and non-U.S. persons with limited domestic credit history frequently return inconclusive results from database verification methods, requiring exception handling that many programs have not formalized.
  • Sponsor bank oversight demands: Sponsor banks are increasingly requiring fintechs to provide regular CIP performance metrics, exception rates, and vendor audit rights, creating a reporting burden that manual processes cannot sustain.
  • Real-time onboarding expectations: Consumer-facing fintechs face competitive pressure to approve accounts in seconds, while CIP obligations require verification within a "reasonable time"—a standard that must be balanced against the risk of allowing account activity before identity is confirmed.
  • Change management: Updates to vendor logic, threshold scores, or fallback rules must be reflected in the written CIP and approved through governance processes before deployment, a discipline that fast-moving engineering teams may not naturally observe.

Automating CIP workflows with orchestration

An identity orchestration platform addresses the structural challenges of fintech CIP compliance by sitting between the onboarding application and multiple identity verification vendors, routing data, applying decisioning logic, and producing a unified record of every verification step. Rather than integrating directly to each vendor and managing separate API contracts, failure handling, and data normalization independently, the fintech configures a single orchestration layer that handles all of that complexity in one place.

From a Section 326 perspective, orchestration supports compliance in several concrete ways. First, it enables fallback logic—if a primary database check returns an inconclusive result, the orchestration layer can automatically route the application to a secondary vendor or trigger a document capture step, all within a single session and without manual intervention. Second, it normalizes outputs across vendors into a consistent record structure, ensuring that the audit log contains the same fields regardless of which verification method was ultimately used. Third, it enforces decisioning rules consistently, eliminating the ad hoc exception handling that creates examiner findings.

FinQub's guidance on orchestration emphasizes that the technology does not replace the written CIP—it operationalizes it. Every routing rule, threshold, and fallback sequence should be documented in the written program so that an examiner can trace any verification outcome back to a pre-approved procedure. The orchestration platform produces the evidence; the written program explains the logic behind each decision.

What regulators and examiners look for in a CIP

The FFIEC BSA/AML Examination Manual and the OCC's large bank supervision procedures both provide detailed guidance on what examiners assess when reviewing a Customer Identification Program. At the highest level, examiners are evaluating whether the program is risk-based, written, board-approved, and actually implemented as written. A gap between the written program and operational practice is one of the most common CIP deficiencies cited in examination findings.

Specific elements that draw examiner attention include: whether the written program addresses all customer types the institution actually serves, whether risk-based distinctions in verification procedures are documented and rational, whether exception rates are tracked and reported to BSA management, and whether the institution has conducted periodic independent testing of CIP controls. Examiners also review whether the institution has a process for updating its CIP when it launches new products, enters new markets, or changes its customer demographic profile.

FinQub recommends that compliance teams map each element of their written CIP to an operational control and maintain evidence that the control is functioning as described. This mapping exercise—sometimes called a CIP control inventory—is the most efficient way to prepare for an examination and to identify gaps before an examiner does. Documentation of board or senior management approval, annual program reviews, and independent testing results should be retained alongside the written program itself.

Frequently asked questions

Stop building your orchestration layer. Start running on it.

Let's talk about what FinQub looks like for your stack — which tools you're running, where the pain is, and how quickly you can eliminate it.

Not ready to book a call? Apply for the Partner Program →