Een KYC-reviewqueue ontwerpen die schaalt

Een KYC-reviewqueue is de back-officeworkflow waarin identiteitschecks die een machine niet zelfstandig kon afronden, aan een mens worden voorgelegd. De meeste aanvragen horen automatisch door te komen; de queue bestaat voor de aanvragen die dat niet doen. Het ontwerpdoel is dat hij klein blijft — alleen echte twijfelgevallen bevat — want een queue die volloopt met zaken die een machine had moeten beslissen, is geen controle maar een bottleneck die lineair meegroeit met het aantal aanmeldingen. Als de queue goed zit, schaalt een back office mee met uitzonderingen, niet met volume.

Die ene eigenschap — bewust klein — stuurt elke beslissing die volgt. Begin met de scheiding die hem zo houdt.

Straight-through is het doel, de queue is de uitzondering

Straight-through processing (STP) betekent dat een aanvraag van begin tot eind zonder menselijke tussenkomst wordt afgerond: documenten gelezen, identiteit gematcht, sanctie- en PEP-screening schoon, liveness geslaagd, beslissing vastgelegd. Dit moet het gewone pad zijn, en het aandeel aanvragen dat dit pad volgt — de STP-rate — is het enige getal dat zegt of de queue zal schalen. Als negentig-en-nog-wat procent automatisch doorkomt, bevat de menselijke queue een beheersbaar stroompje; valt de helft uit naar review, dan neem je reviewers aan in het tempo van de groei. De queue is niet waar KYC gebeurt. Het is waar geautomatiseerde KYC toegeeft dat hij het niet zeker weet. Verhoog de STP-rate en elk ander getal verbetert vanzelf: minder zaken in de queue, kortere wachttijden, minder reviewers om aan te nemen. Het loont om dit direct aan te pakken — betere documentopname in de client, duidelijkere instructies voordat een foto wordt gemaakt, matchingdrempels die zo zijn afgesteld dat echte klanten niet door een te voorzichtige regel worden afgewezen — want elk procentpunt dat je daar terugwint, is een zaak die nooit iemands middag wordt.

Wat er in de queue belandt, en waarom

Zaken vallen uit naar review om specifieke, benoembare redenen, en die reden is het belangrijkste attribuut dat een zaak meedraagt. Een documentfoto is te wazig om te lezen. De naam op het ID komt niet overeen met de naam op de aanvraag. Een sanctie- of PEP-screening gaf een mogelijke hit die een mens moet bevestigen of verwerpen. Een adres kan bij geen enkele bron worden geverifieerd. Een liveness-check mislukte, of hetzelfde gezicht of document bestaat al op een ander account. Elk daarvan is een ander soort werk dat een ander soort oordeel vraagt — en ze op één grote hoop gooien is de eerste fout die een reviewqueue maakt. Bovendien kan dezelfde reden heel verschillend wegen: een naamverschil kan een alledaags verschil door een huwelijksnaam zijn of het eerste teken van een gestolen identiteit, en de queue moet het doorsturen naar iemand die het verschil ziet, in plaats van een snel oordeel af te dwingen over een zaak die zorgvuldigheid verdient.

Eén queue is niet genoeg: segmenteer op reden

Eén enkele queue dwingt elke reviewer een generalist te zijn en laat elke zaak achter niet-gerelateerde zaken wachten. Segmenteren op reden lost beide op. Een queue voor mogelijke sanctiematches wordt bemand door mensen die zijn getraind in screening en afhandeling; een queue voor documentkwaliteit is een snelle visuele check die een junior reviewer in seconden afrondt; een queue voor dubbele accounts is een fraudeonderzoek. Elk segment krijgt zijn eigen routing, vereiste vaardigheid en service-leveldoel, want een wazige foto moet in minuten zijn opgelost, terwijl een echte sanctiehit zorgvuldige, onhaastige afhandeling verdient. Segmentatie laat doorvoer en striktheid naast elkaar bestaan in plaats van tegen elkaar af te wegen.

Een reviewqueue schaal je niet op door meer reviewers aan te nemen. Je schaalt hem door correct te bepalen welke cases er nooit een nodig hadden — en door te zorgen dat de cases die er wel een nodig hebben al gesorteerd op reden binnenkomen.

Acties met verplichte reden en audittrail

