AI agents for KYC and customer onboarding: where the agent assembles the case, and where a human still decides

Customer onboarding is the process every bank does thousands of times a month and still gets wrong at both ends. Push too hard on due diligence and good customers abandon the application — Fenergo’s 2025 survey found around 70% of institutions had lost prospects to slow onboarding, and roughly one in five applications is walked away from over KYC and AML documentation specifically. Push too little and you’ve onboarded a risk you’re accountable for. In between sits an army of analysts doing rule-bound, repetitive work: collecting IDs, running the same screening, chasing the same beneficial-ownership questions, assembling the same case file, over and over.

That’s the exact shape of problem an agent is good at, which is why KYC onboarding is one of the clearest agentic-AI business cases in banking right now — and why the real deployments are showing up. ING has described rebuilding its client-due-diligence workflows around agentic AI with the explicit goal of asking customers for less, by drawing on registry and behavioral data the bank already holds. DBS in Hong Kong announced a March 2026 partnership to automate SME onboarding with real-time business verification across scores of jurisdictions. The category is real and shipping.

The category is also where teams get the boundary catastrophically wrong. An agent that assembles a KYC case is a genuine near-term win. An agent that decides the customer’s risk rating, closes out enhanced due diligence, or files a suspicious-activity report is a compliance incident wearing a productivity costume. This post is the line between those two — drawn where the regulators draw it — and the Salesforce architecture that captures the value without stepping over it.

Why onboarding, and not the risk decision, is the target

The instinct is to point AI at the judgment: “let the model decide who’s high-risk.” That’s the wrong first target, and understanding why shapes the whole build.

The judgment is the small, regulated part. The preparation is the large, mechanical part — and it’s where the cost and the delay live. Taking a new customer from application to a reviewer-ready file means intake, identity verification, sanctions and PEP screening, untangling who really owns a legal entity, checking against existing customers, and compiling all of it into a documented case. None of that is a risk decision. All of it is high-volume, rule-bound, and painfully manual today. That’s the automation target: assemble a complete, defensible case and hand it to a human, exactly the division of labor we drew for AML alert triage — with the important difference that AML triage works the ongoing surveillance queue, while onboarding is the front door. Same principle, different door.

As one 2026 practitioner summary put it: preparation and prioritization are increasingly automatable; regulatory accountability is not. Hold onto that sentence — it’s the whole design.

The onboarding workflow an agent can genuinely own

Here’s the sequence an agent can take end to end, right up to the decision gate. Each step is real work the agent does; none of it is a judgment call reserved for a human.

1. Intake and pre-fill. A conversational agent captures the application, but the higher-value move is not asking — pulling name, address, and entity details from public registries and data the institution already holds, so the customer completes fewer fields. Less friction here is the single biggest lever on abandonment.

2. Identity verification (IDV). The agent orchestrates document authentication and a liveness/biometric check through a specialist identity-verification provider, then records the result. This is where a customer identification program actually gets satisfied — more on the regulatory framing below.

3. Sanctions, PEP, and adverse-media screening. The agent runs the names — the individual and, for an entity, its controllers — against watchlists and adverse-media sources, and generates the potential matches. It does not dispose of an ambiguous match; it surfaces it with context.

4. Beneficial ownership resolution. For a legal-entity customer, the agent parses the corporate structure and resolves the ultimate beneficial owners and controlling parties across jurisdictions. This is some of the most tedious, error-prone work in onboarding and one of the strongest cases for automation.

5. Entity resolution and deduplication. The agent matches the applicant against existing customers to avoid duplicate records and to reuse verified information — refining fuzzy name matches with secondary identifiers like date of birth and nationality rather than trusting a raw string match.

6. Case assembly. The agent compiles everything — verified identity, screening results with dispositions pending, ownership graph, risk factors — into a single, reviewer-ready dossier with a documented, cited reasoning chain. The output isn’t a verdict; it’s a file a compliance officer can act on in minutes instead of hours.

7. Perpetual KYC refresh. After onboarding, the same machinery runs continuously: a new sanctions hit, an ownership change, or fresh adverse media triggers an event-driven review, replacing fixed-interval refreshes that either arrive too late or waste effort re-reviewing customers nothing changed about. This “perpetual KYC” model is where much of the ongoing cost saving is reported — treat the specific percentages vendors quote as directional, but the direction is well-attested.

Notice what’s not in that list: setting the risk rating, signing off enhanced due diligence, deciding to open or refuse the account, or filing a SAR. Those are the next section.

The line you never cross

Here is the non-negotiable, and it’s a regulatory constraint, not a capability gap. The agent gathers, screens, resolves, and drafts. A human sets the risk rating, approves enhanced due diligence, decides whether to open or refuse the relationship, and makes the suspicious-activity determination. Getting this line right means naming the rules correctly, because two lists that sound similar are constantly conflated:

