Evaluate · mass events

Customer due diligence refresh when one event hits thousands

Some events touch thousands of customer files at once: a change to the country risk policy, a sanctions list update, a new due diligence question. A customer due diligence refresh that treats each one as a ticket builds a backlog; Perpetual KYC (pKYC) treats it as one decision, prepared as a batch and approved on a sample.

Updated · 12 min read

A customer due diligence refresh usually means updating one customer's file after something about that customer changes. The hard case is the event that is not about one customer at all: the bank moves two countries into its highest risk tier, a sanctions list adds names overnight, or a new question is added to the due diligence standard. Each of those can touch thousands of files at once, and handled file by file they become thousands of tickets and a backlog measured in weeks. The better model treats the event as one decision about many files: find everyone it touches, re-run only the factor that changed, keep the unchanged results with their reasons, prepare the real changes as one batch and have a checker approve it on a sample. Botminds' Perpetual KYC (pKYC) works that way, and this page follows three mass events through it.

The figures come from a fictional sample bank, Corvane National Bank, as it runs through the solution in October 2026. Research sources are linked where they appear.

One policy change, one batch: the sample bank's country risk update

2,186

customers with exposure to the two countries moved to the top risk tier

1,804

rating unchanged, each kept with its factor sheet

382

rating increases prepared as one batch

38

files in the QC sample, stratified by tier

Fictional Corvane National Bank, country risk policy CR-2026.2, effective October 15, 2026, in Perpetual KYC (pKYC). The 10% sample is a design target and a bank setting.

Which events hit thousands of customer files at once?

Four kinds of event routinely touch a large share of the book: changes to the bank's own risk policy, such as country risk tiers; updates to sanctions and politically exposed person lists; changes to the bank's due diligence standard, such as a new required question; and seasonal waves of public filings, such as annual reports. None is about any one customer, and all of them change what the bank should know about many.

The third kind is the one banks most often miss. FinCEN's 2021 action against CommunityBank of Texas describes a bank that added an international transactions question to its due diligence questionnaire on May 28, 2019, after a customer had been onboarded, and then never put the new question to customers it had already taken on (FinCEN, CommunityBank of Texas, 2021). A new standard is a mass event whether or not anyone files it as one.

How many files one event can touch: four events at the sample bank in October

Annual report season, four states, Oct 1–22
12,410
Sanctions list update, Oct 21
3,964
Country risk policy change, Oct 15
2,186
One customer's new owner, Oct 22
1
Fictional Corvane National Bank in Perpetual KYC (pKYC): customers touched by each event. Annual report season counts reports filed by business customers in four states; the sanctions update added 37 names and amended 112.

What happens when a country risk rating changes?

When a bank raises a country's risk tier, every customer with exposure to that country needs its rating re-run, but only on the geography factor, and most ratings will not move. The work is to find everyone exposed, through owners, payments, counterparties and addresses, re-run the one factor, keep the results that did not change and gather the ones that did into a decision.

At the sample bank, two countries moved into the top tier of country risk policy CR-2026.2, effective October 15, 2026. The agents found 2,186 customers with exposure and re-ran the bank's rating model on the geography factor for each. For 1,804 the rating did not change, and each was kept with its factor sheet. For 382 it went up a tier: 141 from Medium to High and 241 from Low to Medium. Those were grouped into one batch, and a 38-file QC sample, 10% stratified by tier, was drawn.

Bulk changes in Perpetual KYC (pKYC): one policy change, one cluster, one decision

Bulk changes screen. Clusters in the last 30 days: a sanctions list update, done; country risk policy CR-2026.2, two countries moved to tier 3, needs a decision; annual report season, 12,410 reports, running. The selected cluster shows 2,186 customers with exposure, 1,804 rating unchanged and recorded, 382 move up a risk tier as one batch. Steps: found every customer with exposure through owners, payments, counterparties and addresses; re-ran CRR v4.2 for 2,186 customers, geography factor only; recorded 1,804 with no change; grouped 382 increases into one batch, Medium to High 141, Low to Medium 241; drew a QC sample of 38 files, 10%, stratified by tier. A customer list shows Tidewater Freight Brokers handled as its own event, and others with the reason for their change.
Perpetual KYC (pKYC) on the fictional sample bank. The batch is prepared by the head of KYC operations as maker and approved by a QC reviewer as checker before any rating is written.

