Straight-through where it is safe
Clean cases clear automatically against your rules. Reviewer attention goes to the cases that genuinely need judgement rather than to the ones that pass on sight.
KYC & Onboarding
RunThe user who waits two days funds an account somewhere else.
Trained reviewers on your verification and document queues, worked to a defined SLA, with every decision recorded against the policy version it was made under.
Typical stack
- Persona
- Sumsub
- Onfido
- Claude
- PostgreSQL
- Zendesk
- Slack
Written for: A fintech or neobank operations lead whose onboarding queue grows fastest in the weeks acquisition is working.
Who it is for
Is this built for a business like mine?Built for businesses where onboarding is the first thing a customer experiences.
Verification is the one queue where the cost of being slow and the cost of being wrong both fall on you at once. These are the businesses where that tension is sharpest.
What we see
A campaign lands, sign-ups multiply, and the verification queue that took an hour now takes two days — so the users acquisition just paid for churn before funding an account.
What we build
A reviewer pool that flexes with volume, working your policy to an SLA you set, with straight-through cases cleared automatically and only genuine exceptions reaching a person.
The detail that matters
Capacity is contracted against your volume curve. Onboarding is spiky by nature, and a fixed team is either idle or underwater.
What we see
Application packs arrive as unstructured documents and a qualified person reads every one before anything can move.
What we build
Document review with extraction handling the bulk and reviewers handling anything below the confidence threshold you set, filed against the right client record.
The detail that matters
The threshold is yours, because it is a risk decision rather than a technical one.
What we see
Tenant screening documents are collected and checked by hand, one applicant at a time, and the criteria live in one person’s head.
What we build
Document collection, verification and screening against written criteria, applied identically to every applicant.
The detail that matters
Identical application of written criteria is also a fairness property, not just an efficiency one.
What we see
Enrolment season brings applicant documents faster than admissions can verify them, and eligibility rules changed this year.
What we build
Applicant document verification against current, versioned policy, with seasonal capacity that scales back down afterwards.
The detail that matters
Policy is versioned, so a decision made in March can be explained in September.
And who it is not for
We run the queue; we do not own your policy. If you need someone to decide what your risk appetite should be or to sign off a compliance framework, that is a consultancy engagement and we are not it.
The problem
Do they understand what is actually going wrong?Fast and defensible are treated as a trade-off. They are not.
Under pressure, verification teams optimise for whichever one they are measured on. Measured on throughput, the queue clears and the decisions thin out. Measured on caution, everything escalates and the SLA collapses. Both failures come from the same missing thing: a written standard for what a sufficient review looks like, applied the same way by everyone.
The backlog grows fastest in the weeks acquisition is working best.
Two reviewers reach different decisions on the same case, and neither is wrong under the policy as written.
Escalation happens on instinct, so the same edge case is escalated by one reviewer and cleared by another.
Reconstructing why an account was approved means asking whoever remembers.
What we build
What exactly would I be buying?A written standard, applied by a trained pool, recorded as it happens.
The work is not hard to do well once. It is hard to do identically, at volume, on the worst day of the quarter, by people who joined last month. That is an operations problem, and it is the one we solve.
One standard, versioned
What counts as sufficient evidence is written down and versioned. A decision made in March can be explained in September against the policy that was live in March.
Escalation by rule
What goes to enhanced review, and what goes to your compliance team, is a written condition — not a reviewer’s instinct on the day.
The audit trail is the output
Reviewer, timestamp, evidence seen, policy version and outcome recorded on every case, in your system. Not a report generated afterwards.
How it works
How does this actually function?Where a case stops, and who it stops for.
Three exits rather than two. Most queues have pass and fail, which forces every ambiguous case into one of them; the third exit is what keeps both the SLA and the standard intact.
Submitted
Auto-checks
Reviewer
EDD or → your compliance teamDecision
Recorded
Automated checks run first, so reviewers spend their attention on cases that need a person rather than on cases that pass on sight.
Enhanced review is a defined path with its own SLA, not an indefinite hold that quietly ages.
Anything touching your risk appetite goes to your compliance function. We work the queue; the policy stays yours.
What changes
What is different afterwards?What is different afterwards.
The SLA survives the spike
Capacity is contracted against your volume curve rather than a headcount, so the queue that grows with a campaign is absorbed instead of becoming a backlog.
Time to decision at the 90th percentile, held through volume peaks.
Decisions stop varying by reviewer
One written standard and sampled QA mean the same case gets the same outcome regardless of who opened it.
QA agreement rate between reviewers, sampled and reported.
The trail already exists
Evidence, policy version and reasoning are captured at the point of decision, so a regulator request is a query rather than an investigation.
Cases reconstructable from the record without asking a person.
How we deliver
How does this start, and what do I get at each step?Six stages, and every one has an exit.
You can stop after any stage with something useful in hand. That is the point of naming the artefacts rather than the activities.
- 01
Queue audit
Real volume, real decision times, real escalation rates, and where the current standard is ambiguous. The ambiguity is usually the finding.
- Volume and decision-time baseline
- Case type taxonomy from real submissions
- Points where the written policy does not decide the case
- 02
Standard and thresholds
What sufficient evidence looks like per case type, what clears automatically, and what escalates. Agreed with your compliance function, not by us.
- Review standard, versioned
- Auto-clear and escalation conditions
- The decisions we will never make without you
- 03
Integration
Your verification provider, your case system, your record store. We work in your tools so the audit trail lives where your auditor already looks.
- Provider and case system access
- Write-back configured
- Data handling agreed to your residency requirements
- 04
Reviewer training
Your policy, your case types, your edge cases — assessed before anyone touches a live case.
- Trained reviewer pool
- Assessment results per reviewer
- QA rubric
- 05
Parallel run
Our decisions run alongside yours and the two are compared. It is the only honest way to establish that the standard transferred.
- Agreement rate against your current team
- Disagreements analysed by cause
- Standard corrected where it was ambiguous
- 06
Run
Full volume with daily SLA reporting, sampled QA, and a standing review where the standard actually changes.
- Daily SLA report
- Weekly QA agreement rate
- Monthly standard review
Who runs the desk
How does this start, and what do I get at each step?Every desk ships with a lead and a QA function.
A pool of agents with no accountable owner is how outsourced quality degrades — slowly, invisibly, and then all at once. Four roles exist on every account, and the smallest engagement gets all four.
- 01
Agents
Trained on your product, your tone and your escalation boundaries, and assessed before they touch live work. Named and consistent on dedicated plans.
- 02
Team Lead
Accountable for the queue rather than working in it — coverage, SLA, escalations and the shift handover. One person you can name when something goes wrong.
- 03
QA
Samples completed work against a written rubric, independently of the lead. Disagreements between agents are treated as a defect in the knowledge base, not in the agent.
- 04
Account lead
Runs the weekly report and the standing review where the knowledge base actually changes. The person who tells you the number went the wrong way.
QA sampling rate and the review cadence are agreed during onboarding and reported weekly against target — including the weeks it was missed.
Questions
But what about the thing that worries me?The questions people actually ask.
Do you make the compliance decisions, or do we?
We apply the standard you set and escalate anything that touches your risk appetite to your compliance function. We run the queue; you own the policy. That line is written into the escalation conditions during onboarding, and it is not a soft one.
How fast can a case be decided?
It depends on your case mix and your standard, so we baseline both during the queue audit rather than quoting a number. What we commit to is an SLA agreed against that baseline and reported daily — including the cases that missed it.
What about data residency?
It is a constraint we design to, not around. Where case data cannot leave a jurisdiction, reviewers and processing sit inside it. That shapes which reviewers can be assigned and how the tooling is set up, so it is established in the queue audit rather than discovered later.
How do you keep two reviewers from reaching different decisions?
One versioned standard as the single source, and sampled QA measuring agreement between reviewers. Where two defensible readings exist, the standard is ambiguous and gets fixed — we treat that as the defect rather than blaming the reviewer.
Can you work in our existing verification provider?
Yes — Persona, Sumsub, Onfido, Veriff or your own tooling. We work in your system so the record lives where your auditor already looks, rather than in a portal you would lose access to.
The other half
The documents have to be read before they can be judged.
A large share of this queue is extraction before it is ever a decision — pulling fields off a passport, a utility bill, a company registration in a language nobody on the team reads. The engineering that does that reliably, with a confidence score on every field, is something we build as a product. Running the review desk is what tells us where it actually breaks.
AI DevelopmentStart
What is the next step?Tell us the volume, we will tell you the shape.
Send us a week of real numbers — calls, chats, tickets, documents — and we will come back with a coverage model and what it would cost.
Related desks
- ComplianceTransaction & Risk MonitoringStaffed alert review, account investigations and back-office risk operations — worked to an SLA, with the reasoning recorded on every disposition.
- TransactionData Entry & ProcessingDocument processing and data operations where extraction handles the volume and trained reviewers handle everything below the confidence threshold.
- ConversationEmail SupportShared inbox and ticket handling with drafting automation and trained agents, worked to a first-response target rather than to inbox zero.