Customer onboarding & KYC workflow agent

Onboarding a new bank, fintech or corporate customer means collecting documents, verifying identity, screening against sanctions lists, finding the real owners behind a company and writing a risk-rated file. Much of this is chasing and reconciling information across systems. An agent runs the workflow end to end, calls deterministic identity and screening services as tools, drafts the file and escalates judgement calls to a compliance officer. Typical aim: shorter time-to-account and fewer analyst hours per file, without weakening AML controls.

Problem & value

• Today: analysts re-key application data, request missing documents by email, search company registers, trace ownership chains across jurisdictions, triage screening alerts (mostly false positives) and write the narrative for the file. Corporate (KYB) cases with multi-layer structures take days to weeks; drop-off during slow onboarding is a major commercial loss.
• AI value: document intake and consistency checks, automated chasing, registry lookups, UBO graph assembly, first-pass alert triage and file drafting; analysts concentrate on high-risk and ambiguous cases.
• Regulatory pull: the EU AML Regulation (EU) 2024/1624 applies from 10 July 2027 with directly applicable customer due diligence (CDD) rules; AMLA is finalising the CDD technical standards in 2026 (consultation closed May 2026, submission to the Commission planned for Q3 2026; check AMLA for the final status) [1][2]. Institutions are redesigning onboarding processes now. Vendor ROI claims (e.g. percentage time savings) are marketing figures; measure your own baseline.

Variants

• Retail onboarding (B2C): mostly automated ID verification plus screening; agent handles exceptions and missing data.
• Corporate onboarding / KYB: registry retrieval, ownership-structure mapping, UBO identification, source-of-wealth narrative; the strongest agent use case because the work is unstructured.

• Fintech / payment institutions / crypto-asset providers: high volume, API-first, risk-based tiering.

• Periodic / event-driven review (perpetual KYC): same agent refreshes existing files; see AGENT-011.

How it works

application intake (web/app/RM)
  -> identity proofing tool (document check + liveness, eID / EUDI wallet where available)
  -> document intake & extraction (ID, registry extracts, statutes, UBO forms)
  -> registry lookup (national registers, BRIS, transparency registers, LEI)
  -> ownership graph & UBO derivation (threshold, control by other means)
  -> screening (sanctions, PEP, adverse media) + alert triage draft
  -> risk scoring (rules + model) and EDD triggers
  -> gap detection -> auto-request to customer / RM
  -> file narrative + recommendation
  -> human approval (compliance officer) -> account opening in core banking/CRM
  -> monitoring hand-off + review schedule

• Deterministic cores: identity matching, sanctions list matching and the final risk-score rules stay in certified or rule-based components; the LLM reads, reconciles, summarises and drafts.
• Human-in-the-loop: mandatory sign-off for high-risk customers, PEPs, EDD, any rejection, and any alert closed as true match; sampled QA on auto-cleared low-risk cases. Four-eyes principle retained.

Data preparation

Data needed: ID documents and selfies, commercial register extracts, beneficial-owner structures, sanctions and PEP lists, existing customer master data, and the institution's risk policy and onboarding rules. These live in CRM or core banking, the DMS, mail inboxes and paper copies. Typical gaps: poor scan quality, multilingual and foreign documents, duplicate customer records, outdated risk-scoring rules in Word or PDF, inconsistent entity names for screening, and unclear retention periods.

Preparation steps: (1) document the onboarding process with its risk tiers and required evidence (PREP-002); (2) turn the risk policy into a maintained knowledge base (PREP-013); (3) deduplicate and normalise customer and company names before screening (PREP-011); (4) extract data from ID documents with fitted tools (DOC-004) and OCR older files (PREP-006); (5) assemble test cases of past onboardings with the final decision as an evaluation set (PREP-018, PREP-020); (6) set retention rules and check legal basis (PREP-025) and pseudonymise test data (PREP-022).

Effort: medium, about 25-35 %, since vendors deliver much of the data capture; the main work is rules and master-data quality. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path A - KYC is a standard, heavily regulated process and mature EU-hosted providers sell it per verification at SMB prices; building your own adds audit risk.
• Enterprise: Path A - identity verification and screening are commodity functions with certified vendors; build only the orchestration around them (Path B) where you have special onboarding journeys.
• Developer: Path B - integrate vendor verification and screening APIs with a cloud-model-based orchestration and case-file agent.

