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.
Inclusion criteria, attack cases and thresholds the Head of Onboarding, compliance and the CTO agree before any vendor runs a single case.
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.
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.
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.
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, 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.
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.
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.
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.
Read against NIST's requirements, failures cluster in five places:
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.
"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.
Write these down, in this order, before any demo:
| 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.
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.
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.
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.
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.
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 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.
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.
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.
| 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.
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.
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.
Illustrative scenario, not a customer result.
The bank and every detail below are invented to show the process. They aren't drawn from a real case.
A regional bank opens most new retail accounts through its mobile app, and its current KYC tool returns a single score. After a run of fraud losses on newly opened accounts, a re-review of account opening documents finds several generated identity photos that passed every check, the pattern FinCEN described in its deepfake alert.
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 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.
Verification checks feed an AI agent layer that prepares one file with gaps marked; the onboarding analyst decides each application; the compliance officer decides EDD and reports; every step goes to the audit trail.
| Component | Responsibility | Boundary |
|---|---|---|
| Onboarding analyst | Reviews each referred application and its file, then approves, requests more information or declines, with a reason. | Doesn't change thresholds or policies. |
| Compliance officer or MLRO | Owns the CIP and CDD procedures, and decides on enhanced due diligence and on suspicious activity reporting. | Doesn't delegate those decisions to software. |
| AI agent layer | Runs and gathers the checks, compares documents and data, screens the applicant, lists missing items and prepares the file with its reasoning. | Doesn't open, decline or close accounts, or file reports, on its own. |
| Fraud team | Owns the attack case library, reviews fraud signals and feeds confirmed cases back into testing. | Doesn't approve accounts. |
| Technology and model risk | Tests and monitors the checks, thresholds and agent behaviour, independent of the build. | Doesn't decide individual applications. |
The onboarding analyst decides each application, the compliance officer decides enhanced due diligence and reports, the bank sets how much each agent does on its own, and any agent can be stopped with its kill switch.
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.
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.
Voluntary use by nongovernmental organizations; DFAR and DFRR; MRZ comparison; document presence; PAD IAPAR and ISO/IEC 30107-3:2023; injection controls and media analysis; death records, SIM swap and tenure checks; FMR, FNMR and the 25% demographic limit; independent testing; manual review.
US federal identity proofing standard; a benchmark for banks, not bank regulation. Supersedes SP 800-63A.
2026-11-03
GenAI-altered and generated identity documents; synthetic identities; accounts opened and used to launder fraud proceeds; detection on re-review; red flags including webcam plugins, channel switching and inconsistent photos, documents and device data.
US financial institutions; an alert, not a rule.
2026-11-03
Risk-based verification and reasonable belief; minimum data; documentary and non-documentary methods; lack-of-verification procedures; record contents and five-year retention; government list check; customer notice.
US banks; eCFR current text, last amended 2020-11-16 (versioner checked 2026-11-03).
2026-11-03
Ongoing customer due diligence: nature and purpose of customer relationships for a customer risk profile; ongoing monitoring; updating customer information.
US banks; eCFR current text, last amended 2020-11-16 (versioner checked 2026-11-03).
2026-11-03
Apply from 2 October 2023; pre-implementation assessment and end-to-end testing; autonomous and human steps; liveness and matching for unattended onboarding; redirect on insufficient quality; randomness; ongoing monitoring and ad hoc review triggers; outsourcing, including notice of changes.
EU credit and financial institutions under Directive (EU) 2015/849; AMLR instruments pending.
2026-11-03
Bank responsibility unchanged by using a third party; due diligence scope; prior knowledge not a proxy; SOC reports and certifications with relevant scope; right to audit and reports in contract negotiation.
US banking organizations supervised by the Federal Reserve, FDIC and OCC. On 2026-11-03 the Federal Reserve SR 23-4 page showed no supersession or rescission note (last update 7 June 2023); legal confirmation PENDING.
2026-11-03
Status of the draft CDD RTS under AMLR Article 28(1) and the draft guidelines on ongoing monitoring under AMLR Article 26(5).
EU; status page retrieved 2026-11-03.
2026-11-03
Product capabilities for individual applicants (document, selfie and liveness checks, synthetic identity flags, sanctions screening, risk rating, human approval, timestamped file). Observation-mode pilot wording and the individuals-only limit come from the user-supplied Q4 calendar workbook.
FluxForce page and calendar workbook; product and CTA claims only.
2026-11-03
| Metric | Definition | Decision guardrail |
|---|---|---|
| Early-life fraud rate | Confirmed fraud on accounts under 90 days old, per thousand openings. | A sustained rise triggers an ad hoc review. |
| Re-review findings | Accounts found on re-review to have opened on forged or synthetic identities. | Each finding goes back into the test case library. |
| Referral rate by channel | Applications sent to a person, by channel. | Large swings after a vendor change are investigated. |
| Genuine rejection rate by segment | Genuine applicants rejected, by age band, device class and document country. | Any segment far above the overall rate is a finding. |
| Evidence completeness | Approved accounts with a full evidence record. | Anything short of every account is a finding. |
| Change notices | Vendor changes received with advance notice. | Any unannounced change is escalated. |
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.
There's no single best product. The best fit is the one that passes your own test plan: document fraud, presentation and injection attacks, synthetic identities and fairness checks, on your channels and devices, with a complete evidence record in your systems. Rank products against criteria you write down before the demos.
Test genuine applicants and attacks. Build cases for altered and generated documents, screen and print re-captures, printed-photo and replay attacks, virtual camera and face-swap injection, and synthetic identities built from mismatched real attributes. Score each product on the same cases with thresholds fixed in advance.
No. Liveness, or presentation attack detection, catches attacks held up to the camera. Injection attacks insert forged media between the device and the comparison step, and NIST says a biometric comparison performed with a captured sample doesn't prevent them. Test injection defences separately.
Not as regulation. It was written for US federal agencies and their providers, and NIST says other organizations may use it voluntarily. It's useful as a benchmark because it sets measurable requirements for document validation, liveness, face matching, demographic performance and injection defence.
Under the CIP rule, the bank keeps the identifying information obtained, a description of any document relied on and a description of the methods and results of verification. Identifying information is kept for five years after the account closes, and the descriptions for five years after the record is made. Make sure that evidence reaches your own systems as well as the vendor's.
The EBA's guidelines expect a pre-implementation assessment covering data quality, fraud risks including impersonation and end-to-end testing, with results the institution can show its competent authority. They also expect ongoing monitoring and ad hoc reviews, for example when fraud attempts rise.
They shouldn't. Agents can run the checks, compare data, screen the applicant and prepare the file, but the bank owns its CIP procedures and the decisions to open, decline or close an account and to report. Keep account decisions with your onboarding analysts and compliance officer, and set the agents' autonomy and kill switch yourself.