Dissenyar una cua de revisió KYC que escali
Una cua de revisió KYC és el flux de treball de back-office on les verificacions d'identitat que una màquina no ha pogut resoldre soles es posen davant d'una persona. La majoria de sol·licituds haurien de passar automàticament; la cua existeix per a les que no. Tot el seu objectiu de disseny és mantenir-se petita — contenir ambigüitat genuïna i res més — perquè una cua que s'omple de casos que una màquina hauria d'haver decidit no és un control, és un coll d'ampolla que creix linealment amb els alta de clients. Si la cua és la correcta, un back-office escala amb les excepcions, no amb el volum.
Aquesta única propietat — ser petita a propòsit — condiciona cada decisió posterior. Comencem per la divisió que ho garanteix.
El tractament directe és l'objectiu, la cua és l'excepció
El tractament directe (STP, straight-through processing) vol dir que una sol·licitud es resol de cap a cap sense cap intervenció humana: documents llegits, identitat verificada, cribratge de sancions i PEP net, prova de vida superada, decisió registrada. Hauria de ser el camí habitual, i el percentatge de sol·licituds que el segueixen — la taxa d'STP — és l'únic número que diu si la cua escalarà. Si més del noranta per cent es resol automàticament, la cua humana rep un degoteig manejable; si la meitat cau a revisió, contractes revisors al ritme del creixement. La cua no és on es fa el KYC. És on el KYC automàtic admet que no n'està segur. Si puges la taxa d'STP, tota la resta millora de franc: menys casos a la cua, esperes més curtes, menys revisors a contractar. Val la pena atacar-ho directament — millor captura de documents al client, instruccions més clares abans de fer la foto, llindars de coincidència ajustats perquè els clients legítims no siguin rebutjats per una regla excessivament cautelosa — perquè cada punt percentual recuperat és un cas que mai es convertirà en la tarda de ningú.
Què arriba a la cua i per què
Els casos cauen a revisió per motius concrets i identificables, i el motiu és l'atribut més important que porta un cas. La foto d'un document és massa borrosa per llegir-la. El nom del document d'identitat no coincideix amb el de la sol·licitud. Un cribratge de sancions o PEP ha retornat una possible coincidència que cal que una persona confirmi o descarti. No es pot verificar una adreça amb cap font. Ha fallat una prova de vida, o la mateixa cara o el mateix document ja existeix en un altre compte. Cadascun és un tipus de feina diferent que demana un criteri diferent — i ajuntar-los tots en un munt indiferenciat és el primer error d'una cua de revisió. A més, el mateix motiu pot tenir un pes molt diferent: una discrepància de nom pot ser una diferència corrent per cognom de casada o el primer senyal d'una identitat robada, i la feina de la cua és encaminar-la a algú que sàpiga distingir-ho, en lloc de forçar un veredicte ràpid en un cas que en mereix un de curós.
Una cua no n'hi ha prou: segmenta per motiu
Una única cua obliga cada revisor a ser generalista i cada cas a esperar darrere d'altres que no hi tenen res a veure. Segmentar per motiu ho soluciona tot. Una cua de possibles coincidències de sancions la treballen persones formades en cribratge i resolució; una cua de qualitat de document és una comprovació visual ràpida que un revisor júnior resol en segons; una cua de comptes duplicats és una investigació de frau. Cada segment té el seu propi encaminament, la seva pròpia competència requerida i el seu propi objectiu de nivell de servei, perquè una foto borrosa s'ha de resoldre en minuts, mentre que una coincidència real amb sancions mereix una resolució curosa i sense pressa. La segmentació és el que permet que rendiment i rigor convisquin en lloc de compensar-se l'un a costa de l'altre.
Una cua de revisió no escala contractant revisors. Escala decidint, correctament, quins casos no n'han necessitat mai cap, i fent que els que sí arriben ja vinguin ordenats pel motiu.
Accions amb motiu obligatori i auditades
Cada decisió que pren un revisor (aprovar, rebutjar, escalar, demanar més documents) ha d'exigir un motiu i ha de quedar registrada. No com un text lliure afegit a darrera hora, sinó com una selecció estructurada que explica per què s'ha fet l'acció, captada en el moment de fer-la. Això no és burocràcia: és el que fa que la cua sigui defensable. Quan un regulador, un auditor o un revisor posterior pregunta per què es va aprovar un compte malgrat una alerta, la resposta és un revisor amb nom i cognoms, una marca de temps i un motiu declarat, no una arronsada d'espatlles. El registre d'auditoria és només d'addició (append-only), de manera que una decisió no es pot reescriure d'amagat a posteriori; les correccions són entrades noves, no edicions sobre les antigues. A la nostra pila, aquesta cua i el seu model d'auditoria viuen a Protocore Center (/products/center), la consola d'operador on cada acció privilegiada exigeix un motiu i queda en un registre que no es pot alterar en silenci.
Els casos de quatre ulls
Algunes decisions tenen massa conseqüències per deixar-les en mans d'una sola persona. Descartar una coincidència real amb sancions, aprovar un perfil d'alt risc o anul·lar un rebuig automàtic ha d'exigir la confirmació d'un segon revisor: maker-checker, o quatre ulls. El primer revisor proposa i indica un motiu; un segon, amb l'autoritat per fer-ho, confirma o rebutja i indica el seu. Totes dues accions queden registrades. Això no és desconfiança envers els revisors: és reconèixer que les aprovacions de més risc són justament aquelles on un sol error costa més, i que un segon parell d'ulls és l'assegurança més barata. El disseny de la cua ha d'encaminar aquests casos automàticament a una resolució en dos passos, segons el motiu, en lloc de confiar que els revisors se'n recordin. Reserveu, però, els dos passos deliberadament per als casos de conseqüències; aplicar-los a tot duplica el cost de tota la cua i ensinistra els revisors a signar per inèrcia la segona signatura, cosa que anul·la en silenci el sentit de tenir-la.
Dissenyar per al volum: antiguitat, priorització i SLA
Una cua que només creix és una cua que ha fallat. Incorporeu-hi la pressió que la fa avançar. Els casos envelleixen a la vista, de manera que res queda oblidat; cada segment té un objectiu de nivell de servei, així que un cas de foto borrosa que incompleix el seu SLA de pocs minuts es fa notar de manera diferent que un cas de sancions dins del seu, més llarg. Prioritzar és una decisió real: primer el més antic és just i senzill, però primer el de més risc (la pitjor exposició potencial a dalt de tot) sovint és la millor opció, amb l'antiguitat com a desempat perquè els casos de baix risc també es resolguin i no es quedin sense atendre. La pantalla del revisor ha de mostrar el cas següent, ja encaminat i prioritzat, no una llista per escollir, perquè una cua on la gent va triant és una cua on els casos incòmodes no es trien mai. Una cua sense antiguitat visible es podreix en silenci: els casos difícils s'enfonsen al fons mentre els fàcils es mouen a dalt, i l'única mètrica que ho hauria delatat, l'antiguitat del cas obert més vell, és justament el número que ningú mira fins que un client es queixa.
Mesurar la cua
Quatre números diuen si el disseny funciona. La taxa d'STP indica quant no ha necessitat mai una persona; la profunditat de la cua i la seva tendència, si aneu al dia o us esteu quedant enrere; el temps de decisió, seguit per segment respecte del seu SLA, si els clients esperen massa a ser donats d'alta; i la taxa de reobertura (decisions que més tard es revoquen), si els revisors decideixen bé o només de pressa. Mireu-los tots junts, perquè competeixen entre ells: reduir el temps de decisió mentre puja la taxa de reobertura vol dir que heu comprat velocitat a canvi d'errors. Una cua sana és petita, es mou, decideix bé i és honesta sobre els casos que hi continuen oberts.
El back office que la gent s'imagina, sales plenes de personal picant sol·licituds, és el que obteniu quan l'automatització resol massa poc i la cua és un munt indiferenciat. El back office que escala és l'invers: la majoria de sol·licituds no arriben mai a una persona, les que hi arriben vénen ordenades per motiu i prioritat, cada acció porta un motiu a un registre append-only, i els quatre ulls vigilen les decisions que ho mereixen. Construïu la cua per a les excepcions i es mantindrà petita a mesura que creixeu. Construïu-la com el lloc on es fa el KYC i créixer amb cada alta que accepteu.
Tens un sistema per construir?
Explica'ns el problema. Et respondrem amb una arquitectura i un pla.