AI Adoption GuideBankingOnboard
Agentic KYC orchestration
Multi-step AI agent traverses core banking, CRM, and external AML, PEP, and sanctions APIs to complete KYC checks end-to-end without manual routing.
Banking processAcquireOnboardOpenFundTransactServiceReviewClose
By Don, DoneThat’s AI coach · updated
Complete the checklist the bank already owns
The agent runs the KYC procedure the bank already owns. It executes those steps in order, calls the same APIs the desk uses, and either marks the file complete or stops. Speed comes from removing handoffs between core banking, CRM, and screening. A pass still means every required check returned a defined result. The agent does not invent a pass because the applicant sounded cooperative, because a CRM note said identity was seen, or because one screening hop timed out.
Give it the live checklist, not a parallel AI path. If retail individuals skip enhanced due diligence unless a hit appears, it follows that branch. If the product requires sanctions before PEP, it does that. A second path will drift from what audit, the core product, and the AML workbench enforce.
Systems in this class stay systems of record. Temenos holds the customer. Salesforce holds relationship context. NICE Actimize holds investigation workflow. Dow Jones-class sources hold PEP and sanctions list content. Onfido-class tools hold document and biometric capture. The agent maps fields, calls those systems, and stores reference IDs. It does not replace a vendor result with a chat summary.
Analysts own true hits and data gaps. Clean files finish faster. Exceptions wait at a human gate.
Run identity, core, and CRM steps before screening
Walk the file in the order the desk already uses. Do not screen a name the bank has not tied to evidence and a customer record.
Confirm the packet is complete enough to start: legal name, date of birth, nationality, address, product, and the identity evidence policy requires. If ID capture is still in flight, wait. Pull structured fields from the document via form pre-population from ID extraction, not from a chat paraphrase. A spoken name that disagrees with the document is a data gap.
Run document authenticity and liveness when those controls sit on the packet. A still image of a passport is not a completed identity check. Use liveness and deepfake detection so a replayed selfie cannot satisfy the ID control.
Look up the applicant in core banking before any list call. A duplicate customer, existing relationship, restricted product, or account closed for cause changes the rest of the path. Write the core customer number onto the file so later hits attach to the right record. Create only the pending onboarding status the product already uses. Do not activate the account before screening has a final result.
Read CRM for introducer, household, and prior KYC status. Do not treat a Salesforce note as proof that ID was verified. Notes are commentary. The ID check is a system result from the capture vendor or the branch process.
Only then call AML, PEP, and sanctions APIs. Risk tier belongs in policy, not in model confidence. Use risk-tiered onboarding routing so high-risk products and geographies take the longer checklist, and the agent follows that branch without rewriting it.
Treat each screening API as its own control
Each screening call has its own retry, timeout, and hit handling. A successful PEP response does not clear a sanctions timeout. A clean chat does not clear a possible match.
Sanctions: send the identifiers your screening standard requires, typically name, date of birth, nationality, and known aliases. Wait for a definitive response. A timeout is not a clear. If the vendor or gateway asks for a retry, retry the count the runbook already specifies. If the retry fails, queue the file. Do not continue to PEP so the file keeps moving. Skipping a failed sanctions retry is a skipped control, even if every later call returns clean.
PEP: run PEP as PEP, not as a fuzzy extra on the sanctions response. A PEP match is not automatically a decline. It is an enhanced path: source of wealth, source of funds, and the senior-approval rules policy already names. The agent collects the packet those rules require and stops.
Where NICE Actimize or an equivalent case system is the investigation store, open or update the case with the raw screening payload, not a one-line agent summary. Collapsing five API results into "no issues found" hides a possible match from the analyst who is supposed to own it.
Adverse media, if it sits on the onboarding checklist, is another control, not a substitute for list screening. Keep it on adverse media screening. Dow Jones-class list data remains an input. Store the list identifiers. Do not re-score a hit because the applicant offered an explanation in chat.
Queue when a check fails or is incomplete
The human gate is the design. Queue, and block account activation, when a required field is missing, unreadable, or conflicts with the ID extract; when core banking cannot create or match the customer; when an ID or liveness check is failed, expired, or not returned; when a sanctions, PEP, or AML API errors, times out after retries, or returns an unresolved possible match; or when the result is a true hit or a possible match above the auto-clear threshold the screening standard already uses.
The queue item must show which step failed, the raw vendor response or error, the payload sent, the retry count, and what the agent did not do next. If sanctions never returned, the item must not imply that PEP covered it.
Do not auto-approve because the conversation sounded fine. If screening is pending, the file is not approved.
The same stop logic applies after go-live when a refresh finds a new hit. That work is perpetual KYC refresh, not a second onboarding product with a looser gate.
How files get marked complete by mistake
Three patterns show up even when the desk would have stopped.
Skipping a failed sanctions retry. The first sanctions call times out. The agent writes that screening is in progress, calls PEP successfully, and marks KYC complete because two of three screens returned. Fail the whole KYC step if any required screen is not a final clear, a hit, or a queued exception. Partial completion is not completion.
Treating CRM notes as a completed ID check. Salesforce shows that a passport was copied at a branch in a prior year. The agent skips the current Onfido-class capture and proceeds to screening. Relationship notes are not identity assurance for this application. If the product requires a fresh ID and liveness packet, the note is context only.
Auto-approving because the chat sounded fine. The applicant answers promptly, denies any PEP or sanctions nexus, and the model treats that as evidence. Policy evidence is the API result and the ID vendor result. Narrative agreement is not a substitute.
Also watch for continuing after a possible match because the agent thinks it resolved an alias; writing a Temenos customer as onboarded before sanctions returns; and storing only the agent's prose so the analyst never sees the possible-match payload.
Walkthrough: a mid-risk current-account application
A salaried applicant in the bank's home country applies for a current account. Policy says: ID and liveness, core duplicate check, CRM household lookup, sanctions, PEP, then an AML case write only if an alert exists. No enhanced due diligence unless a hit or a high-risk attribute appears.
The agent retrieves the identity session: document extracted, liveness passed. It pre-fills the application from the extract and asks only for fields the document did not provide. It queries the core for duplicates, finds none, and creates a pending customer in the onboarding status the product already uses, not a live account. It reads CRM: no existing relationship. It calls sanctions. The first call times out. It retries once, matching the screening runbook. The retry returns a clear. It calls PEP: clear. No AML case is opened. The file is complete for this product.
Change one fact: the sanctions retry still errors. The agent must not open the account. It queues to KYC ops with the payload, the retry count, and a block on activation. An analyst reruns screening or treats it as an exception. That is the design: the existing checklist, faster routing, no invented pass.
If the PEP call had returned a possible match, the agent would still stop. It would attach the list-record identifiers and wait. The analyst decides true hit versus false positive. The agent does not.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first