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 seulibrary_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 comtransaction_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çõestravelRule.
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 usamscope.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 nopayload 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 sinalizadorescustom_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
DISABLEDe ela deixa de ser avaliada, sem perder a sua identidade - Testada: mude uma predefinição para o modo
TESTpara a avaliar em modo sombra, sem afetar os resultados das transações - Estendida: crie regras personalizadas que complementam ou substituem predefinições