Target Biográfico
Documentación relacionada con el Target Biográfico y su comportamiento. Esta funcionalidad está disponible solo a partir de la versión 5 del GBDS.
Comportamiento
En generación de excepción
Cada vez que se genera una excepción, se crea/actualiza un grupo correspondiente con:
estado: ANALYSIS
target: de acuerdo con el tipo de excepción; si hay más de una excepción para un determinado TGUID, el tipo del grupo es BIOMETRIC si existe alguna excepción BIOMETRIC
Sin prioridad
Organizaciones: todas las organizaciones de excepción que apuntan al grupo y excepción con indicación de origen ENTRANT o REFERENCE
En cada tratamiento de excepción biométrica
Si no existe un grupo de excepción, se creará a partir de los TGUIDs de las excepciones
Definición de Target
Si existe alguna excepción BIOMETRIC_MISMATCH, el grupo será definido como BIOMETRIC_MISMATCH
Si todas las excepciones son BIOMETRIC_INCONCLUSIVE, BIOMETRIC_MISMATCH o BIOGRAPHIC:
BIOMETRIC_MISMATCH si existe alguna excepción BIOMETRIC_MISMATCH
BIOMETRIC_INCONCLUSIVE si existe alguna excepción BIOMETRIC_INCONCLUSIVE
De lo contrario, el grupo será del tipo BIOGRAPHIC
Si la excepción tiene un resultado final asociado, en el caso en que todas las excepciones para TGUID sean tratadas sin CSI, la decisión del grupo cambiará:
Resultado final APPROVED, la decisión del grupo se cambia a APPROVED
Si el resultado final es REJECT, la decisión del grupo se cambia a REJECT
Priorización de excepción biométrica
Cuando una excepción es priorizada usando el endpoint set priority, el grupo también será priorizado
Si todas las excepciones son despriorizadas, el grupo también será despriorizado (usando el mismo endpoint)
Próximo grupo de excepción
Cuando se solicita el próximo grupo de excepción, debe tener:
estado ANALYSIS
target BIOGRAPHIC, BIOMETRIC_MISMATCH o BIOMETRIC_INCONCLUSIVE
No estar asignado a nadie
El grupo debe poseer una organización entre las organizaciones del usuario
Si no se ha solicitado un origen de la organización, se considerará el grupo con todas las organizaciones
Si el origen solicitado es ENTRANT o BOTH, se considerará el grupo con la organización en el origen pedido.
Los grupos se ordenan por prioridad, pendiente y fecha de creación en orden ascendente, por defecto
El usuario debe poseer permiso biográfico
Con un grupo seleccionado, el usuario será asignado a ese grupo por un tiempo determinado, de acuerdo con la configuración. Si la configuración tiene valor -1 el grupo nunca será desasignado y deberá ser desasignado manualmente a través del endpoint Unlock Group.
Asignación y desasignación manual
Puede hacerse desde los endpoints Lock group y Unlock group
Un grupo no puede ser asignado si ya está asignado a otro usuario y no puede ser desasignado si no está asignado al usuario proporcionado
Para cada tratamiento de grupo
Las validaciones a realizar son:
Usuario y permisos deben ser proporcionados, a menos que la seguridad esté activada, en ese caso, ambos son proporcionados por el token
El timeout es cero por defecto, cuando el tratamiento está finalizado y la excepción es tratada como APPROVE, ese valor es utilizado
GGUID del grupo y el estado de decisión del grupo (KEEP or REJECT) son obligatorios
El grupo debe existir y estar en estado/target ANALYSIS/BIOGRAPHIC, BIOMETRIC_MISMATCH o BIOMETRIC_INCONCLUSIVE
El grupo debe estar asignado al usuario
El usuario debe tener alguna organización presente en el grupo
El usuario no puede haber tomado una decisión para ese candidato anteriormente
La biometría debe estar asignada al usuario
Si la decisión de estado es KEEP: Registro - Deben proporcionarse parámetros con al menos una clave, biográficos y labels son opcionales y todos los TGUIDs a almacenar deben ser de excepciones del grupo, del entrante o de la referencia
Actualización - los TGUIDs a almacenar deben ser de excepciones del grupo, pueden mantenerse entrante y/o referencia.
Si todas las validaciones son aprobadas, la decisión del usuario, el usuario, comentarios y parámetros serán guardados en el grupo
Eliminación de transacciones del grupo en tratamiento
Para eliminar transacciones que pertenezcan a excepciones de BIOMETRIC_MISMATCH o BIOMETRIC_INCONCLUSIVE las transacciones deben ser proporcionadas mediante parámetros que serán removidos usando removeTransactions en los parámetros.
En ese caso:
El grupo debe ser un grupo de excepción de registro
No está permitido eliminar la transacción entrante
Las transacciones eliminadas deben ser del grupo de transacciones de referencia de cualquier grupo de excepción biométrica inconclusa o no coincidente (mismatch)
Las transacciones a eliminar no deben entrar en conflicto con las transacciones a permanecer
Decisión pendiente
Si el usuario solicita el rechazo de alguna transacción cuyas organizaciones no se encuentran en sus organizaciones, el grupo se marca con estado PENDING y el tratamiento del grupo se realiza mediante el endpoint treat pending group
Actualización de grupo de excepción
REJECT: rechaza entrante y referencia y elimina las referencias
KEEP: mantiene solo referencia
Rechaza todas las excepciones
KEEP: mantiene el entrante
Rechaza todas las excepciones
Elimina las referencias
Reenvía la transacción entrante como registro
KEEP: referencia y entrante se mantienen
Todas las excepciones son aprobadas
Grupo en tratamiento pendiente
Para grupos en los que la decisión de tratamiento está pendiente, el tratamiento se realiza con el endpoint de treat pending group
Las validaciones difieren del tratamiento regular en:
El grupo debe estar pendiente de decisión
el usuario debe tener una organización presente en todas las transacciones del grupo.
Si la transacción es rechazada, el grupo vuelve al estado ANALYSIS
Si es aceptada, el tratamiento se realizará como se describió arriba.
Prioridad
Cuando un grupo es priorizado o despriorizado, todas las excepciones para ese mismo grupo se ven afectadas.
Última actualización
¿Te fue útil?