1. Control de Secuencia y Calidad¶

Cada vez que GBDS recibe una nueva transacción, se realiza un control de secuencia y calidad. Esta verificación tiene como objetivo evitar que se inserten transacciones incorrectas en la base de datos.

Cualquier transacción rechazada por el control de secuencia y calidad se envía a MIR para su revisión manual.

1.1. Pasos de Verificación¶

1.1.1. Control de Calidad¶

El primer paso al recibir una nueva transacción es que GBDS realice una verificación de calidad en cada plantilla biométrica enviada.

Si la calidad de alguna plantilla no alcanza el umbral configurado [1], se envía toda la transacción a MIR para su verificación manual.

[1]	Consulte el Manual de Configuración de GBDS o comuníquese con el equipo de soporte de Griaule para obtener más información.

Cualquier problema identificado en este paso de verificación se devolverá como "Problema de Calidad" a través de la API.

1.1.2. Control de Duplicidades¶

En este paso, GBDS compara cada huella dactilar individual con las demás para verificar duplicidades.

Si se identifica alguna duplicidad, se envía la transacción a MIR para su verificación manual.

Cualquier problema identificado en este paso de verificación se devolverá como "Problema de Duplicidad" a través de la API.

1.1.3. Control de Secuencia¶

Para realizar este paso, GBDS requiere imágenes de huellas dactilares de 4 dedos (índices 940 y 941).

GBDS intentará segmentar estas imágenes y extraer un número predefinido de biometrías [2]. Luego, comparará las imágenes segmentadas con las huellas dactilares capturadas individualmente (generalmente, capturas de huellas dactilares enrolladas).

Si alguna comparación en este paso identifica una no coincidencia, GBDS intentará encontrar el índice correcto del dedo que no coincide y realizar una corrección automática.

Si se identifican problemas que GBDS no puede corregir automáticamente, o el número de correcciones automáticas requeridas es mayor que el máximo configurado [3], no se realiza ninguna corrección y se envía toda la transacción original a MIR.

Cualquier problema identificado en este paso de verificación se devolverá como "Problema de Control de Secuencia" a través de la API.

[2]	En casos de amputación o discapacidad temporal, una imagen de 4 dedos puede contener menos de 4 dedos.

[3]	Consulte el Manual de Configuración de GBDS o comuníquese con el equipo de soporte de Griaule para obtener más información.

El flujo de comparación para el control de secuencia será el siguiente:

1.1.3.1. Flujo de Comparación¶

Las imágenes de huellas dactilares individuales (enrolladas o planas) con índices entre 0 y 3 [4] se compararán con las imágenes segmentadas del índice 940.

Luego, las imágenes de huellas dactilares individuales con índices entre 6 y 9 se compararán con las imágenes segmentadas del índice 941.

[4]	Los índices para las imágenes de huellas dactilares individuales son:

Index	Finger	Index	Finger
0	Left Minimum	5	Right Thumb
1	Left Ring	6	Right Indicator
2	Left Middle	7	Right Middle
3	Left Indicator	8	Right Ring
4	Left Thumb	9	Right Minimum

1.2. Tratamiento de Anomalías¶

Para obtener más información sobre la herramienta MIR y los procesos para tratar anomalías, consulte el manual específico de MIR, como se mencionó anteriormente.

En esta sección, se detallarán los procedimientos del lado del servidor para el análisis de calidad, desde el momento en que GBDS recibe la decisión proporcionada por MIR.

1.2.1. Transacción aprobada sin cambios¶

Dada esta decisión, GBDS mantendrá la transacción original sin cambios y continuará con el procedimiento de inscripción. El GUID de transacción (TGUID) será el mismo para ambas operaciones (“QUALITY_ANALYSIS” y “ENROLL”).

El flujo de notificación será el siguiente:

1.2.1.1. Análisis de calidad - Aprobado¶

La primera notificación contendrá el estado “APROBADO” para la operación “QUALITY_ANALYSIS”.

{
    "operation": "QUALITY_ANALYSIS", "tguid": "<tguid>", "status": "APROBADO"
}

1.2.1.2. Inscripción - Inscrito¶

La segunda notificación contendrá el estado “INSCRITO” para la siguiente operación “ENROLL”.

{
    "operation": "ENROLL", "tguid": "<tguid>", "status": "INSCRITO"
}

1.2.2. Transacción aprobada con cambios¶

Dada esta decisión, GBDS mantendrá los cambios realizados por el analizador (imágenes eliminadas o editadas) y generará un nuevo TGUID para la inscripción.

El flujo de notificación para esta decisión será similar al de “Transacción aprobada sin cambios”, agregando el nuevo TGUID:

1.2.2.1. Análisis de calidad - Aprobado¶

La primera notificación contendrá el estado “APROBADO” para la operación “QUALITY_ANALYSIS” e incluirá un campo “newTransactionGUID” que denota que la transacción fue aceptada con cambios y apunta al nuevo TGUID.

{
    "newTransactionGUID": "<new_tguid>", "operation": "QUALITY_ANALYSIS", "tguid": "<original_tguid>", "status": "APROBADO"
}

1.2.2.2. Inscripción - Inscrito¶

La segunda notificación contendrá el estado “INSCRITO” para la siguiente operación “ENROLL”.

Note

La operación “ENROLL” se realizará para la transacción modificada, por lo que el TGUID mencionado será el nuevo generado por la operación “QUALITY_ANALYSIS”.

{
    "operation": "ENROLL", "tguid": "<new_tguid>", "status": "INSCRITO"
}

1.2.3. Transacción rechazada¶

Dada esta decisión, GBDS no continuará con el proceso de inscripción y “descartará” [5] toda la transacción. El TGUID será el mismo.

[5]	Se mantendrá el historial de transacciones, pero el perfil no se insertará en la base de datos como registro de persona activa.

El flujo de notificación será el siguiente:

1.2.3.1. Análisis de calidad - Rechazado¶

La primera notificación contendrá el estado “RECHAZADO” para la operación “QUALITY_ANALYSIS”.

{
    "operation": "QUALITY_ANALYSIS", "tguid": "<tguid>", "status": "RECHAZADO"
}

1.2.3.2. Inscripción - Fallido¶

El resultado de la operación “QUALITY_ANALYSIS” será seguido por una notificación de inscripción que apunte al estado “FALLIDO” para la operación “ENROLL”.

{
    "operation": "ENROLL", "tguid": "tguid", "status": "FALLIDO"
}