Sådan designer du en KYC-reviewkø, der skalerer

En KYC-reviewkø er back-office-workflowet, hvor identitetskontroller, en maskine ikke selv kunne afgøre, lægges frem for et menneske. De fleste ansøgninger bør passere automatisk; køen findes til dem, der ikke gør. Dens hele designmål er at forblive lille – at rumme ægte tvetydighed og intet andet – for en kø, der fyldes med sager, en maskine burde have afgjort, er ikke en kontrol, men en flaskehals, der vokser lineært med antallet af tilmeldinger. Får du køen rigtig, skalerer et back office med undtagelserne, ikke med volumen.

Den ene egenskab – lille med vilje – styrer enhver beslutning herfra. Start med det skel, der holder den sådan.

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

Straight-through processing (STP) betyder, at en ansøgning godkendes fra ende til anden uden menneskelig berøring: dokumenter læst, identitet matchet, sanktions- og PEP-screening ren, liveness bestået, beslutning registreret. Det bør være den almindelige vej, og andelen af ansøgninger, der tager den – STP-raten – er det eneste tal, der fortæller, om køen vil skalere. Hvis over halvfems procent godkendes automatisk, rummer den menneskelige kø en overkommelig sildren; hvis halvdelen falder ud til review, ansætter du reviewere i takt med væksten. Køen er ikke der, hvor KYC foregår. Det er der, hvor automatiseret KYC erkender, at den er i tvivl. Skru STP-raten op, og alle andre tal forbedres gratis: færre sager i kø, kortere ventetid, færre reviewere at ansætte. Det er værd at gå direkte efter – bedre dokumentoptagelse i klienten, tydeligere instruktioner før et foto tages, matchtærskler justeret, så ægte kunder ikke afvises af en overforsigtig regel – for hvert procentpoint, der vindes her, er en sag, der aldrig bliver til nogens eftermiddag.

Hvad der havner i køen, og hvorfor

Sager falder ud til review af specifikke, nævnbare årsager, og årsagen er den vigtigste egenskab, en sag bærer. Et dokumentfoto er for sløret til at kunne læses. Navnet på ID'et matcher ikke navnet på ansøgningen. En sanktions- eller PEP-screening gav et muligt hit, som et menneske skal bekræfte eller afvise. En adresse kan ikke verificeres mod nogen kilde. En liveness-kontrol fejlede, eller det samme ansigt eller dokument findes allerede på en anden konto. Hver af disse er en forskellig slags arbejde, der kræver en forskellig slags skøn – og at smide dem i én udifferentieret bunke er den første fejl, en reviewkø begår. Og samme årsag kan veje vidt forskelligt: en navnemismatch kan være en harmløs forskel på grund af et navneskift ved ægteskab eller det første tegn på en stjålet identitet, og køens opgave er at route den til en, der kan se forskel, frem for at presse en hurtig afgørelse igennem på en sag, der fortjener en grundig.

Én kø er ikke nok: segmentér efter årsag

En enkelt kø tvinger enhver reviewer til at være generalist og enhver sag til at vente bag urelaterede. Segmentering efter årsag løser begge dele. En kø for mulige sanktionsmatches behandles af folk uddannet i screening og afgørelse; en kø for dokumentkvalitet er et hurtigt visuelt tjek, som en junior reviewer klarer på få sekunder; en kø for dublerede konti er en svindelundersøgelse. Hvert segment får sin egen routing, sin egen nødvendige kompetence og sit eget servicemål, for et sløret foto bør løses på minutter, mens et ægte sanktionshit fortjener grundig og upresset behandling. Segmentering er det, der lader gennemløb og stringens eksistere side om side i stedet for at skulle byttes mod hinanden.

En gennemgangskø skalerer ikke ved at ansætte flere sagsbehandlere. Den skalerer ved at afgøre korrekt, hvilke sager der aldrig behøvede en – og ved at sikre, at de sager, der gør, allerede ankommer sorteret efter årsag.

Handlinger med krav om begrundelse og revisionsspor

