Saltar para o conteúdo principal
Didit disponibiliza uma biblioteca selecionada de mais de 150 regras predefinidas de monitorização de transações, que pode instalar individualmente ou por pacote. Cada regra corresponde a uma tipologia real de AML, fraude ou conformidade, extraída de normas e orientações regulamentares globais: recomendações do GAFI (FATF), avisos da FinCEN, regras da NACHA, princípios de Wolfsberg, tipologias do Grupo Egmont e padrões de abuso em iGaming. Escolha as predefinições ou os pacotes de que precisa e, em seguida, controle o modo de cada regra instalada (ACTIVE, TEST ou DISABLED). As condições, os limiares e as ações das predefinições são fixos; crie uma regra personalizada quando precisar de uma lógica diferente. Desinstale uma predefinição para a remover da aplicação e reinstale-a mais tarde, se necessário.
As regras da biblioteca podem ser consultadas, instaladas e desinstaladas em Transactions -> Rules -> Library na Business Console, através da API da biblioteca de regras (GET /v3/transactions/rules/library/, POST/DELETE /v3/transactions/rules/install/), ou através das ferramentas MCP didit_transaction_rule_library_list / didit_transaction_rule_install / didit_transaction_rule_uninstall. As predefinições instaladas aceitam apenas alterações de mode (ativar, desativar, testar); os respetivos limiares são fixos: para os substituir, crie uma regra personalizada. Para saber como as regras contribuem para a pontuação, consulte a pontuação de risco.
Uma regra da biblioteca cujas condições leem dados que o motor de regras ainda não consegue avaliar fica retida até poder ser executada: a biblioteca não a apresenta na lista, um pedido que a indique em library_keys responde com 400 e não instala nada (uma chave desconhecida é ignorada), e uma instalação por bundle a ignora. Uma cópia que tenha instalado anteriormente é desligada (DISABLED) e mantém-se na sua lista de regras, e definir o respetivo mode para outro valor responde com 400. Uma regra retida volta automaticamente quando o motor de regras puder avaliar as suas condições, pelo que a lista da biblioteca mostra sempre as regras que pode instalar hoje.

Como as predefinições estão organizadas

Cada predefinição pertence a um pacote (a sua família funcional) e a uma categoria (o tema de risco mais amplo). Os pacotes permitem ativar ou desativar regras relacionadas em conjunto a partir da consola; as categorias orientam a pontuação e os relatórios.

Como ler esta página

Cada regra indica o seu library_key (identificador estável ao qual pode fazer referência na API ou no URL da consola), as condições e a agregação que a fazem disparar, e as ações predefinidas que executa. Os limiares numéricos apresentados aqui são os valores predefinidos de fábrica: cada valor pode ser editado por aplicação sem perder a identidade da regra.

Conjunto de finanças

Estas regras aplicam-se a todas as transações com transaction_type = FINANCE. Modelam a base regulamentar (limiares de comunicação BSA/FinCEN e heurísticas de velocidade do GAFI), bem como padrões de mulas de dinheiro e smurfing.

Estruturação e proximidade do limiar

Volume e velocidade

Stratificação, mulas e smurfing

Anomalias comportamentais


Conjunto AML / CTF

Estas regras modelam tipologias clássicas de AML/CTF que não dependem do enriquecimento de blockchain. Aplicam-se universalmente a transferências em moeda fiduciária e em criptoativos. A lista predefinida de jurisdições de alto risco inclui os territórios objeto de chamada à ação do GAFI e os territórios de regiões de conflito: IRN, PRK, SYR, AFG, RUS, MMR. Pode substituir a lista por aplicação.
A cobertura de contrapartes PEP não está disponível de momento. Nenhum fornecedor de triagem ligado comunica se uma contraparte é uma pessoa politicamente exposta: o campo pep_counterparty é null em todos os resultados de triagem atuais (ver triagem de carteiras), pelo que a biblioteca não tem uma predefinição de contraparte PEP. Uma regra instalada antes de essa predefinição ser retirada continua a ser avaliada, mas não consegue corresponder a uma triagem real. Remova-a ou substitua-a por uma regra personalizada se precisar de atuar sobre outro sinal.

Conjunto de triagem cripto

Estas regras utilizam os dados enriquecidos produzidos pela triagem cripto da Didit. São mais úteis para aplicações nativas de cripto e para VASP.

Pacote de monitorização de criptoativos

Regras de exposição ao nível da carteira, além de verificações de integridade associadas a VASP e à Travel Rule.

Pacote Travel Rule

As regras Travel Rule aplicam-se apenas a transações travelRule. Cada regime regional inclui quatro regras (contraparte pendente, ação pendente, dados obrigatórios em falta, falha na troca).

