ACTIVE, TEST ou DISABLED). As condições, os limiares e as ações das regras predefinidas são fixos. Crie uma regra personalizada quando precisar de uma lógica diferente. Desinstale uma regra predefinida para removê-la da aplicação e reinstale-a depois, se necessário.
As regras da biblioteca podem ser consultadas, instaladas e desinstaladas em Transactions -> Rules -> Library no Business Console, pela API da biblioteca de regras (
GET /v3/transactions/rules/library/, POST/DELETE /v3/transactions/rules/install/) ou pelas ferramentas MCP didit_transaction_rule_library_list / didit_transaction_rule_install / didit_transaction_rule_uninstall. As regras predefinidas instaladas aceitam apenas alterações de mode (ativar, desativar, testar). Seus limiares são fixos: para substituir um deles, crie uma regra personalizada. Para saber como as regras contribuem para a pontuação, consulte pontuação de risco.Uma regra da biblioteca cujas condições leem dados que o mecanismo de regras ainda não consegue avaliar fica retida até que possa ser executada. A biblioteca não a lista. Uma requisição que a cite em
library_keys retorna 400 e não instala nada (uma chave desconhecida, por outro lado, é ignorada). Uma instalação por bundle a ignora. Uma cópia que você instalou anteriormente é desativada (DISABLED) e permanece na sua lista de regras, e definir o mode dela com qualquer outro valor retorna 400. Uma regra retida volta automaticamente assim que o mecanismo de regras consegue avaliar suas condições, de modo que a lista da biblioteca sempre mostra as regras que você pode instalar hoje.Como as regras predefinidas são organizadas
Toda regra predefinida pertence a um pacote (sua família funcional) e a uma categoria (seu tema de risco mais amplo). Os pacotes permitem ativar e desativar regras relacionadas em conjunto pelo painel. As categorias orientam a pontuação e os relatórios.Como ler esta página
Cada regra lista sualibrary_key (identificador estável que você pode referenciar na API ou na URL do console), as condições e a agregação que a disparam e as ações padrão que ela executa. Os limiares numéricos mostrados aqui são os valores padrão fornecidos. Todos os valores podem ser editados por aplicação sem que a regra perca sua identidade.
Pacote de finanças
Estas regras se aplicam a toda transação comtransaction_type = FINANCE. Elas modelam a base regulatória (limiares de comunicação do BSA/FinCEN, heurísticas de velocidade do FATF), além de padrões de contas laranja e de smurfing.
Fracionamento e valores próximos ao limiar
Volume e velocidade
Ocultação (layering), contas laranja e smurfing
Anomalias comportamentais
Pacote AML / CTF
Estas regras modelam tipologias clássicas de AML/CTF que não dependem de enriquecimento de blockchain: elas se aplicam universalmente a transferências em moeda fiduciária e em cripto.
A lista padrão de jurisdições de alto risco já vem com os territórios sujeitos a apelo à ação do FATF e as regiões de conflito:
IRN, PRK, SYR, AFG, RUS, MMR. Você pode substituir a lista por aplicação.
A cobertura de contrapartes PEP não é oferecida no momento. Nenhum provedor de triagem conectado informa se uma contraparte é uma pessoa politicamente exposta: hoje, o campo
pep_counterparty é null em todos os resultados de triagem (consulte triagem de carteiras), por isso a biblioteca não tem um preset para contrapartes PEP. Uma regra instalada antes da retirada desse preset continua sendo avaliada, mas não pode ser acionada por uma triagem real: remova-a ou substitua-a por uma regra personalizada se você precisar agir com base em outro sinal.Pacote de triagem cripto
Estas regras consomem os dados enriquecidos produzidos pela triagem cripto da Didit: elas são mais úteis para aplicações cripto-nativas e de VASPs.Pacote de monitoramento cripto
Regras de exposição no nível da carteira, além de verificações de integridade relacionadas a VASPs e à Travel Rule.Pacote Travel Rule
As regras de Travel Rule se aplicam somente a transaçõestravelRule.
Cada regime regional inclui quatro regras (contraparte pendente, ação pendente, dados ausentes, troca com falha).
Travel Rule global
Regimes regionais
O mesmo modelo de quatro regras é aplicado a cada regime. Substitua<regime> abaixo por qualquer um destes: australia, dubai, eu, hong_kong, india, indonesia, japan, kazakhstan, singapore, south_africa, turkey, uk.
A marcação do regime é automática: a Didit grava custom_values.travel_rule_regime em toda transação de Travel Rule com base no jurisdiction das suas configurações de Travel Rule - SG → singapore, GB → uk e qualquer código de país membro da UE ou do EEE, como DE ou FR → eu. Códigos sem pacote regional são gravados em minúsculas (US → us), para que regras personalizadas ainda possam ser direcionadas a eles. Um valor props.travel_rule_regime enviado na transação sempre substitui o regime derivado.
São 48 regras específicas por região, além das três regras globais de Travel Rule e das cinco regras de contraparte abaixo.
O pacote separado
travel_rule_eu_tfr adiciona quatro regras do TFR da UE, descritas em Pacote de regras do TFR da UE.
Due diligence da contraparte
Estas regras leem o que a sua aplicação sabe sobre o VASP da contraparte que a corretora contatou: sua própria decisão sobre ele, o nível de risco da due diligence desse VASP, seu país e sua capacidade de resposta. Consulte Due diligence da contraparte para saber de onde vem cada valor.Inteligência de dispositivo e prevenção de fraudes
Estas regras transformam sinais do SDK do cliente (fingerprint do dispositivo, IP, navegador, idade da sessão) e o enriquecimento de provedores em eventos de detecção de fraude.Fingerprint do dispositivo e múltiplas contas
IP, rede e VPN
Sinais comportamentais combinados
Sequestro de conta e fraude APP
Abuso de afiliados e bônus
Pacote de jogo responsável
Para aplicações de iGaming. Estas regras foram projetadas para detectar tanto sinais de proteção ao jogador quanto padrões de abuso de bônus.Pacote de fraude em iGaming
Para operadores que enviam eventos de monitoramento além das movimentações financeiras. Essas regras usamscope.record_types = ["event"], então clientes que enviam apenas transações não percebem nenhuma mudança de comportamento. Quando existe uma alternativa baseada apenas em transações, instale a regra alternativa indicada junto com a regra de evento até que sua integração envie a categoria de evento.
Sinais de evento necessários para cada regra
Todas as regras acima leem campos de evento nomeados. Quando um campo obrigatório está ausente, a regra simplesmente não corresponde: ela nunca infere o sinal com base em outro dado e nunca recorre sozinha aos dados de transação. Envie as chaves abaixo nopayload e no device_context do evento (consulte Eventos para o contrato completo de envio e Regras de evento para os caminhos de campo das regras).
Use o pacote
igaming_fraud quando sua integração emitir eventos de login, gameplay, bônus, afiliados, pagamento, disputa, segurança e jogo responsável. As regras continuam sendo opcionais: adicioná-las à biblioteca não as instala em aplicações existentes e não altera os presets atuais de nenhum cliente ativo.
Pacote de e-commerce
Para marketplaces e aplicações que atuam como merchant of record.Pacote de fraude com cheques
Para aplicações que enviam transações de depósito de cheques. Cada regra é acionada por flagscustom_values.check_* que o chamador define quando um cheque apresenta um sinal de risco conhecido (lavagem química, MICR ausente, número de série listado na dark web etc.).
Pacote de BNPL
Para provedores de buy now, pay later (compre agora, pague depois). Identifica padrões de fraude primária (inadimplência intencional) e de compartilhamento de identificadores específicos do crédito parcelado.Referência: padrões por trás da biblioteca
Cada preset da biblioteca da Didit corresponde a uma tipologia de AML, fraude ou conformidade amplamente aceita. Os padrões em que nos baseamos:
A Didit implementa apenas as tipologias que são padrões aceitos no setor e expõe todos os limiares para que você os ajuste.
Personalização de presets
Todo preset pode ser:- Ajustado: altere limiares, janelas, valores de pontuação ou ações por aplicação
- Desativado: coloque um preset no modo
DISABLEDe ele deixa de ser avaliado sem perder sua identidade - Testado: coloque um preset no modo
TESTpara avaliá-lo em modo sombra, sem afetar os resultados das transações - Estendido: crie regras personalizadas que complementam ou substituem os presets