Slik designer du en KYC-kø som skalerer

En KYC-kø er arbeidsflyten i back-office der identitetskontroller som en maskin ikke klarte å godkjenne på egen hånd, legges frem for et menneske. De fleste søknader bør gå gjennom automatisk; køen finnes for dem som ikke gjør det. Hele designmålet er at den skal holde seg liten – at den bare skal romme ekte tvetydighet og ingenting annet – for en kø som fylles med saker en maskin burde ha avgjort, er ikke en kontroll, men en flaskehals som vokser lineært med antall registreringer. Får du køen riktig, skalerer back-office med unntakene, ikke med volumet.

Den ene egenskapen – liten med vilje – styrer alle beslutningene som følger. Begynn med skillet som holder den slik.

Straight-through er målet, køen er unntaket

Straight-through processing (STP) betyr at en søknad går gjennom fra ende til annen uten menneskelig inngripen: dokumenter lest, identitet matchet, sanksjons- og PEP-screening ren, liveness bestått, beslutning registrert. Dette bør være den vanlige veien, og andelen søknader som tar den – STP-raten – er det ene tallet som forteller om køen vil skalere. Hvis over nitti prosent går gjennom automatisk, holder den manuelle køen en håndterbar dryppstrøm; hvis halvparten faller ut til gjennomgang, ansetter du saksbehandlere i takt med veksten. Køen er ikke stedet der KYC skjer. Det er stedet der automatisert KYC innrømmer at den er usikker. Løft STP-raten, og alle andre tall bedres på kjøpet: færre saker i kø, kortere ventetid, færre saksbehandlere å ansette. Den er verdt å angripe direkte – bedre dokumentopptak i klienten, tydeligere instruksjoner før bildet tas, matchterskler justert slik at ekte kunder ikke avvises av en overforsiktig regel – for hvert prosentpoeng som vinnes tilbake, er en sak som aldri blir noens ettermiddag.

Hva som havner i køen, og hvorfor

Saker faller ut til gjennomgang av spesifikke, navngivbare grunner, og grunnen er den viktigste egenskapen en sak har. Et dokumentbilde er for uskarpt til å leses. Navnet på ID-en stemmer ikke med navnet i søknaden. En sanksjons- eller PEP-screening ga en mulig treff som et menneske må bekrefte eller avvise. En adresse kan ikke verifiseres mot noen kilde. En liveness-sjekk feilet, eller det samme ansiktet eller dokumentet finnes allerede på en annen konto. Hver av disse er ulikt arbeid som krever ulik vurdering – og å slå dem sammen i én udifferensiert haug er den første feilen en gjennomgangskø gjør. Og samme grunn kan ha svært ulik tyngde: et navneavvik kan være en uanselig forskjell etter navnebytte ved giftermål, eller det første tegnet på en stjålet identitet, og køens jobb er å rute det til noen som kan se forskjellen, i stedet for å presse frem en rask konklusjon på en sak som fortjener en grundig en.

Én kø er ikke nok: segmenter etter grunn

En enkelt kø tvinger hver saksbehandler til å være generalist og hver sak til å vente bak urelaterte saker. Segmentering etter grunn løser begge deler. En kø for mulige sanksjonstreff behandles av folk som er opplært i screening og disposisjon; en kø for dokumentkvalitet er en rask visuell sjekk som en junior saksbehandler avgjør på sekunder; en kø for duplikatkontoer er en svindeletterforskning. Hvert segment får sin egen ruting, sin egen nødvendige kompetanse og sitt eget servicenivåmål, fordi et uskarpt bilde bør løses på minutter, mens et ekte sanksjonstreff fortjener grundig og upresset behandling. Segmentering er det som lar gjennomstrømning og grundighet eksistere side om side i stedet for å veies mot hverandre.

En godkjenningskø skalerer ikke ved å ansette flere saksbehandlere. Den skalerer ved å avgjøre, riktig, hvilke saker som aldri trengte manuell behandling — og ved å sørge for at de som trenger det, kommer inn allerede sortert etter årsak.

Handlinger som krever begrunnelse og logges

