Pular para o conteúdo principal
A revisão de quatro olhos adiciona uma segunda aprovação independente antes que uma resolução entre em vigor. É um controle padrão de segregação de funções para investigações de maior risco.

​
Como configurar

No blueprint do maker, defina 4-eyes review como um checker blueprint. É ao preencher esse campo que a revisão a 4 olhos é ativada no blueprint do maker; não há um controle separado.

​
Como funciona

  1. Um analista no blueprint do maker resolve um caso normalmente (falso positivo ou ameaça válida, mais uma nota, se exigida).
  2. Em vez de ser encerrado, o caso permanece com o status Aberto, a resolução proposta fica pendente e o caso vai para a fila do blueprint do checker. A linha do tempo do caso registra Submitted for approval.
  3. Um checker analisa a aba de visão geral do caso, onde um banner de controle duplo exibe as ações Aprovar e Rejeitar.
  4. Aprovar aplica a resolução pendente: o caso passa para Resolvido com a resolução e a nota originais, atribuídas ao analista que as enviou. A linha do tempo registra Approval granted e depois Resolved.
  5. Rejeitar descarta a resolução pendente e devolve o caso ao blueprint do maker. A linha do tempo registra Approval rejected, e o maker é notificado.
O analista que enviou a resolução não pode aprová-la nem rejeitá-la, e essa restrição é aplicada no servidor. Qualquer tentativa retorna um 403. (Aprovar ou rejeitar um caso sem resolução pendente de aprovação retorna um 409.)

​
Como indicar o checker

O analista que resolve o caso pode indicar o membro que deve aprovar a resolução, usando o campo checker da API de resolução de casos. A partir daí, somente esse membro pode aprová-la ou rejeitá-la; qualquer outra pessoa, inclusive uma chave de API, recebe um 403. O campo checker do caso mostra o membro indicado até que a resolução seja aprovada, rejeitada ou devolvida para uma nova revisão. Sem um checker indicado, a resolução aguarda na fila do blueprint do checker, conforme descrito acima. O checker indicado precisa ter acesso a casos na aplicação e não pode ser o analista que enviou a resolução.

​
Quando as evidências mudam

Alterar uma resposta do checklist ou adicionar ou remover uma verificação ou transação vinculada descarta a decisão pendente e devolve o caso à sua política de revisão original. A linha do tempo de atividades registra que uma nova decisão de revisão é necessária e preserva a proposta anterior no evento de auditoria. O revisor precisa examinar as evidências atualizadas e enviar uma nova decisão antes que um segundo responsável possa aprová-la. Repetir a mesma resposta do checklist não cancela uma revisão pendente. A aprovação também compara as evidências de origem vinculadas com o que foi enviado para revisão. Um status de verificação alterado, um campo de documento corrigido, evidências de transação alteradas ou uma origem indisponível bloqueiam a aprovação com 409. Perder o acesso a evidências da rede global vinculadas por meio de um Fraud Check também exige uma nova revisão. Use Reject para devolver o caso ao maker, analisar as evidências atualizadas e enviar uma nova decisão. Abrir o registro de origem ou adicionar uma nota interna ao caso não bloqueia, por si só, uma revisão que não foi alterada. Se não for possível verificar as evidências enviadas, uma nova revisão será necessária antes da aprovação.

​
Observações

  • Os requisitos de revisão são salvos quando o caso é aberto. A entrada na fila do checker não substitui esses requisitos por edições posteriores da política.
  • Um caso só pode ter uma resolução pendente por vez; solicitar mais informações (Aguardando usuário) fica bloqueado enquanto houver uma resolução pendente de aprovação.
  • A revisão a quatro olhos funciona em conjunto com as notas de resolução obrigatórias: ative as duas nos seus blueprints de maior risco para exigir tanto uma justificativa documentada quanto um segundo revisor.
Última modificação em 1 de novembro de 2026