Saltar al contenido principal

Descripción general

Las advertencias del informe de verificación de identidad señalan cada condición que Didit observó al leer y validar el documento. Se incluyen en el array warnings[] de cada elemento de id_verifications[] (consulta Informe de verificación de identidad), con la estructura descrita en Modelos de datos: objeto Warning: feature, risk, additional_data, log_type, short_description, long_description, node_id. Cada advertencia tiene tres capas:
  1. El código risk: un identificador estable que puedes comprobar en tu código.
  2. El log_type: se deriva de la acción que tu configuración asigna al riesgo en el momento de la evaluación: Rechazar → error, Revisión → warning, cualquier otra → information.
  3. El impacto en la decisión: lo determinan los grupos de riesgo configurables del flujo de verificación (workflow). El mismo código risk puede asignarse a Aprobar, Revisión o Rechazar según cómo esté configurada tu aplicación.

Condiciones de rechazo automático

En los flujos, los siguientes riesgos siempre fuerzan el informe de identidad (y la sesión) a Declined. No se pueden configurar: En la API de OCR independiente, el conjunto de rechazo incondicional es DOCUMENT_EXPIRED, MINIMUM_AGE_NOT_MET, PORTRAIT_IMAGE_NOT_DETECTED, SCREEN_CAPTURE_DETECTED, PRINTED_COPY_DETECTED, PORTRAIT_MANIPULATION_DETECTED y PUBLIC_DOCUMENT_IMAGE_DETECTED. En los flujos, la edad mínima es configurable (Rechazar por defecto) y los tres riesgos de prueba de vida del documento dependen de umbrales (ver más abajo). Los riesgos configurables de esa API admiten DECLINE o NO_ACTION en lugar de un veredicto de Revisión, como parámetros de la solicitud. El único resultado de Revisión que puede devolver no es configurable: cuando una comprobación de prueba de vida del documento solicitada no produce una puntuación utilizable, la respuesta es In Review con una advertencia DOCUMENT_LIVENESS_NOT_COMPUTED (consulta Prueba de vida del documento).

Configuración de verificación ajustable

En la consola de Didit, los demás riesgos de identidad se agrupan en ajustes que puedes dirigir a Aprobar, Revisión o Rechazar (por flujo y, en los flujos de grafo, por nodo): Los riesgos de duplicado y de lista de bloqueo de la captura silenciosa provienen de la Búsqueda facial sobre la selfie tomada durante la captura del documento. La búsqueda se ejecuta mientras Búsqueda facial con captura silenciosa (document_selfie_face_search_enabled) está activada, que es el valor predeterminado, y la Búsqueda facial no está desactivada en el paso de Prueba de vida; de lo contrario, no se genera ninguno de estos seis riesgos. Dos familias de riesgos de identidad están basadas en umbrales en lugar de usar los selectores Aprobar/Revisión/Rechazar:
  • Prueba de vida del documento: SCREEN_CAPTURE_DETECTED, PRINTED_COPY_DETECTED, PORTRAIT_MANIPULATION_DETECTED. Cada tipo de fraude tiene sus propios umbrales de rechazo y de revisión: una puntuación por debajo del umbral de rechazo → error + Rechazado; por debajo del umbral de revisión → warning + En revisión; en cualquier otro caso, information.
  • Coincidencia facial entre cámaras: LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY, regida por document_selfie_portrait_match_decline_threshold / document_selfie_portrait_match_review_threshold.

Configurar los umbrales de prueba de vida del documento

