KYC onboarding software should be judged on your own closed files, not on a vendor's demonstration. Take 30 to 50 corporate files your bank approved in the last year or two, ideally some that examiners or internal audit have already reviewed, give the software the same source documents your analysts had, and let it build each file without seeing the approved version. Then compare the two, field by field. Where the software agrees, you have evidence it works on your clients; where it differs, each difference is either a software error or a gap in the approved file, and both are worth knowing before you buy. Botminds' Corporate KYC is offered for exactly this kind of test: run on a sample of your own past corporate files, against your own CDD standard.
Where the page uses an example it is a fictional bank and client, Corvane National Bank and Brightwater Cold Chain Holdings, as their file runs through the solution. The plan, the weeks and the measures are ours; the regulatory statements are quoted from the agencies.
A KYC onboarding software pilot in six parts
1
Files
30 to 50 corporate files approved in the last one to two years, some of them already seen by examiners or internal audit
2
Inputs
The source documents as they stood when each file was built: application, registry extracts, certification, statements, the client’s answers
3
Settings
Your CDD standard, risk model, chapter templates, reason codes and screening thresholds, as they were at the time
4
Run
The software builds each file blind, without seeing the approved version
5
Compare
Field by field against the approved file; every difference classified as software error, file gap or judgement
6
Decide
Your analysts, QC and BSA officer review the differences; the write-up goes to your governance
How to evaluate KYC onboarding software: run it on files you already closed
Evaluate KYC onboarding software by measuring its output against a standard you already trust: your own approved files. A demonstration shows the software on data the vendor chose, usually clean, usually small. A closed file shows it on a real client with a real structure, real gaps in the documents and a real decision that your analyst, your QC reviewer and perhaps an examiner already made. If the software reaches the same conclusions from the same evidence, and shows its sources, you have learned something no demonstration can tell you.
Closed files have a second advantage: the answer is known. For each file you know who the beneficial owners were, what the rating was, what QC returned and why, and sometimes what the examiner said. That turns the pilot into a measurement rather than an impression. It also protects clients, because nothing the software produces reaches a live relationship.
Which files to use in a KYC pilot
Use a stratified sample of 30 to 50 corporate files, chosen so that the hard cases are over-represented. A random sample of corporate files will be mostly simple operating companies with one owner, and software that handles those well has proved little. The sample should include the structures that make corporate KYC hard.
What a 30-to-50-file pilot sample should contain
- Several entity types
LLCs, corporations, limited partnerships, a nonprofit (control prong only) and an excluded entity such as a listed company’s US subsidiary.
- Ownership through funds and trusts
At least a few files where a fund or trust holds a stake and the look-through decides who must be identified.
- Foreign entities and subsidiaries
Non-US registries, non-US identification numbers and cross-border expected activity.
- High-risk ratings
Files that went to the second line, so the pilot tests the cases where judgement mattered most.
- Files QC returned
The return reason is a known gap; did the software find it before QC would have?
- Files examiners or auditors sampled
Their findings, or lack of them, are the strongest external answer key you have.
- Existing clients opening another account
To test reuse of the file under FinCEN’s 2026 relief rather than a fresh certification.
- A few files with later problems
An ownership change or activity alert after approval: would the software’s file have flagged it earlier?
Two practical rules help. Use files closed recently enough that the source documents are still on file and the analysts remember them, because the review of differences needs both. And avoid files tied to an open investigation or a suspicious activity report; the pilot needs files the team can discuss freely.
How long does a KYC software pilot take?
A pilot on 30 to 50 corporate files takes about seven weeks of elapsed time in our plan, most of it on either side of the run: choosing files and getting approvals at the start, reviewing differences with the people who built the originals at the end. The run itself is the shortest phase.
Seven weeks from file selection to a write-up for governance
- Select files, approvals, data accesswk 1–1.5
- Load your standard and modelwk 2–3
- Run blindwk 4
- Review differences with analysts and QCwk 5–6
- Write-up to the BSA officerwk 7
The review phase is the one to protect. A difference between the software's file and the approved one has to be read by someone who knows the client, classified, and recorded with a reason. Rushing it turns a measurement back into an impression, and the write-up will be the document your BSA officer and, later, an examiner reads.
What to measure: the differences from the approved file
Measure agreement on the facts, coverage of the parties, quality of the evidence and the time a reviewer needs, and classify every difference. The table lists the measures we would use for a corporate KYC pilot and what each tells you.
Measures for a corporate KYC software pilot, and what each shows
| Measure | How to score it | What it tells you |
|---|---|---|
| Owners and control person | Same individuals identified as the approved file, per file | Whether the look-through and the exclusions are right |
| Party coverage | Parties screened ÷ parties in the structure that transact | Whether entities like a new foreign subsidiary are missed |
| Expected activity | Products, volumes and countries against the approved file and the statements | Whether figures come from current documents |
| Rating | Same band as approved; every factor cited | Whether the bank’s model is applied as written |
| Citations | A random sample of sentences: does the cited passage support the sentence? | Whether a reviewer can trust the sources without re-reading everything |
| Gaps found | Differences where the approved file was wrong or incomplete, confirmed by your reviewer | What the software would add to your current quality |
| Reviewer time | Analyst and QC minutes to review the software’s file | The real saving, measured on your people |
| Client requests | Items the software would have asked the client for, against what was asked | Whether the client would have been asked once |
Every difference falls into one of three classes: the software was wrong, the approved file was wrong, or both are defensible judgements. Count each class separately. A vendor whose error count is low and whose "approved file was wrong" count is high has found real gaps; a vendor that disagrees on judgement calls may simply be applying a different standard, which configuration should fix.
Will regulators criticise a pilot that finds gaps in your files?
Not for the pilot itself, according to the agencies' standing statement on innovation. The 2018 joint statement of the Federal Reserve, FDIC, FinCEN, NCUA and OCC addressed this directly, and it remains the guidance the 2026 proposals build on.
Pilot programs in and of themselves should not subject banks to supervisory criticism even if the pilot programs ultimately prove unsuccessful. Likewise, pilot programs that expose gaps in a BSA/AML compliance program will not necessarily result in supervisory action with respect to that program.
Federal Reserve, FDIC, FinCEN, NCUA and OCC, Joint Statement on Innovative Efforts to Combat Money Laundering and Terrorist Financing, December 3, 2018
The statement adds that when innovative systems find something existing processes missed, "the Agencies will not automatically assume that the banks' existing processes are deficient." FinCEN's April 2026 AML/CFT program proposal goes further and would say that responsible experimentation adds no additional risk of significant supervisory or enforcement action solely because innovative technology is used; it is a proposal, not yet final (FinCEN, 91 FR 18704).
None of that removes a bank's duty to act on what it finds. If the pilot shows that an approved file missed an owner or a sanctioned party, the bank must deal with that client as it would any discovered gap. That is a reason to run the pilot, not to avoid it: the gap existed before the software found it.
Governance for the pilot: data, masking and who signs off
Govern the pilot as the bank will govern the tool, because the pilot's write-up becomes the first evidence of that governance. Since SR 26-2 took generative and agentic AI out of the agencies' model risk guidance in April 2026, the controls for those tools are the bank's own to set through its usual risk management and governance (SR 26-2; agentic AI for KYC reads the carve-out). For a pilot that means four decisions written down in advance.
First, data: which files, which environment, and how identifiers are masked; real files contain dates of birth and taxpayer numbers. Second, the configuration: the CDD standard, risk model and thresholds in force when each file was built, versioned, so the pilot tests the software and not a moving policy. Third, the split of work: the EBA's guidelines for remote onboarding ask firms to state which steps run with no person involved and which need one (EBA/GL/2022/15), a good discipline even for a US bank that is not bound by them. Fourth, who signs the conclusion: usually the BSA officer, with the head of KYC operations.
KYC software for banks: questions to settle before the pilot starts
Settle the terms of the test with each vendor before the first file runs, so the result cannot be argued away afterwards. These are the questions we would put to any vendor of KYC software for banks, ourselves included.
Questions for any KYC onboarding software vendor before a pilot
- Will it run on our closed files, with our standard and model?
Not a sample dataset, not the vendor’s default risk model.
- Will it run blind?
The software must not see the approved file it will be compared with.
- Does every statement cite a source we can open?
So the citation measure can be scored at all.
- What may it not do on its own?
Sign, approve, contact a client, clear a match, override the model; and how that is enforced.
- How does it handle reuse for existing clients?
Under FIN-2026-R001 a bank may rely on a recorded confirmation instead of a new certification.
- How is a change to a prompt, model or threshold tested and approved?
On a fixed set of past files, with the bank’s approval, before release.
- What will we hand an examiner?
Every version, source, signature and dispute, with identifiers masked.
- What happens to our data after the pilot?
Where it was processed, what was retained, and how it is deleted.
A KYC software demonstration against a pilot on your own files
A demonstration shows what software can do; a pilot shows what it does on your clients. Both have a place, and the difference is worth stating plainly when a buying committee is tempted to decide on the first.
What a demonstration shows, and what a pilot on closed files shows
Vendor demonstration: The vendor’s sample clients, often simple and complete.
Pilot on your closed files: Your clients, with their funds, trusts, foreign subsidiaries and missing documents.
Vendor demonstration: The vendor’s default checks and risk model.
Pilot on your closed files: Your CDD standard and your model, as they were when the files were built.
Vendor demonstration: None: the audience judges by eye.
Pilot on your closed files: Your approved files, QC returns and examiners’ findings.
Vendor demonstration: Whether the interface is pleasant and the vendor knows the domain.
Pilot on your closed files: Agreement rates, gaps found, reviewer minutes saved, and where it fails.
Vendor demonstration: Slides.
Pilot on your closed files: A write-up your BSA officer signs and an examiner can read.
What a Corporate KYC pilot on your files looks like
A Corporate KYC pilot follows the plan above. The bank's CDD standard, risk model, chapter templates and reason codes are loaded as versioned settings; the agents build each sampled file blind from the original documents; and the bank's analysts and QC compare the result with what they approved. The output for each file is the same as in production: seven chapters in cited prose, a structure chart, a screening register, a rating worksheet with every factor sourced, and the checker's disputes.
A file built by the agents, signed by the analyst and approved by QC
The differences are where a pilot earns its cost. On the fictional sample file, the Checker agent found two gaps a manual file could easily carry into approval: expected activity written on statements that predated a new foreign subsidiary, and that subsidiary missing from the screening register although it would receive wires. In a pilot, every such finding on a real closed file is classified by the bank's own reviewers, and the solution's design target of 30 to 50% fewer analyst hours per corporate file is measured on the bank's people rather than asserted.
The trail and the examiner pack a pilot's results can be checked against
Before the pilot, it helps to know what one of your corporate files costs today, so the result can be priced; how to measure that is set out separately, as is the checklist a pilot's files should pass. To arrange a test on your own files, start from Corporate KYC.
Questions people ask
What is a KYC onboarding system?
A KYC onboarding system is the software a bank uses to collect, verify and decide on a new customer's identity and due diligence before opening accounts: intake, document collection, registry and identity checks, beneficial ownership, screening, risk rating and approval. For corporate clients it may be part of a client lifecycle management platform or a dedicated tool that builds the KYC file.
How is KYC software for banks different from fintech identity verification tools?
Identity verification tools check that a person or document is genuine, usually in seconds. KYC software for a bank's corporate clients has to do far more: identify the entity and its owners under 31 CFR 1010.230, document nature and purpose, screen every party, rate the risk and leave a file an examiner can test.
Do we need to tell our examiners before running a pilot?
We know of no rule requiring notice for a pilot on closed files that does not touch live decisions. A bank may still mention it at its next supervisory contact, and the 2018 joint statement says the agencies may provide feedback on pilots; the pilot's write-up is the document to share.
Can a KYC pilot use real customer files?
Yes, with the same protections as production: an approved environment, masked identifiers where possible, limited access and deletion afterwards. Using real closed files is the point; synthetic files cannot show how the software handles your clients' structures and documents.
What if the software disagrees with a file we approved?
Classify the difference: software error, gap in the approved file, or a judgement where both are defensible. A confirmed gap must be dealt with like any discovered issue with that client, and the 2018 joint statement says the agencies will not automatically assume existing processes are deficient when new technology finds something they missed.