Customer due diligence software keeps the bank's knowledge of its customers current after onboarding: it holds each customer's file, watches for changes, decides which matter and routes updates for approval. The way to choose it is not a demonstration on the vendor's sample data but a pilot on your own: take the periodic reviews your team completed last year, replay the same year's trigger events through the software, and compare what the calendar found with what the software would have refreshed, how early and on what evidence. The comparison answers the questions a buyer actually has (would it have caught what our reviews caught, what did our reviews miss, and how much work would it have created) with numbers from the bank's own book. Botminds' Perpetual KYC (pKYC) is designed to be evaluated this way, and the method applies to any event-driven product.
Last year, twice: what the calendar found against what an event replay would have done
Last year's periodic reviews: Every file whose review date fell in the year, changed or not.
The same year, replayed on events: Every file that received a material event, plus backstops for quiet ones.
Last year's periodic reviews: At the review date, however long after the change happened.
The same year, replayed on events: On the day the event arrived: the gap is measured in days, per file.
Last year's periodic reviews: All sections, and often documents the bank already held.
The same year, replayed on events: Only the sections each event touched.
Last year's periodic reviews: The test that matters: any change your reviewers caught that no feed showed.
The same year, replayed on events: Each one is a feed, linking or rule gap to fix before go-live.
Last year's periodic reviews: Changes that landed after a file's review and before the next.
The same year, replayed on events: Each one is risk the calendar carried unseen.
Last year's periodic reviews: Hours actually logged on reviews.
The same year, replayed on events: Event refreshes, sampled closures and backstops, timed on the pilot.
What customer due diligence software should prove before you buy
It should prove three things on your data: that it catches the changes your reviewers caught, that it catches changes they missed or found late, and that the work it creates is the kind your team should be doing. Every other claim, from speed to coverage, follows from those three and can be measured in the same pilot.
The first is the safety test, and the one a vendor demonstration cannot answer. If last year's reviews found a new owner, a change of business or a new country that no feed would have shown, the software would have missed it; that tells the bank which sources it lacks before it relies on them. The second is the benefit: every material change that landed between review dates is a period in which the bank's file was wrong. The third is the cost, measured in hours, sampled closures and backstop reviews.
The replay design: last year's reviews against last year's events
The replay design matches two histories of the same year. One is the review history: every periodic review completed, with what it changed, the date, and the analyst's notes. The other is the event history: everything the bank's feeds delivered that year, from registry filings and core banking changes to screening results, media matches and monitoring alerts. The software processes the event history under the bank's trigger policy, as it would have in real time, and its output is compared customer by customer with the review history.
Three outputs come out of the match. Changes both found, with how many days earlier the events found them. Changes only the reviews found, each traced to a missing feed, a failed link or a rule. And changes only the events found, each a period of unseen risk under the calendar. A fourth output is every event the software closed as not material, which should be sampled by the bank's QC reviewers exactly as it would be in production.
The replay has to be blind where it can be. The trigger policy is fixed before the replay starts, the analysts who score the output are not the ones who wrote it, and nobody tunes a rule after seeing which files it missed without re-running the whole year. The seeded test for event-driven KYC review adds planted events with a known answer, which is the cleanest way to measure what the software misses.
What data do you need for a CDD software pilot?
You need a year of both histories, the policies that applied, and a sample of files in full. Most of it already exists in the bank's systems; the work is extracting it with dates intact.
What to bring to a customer due diligence software pilot
- The customer due diligence standard
What each section of a file must contain, by customer type and risk tier.
- The trigger policy, or a first draft of one
Numbered rules with thresholds; if none exists, writing it is part of the pilot.
- The customer risk rating model and its version
So proposed ratings can be compared with the ratings actually applied.
- A year of completed periodic reviews
Customer, date, what changed, which sections, analyst notes and the checker.
- A year of events from every feed
Registry filings, core banking changes, screening results, media matches, monitoring alerts, lifecycle changes, with timestamps.
- A sample of full files
For the customers in the pilot segment, so section-level drafts can be checked against what the file held.
- Time logs, if you have them
Hours on reviews by customer type; otherwise time a sample during the pilot.
How long is a pKYC pilot?
We plan a focused pilot on one segment of the book at about a quarter, and most of that time goes on data and policy, not on running the software. The plan below is an illustration of the phases and their relative length, not a commitment; the data extraction phase is the one that varies most between banks.
An illustrative pilot plan: most of the calendar is data and policy
- Extract both histories4 wk
- Trigger policy2 wk
- Replay1
- Score, sample closures, trace gaps3 wk
- Findings and decision2 wk
The temptation is to shorten the scoring phase. Resist it: the cases where the software and the reviewers disagree are the pilot's real output, and each needs a person to decide whether the software, the reviewer or the policy was wrong.
Scoring the pilot
Score the pilot on the questions a decision needs answered, each with a measure taken from the match between the two histories. A single headline accuracy figure is less useful than the breakdown, because the failures concentrate in particular event types and particular feeds.
Pilot questions, the measure for each, and what to do with the answer
| Question | Measure | If the answer is poor |
|---|---|---|
| Would it have caught what our reviews caught? | Share of review-found changes that a replayed event also found | Trace each miss to a feed, a link or a rule before go-live |
| How much earlier? | Days between the event and the review that found the same change, median and longest | Little gain suggests the calendar is already tight for this segment |
| What did our reviews miss? | Material changes found only by events, by type | Each is risk to discuss with the BSA officer, not just a sales point |
| Were the closures right? | QC pass rate on a sample of not-material calls, by trigger family | Rewrite the rule behind the failing family and re-run |
| Were the drafts right? | Share of drafted sections an analyst accepted without change | Look at sources: a wrong draft usually means a wrong or stale source |
| What work did it create? | Event refreshes, sampled closures and backstops, timed | Compare with hours actually logged on last year's reviews |
One number from the pilot also anchors the business case: the material event rate for the segment, events per thousand customers a year. It drives the event-refresh hours and the sample size, and it is the input that vendor estimates most often get wrong. The program math for a KYC tracking system shows where it goes.
Can perpetual KYC be piloted on part of the book?
Yes, and it usually should be. The US rule sets no refresh schedule, so a bank can move one segment to event-driven refresh while the rest of the book stays on its calendar, provided its written program describes both and each customer is clearly under one regime. Business customers in one region, or one line of business with good registry coverage, make a natural first segment.
FinCEN's recent relief on beneficial ownership shows how much of this is left to the bank. Its February 2026 order lets banks stop re-identifying owners at each new account, and leaves it entirely to each institution whether, and how far, to use that relief (FinCEN, FIN-2026-R001; FinCEN's 2026 CDD rule relief reads the order). A phased move to event-driven refresh is the same kind of risk-based choice, documented and owned by the bank.
Choose the pilot segment for the evidence it will produce. A segment where owners change often and filings are public will show the benefit clearly. A segment where most changes are in activity, not ownership, tests the transaction monitoring link, which is often the weakest feed.
What regulators have said about pilots
The federal banking agencies and FinCEN have said that a pilot will not, by itself, be held against a bank. Their joint statement of December 3, 2018, says a pilot should not draw supervisory criticism even if it fails, and that a pilot which uncovers gaps in a BSA/AML program will not necessarily lead to supervisory action on that program (Joint Statement on Innovative Efforts; the statement is read in full in a KYC onboarding software pilot). The second half matters for a replay pilot, which is designed to expose gaps: changes the calendar missed are exactly that. FinCEN's April 2026 proposed program rule, not yet final, goes further.
Institutions that responsibly experiment with innovative technologies in their AML/CFT programs will not incur any additional risk of being subject to a significant supervisory AML/CFT action or AML/CFT enforcement action solely based on the use of innovative technologies.
FinCEN, proposed rule on AML/CFT programs, 91 FR 18704, April 10, 2026
It is a proposal, so it protects nobody yet, but it shows the direction. Treasury's Under Secretary for Terrorism and Financial Intelligence put it more bluntly in September 2025: a team that uses AI to reduce false positives and escalate faster deserves credit from examiners rather than criticism (Treasury, remarks by John K. Hurley).
None of that removes the bank's duty to keep its program effective during the pilot. A replay on historical data carries no customer risk, which is one reason to pilot that way first; a live pilot on a segment should run alongside the calendar for that segment until the results justify switching.
How to evaluate customer due diligence software vendors
Evaluate vendors on what the pilot measured and on what it cannot: the limits on automated decisions, the evidence trail and the fit with the bank's existing systems. KYC refresh software: which agent watches, drafts, checks and stops sets out the limits to ask about.
Three practical checks separate products quickly. Ask the vendor to run the replay on your data under your trigger policy, not theirs. Ask to see, for any closed event in the replay, the rule version, the reason and the sources in one view. And ask what an examiner export of the pilot would contain. The FFIEC's examination procedures have examiners sample customer information and test whether it supports the risk profile (FFIEC examination procedures, CDD); a pilot output that can answer that test file by file is the one to take forward.
What a replayed day looks like in Perpetual KYC (pKYC): every event decided, reason kept
Notice the banner on that screen: the adverse media feed is 47 minutes behind and its backlog is queued, not dropped. Feed health is part of what a pilot should test, because a feed that silently drops events produces exactly the misses a replay is designed to find.
The control a Perpetual KYC (pKYC) pilot must keep: a different person approves every change
Questions people ask
What is a customer due diligence program?
It is the part of a bank's AML program that identifies customers and their beneficial owners, understands the nature and purpose of each relationship, builds a risk profile and keeps customer information current on a risk basis. The ongoing, updating part is what customer due diligence software mostly supports.
What is a customer due diligence system?
The system that holds customers' due diligence files and manages their updates, often a client lifecycle management system with screening, monitoring and rating systems around it. Event-driven software sits on top of these, reading their changes and writing approved updates back.
How do you evaluate pKYC software?
Replay a year of your own trigger events through it under your own trigger policy and compare the result, customer by customer, with the periodic reviews your team completed that year. Measure what it caught, how early, what it missed and why, whether its closures pass QC sampling and how much work it created.
Do you need a written trigger policy before a pilot?
It helps, but writing one can be part of the pilot. FinCEN's FAQs tie the duty to update to information learned through monitoring, so the policy is what turns that duty into rules the software and the reviewers can apply the same way.
Is a pilot on historical data enough to go live?
It is enough to decide whether to go further. A sensible next step is a live pilot on one segment alongside the calendar, with maker, checker and daily QC sampling in place, before switching that segment to event-driven refresh.