Target Biográfico
Documentação relacionada ao Target Biográfico e seu comportamento. Essa funcionalidade está disponível apenas a partir da versão 5 do GBDS.
Comportamento
Em geração de exceção
Toda vez que uma exceção é gerada, um grupo correspondente é criado/atualizado com:
status: ANALYSIS
target: de acordo com o tipo de exceção; se há mais de uma exceção para um dado TGUID, o tipo do grupo é BIOMETRIC se houver alguma exceção BIOMETRIC
Sem prioridade
Organizações: todas as organizações de exceção apontando para o grupo e exceção com indicação de origem ENTRANT ou REFERENCE
Em cada tratamento de exceção biométrica
Caso não haja um grupo de exceção, ele será criado a partir dos TGUIDs das exceções
Definição de Target
Caso haja alguma exceção BIOMETRIC_MISMATCH, o grupo será definido como BIOMETRIC_MISMATCH
Caso todas as exceções do sejam BIOMETRIC_INCONCLUSIVE, BIOMETRIC_MISMATCH ou BIOGRAPHIC:
BIOMETRIC_MISMATCH se houver alguma exceção BIOMETRIC_MISMATCH
BIOMETRIC_INCONCLUSIVE se houver alguma exceção BIOMETRIC_INCONCLUSIVE
Caso contrário, o grupo será do tipo BIOGRAPHIC
Caso a exceção tenha um resultado final associado, no caso em que todas as exceções para TGUID forem tratadas sem CSI, a decisão do grupo mudará:
Resultado final APPROVED, decisão do grupo é alterada para APPROVED
Se o resultado final for REJECT, a decisão do grupo é alterada para REJECT
Priorização de exceção biométrica
Quando uma exceção é priorizada usando endpoint set priority, o grupo também será priorizado
Caso todas as exceções sejam despriorizadas, o grupo será despriorizado também (usando o mesmo endpoint)
Próximo grupo de exceção
Quando o próximo grupo de exceção é requisitado, ele deve ter:
status ANALYSIS
target BIOGRAPHIC, BIOMETRIC_MISMATCH ou BIOMETRIC_INCONCLUSIVE
Não estar alocado para ninguém
O grupo deve possuir uma organização dentre as organizações do usuário
Caso não tenha sido requisitada uma origem da organização, será considerado o grupo com todas as organizações
Caso a origem requisitada seja ENTRANT ou BOTH, será considerado o grupo com a organização na origem pedida.
Os grupos são ordenados por prioridade, pendência e data de criação em ordem crescente, por padrão
O usuário deve possuir permissão biográfica
Com um grupo selecionado, o usuário será alocado para esse grupo por um dado tempo, de acordo com a configuração. Se a configuração tiver valor -1 o grupo nunca será desalocado e precisará ser desalocado manualmente através do endpoint Unlock Group.
Alocação e desalocação manual
Pode ser feito a partir dos endpoints Lock group e Unlock group
Um grupo não pode ser alocado se ele já estiver alocado para outro usuário e não pode ser desalocado se não estiver alocado para o usuário em fornecido
Para cada tratamento de grupo
As validações a serem feitas são:
Usuário e permissões devem ser fornecidos, a menos que a segurança esteja ativada, nesse caso, ambos são fornecidos pelo token
Timeout é zero por padrão, quando o tratamento é final e a exceção é tratada como APPROVE, esse valor é utilizado
GGUID do grupo e o status de decisão do grupo (KEEP or REJECT) são obrigatórios
Grupo deve existir e estar em status/target ANALYSIS/BIOGRAPHIC, BIOMETRIC_MISMATCH ou BIOMETRIC_INCONCLUSIVE
Grupo deve estar alocado ao usuário
O usuário deve ter alguma organização presente no grupo
O usuário não pode ter tomado uma decisão para esse candidato anteriormente
A biometria deve estar alocada ao usuário
Caso a decisão de status seja KEEP: Cadastro - Parâmetros devem ser fornecidos com pelo menos uma chave, biográficos e labels são opcionais e todos os TGUIDs a serem armazenados devem ser de exceções do grupo, do entrante ou da referência
Atualização - os TGUIDs a serem armazenados devem ser de exceções do grupo, podem ser mantidos entrante e/ou referência.
Se todas as validações forem aprovadas, a decisão do usuário, o usuário, comentários e parâmetros serão salvos no grupo
Remocão de transações do grupo em tratamento
Para remover transações que pertencam a exceções de BIOMETRIC_MISMATCH ou BIOMETRIC_INCONCLUSIVE as transações devem ser fornecidas através de parâmetros que serão removidos usando removeTransactions nos parâmetros.
Nesse caso:
O grupo deve ser um grupo de exceção de cadastro
Não é permitido remover a transação entrante
As transações removidas devem ser do grupo de transações de referência de qualquer grupo de exceção biométrica inconclusiva ou não correspondente (mismatch)
Transações de remoção não devem conflitar com transações de permanência
Decisão pendente
Caso o usuário requisite uma rejeição de alguma transação cujas organizações não se encontram em suas organizações, o grupo é marcado com status PENDING e o tratamento do grupo é feito pelo endpoint treat pending group
Atualização de grupo de exceção
REJECT: rejeita entrante e referência e deleta as referências
KEEP: mantém apenas referência
Rejeita todas as exceções
KEEP: mantém o entrante
Rejeita todas as exceções
Deleta as referências
Reenvia a transação entrante como cadastro
KEEP: referência e entrante são mantidos
Todas as exceções são aprovadas
Grupo em tratamento pendente
Para grupos em que a decisão de tratamento está pendente, o tratamento é feito com o endpoint de treat pending group
A validações diferem do tratamento regular em:
O grupo deve estar pendente de decisão
o usuário deve ter uma organização presente em todas as transações do grupo.
Caso a transação seja rejeitada, o grupo volta para o status de ANALYSIS
Se for aceita, o tratamento será feito como descrito acima.
Prioridade
Quando um grupo é priorizado ou despriorizado, todas as exceções para o mesmo grupo são afetadas.
Atualizado
Isto foi útil?