Cómo diseñar una cola de revisión KYC que escale

Una cola de revisión KYC es el flujo de trabajo de back office en el que las verificaciones de identidad que una máquina no pudo resolver por sí sola se ponen delante de una persona. La mayoría de las solicitudes deberían pasar automáticamente; la cola existe para las que no. Su objetivo de diseño es mantenerse pequeña —contener ambigüedad genuina y nada más—, porque una cola que se llena de casos que una máquina debió decidir no es un control, es un cuello de botella que crece de forma lineal con los registros. Si la cola está bien hecha, el back office escala con las excepciones, no con el volumen.

Esa única propiedad —ser pequeña a propósito— condiciona cada decisión que sigue. Empecemos por la división que la mantiene así.

El objetivo es el procesamiento directo; la cola es la excepción

El procesamiento directo (STP, straight-through processing) significa que una solicitud se resuelve de principio a fin sin intervención humana: documentos leídos, identidad cotejada, cribado de sanciones y PEP limpio, prueba de vida superada, decisión registrada. Debería ser el camino habitual, y el porcentaje de solicitudes que lo siguen —la tasa de STP— es la cifra que te dice si la cola escalará. Si más del noventa por ciento se resuelve automáticamente, la cola humana recibe un goteo manejable; si la mitad cae a revisión, estarás contratando revisores al ritmo del crecimiento. La cola no es donde ocurre el KYC. Es donde el KYC automatizado admite que no está seguro. Sube la tasa de STP y todo lo demás mejora gratis: menos casos en cola, esperas más cortas, menos revisores que contratar. Merece la pena atacarla de frente —mejor captura de documentos en el cliente, instrucciones más claras antes de tomar la foto, umbrales de coincidencia ajustados para que los clientes legítimos no reboten por una regla demasiado cautelosa—, porque cada punto porcentual recuperado ahí es un caso que nunca se convierte en la tarde de alguien.

Qué llega a la cola y por qué

Los casos pasan a revisión por motivos concretos y nombrables, y el motivo es el atributo más importante que lleva un caso. La foto del documento está demasiado borrosa para leerse. El nombre del documento de identidad no coincide con el de la solicitud. Un cribado de sanciones o PEP devolvió una posible coincidencia que una persona debe confirmar o descartar. Una dirección no puede verificarse con ninguna fuente. Falló una prueba de vida, o la misma cara o el mismo documento ya existen en otra cuenta. Cada uno es un tipo de trabajo distinto que requiere un tipo de criterio distinto, y mezclarlos en un montón indiferenciado es el primer error de una cola de revisión. Además, un mismo motivo puede tener un peso muy distinto: una discrepancia de nombre puede ser un cambio de apellido por matrimonio sin importancia o el primer indicio de una identidad robada, y la tarea de la cola es derivarla a quien sepa distinguirlo, en lugar de forzar un veredicto rápido en un caso que merece uno cuidadoso.

Una sola cola no basta: segmenta por motivo

Una cola única obliga a cada revisor a ser generalista y a cada caso a esperar detrás de otros que no tienen nada que ver. Segmentar por motivo resuelve ambas cosas. Una cola de posibles coincidencias de sanciones la trabajan personas formadas en cribado y resolución; una cola de calidad de documento es una comprobación visual rápida que un revisor junior despeja en segundos; una cola de cuentas duplicadas es una investigación de fraude. Cada segmento tiene su propio enrutamiento, su propia cualificación requerida y su propio objetivo de nivel de servicio, porque una foto borrosa debe resolverse en minutos, mientras que una coincidencia real de sanciones merece una resolución cuidadosa y sin prisas. La segmentación es lo que permite que rendimiento y rigor convivan en lugar de sacrificarse el uno por el otro.

Una cola de revisión no escala contratando revisores. Escala decidiendo, con acierto, qué casos nunca necesitaron uno — y asegurando que los que sí lo necesitan lleguen ya ordenados por motivo.

Acciones auditadas con motivo obligatorio

