Designing a KYC review queue that scales

A KYC review queue is the back-office workflow where identity checks that a machine could not clear on its own are put in front of a human. Most applications should pass automatically; the queue exists for the ones that do not. Its whole design goal is to stay small — to hold genuine ambiguity and nothing else — because a queue that fills with cases a machine should have decided is not a control, it is a bottleneck that grows linearly with signups. Get the queue right and a back office scales with exceptions, not with volume.

That single property — small on purpose — drives every decision that follows. Start with the split that keeps it that way.

Straight-through is the goal, the queue is the exception

Straight-through processing (STP) means an application clears end to end with no human touch: documents read, identity matched, sanctions and PEP screening clean, liveness passed, decision recorded. This should be the common path, and the share of applications that take it — the STP rate — is the single number that tells you whether the queue will scale. If ninety-something percent clear automatically, the human queue holds a manageable trickle; if half of them fall out to review, you are hiring reviewers in step with growth. The queue is not where KYC happens. It is where automated KYC admits it is unsure. Push the STP rate up and every other number improves for free: fewer cases queued, shorter waits, fewer reviewers to hire. It is worth attacking directly — better document capture on the client, clearer instructions before a photo is taken, matching thresholds tuned so genuine customers are not bounced by an over-cautious rule — because every percentage point recovered there is a case that never becomes someone's afternoon.

What lands in the queue, and why

Cases fall out to review for specific, nameable reasons, and the reason is the most important attribute a case carries. A document photo is too blurry to read. The name on the ID does not match the name on the application. A sanctions or PEP screen returned a possible hit that needs a human to confirm or dismiss. An address cannot be verified against any source. A liveness check failed, or the same face or document already exists on another account. Each of these is a different kind of work needing a different kind of judgment — and lumping them into one undifferentiated pile is the first mistake a review queue makes. And the same reason can carry very different weight: a name mismatch might be an unremarkable married-name discrepancy or the first sign of a stolen identity, and the queue's job is to route it to someone who can tell the difference rather than force a snap verdict on a case that deserves a careful one.

One queue is not enough: segment by reason

A single queue forces every reviewer to be a generalist and every case to wait behind unrelated ones. Segmenting by reason fixes both. A sanctions possible-match queue is worked by people trained on screening and disposition; a document-quality queue is a fast visual check that a junior reviewer clears in seconds; a duplicate-account queue is a fraud investigation. Each segment gets its own routing, its own required skill, and its own service-level target, because a blurry photo should be resolved in minutes while a genuine sanctions hit deserves careful, unhurried disposition. Segmentation is what lets throughput and rigor coexist instead of trading off.

A review queue does not scale by hiring reviewers. It scales by deciding, correctly, which cases never needed one — and by making sure the ones that do arrive already sorted by why.

— Protocore · Operations engineering

Reason-required, audited actions

Every decision a reviewer makes — approve, reject, escalate, request more documents — must require a reason and must be recorded. Not a free-text afterthought, but a structured selection that says why the action was taken, captured at the moment it is taken. This is not bureaucracy; it is what makes the queue defensible. When a regulator, an auditor, or a later reviewer asks why an account was approved despite a flag, the answer is a named reviewer, a timestamp, and a stated reason — not a shrug. The audit trail is append-only, so a decision cannot be quietly rewritten after the fact; corrections are new entries, not edits over old ones. In our stack this queue and its audit model live in Protocore Center (/products/center), the operator console where every privileged action requires a reason and lands in a log that cannot be silently altered.

The four-eyes cases

Some decisions are too consequential for one person. Clearing a genuine sanctions hit, approving a high-risk profile, or overriding an automated rejection should require a second reviewer to confirm — maker-checker, or four-eyes. The first reviewer proposes and states a reason; a second, with the authority to do so, confirms or rejects and states theirs. Both actions are logged. This is not distrust of reviewers; it is the recognition that the highest-risk approvals are exactly the ones where a single mistake is most expensive, and a second set of eyes is the cheapest insurance against it. The queue design should route these cases to a two-step disposition automatically, by reason, rather than relying on reviewers to remember. Reserve the two-step deliberately for the consequential cases, though; applying it to everything doubles the cost of the whole queue and trains reviewers to rubber-stamp the second signature, which quietly defeats the point of having one.

Designing for volume: aging, prioritization, SLAs

A queue that only grows is a queue that has failed. Design in the pressure that keeps it moving. Cases age visibly, so nothing sits forgotten; each segment carries a service-level target, so a blurry-photo case breaching its minutes-long SLA surfaces differently from a sanctions case within its longer one. Prioritization is a real choice: oldest-first is fair and simple, but risk-first — worst potential exposure at the top — is often the right call, with aging as a tiebreaker so low-risk cases still clear rather than starve. The reviewer's screen should present the next case, already routed and prioritized, not a list to shop from — because a queue people pick through is a queue where the awkward cases never get picked. A queue without visible aging rots quietly: the hard cases sink to the bottom while easy ones churn on top, and the one metric that would have exposed it — the age of the oldest open case — is exactly the number nobody is watching until a customer complains.

Measuring the queue

Four numbers tell you whether the design works. The STP rate says how much never needed a human; queue depth and its trend say whether you are keeping up or falling behind; time-to-decision, tracked per segment against its SLA, says whether customers are waiting too long to be onboarded; and the reopen rate — decisions later overturned — says whether reviewers are deciding correctly or just quickly. Watch these together, because they trade against each other: pushing time-to-decision down while the reopen rate climbs means you bought speed with mistakes. A healthy queue is small, moving, decided correctly, and honest about the cases still open in it.

The back office people imagine — rooms of staff keying through applications — is what you get when automation clears too little and the queue is one undifferentiated pile. The back office that scales is the inverse: most applications never reach a human, the ones that do arrive sorted by reason and priority, every action carries a reason into an append-only log, and four-eyes guards the decisions that warrant it. Build the queue for the exceptions and it stays small as you grow. Build it as the place KYC happens and it grows with every signup you take.