Regras e pontuação de KYT: velocidade e condições

Todas as transações submetidas à Didit são avaliadas em relação a todas as regras ativas da sua aplicação. As regras definem condições, verificações de frequência e ações que determinam o estado final e a pontuação da transação. Este capítulo da aula do motor de regras de fraude da Didit Academy retoma a criação de uma regra. A aula do motor de regras da Academy mostra, aos 7:54, como criar uma regra: acionador, condições, ações e pontuação, seguido de testes retrospetivos antes da implementação.

​

Pacotes de regras integrados

A Didit disponibiliza uma biblioteca de regras pré-configurada que cobre tipologias regulamentares comuns. Instale as predefinições (ou pacotes completos) que pretende a partir da biblioteca - na consola, através da API de instalação ou com as ferramentas MCP - e controle o modo de cada predefinição instalada. Para obter o catálogo completo de todas as regras predefinidas com limiares e ações, consulte a Biblioteca de regras.

​

Origens das regras

Cada regra tem uma source que indica quem a gere:

​

Estrutura das regras

Cada regra é composta por:

​

Ações

Quando uma regra corresponde a uma transação, uma ou mais ações são executadas. Cada regra pode ter múltiplas ações que são todas aplicadas em conjunto: A maioria das regras predefinidas combina adicionar pontuação com alterar estado — por exemplo, uma regra de contraparte sob sanções adiciona 90 pontos à pontuação e recusa imediatamente a transação.

​

Exigir verificação do utilizador (AWAITING_USER)

Uma ação alterar estado → AWAITING_USER faz mais do que definir um estado: a Didit cria automaticamente uma sessão de verificação alojada para o sujeito da transação (mesmo vendor_data) no momento em que a regra é acionada. A sessão é devolvida no bloco action_required (e no objeto remediation) da resposta de criação e em todas as leituras subsequentes, bem como em ambos os webhooks da transação - para que possa redirecionar o utilizador de imediato, consulte ações de utilizador necessárias. As regras personalizadas têm de indicar o fluxo na própria ação (workflow_id) - tanto o construtor de regras da consola como a API de regras o exigem. As regras incorporadas da biblioteca não contêm um fluxo; para elas, o fluxo da sessão é determinado por esta ordem:

1. O fluxo de remediação configurado nas suas definições de transação.
2. O fluxo de Autenticação biométrica da sua aplicação, quando o sujeito já tem um rosto de referência guardado de uma verificação aprovada.
3. O fluxo predefinido da sua aplicação.

Isto significa que as regras da biblioteca com AWAITING_USER produzem sempre uma sessão pronta a utilizar desde o início - uma verificação biométrica adicional para utilizadores que já verificou, ou uma verificação completa caso contrário. As transações Travel Rule estão excluídas deste mecanismo automático de recurso alternativo: a espera no estado AWAITING_USER destina-se ao comprovativo de propriedade da carteira, que possui o seu próprio fluxo. A opção mais sólida para transações de alto risco é um fluxo de Autenticação biométrica: como o sujeito é o utilizador que já passou pelo KYC, a Didit reutiliza o rosto de referência verificado do onboarding (a selfie de prova de vida aprovada, a foto do chip do passaporte ou o retrato do documento) - o utilizador só precisa de tirar uma selfie em tempo real, e a Didit executa a prova de vida e uma correspondência facial 1:1 com a identidade que abriu a conta. Credenciais roubadas, OTPs obtidos por phishing e trocas de SIM falham todos neste ponto. Guia passo a passo completo: biometria adicional para um levantamento de alto valor. Quando a sessão atinge uma decisão, a transação segue-a automaticamente e um webhook transaction.status.updated é acionado: uma sessão aprovada aprova a transação (decision_reason_code: user_action_approved), uma sessão recusada recusa-a (user_action_declined), e uma sessão que termina em análise envia a transação para IN_REVIEW (user_action_in_review). Uma sessão expirada ou abandonada mantém a transação em AWAITING_USER.

​

Pontuação

Quando uma transação corresponde a uma ou mais regras, as pontuações são combinadas:

1. A correspondência de cada regra contribui para a pontuação de risco global da transação através da ação add_score
2. A pontuação final determina o estado da transação com base nos limiares de pontuação da sua aplicação
3. Se alguma regra tiver uma ação change_status, esse estado é aplicado diretamente — DECLINED tem sempre prioridade

Limiares de pontuação predefinidos (configuráveis na consola):

​

Criar regras personalizadas

As regras personalizadas podem ser criadas a partir da Consola Empresarial ou através da Management API (também acessível a partir do Didit MCP e de qualquer assistente de IA ligado ao MCP). As regras em modo Active entram em vigor imediatamente para todas as novas transações. Os títulos são únicos por aplicação.

​

Backtesting

Antes de ativar uma regra, pode validá-la em relação a dados históricos:

