# Regras de decisão e limiares

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

Cada comprovação produz avisos, e tu decides o que cada aviso faz - passar, rever, ou recusar. Esse mapeamento é onde o teu apetite de risco realmente vive.

Cada passo mapeia os seus **avisos** para uma ação: passar, rever, ou recusar.
Um passo configurado para recusar **para o fluxo de trabalho** - os passos
seguintes nunca correm, e não és faturado por eles. Isso torna a ordem das
regras tanto uma decisão de risco como uma decisão de custo.

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

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

É tentador pensar num fluxo de trabalho como "as comprovações que executo". As comprovações são apenas metade disso. A outra metade - e a metade que determina a tua taxa de aprovação - é o que os **avisos** de cada comprovação estão configurados para fazer.

![O criador de fluxos de trabalho da Didit com nós de funcionalidades 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 passo, cada aviso que pode levantar mapeia para uma de três ações:

| Ação | Efeito |
|---|---|
| **Approve** (ou ignorar) | O aviso é registado 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 tua política, expressa em configuração.

## Uma recusa para o fluxo de trabalho

Este é o comportamento que mais surpreende as pessoas, por isso vale a pena ser explícito: quando um passo recusa, a execução para ali. Os passos a seguir **nunca correm**.

Duas consequências:

1. **O resultado vai ter comprovações em falta que esperavas.** Não falharam - nunca foram executadas. Uma sessão recusada na verificação de ID não vai ter prova de vida, nem correspondência facial, nem AML.
2. **Não és faturado por elas.** A faturação é por funcionalidade concluída, por isso um passo que nunca correu não custa nada.

## Usar a ordem das regras para controlar o custo

Como uma recusa para o fluxo, a ordem dos passos é uma alavanca de custo. Colocar uma comprovação de risco barata à frente de um pacote caro significa que o tráfego que nunca ia passar para antes de pagares pela parte cara.

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

> **Warning:** O compromisso é a experiência do utilizador e os falsos positivos. Os sinais
> de dispositivo e IP são as comprovações mais ruidosas que a Didit oferece -
> redes empresariais, NAT de operadora, e navegadores na cloud colocam
> utilizadores genuínos atrás de endereços partilhados. Filtrar um fluxo inteiro
> com base neles vai bloquear clientes reais, por isso encaminha-os para
> **review** em vez de recusar, a menos que já tenhas medido o teu próprio
> tráfego.

## Regras que precisam de julgamento, não de automação

Alguns avisos são inequívocos e devem recusar: uma checksum de MRZ falhada, um chip cuja assinatura não encadeia até ao seu emissor, uma face na tua lista de bloqueio. São falhas de integridade.

Outros são quase sempre melhor como revisão:

- Correspondências parciais de morada no comprovativo de morada - os formatos variam por país.
- Correspondências parciais de nome na validação de base de dados - as fontes oficiais registam nomes de forma diferente.
- Ocorrências de candidato AML com baixa confiança - nomes comuns geram-nas constantemente.
- Uma correspondência facial no limite - consulta [pontuações e limiares de correspondência facial](https://help.didit.me/pt-PT/liveness-biometrics/face-match-thresholds).
- Uma sinalização de face duplicada - que é fraude para uma conta nova e normal para um cliente que regressa.

E alguns são falhas de usabilidade que merecem uma **repetição**, não um veredito: um chip NFC não lido, uma captura desfocada, uma imagem de câmara perdida.

## Políticas de idade

A idade mínima e máxima são configuradas por fluxo de trabalho, e a ação sobre uma violação é escolha tua. `MINIMUM_AGE_NOT_MET` pode recusar diretamente, ou encaminhar para revisão se a tua política permitir uma exceção com prova. Ambas são legítimas; escolhe deliberadamente.

## Regras personalizadas sobre dados extraídos

Para além do mapeamento por aviso, podes escrever regras sobre os dados que um passo extraiu - por exemplo, recusando quando um campo extraído assume um valor específico. Duas coisas a ter em conta:

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

Se estiveres a construir uma regra que ativa com base numa característica protegida, trata isso como uma questão jurídica para a tua equipa de compliance antes de ser uma questão de engenharia.

## Testa as regras, não só os passos

Os passos de um fluxo de trabalho são fáceis de verificar a olho. As regras não são - a única forma de saber que um aviso é encaminhado para onde pensas é produzir esse aviso.

O sandbox existe para isto. Cada cenário força um aviso específico, por isso consegues 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 por aí adiante. Consulta [testar em sandbox](https://help.didit.me/pt-PT/getting-started/sandbox-and-testing).

> **Tip:** Testa o caminho de **revisão** com tanto cuidado como o caminho de recusa. Uma
> regra que encaminha para revisão só é útil se alguém trabalhar mesmo a fila, e
> a forma de descobrir se o teu processo de revisão funciona é fazer passar uma
> sessão sintética por ele antes de um cliente real estar à espera.

## As alterações aplicam-se a sessões novas

Editar um fluxo de trabalho não muda retroativamente as sessões já criadas. Uma sessão transporta a configuração com que foi criada, por isso, depois de uma alteração de regra, testa com uma sessão **nova** em vez de voltares a verificar uma antiga.