Hver beslutning, en sagsbehandler træffer – godkend, afvis, eskalér, anmod om flere dokumenter – skal kræve en begrundelse og skal registreres. Ikke et fritekstfelt som en eftertanke, men et struktureret valg, der siger hvorfor handlingen blev udført, og som fanges i det øjeblik, den udføres. Det er ikke bureaukrati; det er det, der gør køen forsvarlig. Når en tilsynsmyndighed, en revisor eller en senere sagsbehandler spørger, hvorfor en konto blev godkendt trods et flag, er svaret en navngiven sagsbehandler, et tidsstempel og en angivet begrundelse – ikke et skuldertræk. Revisionssporet er append-only, så en beslutning ikke i det skjulte kan omskrives bagefter; rettelser er nye poster, ikke redigeringer oven på gamle. I vores stack findes denne kø og dens revisionsmodel i Protocore Center (/products/center), operatørkonsollen, hvor hver privilegeret handling kræver en begrundelse og havner i en log, der ikke kan ændres i det skjulte.

Sager med fire øjne

Nogle beslutninger er for vidtrækkende til én person. At afvise et reelt sanktionshit, godkende en højrisikoprofil eller tilsidesætte en automatisk afvisning bør kræve, at en anden sagsbehandler bekræfter – maker-checker, eller fire-øjne-princippet. Den første sagsbehandler foreslår og angiver en begrundelse; en anden med den fornødne beføjelse bekræfter eller afviser og angiver sin egen. Begge handlinger logges. Det er ikke mistillid til sagsbehandlerne; det er anerkendelsen af, at de mest risikable godkendelser netop er dem, hvor en enkelt fejl er dyrest, og at et ekstra par øjne er den billigste forsikring mod den. Køens design bør automatisk route disse sager til en totrinsafgørelse ud fra årsag, i stedet for at stole på, at sagsbehandlerne husker det. Spar dog totrinsproceduren til de afgørende sager; hvis den bruges på alt, fordobles omkostningen for hele køen, og sagsbehandlerne trænes til blot at stemple den anden underskrift, hvilket i det stille underminerer meningen med at have den.

Design til volumen: alder, prioritering, SLA'er

En kø, der kun vokser, er en kø, der har fejlet. Byg det pres ind, der holder den i bevægelse. Sager ældes synligt, så intet ligger glemt; hvert segment har et servicemål, så en sag med et sløret foto, der overskrider sin SLA på få minutter, træder frem anderledes end en sanktionssag inden for sin længere frist. Prioritering er et reelt valg: ældst først er retfærdigt og enkelt, men risiko først – størst potentiel eksponering øverst – er ofte det rigtige, med alder som tiebreaker, så lavrisikosager stadig bliver afsluttet i stedet for at sulte. Sagsbehandlerens skærmbillede bør vise den næste sag, allerede routet og prioriteret, ikke en liste at vælge fra – for en kø, folk plukker i, er en kø, hvor de besværlige sager aldrig bliver plukket. En kø uden synlig alder rådner stille: de svære sager synker til bunden, mens de nemme vrimler øverst, og det ene nøgletal, der ville have afsløret det – alderen på den ældste åbne sag – er netop det tal, ingen holder øje med, før en kunde klager.

Sådan måler du køen

Fire tal fortæller, om designet virker. STP-raten siger, hvor meget der aldrig behøvede et menneske; køens dybde og dens tendens siger, om du holder trit eller sakker bagud; tid til beslutning, målt pr. segment mod dets SLA, siger, om kunderne venter for længe på at blive onboardet; og genåbningsraten – beslutninger, der senere omstødes – siger, om sagsbehandlerne afgør sagerne rigtigt eller bare hurtigt. Følg dem sammen, for de modvirker hinanden: presser du tiden til beslutning ned, mens genåbningsraten stiger, har du købt hastighed med fejl. En sund kø er lille, i bevægelse, afgjort korrekt og ærlig om de sager, der stadig er åbne i den.

Det back office, folk forestiller sig – rum fuld af medarbejdere, der taster ansøgninger igennem – er det, man får, når automatiseringen afgør for lidt, og køen er én udifferentieret bunke. Det back office, der skalerer, er det omvendte: de fleste ansøgninger når aldrig et menneske, de, der gør, ankommer sorteret efter årsag og prioritet, hver handling bringer en begrundelse med ind i en append-only log, og fire øjne vogter de beslutninger, der kræver det. Byg køen til undtagelserne, så forbliver den lille, mens du vokser. Byg den som stedet, hvor KYC foregår, og den vokser med hver tilmelding, du får.