KYC analysts bank a correction by recording why they changed the agent's ownership trace, document check or risk rating, and identifying which source or rule caused it. The agent owner then changes the brief, sources or bounds and re-certifies. The KYC-specific lesson is provenance: most banked fixes are about which documents the agent may trust.
What does the agent do in a KYC team?
An onboarding agent gathers documents, screens names, traces beneficial ownership through company filings and drafts a risk rating with its reasoning. It works at depth 1 and 2: it reads and drafts, and an analyst decides whether the customer is accepted, refused or escalated. Analysts correct it every day.
It stops tracing ownership at a holding company that itself has a foreign parent. It accepts a utility bill uploaded by the customer as proof of address when your policy requires a document from a regulated issuer. It rates a customer low risk without noticing a director also sits on the board of a company in a high-risk jurisdiction. Or it flags a name match that the analyst resolves in two minutes by date of birth.
Each correction is a candidate for banking, but only if the analyst can say why. The skills each role brings to this are mapped in AI agent skills by role.
Why does provenance sit at the centre?
Every fact reaching the agent arrives stamped with where it came from. A company registry extract is signed: an identifiable party answers for it. A customer-uploaded document is declared: the customer says it is true, and nothing yet confirms it. An emailed letter from an introducer is external. Your policy decides which classes count as evidence for which checks.
Many KYC corrections turn out to be provenance errors. The agent treated a declared document as if it were signed, or relied on an external source where policy needs a signed one. The banked fix is not "accept fewer utility bills"; it is "proof of address requires a signed source; a declared document opens a request for one". Analysts who learn to diagnose this way bank fewer, better changes.
What are the steps?
- Agent, depth 1: gathers documents and registry data, each fact stamped with its provenance class.
- Agent, depth 2: drafts the ownership trace and risk rating, citing the facts behind each conclusion.
- Person (KYC analyst): corrects and records a reason: provenance accepted wrongly, trace stopped early, risk factor missed, false match, unclear policy, or one-off.
- Agent, depth 1: groups reasons weekly by customer type and jurisdiction.
- Person (KYC team lead): decides what to bank. Anything that relaxes acceptance criteria also goes to the MLRO or equivalent.
- Person (agent owner): makes the change. A rule to trace to natural persons through every layer goes into the brief; an updated high-risk jurisdiction list replaces the old source; provenance requirements per check are set as bounds.
- Attest replays the agent against your past onboarding files, including ones later found to be high risk.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Gather | Collects documents and registry data with provenance | 1 | Requesting more evidence |
| Draft rating | Traces ownership, proposes risk rating | 2 | Accept, refuse or escalate |
| Correct | Nothing; reason filed | 1 | Reason code |
| Bank | Nothing | none | Team lead, MLRO for relaxations |
| Re-certify | Replayed in Attest | none | Accepting the result |
What else must KYC analysts learn?
How to handle false matches without teaching the agent to ignore them. Analysts clear dozens of name-screening hits a day, and the natural request is for the agent to stop raising those. Bank the resolution method instead: "where date of birth and nationality both differ, the agent may close the hit and record why", with a sample of closed hits reviewed by a person. That keeps the evidence.
When a correction reflects a policy gap. If analysts keep disagreeing with each other on how to treat trusts, the agent cannot be fixed until the policy is. Escalate the policy question instead of banking one analyst's view. The checks underneath are in how KYC analysts review an AI agent's decisions, and the decisions that must never move to the agent are in what KYC analysts should never let an AI agent do.
Which controls and evidence matter?
- Provenance rules per check. Evidence: the class of each fact cited in the rating.
- MLRO sign-off for relaxations. Evidence: approver name on each loosening change.
- Replay including known bad files. Evidence: gate scores on cases later found to be high risk.
- Sampling of auto-closed screening hits. Evidence: the sample and the reviewer's conclusion.
What should the team measure?
Repeat corrections per reason code, especially provenance and early-stopped traces. The share of files where the agent requested further evidence on its own, which should rise as provenance rules are banked. Time from a jurisdiction list update to the agent's sources. And the outcome of the auto-closed hit sample, which tells you whether a banked screening rule is safe.
Where does it usually go wrong?
Analysts bank their own tolerances. One analyst accepts a document type others would not, corrects the agent towards it, and the agent inherits a view the team never agreed. Calibrate analysts on sample files before banking anything that changes acceptance.
Jurisdiction lists go stale. The compliance team updates its list, but the agent reads an old copy. Link the list update to the source change.
Teams bank screening fixes faster than ownership fixes because they are easier, leaving the harder trace errors unaddressed. Credit teams see similar pressure on financial spreading, as teaching credit analysts to bank corrections explains, and fraud teams work the same problem at transaction speed, covered in teaching fraud analysts to bank corrections.
Questions people ask
Can the agent accept a customer on its own after enough corrections?
Acceptance is a decision with regulatory consequences, and most firms keep it with a person. Banking corrections improves the draft the analyst decides on; it does not, by itself, raise the agent's depth.
What if registry data is wrong?
Registry data is signed, not sealed, so it can be wrong. Analysts should record the discrepancy as a reason, and the policy should say how conflicts between sources are resolved.
How often should KYC corrections be reviewed?
Weekly is common, with a faster path for anything affecting sanctions or high-risk jurisdictions.