AI KYC Vendor Due Diligence Checklist

An AI KYC vendor due diligence checklist should turn each supplier claim into evidence your firm can assess, a test it can run or a commitment it can enforce. Before signing, establish where customer data goes, how the complete workflow performs, who reviews exceptions and whether you can retrieve the records if you leave.

This guide is for procurement, compliance, risk, security and operations teams buying know your customer (KYC) software or managed KYC services. It covers document review, beneficial ownership, screening and case assessment. Apply identity-verification and biometric questions only where those functions are in scope. A passport check alone is not an evaluation of a corporate investor’s KYC file.

How to use the checklist in an RFP

Use one workbook per vendor and proposed deployment. Record the legal entities, service version, jurisdictions, customer types, expected volumes and evaluation owner. Set your mandatory conditions before sending the request for proposal (RFP). Keep confidential evidence in an access-controlled repository and put references in the workbook.

For each question, record the vendor’s answer, evidence and date, buyer finding, owner, acceptance condition, status and contract reference. Use “Not assessed”, “Evidence requested”, “Gap”, “Accepted” or “Not applicable”. Explain every “Not applicable”. A completed questionnaire is not approval to use live customer data.

Compare vendors on the same scope and test cases. Separate mandatory requirements from preferences; do not let a weighted score hide a failed legal requirement, an unsafe data flow or an unresolved material testing gap. An exception needs a named risk owner, compensating controls, an expiry date and approval within the firm’s authority. It cannot waive a legal duty.

The checklist below is AgentKYZ’s procurement recommendation, not a regulator-issued form. Sources were checked on 27 October 2026. The NIST AI Risk Management Framework is voluntary; NIST says version 1.0 is being revised.

The June 2023 US interagency third-party guidance addresses supervised banking organisations and does not itself impose new legal requirements. US regulators proposed replacement guidance in September 2026; as of the source-check date, that proposal is not final. The references below use the 2023 guidance’s lifecycle approach as a procurement reference, not as a rule for every buyer.

Apply your own AML, outsourcing, privacy, AI and sector-specific requirements. For Singapore-regulated teams, our MAS AI risk management guide provides a separate jurisdiction-specific starting point.

Scope, data handling, privacy and security

01. Define the service and its governance

• 01A. Which tasks does the system perform, which actions can it take, and which decisions remain with your firm?
• 01B. Who owns the use-case risk assessment, approval, material changes and the authority to stop the service?

Request a service description, architecture, AI/model inventory and responsibility matrix covering the vendor, your team and any administrator. Distinguish software-only access from a managed service with vendor reviewers. Identify permitted jurisdictions, customer types, unsupported uses and interfaces that can update records or contact customers.

Approve a specific workflow, such as preparing periodic-review files for human assessment. “AI-powered compliance” is too broad to define a deliverable or assign accountability. Check whether outsourcing notifications, approvals or other local requirements apply before contracting.

02. Map data handling and model-training use

• 02A. Where do documents, extracted fields, prompts, outputs, embeddings, logs and backups travel, and who can access each copy?
• 02B. Is any of that data used for training, fine-tuning, evaluation, product improvement or human support review, and what controls and terms govern each use?

Request a data-flow map naming legal entities, processing and storage countries, support locations, transfer routes and retention periods. Include the model provider, routing service, screening provider and observability tools. Ask for deletion behaviour in caches, vector stores and backups, not only the main application.

A “no training” answer does not settle logging, abuse monitoring or retention. Reconcile the proposed settings with the contract and upstream terms. Treat unexplained onward transfers or broad reuse rights as unresolved issues before sharing live files.

03. Establish privacy responsibilities

• 03A. What are each party’s controller or processor roles, lawful-processing grounds, transfer arrangements and applicable impact-assessment obligations?
• 03B. How will the vendor support access, correction, deletion, complaints and incident handling without compromising required KYC records or restricted reporting material?

