The agent assembles and checks the file; a named person accepts the customer. It confirms every required document is present, cross-checks names, dates and addresses across them, requests what is missing, runs the screening requests and drafts a summary with a proposed risk rating. A person decides on screening matches, higher-risk customers and the final approval.
What is in an onboarding file, and who owns it?
An onboarding file is the evidence that a firm knows who its new customer is. For an individual, it usually holds the application, identity evidence, proof of address and screening results. For a business, it adds company registration documents, the ownership structure, the beneficial owners and their own checks, and an explanation of the nature of the business. Customer due diligence of this kind is required under the FATF standards that most countries' anti-money laundering rules follow.
The onboarding operations team owns the process and the file's completeness. The financial crime or compliance team owns the policy: what documents are needed for which customer type, and what risk factors require enhanced checks. The approver, usually a senior onboarding officer or a compliance officer for higher-risk cases, owns the decision to accept.
What does the agent prepare, step by step?
- Agent, depth 1: reads the application and identifies the customer type and the products requested, which decide the document checklist.
- Agent, depth 1: checks completeness against the checklist for that customer type and risk level.
- Agent, depth 2: drafts requests for missing items to the customer or their adviser. A person sends them until the request types are certified, then the agent sends routine ones at depth 3.
- Agent, depth 1: cross-checks consistency: the name on the identity document against the application, the address on the proof of address, the directors on the company registry extract against the application, dates of birth across documents.
- Agent, depth 3: submits screening requests to the sanctions, politically exposed person and adverse media tools, for every individual the policy names.
- Agent, depth 1: reads screening results and summarises any possible matches with the details that support or weaken each.
- Agent, depth 2: drafts the file summary and a proposed risk rating, citing the factors from the policy.
- Agent, depth 3: stores the file in the document store with the naming and access rules for onboarding records.
- Person: decides on screening matches, approves enhanced due diligence cases, and accepts or declines the customer.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read application | Identifies type and checklist | 1 | Nothing |
| Completeness | Checks against checklist | 1 | Nothing |
| Missing items | Drafts, later sends routine requests | 2, then 3 | Unusual requests |
| Consistency | Cross-checks fields | 1 | Resolving conflicts |
| Screening | Submits requests | 3 | Nothing |
| Screening results | Summarises possible matches | 1 | Match decisions |
| Summary and rating | Drafts | 2 | Agreeing the rating |
| Store file | Files with access rules | 3 | Nothing |
| Accept | Nothing | none | The decision |
What does the approver need from the file?
A good file summary saves the approver from reopening every document. It should state, at the top: who the customer is, what they want, the risk rating proposed and why, what was checked, and anything unresolved. Below that, each document with what it was used to verify and its provenance.
Provenance matters here more than almost anywhere. An identity document uploaded by the customer is declared evidence until verified. A company registry extract pulled directly from the registry is stronger. A screening result from your screening tool is a fact about what the tool returned, not a fact about the person. The summary should say which is which, so the approver knows what has been verified and what has only been provided.
Where does it usually go wrong?
Documents are accepted because they look right. An agent that reads a utility bill and finds the right name and address has not verified anything. It has extracted. Verification needs an independent check, and the summary must not call extracted data "verified".
Exceptions are forced through the normal path. A trust with an unusual structure, a customer with no fixed address, a company owned through several layers abroad: these do not fit the checklist. The agent should recognise them and stop, handing over to the process in handling onboarding exceptions with an AI agent. The general rule for work an agent cannot process is in how to handle the exceptions an AI agent cannot process.
Screening matches are dismissed by the agent. "Different date of birth, so not a match" sounds safe, until the date on the list is wrong. The agent summarises; a person dismisses.
Files end up in the wrong place. Onboarding files hold identity documents and sensitive financial information. If the agent saves them in a general shared folder, they are exposed. Apply the rules in letting an AI agent save files to shared drives, and keep onboarding files in folders with onboarding access only.
It is treated as automation, not judgement. Teams who have used robotic process automation for onboarding expect the agent to follow the same fixed script. The agent can handle variety that a script cannot, which is useful, but that is also why its bounds must be explicit: it will try to handle cases a script would have rejected.
Which controls apply, and what evidence do they leave?
A checklist per customer type. Evidence: the checklist version used for each file.
Consistency checks recorded field by field. Evidence: each comparison and its result.
Screening submitted for every named individual. Evidence: the request and result for each, with time.
Approval by a named person. Evidence: the approver, their decision, and the summary they saw.
The minimum chain on every action. Evidence: each verdict and its deciding bound, including any request held for a person.
What should you measure?
- Files returned by approvers for missing or wrong information.
- Time from complete application to decision.
- Customer contacts chasing their application.
- Consistency issues found later, in periodic reviews or audits.
- Exceptions correctly identified versus forced through.
Write all of this down as the process documentation, following how to document an AI agent's process, and widen depth only through train, shadow, certify, widen.
Questions people ask
Can the agent approve low-risk customers on its own?
Some firms allow automated acceptance for the lowest-risk products, under their own policy. If you do, certify that capability separately, keep a sample review, and make sure the policy permits it.
What if the customer's documents are in another language?
The agent can translate for its own checking, and should record that it did. Where policy requires a certified translation, it requests one.
How long should onboarding files be kept?
As long as your anti-money laundering and record-keeping rules require, usually measured from the end of the relationship. The agent applies the retention class; it does not set it.