KYC · Onboarding review
WorkflowRetail and business bankingA KYC onboarding review workflow in six steps
Onboarding files arrive incomplete, and reviewers spend their time finding out what is missing. This playbook builds one workflow that checks the file first and routes it by risk to the right person.
Valnora & Elric team5 min read
- Format
- Playbook
- Steps
- 6
- Solution
- Workflow
- Parts used
- 6
KYC reviewers are hired to judge risk. Much of their day goes on something else: opening each document, checking that the name on the passport matches the application, finding the page of the registry extract that lists shareholders, and writing to the applicant for the item that was not attached.
This playbook builds one workflow in Agent Serve that does that preparation for every new onboarding file. It does not approve or decline anyone. It hands the reviewer a checked file, a short note and a clear list of open points, and records what the reviewer decided.
Define what a complete file looks like
Before building anything, write down what a complete file contains for each customer type. A personal current account needs proof of identity and address. A small business account adds registry extracts, a list of directors and beneficial owners, and an explanation of expected activity.
This list becomes the first set of Rules in the workflow, so keep it plain: "a proof of address dated within your policy’s window is present", "every director has a verified ID". Your KYC procedures go into the Knowledge Base so the workflow can cite them. FATF Recommendation 10 sets out the core customer due diligence measures most regimes build on: identifying the customer, identifying beneficial owners, and understanding the purpose of the relationship. Your own procedures will be more specific, and they are what the workflow should follow.
Extract the documents into fields
The workflow starts from a webhook each time your onboarding system receives an application. A File block collects the uploaded documents, and an OCR block (AWS Textract or Reducto) turns each one into text and fields: names, dates of birth, addresses, company numbers, shareholders and percentages.
Run a Guardrails block with PII detection on anything that will be posted outside the review itself, such as a notice in a team channel. The review note needs personal data; a channel message usually does not.
Check the file against your policy
Two kinds of check run next, and it helps to keep them separate.
- Deterministic checks are rules: is each required document present, does the name match across documents, is the address proof recent enough, do ownership percentages add up.
- Judgement checks go to an Agent block that reads the extracted fields alongside the matching procedure from the Knowledge Base. It answers narrower questions: does the stated business activity fit the expected transactions, does the ownership chart agree with the registry extract, is anything unusual worth a reviewer’s attention.
Sanctions and PEP screening stays with your existing provider. An API block fetches its results so the reviewer sees them in the same note. The workflow reports matches; it never discounts one.
Route the file by risk, not by queue order
A Router block reads the risk factors your policy names (customer type, geography, products, screening results) and sends the file one of three ways:
- Incomplete files produce a draft request for the missing items, like the second example below, for the onboarding officer to review and send.
- Standard-risk files go to a KYC reviewer.
- Higher-risk files go to the enhanced due diligence team.
In each case the Human block pauses the run until a named reviewer decides. The workflow never moves a file to approved by itself.
Write the review note and keep the record
What the solution produces
KYC review note for a business account (illustrative)
Record- Applicant
- Private limited company · wholesale food distribution · 2 directors
- Identity
- Both directors verified. Passport and driving licence match the application details.
- Beneficial ownership
- Registry extract lists one shareholder with 60%. The ownership chart lists two. Mismatch needs explaining.
- Screening
- No sanctions match. One PEP name match on a director, low similarity, needs a reviewer to discount.
- Expected activity
- Stated turnover is consistent with sector and size. Cash deposits declared as occasional.
- Missing items
- Signed ownership declaration for the second shareholder.
- Suggested route
- Standard review, with the ownership mismatch and PEP match listed as open points.
Draft request for missing items (illustrative)
MessageThank you for your application. To finish our checks we need one more document:
a signed beneficial ownership declaration for the second shareholder listed on your ownership chart.
You can upload it through the same link you used for your application.
The note follows the same structure every time: identity, ownership, screening, expected activity, missing items and suggested route. Every point refers to the document or procedure it came from.
When the reviewer decides, the decision, their name and any override reason are written to a KYC review table in Tables. Every run is traced in Logs, block by block, so an auditor can see which documents were read and what each check returned. For a recurring periodic review, the same workflow can be run again on a schedule against existing customers.
What the change could be worth
An onboarding team reviewing 1,200 new business account applications a month.
| Assumption | Value |
|---|---|
| Applications per month | 1,200 files / month |
| Reviewer minutes preparing a file today | 40 min |
| Reviewer minutes checking a prepared file | 15 min |
| Days until a missing item is requested today | 4 days |
| Days until it is requested with the workflow | 1 days |
- sooner applicants hear what is missing: Days until a missing item is requested today − Days until it is requested with the workflow
- reviewer hours freed a month: Applications per month × (Reviewer minutes preparing a file today − Reviewer minutes checking a prepared file) ÷ 60
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
Run it in parallel before you switch
Take a set of past files with known outcomes and run them through the workflow. Compare its notes and routes with what your reviewers actually decided, and look hardest at the cases where they differ. Then run it on live applications alongside the current process for a few weeks before reviewers start working from its notes.
Deploy each change to the workflow as a new version, so a change to a rule or a prompt is reviewed before it reaches live applications. Once onboarding is steady, the same customer context feeds AML alert triage later in the relationship.
Controls and governance
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
GDPR ready
Retention from one day to five years, deletion and access controls support GDPR obligations. Ready means the controls are in place, not a certification.
More on how Agent Serve handles access, data and audit on the security page.
One onboarding file, one workflow run
Workflow · KYC onboarding review
- 01New applicationA webhook from your onboarding system starts one run per application.
- 02Extract documentsOCR blocks read ID, proof of address, company registry extracts and ownership charts.
- 03Policy checksRules and an Agent block check the file against the KYC procedures in your Knowledge Base.
- 04Screening resultsAn API block fetches sanctions and PEP screening results from your existing provider.
- 05Route by riskA Router sends the file to standard review or enhanced due diligence; a Human block waits.
- 06Review recordThe note, checks, reviewer and decision are written to a KYC review table.