The cohort from launch year is now due
Your first customers signed up two years ago. Their onboarding was checked properly at the time. Since then some have moved house, changed name, let an identity document expire, or changed how they use the account. Your own policy says certain customers should be looked at again on a schedule, and some when something about them changes.
Nobody is quite sure who is due. There is a query an engineer wrote once, and a spreadsheet the compliance lead updates when they have a spare afternoon. Requests to customers go out as individual emails from the ops inbox. Replies come back as attachments in the same inbox and wait there.
Why the later checks get neglected
Onboarding is on the growth path, so it gets product and engineering time. Periodic reviews are not, so they get a spreadsheet.
- The date a customer is next due is not stored anywhere, so it has to be worked out.
- Triggers for an earlier review, such as a change of address or a document expiry, are not captured as events.
- Customer requests are written by hand and tracked in an inbox.
- Replies are not attached to the customer's record.
- Nobody sees the backlog building until it is large.
What intervals apply and what triggers an early review are matters for your own policy, set by your compliance lead and advisers. The problem we deal with is doing what that policy says, on time, at scale.
The cost of a growing backlog
A backlog of overdue reviews is hard to explain to a partner and harder to clear quickly, because it needs the same people who handle onboarding. Customers asked for documents months late are confused and sometimes annoyed. Records that were accurate at sign-up drift out of date, which affects everything from payments to support.
A schedule that runs itself, and a queue for people
What we build turns your review policy into dates, requests and a queue.
- Each customer gets a stored next review date, calculated from the rules your policy sets, such as risk level or product.
- Events that should bring a review forward, such as a document expiry date or a change of details, update that date automatically.
- A set period before the date, the customer gets an in-app and email request for whatever your policy needs, with a secure upload or a re-run of the relevant check through your existing provider.
- Reminders follow on a schedule you choose, and the ops queue shows who has not responded.
- What comes back lands on the customer's review case, with any provider results attached.
- An analyst reviews and records the outcome, and the next date is set.
- A dashboard shows reviews due, in progress, overdue and completed, by month.
| Review stage | What happens | Who |
|---|---|---|
| Coming due | Customer request sent automatically | System |
| Waiting on customer | Reminders on your schedule | System, ops sees list |
| Customer responded | Checks re-run, case updated | System |
| Ready for review | Analyst reviews and records outcome | Ops analyst |
| No response after final reminder | Case moves to the next step your policy sets | Ops lead |
What the review work looks like after
The compliance lead stops maintaining a spreadsheet of due dates. Requests go out on time. Analysts see a queue of reviews ready for a decision, with the material already attached, rather than chasing emails. The backlog, if there is one, becomes a number on a dashboard that can be planned against.
Is this your periodic review setup?
- Nobody can list which customers are due a review this month.
- Document expiry dates are stored but not acted on.
- Customer requests go out as individual emails.
- Replies sit in the ops inbox.
- A backlog exists and nobody knows its exact size.