Reglas de decisión y umbrales
Cada comprobación produce avisos, y tú decides qué hace cada aviso - pasar, revisar o rechazar. Ese mapeo es donde vive de verdad tu apetito de riesgo.
Cada paso mapea sus avisos a una acción: pasar, revisar o rechazar. Un paso configurado para rechazar detiene el flujo de trabajo: los pasos posteriores nunca se ejecutan, y no se te factura por ellos. Eso hace que el orden de las reglas sea a la vez una decisión de riesgo y una decisión de coste.
#Dónde se toman de verdad las decisiones
Es tentador pensar en un flujo de trabajo como "las comprobaciones que ejecuto". Las comprobaciones son solo la mitad. La otra mitad, y la mitad que determina tu tasa de aprobación, es lo que están configurados para hacer los avisos de cada comprobación.
- Cada nodo de función lleva sus propios umbrales y su propia decisión.
- Una comprobación puede ser obligatoria u opcional, lo cual es en sí mismo una decisión sobre quién pasa.
- Una regla cambiada llega a las sesiones nuevas en cuanto se guarda el flujo de trabajo.
Para cada paso, cada aviso que pueda generar se mapea a una de tres acciones:
| Acción | Efecto |
|---|---|
| Aprobar (o ignorar) | El aviso queda registrado pero no cambia el resultado |
| Revisar | La sesión pasa a En revisión para que una persona decida |
| Rechazar | La sesión se rechaza y el flujo de trabajo se detiene |
Ese mapeo es tu política, expresada como configuración.
#Un rechazo detiene el flujo de trabajo
Este es el comportamiento que más sorprende a la gente, así que merece la pena decirlo explícitamente: cuando un paso rechaza, la ejecución se detiene ahí. Los pasos posteriores nunca se ejecutan.
Dos consecuencias:
- Al resultado le faltarán comprobaciones que esperabas. No fallaron, nunca se ejecutaron. Una sesión rechazada en la verificación de ID no tendrá prueba de vida, ni coincidencia facial, ni AML.
- No se te factura por ellas. La facturación es por función completada, así que un paso que nunca se ejecutó no cuesta nada.
#Usar el orden de las reglas para controlar el coste
Como un rechazo detiene el flujo, el orden de los pasos es una palanca de gasto. Poner una comprobación de riesgo barata delante de un paquete caro hace que el tráfico que de todas formas nunca iba a pasar se detenga antes de que pagues por la parte cara.
El análisis de dispositivo e IP a 0,03 $ delante de un flujo de KYC completo es el ejemplo estándar: filtra el tráfico que rechazarías de todas formas, de forma barata.
La contrapartida es la experiencia de usuario y los falsos positivos. Las señales de dispositivo e IP son las comprobaciones más ruidosas que ofrece Didit: las redes corporativas, el NAT de los operadores móviles y los navegadores en la nube ponen a usuarios genuinos detrás de direcciones compartidas. Condicionar todo un flujo a ellas bloqueará a clientes reales, así que envíalos a review en lugar de rechazar a menos que hayas medido tu propio tráfico.
#Reglas que necesitan criterio, no automatización
Algunos avisos son inequívocos y deberían rechazar: un checksum de MRZ fallido, un chip cuya firma no encadena con su emisor, una cara en tu lista de bloqueo. Esos son fallos de integridad.
Otros casi siempre son mejores como revisión:
- Coincidencias parciales de dirección en el comprobante de domicilio: los formatos varían según el país.
- Coincidencias parciales de nombre en la validación de base de datos: las fuentes autorizadas registran los nombres de forma distinta.
- Coincidencias candidatas de AML de baja confianza: los nombres comunes las generan constantemente.
- Una coincidencia facial límite: consulta puntuaciones y umbrales de coincidencia facial.
- Un aviso de cara duplicada: que es fraude para una cuenta nueva y normal para un cliente recurrente.
Y algunos son fallos de usabilidad que merecen un reintento, no un veredicto: un chip NFC no leído, una captura borrosa, un fotograma de cámara perdido.
#Políticas de edad
La edad mínima y máxima se configuran por flujo de trabajo, y la acción ante una infracción la eliges tú. MINIMUM_AGE_NOT_MET puede rechazar directamente, o dirigirse a revisión si tu política permite una excepción con evidencia. Ambas son legítimas; elige de forma deliberada.
#Reglas personalizadas sobre datos extraídos
Más allá del mapeo por aviso, puedes escribir reglas contra los datos que extrajo un paso; por ejemplo, rechazar cuando un campo extraído toma un valor concreto. Dos cosas a tener en cuenta:
- La regla solo puede actuar sobre datos que el paso realmente produjo. Si el OCR no extrajo el campo, la regla no tiene nada que evaluar.
- Una regla que rechaza sigue deteniendo el flujo de trabajo, con las mismas consecuencias que arriba.
Si estás construyendo una regla que se activa sobre una característica protegida, trátala como una cuestión legal para tu equipo de cumplimiento antes que como una cuestión de ingeniería.
#Prueba las reglas, no solo los pasos
Los pasos de un flujo de trabajo son fáciles de verificar a simple vista. Sus reglas no lo son: la única forma de saber que un aviso se dirige a donde crees es producir ese aviso.
Sandbox existe para esto. Cada escenario fuerza un aviso concreto, así que puedes confirmar la acción de cada regla de principio a fin: decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match, y así sucesivamente. Consulta probar en sandbox.
Prueba la ruta de revisión con tanto cuidado como la ruta de rechazo. Una regla que dirige a revisión solo es útil si alguien realmente trabaja la cola, y la forma de saber si tu proceso de revisión funciona es hacer pasar una sesión sintética por él antes de que un cliente real esté esperando.
#Los cambios se aplican a las sesiones nuevas
Editar un flujo de trabajo no cambia retroactivamente las sesiones ya creadas. Una sesión lleva la configuración con la que se creó, así que después de un cambio de regla, prueba con una sesión nueva en lugar de volver a comprobar una antigua.