Automated identity verification for CIP, traced second by second

Automated identity verification checks a new customer's identity with software instead of a person: it reads the ID document, tests it for tampering, compares the applicant's name, date of birth, address and ID number with credit bureau and database records, and screens the name against sanctions lists, usually in seconds. For a bank, the hard part is what happens when those checks disagree, because the Customer Identification Program rule still asks for a reasonable belief about who the customer is and a written resolution of each substantive discrepancy. Botminds' CIP Verification is an agentic solution for that second part: its agents compare every field across every source and draft the resolution the bank's own procedure allows, and people approve it. Tracing one application through it shows exactly which steps are automated and which are not.

Where the trace starts: four fields, four sources, one conflict

How does automated identity verification work?

Automated identity verification works as a chain of checks, each answering a narrower question. A document check asks whether the ID is genuine and unaltered, reading the barcode and comparing it with the printed front. A biometric check, in remote channels, asks whether the person holding the phone is the person in the photo, and whether they are live. A data check asks whether the name, date of birth, address and number belong together in sources the applicant does not control: the credit bureau header, a non-documentary database, sometimes a phone carrier or a utility. A list check asks whether the name matches OFAC's lists or a 314(a) request.

Each check returns pass, fail or refer. Most applicants pass every one and the account opens. The CIP rule is indifferent to whether a person or a program did the checking: it asks that the procedures let the bank reasonably believe it knows who each customer really is, and that the record describe what was relied on and how discrepancies were resolved (31 CFR 1020.220). Automation earns its keep on the passes. The design question is the refers.

The trace: one application, minute by minute

Take one sample application as it runs through CIP Verification. The applicant, the credit union and every identifier are fictional. On Thursday, October 22, 2026, at 10:24 a.m., Ahmad Rezaei applies at a branch desk for a share savings account and checking with a $250 deposit. His identity verification service refers him: date of birth mismatch, address partial. The membership opens sixteen minutes later. Here is where those sixteen minutes went.

The machine checks: seconds, not minutes

The machine checks in this trace took seconds. Reading the license, pulling two more sources, comparing four fields across four sources together used well under ten seconds of logged processing. For an applicant whose data agrees everywhere, that is the whole of identity verification, and the account can open while the applicant is still at the desk or on the app.

What the machines produced, though, was more than a score. The Source Comparison agent marked each field as a match, near-match or conflict and wrote why: "The application says March 7, 1991. The license and the database say July 3, 1991, and the bureau says July 1991: the day and month are swapped on the application, a typing transposition." The address row explained that the license writes "Ln" for "Lane" and leaves out "Apt 2", and that the procedure treats unit-number and street-suffix variants as the same address. That sentence is what the person at the desk reads instead of four vendor codes.

Where the agent drafts and a person decides

