Diseñar una política de riesgo

Qué hace

El Diseñador de políticas de flujo de trabajo le permite decidir cómo se aprueba, se rechaza o se envía a revisión manual una verificación, de forma visual y sin código. Arrastra bloques de reglas a un lienzo, define condiciones sobre las señales que genera cada verificación (puntuación de confianza, coincidencia con sanciones, comprobaciones de documentos, país del solicitante, riesgo de red, prueba de cámara en vivo y otras) y los conecta a los resultados Aprobar, Rechazar, Escalar o Requerir verificación en vivo.

Cada organización empieza con una política predeterminada integrada que reproduce exactamente la decisión estándar de puntuación de confianza de 17 factores de Certivant. Por tanto, activar la función no cambia nada hasta que decida personalizarla: sus resultados actuales se mantienen idénticos.

Antes de empezar

• Su plan debe incluir el Diseñador de políticas de flujo de trabajo (Pro o superior). Si el elemento Políticas de flujo de trabajo del menú Desarrollador muestra la insignia «Requiere Pro», pida al propietario de la cuenta que mejore el plan; consulte Facturación y créditos.
• Debe entender cómo se puntúa una verificación, para saber en qué señales escribir sus reglas. Consulte Revisar solicitudes de verificación.
• Publicar una política cambia cómo se deciden las verificaciones futuras de toda su organización. No vuelve a decidir las solicitudes anteriores.

Conceptos clave

• Nodos: los bloques del lienzo. Un nodo Inicio comienza el flujo; los nodos Condición contienen las reglas; los nodos Fin son los resultados (Aprobada / Rechazada / Escalada / Revisión manual / Requerir verificación en vivo / Traspasar a otra política). Los nodos de acción (Formulario, Validación de ID, Correo electrónico, SMS, Webhook, Conferencia en vivo) documentan los pasos de orquestación alrededor de la decisión; para ejecutar pasos, use los Flujos de trabajo de automatización.
• Condiciones: un nodo de Condición evalúa las señales de la verificación, por ejemplo overallScore >= 75, sanctions.isMatch = true, applicant.country IN ["IR","KP","SY"] o redFlags CONTAINS "network_vpn_detected". Puede combinar pruebas con Y / O / NO y anidar grupos, incluidas las condiciones encadenadas tras otras condiciones en el lienzo.
• Gana la primera coincidencia: las reglas se evalúan de arriba abajo desde el Inicio; la primera Condición cuya prueba sea verdadera aporta la decisión. Una regla final captura todo lo demás (falla de forma segura a Escalar, nunca a una aprobación silenciosa).
• Motivos: asigne a una condición un motivo (por ejemplo, «País de alto riesgo»). Se registra junto con la decisión, de modo que el revisor ve por qué se escaló la solicitud, no solo qué regla se activó.
• Versiones: cada política guardada es un borrador hasta que la publica. Al publicarla, esa versión queda congelada (es inmutable) y pasa a estar activa; la versión activa anterior de esa política se archiva. Para cambiar una política publicada, haga clic en Nueva versión; así siempre dispone de un historial completo y auditable.
• Dónde se aplica: una política publicada decide las solicitudes de todos los formularios que la fijan. Si la convierte en la política predeterminada de la organización, decidirá también el resto de solicitudes, incluidas las creadas mediante la API. Si no hace ninguna de las dos cosas, decide la política predeterminada integrada de Certivant.

Pasos

Qué activa su política

Una política de flujo de trabajo se ejecuta automáticamente: no hay ningún botón de «ejecutar» y no se activa a mano. Dos cosas la arman y la disparan:

1. Publicar la arma. Al publicar una política, esa versión pasa a estar activa (una sola versión activa por política; al publicar se archiva la anterior). Decide las solicitudes de todos los formularios que la fijan, y también todas las demás solicitudes una vez que la convierte en la predeterminada de la organización.
2. Cada nueva verificación la dispara. Cada vez que se ejecuta una verificación (un solicitante envía sus documentos, usted envía una solicitud de verificación o un revisor pulsa Volver a verificar), Certivant ejecuta la cadena completa de comprobaciones (OCR, biométricos, sanciones, fraude, comprobaciones de red y de captura, la puntuación de confianza de 17 factores) y después entrega los resultados a la política que decide. El veredicto de la política (Aprobar / Rechazar / Escalar / Requerir verificación en vivo) pasa a ser el estado final de la solicitud.

