Remote ID verification software lets a bank verify a new customer who is not in the branch: the applicant photographs an ID, takes a selfie, and the software checks the document for tampering, matches the face, tests for liveness and compares the details with independent data. Buying it is the easy part. Going live under the Customer Identification Program rule means deciding what the bank does with every applicant the software cannot clear, writing that into the procedure, and proving on past files that the decisions hold. Botminds' CIP Verification is an agentic solution for that second half: it sits beside the bank's remote ID vendor, takes the files it refers, compares every field across every source and drafts the resolution the procedure allows, for people to approve. This page sets out an eight-week plan for both halves.
What remote ID verification software does, and what stays with the bank
The remote ID vendor
- Captures the ID, front, back and barcode, and checks it for tampering
- Matches the selfie to the ID photo and tests that the person is live
- Compares details with bureau and database records
- Returns pass, refer or fail, with reasons
The bank, by rule and good practice
- A written procedure saying which method applies when
- A route for each situation the rule names, such as no current photo ID
- A person who confirms any automated decline or adverse result
- A resolution of each substantive discrepancy, recorded
- The decision to open, restrict, close or report
What remote ID verification software does, and what it leaves
Remote ID verification software answers three questions quickly: is the document genuine, is the person presenting it the person in the photo, and do the details agree with independent records. For most applicants the answer to all three is yes, and the account can open in minutes. What it leaves is every file where an answer is "no" or "not sure", and the CIP rule is explicit that those are the bank's: the procedure must address an applicant who never comes into a branch, one who has no current government photo ID to show, and every case where the bank cannot reasonably believe it knows who the customer really is (31 CFR 1020.220).
That is why a go-live plan that is only an integration plan fails in week one of production. The vendor's refers arrive in a queue nobody has designed, the analysts improvise, and the files say "verified" without saying why. The eight weeks below are mostly about that queue.
What IAL do banks need?
No US banking rule names an identity assurance level, but NIST's levels are the clearest public yardstick for remote proofing, and FATF's digital identity guidance "primarily refers to" them (FATF, 2020). Under NIST SP 800-63A-4, IAL2 can be performed remotely and is built to resist attacks at scale or aimed at one person, as well as simple forgery, stolen evidence and social engineering. IAL3 "adds the requirements for a trained CSP representative (i.e., proofing agent) to interact directly with the applicant as part of an on-site attended identity proofing session" and a biometric (NIST SP 800-63A-4).
So for remote account opening, IAL2 is the highest NIST level available without bringing the applicant to a site, and the practical target is to buy software that can show it meets IAL2's evidence and verification requirements. That is a design target for the vendor, not a CIP requirement; the CIP rule asks for a reasonable belief, and a bank may reach it with other evidence on the files that fall short.
The international position has moved in the same direction. In February 2025 FATF amended its standards so that non-face-to-face relationships count as a possible higher-risk factor only when the bank has not put suitable safeguards in place (FATF, February 2025; digital account opening after FATF's 2025 change reads the amendment). Remote opening is not riskier in itself; it is as safe as the controls a bank can show.
How good is remote document validation?
It varies far more than vendor brochures suggest. In the Department of Homeland Security's Remote Identity Validation Rally, run at the Maryland Test Facility, seven document validation systems were tested with genuine and fake IDs photographed on several smartphones. The worst-case rate at which each accepted a fraudulent document ranged from under 0.88% for the best system to under 76.68% for the weakest (Maryland Test Facility).
Worst-case rates at which seven systems accepted fake IDs
Two further findings matter for a go-live. DHS's summary of the earlier technology demonstration says "Validation Errors Depended on Document State of Issuance" and on "the Smart Phone Used to Collect the Image", and warns that "System deployers should ensure compatibility with their users' documents and devices" (DHS Science and Technology). A product that performs well on one state's licence and one phone may not on your applicants'. The only test that answers that is a test on your own past applications.
Do we need to update our CIP policy for remote opening?
Yes, if the written CIP does not already describe the remote channel's methods and what happens when they fail. The rule requires procedures that "describe when the bank will use documents, non-documentary methods, or a combination of both"; adding a remote channel adds a "not in person" situation and usually new non-documentary methods (a selfie match, a liveness check, a device signal), and each needs a line in the procedure and a place in the record.
The European guidelines put the design question well. The EBA asks institutions to state which steps run with no person involved and which need one, and to monitor the solution through quality assurance testing, "sample testing" and "manual reviews" (EBA/GL/2022/15). They are not US law, but a US procedure that answers the same question in writing is easier to defend.
The eight weeks, week by week
The plan runs two tracks in parallel: the procedure, owned by the BSA officer, and the systems, owned by IT and operations. Neither can finish without the other, and the pilot in weeks six and seven is where they meet.
An eight-week plan to take remote ID verification live under the CIP
- Map exceptions to routes and stepswk 1–2
- IAL target, thresholds, review ruleswk 3
- Messages and reason codeswk 4
- Procedure version approvedwk 5
- Pilot reviewwk 6–7
- Sign-off to widenwk 8
- Read-only connectionswk 1–3
- Back-test on past exceptionswk 4–5
- Pilot: one branch and onlinewk 6–7
- Live in stageswk 8
Weeks 1 and 2: map the exceptions. Pull a quarter of past refers and classify them: address variants, recent movers, name variants, date of birth errors, expired or unfamiliar documents, thin files, ITIN applicants, military addresses, number conflicts. Give each a numbered step in the procedure with the evidence it needs and the resolution it allows, and a separate step for files no step can resolve. The five routes the CIP rule names is the skeleton.
Week 3: set the rules. Decide the vendor's pass, refer and fail thresholds; the confidence below which the agents must ask a person; who may approve what; and that no automated result declines an applicant without a person's review. Week 4: write the messages. Each request to an applicant comes from an approved template, asks for one thing, and never hints at a referral. Week 5: approve the procedure as a new version, so every file from go-live cites it.
Weeks 4 and 5, systems: back-test. Run the solution on resolved exceptions from the past quarter, with the original decisions held back, and compare: where it proposed what the analysts decided, where it proposed something else, and where it asked a person. Weeks 6 and 7: pilot in one branch and the online channel, with every proposal still approved by a BSA analyst and a sample re-reviewed by the BSA officer. Week 8: widenchannel by channel, keeping the sampling on.
A route written into the procedure: an ITIN applicant with no credit file
How long to implement identity verification?
Connecting a remote ID vendor is an IT project of its own; implementing identity verification under the CIP takes as long as writing and testing the procedure for its exceptions, which is why this plan is eight weeks and not two. Banks that already have a numbered exception procedure, clean reason codes and a quarter of resolved files can move faster; banks whose exception decisions live in email threads should expect the first two weeks to stretch.
The settings a bank has to decide are few, but each is a policy choice with an owner. The table lists the ones CIP Verification exposes, with the sample defaults.
Settings to decide before go-live, with CIP Verification's sample defaults
| Setting | Sample default | Who decides |
|---|---|---|
| A file is due | 4 business hours after the exception opens | BSA officer with operations |
| When a file passes its time | Escalate to the BSA officer and tell the branch manager | BSA officer |
| Agents propose at confidence | 0.90; below it, they ask a person | BSA officer, as a versioned change |
| Name similarity for OFAC review | 0.85 | BSA officer |
| Reminders to the applicant | After 1 and 3 business days | Operations |
| An edited message needs a BSA analyst | On | BSA officer |
| Accept a TIN from a third-party source | Off | BSA officer, under the 2025 orders |
What the pilot must measure
The pilot must measure the exceptions, not the passes. Pass rates are the vendor's number; the bank's numbers are how many files were referred, how long each took to resolve, how many proposals the analysts returned and why, and whether any account opened with an unresolved field. The 2018 joint statement of the banking agencies and FinCEN gives room to try: a pilot should not, by itself, draw supervisory criticism, even one that fails (Joint Statement, 2018).
Before widening beyond the pilot, confirm
- Every exception type seen in the pilot has a procedure step
Or a decision to add one. Unmapped files are the ones that end up saying “verified”.
- No automated result declined anyone
Every refusal was reviewed by a person, as NIST requires for automated biometric hits.
- The maker never approved their own proposal
In single or bulk approvals.
- Returned proposals have reason codes, and the codes point somewhere
A cluster on one step means the step needs rewriting.
- Referrals stayed restricted
Applicants and branch staff saw a neutral status only.
- The record is complete in four parts on a sample of files
Re-reviewed by someone who did not work them.
- The vendor performs on your documents and phones
Refer and failure rates by issuing state and device, not just overall.
What the pilot reports, in CIP Verification
Where CIP Verification fits beside your remote ID vendor
CIP Verification is not remote ID verification software, and the distinction matters to a buyer. It does not capture documents, match selfies or test liveness; the bank's vendor does that. It takes the files the vendor refers, reads the application and the ID, pulls the credit bureau header and a non-documentary database, compares the four CIP fields across every source, explains each difference and proposes the resolution the bank's own procedure step allows. A member service representative proposes and a BSA analyst approves; nothing is written to the core system until then.
That makes it a fit for banks that already have, or are buying, a remote ID vendor and want the exceptions handled consistently and recorded properly. It is not a fit for a bank looking for its first document and selfie check; buy that first, and come back to the exceptions once there is a queue. The CIP Verification go-live begins exactly where weeks one and two do: with a sample of the bank's own past exceptions and its CIP procedure.
A service member's APO address, handled by the step the bank wrote for it
What the bank keeps at the end of eight weeks is more than a connection: a versioned procedure, a set of reason codes, a measured baseline and a record that will stand up to an examiner's CIP sample. The solution is described in full on the CIP Verification page.
Questions people ask
What is remote identity verification?
Remote identity verification confirms who an applicant is without meeting them, usually by checking a photographed ID for tampering, matching a selfie to it with a liveness test, and comparing the details with independent records. Under the CIP rule it is one of the situations that require non-documentary procedures.
Is NIST 800-63 required for banks?
No. It is written for federal agencies and is voluntary for banks. It is still the most detailed public standard for remote identity proofing, and FATF's digital identity guidance refers to it, which makes it a sound yardstick for a vendor evaluation.
Can a bank open accounts entirely remotely?
Yes. The CIP rule plans for customers who do not appear in person, provided the procedure covers that situation with non-documentary methods and says what happens when verification fails. FATF no longer treats non-face-to-face relationships as higher risk where appropriate mitigation is in place.
Should we pilot remote ID verification on part of the book?
Yes. A pilot in one branch and one channel, with every decision still approved by a person, shows how the vendor performs on your applicants' documents and phones. The 2018 joint statement says pilots that fail should not by themselves draw supervisory criticism.
What does remote ID verification software cost?
Prices are rarely published; ask whether a product is priced per check, per account or per exception, and what volume does to the rate. The larger cost is often staff time on the exceptions the software refers, which is why the pilot should measure minutes per exception as well as the price per check.