The agents prepare the decision; people make it. In CIP Verification, the Resolution agent mapped the conflict to procedure step 4.5 (a transposed day and month may be corrected to the ID document's date when the member confirms it and an independent source agrees) and the address to step 4.2, and proposed both with a confidence of 0.97. Below 0.90, it would have asked a person instead. The Member Request agent picked the one request that would close the file, a one-tap confirmation rather than a document upload, and drafted it from an approved template.

The one confirmation that closed the file, and the proposal it supports

Two people then decided. Dana Whitcombe, the member service representative, proposed the resolution at 10:38 with a reason code; she could not approve it herself, because the button is disabled for the maker. Marcus Ellery, a BSA analyst, opened the proposal with its sources and approved it at 10:40. Only then did the core banking system record July 3, 1991 as Ahmad's date of birth. Had Marcus returned it, he would have chosen a reason code (evidence insufficient, wrong step, not confirmed, or other) and the file would have gone back to the desk.

The checker's screen: approve, or return with a reason

Is automated identity verification compliant with CIP?

Yes, if the automated steps sit inside a written procedure that says when each method is used and what happens when verification fails, and if the record shows what was done. Nothing in the CIP rule requires a person to perform each check; the rule requires procedures, a reasonable belief and a record. The agencies have long accepted that a bank may describe a non-documentary method once in its procedure: their 2005 FAQ says a bank may keep that description "in a general policy or procedure" instead of on each file, "provided that the record cross-references the specific provision(s) of the risk-based procedures contained in the bank's CIP used to verify the customer's identity" (interagency CIP FAQs). Citing the procedure step on every resolution is that cross-reference, made routine.

The bank stays responsible for the automation it buys. The FFIEC manual says a bank may use a third party to perform CIP services, but "the bank is ultimately responsible for compliance with the requirements of the CIP rule" (FFIEC BSA/AML Manual). For agents specifically, the April 2026 model risk guidance, SR 26-2, places generative and agentic AI outside its scope as too new and fast-moving, and leaves the controls for them to the bank's own risk management and governance (SR 26-2; agentic AI for KYC reads the carve-out in full). A maker, a checker, versioned procedure steps and a confidence threshold the BSA officer approves are what that governance looks like on the desk.

The direction of policy is encouraging but not settled. FinCEN's April 2026 proposed rule says an institution that tries new technology responsibly in its AML/CFT program would face no added risk of significant supervisory or enforcement action merely for using it (FinCEN proposed rule, 2026). It is a proposal, not a final rule.

Can a bank decline an applicant automatically?

The CIP rule does not forbid it, but federal identity guidance and good practice both say a person should confirm an automated decline. NIST's identity proofing standard is explicit for biometric searches: a service that matches one face against many must not turn an applicant away until a person has reviewed the automated result and confirmed it is not a false match (NIST SP 800-63A-4; NIST identity assurance levels for account opening sets out the levels). Regulators apply the same standard to themselves: GAO found that the financial regulators using AI never let it decide alone or treated it as their only input (GAO-25-107197).

In CIP Verification, the agents cannot decline anyone. When the sources show something no procedure step can resolve, such as a Social Security number linked to another person, the agents stop the opening, propose nothing and refer the file to the BSA officer, who decides whether to decline or ask for a second ID in a branch. The applicant sees a neutral status. Automating the decline would save a few minutes on the rarest files and put the bank's most consequential decision on its least explainable step.

Non-documentary verification automation

Non-documentary verification is where automation has the most to offer, because the rule's own examples are data comparisons: checking what the customer gave against a credit bureau, a public database or another independent source. Software does that faster and more consistently than a person reading screens. The hard cases are the ones where the absence of data is normal: an 18-year-old with no credit file, an ITIN holder who arrived last year, a service member with an APO address.

A good automated design treats those as routes, not failures. In the sample data, an ITIN applicant with a passport and no bureau file is not marked as a conflict; the agents look for an independent source for the address instead, find a utility account held since June 2023, and propose verification with the passport and that record under the procedure's step for ITIN applicants. A person still approves it. The five routes the CIP rule names sets out how each such situation should be written into a procedure.

What to ask of automated identity verification software

Ask any vendor to run its product on a sample of your own past exceptions, with your procedure, and to show the following on screen. A vendor that can only show its passes is selling the easy half of the problem.

Where CIP Verification fits in an automated identity verification stack

CIP Verification sits after the identity verification service, not in place of it. The vendor checks documents, selfies and liveness and returns its results; the solution reads those results with the bureau header and the database, explains the exceptions, proposes the resolution the bank's procedure allows and keeps the record. It connects to the systems an account opening already uses: the core banking system (written only after approval), the digital account opening platform, document imaging, the credit bureau, and the bank's OFAC and 314(a) screening.

What it leaves behind is the part an examiner reads. Ahmad's file is kept in the rule's four parts, with the versions in force: procedure version 9, the Resolution agent's version and threshold, the list dates. Internal audit can replay it step by step.

The trace, kept: the CIP record with a replay of every step

The trace also shows what a bank should measure in a pilot: not the seconds of machine time, which every vendor can show, but the minutes of human time per exception and the share of proposals a checker returns. Where the CIP minutes actually go puts numbers on that, and the CIP Verification page describes the solution in full.

Questions people ask

Is automated identity verification the same as KYC?

No. Automated identity verification answers who the customer is, which is the CIP part of KYC. Customer due diligence goes further, into the nature and purpose of the relationship, beneficial owners for legal entities and a risk profile.

How accurate is automated ID verification?

It varies widely by product, phone and document. Government-sponsored testing has found large differences between commercial systems, and the remote ID verification go-live plan sets out those results and how to test a product on your own applicants before relying on it.

Can an AI agent approve a CIP exception?

Nothing in the CIP rule names who approves, but SR 26-2 leaves agentic AI to each bank's own governance, and examiners look for dual control. A design in which agents propose and a named person approves is the defensible one.

Does automation change what goes in the CIP record?

No. The record still holds the identifying information, the document relied on, the non-documentary methods and results, and the resolution of each discrepancy. Automation can make every one of those parts complete and consistent, and can add the versions that decided it.

How long does automated identity verification take?

The checks themselves take seconds; in the sample trace each logged step took about a second. The elapsed time on an exception is the applicant's reply and the people who propose and approve, sixteen minutes in that file.