Qué política decide una solicitud, por orden:

1. la política que fija su formulario;
2. si no, la política predeterminada de su organización;
3. si no, la predeterminada integrada de Certivant.

Una política fijada o predeterminada sin versión activa (por ejemplo, si la archivó) recurre a la predeterminada integrada, nunca a otra política.

flowchart LR
    A[Applicant submits<br/>verification] --> B[Checks run:<br/>OCR · biometrics ·<br/>sanctions · fraud]
    B --> C[17-factor<br/>trust score]
    C --> D{Active policy<br/>evaluates the<br/>score + signals}
    D -->|first matching rule| E[Approve]
    D --> F[Reject]
    D --> G[Escalate to<br/>manual review]

Cómo cambia sus verificaciones

Tras publicar, cada nueva verificación la decide su política activa en lugar de la predeterminada integrada. Para cada solicitud, Certivant registra:

• el id, el nombre y la versión de la política que la decidió, y
• la lista de reglas que se activaron,

tanto en el registro de auditoría de la solicitud como en la carga útil del webhook (data.policy en kyc.request.approved / rejected / escalated). Así, sus sistemas posteriores pueden ver qué política y qué reglas impulsaron cada decisión. Consulte Webhooks.

Cuando una salvaguarda posterior cambia el resultado de la política (una solicitud KYB que todavía espera su comprobación en el registro, o una solicitud en modo de prueba), el registro de auditoría recoge esa anulación y el estado final, de modo que el registro nunca muestra una decisión que no llegó a prevalecer.

Requerir verificación en vivo

Elija Requerir verificación en vivo como resultado de un nodo Fin para enviar una solicitud a una videollamada en lugar de decidirla solo con los documentos; por ejemplo, cuando la puntuación está en el límite, el solicitante usa una VPN o no se pudo demostrar que la selfie proviene de una cámara en vivo:

overallScore >= 60 AND overallScore < 80 → Require live verification
network.vpn = true OR capture.tokenMismatch = true → Require live verification

La solicitud pasa a Escalada, y su página muestra un aviso de Verificación de identidad en vivo requerida con el motivo de la regla, para que su equipo sepa que debe reservar la llamada. La carga útil del webhook incluye data.policy.decision = "live_verification" y liveVerificationRequired: true.

Para reservar la llamada automáticamente, añada un Flujo de trabajo de automatización con el disparador Verificación en vivo requerida y la acción Programar una verificación de identidad en vivo. Cuando el anfitrión registra una decisión durante la llamada, la solicitud se aprueba o se rechaza y se disparan los eventos habituales de aprobación o rechazo. Si se vuelve a verificar después, la política puede leer el resultado de la llamada (por ejemplo, liveVerification.hostDecision = "approved"), de modo que una regla puede aprobar una solicitud que superó su comprobación en vivo.

Señales que puede probar

Además de la puntuación de confianza y de los resultados por comprobación (checks.*, sanctions.*, document.*, applicant.*), una condición puede leer:

Un campo que la solicitud no tiene (sin llamada celebrada, sin código de barras leído…) nunca coincide, ni siquiera con !=, NOT IN o NOT CONTAINS. Así, document.issuingCountry != "US" es falso cuando no se leyó ningún documento, en lugar de ser verdadero de forma silenciosa.

Opciones y campos

Solución de problemas

No veo «Políticas de flujo de trabajo» en el menú

Está en el menú Desarrollador y es una función Pro. Si el elemento Políticas de flujo de trabajo muestra la insignia «Requiere Pro», su plan no la incluye; pida a su propietario que mejore el plan en Facturación y créditos. Si el menú Desarrollador no aparece en absoluto, es posible que no sea administrador ni propietario; si el elemento simplemente desapareció, actualice la página: la comprobación del plan se guarda en caché durante unos minutos.

No puedo editar una política: los campos están bloqueados

Las versiones publicadas son inmutables por diseño. Abra la versión y haga clic en Nueva versión en la barra: copia la política en el siguiente borrador editable. Haga los cambios y publique; la versión anterior seguirá decidiendo hasta que lo haga.

El botón Simular está desactivado

Simular necesita que la política se haya guardado al menos una vez. Haga clic en Guardar borrador; a partir de ahí, Simular ejecuta lo que hay en el lienzo, incluidos los cambios sin guardar.