• Defina uma regra para o modo Test — a regra é avaliada a cada nova transação, mas os resultados não afetam o estado nem a pontuação da transação. As estatísticas de execução (contagem de correspondências, entidades afetadas) acumulam-se para que possa avaliar o impacto antes de entrar em produção.
• Utilize a funcionalidade de backtest - na consola ou através de POST /v3/transactions/rules/backtest/ - para avaliar retroativamente as condições e a agregação de uma regra em relação a transações de um período de tempo especificado. O backtest devolve o número de transações avaliadas e correspondidas, bem como as entidades afetadas - sem modificar quaisquer dados históricos. Envie os mesmos conditions, aggregation, evaluation_mode e scope da regra que pretende ativar: um âmbito omitido significa nenhuma restrição, pelo que o backtest contaria transações que a regra guardada ignora.

​

Janelas de velocidade (agregação)

As regras de velocidade agregam dados históricos de transações ao longo de um período de tempo para detetar padrões que as verificações de uma única transação não detetariam: Cada agregação especifica:

• Uma janela temporal: <N>m (minutos), <N>h (horas) ou <N>d (dias) - por exemplo, 30m, 6h, 7d, 30d. Atenção: m corresponde a minutos, e não a meses.
• Filtros para restringir as transações históricas que são incluídas. As chaves são caminhos de campos do catálogo de campos; o valor especial "__current__" resolve para o valor do mesmo campo na transação que está a ser avaliada (por exemplo, "subject_vendor_data": "__current__" restringe a janela ao mesmo sujeito), e um valor sob a forma de lista indica pertença. Os filtros comparam apenas por igualdade ou pertença - não existe um filtro lt/gte, pelo que um intervalo como transações inferiores a 10,000 não é algo que um filtro possa expressar. Em vez disso, coloque o intervalo na métrica (max abaixo de 10,000, min acima de 1,000) e lembre-se de que uma condição restringe a transação que está a ser avaliada, nunca a janela.
• Um operador e limiar (eq, ne, gt, gte, lt, lte em relação a value, por exemplo, contagem >= 20)

​

Padrões de exemplo

​

Catálogo de campos

As condições e os filtros de agregação referenciam campos de transações por caminho:

​

Operadores de condição

As regras suportam os seguintes operadores de comparação para condições: Todos os outros operadores exigem um value não vazio, e a API responde com 400 caso este falte. contains, not_contains e regex aceitam uma única cadeia de caracteres, e não uma lista ou objeto; contains_any aceita uma lista de cadeias de caracteres.

​

Tipos de valor de condição

Um value_type opcional numa condição altera a forma como o value é interpretado:

​

Condições agrupadas

Uma lista simples de condições é combinada de acordo com o evaluation_mode da regra (ALL/ANY). Para lógica mista, atribua um group_index às condições: as condições que partilham um índice formam um grupo, o group_logic (AND/OR, por omissão AND) combina condições dentro de um grupo, e o groups_logic na primeira condição (AND/OR, por omissão OR) combina os resultados dos grupos. Quando qualquer condição inclui um group_index, a avaliação agrupada substitui o evaluation_mode.

​

Referenciar propriedades personalizadas

Cada chave enviada no objeto custom_properties de POST /v3/transactions/ é armazenada na transação como custom_values e pode ser utilizada em condições com o caminho de campo custom_values.<key>. Por exemplo, uma transação enviada com "custom_properties": {"channel": "mobile_app"} corresponde à condição custom_values.channel eq "mobile_app". Todos os operadores acima funcionam com propriedades personalizadas e estas também podem ser comparadas com outros campos ou utilizadas em filtros de velocidade. No construtor de regras da Console, as chaves detetadas em transações recebidas recentemente aparecem automaticamente no seletor de campos de condição sob Propriedades personalizadas. Também pode referenciar uma chave antes de qualquer transação a conter: selecione Introduzir propriedade personalizada no mesmo grupo e digite a chave exatamente como a sua integração a envia (as chaves diferenciam maiúsculas de minúsculas). A regra simplesmente será avaliada como não correspondente até chegarem transações que contenham essa chave.

​

Recusa automática por lista de bloqueio

Antes de qualquer regra ser avaliada, a Didit verifica as entidades da transação contra as listas de bloqueio da sua aplicação. Se for encontrada qualquer correspondência, a transação é imediatamente recusada — as regras não chegam a ser avaliadas. São verificadas as seguintes entidades: Quando ocorre uma correspondência numa lista de bloqueio:

• O estado da transação é definido como DECLINED
• O motivo da decisão é definido como blocklisted
• É criado um registo de atividade para efeitos de auditoria

​

Triagem de transações

A Didit integra-se com fornecedores externos de análise AML e de blockchain para enriquecer as transações com dados de risco. Quando uma transação é submetida, o sistema pode:

• Fazer a triagem de contrapartes contra bases de dados globais de sanções e de listas de vigilância
• Avaliar endereços de carteiras (para transações cripto) contra dados de inteligência de blockchain, incluindo exposição a misturadores, ligações a entidades sancionadas e interações com serviços de alto risco
• Verificar o estado AML do requerente, cruzando o utilizador associado à transação com os seus resultados mais recentes de triagem AML

Os resultados da triagem são associados à transação e influenciam a pontuação do motor de regras. Se uma contraparte ou carteira corresponder a uma lista de sanções, a regra correspondente sinaliza ou recusa automaticamente a transação.

​

Passos seguintes