• The Customer Identification Program (CIP) comes from the USA PATRIOT Act (Section 326). It requires risk-based procedures to verify identity enough to form “a reasonable belief that it knows the true identity of each customer,” at minimum collecting name, date of birth, address, and an identification number. Crucially, a CIP must define what happens when the institution cannot form that reasonable belief — whether to refuse, close, or file. That branch is inherently a human judgment.
• The FinCEN Customer Due Diligence (CDD) Rule (finalized 2016, compliance from May 2018) sets four core elements: (1) identify and verify the customer, (2) identify and verify the beneficial owners of legal-entity customers, (3) understand the nature and purpose of the relationship to build a risk profile, and (4) conduct ongoing monitoring. Note the terminology trap: the classic BSA/AML program has four pillars — internal controls, a designated compliance officer, training, and independent testing — and the CDD Rule added CDD as a widely-cited “fifth pillar.” “Four CDD elements” and “four AML pillars” are different lists; an agent’s documentation should get this right, and so should yours.

The European package is moving in the same direction with more force. The EU’s single AML rulebook — Regulation (EU) 2024/1624 (AMLR) — applies from 10 July 2027 and sets harmonized CDD and beneficial-ownership obligations, with occasional-transaction due diligence triggered at €10,000 and cash-transaction checks above €3,000. It’s supervised by a new Authority for Anti-Money Laundering (AMLA), seated in Frankfurt and operational since July 2025. Underneath all of it, the FATF’s risk-based approach governs — and FATF’s Digital Identity guidance explicitly permits non-face-to-face, digitally-verified onboarding provided you make a risk-based judgment about the ID system’s reliability. Technology-neutral, but judgment-required.

There’s one more nuance worth getting right, because blogs routinely botch it. Under the EU AI Act, KYC/AML and fraud-detection AI is not automatically “high-risk” — Recital 58 carves out fraud detection in financial services from the Annex III high-risk list. What is high-risk is AI that assesses the creditworthiness of natural persons. The line blurs the moment your onboarding flow bundles a credit decision, or your KYC risk score starts driving account denial — at which point the high-risk obligations (risk management, data governance, technical documentation, and human oversight) attach. The high-risk obligations were deferred to December 2027 under the Digital Omnibus, but the design lesson lands today: keep the compliance-risk decision and any credit decision cleanly separated, and keep a human on the consequential one.

Auditability and model governance are the product

In most AI applications, explainability is a nice-to-have. In KYC it’s the deliverable, because the entire point of the program is to be defensible to an examiner. If the agent can’t show its work, its work is a liability.

That means every step is logged, attributable, and reconstructable: which sources the agent pulled, what it found, how it reasoned, and what the human decided next. When a regulator asks “why did you onboard this entity in March, and how did you satisfy yourself about its owners,” the answer has to be a complete record with linked evidence — not “the model was confident.” This is where the grounding and data-quality discipline stops being best practice and becomes a control: an agent that reasons only on facts it actually retrieved produces a defensible file; an agent that fills a gap with a plausible-sounding invention — a sanctions match that doesn’t exist, a risk rationale it made up — produces something that looks fine until it’s audited. The rule from every agent build applies with maximum force here: every fact traces to a source, or it doesn’t go in the file.

Two governance realities decide whether this survives contact with a regulator:

• Model risk management applies. The models behind the agent fall under existing model-risk expectations — in the US, the SR 11-7 framework, which the 2021 interagency statement confirmed covers BSA/AML and screening models: validation, ongoing monitoring, and outcomes analysis. An onboarding agent is a new entrant into the model-risk framework your institution already runs, not an exception to it.
• The agent’s access is an attack surface. An onboarding agent reaches identity documents, screening data, and customer records across systems. Its running identity must be scoped to least privilege and its inputs treated as untrusted — the same agent security posture any production agent needs, because an over-permissioned compliance agent is both a data-exposure risk and a control failure. And watch the fairness dimension: even with protected attributes excluded, a risk model can proxy-discriminate, which is exactly the territory regulators scrutinize when onboarding shades toward a lending decision.

Where Salesforce fits — and where it doesn’t

Be honest about the stack. Salesforce is not your identity-verification vendor or your sanctions-screening engine — those are specialist providers, and they should stay specialist. Where Salesforce earns its place is the layer around them: the unified customer record, the case workflow, the agent, and the audit trail.

