Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesQuando usar cada superfície
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 das ferramentas MCP.
O esquema completo - o catálogo de campos, os 19 operadores de condição, as janelas temporais de análise de velocidade, as condições agrupadas e os seis tipos de ação - está documentado na página Regras e pontuação e incorporado na referência da API.
Criar, fazer backtest e ativar
O padrão seguro para lançar qualquer regra nova:1
Criar a regra no modo TEST
scope e conditions descrevem a transação avaliada: uma transação financeira de entrada em EUR com um amount bruto inferior a 10 000. As entradas de aggregation descrevem a janela de 30 dias para o mesmo sujeito: pelo menos 20 transações financeiras de entrada em EUR, e nenhuma delas de 10 000 EUR ou mais. Ambas as entradas de agregação têm de se verificar, independentemente do valor de evaluation_mode; essa definição rege apenas as condições.Este exemplo usa o amount bruto e fixa currency em EUR nas duas partes, pelo que não depende da normalização cambial. Para fazer backtest com os dados de teste do sandbox, submeta pelo menos 20 transações financeiras de entrada em EUR para o mesmo sujeito nos 30 dias, cada uma com amount inferior a 10 000. Nem preferred_currency_amount nem amount_in_default_currency são obrigatórios. A ingestão no sandbox guarda estas transações; execute o backtest explicitamente.Uma regra TEST avalia cada nova transação e regista as correspondências que teria produzido, mas nunca altera a pontuação nem o estado da transação.Um filtro de agregação não é uma condição. Uma condição lê apenas a transação avaliada; um filtro de agregação restringe apenas a janela histórica, e compara por igualdade ou por pertença a uma lista - não existe um filtro
lt, por isso 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: exige que todas as transações da janela sejam inferiores a 10 000, o que é mais restritivo do que contar apenas as pequenas - uma transferência de 12 000 entre as vinte impede a regra de disparar. Remova essa entrada se preferir que a contagem seja independente, e indique-o então no título: sem ela, a regra conta transferências de entrada de qualquer valor, e dezanove transferências de 50 000 seguidas de uma pequena fazem com que a regra seja acionada.2
Fazer backtest contra o seu histórico
matched significa que os limiares precisam de ser ajustados antes de a regra poder ser aplicada.3
Ativar
Migração de regras de outro fornecedor
Como a criação de regras é uma simples chamada de API com um esquema totalmente documentado, um assistente de IA pode traduzir a exportação de regras de outro fornecedor para regras da Didit por si.- Exportar as suas regras do fornecedor atual - a maioria das ferramentas exporta para CSV ou Excel.
- Coloque o ficheiro no assistente da consola da Didit (ou em qualquer agente ligado ao MCP, como o Claude, com o MCP da Didit associado). As folhas de cálculo são convertidas automaticamente para texto.
- O assistente mapeia cada linha para o esquema da Didit - condições, janelas de velocidade, ações - e mostra-lhe o mapeamento, assinalando tudo o que não tenha equivalente na Didit, antes de criar seja o que for.
- Após a sua confirmação, cria as regras em modo TEST, faz testes retrospetivos com o seu próprio histórico de transações e indica as linhas criadas, falhadas e não mapeáveis.
- Analise os números e ative as regras que lhe parecerem corretas, na consola ou com um
PATCH {"mode": "ACTIVE"}.
scope e conditions fixam a transação avaliada a uma transferência de saída em EUR inferior a 10.000, e os filtros de agregação fixam a janela de 30 dias às transferências de saída em EUR do mesmo sujeito. O amount bruto só é comparável dentro de uma mesma moeda, por isso mantenha a moeda fixa como indicado acima. Um limite que abrange várias moedas exige um valor normalizado para cada transação da janela. Mudar apenas para preferred_currency_amount não garante a disponibilidade: os valores normalizados históricos em falta podem ser tratados como zero pelas agregações numéricas.
A entrada max é o que mantém a janela abaixo de 10.000 EUR, porque um filtro de agregação não consegue expressar “inferior a 10.000”. Veja a nota sobre o passo de criação acima para o compromisso que isso implica. Tudo o que o esquema não consiga expressar com exatidão deve ser indicado explicitamente na description da regra, em vez de ser aproximado sem aviso.
Os erros de validação são deliberadamente precisos
Os endpoints de criação e atualização validam as condições, a agregação e os valores de âmbito contra exatamente aquilo que o motor de regras aceita: operadores ou métricas desconhecidos, janelas inválidas ("30days" em vez de "30d"), direções de âmbito inválidas, contains_any sem uma lista, fuzzy_match sem um score, e change_status para AWAITING_USER sem um workflow_id devolvem todos um 400 que indica o índice e o problema, em vez de guardarem uma regra que nunca corresponde, sem aviso. Agentes e scripts devem ler o corpo do erro e corrigir o payload. As chaves de âmbito extra, além de transaction_types, directions e action_types, são guardadas mas ignoradas pelo motor, tal como a Business Console sempre as guardou.
Próximos passos
Regras e pontuação
O esquema completo das regras: campos, operadores, janelas de velocidade, ações.
API de criação de regras
Referência do endpoint com os esquemas de pedido e de resposta.
Biblioteca de regras
O catálogo com 150+ predefinições e os respetivos pacotes.
Visão geral do MCP
Ligue um agente de IA ao seu espaço de trabalho da Didit.