How to design a manual review queue for marketplace fraud and verification: what to route, how to prioritise, what reviewers need and how to keep it small.
Every marketplace with automated checks ends up with a review queue. Sooner or later, a check returns something that is neither a clear pass nor a clear fail, and a person has to look.
The queue starts small. Then a new rule goes live, or signups jump after a campaign, and it grows. Good sellers wait days to be approved. Reviewers start approving on autopilot to clear the pile. At that point the queue is costing you sellers and not catching much fraud.
This post covers how to design a review queue that stays manageable.
A review queue exists for cases where a person can make a better decision than a rule. That sounds obvious, but many queues are full of cases that do not meet that test:
Before tuning anything else, look at your last few hundred review decisions. If reviewers approve almost everything from one rule, that rule is sending too much. If they reject almost everything from another, it could probably block on its own.
Most checks should end in one of three outcomes:
TrustVerify's fraud score works this way. Each call to the fraud score API returns an action of approve, review or block, along with a 0-100 score (higher is safer), a risk tier and the factors behind it. You decide what to do with each action in your own system.
One detail matters for queue design. When a score is produced from limited signals, TrustVerify does not return approve. The case goes to review instead. That is deliberate: it avoids a confident pass based on thin evidence. But if a lot of your traffic falls into that category, you will see it in your queue volume, and the fix is to send richer signals rather than to loosen thresholds.
Business checks follow the same idea. In the TrustVerify dashboard, a full KYB check that is registry-verified and low risk is approved automatically, and everything else is routed to manual review.
A case that arrives in the queue with "risk score 41" tells the reviewer almost nothing. A case that arrives with "new device, email domain registered last week, shipping address differs from billing" tells them where to look.
Make sure every queued case carries:
If reviewers keep opening other tools to find context, put that context in the case.
First in, first out is a fair default and a poor strategy. Not every case costs the same to leave waiting. Rough priority order for most marketplaces:
Add a visible age to every case, and set a target time for each priority level.
A large share of many queues is cases waiting on the user: an ID check started and abandoned, a request for documents that was never answered. Those cases cannot be decided by a reviewer, and they inflate the queue.
Close them automatically after a set period, with a clear status. TrustVerify does this for KYC: verifications left pending for seven days are closed as incomplete, and each batch of closures writes an audit event. An incomplete verification is not a rejection. The user can start again.
Each review decision should record who decided, what they decided, when, and why. In TrustVerify, reviewer decisions on KYC submissions are recorded as approved or rejected, with optional notes, and audit events are append-only. That record matters when a seller appeals, when a partner asks how a decision was made, or when you want to tune your rules.
Write notes as if someone else will read them in six months. "Looks fine" helps nobody. "ID matches, address confirmed by utility bill, device seen on two other good accounts in same household" does.
The queue is your best source of information about how well your rules work. Once a month:
That loop is how a queue stays small as volume grows.
Our posts cover the signals that feed many review decisions: device fingerprinting and bot signals and marketplace account takeover. For routing decisions automatically as they arrive, see KYC webhooks and decision handling. If you are new to scores, what is a trust score is a good primer.
Track a few numbers every week: cases in, cases decided, median age at decision and the oldest open case. If cases in keeps beating cases decided, the queue will grow no matter how hard reviewers work. That is a routing problem, not a staffing problem.
If you only remember a few points from this post, make them these:
None of these points requires a large team or a long project. Most can be put in place in a few weeks, and each one makes the next decision easier to explain.
See how TrustVerify routes cases to review and records decisions. Explore review queues.
KYC, KYB, AML screening and fraud prevention in one place, with published pricing.
Fraud Prevention
Device Fingerprinting and Bot Signals on UK Marketplaces
What device fingerprinting and bot signals can tell a UK marketplace about fake sellers and scripted signups, and how to use them without overreacting.
Fraud Prevention
Email and Phone Risk Signals at Signup
What email and phone checks reveal at signup: disposable domains, missing mail servers, VoIP numbers and how to act without blocking real users.
Fraud Prevention
Account Takeover on Marketplaces: How It Happens and What to Check
How account takeover hits UK marketplaces, from credential stuffing to payout changes, and the signals and controls that catch it early.