En el editor de flujos, estos umbrales se encuentran en la pestaña Falsificación del paso de Verificación de identidad, con una tarjeta por tipo de fraude: Sustitución del retrato, Copia impresa y Captura de pantalla. Cada comprobación asigna al documento una puntuación de 0 a 100 según lo auténtico que parezca. Una puntuación más alta significa que es más probable que el documento sea auténtico. Los dos valores de una tarjeta dividen esa escala en tres franjas: Subir cualquiera de los dos valores hace la comprobación más estricta: más sesiones caen en la franja de resultado más estricto correspondiente. Bajar un valor deja pasar más sesiones. En el editor, el valor de Rechazar no puede superar el valor de Revisión. A través de la API, un valor de Rechazar superior al de Revisión elimina la franja En revisión. Valores predeterminados de la plataforma, que se usan cuando un flujo no define un valor: Parte de los valores predeterminados y cambia un valor cada vez. Cada tarjeta muestra su valor predeterminado y un botón Restablecer valores predeterminados, para que siempre puedas volver a él. El editor también te advierte sobre estas configuraciones:
  • Revisión en 100. Solo una puntuación perfecta supera la comprobación, así que casi todas las sesiones pasan a En revisión o se rechazan.
  • Rechazar en 100. Solo una puntuación perfecta evita el rechazo, así que casi todas las sesiones se rechazan.
  • Ambos valores en 0. Nunca se marca ninguna puntuación, así que la comprobación queda desactivada en la práctica.
Asignar el mismo número a ambos valores elimina la franja En revisión: una puntuación inferior a ese número se rechaza y cualquier otra supera la comprobación. Cuando tanto Copia impresa como Captura de pantalla marcarían el mismo documento, solo se informa de SCREEN_CAPTURE_DETECTED. La coincidencia facial entre cámaras sigue la misma lógica con una diferencia en el límite: una puntuación igual a su umbral de revisión también pasa a En revisión. Cuatro riesgos de la verificación de identidad no son configurables ni dependen de un umbral. POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST siempre se envía a Revisión: una selfie parecida a un rostro de la lista de bloqueo, sin llegar a ser una coincidencia confirmada, debe valorarla una persona, nunca se rechaza automáticamente y nunca se ignora. BARCODE_SIGNATURE_INVALID siempre se envía a Revisión. Solo se activa cuando un código de barras lleva una firma de la autoridad emisora que no supera la verificación criptográfica, así que no existe ninguna configuración en la que se ignore una falsificación demostrada. DOCUMENT_BACK_SIDE_NOT_AVAILABLE siempre es información y nunca afecta a la decisión: indica una limitación del catálogo de documentos de Didit, no una propiedad del documento presentado, así que no existe ninguna configuración en la que pueda rechazar a un titular legítimo o enviarlo a revisión. FRONT_CAMERA_CAPTURED_DOCUMENT siempre se envía a Revisión. Solo se activa cuando el fotograma de la cámara frontal tomado mientras se escanea el documento muestra un documento de identidad y ninguna persona, de modo que una captura que no dice nada sobre quién sostenía el documento siempre se somete a revisión humana. Se comprueba siempre que está activada la coincidencia entre la selfie y la captura del documento (is_document_selfie_portrait_match_enabled).

Advertencias generadas

Comprobado con collect_ocr_logs, el flujo de captura de documentos y process_ocr_logs_and_get_status. Las descripciones breves que aparecen a continuación son las cadenas short_description exactas que devuelve la API.

Reconocimiento y calidad del documento

El flujo de captura también puede rechazar una subida con los códigos de respuesta IMAGE_RESOLUTION_TOO_LOW, DOCUMENT_NOT_FULLY_VISIBLE, IMAGE_QUALITY_TOO_LOW y DOCUMENT_OCCLUSION_DETECTED (se considera que un dedo o un objeto tapa físicamente el texto impreso). Cada uno solicita una nueva captura en el SDK y queda registrado en el informe como un riesgo propio, gestionado según la configuración de Image Quality; DOCUMENT_OCCLUSION_DETECTED e IMAGE_QUALITY_TOO_LOW comparten una misma acción. Describen la captura: una nueva captura exitosa elimina la advertencia. Si un campo tapado debe afectar a la decisión lo determina por separado CRITICAL_FIELD_OCCLUSION_DETECTED, del lado de la integridad (ver más abajo), que se genera en el momento de la decisión y tiene Review por defecto.
Si tu flujo basa la identidad en la coincidencia facial y no en la foto del documento, considera asignar Decline a Document Without Portrait; de lo contrario, una familia de documentos sin foto llega a la coincidencia facial sin nada con qué comparar.

Extracción de campos

MRZ, QR, código de barras

