# Regras de decisão e limiares

Source: https://help.didit.me/pt-BR/workflows/decision-rules
Updated: 2026-10-12

Toda verificação produz avisos, e você decide o que cada aviso faz - aprovar, revisar ou recusar. Esse mapeamento é onde o seu apetite ao risco realmente vive.

Cada etapa mapeia seus **avisos** para uma ação: aprovar, revisar ou recusar. Uma
etapa configurada para recusar **interrompe o fluxo de trabalho** - as etapas
seguintes nunca rodam, e você não é cobrado por elas. Isso faz da ordem das regras
tanto uma decisão de risco quanto uma decisão de custo.

[Video: Fluxos condicionais: direcione usuários pela pontuação de risco AML - Didit Academy](https://www.youtube.com/watch?v=Qp3qzFDvTC8&t=91)

## Onde as decisões realmente são tomadas

É tentador pensar em um fluxo de trabalho como "as verificações que eu executo". As verificações são só metade disso. A outra metade - e a metade que determina sua taxa de aprovação - é o que os **avisos** de cada verificação estão configurados para fazer.

![O construtor de fluxos de trabalho da Didit com nós de recursos e o botão Publish](https://help.didit.me/screenshots/workflow-builder-light.webp)

*Cada nó decide o seu próprio resultado; o fluxo de trabalho decide o que isso significa.*

Para cada etapa, cada aviso que ela pode gerar é mapeado para uma de três ações:

| Ação | Efeito |
|---|---|
| **Approve** (ou ignorar) | O aviso é registrado, mas não muda o resultado |
| **Review** | A sessão vai para In Review para uma pessoa decidir |
| **Decline** | A sessão é recusada e o fluxo de trabalho para |

Esse mapeamento é a sua política, expressa em configuração.

## Uma recusa interrompe o fluxo de trabalho

Esse é o comportamento que mais surpreende as pessoas, então vale a pena ser explícito: quando uma etapa recusa, a execução para ali. As etapas depois dela **nunca rodam**.

Duas consequências:

1. **O resultado vai ter verificações faltando que você esperava.** Elas não falharam - simplesmente nunca foram executadas. Uma sessão recusada na verificação de ID não vai ter liveness, nem reconhecimento facial, nem AML.
2. **Você não é cobrado por elas.** A cobrança é por recurso concluído, então uma etapa que nunca rodou não custa nada.

## Usando a ordem das regras para controlar custo

Como uma recusa interrompe o fluxo, a ordem das etapas é uma alavanca de gasto. Colocar uma verificação de risco barata na frente de um pacote caro faz com que o tráfego que nunca ia passar pare antes de você pagar pela parte cara.

Análise de dispositivo e IP a US$ 0,03 na frente de um fluxo completo de KYC é o exemplo padrão: filtra, de forma barata, o tráfego que você rejeitaria de qualquer forma.

> **Warning:** O trade-off é a experiência do usuário e os falsos positivos. Os sinais de
> dispositivo e IP são as verificações mais ruidosas que a Didit oferece - redes
> corporativas, NAT de operadora e navegadores em nuvem colocam usuários legítimos
> atrás de endereços compartilhados. Bloquear um fluxo inteiro com base neles vai
> barrar clientes reais, então direcione-os para **revisão** em vez de recusa, a
> menos que você já tenha medido o seu próprio tráfego.

## Regras que exigem julgamento, não automação

Alguns avisos são inequívocos e devem recusar: um checksum de MRZ que falhou, um chip cuja assinatura não encadeia até o emissor, um rosto na sua blocklist. Essas são falhas de integridade.

Outros quase sempre funcionam melhor como revisão:

- Correspondências parciais de endereço no comprovante de endereço - os formatos variam por país.
- Correspondências parciais de nome na validação de banco de dados - fontes oficiais registram nomes de formas diferentes.
- Hits de baixa confiança em candidatos de AML - nomes comuns geram esses hits o tempo todo.
- Um reconhecimento facial no limite - veja [pontuações e limiares de reconhecimento facial](https://help.didit.me/pt-BR/liveness-biometrics/face-match-thresholds).
- Um sinal de rosto duplicado - que é fraude para uma conta nova e normal para um cliente recorrente.

E alguns são falhas de usabilidade que merecem uma **nova tentativa**, não um veredito: um chip NFC não lido, uma captura borrada, um frame de câmera perdido.

## Políticas de idade

Idade mínima e máxima são configuradas por fluxo de trabalho, e a ação em caso de violação é sua para escolher. `MINIMUM_AGE_NOT_MET` pode recusar diretamente, ou direcionar para revisão se a sua política permitir uma exceção com evidências. Ambas são legítimas; escolha de forma deliberada.

## Regras personalizadas sobre dados extraídos

Além do mapeamento por aviso, você pode escrever regras contra os dados que uma etapa extraiu - por exemplo, recusando quando um campo extraído assume um determinado valor. Duas coisas para ter em mente:

- A regra só pode agir sobre dados que a etapa realmente produziu. Se o OCR não extraiu o campo, a regra não tem nada para avaliar.
- Uma regra que recusa ainda interrompe o fluxo de trabalho, com as mesmas consequências descritas acima.

Se você está construindo uma regra que se baseia em uma característica protegida, trate isso como uma questão jurídica para o seu time de compliance antes de ser uma questão de engenharia.

## Teste as regras, não só as etapas

As etapas de um fluxo de trabalho são fáceis de verificar visualmente. As regras não são - a única forma de saber se um aviso é direcionado para onde você pensa é produzir aquele aviso.

O sandbox existe para isso. Cada cenário força um aviso específico, então você pode confirmar a ação de cada regra de ponta a ponta: `decline_document_expired`, `review_face_match_borderline`, `decline_aml_hit`, `review_poa_partial_match`, e assim por diante. Veja [testes no sandbox](https://help.didit.me/pt-BR/getting-started/sandbox-and-testing).

> **Tip:** Teste o caminho de **revisão** com o mesmo cuidado que o caminho de recusa. Uma
> regra que direciona para revisão só é útil se alguém realmente trabalhar a fila, e
> a forma de descobrir se o seu processo de revisão funciona é colocar uma sessão
> sintética por ele antes de um cliente real estar esperando.

## As mudanças se aplicam a novas sessões

Editar um fluxo de trabalho não muda retroativamente sessões já criadas. Uma sessão carrega a configuração com a qual foi criada, então, depois de uma mudança de regra, teste com uma sessão **nova** em vez de reverificar uma antiga.