How to Test a Bank CIP: Sampling, Evidence, Exceptions, and Conclusions

TL;DR

• Customer identification program testing starts with the account-opening population. If the extract omits failed, abandoned, manually opened, or partner-originated accounts, a clean sample proves very little.
• Build the workpaper at the attribute level: requirement, procedure, evidence expected, result, exception, and conclusion. “CIP passed” is not a test step.
• Keep random or representative sampling separate from targeted testing. Targeted exceptions expose risk; they do not establish a population-wide failure rate.
• Record the original failure before considering a compensating control. Never let a later screenshot turn a historical exception into a pass.

A bank can produce 40 immaculate customer files and still have a broken CIP.

The usual problem is upstream: the tester sampled from the KYC vendor’s “completed” table. Accounts that failed verification, entered manual review, came through a fintech partner, or never reached the vendor were outside the file. Every selected item passed because the population had already filtered out the failures.

That is why customer identification program testing must begin with population completeness, not document inspection. The workpaper should let a skeptical reviewer reconstruct four things: what should have happened, which accounts were in scope, what evidence was inspected, and why the results support the conclusion.

This guide is the CIP-specific testing layer. Use the CIP documentation guide for program design, the control-testing techniques guide for broader methodology, and the compliance monitoring and testing plan to place the test in the annual program.

Convert 31 CFR 1020.220 Into Testable Attributes

The legal anchor is 31 CFR 1020.220. It requires a written, risk-based CIP that enables the bank to form a reasonable belief that it knows each customer’s true identity. The regulation identifies minimum information, verification, failed-verification procedures, records, government-list comparison, notice, and conditions for reliance on another financial institution.

Do not paste the regulation into the workpaper and call it criteria. Translate each applicable provision and the bank’s procedure into an observable attribute.

The rule is precise about records. It calls for identifying information; a description of documentary evidence; methods and results for non-documentary verification; and the resolution of substantive discrepancies. Identifying information is retained for five years after account closure, while the specified verification and discrepancy records are retained for five years after the record is made.

The FFIEC BSA/AML Manual’s CIP examination procedures are the practical companion source. Use them to challenge whether the bank’s risk assessment, procedures, account-opening methods, records, notice, and testing are consistent—not as a substitute for the regulation or institution-specific criteria.

Prove the Population Before Selecting a Sample

Request the population from the system that establishes the banking relationship, then reconcile it to the systems that perform verification. A vendor success file is evidence about one control step; it is rarely the full account-opening population.

Your population request should include, at minimum:

• unique application and account identifiers;
• customer and product type;
• origination channel, including branch, digital, API, and partner;
• application, account-opening, and closure timestamps;
• verification status and every material status change;
• verification method and vendor or internal system;
• manual-review and exception flags;
• restriction status;
• partner or program identifier;
• whether a third-party TIN source was used; and
• test-period cancellations, rejections, and failed openings where the process reached a CIP control.

Then perform three reconciliations:

1. Application-to-account: Every opened account maps to an application or approved opening event. Orphan accounts require investigation.
2. Account-to-verification: Every in-scope opened account maps to a verification record or an authorized exception path.
3. Summary-to-detail: Counts by day, product, channel, and status agree between the detailed extract and control-owner reports.

Retain the query, report parameters, extraction date, source owner, and reconciliation results. A statement from Operations that “the file is complete” is inquiry, not completeness evidence.

A real-world nuisance: joint accounts, renewed products, and existing customers can create duplicate-looking rows or exclusions. Resolve those rules before sampling. Record why a row is in or out using the regulation’s and the bank’s definitions of “account” and “customer.” Do not silently de-duplicate until the counts look tidy.

Design the CIP Sample Around Risk and Purpose

There is no universal regulatory number of files that makes a CIP test defensible. The selection should answer the test objective.

Use separate sample tabs or labels for:

• Population-based selection: random, systematic, or another documented method intended to assess routine operation across the defined population.
• Stratified selection: coverage across products, channels, legal entities, non-U.S. persons, remote openings, partners, or other meaningful segments.
• Targeted selection: failed verification, long-pending cases, manual overrides, identity mismatches, early closures, third-party TIN collection, or prior-problem channels.

A realistic hypothetical: a tester has 2,400 opened accounts across branch, direct digital, and two fintech programs. The tester selects 60 records using a reproducible random method, then adds 20 targeted records from failed-verification and manual-override queues. Those numbers are illustrative, not benchmarks. The workpaper must report the random results and targeted results separately. An exception rate from the 20 deliberately risky cases cannot be projected onto all 2,400 accounts.

