Saltar para o conteúdo principal
A revisão a 4 olhos acrescenta uma segunda validação independente antes de uma resolução produzir efeitos, um controlo padrão de segregação de funções para investigações de maior risco.

​
Configuração

No blueprint do maker, defina Revisão a 4 olhos como um blueprint do checker. Este campo é o que ativa a revisão a 4 olhos no blueprint do maker, não existindo um interruptor separado.

​
Como funciona

  1. Um responsável no blueprint do maker resolve um caso como habitualmente (falso positivo ou ameaça válida, com uma nota, se for exigida).
  2. Em vez de fechar o caso, o estado mantém-se como Aberto, a resolução proposta fica preparada e o caso passa para a fila do blueprint do checker. A cronologia do caso regista Submitted for approval.
  3. Um verificador analisa o separador Visão geral do caso, onde um banner de controlo duplo apresenta as ações Aprovar e Rejeitar.
  4. Aprovar aplica a resolução preparada: o caso passa para Resolvido, com a resolução e a nota originais, ficando esta registada em nome do responsável que a submeteu. A cronologia regista Approval granted e, a seguir, Resolved.
  5. Rejeitar limpa a resolução preparada e devolve o caso ao blueprint do maker. A cronologia regista Approval rejected, e o maker é notificado.
O responsável que submeteu a resolução não a pode aprovar nem rejeitar, o que é imposto pelo servidor. Se tentar fazê-lo, recebe um 403. (Aprovar ou rejeitar um caso sem resolução pendente de aprovação devolve um 409.)

​
Indicar o verificador

O responsável que resolve pode indicar o membro que deve aprovar a resolução, com o campo checker da API de resolução de casos. Só esse membro pode então aprovar ou rejeitar a resolução; qualquer outra pessoa, incluindo 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 nova revisão. Sem um verificador indicado, a resolução aguarda na fila do blueprint do checker, como descrito acima. O verificador indicado tem de ter acesso ao caso na aplicação e não pode ser o responsável que submeteu a resolução.

​
Quando as evidências mudam

Alterar a resposta a um item da lista de verificação, ou adicionar ou remover uma verificação ou transação associada, limpa a decisão pendente e devolve o caso à sua política de revisão original. A cronologia de atividade regista que é necessária uma nova decisão de revisão e preserva a proposta anterior no evento de auditoria. O revisor tem de analisar as evidências atualizadas e submeter uma nova decisão antes de um segundo responsável a poder aprovar. Repetir a mesma resposta na lista de verificação não cancela uma revisão pendente. A aprovação também verifica as evidências de origem associadas face ao que foi submetido para revisão. Um estado de verificação alterado, um campo de documento corrigido, evidências de transação alteradas ou uma fonte indisponível bloqueiam a aprovação com 409. Perder o acesso às evidências da rede global associadas através de um Fraud Check também exige uma nova revisão. Use Rejeitar para devolver o caso ao maker, analisar as evidências atualizadas e submeter uma nova decisão. Abrir o registo de origem ou adicionar uma nota interna ao caso não bloqueia, por si só, uma revisão inalterada. Se as evidências submetidas não puderem ser verificadas, é necessária uma nova revisão antes da aprovação.

​
Notas

  • As exigências de revisão são guardadas quando o caso é aberto. Passar para a fila do checker não substitui essas exigências por alterações posteriores à política.
  • Um caso só pode ter uma resolução preparada de cada vez; pedir mais informações (A aguardar utilizador) fica bloqueado enquanto uma resolução estiver pendente de aprovação.
  • A revisão a 4 olhos complementa as notas de resolução obrigatórias: ative ambas nos seus blueprints de maior risco para exigir uma justificação documentada e um segundo revisor.
Última modificação em 7 de novembro de 2026