Have privacy counsel assess the actual processing, including special-category or biometric data where relevant and any automated decisions affecting individuals. Request processing terms, the retention schedule and assistance procedures; document whether a data protection impact assessment is required.

For UK GDPR processor arrangements, the ICO’s Article 28 guidance covers documented instructions, confidentiality, security, subprocessors, assistance, audit and return or deletion. The ICO marks this guidance as under review following the Data (Use and Access) Act. Confirm current law and applicability rather than copying a UK clause into every jurisdiction.

04. Inspect security controls and assurance

• 04A. How are tenant isolation, encryption, key management, privileged access, authentication and staff access controlled and tested?
• 04B. What independent assurance, penetration-test findings, remediation evidence and incident-response exercises cover this exact service?

Request relevant reports through the vendor’s approved disclosure process. Check the legal entity, systems, assessment period, exceptions, excluded subcontractors and controls your firm must operate. Ask about secure development, vulnerability handling and access removal when staff leave. Require specific notification and cooperation arrangements for incidents affecting your files or service.

The US interagency guidance, due-diligence sections on risk management and information security, explicitly considers report scope, testing and remediation. A SOC 2 report or ISO certificate can inform assurance; neither, on its own, establishes KYC accuracy or regulatory approval.

Test the KYC workflow, including its reviewers

05. Test the model and the complete system

• 05A. What testing covers the deployed models, prompts, retrieval, screening feeds, policy rules, integrations and human-review workflow together?
• 05B. Can your team run an independently labelled test set, inspect failures and require retesting after material changes?

Request dated test reports tied to the proposed configuration, including limitations and review independent of development in proportion to risk. Keep test cases separate from tuning examples. Start with synthetic data. Before using customer-derived test data, including de-identified files, confirm the required permissions and safeguards with your privacy and security teams.

Include these KYC acceptance tests:

• A blurred identity document and an unreadable page: the workflow flags uncertainty rather than inventing fields.
• Conflicting ownership records and a missing link in a layered structure: it preserves the conflict and routes the evidence gap.
• A genuine screening match and a similar-name non-match: assess both missed risks and unnecessary alerts, including transliteration.
• An unavailable screening feed: it reports an incomplete check rather than a clean result.
• A document containing instructions to ignore policy: it cannot override workflow controls or gain unauthorised tool access.
• A convincing but unsupported source-of-wealth narrative: the assessment identifies what evidence is still needed.

Test altered documents and presentation or injection attacks where identity verification is included.

06. Define accuracy and document limitations

• 06A. What are the results for each task, with test population, sample size, ground truth, threshold, error severity and uncertainty?
• 06B. Where does performance deteriorate, and how does the system abstain, escalate or restrict unsupported cases?

Ask for extraction errors by field, beneficial-owner identification errors, screening recall and false alerts, unsupported conclusions, exception-routing failures and reviewer rework. Screening recall is the share of known relevant matches detected. A false-positive rate measures false alerts among actual non-matches; the share of alerts that are false uses a different denominator. Make the vendor state which measure it reports.

An illustrative system that labels all 1,000 test cases “clear” is 99% accurate if 990 are clear, yet misses all 10 risky cases. A headline percentage can therefore conceal the failure you care about. Check performance by relevant language, script, document type and ownership complexity; assess demographic disparities where lawful and relevant. Small samples and zero observed misses do not prove zero production risk.

Set thresholds with your compliance and risk owners before the pilot. Measure review time and total cost per completed, acceptable case, including failed attempts, manual checks and rework. Do not compare one vendor’s automated first pass with another’s fully reviewed file.

07. Make human oversight testable

• 07A. Who reviews outputs, with what competence, evidence access, time, escalation rules and authority to override or stop processing?
• 07B. What shows that review catches material errors rather than routinely confirming the AI’s recommendation?

Request reviewer procedures, training, quality-assurance samples, escalation records and workload assumptions. Seed known errors into a controlled exercise and test whether reviewers catch them. Check unresolved-case handling and who makes customer acceptance, high-risk approval and reporting decisions. Keep confidential suspicious-activity material within the authorised process.