Hver beslutning en saksbehandler tar — godkjenne, avslå, eskalere, be om flere dokumenter — må ha en begrunnelse og må registreres. Ikke et fritekstfelt man husker i etterkant, men et strukturert valg som sier hvorfor handlingen ble utført, fanget i det øyeblikket den utføres. Dette er ikke byråkrati; det er det som gjør køen forsvarlig. Når en tilsynsmyndighet, en revisor eller en senere saksbehandler spør hvorfor en konto ble godkjent til tross for et varsel, er svaret en navngitt saksbehandler, et tidspunkt og en oppgitt begrunnelse — ikke et skuldertrekk. Revisjonssporet er append-only, slik at en beslutning ikke kan skrives om i det stille i ettertid; rettelser er nye oppføringer, ikke redigeringer oppå gamle. I vår stack ligger denne køen og revisjonsmodellen i Protocore Center (/products/center), operatørkonsollen der hver privilegerte handling krever en begrunnelse og havner i en logg som ikke kan endres i det skjulte.

Fireøyesakene

Noen beslutninger er for inngripende til at én person bør ta dem alene. Å avskrive en reell sanksjonstreff, godkjenne en høyrisikoprofil eller overstyre et automatisk avslag bør kreve at en andre saksbehandler bekrefter — maker-checker, eller fireøyesprinsippet. Den første saksbehandleren foreslår og oppgir en begrunnelse; en andre, med myndighet til det, bekrefter eller avviser og oppgir sin egen. Begge handlingene logges. Dette handler ikke om mistillit til saksbehandlerne; det er en erkjennelse av at de høyrisikogodkjenningene er nettopp de der én enkelt feil koster mest, og at et ekstra par øyne er den billigste forsikringen mot den. Kødesignet bør rute disse sakene automatisk til en totrinnsbehandling, basert på årsak, i stedet for å stole på at saksbehandlerne husker det. Reserver totrinnsbehandlingen bevisst for de alvorlige sakene; brukes den på alt, dobles kostnaden for hele køen, og saksbehandlerne lærer seg å stemple den andre signaturen uten å se etter, noe som i det stille ødelegger poenget med å ha den.

Design for volum: alder, prioritering, SLA-er

En kø som bare vokser, er en kø som har sviktet. Bygg inn presset som holder den i bevegelse. Saker eldes synlig, slik at ingenting blir liggende glemt; hvert segment har et servicenivåmål, slik at en sak med uskarpt bilde som bryter SLA-en på noen få minutter, vises annerledes enn en sanksjonssak innenfor sin lengre frist. Prioritering er et reelt valg: eldst først er rettferdig og enkelt, men risiko først — størst potensiell eksponering øverst — er ofte riktig, med alder som tiebreaker slik at lavrisikosaker fortsatt blir avgjort i stedet for å bli liggende. Saksbehandlerens skjerm bør vise neste sak, allerede rutet og prioritert, ikke en liste å plukke fra — for en kø folk plukker i, er en kø der de vanskelige sakene aldri blir plukket. En kø uten synlig alder råtner i stillhet: de vanskelige sakene synker til bunns mens de enkle surrer rundt øverst, og det ene målet som ville avslørt det — alderen på den eldste åpne saken — er nettopp tallet ingen følger med på før en kunde klager.

Måle køen

Fire tall forteller om designet fungerer. STP-raten sier hvor mye som aldri trengte et menneske; kødybden og trenden sier om du henger med eller faller etter; tid til beslutning, målt per segment mot SLA-en, sier om kundene venter for lenge på å bli onboardet; og gjenåpningsraten — beslutninger som senere omgjøres — sier om saksbehandlerne bestemmer riktig eller bare raskt. Følg med på disse sammen, for de trekker i hver sin retning: presser du tid til beslutning ned mens gjenåpningsraten stiger, har du kjøpt fart med feil. En sunn kø er liten, i bevegelse, avgjort riktig og ærlig om sakene som fortsatt er åpne i den.

Back office slik folk forestiller seg det — rom full av ansatte som taster seg gjennom søknader — er det du får når automatiseringen avklarer for lite og køen er én udifferensiert haug. Back office som skalerer er det motsatte: de fleste søknader når aldri et menneske, de som gjør det kommer sortert etter årsak og prioritet, hver handling tar med seg en begrunnelse inn i en append-only-logg, og firøyesprinsippet vokter beslutningene som fortjener det. Bygg køen for unntakene, så holder den seg liten etter hvert som du vokser. Bygg den som stedet der KYC skjer, og den vokser med hver eneste registrering du tar imot.