Manual Review Queue
Ayrıca şöyle anılır Review Queue, Case Queue, KYC Case Management, Exception Queue
A manual review queue is the holding area a KYC or fraud-screening system routes cases to when it can't resolve them automatically with enough confidence to auto-approve or auto-reject outright: a document that scanned with unusual metadata, a liveness check that came back borderline, a name that fuzzy-matched a watchlist entry, or a customer flagged manually by someone downstream. A human analyst then looks at the evidence and makes a binding call, approve, reject, escalate to a more senior reviewer, or ask the customer for more information, that the automated system alone wasn't trusted to make.
The queue itself is an operational artifact as much as a compliance one: cases need to be prioritized (which one does an analyst look at first, the highest risk, the oldest, the one closest to breaching a service-level deadline), assigned (to a specific analyst or team, or left in a shared pool), and tracked (so a regulator or an internal audit can later see who decided what, and why). Getting this operationally right is a real cost center for any KYC program, because review capacity scales with case volume, and case volume scales with how noisy the automated system upstream is, a high False Positive Rate on any upstream check directly inflates this queue.
Who actually built this
FATF's risk-based-approach guidance is the regulatory reason an escalation path has to exist at all, a fully automated system with no human backstop on its uncertain calls doesn't satisfy due-diligence expectations. But the concrete shape of a review queue, SLA timers, assignment, a fixed decision set, an audit trail, isn't spelled out by any regulator; it's standard case-management and fraud-ops tooling practice, the same pattern used across customer support and fraud operations generally, adapted to a compliance context. Solidus did not originate any part of this pattern.
Solidus today
Solidus Verify's merchant dashboard genuinely ships a version of this: failed and expired verification sessions land in a queue, get a transparent risk-ordering heuristic, and a reviewer can approve, reject, escalate, or request more information, with the decision written to an audit log and, on approval, the original auto-reject overturned and the credential issued. It's real code against a real database, running today, and it's also narrow: it handles Solidus's own automated pipeline's edge cases, not a customer's separate AML or sanctions review workload, and there's no multi-analyst assignment model behind it yet.
See also
Risk Scoring explains why the heuristic that orders this queue is deliberately not an AML risk score. False Positive Rate is the upstream metric that determines how full this queue gets. KYC is the process whose uncertain outcomes land here. Drop-off Rate and Pass Rate are the funnel-level metrics this queue sits downstream of.
Nereden geliyor
Bunu başkası belirtti. Solidus bir araya getiriyor.
Not from a formal standard. FATF's risk-based-approach guidance (Recommendation 1) is the regulatory backdrop requiring that some escalation path exist at all: an automated system can't be allowed to auto-reject or auto-approve every case with no human check on the ones it isn't confident about. But the specific shape of a manual review queue, cases with SLA timers, analyst assignment, a defined set of decisions (approve/reject/escalate/request more information), and an audit trail of who decided what, is standard case-management and operations-tooling practice, borrowed from fraud operations and customer-support tooling generally, not something any single body defined.
Bunu nasıl doğrularsınız
Test ağında çalışıyor. Ana ağda değil.
Not independently checkable by a stranger, it lives behind the merchant dashboard's account authentication, so there's no public URL to curl. Stated honestly rather than pointed at something unverifiable.