Before pulling records, write down:

• the population and period;
• the sampling unit—customer, account, application, or verification event;
• selection method and random seed or reproducible logic, if used;
• strata and why they matter;
• targeted criteria;
• expected tolerable deviation or decision rule, if the methodology uses one; and
• what happens if an exception is found, including possible expansion.

If the population is small enough, test all items. If a control is automated, inspect configuration and change history in addition to transaction samples. A hundred passing outputs do not prove the rule was configured correctly for every branch of the decision tree.

Build a Row-Level Testing Workpaper

One row should represent one sampling unit, with separate columns for each attribute. Avoid a single “pass/fail” cell that hides where the record failed.

That example is hypothetical. Notice what it does not say: “address mismatch—minor.” Severity comes after the factual exception is established.

Evidence requests should be precise. Ask for the original system record, decision response, case history, and procedure effective on the transaction date. A PDF assembled after the request may explain the process, but it does not prove the control operated at account opening.

Classify Exceptions Without Rewriting History

Use a consistent decision sequence:

1. Did the required attribute fail? Record the deviation and cite the criterion.
2. Is the evidence missing, or did the activity not happen? “Unable to determine” is different from confirmed nonperformance, but both can affect the control conclusion.
3. Was an alternative method authorized at the time? Identify the exact procedure provision.
4. Did it achieve the same objective, on time, with retained evidence? If yes, explain its effect. If no, it is not compensating.
5. Does the exception expose other accounts? A configuration defect or missing queue can require population expansion, not just one finding.

A compensating control does not delete the original exception. Suppose the automated identity vendor failed to return a result, but a trained reviewer completed an approved documentary review before activation and retained all required metadata. The automated-control attribute failed. The overall identity-verification objective may still have been achieved. Record both facts.

Contrast that with a manager reviewing the file after the tester requests it. That is remediation evidence, not a historical compensating control.

Test the 2025 TIN Exemption as Its Own Stratum

The June 27, 2025 interagency exemption order lets banks under the OCC, FDIC, or NCUA optionally obtain TIN information from a third-party source rather than directly from the customer. It does not remove the TIN requirement or the reasonable-belief standard.

For accounts using the exemption, test whether:

• the bank was within the order’s scope;
• the procedure authorized the specific third-party source;
• the TIN was obtained before account opening;
• the source and method were covered by the bank’s risk assessment;
• identity verification still supported a reasonable belief about the customer; and
• source failures, mismatches, and unavailable TINs followed defined escalation paths.

Do not mix these accounts into a general sample without identifying them. The control path is different, so the evidence is different.

Write a Conclusion That Matches the Results

The conclusion should state scope, population, selections, exceptions, limitations, and the effect on the control objective.

Example—effective with isolated exceptions:

We tested the bank’s CIP controls for deposit accounts opened from January 1 through March 31, 2026. The reconciled population contained [count] accounts. We tested [count] population-based selections and [count] targeted selections. [Count] population-based items and [count] targeted items contained exceptions, primarily [nature]. Based on the defined decision criteria, the controls operated effectively overall, with an isolated documentation issue requiring remediation. Targeted results were not projected to the full population.

Example—cannot conclude:

We could not establish population completeness because partner-originated account openings did not reconcile to the bank’s verification system. As a result, the selected records do not provide sufficient evidence to conclude on CIP operating effectiveness for the period. Management should reconcile the omitted channel, assess affected accounts, and repeat testing on the complete population.

That second conclusion is uncomfortable—and correct. A missing population is not a footnote to an otherwise clean test.

So What?

If you inherited customer identification program testing that begins with “select 25 files,” stop before selecting anything. Map the rule to attributes. Reconcile openings to verification. Separate routine selections from targeted risk cases. Preserve every exception before evaluating alternatives.

The first-week deliverable is simple: one population-control tab, one attribute matrix, and one evidence index that another tester can reconstruct without calling the preparer. That is the difference between a checklist and a defensible CIP workpaper.

For a broader control inventory and testing calendar that can hold the CIP control family, the RCSA (Risk & Control Self-Assessment) template provides a structured starting point; tailor the control criteria and evidence to your bank’s actual CIP.

Enforcement context: the SEC’s January 17, 2025 LPL Financial release and administrative order show why unresolved identity-verification records deserve targeted testing. The broker-dealer rule differs from the bank rule, so use the case as a control-failure example—not as bank-specific legal criteria.