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

Caso sejam fornecidas transações para serem removidas, elas não serão aplicadas ao perfil unificado e seus perfis não serão deletados

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?