Path A — Buy (recommended for most obliged entities)

• Identity verification & orchestration: Onfido (Entrust), Veriff (EU), IDnow (DE), Signicat (NO), Sumsub, Jumio, Persona, Fourthline (NL), WebID (DE), Idenfy (LT).
• KYB / KYC lifecycle & AI agents: Moody's (Orbis/Maxsight), LSEG World-Check and Dow Jones Risk & Compliance (screening data), Fenergo, Quantexa (UBO/entity resolution), Napier AI, Hawk, ComplyAdvantage, Lexis Nexis Risk, Encompass, Parcel, Alloy, Workfusion and Pega/Appian-based onboarding suites.
• Choose A when: regulated, limited in-house ML team, need supervisor-accepted vendors with audit evidence. Check EU data residency, certification of the ID solution, explainability of alert decisions and exit options (the institution remains responsible when outsourcing; see EBA guidelines [3]).

Path B — Build on cloud APIs

• Models: frontier LLMs with EU processing (Claude via AWS Bedrock or Google Vertex EU regions, Azure OpenAI EU data zones, Gemini on Vertex EU) or EU providers (Mistral). Structured outputs for extraction.
• Documents: Azure Document Intelligence ID model, Google Document AI identity processors, AWS Textract AnalyzeID, Mistral OCR.
• Tools via MCP or function calling: registry APIs (e.g. OpenCorporates, Handelsregister-based providers, national transparency registers), screening vendor API, case management.
• Orchestration: LangGraph, Temporal or Camunda for durable state and approvals; n8n for lighter flows.
• Choose B when: you have a platform team and a specific process or legacy stack that vendors do not fit.

Path C — Self-host (open source)

• Models: open-weight reasoning/instruction models (Qwen3, Llama, Mistral, gpt-oss class) via vLLM; Docling, PaddleOCR or olmOCR for documents; Qwen-VL for visual document reading.

• Stack: Neo4j or Memgraph for ownership graphs, OpenSanctions / yente (open sanctions and PEP data and matching API, commercial licence for business use) [4], OpenSearch, Temporal/Camunda, Langfuse for tracing.

• Hardware: HW3 for a 30-120B model serving analysts; HW2 suffices for extraction-only pipelines.

Path D — Custom training

Worthwhile for entity-resolution and name-matching models, document-fraud classifiers or alert-triage models trained on the institution's own historical alert dispositions (thousands of labelled cases). Generic LLM fine-tuning is rarely needed.

State of the art (2026)

• Agentic KYC is moving from pilots to production at large banks and vendors: agents that retrieve registry data, build UBO graphs and draft the file; vendor launches in 2025-2026 position them as "digital analysts". Evidence is mostly vendor case studies; independent benchmarks are scarce.

• Identity layer is changing: EBA remote-onboarding guidelines (applicable since 2 Oct 2023) set expectations for liveness, document checks and outsourcing [3]. The EU Digital Identity Wallet (Regulation (EU) 2024/1183) is due in each Member State by end of 2026, with acceptance duties for banks and other regulated sectors roughly a year later; national readiness is uneven [5]. Wallet attestations will shift part of onboarding from document scanning to credential verification.

• Limits and failure modes: hallucinated registry facts, wrong entity matches for common names, missed control-by-other-means ownership, silent skipping of steps, over-trust in adverse-media summaries and inconsistent risk rationales. Mitigate with source-cited statements, deterministic matching, evaluation sets of historic files and mandatory human sign-off.

Shared resources & combinations

• Same stack: DOC-004 (ID document extraction), ANOM-014 (forgery and liveness), ANOM-016 (sanctions/PEP screening with alert adjudication), ANOM-017 (document tampering), DOC-022 (trade-finance documents).
• Downstream: AGENT-028 (credit memo), PRED-009 (credit scoring, separate high-risk assessment), AGENT-011 (CRM hygiene and perpetual KYC refresh).

Effort, cost & KPIs

• Path A: 3-9 months for integration with core banking, case management and policy mapping; licence per verification/check or per entity.

• Path B: 6-12 months incl. model risk management, evaluation and supervisor dialogue.