Toda decisión de un revisor —aprobar, rechazar, escalar, solicitar más documentos— debe exigir un motivo y quedar registrada. No como un texto libre añadido a posteriori, sino como una selección estructurada que indica por qué se tomó la acción, capturada en el momento en que se toma. No es burocracia: es lo que hace defendible la cola. Cuando un regulador, un auditor o un revisor posterior pregunta por qué se aprobó una cuenta pese a una alerta, la respuesta es un revisor identificado, una marca de tiempo y un motivo declarado, no un encogimiento de hombros. El registro de auditoría es de solo adición, de modo que una decisión no puede reescribirse en silencio a posteriori; las correcciones son nuevas entradas, no ediciones sobre las anteriores. En nuestro stack, esta cola y su modelo de auditoría viven en Protocore Center (/products/center), la consola de operador donde toda acción privilegiada exige un motivo y queda en un registro que no puede alterarse sin dejar rastro.

Los casos de cuatro ojos

Algunas decisiones tienen demasiadas consecuencias para recaer en una sola persona. Descartar una coincidencia real en sanciones, aprobar un perfil de alto riesgo o anular un rechazo automático deberían requerir la confirmación de un segundo revisor: maker-checker, o cuatro ojos. El primer revisor propone e indica un motivo; un segundo, con la autoridad para hacerlo, confirma o rechaza e indica el suyo. Ambas acciones quedan registradas. No es desconfianza hacia los revisores: es reconocer que las aprobaciones de mayor riesgo son justo aquellas donde un solo error sale más caro, y un segundo par de ojos es el seguro más barato contra él. El diseño de la cola debe enrutar estos casos a una resolución en dos pasos de forma automática, según el motivo, en lugar de confiar en que los revisores se acuerden. Eso sí, reserva los dos pasos a propósito para los casos de peso; aplicarlos a todo duplica el coste de toda la cola y acostumbra a los revisores a firmar la segunda vez sin mirar, lo que anula en silencio el sentido de tenerla.

Diseñar para el volumen: antigüedad, priorización y SLA

Una cola que solo crece es una cola que ha fracasado. Diseña la presión que la mantiene en movimiento. Los casos envejecen a la vista, para que nada quede olvidado; cada segmento lleva un objetivo de nivel de servicio, así que un caso con foto borrosa que incumple su SLA de minutos se hace notar de forma distinta a un caso de sanciones dentro del suyo, más largo. Priorizar es una decisión real: primero el más antiguo es justo y sencillo, pero primero el de mayor riesgo —la peor exposición potencial arriba— suele ser lo acertado, con la antigüedad como desempate para que los casos de bajo riesgo se resuelvan en vez de quedar desatendidos. La pantalla del revisor debe mostrar el siguiente caso, ya enrutado y priorizado, no una lista donde elegir — porque en una cola donde la gente escoge, los casos incómodos nunca se escogen. Una cola sin antigüedad visible se pudre en silencio: los casos difíciles se hunden mientras los fáciles circulan arriba, y la única métrica que lo habría delatado —la antigüedad del caso abierto más viejo— es justo el número que nadie mira hasta que un cliente se queja.

Medir la cola

Cuatro números dicen si el diseño funciona. La tasa de STP indica cuánto nunca necesitó a una persona; la profundidad de la cola y su tendencia, si vas al día o te estás quedando atrás; el tiempo hasta la decisión, medido por segmento frente a su SLA, si los clientes esperan demasiado para ser dados de alta; y la tasa de reapertura —decisiones revocadas después— si los revisores deciden bien o solo deprisa. Obsérvalos juntos, porque se compensan entre sí: bajar el tiempo hasta la decisión mientras sube la tasa de reapertura significa que has comprado velocidad con errores. Una cola sana es pequeña, avanza, se decide con acierto y es honesta sobre los casos que siguen abiertos.

El back office que se imagina la gente —salas llenas de personal tecleando solicitudes— es lo que resulta cuando la automatización resuelve muy poco y la cola es un montón sin distinguir. El back office que escala es lo contrario: la mayoría de las solicitudes nunca llega a una persona, las que llegan vienen ordenadas por motivo y prioridad, cada acción deja su motivo en un registro de solo adición y los cuatro ojos protegen las decisiones que lo merecen. Construye la cola para las excepciones y seguirá siendo pequeña a medida que creces. Constrúyela como el lugar donde ocurre el KYC y crecerá con cada alta que aceptes.