Key takeaways
-
Scope the agent to evidence gathering and comparison only. Approval, rejection, and alert clearance stay with named humans.
-
The agent compares three source categories: what the applicant typed, what they uploaded, and what independent registries hold. Conflicts between them are surfaced, not resolved.
-
When ownership records disagree, both values stay on the record with their sources and timestamps. A person chooses which to trust and writes down why.
-
The three-stage workflow has explicit gates: an authorized operator triggers the evidence run after submission, the analyst works exceptions one at a time, and the compliance officer cannot approve while a required exception is open.
-
Enforce the agent’s hard limits at the orchestration layer, not in a prompt. An action that is structurally unreachable cannot be invoked, even if someone tries.
-
SR 26-2 explicitly excludes agentic AI from its scope. That means your governance framework for agents is yours to build. The six control-plane questions in this article are a starting point.
-
Answer the six control questions once, in the control plane. After that, the next agent is a configuration rather than a rebuild.
-
Keep the full audit trail: session, prompt version, every tool call, agent reasoning, analyst rationale, officer decision, and blocked actions. Blocked actions are evidence that the boundary held.
You can use an AI agent in commercial KYC once you scope it to evidence and not decisions. It can retrieve and compare what the applicant typed, what they uploaded, and what independent registries hold. Where those disagree, it shows the conflict to a person instead of resolving it quietly. Your analyst picks which source to trust and records why. Your compliance officer approves, rejects, or asks for more evidence. Every retrieval, comparison, and decision is kept, so when someone asks about a case six months later, you can show exactly what happened and who decided it.
Why does commercial KYC onboarding require evidence reconciliation?
The sources disagree, and they always have.
A corporate registry says a shareholder holds 22 percent. A tax-authority extract says 28. In this illustrative example, the records may reflect different filing dates or rules. Your reviewer needs to establish the reason for the difference. But if your policy screens beneficial owners at 25 percent, that gap decides whether this person gets screened at all. (The 25 percent threshold reflects FinCEN’s Customer Due Diligence Rule for covered U.S. financial institutions. 31 CFR 1010.230. Your own policy and jurisdiction may set a different threshold.)
Names do the same thing. An incorporation record spells a director one way and gives one date of birth, while the sanctions list has a variant spelling and a different date. So does structure: the annual return filed with the regulator shows a subsidiary that the group chart the applicant sent you never mentions.
An analyst handles this by hand today. Six tabs open, three PDFs printed, differences highlighted in yellow, an email to the applicant asking which number is right, then three days of waiting, then a summary typed into the case system. The work is necessary. It’s also the least interesting thing a trained financial-crime analyst does all week, and it is very hard to reconstruct six months later when someone asks which source you trusted and why.
An agent can do the gathering and the comparing. It can’t do the trusting.
What three evidence categories does a KYC agent reconcile?
There are three, and the discipline is refusing to collapse them into one.
What the applicant typed. Entity name, jurisdiction, registration number, address, industry code, ownership percentages, officer names. Self-reported and unverified, and often where the mismatch starts.
What the applicant uploaded. Incorporation records, share registries, annual returns, group-structure charts, appointment letters. This is primary evidence, but it is frequently stale, partial, or a scan of a scan.
What the registries hold. Corporate registry, tax-authority extracts, sanctions lists, PEP lists, adverse media. Authoritative and independent, which also means they lag, use their own identifiers, and only cover the jurisdictions they cover.
None of the three is the truth on its own. The agent’s job is to hold all three open at once and point at every difference that matters, meaning one that changes a screening requirement, a risk rating, or something you have to file.
What happens when ownership records disagree?
It keeps both numbers, and that turns out to be the most important design decision in the whole workflow.
Faced with 22 and 28, a naive system averages them to 25, lands you exactly on your own threshold, and leaves no trace of how it got there. A slightly less naive one picks the better source and overwrites the record. Both are how you end up unable to answer a regulator.
So the agent shows both values side by side, each with its source and the time it was retrieved. Then a person decides. If the tax extract is more recent, the analyst may take 28 and write down why. If policy makes the corporate registry authoritative, they may take 22 and send the discrepancy to the relationship manager. If neither source is good enough, they ask the company secretary for a certified share registry and the case waits.
Registration numbers and jurisdictions break the same way. An applicant keys Delaware and 5038471, the registry finds no match, but it offers 5038417 in Delaware and 5038471 in Nevada. (Illustrative digits. The pattern is real, the numbers are not.) The agent surfaces both possibilities. The analyst confirms with the applicant, corrects the record, and the correction itself is retained. When the compliance officer opens the case they see the original entry, the conflict, the decision and the evidence behind it on one timeline.
What is the three-stage workflow that keeps humans in control?
Three stages, three named humans, and a gate between each one.
Stage one, submission and evidence run.
The applicant completes the form and uploads what they have. Someone on your side then explicitly triggers the run, because it does not fire on submission. The agent fetches the external records, compares all three categories, and hands back a list of exceptions: ownership mismatches, jurisdiction conflicts, missing documents, screening hits, adverse media. It approves nothing. What comes out is a reconciliation, and nobody should read it as a recommendation to onboard.
Stage two, the analyst works the exceptions.
One at a time. For an ownership mismatch, choose a source and record the reason in a structured field. For a jurisdiction conflict, go back to the applicant and update the record when they answer. For a screening hit, check the match quality, clear the obvious false positives, and escalate anything real. What the analyst cannot do is clear an alert or approve the customer. Those decisions belong to the compliance officer.
Stage three, the compliance officer decides.
They see the reconciled evidence, the analyst’s reasoning on every exception, and the risk rating. Then they approve, reject with a reason code, or send it back for more evidence. While a required exception is open, approval is not available at all. If the officer wants a certified share registry before the case moves, it does not move until the document arrives and the comparison runs again.
What can the agent not do?
Three things, and they are deliberate.
It cannot approve onboarding. It cannot reject a customer. It cannot clear a screening alert.
Those decisions turn on risk appetite, on how your firm reads a regulation, and on whether a relationship is worth the friction. They belong to someone whose name goes on them. The agent gets everything up to that line: fetch, parse, compare, flag, and score against a rubric you wrote. Whether a conflict is acceptable, or whether a screening hit is really your customer, is not its call.
This boundary lives in the control plane, not in a system prompt, and the distinction matters more than it might seem. A prompt is an instruction, and research into adversarial prompting shows that instructions can be overridden or manipulated. A boundary enforced at the orchestration layer means the approval action is not reachable by the agent at all. If something tries to invoke it, the call fails and the attempt is logged.
What is the reusable control pattern for regulated agents?
Six questions. Answer them once in the control plane, reuse the answers, and you stop rebuilding governance inside every agent you ship.
- Who owns this? Compliance officer
- What risk tier? Elevated (PII, sanctions data, regulatory decisions)
- What can it reach? Corporate registry, tax extracts, sanctions and PEP lists, uploaded documents, keyed intake
- Where is the hard line? Cannot approve onboarding, reject customers, or clear alerts
- Who decides? Analyst resolves exceptions with recorded rationale; compliance officer approves, rejects or requests evidence
- What is kept? Ownership lineage, screening evidence, document comparisons, analyst rationale, officer decision and reason code, every tool call and trace
Read through these six answers and you have the agent’s whole governance posture on one screen. The owner is accountable and can switch it off. The risk tier sets how much you log and who has to approve. The reach list is the blast radius. The hard line is what is structurally impossible, not merely discouraged. The decider is a named role instead of “a human in the loop.” What is kept is what you hand to an examiner.
The pattern travels. A transaction-monitoring agent surfaces suspicious activity but cannot file the report, because a financial-crime analyst does that. An underwriting agent scores the risk but cannot approve the loan. A trade-surveillance agent flags possible abuse but cannot halt trading. Same six questions each time, different answers in the column.
Before you ship any regulated agent, check these six things:
- A named owner is registered and can pause or stop the agent
- Risk tier is assigned and determines log depth and approval requirements
- The reach list covers only what the workflow requires, nothing broader
- The hard line is enforced at the orchestration layer, not in a prompt
- A named human role is assigned to each decision the agent cannot make
- The evidence retained is sufficient to reconstruct the decision for an examiner
See how Moring governs each of these in production: AI Control Plane.
How do you build model discipline into a KYC agent?
Start with the expensive model, get the workflow right, then find out how cheap you can go.
Build it end to end on the strongest model available: retrieval, parsing, conflict detection, exception surfacing, and the handoffs between stages. Do not optimise anything yet. Then assemble an evaluation set of twenty to thirty real cases, anonymised, covering the conflicts you actually see plus the awkward edges. Run them and measure how often the agent catches a real conflict, how often it misses one, and how often it cries wolf. That is your baseline, and without it every later decision is guesswork.
Now run the cheaper model against the same set. If it holds the baseline, take the savings. If it does not, find out where it breaks, because the problem is often retrieval and not the model, and then either fix that or stay where you are.
Two warnings. A model that summarizes beautifully can be poor at comparing structured records with missing fields and inconsistent formatting, because they are not the same skill. And vendor benchmark scores measure general reasoning, not your task. Build the set from your own cases and refresh it as new conflict types appear.
Evaluation set checklist:
- 20-30 real cases, anonymized, covering common conflict types
- At least five cases with ownership percentage discrepancies across sources
- At least five cases with name variant or date-of-birth mismatches
- At least three cases where the correct answer is “escalate, do not resolve”
- Metrics tracked: conflict detection rate, missed conflicts, false positives
- Baseline established before any model swap or prompt change
What does the audit trail contain?
Six months from now someone will point at one case and ask why you accepted 28 percent. Whether that has a good answer depends entirely on what you kept.
The control plane keeps the session, meaning the whole run from trigger to exception list. It keeps the prompts, including which version was live that day, which matters the first time you upgrade a model and the behavior shifts underneath you. It keeps every tool call: the registry lookup, the PDF parse, the two percentages it set beside each other. It keeps the reasoning that got it there, and what each sub-agent did on its own.
Then there is the human half, which is the half examiners care about: which analyst chose the tax extract, what they wrote in the rationale field, which officer signed off, under what reason code, at what time.
A note on SR 26-2. The Federal Reserve, OCC, and FDIC issued revised model risk guidance, SR 26-2, in April 2026, superseding SR 11-7. SR 26-2 explicitly excludes generative and agentic AI from its scope on the basis that these technologies are novel and rapidly evolving. That exclusion does not mean agents are ungoverned. Banks still need their own risk management and governance practices around agent oversight, stop controls, and data access boundaries. The audit record described here is designed to answer those questions.
It also keeps what failed. If something tried to use the agent to approve a case, that sits in the trail as a blocked request. A log with no refusals in it tells an auditor very little. A log that shows the boundary holding tells them a lot.
On cost and latency, you get request counts and token spend per session, and latency as an average across runs of the same agent type. It is deliberately not blended across types, because a two-line greeting and a forty-page document comparison are not the same job, and averaging them produces a number that means nothing.
How does the agent run under the hood?
One orchestration agent coordinates several specialists.
The orchestrator takes the trigger, reads the intake data and the uploads, works out which external sources apply for this jurisdiction and entity type, then dispatches. A corporate-profile agent queries the registry. A capital-structure agent goes after ownership and share capital in tax filings. An officer-registry agent pulls directors and appointments. A retrieval agent works sanctions, PEP and adverse-media sources.
Each one hands back structured data. The orchestrator compares field by field across the three categories, and every material difference becomes an exception carrying both sources and both retrieval timestamps. When the specialists finish, the analyst gets the list.
All of it runs on the Moring AI Control Plane (AICP), deployed into your own cloud. Your platform team can open any session, read the prompts for the orchestrator and each sub-agent, see the tool calls, follow the traces, inspect the execution graph, and check the cost, without raising a ticket with a vendor to reach your own audit data.
What does ROI look like for a KYC evidence agent?
The arithmetic is annual cases multiplied by hours saved per case multiplied by loaded hourly cost.
Illustrative only. The figures below use made-up inputs to show the calculation structure. Do not use them as benchmarks. Substitute your own numbers.
A commercial bank running 2,000 commercial KYC cases a year, saving 1.5 hours on each, at $65 an hour loaded, recovers roughly $195,000 of analyst capacity. A global asset manager at 10,000 cases on the same assumptions recovers roughly $975,000.
To build your own estimate: time twenty of your current cases end to end. Split the hours: how many go on gathering and comparing, how many on the officer’s review, and how much of that review is really just re-checking evidence quality. Run ten similar cases through the agent. Take the difference, then multiply by volume and cost.
Be careful with anyone offering you a percentage improvement without showing their assumptions. Productivity in commercial KYC looks nothing like retail KYC, which looks nothing like transaction monitoring. What you save depends on how many sources you query, how often they disagree, how many exceptions need real judgment, and how your officers actually spend review time. None of that is knowable from outside your building.
What is under development?
Four things are not shipped yet, and it is better to say so here than have you find out during a pilot.
A picture of who owns what: the entity, the shareholders, the percentages, the holding companies in between, the ultimate owners, with conflicts marked. The chain is readable today, but as a list, not yet a diagram.
Spreadsheet export, for cases carrying enough exceptions that working through them in a browser stops being sensible.
Wider registry and tax coverage, to reduce how often ownership data simply is not available. Part of that is a commercial problem more than an engineering one, because some of the better ownership data sits behind pro-tier licences.
And agent identity. The aim is that every action traces to four things: the employee who initiated it, the named agent that acted, the owner accountable for that agent, and the human who approved the result. We want that chain to hold even when the agent crosses from one cloud to another. Two related controls are already live and worth separating out. Skills and tools are scanned before they are published, and every call through the gateway records a guardrail verdict of passed, flagged or blocked. What is still in progress is re-checking an agent’s tool access while it runs, instead of only at the point it was registered.
Frequently asked questions
What is a KYC evidence agent?
An agent that gathers and compares KYC evidence without deciding on it. It retrieves what the applicant keyed in, what they uploaded, and what corporate registries, tax authorities, sanctions lists, and adverse-media sources hold. It then flags every material conflict between them and asks for more evidence where the record is thin. It does not approve or reject anyone. See AI agents for banking and financial institutions for the full set of banking workflow agents Moring builds and deploys.
Can an AI agent approve KYC?
Not in the scope described here. An agent can gather evidence, compare sources, score against a rubric, and surface exceptions. Approving onboarding, rejecting a customer, and clearing a screening alert all require judgment about risk appetite and regulatory interpretation, and they need a named person’s accountability behind them. In the workflow described here, that boundary is enforced by the control plane, so the action is not available to the agent at all. SR 26-2 excludes generative and agentic AI from its scope and leaves banks to determine appropriate governance for systems outside it. Building the boundary into the orchestration layer rather than a prompt is one way to demonstrate that you have.
What happens when ownership records disagree?
Both values stay on the record. If a registry shows 22 percent and a tax extract shows 28, the agent presents them side by side with their sources and timestamps and asks for more evidence. An analyst reviews the dates, decides which to trust, and writes down why. If neither source is definitive, they request a certified share registry from the company secretary. The compliance officer sees the conflict, the decision, and the reasoning before approving anything.
What audit trail do regulators expect from AI agents?
Enough to reconstruct a decision months later. In practice that means the session, the prompt version that was live, every tool call, the agent’s reasoning, what each sub-agent did, and most importantly which human made which call and on what basis. Refused and blocked actions matter as much as successful ones, because they are what demonstrates the boundary was actually holding.
How do you measure ROI on a KYC agent?
From your own baseline, not a vendor’s percentage. Time twenty current cases from submission to approval and record where the hours go. Run ten comparable cases through the agent. Multiply the saving per case by annual volume and loaded analyst cost. As an illustration of the calculation structure only (not a benchmark): 2,000 cases a year at 1.5 hours saved and $65 an hour is about $195,000 of recovered capacity. Your numbers will differ based on case volume, source count, exception rate, and how your officers spend review time.
How is this different from RPA?
RPA follows a fixed script, clicking here and copying that field into this system, and it breaks when a page layout or document format changes. A KYC agent reasons about conflicting evidence, copes with documents that do not share a structure, and hands the ambiguous cases to a person. RPA suits deterministic work with stable interfaces. Agents suit work that needs comparison and judgment across messy inputs.
Map your KYC workflow and design a governed evidence-reconciliation agent in a free banking workflow workshop.