Fältanteckningar

Så designar du en KYC-granskningskö som skalar

En KYC-granskningskö är back office-flödet där identitetskontroller som en maskin inte kunde godkänna på egen hand läggs framför en människa. De flesta ansökningar ska passera automatiskt, och kön finns för dem som inte gör det. Hela designmålet är att hålla den liten – att bara rymma verklig tvetydighet – eftersom en kö som fylls av fall som en maskin borde ha avgjort inte är en kontroll utan en flaskhals som växer linjärt med antalet registreringar. Får du kön rätt skalar back office med undantagen, inte med volymen.

Just den egenskapen – liten med flit – styr varje beslut som följer. Börja med uppdelningen som håller den så.

Straight-through är målet, kön är undantaget

Straight-through processing (STP) innebär att en ansökan godkänns från början till slut utan mänsklig inblandning: dokument lästa, identitet matchad, sanktions- och PEP-screening ren, liveness godkänd, beslut registrerat. Det här bör vara den vanliga vägen, och andelen ansökningar som tar den – STP-graden – är det enda tal som säger om kön kommer att skala. Om över nittio procent godkänns automatiskt rymmer den mänskliga kön ett hanterbart flöde. Om hälften faller ut till granskning anställer du granskare i takt med tillväxten. Kön är inte där KYC sker. Den är där automatiserad KYC erkänner att den är osäker. Höj STP-graden och alla andra tal förbättras på köpet: färre köade fall, kortare väntetider, färre granskare att anställa. Det är värt att angripa direkt – bättre dokumentinfångning i klienten, tydligare instruktioner innan ett foto tas, matchningströsklar som justeras så att genuina kunder inte avvisas av en alltför försiktig regel – eftersom varje procentenhet som vinns där är ett fall som aldrig blir någons eftermiddag.

Vad som hamnar i kön, och varför

Fall faller ut till granskning av specifika, namngivbara skäl, och skälet är det viktigaste attributet ett fall har. Ett dokumentfoto är för suddigt för att läsas. Namnet på id-handlingen stämmer inte med namnet i ansökan. En sanktions- eller PEP-screening gav en möjlig träff som en människa måste bekräfta eller avfärda. En adress går inte att verifiera mot någon källa. En liveness-kontroll misslyckades, eller samma ansikte eller dokument finns redan på ett annat konto. Vart och ett av dessa är en egen sorts arbete som kräver en egen sorts bedömning – och att slänga ihop dem i en enda odifferentierad hög är det första misstaget en granskningskö gör. Dessutom kan samma skäl väga mycket olika: en namnavvikelse kan vara en obetydlig skillnad på grund av namnbyte vid giftermål eller det första tecknet på en stulen identitet, och kön har till uppgift att styra fallet till någon som kan se skillnaden, i stället för att tvinga fram ett snabbt avgörande i ett fall som förtjänar ett noggrant.

En enda kö räcker inte: segmentera efter skäl

En enda kö tvingar varje granskare att vara generalist och varje fall att vänta bakom orelaterade fall. Segmentering efter skäl löser båda problemen. En kö för möjliga sanktionsträffar hanteras av personer utbildade i screening och avgörande. En kö för dokumentkvalitet är en snabb visuell kontroll som en junior granskare klarar på några sekunder. En kö för dubbletter av konton är en bedrägeriutredning. Varje segment får sin egen routing, sin egen nödvändiga kompetens och sitt eget servicenivåmål, eftersom ett suddigt foto ska lösas på minuter medan en verklig sanktionsträff förtjänar noggrant och lugnt avgörande. Segmentering är det som låter genomströmning och noggrannhet samexistera i stället för att vara en avvägning.

En granskningskö skalar man inte genom att anställa fler granskare. Man skalar den genom att rätt avgöra vilka ärenden som aldrig behövde granskas — och se till att de som behöver det redan kommer sorterade efter orsak.
— Protocore · Operations engineering

Åtgärder som kräver motivering och revideras