Mi política publicada no decide nada

Una política publicada solo decide las solicitudes de los formularios que la fijan. Fíjela en el formulario (ajustes del formulario → Política de decisión), o haga clic en Usar para todas las solicitudes en el editor para convertirla en la predeterminada de la organización.

Una solicitud se escaló con «Verificación de identidad en vivo requerida»

Su política coincidió con una regla de Requerir verificación en vivo; el aviso de la solicitud muestra el motivo de la regla. Reserve una llamada en vivo desde la página de la solicitud, o automatícelo con un flujo de trabajo (consulte Requerir verificación en vivo).

Una condición muestra una insignia roja de «no válida»

La expresión no se pudo analizar. Abra la condición, revise el nombre del campo y el operador, y confirme que los valores de lista están separados por comas. La pestaña DSL sin procesar muestra el mensaje exacto del analizador.

¿Cómo disparo mi flujo de trabajo / cuándo se ejecuta?

No se dispara manualmente. Una vez que está publicada y fijada en un formulario (o convertida en la predeterminada de la organización), se ejecuta automáticamente en cada nueva verificación que cubre: cuando un solicitante envía sus documentos, cuando usted envía una solicitud de verificación o cuando un revisor pulsa Volver a verificar. Consulte Qué activa su política.

Publiqué, pero no pasa nada

Hay tres causas habituales. Primero, una política solo decide las verificaciones que se ejecutan después de activarse; las solicitudes existentes y ya completadas no cambian (consulte más abajo). Inicie una nueva verificación (o use Volver a verificar en una existente) para ver cómo la decide su política. Segundo, confirme que la versión que editó aparece con el estado activa en la tabla del panel: guardar un borrador no la activa; debe publicarla. Tercero, compruebe que el formulario de la solicitud fija la política, o que la política es la predeterminada de la organización.

Publicar no cambió nada en una solicitud en curso

Las políticas solo deciden verificaciones nuevas. Una solicitud que ya se envió conserva la decisión de la política activa en ese momento. Vuelva a ejecutarla solo si pretende volver a decidirla: abra la solicitud y use Volver a verificar.

Historial de versiones, restauración y pruebas A/B

Cada guardado de una política publicada inicia una nueva versión en borrador; Publicar la congela como versión inmutable y archiva la que sustituye. Cada decisión registra el id y la versión exactos de la política que la tomó (en la solicitud, en el registro de auditoría y en el bloque policy de la carga útil del webhook), de modo que siempre puede ver qué versión decidió una verificación.

Haga clic en Versiones y prueba A/B en la cabecera del editor para:

• Ver todas las versiones de la política (borrador, activa y archivadas) y abrir cualquiera de ellas en modo de solo lectura.
• Restaurar como nuevo borrador: copia una versión anterior en un nuevo borrador con el mismo nombre. Publíquelo cuando quiera que esté en vivo. Nunca se modifica nada que ya estuviera publicado.
• Ejecutar una prueba A/B: compare la versión activa (variante A) con un retador (variante B, un borrador o una versión anterior de la misma política). Elija el porcentaje de verificaciones nuevas que van a B (0–100 %); el resto sigue en A. La división es automática y estable: una verificación siempre cae en la misma variante, incluso si se vuelve a ejecutar.

Mientras la prueba está en curso, el borrador retador está congelado (editarlo invalidaría la comparación). La tabla de Resultados muestra, por variante, cuántas verificaciones se asignaron, el porcentaje aprobado, rechazado y escalado, y cuántas llegaron a una decisión. La comparación de tasas de aprobación solo indica que la diferencia es «significativa» cuando cada variante tiene al menos 30 verificaciones decididas. Para adoptar B, publique el retador: la prueba termina automáticamente. Para abandonarla, haga clic en Detener prueba; cada nueva verificación vuelve a la versión activa.

Relacionado

• Revisar solicitudes de verificación: las señales que prueban sus reglas proceden de aquí.
• Webhooks: el bloque policy añadido a los eventos de decisión.
• Flujos de trabajo de automatización: reaccione a la decisión: reserve la llamada en vivo, notifique, enrute.
• Verificación de identidad en vivo: la videollamada que pide una regla de Requerir verificación en vivo.
• Facturación y créditos: mejore el plan para desbloquear el Diseñador de políticas de flujo de trabajo.