# 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 {% hint style="info" %} 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 {% endhint %} ### 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.