Varje beslut en granskare fattar — godkänna, avslå, eskalera, begära fler dokument — måste kräva en motivering och måste registreras. Inte som ett fritextfält i efterhand, utan som ett strukturerat val som anger varför åtgärden vidtogs, fångat i samma ögonblick som den vidtas. Det är ingen byråkrati; det är det som gör kön försvarbar. När en tillsynsmyndighet, en revisor eller en senare granskare frågar varför ett konto godkändes trots en flagga är svaret en namngiven granskare, en tidsstämpel och en angiven orsak — inte en axelryckning. Revisionsspåret är append-only, så ett beslut kan inte i tysthet skrivas om i efterhand; rättelser är nya poster, inte ändringar över gamla. I vår stack finns den här kön och dess revisionsmodell i Protocore Center (/products/center), operatörskonsolen där varje privilegierad åtgärd kräver en motivering och hamnar i en logg som inte kan ändras i det tysta.

Fall som kräver fyra ögon

Vissa beslut är för tunga för en enda person. Att avfärda en verklig sanktionsträff, godkänna en högriskprofil eller upphäva ett automatiskt avslag bör kräva att en andra granskare bekräftar — maker-checker, eller fyraögonprincipen. Den första granskaren föreslår och anger en motivering; en andra, med behörighet att göra det, bekräftar eller avslår och anger sin. Båda åtgärderna loggas. Det handlar inte om misstro mot granskare; det handlar om att de mest riskfyllda godkännandena är precis de där ett enda misstag blir dyrast, och att ett andra par ögon är den billigaste försäkringen mot det. Köns design bör dirigera de här ärendena till ett tvåstegsbeslut automatiskt, utifrån orsak, i stället för att lita på att granskare kommer ihåg det. Spara dock tvåstegsförfarandet medvetet för de avgörande fallen; om det används på allt dubblas kostnaden för hela kön och granskare vänjer sig vid att stämpla den andra signaturen utan att läsa, vilket i det tysta gör hela poängen med den meningslös.

Design för volym: åldrande, prioritering, SLA:er

En kö som bara växer är en kö som har misslyckats. Bygg in det tryck som håller den i rörelse. Ärenden åldras synligt, så ingenting ligger bortglömt; varje segment har ett servicenivåmål, så ett ärende med suddigt foto som överskrider sin SLA på några minuter syns på ett annat sätt än ett sanktionsärende inom sin längre. Prioritering är ett verkligt val: äldst först är rättvist och enkelt, men risk först — störst potentiell exponering överst — är ofta rätt väg, med ålder som utslagsgivare så att lågriskärenden ändå blir avgjorda i stället för att svältas ut. Granskarens skärm ska visa nästa ärende, redan dirigerat och prioriterat, inte en lista att välja från — för en kö som folk plockar i är en kö där de obekväma ärendena aldrig blir valda. En kö utan synligt åldrande ruttnar i det tysta: de svåra ärendena sjunker till botten medan de enkla snurrar högst upp, och det enda nyckeltal som hade avslöjat det — åldern på det äldsta öppna ärendet — är precis den siffra ingen tittar på förrän en kund klagar.

Att mäta kön

Fyra siffror visar om designen fungerar. STP-andelen visar hur mycket som aldrig behövde en människa; köns djup och dess trend visar om ni hänger med eller halkar efter; tid till beslut, följd per segment mot dess SLA, visar om kunder väntar för länge på att bli onboardade; och andelen återöppnade ärenden — beslut som senare ändrats — visar om granskarna beslutar rätt eller bara snabbt. Titta på dem tillsammans, för de väger mot varandra: om tiden till beslut pressas ned medan andelen återöppnade stiger har ni köpt fart med misstag. En frisk kö är liten, i rörelse, avgörs korrekt och är ärlig om de ärenden som fortfarande är öppna i den.

Den back office folk föreställer sig — rum fyllda av personal som knappar in ansökningar — är vad man får när automatiseringen avgör för lite och kön är en odifferentierad hög. Den back office som skalar är motsatsen: de flesta ansökningar når aldrig en människa, de som gör det kommer sorterade efter orsak och prioritet, varje åtgärd för med sig en motivering in i en append-only-logg, och fyra ögon vaktar de beslut som kräver det. Bygg kön för undantagen så förblir den liten när ni växer. Bygg den som platsen där KYC sker så växer den med varje registrering ni tar emot.

Har du ett system att bygga?

Berätta vad problemet är. Vi återkommer med en arkitektur och en plan.