Travel Rule global

Regimes regionais

O mesmo modelo de quatro regras aplica-se a cada regime. Substitua <regime> abaixo por qualquer um dos seguintes: australia, dubai, eu, hong_kong, india, indonesia, japan, kazakhstan, singapore, south_africa, turkey, uk. A marcação do regime é automática: a Didit atribui custom_values.travel_rule_regime a cada transação Travel Rule a partir do campo jurisdiction das suas definições Travel Rule - SG → singapore, GB → uk, e qualquer código de Estado-Membro da UE ou do EEE, como DE ou FR → eu. Os códigos sem pacote regional são atribuídos em minúsculas (US → us), para que as regras personalizadas os possam ainda assim visar. Um valor de props.travel_rule_regime enviado na transação substitui sempre o regime derivado. Ou seja, são 48 regras específicas por região, além das três regras Travel Rule globais e das cinco regras de contraparte abaixo. O pacote travel_rule_eu_tfr, separado, acrescenta quatro regras TFR da UE, descritas em Pacote de regras TFR da UE.

Diligência devida sobre contrapartes

Estas regras leem o que a sua aplicação sabe sobre o VASP da contraparte com que a plataforma de câmbio contactou: a sua própria decisão sobre ele, o nível de risco apurado na diligência devida, o país e a capacidade de resposta. Consulte Diligência devida sobre contrapartes para saber de onde provém cada valor.

Inteligência de dispositivo e prevenção de fraude

Estas regras transformam sinais do SDK do cliente (impressão digital do dispositivo, IP, navegador, idade da sessão) e do enriquecimento do fornecedor em eventos de deteção de fraude.

Impressão digital do dispositivo e utilização de múltiplas contas

IP, rede e VPN

Composto comportamental

Tomada de controlo de contas e fraude APP

Abuso de afiliados e de bónus


Pacote de jogo responsável

Para aplicações de iGaming. Estas regras foram concebidas para detetar tanto sinais de proteção do jogador como padrões de abuso de bónus.

Pacote de fraude iGaming

Para operadores que enviam eventos de monitorização, além de movimentos de dinheiro. Estas regras usam scope.record_types = ["event"], por isso os clientes apenas com transações não veem qualquer alteração de comportamento. Quando existe uma alternativa apenas para transações, instale a regra alternativa indicada juntamente com a regra de evento até que a sua integração envie a categoria de evento.

Sinais de evento necessários para cada regra

Cada regra acima lê campos de evento identificados. Quando um campo obrigatório está ausente, a regra simplesmente não corresponde - nunca infere o sinal a partir de outro dado, e nunca recorre sozinha aos dados de transação. Envie as chaves abaixo no payload do evento e em device_context (consulte Eventos para o contrato completo de submissão e Regras de evento para os caminhos de campos das regras). Use o pacote igaming_fraud quando a sua integração emitir eventos de início de sessão, jogo, bónus, afiliados, pagamento, disputa, segurança e jogo responsável. As regras são de adesão voluntária: adicioná-las à biblioteca não as instala para aplicações existentes e não altera as predefinições atuais de qualquer cliente ativo.

Pacote de e-commerce

Para marketplaces e aplicações de comerciante de registo.

Pacote de fraude em cheques

Para aplicações que submetem transações de depósito de cheques. Cada regra é acionada pelos sinalizadores custom_values.check_* que quem faz o pedido à API define quando um cheque apresenta um sinal de risco conhecido (lavagem química, MICR em falta, número de série listado na dark web, etc.).

Pacote BNPL

Para fornecedores de compra agora, paga depois (BNPL). Deteta padrões de fraude de primeira parte (falta de pagamento) e de partilha de identificadores específicos do crédito em prestações.

Referência: normas na base da biblioteca

Cada predefinição da biblioteca da Didit corresponde a uma tipologia de AML, de fraude ou de conformidade amplamente aceite. As normas em que nos apoiamos: A Didit implementa apenas as tipologias que são normas aceites pelo setor e expõe todos os limiares para que você os possa ajustar.

Personalizar predefinições

Cada predefinição pode ser:
  • Ajustada: altere limiares, janelas, valores de pontuação ou ações por aplicação
  • Desativada: mude uma predefinição para o modo DISABLED e ela deixa de ser avaliada, sem perder a sua identidade
  • Testada: mude uma predefinição para o modo TEST para a avaliar em modo sombra, sem afetar os resultados das transações
  • Estendida: crie regras personalizadas que complementam ou substituem predefinições
Consulte Regras e pontuação para a anatomia das regras, os endpoints da API e exemplos práticos de criação de regras personalizadas.
Última modificação em 7 de novembro de 2026