Primeiros passos
Integração / SDKs
Verificação de usuários
Verificação de empresas
Monitoramento de transações
Registro de alteraçõesQuando usar cada interface
Os endpoints
As ferramentas MCP correspondentes são
didit_transaction_rule_list, didit_transaction_rule_get, didit_transaction_rule_create, didit_transaction_rule_update, didit_transaction_rule_delete, didit_transaction_rule_backtest, didit_transaction_rule_library_list, didit_transaction_rule_install e didit_transaction_rule_uninstall. Consulte a referência de ferramentas MCP.
O esquema completo (o catálogo de campos, os 19 operadores de condição, as janelas de velocidade, as condições agrupadas e os seis tipos de ação) está documentado na página Regras e pontuação e incorporado à referência da API.
Criar, fazer backtest, ativar
O padrão seguro de implantação para qualquer regra nova:1
Crie a regra no modo TEST
scope e conditions descrevem a transação que está sendo avaliada: uma transação financeira de entrada em EUR com amount bruto abaixo de 10.000. As entradas de aggregation descrevem a janela de 30 dias para o mesmo titular: pelo menos 20 transações financeiras de entrada em EUR, e nenhuma delas de 10.000 EUR ou mais. As duas entradas de agregação precisam ser satisfeitas, seja qual for o valor de evaluation_mode, pois essa configuração rege apenas as condições.Este exemplo usa o amount bruto e fixa currency em EUR nas duas metades, por isso não depende da normalização cambial. Para fazer o backtest com dados de teste do sandbox, envie pelo menos 20 transações financeiras de entrada em EUR para o mesmo titular em até 30 dias, cada uma com amount abaixo de 10.000. Nem preferred_currency_amount nem amount_in_default_currency são obrigatórios. A ingestão no sandbox armazena essas transações; execute o backtest explicitamente.Uma regra TEST é avaliada em cada nova transação e registra as correspondências que teria encontrado, mas nunca altera a pontuação nem o status da transação.Um filtro de agregação não é uma condição. Uma condição lê apenas a transação que está sendo avaliada; um filtro de agregação apenas restringe a janela histórica e compara por igualdade ou pertencimento a uma lista. Não existe filtro
lt, portanto não é possível contar apenas as transferências abaixo de 10.000.A entrada max ... lt 10000 é a forma suportada de impor um teto à janela: ela exige que todas as transações da janela estejam abaixo de 10.000, o que é mais rigoroso do que contar apenas as pequenas. Uma única transferência de 12.000 entre as vinte impede que a regra seja acionada. Remova essa entrada se preferir que a contagem valha por si só e, nesse caso, deixe isso claro no título: sem ela, a regra conta transferências de entrada de qualquer valor, e dezenove transferências de 50.000 seguidas de uma pequena correspondem a ela.2
Faça o backtest com o seu histórico
matched inesperada indica que os limiares precisam de ajuste antes que a regra possa ter qualquer efeito.3
Ative
Migrando regras de outro provedor
Como a criação de regras é uma simples chamada de API com um schema totalmente documentado, um assistente de IA pode converter a exportação de regras de outro provedor em regras da Didit para você.- Exportar: exporte suas regras do provedor atual. A maioria das ferramentas exporta para CSV ou Excel.
- Envie o arquivo para o assistente do console da Didit (ou para qualquer agente conectado via MCP, como o Claude com o Didit MCP configurado). Planilhas são convertidas em texto automaticamente.
- O assistente mapeia cada linha para o schema da Didit (condições, janelas de velocidade, ações) e mostra o mapeamento antes de criar qualquer coisa, apontando tudo o que não tem equivalente na Didit.
- Com a sua aprovação, ele cria as regras no modo TEST, faz o backtest delas com o seu próprio histórico de transações e informa as linhas criadas, as que falharam e as que não puderam ser mapeadas.
- Revise os números e ative as regras que parecerem corretas, pelo console ou com um
PATCH {"mode": "ACTIVE"}.
scope e conditions restringem a transação avaliada a uma transferência de saída em EUR abaixo de 10.000, e os filtros de agregação restringem a janela de 30 dias às transferências de saída em EUR desse mesmo sujeito. O amount bruto só é comparável dentro de uma mesma moeda, por isso mantenha a moeda fixada como acima. Um teto entre moedas diferentes exige um valor normalizado para cada transação da janela. Mudar apenas para preferred_currency_amount não garante essa disponibilidade: valores normalizados ausentes no histórico podem ser tratados como zero pelas agregações numéricas.
É a entrada max que mantém a janela abaixo de 10.000 EUR, porque um filtro de agregação não consegue expressar abaixo de 10.000. Veja a observação sobre a etapa de criação acima para entender a contrapartida envolvida. Tudo o que o schema não consegue expressar com exatidão deve ser declarado explicitamente na description da regra, em vez de ser aproximado silenciosamente.
Erros de validação são precisos de propósito
Os endpoints de criação e atualização validam os valores de condições, agregação e escopo exatamente com base no que o motor de regras aceita: operadores ou métricas desconhecidos, janelas malformadas ("30days" em vez de "30d"), direções de escopo inválidas, contains_any sem uma lista, fuzzy_match sem um score e change_status para AWAITING_USER sem um workflow_id retornam um 400 que indica o índice e o problema, em vez de armazenar uma regra que silenciosamente nunca é correspondida. Agentes e scripts devem ler o corpo do erro e corrigir o payload. Chaves de escopo adicionais além de transaction_types, directions e action_types são armazenadas, mas ignoradas pelo motor, seguindo a forma como o Business Console sempre as salvou.
Próximos passos
Regras e pontuação
O schema completo de regras: campos, operadores, janelas de velocidade, ações.
API de criação de regras
Referência do endpoint com os schemas de requisição e resposta.
Biblioteca de regras
O catálogo de 150+ presets e seus pacotes.
Visão geral do MCP
Conecte um agente de IA ao seu workspace da Didit.