NIST’s Generative AI Profile, sections 2.2 and 2.7, describes confidently false outputs and human over-reliance. A reviewer needs source evidence and a way to challenge the result. File-level review also serves a different purpose from validation of the system itself.

08. Reconstruct a case for audit

• 08A. Can a reviewer trace material findings to source documents, screening results, policy rules and the people who made decisions?
• 08B. Can you export that history, including versions, timestamps, overrides and outstanding issues, and read it without the vendor’s application?

Request a sample export and walk backwards from a decision to its evidence. Check the model/configuration and policy versions, source dates, screening query and feed references, reviewer identity and reasons for changes. Ask how logs are protected from alteration and how access and retention are controlled. Do not collect unnecessary sensitive prompts merely because logging is available.

Generated reasoning can itself be wrong. Require verifiable evidence and decision records rather than treating a fluent explanation as proof. Preserve the actual output and relevant versions; rerunning a changing model later may not reproduce the original case.

Evaluating this workflow with your own reviewers? See AgentKYZ’s KYC review software, then use the same test cases and export checks in the product discussion.

Subcontractors, resilience and contractual protections

09. Identify subcontractors and upstream dependencies

• 09A. Which entities supply models, hosting, routing, screening data, support and human review, and what can each see or change?
• 09B. How are those suppliers assessed, monitored and replaced, and how will you learn of or object to relevant changes?

Request a current subcontractor register with functions, locations, data access and dependencies. Distinguish a processing subprocessor from another supplier; the same privacy rules do not automatically apply to every subcontractor. Ask which obligations flow down and which service provider remains accountable to you.

Where UK GDPR applies, ICO guidance addresses prior specific or general written authorisation, notice and an opportunity to object under general authorisation, and equivalent Article 28 protection downstream. A well-known model provider’s name is not a substitute for checking the actual processing terms.

10. Assess resilience and vendor viability

• 10A. What happens if a model, screening feed, cloud region or review team becomes unavailable, and what recovery has actually been tested?
• 10B. Does the vendor have the financial resources, staffing and commercial rights to sustain the proposed service?

Request business-continuity and disaster-recovery results, relevant financial information, insurance, key-person cover and incident history. Agree recovery time and recovery point objectives: how soon service should recover and how much data loss is tolerable. Test queued cases, retries and reconciliation so an outage cannot silently lose work or duplicate decisions.

Check shared dependencies in any proposed fallback; two products may rely on the same upstream model or infrastructure. A substitute model may also change data location or performance. Require an approved fallback or a safe pause with a staffed manual route. The interagency guidance treats financial condition and operational resilience as separate due-diligence considerations.

11. Put material commitments in the contract

• 11A. Do the signed scope, processing terms and service levels capture the evidence and commitments your approval relies on?
• 11B. Are liability, audit, change, suspension, termination and transition rights workable for the risks you retain?

Have counsel reconcile the agreement, order form, processing addendum and linked policies, including which takes precedence and which can change unilaterally. Address:

• Data purposes, locations, reuse restrictions, subprocessors, confidentiality and security obligations.
• Deliverables, acceptance tests, human-review responsibilities, support hours and remedies for missed service levels.
• Incident notice and cooperation, material model or supplier changes, retesting and suspension rights.
• Audit evidence, access for your auditors and regulators where required, and remediation deadlines.
• Ownership and usable rights in inputs, outputs and case records; screening-data licence restrictions on retention and export.
• Liability caps, relevant exclusions, indemnities, insurance, governing law and dispute arrangements.
• Pricing for integration, manual exceptions, screening, storage, overages, renewal and exit assistance.

These are negotiation topics, not universal mandatory clauses. The interagency guidance’s contract section provides a banking-sector reference. Record any negotiated limitation and assess whether the residual risk is acceptable; service credits alone may not address lost records or a prolonged inability to perform checks.

