How to handle onboarding exceptions with an AI agent

Sort exceptions into those the customer can fix and those that need judgement. The agent classifies each onboarding exception, requests missing or better documents, re-runs checks when they arrive and drafts a proposed resolution. Screening hits, enhanced due diligence, unclear source of funds and the decision to accept or decline a customer stay with a named analyst.

What are onboarding exceptions, and who owns them?

Most applications pass onboarding checks cleanly. The rest stop on an exception: an expired or unreadable identity document, a name that differs between the document and the application, a missing proof of address, a possible sanctions or politically exposed person match, a complex ownership structure, or a source of funds that does not add up. Exceptions are where onboarding queues build and where risk concentrates.

The head of onboarding operations owns the exception process. The financial crime team owns screening and due diligence decisions. The money laundering reporting officer owns anything suggesting suspicion. Customer due diligence follows a risk-based approach, as set out in the FATF Recommendations and national rules. The standard flow before exceptions arise is in how to process new customer onboarding files with an AI agent.

What are the steps, and at what depth?

1. Agent, depth 1: classifies the exception by type: document quality, document validity, data mismatch, missing evidence, screening match, risk factor, or complex structure.
2. Agent, depth 1: routes judgement exceptions straight to an analyst: screening matches, high-risk factors, complex ownership, source of funds.
3. Agent, depth 3: requests documents for fixable exceptions using approved templates: a clearer copy, an in-date document, a recent proof of address.
4. Agent, depth 3: sends reminders on a set schedule while the application waits.
5. Agent, depth 1: re-runs checks when new documents arrive, recording which document cleared which exception.
6. Agent, depth 2: drafts a resolution for name mismatches and similar data issues, such as a recognised name variant or a marriage certificate, for an analyst to accept.
7. Agent, depth 2: prepares the analyst pack for judgement exceptions: the match details, the customer's information, sources and what is still unknown.
8. Person, analyst: resolves judgement exceptions and decides to accept, decline or escalate.
9. Agent, depth 2: proposes closing stalled applications after the set period; an analyst confirms.

What stays with a person, and why?

Screening matches. Deciding whether a possible sanctions or politically exposed person match is the customer is a regulated judgement. An agent that could clear matches could be steered into clearing a real one.

Enhanced due diligence. Higher-risk customers need a person to weigh source of wealth, purpose and ownership.

Accept or decline. Whether to take a customer on is a decision the firm answers for.

Suspicion. If anything suggests money laundering, the analyst escalates to the reporting officer. The agent must not alert the customer, and its messages must never mention screening or suspicion.

How to handle work that falls outside what any agent should process is discussed in how do you handle the exceptions an AI agent cannot process?

Which controls matter, and what evidence do they leave?

Templates that reveal nothing. Document requests never mention screening or risk. Evidence: the template version on each message.

Provenance on documents. A document uploaded by the customer is declared; a check against an issuing authority is signed. Evidence: provenance on each document used to clear an exception.

Clearing tied to evidence. Every cleared exception names the document or check that cleared it. Evidence: the exception log.

No agent clears screening. Evidence: role scope excluding the capability, and refusals if attempted.

Analyst decisions recorded with reasons. Evidence: decision records with analyst identity.

What should you measure?

Exceptions by type, time to resolve by type, exceptions cleared by customer documents without an analyst, applications abandoned while waiting, analyst time per judgement exception, and later findings that an exception was cleared wrongly. Abandonment matters: slow exception handling loses good customers.

Where does it usually go wrong?

Fixable and judgement exceptions share a queue. Analysts spend time chasing documents while screening matches wait.

The customer is told too much. "We need more information because your name matched a sanctions list" can tip off a real target and distress an innocent one.

Repeated requests annoy customers. The agent asks for documents one at a time. Ask for everything needed in one message.

Name variants are accepted too readily. Transliterated names and spelling differences are common, but so is impersonation. Analysts should accept, not the agent.

Business applications are treated like personal ones. Exceptions on company applications often involve ownership chains, nominee directors or overseas entities. The agent can map the structure from registry extracts and the application, but deciding who the beneficial owners are, and whether that is enough, belongs to an analyst.

Where Pryme fits

In Pryme, documents arrive with their provenance class, so an uploaded document is treated as declared until checked. Clearing screening matches sits outside the agent's role scope, and accept or decline decisions are held for a named analyst. The rollout approach is in deploying an AI agent: train, shadow, certify, widen.