Two details on that screen are the design. First, a customer already being handled as its own event, Tidewater Freight Brokers, is kept out of the batch so the two decisions do not collide. Second, each customer in the cluster carries the reason its rating moved or did not: owner residence, payments, control person, suppliers, or payments below the threshold. The batch is one decision, but it is not an anonymous one.

The rule does not ask a bank to rate a whole category high because of a label. FinCEN's FAQ F.5 says a bank need not treat a product or customer type as high risk just because a government publication names it (CDD Rule FAQs, F.5). The same logic applies to a country tier change: re-running the factor for every exposed customer, and letting the model decide who moves, is more defensible than moving everyone with a connection.

What happens to KYC after a sanctions list update?

After a sanctions list update, every customer with a party whose name resembles a new or amended entry has to be checked, and nearly all of them will be cleared. The KYC question is not the screening itself but what the file should show afterwards: which identifiers cleared each similar name, and which potential matches went to the sanctions team.

The sample bank's list update on the evening of October 21 added 37 names and amended 112. 3,964 customers had a party with a similar name. 3,941 were cleared on two or more identifiers, such as date of birth and nationality, and each clearance was kept with the identifiers cited; 394 of those clearances went into QC's sample. 23 potential matches went to the Sanctions Screening team. None of the 23 was cleared inside the refresh process, because clearing a potential true match is not a KYC analyst's call.

Annual report season: a mass event that is mostly good news

Registry filing seasons produce large volumes of events that mostly confirm what the file already says. Between October 1 and 22, business customers of the sample bank filed 12,410 annual reports in four states. Each one is a chance to confirm a customer's identity and registration section without asking the customer for anything.

Tidewater's own report is a small example. Its Delaware annual report on October 8 showed no change; the event was not material, and the identity section's last-reviewed date moved to October 8 without anyone re-collecting it. Multiply that by twelve thousand, and a season that a calendar program would ignore becomes a free refresh of one section across much of the business book.

Can KYC changes be approved in batch?

Yes, if the batch is one decision with one rationale and a checker tests it on a sample before anything is written. The alternative, 382 individual approvals of the same factor change, adds clicks, not judgement: the reviewer is approving the same reasoning 382 times and the 382nd approval is the least careful.

Examiners judge whether the process is sound more than they second-guess individual calls; the FFIEC manual's customer due diligence section says as much about customer risk decisions made under an established, effective process (FFIEC BSA/AML Manual, CDD). A batch makes the process inspectable: one rationale, one factor, one model version, one list of affected customers and one sample with its results. European guidance on automated onboarding points the same way, listing sample testing and manual reviews among the controls a firm should run on automated steps (EBA/GL/2022/15).

One mass event in Perpetual KYC (pKYC), from policy change to written ratings

  1. Agent

    Find every customer exposed

    Search owners, payments, counterparties and addresses for the two countries: 2,186 customers.

    Never: drops a customer already being handled as its own event into the batch.

  2. Agent

    Re-run one factor

    Re-run the rating model on the geography factor only, and keep 1,804 unchanged results with their factor sheets.

    Never: applies a rating.

  3. Agent

    Prepare the batch and the sample

    Group 382 increases by tier and draw a 38-file sample, stratified by tier.

  4. A person decides

    Head of KYC operations, maker

    Reviews the rationale and the affected list, and prepares the batch for approval.

  5. A person decides

    KYC QC reviewer, checker

    Works the 38 sampled files; approves the batch or returns it with a reason before any rating is written.

The country risk change in the fictional sample bank, in Perpetual KYC (pKYC). Approving writes the new ratings to the core banking system; the batch, the sample and the results stay on the audit trail.

How big should the QC sample on a batch be?

Large enough that a clean sample means something. A useful rule of thumb comes from simple probability: if a reviewer finds no errors in a random sample of n files, the bank can be 95% confident that the true error rate in the batch is below 1 − 0.05^(1/n). Thirty-eight clean files support a bound of about 7.6%; it takes 59 to get to 5% and about 300 to get to 1%.

What a clean QC sample proves about a batch