Implementation, monitoring and exit arrangements

12. Gate the implementation and go-live

• 12A. Who validates policy configuration, field mapping, permissions, integrations, migration and staff readiness before production?
• 12B. What pilot results, unresolved defects and rollback tests will determine whether the service goes live?

Agree a phased plan with named owners on both sides. Test duplicate records, incomplete uploads, API timeouts, retries, screening outages, user removal and permission boundaries. Reconcile migrated counts and evidence links against the source. Train reviewers on failure handling, not just the successful path.

Keep the pilot’s scope and success criteria in writing. Approval should identify the deployment version, permitted population, operating controls, open issues and authorised signatories. A successful demo does not authorise processing the full customer book. For a bounded pilot, a periodic-review workflow can provide concrete evidence and decision points; adapt the jurisdiction-specific requirements.

13. Monitor quality and changes after launch

• 13A. Which quality, service and control measures will you review, at what cadence and with what response thresholds?
• 13B. Which incidents, model changes or shifts in customer data trigger retesting, reapproval, restriction or suspension?

Monitor sampled errors, potential missed risks, false alerts, reviewer overrides, incomplete checks, evidence gaps, queue age, latency, outages and cost per acceptable case. Review relevant subgroups as well as aggregate results. Production false negatives require active quality sampling or other follow-up; an absence of complaints cannot establish recall.

Assign a response owner to every threshold. Set a risk-based review cadence and event triggers for new models, prompts, data sources, jurisdictions, document types and material subcontractor changes. Keep a versioned regression set. The interagency guidance’s ongoing-monitoring section covers both service performance and changes in controls, finances and dependencies throughout the relationship.

14. Prove the exit arrangement before signing

• 14A. Can you move complete, usable case records and configuration to an alternative provider or your own operation within an agreed time and cost?
• 14B. How will access be revoked and data returned, retained where required or deleted, including upstream copies and backups?

Test an export containing source documents, ownership information, screening evidence, decisions, timestamps, overrides and open cases. Check that linked files remain accessible and that licences permit the intended retention and reuse. Assign transition staffing, assistance fees, notice periods and continuity responsibilities before they become urgent.

Reconcile the exported population, test a sample in the destination, revoke tokens and integrations, and obtain deletion confirmation with any lawful retention exceptions recorded. For UK processor arrangements, ICO guidance addresses return or deletion and safeguards where immediate backup deletion is impractical. “Delete everything immediately” may conflict with required records; leaving every copy indefinitely is not an exit plan.

Record a decision, not just a score

Your approval pack should identify the approved service, evidence reviewed, test results, unresolved issues, contract commitments and who accepts the remaining risk. Keep the decision separate from the vendor’s self-assessment.

Where a vendor cannot disclose evidence, record what is missing and why. Consider an independent report, controlled inspection, additional testing or a narrower deployment. If those measures do not resolve a material requirement, hold the approval. The interagency guidance recognises due-diligence limitations and the need to assess alternatives and mitigating controls.

Evaluate AgentKYZ against the same checklist

AgentKYZ offers AI-assisted KYC software and managed KYC services. The workflow starts from your AML policy: agents prepare the case, your reviewers or managed KYC specialists check the findings, and your firm retains the final decision. Case preparation includes document review, ownership mapping, screening and a reasoned assessment with supporting records.

Use a scoped demonstration to examine the source evidence, reviewer actions, escalation and case output. Start with the AgentKYZ trust centre for security enquiries, then confirm which assurance documents and commitments apply to the proposed engagement. This guide does not establish a certification, test result, hosting location or service-level commitment for your deployment.

Bring your use case, jurisdictions, customer types, volumes, required integrations and mandatory controls to the discussion. Include your completed checklist or the questions that remain open. Agree a suitable test-data route before sending identity documents or other confidential files.

Download the AI KYC vendor due diligence checklist and use it to set the agenda for your evaluation.