Opening a new customer is the most document-heavy thing a bank does, and the most tedious. Know-your-customer (KYC) onboarding means collecting identity documents, verifying them, screening the name against sanctions and politically-exposed-person lists, untangling beneficial ownership, and assessing the risk the relationship carries — before a single transaction clears. Most of it is mechanical assembly. None of it is fast.
An AI agent is well-suited to the assembly. It can read the documents, pull the corporate registry, run the screening, summarize the adverse media, and hand a human a finished file in minutes instead of days. That is a real win, and it is why customer due diligence (CDD) is one of the first places agents get pointed.
The danger is the step that looks like the next logical one: letting the agent decide the customer is acceptable and open the account. That is not assembly. That is the onboarding decision — a regulated judgment with the bank's name on it — being made by an actor no examiner authorized to make it.
The line through the onboarding file
There is a clean division of labor in a CDD workflow, and it pays to draw it before any agent touches the queue.
| Stage | Who acts | Why |
|---|---|---|
| Collect and verify documents | Agent | Mechanical, high-volume, reviewable |
| Screen sanctions, PEP, adverse media | Agent | Fast, comprehensive, never final |
| Resolve obvious false matches | Agent, under policy | Reversible, sampled, logged |
| Escalate to enhanced due diligence | Named officer | Mandated human judgment |
| Approve or decline the relationship | Named officer | The bank's accountable decision |
The first three stages are where the speed lives. An agent reads what would take an analyst an afternoon and produces a structured file in seconds. It can clear the noise that policy already defines as clearable — the common-name watchlist hit, the transposed date of birth — and it can rank what remains so the harder cases reach a person first.
The last two stages are different in kind. The decision to escalate a customer to enhanced due diligence (EDD) — the deeper investigation a higher-risk relationship requires — and the decision to onboard or refuse are both judgment calls with legal weight. They belong to a named officer, not to the model that assembled the file.
EDD is exactly the wrong place to remove the human
It is tempting to let the agent triage straight through: clear the low-risk customers, escalate only the rest. The clearing is fine, under policy. The escalation threshold is where the temptation gets dangerous.
Deciding that a customer is not high-risk — that a relationship does not need enhanced scrutiny — is itself a consequential call. An agent that quietly sets that threshold too low is not running fast. It is running a CDD program that under-investigates by design, and nothing in the file would show the line was ever crossed.
So the rule is not "let the agent escalate." It is: the agent can recommend escalation and assemble the EDD pack, but the decision to clear a customer past the EDD threshold, and the decision to onboard, both stop at a person.
The Wolfsberg standard says the same thing
This is not a MakerChecker preference. The Wolfsberg Group — the consortium of global banks that writes the de facto reference for financial-crime controls — names the four-eyes principle, the maker-checker split, as the control standard for exactly these decisions. One actor prepares the file; a different, qualified actor reviews and signs. The reviewer owns the call.
The principle is older than the technology, and that is the point. When the maker was a junior onboarding analyst and the checker was a compliance officer, the separation was held by org charts and sign-off forms. When the maker becomes an agent, the org chart stops helping. The agent does not sit in a reporting line. It cannot be questioned, disciplined, or held personally liable. The control has to move somewhere the agent cannot edit — and stay provable.
Why the prompt won't hold this line
The obvious fix is to instruct the agent: assemble everything, screen everything, but never clear a high-risk customer and never open an account without a human. This reads like a control. It is a request.
A prompt instruction has no record of who set the boundary, no version history when it changes, and no proof — months later, in an examination or a discovery request — that the agent actually stopped where it was told. An agent that is re-prompted, upgraded, or jailbroken can quietly start onboarding the customers it was meant to escalate, and nothing in the file would show the boundary ever existed. "It was in the system prompt" is not evidence an examiner accepts.
A control plane moves the boundary out of the agent and into enforced, versioned policy. The agent's authority to act on a file is a grant attached to its role, denied by default, and that grant simply does not include "clear a high-risk customer" or "open the account." The agent can propose. It structurally cannot complete.
The requester cannot approve its own request
Here is the rule that does the real work, and it is the one prompts can never deliver. When the CDD agent escalates a file, it becomes the requester. The control plane parks the run at an approval gate and demands a signature from a named officer — and the officer who signs cannot be the agent that raised it. The same actor provably cannot be both maker and checker on one onboarding.
This matters more with agents than it ever did with people, because an agent is fast enough to assemble and self-approve thousands of files before anyone notices the pattern. Structural segregation removes the possibility rather than auditing for it after the fact. The agent that built the file is barred from approving the relationship, full stop — and every attempt, including the refusals, lands in the record.
What the officer signs is captured with its meaning intact: the decision, the signer's identity, and the reason in their own words, linked to the exact version of the file they reviewed. That turns the onboarding sign-off from a checkbox into defensible evidence.
What the examiner gets
KYC and CDD obligations are date-proof. They sit underneath the customer due-diligence and enhanced-due-diligence expectations every supervised institution already runs against, and they did not move when the guidance for agents went quiet. The question an examiner asks about an onboarding file is the same one they ask about an AML escalation: prove the agent could not open this account on its own, and prove the record of who decided what is intact.
A control plane answers it directly. Every document the agent pulled, every screening hit it cleared under policy, every escalation it raised, and every human signature lands in an append-only, hash-chained, cryptographically signed ledger. Change one record and the chain visibly breaks. The export verifies offline, against a published spec, by someone who does not trust the vendor — which is the posture you want when the third party is a regulator who distrusts the vendor by default.
This is also where the line with content guardrails matters. Tools that screen an agent's output for prompt injection or unsafe text answer "is this content dangerous?" They are useful, and they are not this. A control plane answers a different question: "is this actor authorized to take this action, and who signed it?" You want both. Only one of them keeps an onboarding decision in human hands.
Done this way, the split holds at speed: the agent does the document work, the institution keeps the judgment, and the decision the bank is accountable for stays with a person — not as policy hope, but as a structural fact the audit trail can demonstrate to anyone who asks. CDD is one queue; the same pattern runs across alert handling, sanctions, and reconciliation across the bank middle office, and it is the same discipline that keeps an AML escalation in human hands.
See how it works, or book a demo to watch an agent get blocked from approving its own onboarding decision — live.