Files sampled, no errors found95% upper bound on the batch error rateWhen it is enough
2013.9%A small batch where any error would be caught downstream
38 (10% of the sample bank's batch)7.6%A factor-only change with a single, reviewable rationale
595.0%The smallest clean sample that supports a 5% bound
1003.0%Rating moves that change monitoring for many customers
3001.0%Changes that would be costly to unwind, such as exits
Our arithmetic: upper bound = 1 − 0.05^(1/n), for a simple random sample with zero errors found. A stratified sample, as in the sample bank, should be read per stratum. The 'when' column is our suggestion, not a regulatory standard.

The table also shows why a percentage sample is not always the right setting. Ten percent of a small batch proves little, and ten percent of a very large one may be more than the risk needs. A bank's policy can set a floor in files as well as a rate.

When the rating model itself changes

A new version of the customer risk rating model is the largest mass event a bank can create, because it can move every rating in the book at once. It deserves the same treatment as a country tier change, with one addition: the model change should be validated before the batch is ever prepared, and the batch should show, for each customer who moves, which factor moved them.

Customer risk rating models are usually traditional scoring models, and the interagency model risk guidance issued on April 17, 2026, as SR 26-2 says its principles apply to "traditional statistical and quantitative models", while noting that it is "expected to be most relevant to banking organizations with over $30 billion in total assets" (Federal Reserve SR 26-2). Whatever a bank's size, the practical sequence is the same: validate the new version, run it across the book in a test, read the distribution of moves, then prepare the real changes as clusters by cause, each with its own sample.

The sample bank's model is versioned for this reason. Every rating on Tidewater's file names the model that produced it, CRR v4.2, so a later version can be compared customer by customer, and a rating moved by a model change can be told apart from one moved by an event.

Why a backlog is the worst answer to a mass event

A mass event handled as tickets does not fail loudly. It becomes a queue, the queue ages, and the files in it sit in a state the bank knows to be out of date. Enforcement shows how far that can go when a population is simply set aside.

FinCEN's 2024 order against TD Bank recounts a backlog of 1.6 million customers who had never been risk-scored, and a sample suggesting that the high-risk customers among them "may have exceeded 200,000". The committee decided against any remediation aimed at that population, partly because it would have competed for people and money with other risk projects (FinCEN, TD Bank, 2024; the order is read in BSA consent orders that ordered KYC remediation). That is the logic a ticket queue invites: the work is too big, so it waits.

A batch changes the arithmetic. The sample bank's 2,186 exposed customers became one decision with 38 files to review. The KPIs a KYC tracking system should report include mass events separately for that reason: the time from policy change to written ratings is one of the clearest measures of whether a program can keep up.

Designing a mass-event cluster

A cluster is defined by its cause, not by its size. Every customer touched by the same policy change, list update or standard change belongs in one cluster, with one rationale and one model or rule version. Customers already in an open event of their own stay out, and customers whose change is not purely the mass event's factor go to an analyst individually.

Three settings matter. The factor scope says which part of the rating is re-run, so the cluster cannot quietly change other factors. The sample design says how many files QC sees, by stratum. And the maker and checker are named in advance: in the sample bank the head of KYC operations prepares and a QC reviewer approves. What KYC refresh software should and should not do covers the agents' limits that make a batch safe to approve.

Questions people ask

What is a client due diligence refresh?

It is the same as a customer due diligence refresh: bringing an existing client's file up to date with what the bank now knows. Banks with institutional or wealth clients often say client; the duty under 31 CFR 1020.210 is to maintain and update customer information on a risk basis.

How do you handle a mass KYC refresh?

Treat the cause as one decision. Find every customer the event touches, re-run only the factor that changed, keep the unchanged results with their reasons, prepare the changes as one batch and have a checker approve it on a sample before any rating or file is written.

What is a bulk KYC review?

A review of many files for the same reason at the same time, such as a country risk change or a new standard. It differs from a periodic review because the reason is shared and the work can be scoped to the one factor or section the reason affects.

Does a new CDD question have to be asked of existing customers?

If the bank's risk-based procedures make the information necessary, the back book needs a plan. FinCEN's 2021 action against CommunityBank of Texas cited a bank that added a question in 2019 and never went back to ask existing customers.

Can a sanctions list update be cleared in bulk?

Similar names can be cleared at scale when two or more identifiers rule them out and each clearance is kept with the identifiers used. Potential true matches should never be cleared inside a bulk process; they go to the sanctions team one by one.

Perpetual KYC (pKYC).
See it on your own files.

An agentic solution from Botminds. Agents watch every trigger event, refresh only the sections it touches, and send material changes to an analyst and a QC reviewer Book a demo, or explore how it works.