Listen To Our Podcast🎧
How should a bank choose KYC software?
Every KYC vendor demo goes well. The sample passport scans cleanly, the selfie matches, the liveness check passes and the dashboard turns green. None of that tells you what happens when the passport is a generated image, the selfie arrives through a virtual camera, or the applicant is a person who doesn't exist.
This guide is for the Head of Onboarding and the CTO who have to pick KYC software together and defend the choice later. It doesn't rank vendors, and it names none. Instead it gives you a way to decide what "best" means for your bank, a proof-of-concept test plan built around document fraud, liveness and synthetic identity cases, the measures to score it with, and the questions to put to a vendor before you sign.
It reflects the US customer identification program rule, the European Banking Authority's remote onboarding guidelines, NIST SP 800-63A-4 and FinCEN's deepfake alert as they stood on 3 November 2026. It isn't legal advice. Check the current text with your counsel and supervisor before you change a procedure or sign a contract.
- What KYC software has to help a bank prove under the US CIP rule and the EBA remote onboarding guidelines.
- Where onboarding checks fail in 2026: forged documents, presentation attacks, injected media and synthetic identities.
- How to define "best" for your own channels and customers before you look at a vendor.
- A KYC proof-of-concept test plan, with the cases to build and the measures to score them.
- The vendor evidence and contract terms to secure before you sign, and where AI agents fit.
Request a KYC POC test plan
The best KYC software for a bank is the one that passes your own test plan, not the best demo. Under the US CIP rule and the EBA remote onboarding guidelines, it has to produce evidence of how each customer was verified. Test every vendor on the same cases: altered and generated documents, presentation and injection attacks, synthetic identities and fairness, with thresholds fixed before testing.
What does a bank's KYC software have to prove?
KYC software doesn't make a bank compliant. It produces evidence that the bank's own procedures worked for each customer, and the first question for any product is whether its output answers the questions your rules ask.
- The CIP rule feeds the test plan with the evidence and record questions. The EBA guidelines feed the test plan with the pre-implementation and end-to-end tests. NIST SP 800-63A-4 feeds the test plan with measures and test standards. FinCEN's deepfake alert feeds the test plan with the attack cases. The test plan then goes to the contract as acceptance criteria.
US banks: the customer identification program rule
For US banks the floor is the customer identification program (CIP) rule at 31 CFR 1020.220. It requires risk-based procedures for verifying the identity of each customer to the extent reasonable and practicable, and those procedures must let the bank form a reasonable belief that it knows the true identity of each customer.
The rule sets a minimum data set before an account opens: name, date of birth for an individual, an address and an identification number. Verification can use documents, non-documentary methods or both, and the procedures must say which the bank uses and when.
Two parts of the rule matter more for software selection than they first appear. The first is the lack-of-verification procedure. The CIP must describe when the bank should not open an account, the terms under which a customer may use an account while verification continues, when to close an account after verification fails, and when to file a Suspicious Activity Report.
A tool that returns only "pass" or "fail" can't support those branches. You need the reason for the result, the checks that ran and the ones that didn't.
The second is the record. The bank must keep a description of any document relied on, including its type, number, place of issuance and dates, and a description of the methods and results of any measures undertaken to verify identity. Identifying information is kept for five years after the account is closed, and the descriptions of documents, methods and results for five years after the record is made.
If your vendor keeps the verification evidence and you keep only a status flag, you don't have that record.
The rule also requires procedures for checking whether the customer appears on any federal government list of known or suspected terrorists or terrorist organizations, and adequate notice to customers that the bank is requesting information to verify their identities.
Banks also have to run ongoing customer due diligence. The bank AML program rule at 31 CFR 1020.210 requires risk-based procedures for understanding the nature and purpose of customer relationships to develop a customer risk profile, and for ongoing monitoring to identify and report suspicious transactions and, on a risk basis, to maintain and update customer information.
That's why the onboarding file matters after day one: it's the baseline later reviews compare against.
EU institutions: the EBA remote onboarding guidelines
In the EU, the EBA's guidelines on the use of remote customer onboarding solutions have applied since 2 October 2023. They are the closest thing to a regulator-written KYC software test plan.
Before adopting a new remote onboarding solution, an institution should carry out a pre-implementation assessment. That assessment should cover the completeness and accuracy of the data and documents the solution collects, the reliability and independence of its sources, tests of fraud risks including impersonation, and end-to-end testing on the customers, products and services in scope. The institution should be able to show its competent authority which assessments it carried out and what they found.
The guidelines also ask policies to state which steps are fully autonomised and which steps require human intervention.
For unattended onboarding, where the customer doesn't interact with an employee, institutions should perform liveness detection and use strong and reliable algorithms to match the photo or video with the picture on the official document. Where evidence is of insufficient quality, the onboarding process should be interrupted and restarted or redirected to a face-to-face verification. Where possible, solutions should include randomness in the sequence of actions the customer performs, to guard against synthetic identities or coercion.
The guidelines don't stop at go-live. Institutions should monitor the solution on an ongoing basis, and ad hoc reviews should be triggered by changes in risk exposure, deficiencies found in monitoring or audit, a perceived increase in fraud attempts and changes to the legal framework.
The EU framework is moving. AMLA's list of regulatory instruments shows the draft regulatory technical standards on customer due diligence under AMLR Article 28(1) as "Final report published", and draft guidelines on ongoing monitoring of business relationships as "Consultation closed". If you onboard EU customers, ask each vendor how it will track those instruments as they're adopted.
NIST SP 800-63A-4: a measurable benchmark
NIST SP 800-63A-4, published in July 2025, sets identity proofing requirements for US federal agencies and their credential service providers. NIST states that the publication may be used by nongovernmental organizations on a voluntary basis.
It isn't bank regulation. It's useful here because it does what most rules don't: it puts numbers and test standards on document checks, biometric matching, liveness and injection defence. This guide uses it as a reference point for the test plan, not as a legal requirement.
The first figure shows how these sources feed one test plan. The CIP rule feeds the test plan with the evidence and record questions. The EBA guidelines feed the test plan with the pre-implementation and end-to-end tests. NIST SP 800-63A-4 feeds the test plan with measures and test standards. FinCEN's deepfake alert feeds the test plan with the attack cases. The test plan then goes to the contract as acceptance criteria.
Where does KYC software fail in 2026?
Most KYC failures don't look like failures at the time. The account opens, the checks are green, and the problem surfaces months later as fraud losses, a funnel account or a SAR.
- An applicant device sends a selfie or document image toward the capture point. An injection attack inserts forged media between the capture point and the comparison engine. Genuine sensor checks sit between the capture point and the comparison engine to detect a virtual camera, device emulator or jailbroken device. The comparison engine sends its result to the onboarding file. Flagged sessions go from the onboarding file to manual review.
Generated documents and synthetic people
FinCEN's November 2024 alert on deepfake media describes criminals using generative AI to alter or generate images used for identification documents, such as driver's licenses or passport cards and books. It also reports that criminals have combined those images with stolen personal information, or with entirely fake information, to create synthetic identities. FinCEN defines a synthetic identity as a combination of real and fake personal information used to fabricate a person or entity to pass validation processes.
According to the alert, FinCEN's analysis of BSA data shows that malicious actors have opened accounts with fraudulent identities suspected to have been produced with generative AI, and used those accounts to receive and launder the proceeds of other fraud schemes. FinCEN also notes that financial institutions often detect this content by re-reviewing a customer's account opening documents.
That last point is uncomfortable for buyers. It means the first check often missed it, and the catch came later from someone looking again.
If your own re-reviews have found generated or synthetic identity documents that passed onboarding, put those exact cases in the proof of concept. They are the attacks your current checks already let through.
Presentation attacks and injected media
A presentation attack holds something up to the camera: a printed photo, a screen replay, a mask. Liveness detection, which NIST calls presentation attack detection, is built to catch those.
Injection attacks are different. NIST describes them as attacks that insert modified or forged media between the capture point, such as a device, and the element conducting the comparison. NIST is direct about the limit of a biometric match here: a biometric comparison performed with a captured sample does not prevent these attacks. Live document capture and presentation attack detection make injection harder, but NIST says even these mechanisms are not sufficient to address all possible cases.
FinCEN's red flags show what that looks like from the bank's side. They include a customer using a third-party webcam plugin during a live verification check, or attempting to change communication methods because of excessive or suspicious technological glitches. They also include a photo that is internally inconsistent or inconsistent with other identifying information, multiple identity documents that are inconsistent with each other, and geographic or device data that is inconsistent with the customer's identity documents.
The second figure shows the attack path. An applicant device sends a selfie or document image toward the capture point. An injection attack inserts forged media between the capture point and the comparison engine. Genuine sensor checks sit between the capture point and the comparison engine to detect a virtual camera, device emulator or jailbroken device. The comparison engine sends its result to the onboarding file. Flagged sessions go from the onboarding file to manual review.
Where the gaps usually sit
Read against NIST's requirements, failures cluster in five places:
- Document checks that look at the image but don't test whether the document was physically present.
- Liveness checks tested only against printed photos and screen replays, not against injected video.
- Identity data checks that confirm each attribute exists but never ask whether the attributes belong together, or whether the person is alive.
- Thresholds tuned on the vendor's data, not on your applicants, devices and document types.
- Results that reach your systems as a score, with the evidence left in the vendor's console.
The pillar guide to KYC and digital identity verification covers how document, biometric and liveness checks fit together. The rest of this guide turns those gaps into tests.
How should you define "best" before you look at vendors?
"Best KYC software" lists usually rank products on features. A bank can't buy that way, because the best product for a branch-led bank with mostly domestic customers is rarely the best one for a mobile-only bank onboarding non-resident applicants.
Define your own inclusion criteria first, then score every product against them on your own data. Keep the order of your shortlist tied to use cases you've written down, not to a vendor's marketing or an undisclosed league table.
Start with your channels and customers
Write these down, in this order, before any demo:
- Your onboarding channels: branch, mobile app, web, assisted video, partner or broker.
- Your customer types. This guide covers individuals. Business customers add know your business checks, such as registry data and beneficial ownership, which need their own test plan.
- The document types you accept, by country of issue.
- Your applicants' devices, including older phones and low-end cameras.
- Your risk appetite for unattended onboarding, and which customer segments must go to an attended or face-to-face route.
Then weight the criteria by use case
| Your situation | Weight most heavily | Why |
|---|---|---|
| Mobile-only onboarding, mostly unattended | Injection defence, liveness under attack, device signals | Nobody from the bank sees the applicant |
| Many foreign documents | Document coverage by country and type, MRZ and barcode checks, manual review route | Coverage gaps push applicants into slower routes |
| High synthetic identity exposure, such as credit products | Data consistency and linkage checks, deceased-person checks, re-review support | Synthetic identities pass attribute-by-attribute checks |
| Branch or assisted onboarding | Staff tooling, document inspection support, record quality | People do the inspection; the tool supports and records it |
| Several regulators across markets | Configurable rules per market, record export, data residency | One flow rarely fits every jurisdiction |
Know your customer covers more than identity proofing: customer due diligence, risk rating and ongoing monitoring sit on top of it. Decide which of those the product must do and which stay in other systems before you compare prices.
What should be in a KYC proof-of-concept test plan?
A proof of concept that runs only genuine customers proves that good customers can get through. It says nothing about who else can. The test plan below adds forged and altered documents, presentation and injection attacks, synthetic identities and the fairness checks NIST sets for biometrics.
- The test case library goes to the vendor run on your devices and document mix. The vendor run produces scored results by case. Scored results go to the review panel from onboarding, compliance and fraud. The review panel makes the go or no-go decision against the thresholds set before testing. Missed attack cases go back from the review panel to the test case library for a retest after any vendor change.
Build the attack cases yourself or with a testing partner, under your own security and privacy controls. Don't rely only on the vendor's test files.
Document fraud cases
NIST SP 800-63A-4 sets two measures for automated document validation: a document false acceptance rate (DFAR) of 0.1 or less and a document false rejection rate (DFRR) of 0.1 or less. DFAR is the share of fraudulent documents the system accepted as valid, and DFRR is the share of genuine documents it rejected.
NIST also requires that where a machine-readable zone or barcode is present, the check compares it with the printed data for consistency. It requires live capture of documents with passive or active document presence checks, so the image isn't a manipulated digital copy.
Your cases should include genuine documents for every type and issuing country you accept; altered genuine documents with a changed photo, name or date; generated document images; screen and print re-captures; expired documents; and documents whose MRZ or barcode doesn't match the printed fields.
NIST requires that these tests run in conditions substantially similar to the operational environment, covering the evidence types the user base presents. If customer documents are used in testing, NIST says it should be on a voluntary basis with notification and consent.
Liveness and presentation attack cases
For remote biometric capture, NIST requires presentation attack detection that meets an impostor attack presentation accept rate (IAPAR) below 0.07, with tests conformant to ISO/IEC 30107-3:2023.
Your cases should include printed photos, screen replays, video replays and masks, captured on the device types your applicants use. Ask the vendor for its independent PAD test report and check which attack types and devices it covered.
Injection and deepfake cases
This is where many proofs of concept are weakest. NIST requires technical controls to increase confidence that digital media is produced by a genuine sensor, for example by detecting a virtual camera, device emulator or jailbroken device. It also requires analysis of all submitted media for signs of modification or forgery.
Automated image analysis must be tested against available attack artifacts and genuine media to establish expected false positive and false negative rates. The attack types tested and the corresponding false negative rates must be documented and made available on request.
Your cases should include a virtual camera feeding pre-recorded video, an emulator session, a face-swapped video stream, and a generated face matched to a generated document. Add a session that claims repeated technical glitches and asks to switch channels mid-check, since FinCEN lists that behaviour as a red flag.
Synthetic identity cases
Synthetic identities defeat checks that ask "does this attribute exist?" rather than "do these attributes belong to one living person?"
NIST requires credential service providers to confirm with a credible, authoritative or issuing source that the applicant is not deceased, noting that such checks can aid in preventing synthetic identity fraud. Its recommended fraud checks also include SIM swap detection and device or account tenure checks.
Your cases should include a real identification number paired with a different name and date of birth, a new identity with thin or no history, an identity belonging to a deceased person, and several applications sharing a device, phone number or address. Score whether the product flags the inconsistency, explains it and routes the application to review, not just whether it returns a lower score.
Fairness and false rejection cases
A product that rejects too many genuine applicants from one group creates a conduct problem as well as a conversion problem.
For 1:1 biometric verification, NIST sets a false match rate of 1:10,000 or better and a false non-match rate of 1:100 or better. It also requires that performance for any demographic group be no more than 25% worse than for the overall population, with a fixed threshold, considering sex, age and skin tone where these affect performance.
NIST requires independent testing of biometric recognition and attack detection algorithms, including performance across demographic groups. Ask for those reports, then check your own results by segment, including older devices and poor lighting.
Evidence and record cases
For every test application, check what lands in your systems. Can you see which checks ran, which were skipped, the reason for each result and the images or data relied on? Could you rebuild the CIP record from it five years from now? Does a failed or inconclusive check route to a person with enough context to decide?
NIST says algorithmic analysis and automated decisioning should be augmented by manual reviews to address detection errors. Where a 1:N search suggests an applicant is already enrolled under another name, NIST says enrollment shall not be declined without a manual review to confirm the automated result.
The test plan at a glance
| Test area | Cases to build | Measure | Reference point |
|---|---|---|---|
| Document validation | Genuine documents per type and country; altered, generated, re-captured and expired documents; MRZ or barcode mismatch | DFAR, DFRR, MRZ consistency result | NIST: DFAR and DFRR of 0.1 or less; MRZ compared with printed data |
| Document presence | Screen and print re-captures of genuine documents | Share of re-captures accepted | NIST: live capture with document presence checks |
| Presentation attacks | Printed photos, screen and video replays, masks | IAPAR by attack type and device | NIST: IAPAR below 0.07; ISO/IEC 30107-3:2023 testing |
| Injection and deepfakes | Virtual camera, emulator, face-swap stream, generated face with generated document | Detection rate per attack type; false negatives documented | NIST: genuine sensor controls; media analysis tested on attack artifacts |
| Synthetic identities | Mismatched real attributes, thin-file identities, deceased identities, shared device or phone | Share flagged and routed to review, with reason | NIST: deceased-person check; SIM swap and tenure checks |
| Biometric matching and fairness | Genuine applicants across age, sex and skin tone, on your device mix | FMR, FNMR, worst-group gap | NIST: FMR 1:10,000, FNMR 1:100, no group more than 25% worse |
| Evidence and records | Every test application | Checks run, reasons, artefacts retained, export completeness | CIP record contents and retention |
| Human review route | Inconclusive and failed cases | Time to a reviewer; context available | EBA: redirect on insufficient quality; NIST: manual review of detection errors |
The NIST figures are reference points from a federal standard. Set your own pass thresholds in writing before testing starts, approved by onboarding, compliance and fraud, and don't move them after you see the results.
The third figure shows the proof-of-concept loop. The test case library goes to the vendor run on your devices and document mix. The vendor run produces scored results by case. Scored results go to the review panel from onboarding, compliance and fraud. The review panel makes the go or no-go decision against the thresholds set before testing. Missed attack cases go back from the review panel to the test case library for a retest after any vendor change.
How do you measure the results?
Score each product on the same cases, with the thresholds fixed before testing. These measures cover what a dashboard usually hides.
| Measure | Definition | What to watch |
|---|---|---|
| Document false acceptance rate | Fraudulent test documents accepted, divided by fraudulent test documents processed | Break it down by document type and attack type |
| Document false rejection rate | Genuine documents rejected, divided by genuine documents processed | High rejection on one issuing country is a coverage gap |
| Impostor attack presentation accept rate | Presentation attacks accepted, divided by presentation attacks attempted | Results by device class, not just overall |
| Injection detection | Injection sessions flagged, by attack type | Any attack type with zero detection is a finding |
| False non-match rate | Genuine applicants wrongly failed at face match | Compare the worst group with the overall rate |
| Manual review rate | Applications routed to a person | Too low can mean missed attacks; too high can mean poor tuning |
| Time to decision | From application start to recorded approval, referral or decline | Measure on genuine applicants, by channel |
| Evidence completeness | Test applications whose full evidence arrived in your systems | Anything below all of them is a finding |
Run the genuine-customer part of the test on real applications only with the consent and privacy controls your counsel approves. Mark synthetic test identities for attack cases clearly so they never reach production records.
What should you ask a vendor before you sign?
The US banking agencies' 2023 interagency guidance on third-party relationships is clear that using a third party does not diminish or remove a bank's responsibility to perform activities safely and in compliance with applicable laws. It says due diligence includes assessing the third party's ability to perform the activity as expected, adhere to the bank's policies, comply with applicable laws and regulations, and operate in a safe and sound manner.
It also warns that relying solely on experience with or prior knowledge of a third party is not an adequate proxy for due diligence. The guidance suggests reviewing SOC reports and any conformity assessments or certifications by independent third parties, while checking whether their scope is relevant to the activity.
That matters for KYC: a SOC report on a vendor's hosting doesn't tell you anything about its liveness detection.
In the EU, where an institution outsources all or part of remote onboarding, the EBA expects it to make sure the provider applies the institution's policies and procedures, to assess the provider's technology fitness and data governance, and to make sure the provider informs it of any proposed change to the onboarding process or modification to the solution.
| Ask the vendor | Evidence to request | Why it matters |
|---|---|---|
| Which document types and issuing countries are covered, and how are new versions added? | Coverage list with dates; update process | Coverage gaps become manual work or rejected customers |
| What are your DFAR and DFRR, on what test set? | Test report with method and sample sizes | NIST sets measures; you need to know how theirs were produced |
| Has your presentation attack detection been tested independently to ISO/IEC 30107-3? | Lab report naming attack types and devices | Self-reported liveness results aren't comparable |
| How do you detect virtual cameras, emulators and injected media? | Description of controls; attack types tested and false negative rates | NIST asks for these to be documented and available on request |
| How does face matching perform across age, sex and skin tone? | Independent demographic test results | NIST sets a 25% limit on group differences |
| Which data sources do you check, and how do you test that attributes belong together? | Source list; synthetic identity test results | Attribute-by-attribute checks miss synthetic identities |
| What reaches our systems for each applicant? | Sample evidence export | The CIP record has to describe methods and results |
| Who can change thresholds or models, and how are we told? | Change policy; notice terms | The EBA expects the provider to tell you about proposed changes and modifications |
| Where is data stored and for how long, including biometrics? | Data map; retention and deletion terms | Biometric consent, retention and deletion carry legal duties |
| Can we audit, and what reports do we receive? | Contract audit clause; report list | The interagency guidance lists the right to audit and the reports to be received among contract terms |
| How do we leave? | Exit plan; data return format | You still need the records after the contract ends |
Ask for every answer in writing. If a vendor won't share the test methods behind its liveness or injection defence, you have no evidence that the defence works.
Who decides what when AI agents are part of onboarding?
AI agents can now do much of the assembly work around an application: running checks in parallel, comparing documents with the data supplied, screening the applicant, noting gaps and preparing a single file. That changes the workload but not who is accountable.
- The applicant submits documents, a selfie and personal data to the verification checks. The verification checks send their results to the AI agent layer, which prepares one file with the gaps marked. The AI agent layer sends each file to the onboarding analyst. The AI agent layer also writes every check and data version to the audit trail. The onboarding analyst refers suspicious applications to the compliance officer. The compliance officer decides on enhanced due diligence or a report, and that decision and its reasons go to the audit trail.
The CIP rule puts the procedures, and the decisions about when not to open, when to close and when to file a SAR, on the bank. The EBA guidelines ask the institution to define which steps are autonomous and which need a person.
The fourth figure shows that architecture. The applicant submits documents, a selfie and personal data to the verification checks. The verification checks send their results to the AI agent layer, which prepares one file with the gaps marked. The AI agent layer sends each file to the onboarding analyst. The AI agent layer also writes every check and data version to the audit trail. The onboarding analyst refers suspicious applications to the compliance officer. The compliance officer decides on enhanced due diligence or a report, and that decision and its reasons go to the audit trail. Autonomy settings and a kill switch sit on the agent layer, under the bank's control.
What should onboarding, compliance and technology agree before signing?
Before you sign, the Head of Onboarding, the compliance officer and the CTO should be able to tick every line of the checklist below, and agree which metrics they'll watch once the product is live.
- Proof-of-concept results go to the review panel. The review panel sends an approved product to contract terms. Contract terms go to go-live. Go-live leads to ongoing monitoring. Ongoing monitoring triggers an ad hoc review when fraud attempts rise, risk exposure changes, a deficiency is found or the rules change. The ad hoc review goes back to the review panel.
The fifth figure shows the decision gates. Proof-of-concept results go to the review panel. The review panel sends an approved product to contract terms. Contract terms go to go-live. Go-live leads to ongoing monitoring. Ongoing monitoring triggers an ad hoc review when fraud attempts rise, risk exposure changes, a deficiency is found or the rules change. The ad hoc review goes back to the review panel.
- KYC software produces evidence for your CIP and CDD procedures; the bank, not the vendor, stays responsible for them.
- The CIP rule requires a record describing documents relied on and the methods and results of verification, kept for five years.
- The EBA expects a pre-implementation assessment with fraud and end-to-end tests, then ongoing monitoring with ad hoc reviews.
- NIST SP 800-63A-4 gives measurable reference points for document checks, liveness, face matching, fairness and injection defence.
- Agents can prepare the onboarding file; analysts and the compliance officer decide accounts, enhanced due diligence and reports.
Conclusion
There isn't a best KYC software for banks in general. There's a product that holds up on your channels, your documents, your applicants' devices and the attacks your fraud team is already seeing. The CIP rule tells you what the record must hold. The EBA guidelines tell you to test before go-live and keep testing after it. NIST gives you measures to score with, and FinCEN's alert tells you what attackers are doing with generated media.
Write your criteria and thresholds first. Then run every vendor through the same cases, and keep the decisions with your onboarding team and compliance officer.
Request a KYC POC test plan
Frequently Asked Questions
About the author
Sahil Kataria
Founder and CEO of FluxForce
Share this article