Elke beslissing van een reviewer — goedkeuren, afwijzen, escaleren, extra documenten opvragen — moet een reden vereisen en worden vastgelegd. Geen vrije tekst achteraf, maar een gestructureerde keuze die aangeeft waarom de actie is uitgevoerd, vastgelegd op het moment zelf. Dat is geen bureaucratie: het maakt de queue verdedigbaar. Als een toezichthouder, een auditor of een latere reviewer vraagt waarom een account ondanks een flag is goedgekeurd, is het antwoord een reviewer met naam, een tijdstempel en een vermelde reden — geen schouderophalen. De audittrail is append-only, dus een beslissing kan achteraf niet ongemerkt worden herschreven; correcties zijn nieuwe regels, geen aanpassingen van oude. In onze stack leven deze queue en het bijbehorende auditmodel in Protocore Center (/products/center), de operatorconsole waar elke geprivilegieerde actie een reden vereist en terechtkomt in een log dat niet ongemerkt kan worden gewijzigd.

De vierogencases

Sommige beslissingen wegen te zwaar voor één persoon. Een echte sanctiehit vrijgeven, een hoogrisicoprofiel goedkeuren of een geautomatiseerde afwijzing overrulen vraagt om bevestiging door een tweede reviewer — maker-checker, oftewel het vierogenprincipe. De eerste reviewer stelt voor en geeft een reden; een tweede, met de bevoegdheid daartoe, bevestigt of wijst af en geeft ook een reden. Beide acties worden gelogd. Dat is geen wantrouwen jegens reviewers; het erkent dat juist bij de goedkeuringen met het hoogste risico één fout het duurst is, en dat een tweede paar ogen daar de goedkoopste verzekering tegen is. Het queueontwerp hoort deze cases automatisch, op basis van de reden, naar een afhandeling in twee stappen te routeren, in plaats van te rekenen op het geheugen van reviewers. Bewaar die twee stappen wel bewust voor de zwaarwegende cases: als je ze overal toepast, verdubbelt de hele queue in kosten en leer je reviewers de tweede handtekening blind af te stempelen — wat het nut ervan stilletjes tenietdoet.

Ontwerpen voor volume: veroudering, prioritering, SLA's

Een queue die alleen maar groeit, is een queue die heeft gefaald. Bouw de druk in die hem in beweging houdt. Cases verouderen zichtbaar, zodat niets vergeten blijft liggen; elk segment heeft een servicelevel-doel, zodat een case met een wazige foto die zijn SLA van enkele minuten overschrijdt anders opvalt dan een sanctiecase binnen zijn langere SLA. Prioritering is een echte keuze: oudste-eerst is eerlijk en simpel, maar risico-eerst — de grootste mogelijke blootstelling bovenaan — is vaak de juiste keuze, met veroudering als tiebreaker zodat cases met laag risico alsnog worden afgehandeld in plaats van te verhongeren. Het scherm van de reviewer toont de volgende case, al gerouteerd en geprioriteerd, geen lijst om uit te kiezen — want een queue waar mensen doorheen struinen is een queue waarin de lastige cases nooit worden gekozen. Een queue zonder zichtbare veroudering rot stilletjes weg: de moeilijke cases zakken naar de bodem terwijl de makkelijke bovenin rondtollen, en de ene metric die dat had blootgelegd — de leeftijd van de oudste openstaande case — is precies het getal waar niemand naar kijkt tot een klant klaagt.

De queue meten

Vier getallen laten zien of het ontwerp werkt. De STP-rate zegt hoeveel er nooit een mens nodig had; queuediepte en de trend daarvan zeggen of je het bijhoudt of achterop raakt; de doorlooptijd tot beslissing, per segment gemeten tegen de SLA, zegt of klanten te lang wachten op onboarding; en de reopen-rate — beslissingen die later zijn teruggedraaid — zegt of reviewers correct beslissen of alleen snel. Kijk naar alle vier tegelijk, want ze wegen tegen elkaar af: de doorlooptijd verlagen terwijl de reopen-rate stijgt, betekent dat je snelheid hebt gekocht met fouten. Een gezonde queue is klein, beweegt, wordt correct afgehandeld en is eerlijk over de cases die er nog in openstaan.

De backoffice waar mensen aan denken — zalen vol medewerkers die aanvragen invoeren — krijg je wanneer automatisering te weinig afhandelt en de queue één ongedifferentieerde hoop is. De backoffice die schaalt is het omgekeerde: de meeste aanvragen bereiken nooit een mens, de aanvragen die dat wel doen komen gesorteerd op reden en prioriteit binnen, elke actie draagt een reden mee naar een append-only log, en het vierogenprincipe bewaakt de beslissingen die dat verdienen. Bouw de queue voor de uitzonderingen en hij blijft klein terwijl je groeit. Bouw hem als de plek waar KYC gebeurt en hij groeit mee met elke aanmelding die je binnenhaalt.