• KPIs: time to onboard (median/P90), straight-through rate for low-risk cases, onboarding abandonment, analyst minutes per file, alert false-positive ratio, QA error rate vs. human baseline, rework after supervisory or internal-audit review, share of files with complete source citations.

People & change

Involve management and the compliance or money-laundering officer (legal-compliance) as owner of the risk policy, the onboarding department lead and the analysts who will review files, IT for CRM and core integration, and the DPO (ID data, possibly biometrics; DPIA likely, AVV with every verification provider). Inform customers transparently about automated checks and how to reach a human.

Works council: yes in practice. Case management that records analyst decisions and handling times is objectively suitable for monitoring (§87(1) no. 6 BetrVG, BAG case law); §90(1) no. 3 requires early information about AI in work processes and §80(3) allows an expert. Public bodies involve the staff council.

Take measures to support AI literacy (AI Act Art. 4): analysts need to know what the agent checks, its false-positive and false-negative patterns, and that a negative decision never rests on the agent alone. Run a parallel pilot with a small team (agent proposal versus analyst decision) and measure agreement before go-live. Communicate that the agent removes document chasing, not accountability; the analyst signs off high-risk files, PEP hits and rejections. Typical concerns - regulatory exposure and audit trail - are met by full logging and supervisor sampling. Guides: GUIDE-005, GUIDE-010, GUIDE-014.

Risks, regulation & compliance

• EU AI Act: classification depends on scope. Fraud-detection AI used to detect financial fraud is excluded from the Annex III creditworthiness category, and pure document handling or screening support is usually minimal or limited risk (chatbots: Art. 50). Systems that evaluate creditworthiness or credit score natural persons are high-risk (Annex III 5(b)); a KYC agent that feeds an account-opening decision with a credit element may cross that line. Remote biometric identification systems are listed high-risk in Annex III; biometric verification (1:1 confirming a claimed identity) is excluded from that category. Art. 5 prohibitions: no social scoring, no biometric categorisation inferring sensitive traits, and no untargeted scraping of facial images; keep all of this out of the onboarding design [6].
• AML law: AMLD (current), AMLR 2024/1624 from 10 July 2027, AMLA technical standards; ultimate responsibility stays with the obliged entity, including for outsourced or AI-supported steps [1][2][3].

• GDPR: biometric data used to uniquely identify is special-category data (Art. 9); needs a legal basis (often national AML law or explicit consent), DPIA, data minimisation and retention limits. Art. 22 limits solely automated decisions with legal effect: keep meaningful human review of rejections. Transfers of documents to non-EU model endpoints need a valid mechanism; prefer EU regions.

• Mitigations: policy-bound state machine, source citation, immutable audit trail, sampling QA, model validation, kill switch, fallback manual path for customers who cannot use digital onboarding.

Getting started

1. Map the current onboarding process by segment and risk tier; measure cycle time, abandon rate and analyst effort.
2. Define which steps are deterministic, which are agent-assisted and which need mandatory human approval.
3. Pilot on KYB document review and UBO drafting for low- and medium-risk files, in shadow mode against analysts.
4. Build an evaluation set of 200-500 historic files; measure extraction accuracy, citation correctness and disagreement with analysts before any automation.
5. Run DPIA, AI Act classification and model-risk review; brief the supervisor early.

Sources

1. Regulation (EU) 2024/1624 (AML Regulation) - https://eur-lex.europa.eu/eli/reg/2024/1624/oj
2. AMLA - draft RTS and guidelines on customer due diligence (consultations, 2026) - https://www.amla.europa.eu
3. EBA - Guidelines on the use of remote customer onboarding solutions (EBA/GL/2022/15) - https://www.eba.europa.eu/legacy/regulation-and-policy/regulatory-activities/anti-money-laundering-and-countering-financing-4
4. OpenSanctions / yente - https://www.opensanctions.org/docs/yente/
5. Regulation (EU) 2024/1183 (European Digital Identity Framework) - https://eur-lex.europa.eu/eli/reg/2024/1183/oj
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Kennedys Law - The European Digital Identity Framework and the EU Digital Identity Wallet (2026) - https://kennedyslaw.com/en/thought-leadership/article/2026/the-european-digital-identity-framework-introducing-the-new-eu-digital-identity-wallet/