KYC · Periodic review
MixedRetail and business bankingClear the KYC periodic review backlog without adding analysts
Periodic reviews pile up because every file starts from scratch, even when nothing has changed. Here is a setup that refreshes the data, drafts the file and routes it by risk, so analysts spend their time on the reviews that need judgement.
Valnora & Elric team12 min read
- Team
- KYC operations in retail and business banking
- Manual steps today
- 6
- Build steps
- 9
- Review points
- 5
The problem
Periodic review is the part of KYC that never ends. FATF Recommendation 10 includes ongoing due diligence on the business relationship, and most banks meet it with a risk-based cycle: higher-risk customers are reviewed more often, lower-risk ones less often. Every review falls due on schedule, whether or not the team has capacity.
The backlog builds because each file starts from zero. An analyst rebuilds the customer picture across four or five systems, re-runs screening, and compares activity with what the customer said at onboarding. For most customers, nothing material has changed, but that takes the same two or three hours to establish. Meanwhile document requests sit in personal inboxes and the overdue count is reported once a month.
For example, a bank with 1,200 reviews falling due each month at 2.5 analyst hours each, and 1,800 reviews already overdue, needs extra capacity just to stand still.
How kyc operations in retail and business banking works today
Today, done by hand · KYC operations in retail and business banking
- 01A monthly report lists customers whose review date has passed or is near.
- 02An analyst opens the customer in four or five systems to rebuild the picture from scratch.
- 03Screening is re-run by hand and registry records are checked for business customers.
- 04The analyst compares current activity with what the customer said at onboarding.
- 05Missing documents are requested by email from a personal mailbox and tracked in a spreadsheet.
- 06The analyst writes up the review, sets the next review date and closes the case.
Where it breaks
- Every review starts from zero, even the majority where nothing material has changed.
- Low-risk refreshes take the same queue as high-risk files that need real judgement.
- Customer replies land in personal inboxes, so reviews stall when someone is away.
- The overdue count is known once a month, after it has already grown.
What the change could be worth
A retail and business bank with 1,200 periodic KYC reviews falling due each month and 1,800 already overdue.
| Assumption | Value |
|---|---|
| Reviews falling due per month | 1,200 reviews / month |
| Analyst hours per review today | 2.5 h |
| Analyst hours per review with a drafted file | 1.75 h |
| Loaded cost of an analyst hour | 45 GBP |
| Reviews already overdue | 1,800 reviews |
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
In this illustrative scenario, a drafted file cuts the work from 2.5 to 1.75 hours per review, about 1.4x faster. That frees around 900 analyst hours a month, worth roughly £486k a year, and is enough to clear the 1,800 overdue reviews in about 15 weeks with the same team.
The outcome you want
Every review arrives with fresh data, a summary of what changed and a track set by a written rule. Analysts spend their time on files that need judgement, document requests go out from a shared inbox after approval, and managers see the backlog daily. People still decide every review.
Acceptance criteria
- Every review due within 60 days has a refreshed data set and a what-changed summary.
- Every review is routed to a track by a written rule, not by who picks it up.
- No review closes without an analyst’s recorded decision.
- No customer email is sent without a named approver’s approval of the exact message.
- Any overdue high-risk review raises a critical alert within the day.
The solution end to end
Data and tables. The periodic reviews table holds one row per due review, with what changed, what is missing, the review track and the decision. A small review cycle table holds the months between reviews per risk rating from your policy.
Workflow 1, refresh and route. Built in the workflow builder, it runs daily on a Schedule block and finds customers due within 60 days or with a trigger event. API blocks re-screen the customer and check the company registry, and a warehouse block pulls an activity summary. A Guardrails block with PII Detection masks what the model does not need, then an Agent block compares the profile on file with the fresh data and writes what changed. A Table block upserts the row, and every run is traced in Logs.
Rules, metrics and monitors. A Classification rule sets the review track: Enhanced for high risk or a material change, Refresh only for lower risk with no change, Standard otherwise. A Flag rule marks overdue high-risk reviews. An overdue metric feeds the dashboard and a Metric threshold monitor, and a Rule match monitor raises a critical alert on any overdue high-risk review. Alerts show in the app and by email.
Workflow 2, the review file. It picks up reviews ready for an analyst, searches your procedures in the Knowledge Base, and drafts each section of the file. A Human block pauses the run until the analyst submits a decision: confirm and close, request information, escalate to enhanced due diligence or refer for exit review. A Table block records the decision and a Microsoft Teams block tells the EDD team about escalations.
The Relay. A Relay named KYC refresh assistant watches the reviews table for rows marked Request info and drafts a plain-language email to the customer. It runs at the Assist level from a workspace inbox: every email waits for a team lead to Approve & send the exact message, and the approval expires if nobody decides. It also watches the shared Outlook mailbox for replies and opens a task for the analyst, and sends the KYC manager a backlog briefing every Monday. It reads tables but cannot change them.
The dashboard and Chat. One dashboard shows overdue, due-soon and completed reviews by segment and risk rating, with row-level security so each team lead sees their own segment. Chat can query the reviews table for ad-hoc questions.
From review due date to an analyst decision
Data · Customer and screening sources
- 01Core banking and CRMCustomer profile, risk rating, last review date and expected activity.
- 02Screening and registriesSanctions, PEP and adverse media re-screening; company registry checks for business customers.
- 03Periodic reviews tableOne row per due review: what changed, review track, status and decision.
Workflow 1 · Refresh and route
- 04Daily scheduleFinds customers due within 60 days under your risk-based cycle, or with a trigger event.
- 05Summarise what changedAn Agent block compares the profile on file with fresh screening, registry and activity data.
- 06Review track ruleA Classification rule routes each review to Refresh only, Standard or Enhanced.
Workflow 2 · Review file
- 07ProceduresA Knowledge block finds the review requirements for the customer type and risk rating.
- 08Draft the review fileAn Agent block pre-fills every section and lists what is missing.
- 09Analyst decisionA Human block pauses until the analyst submits a decision in the Resume Form.
Relay · KYC refresh assistant
- 10Watches table and inboxPicks up reviews marked Request info and customer replies in the shared KYC mailbox.
- 11Email after approvalDrafts each customer request; a team lead approves the exact email before it is sent.
Dashboard · Backlog
- 12Backlog dashboardOverdue, due soon and completed reviews by risk rating and segment.
- 13Overdue monitorsAlert when any high-risk review is overdue, or the overdue count rises above your limit.
Build it
Start with the tables and Workflow 1, check the summaries against real files, then add routing, drafting and the Relay.
Configure it step by step
- 01
Create the reviews and cycle tables
Tables → New table
- Periodic reviews: Customer ID, Segment, Risk rating, Due date (Date), What changed, Missing, Review track (Select), Status (Select), Draft file, Decision, Analyst, Next review date.
- Review cycle: Risk rating and Months between reviews, filled from your policy.
- 02
Upload procedures to a Knowledge Base
Knowledge → New knowledge base
- Name: KYC procedures. Upload Documents with review procedures and document lists per customer type, then Create.
- For procedures in SharePoint or Confluence, use New connector with Sync Frequency Daily.
- 03
Build Workflow 1, refresh and route
Workflow builder · Schedule, API, Agent, Table blocks
- Schedule block: Run frequency Daily. Table block Query Rows for customers due within 60 days.
- API blocks re-screen against your screening provider and check the company registry; a Snowflake or BigQuery block pulls the activity summary.
- Guardrails block with PII Detection before the Agent block, which writes What changed and Missing.
- Table block Upsert Row on Periodic reviews. Deploy.
- 04
Add the routing rules
Rules → New rule
- Classification (labels): Review track, with Enhanced for high risk or a material change, Refresh only for low and medium risk with no change, and Standard as the Fallback label.
- Flag (true / false): High-risk overdue, when Risk rating is High and Due date is past. Create rule.
- 05
Define the metrics and monitors
Metrics → New metric, then Monitors → New monitor
- Metric Overdue reviews: Aggregate, Count (rows) where Status is open and Due date is past.
- Rule match monitor on High-risk overdue, threshold 1 row, Check Daily, Severity Critical.
- Metric threshold monitor on Overdue reviews: Fire when it rises above your agreed limit, Severity Warning.
- 06
Build Workflow 2, the review file
Workflow builder · Knowledge, Agent, Human, Table blocks
- Schedule every hour; Table block Query Rows for Status Ready for analyst; a Loop over the rows.
- Knowledge block searches KYC procedures; Agent block drafts the file section by section.
- Human block: Display Data shows the draft, Resume Form has a Decision field (Confirm and close / Request info / Escalate to enhanced due diligence / Refer for exit review).
- Table block Update Row by ID with the decision; a Microsoft Teams block tells the EDD team about escalations. Deploy.
- 07
Build the dashboard
Dashboards → New dashboard
- Build tab: KPI cards, a bar chart of reviews falling due vs completed by month, and a Table panel of the oldest overdue reviews.
- Filters tab: Choice list for Segment and Risk rating. Settings → Row security so team leads see their own segment.
- 08
Set up the Relay
Relays → New Relay
- Specialization: Custom. Name: KYC refresh assistant. Create draft.
- Instructions: draft plain-language information requests, never mention screening results. Tools in conversations: Query tables, Search knowledge bases.
- Email: Workspace inbox. Autonomy: Assist. Email recipients: Anyone. Approvers: KYC team leads.
- 09
Give the Relay its responsibilities
Relay → Responsibilities → New responsibility
- Watch a connected source: Workspace table, Periodic reviews; What needs your attention: reviews whose Status changed to Request info.
- Watch a connected source: Outlook; What needs your attention: customer replies with documents for a KYC review. Follow-up: Message me and open a task.
- On a schedule, Mondays at 8:00: backlog briefing for the KYC manager. Publish.
What it produces
A business customer due for review becomes a summary that spots a new shareholder and a jump in overseas payments, routes the file to Enhanced, and drafts the request for missing documents.
What the solution produces
Customer record at review date (illustrative)
Record- Customer
- C-20817 · limited company, wholesale food distribution
- Risk rating
- High · last reviewed 13 months ago
- Expected activity
- Domestic supplier payments, about GBP 400k a month
- Documents on file
- Director ID, ownership chart dated two years ago
What changed summary (illustrative)
Record- Ownership
- Registry shows a new 30% shareholder since the last review.
- Activity
- Monthly outflows now about GBP 950k, including new payments to two overseas suppliers.
- Screening
- No sanctions or PEP matches. One adverse media article, judged unrelated by name and date of birth.
- Review track
- Enhanced · high risk with a material ownership change
- Missing
- ID and source of funds for the new shareholder; explanation of overseas payments
Drafted customer information request (illustrative)
MessageSubject: Keeping your business account details up to date
As part of our regular review, please send ID for your new shareholder and a short note on the new overseas suppliers you pay.
You can reply to this email with the documents attached.
Where people stay in charge
Where people stay in charge
- Gate 1Compliance owns the review cycle table and the routing rule; both change by a reviewed edit.
- Gate 2An analyst decides every review in the Resume Form, including refresh-only ones.
- Gate 3A team lead approves each customer email as written; any edit needs a new approval.
- Gate 4Escalations to enhanced due diligence and exit referrals go to the teams that own them.
- Gate 5The KYC manager reviews the weekly briefing and the rate of overturned routings.
The dashboard
KYC periodic reviews · backlog
Oldest overdue reviews
| Customer | Segment | Risk | Days overdue | Track |
|---|---|---|---|---|
| C-20817 | Business | High | 41 | Enhanced |
| C-11564 | Retail | Medium | 37 | Standard |
| C-30422 | Business | Medium | 29 | Refresh only |
The dashboard is an illustrative example. The comparison with the previous period shows whether completions are outpacing new due dates, which is the only number that tells you the backlog is shrinking.
Controls and audit
Workflow runs record each block’s inputs, outputs and errors in Logs, so you can show which screening and registry data a review relied on. Relay proposals, approvals and declines are written to the audit log, which admins export from Activity audit. Analysts’ decisions sit in the reviews table with their names against them.
Row-level access narrows what each team sees in tables, dashboards and exports, and roles and permission groups limit who can edit rules and workflows. People sign in through SSO and are provisioned with SCIM. If customer data must stay in your environment, run Agent Serve self-hosted. Zero data retention is available with supported model providers through your own keys or self-hosted models. Some provider features keep data on the provider's side by design, such as Gemini Deep Research, so they are outside zero data retention.
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
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.
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.
More on how Agent Serve handles access, data and audit on the security page.
Roll it out
Pilot one segment with a predictable profile, such as medium-risk retail customers, before taking on business customers and high-risk files. Put overdue reviews, completions against due dates, hours per review and the refresh-only share on the dashboard from week one. The timings are a plan, not a promise.
Pilot, measure, expand
- Weeks 1–3
Pilot one segment
- Build the tables, Workflow 1 and the routing rule for one segment, such as retail medium risk.
- Compare what-changed summaries with what analysts found on the same files.
Done when: Summaries match analyst findings on a reviewed sample, with gaps explained.
- Weeks 4–6
Draft files and dashboard
- Deploy Workflow 2 for the pilot segment and turn on the monitors.
- Track hours per review and refresh-only share on the dashboard.
Done when: Analysts work from the drafts for most pilot reviews.
- Weeks 7–12
Outreach and expansion
- Publish the Relay for customer requests in the pilot segment.
- Add business customers and high-risk reviews.
Done when: Completed reviews outpace reviews falling due for four weeks running.
| Risk | How to handle it |
|---|---|
| The routing rule sends a review that needs judgement to Refresh only. | Analysts still decide every review; track overturned routings weekly and tighten the rule. |
| A customer email reveals a screening result. | Relay instructions forbid it, and every email is approved as written before it is sent. |
| Personal data reaches a model unnecessarily. | Use a Guardrails block with PII Detection and send only the fields the summary needs. |
| Source data is stale or incomplete. | Show the data date in the summary and flag missing sources rather than guessing. |
Timings are an illustrative plan, not a commitment; your pilot sets the pace.
Before you start
What you need
- Read access to customer profiles, risk ratings and last review dates
- API access to your screening provider and, for business customers, a company registry
- A transaction summary per customer from your warehouse, such as Snowflake or BigQuery
- Your periodic review procedures and review cycle per risk rating, uploaded to a Knowledge Base
- A shared KYC mailbox in Gmail or Outlook for customer replies
- Named analysts who decide reviews and team leads who approve customer emails
- An agreed overdue limit for the backlog monitor
Questions teams ask
Questions teams ask
Does the setup decide whether a customer passes review?
No. Workflow 2 pauses at a Human block for every review, including refresh-only ones, and the analyst submits the decision in the Resume Form. Rules route the work; they do not close it.
Who sets the review cycle for each risk rating?
Your policy does. Put the cycle per risk rating in a table and the daily workflow reads it, so a policy change is a table edit. Agent Serve does not ship review cycles.
Can the Relay email customers?
It drafts the email; it never sends on its own. Every send waits for a named approver to Approve & send the exact message, and the approval expires if nobody decides. Its instructions forbid mentioning screening results, to avoid tipping off.
What happens when a customer replies?
The Relay watches the shared KYC mailbox, matches the reply to the open review and opens a task for the analyst. It reads the mailbox but never changes it, and it cannot update the reviews table; the analyst records receipt.
How do trigger events fit in?
Workflow 1 also picks up customers with a trigger event, such as a screening hit or activity well above the expected level, even when no review is due. A Flag rule marks them so they jump the queue.
Can managers ask ad-hoc questions about the backlog?
Yes. Chat can query workspace tables, so a manager can ask how many high-risk business reviews are overdue in one region and get the rows back.
Related: KYC onboarding review and AML alert triage. Request access