• Financial Services Cloud (FSC) supplies the data model onboarding actually needs. Person Accounts for individuals, business accounts for entities, and the Financial Account Party and related structures that model beneficial owners and controlling parties — the natural home for a UBO graph rather than a bolt-on spreadsheet. FSC’s KYC/KYB data structures and party-profile framework put the regulatory data capture inside the client record.
• Data 360 (the platform formerly called Data Cloud) unifies the customer, screening, and third-party data into one real-time profile the agent reasons over — the grounding substrate that lets it gather context before it escalates, and the place where governed, permission-aware access decides what the agent can and can’t see.
• Agentforce hosts the agent itself: topics scope its mission, actions invoke the Flows, Apex, and API calls that reach the IDV and screening vendors, and an action can escalate to a human — the native home for the approval gate. The Einstein Trust Layer wraps every model call with grounding, masking, and zero-retention, and the audit trail records what the agent did.
• MuleSoft is the standard integration path from FSC out to the identity-verification and screening providers, so the agent calls governed APIs rather than screen-scraping a vendor portal.
• Flow orchestration drives the case and, critically, enforces the human-in-the-loop approval gate before a risk rating is set or an account is opened.

The honest architecture is a division of labor: specialist vendors verify and screen, Data 360 grounds, Agentforce assembles the case inside FSC, Flow enforces the gate, and a human decides. Building it as if Salesforce were the screening engine — or as if the agent were the compliance officer — is one more entry in the long list of reasons agent projects fail: wrong system of record, ungrounded confidence, and a human accountability line nobody drew. This front-door pattern is the same one we mapped for insurance submission intake: automate the assembly, keep the bind decision human.

The takeaway

KYC onboarding is a near-ideal agentic use case because the work is high-volume, rule-bound, expensive, and bounded — and the one part that isn’t bounded, the risk judgment, is small and clearly delimited. The pattern that works: let the agent handle intake, identity verification, screening, ownership resolution, deduplication, and case assembly, and run perpetual KYC in the background; keep the risk rating, the enhanced-due-diligence sign-off, the open/refuse decision, and any SAR firmly with an accountable human. Name the rules correctly — CIP under the PATRIOT Act, the four CDD elements under the FinCEN rule, AMLR and AMLA in the EU, the FATF risk-based approach — and treat the EU AI Act’s fraud-detection carve-out with care the moment onboarding touches a credit decision. Make every step auditable, subject the models to your model-risk framework, scope the agent to least privilege, and ground it strictly on real data. Do that and you turn onboarding from a week-long, abandonment-prone slog into a same-day, examiner-defensible process — without ever letting the machine be the one on the accountability line.

Understanding the basics

Can an AI agent do KYC onboarding on its own?

No — and building toward full autonomy is the fastest route to a compliance failure. An agent is well-suited to the preparation: capturing the application, verifying identity through a specialist provider, running sanctions/PEP/adverse-media screening, resolving beneficial ownership, deduplicating against existing customers, and assembling a reviewer-ready case file, plus running event-driven perpetual KYC afterward. The decisions — setting the customer risk rating, signing off enhanced due diligence, deciding to open or refuse the account, and filing a suspicious-activity report — must remain with an accountable human. Regulators expect high-stakes onboarding decisions to be interpretable, auditable, and attributable to a responsible person.

What KYC steps can be automated safely?

The high-volume, rule-bound preparation steps: intake and data pre-fill from registries and existing records, identity/document verification and liveness checks (via a specialist IDV vendor), watchlist and PEP and adverse-media screening, ultimate-beneficial-owner resolution for legal entities, entity matching and deduplication, and compilation of the case file with a documented, cited reasoning chain. Ambiguous screening matches, the customer risk rating, enhanced-due-diligence conclusions, and any decision to onboard, refuse, exit, or report stay with a human. The safe rule of thumb: automate everything up to the point where judgment and accountability begin.

Is using AI for KYC compliant with regulations?

Governed use is increasingly aligned with regulatory direction, but compliance depends on how you build it. Keep the risk decision, EDD sign-off, and SAR filing with an accountable human; log every agent step so the reasoning is reconstructable and attributable; ground the agent strictly on real data rather than letting it invent facts; subject the underlying models to your model-risk framework (SR 11-7 in the US); and watch the EU AI Act line — KYC and fraud detection aren’t automatically high-risk, but creditworthiness assessment of individuals is, so keep any credit decision separate and human-supervised. An onboarding agent that can’t show its work to an examiner is a liability regardless of how fast it is.

Where does Salesforce fit in KYC onboarding?

In the record, workflow, agent, and audit layers — not as the identity-verification or screening engine, which stay with specialist vendors. Financial Services Cloud provides the party and beneficial-ownership data model, Data 360 unifies customer and screening data into the profile the agent grounds on, Agentforce hosts the agent that assembles the case and escalates to a human, MuleSoft integrates the IDV and screening providers, and Flow orchestration enforces the approval gate before a risk rating is set or an account is opened. The division of labor is: vendors verify and screen, Data 360 grounds, Agentforce assembles, Flow gates, and a human decides.

---

Building the onboarding and due-diligence layer around a compliance program — a unified data foundation, a governed agent, and a human-in-the-loop that satisfies an examiner? Talk to us about financial services. Getting the data grounded and the accountability line drawn is the work that makes a KYC agent defensible, not just fast.