Los tres riesgos de MRZ se omiten para los tipos de documento cuya MRZ se sabe que no es fiable.
La verificación de firma de códigos de barras cubre actualmente los documentos nacionales de identidad franceses, cuyo código de barras 2D-Doc de ANTS está firmado por la autoridad emisora. BARCODE_SIGNATURE_INVALID solo se genera cuando la propia comprobación de la firma rechaza el payload. Un código de barras sin firma, uno firmado por una autoridad que aún no está en el almacén de confianza de Didit o uno cuya firma no se puede decodificar se trata como datos no autenticados y se valida con la MRZ y el texto impreso como hasta ahora, sin generar este riesgo.Los códigos de barras de las licencias de conducir de EE. UU. y Canadá (AAMVA) no se verifican criptográficamente: allí la firma digital es opcional y depende de cada jurisdicción, y ninguna jurisdicción publica claves de verificación, así que Didit solo detecta y registra si un payload contiene una firma; la firma en sí nunca se comprueba. Hoy en día, los fallos de firma AAMVA no son una señal de riesgo. Un payload AAMVA manipulado solo aparece como BARCODE_VALIDATION_FAILED, y únicamente si la manipulación también hace que el código de barras no coincida con la MRZ o con los datos impresos/OCR: una firma falsificada en un payload por lo demás coherente internamente pasa sin ninguna señal.Nunca se pide al usuario que repita la captura ante BARCODE_SIGNATURE_INVALID: una firma que no coincide con el payload no se puede corregir tomando una foto mejor.

Coincidencia de identidad

Prueba de vida del documento (manipulación)

En los flujos se rige por umbrales para cada tipo de fraude. En la API de OCR independiente, estos tres riesgos provocan el rechazo sin condiciones, y una comprobación solicitada que no produce una puntuación utilizable devuelve In Review en lugar de aprobar. Las puntuaciones en sí aparecen en todos los informes V3 como document_liveness, incluso cuando no se generó ninguna advertencia, de modo que un documento aprobado puede seguir auditándose.

Integridad del canal de captura

El log_type refleja la acción configurada: error para Rechazar, warning para Revisión y information para Sin acción. Acción recomendada: trata una sesión rechazada como una captura inyectada y pide a la persona que vuelva a intentarlo en un dispositivo físico con su cámara integrada. Las señales que puede producir una persona real nunca generan INJECTION_ATTACK_DETECTED y se quedan como informativas. Las aplicaciones que retransmiten una cámara real, como un teléfono usado como webcam o una capa de efectos sobre una webcam real, no se notifican como ataques de inyección. Esto es detección de ataques de inyección, que es distinta de la detección de ataques de presentación (una falsificación presentada ante una cámara real).

Imágenes públicas conocidas de documentos

Discrepancias con los datos esperados

Cuando pasas expected_details a una sesión, Didit genera una advertencia de discrepancia por cada campo que no coincide. Una única agrupación (expected_details_mismatch_action, Revisión por defecto) controla el enrutamiento de todas ellas: Cada advertencia de discrepancia incluye los valores esperados y extraídos en additional_data.

Edad

Dirección

Coincidencias de documentos entre sesiones

Además de las advertencias anteriores, el informe de ID V3 incluye un array matches[]: hasta 5 documentos más de tu aplicación con la misma fecha de nacimiento, el mismo país emisor y un nombre completo muy similar (los documentos en la lista de bloqueo exigen además una coincidencia exacta del número de documento), excluidas las sesiones que pertenecen al mismo usuario. Los documentos añadidos a tu lista de bloqueo aparecen con is_blocklisted: true. Los documentos de tu lista de permitidos siguen apareciendo en las coincidencias, pero se omite la acción para usuarios duplicados. Cada coincidencia incluye session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted, api_service y una front_image_url firmada.

Ejemplos

Advertencia configurable con su enrutamiento por defecto (informativa)

Rechazo automático por documento expirado

Discrepancia entre los datos esperados y el payload

Tipos de advertencia

A cada riesgo se le asigna una gravedad según la configuración de tu aplicación. Las tres gravedades son:

Relacionado

Última modificación el 1 de noviembre de 2026