Como a TMNZ incorpora a gestão de decisões auditáveis em sua plataforma de pagamentos de impostos

O ponto de partida

A plataforma da TMNZ processa transações de pooling de impostos que precisam cumprir a Lei do Imposto de Renda de 2007, a Lei de Administração Tributária de 1994 e a Lei de AML/CFT de 2009 — simultaneamente. Diferentemente da maioria das fintechs, em que a conformidade é uma camada adicional, o produto central da TMNZ é inseparável do arcabouço regulatório: cada transação é auditável em relação à legislação primária, e cada regra que governa precificação, faturamento e correspondência de pagamentos precisa ser rastreável à sua base legal. Quando essas regras viviam em código, planilhas ou processos não documentados, o resultado foi uma escalabilidade limitada, aumento do custo de atendimento e a incapacidade de evoluir as regras com a confiança de que o rastro de auditoria permaneceria consistente.

A equipe adota um princípio arquitetural claro: manter a lógica de regras de negócios desacoplada do código da aplicação sempre que possível, para que as regras possam ser criadas, auditadas e evoluídas de forma independente das liberações de funcionalidades.

Por que a TMNZ avaliou o DecisionRules

A TMNZ avaliou vários engines de regras, tanto de código aberto quanto comerciais. A lista final precisava cumprir um padrão rigoroso de soberania de dados, integração com a pilha de ferramentas nativa de IA existente, acessibilidade entre equipes e segurança. O DecisionRules atendeu aos critérios priorizados pela equipe:

Como foi configurado

O DecisionRules foi implantado self-hosted no ambiente Azure da TMNZ com SSO e integração com banco de dados. A equipe o conectou a microserviços .NET por meio de chamadas de API para o solver do DecisionRules e o integrou a workflows agentic do n8n — incluindo via MCP (Model Context Protocol) — para que agentes de IA e fluxos de automação pudessem invocar as mesmas regras centrais usadas pela camada de aplicação. A intenção era simples: uma única fonte de verdade para a lógica de regras, chamável de qualquer lugar na pilha, independentemente de o chamador ser um microserviço, um workflow de automação ou um agente de IA.

A configuração foi desenhada para que tabelas DMN pudessem ser criadas e atualizadas fora do código da aplicação, com desenvolvedores cuidando das entradas de dados e da integração via API. Os fluxos de processo foram modelados com formas de Decision Task conectando às tabelas DMN subjacentes.

Os recursos recentemente adicionados sobre integração nativa com banco de dados e testes automatizados elevaram a plataforma ao ponto em que ela consegue atender a todos os controles-chave como o ISO27001.

O que foi desenvolvido

Duas frentes avançaram mais durante o desenvolvimento:

Lógica de faturamento

Regras para automatizar a determinação de intenção do cliente quando a TMNZ recebe um pagamento de entrada, incluindo validação da atividade do cliente, correspondência de referências do pagamento com faturas e tratamento de pagamentos a maior, a menor, pagamento integral, escalonamento e casos de borda.

Lógica de precificação

Regras de precificação e descontos desenhadas para decisões de precificação consistentes e auditáveis em toda a plataforma.

Em ambos os casos, o modelo foi o mesmo: as regras ficaram no DecisionRules, os serviços .NET e os workflows n8n as chamavam quando necessário, e as tabelas de decisão subjacentes continuaram editáveis sem passar por liberações da aplicação.

Reflexões do desenvolvimento

A experiência da TMNZ é uma visão útil de onde plataformas de decisão se encaixam naturalmente — e de como elas se conectam a ferramentas nativas de IA. Algumas observações da equipe:

A separação da lógica de negócios do código trouxe benefícios mensuráveis: regras complexas de faturamento e precificação que antes levavam dias para definir e testar puderam ser criadas em horas usando os fluxos visuais de decisão do DecisionRules, e a mesma regra pôde ser reutilizada entre .NET e n8n sem duplicação.

A rastreabilidade e o versionamento que vêm com uma plataforma de decisão gerenciada importaram mais do que a equipe inicialmente esperava, especialmente em um contexto em que cada transação precisa ser auditável em relação à legislação. Fazer o self-host do engine de regras na própria infraestrutura Azure da TMNZ também entregou a execução de baixa latência necessária para transações em serviços financeiros em tempo real — uma consideração importante para qualquer fintech que avalie alternativas hospedadas na nuvem.

Integrar o DecisionRules a workflows agentic e ao MCP se tornou um requisito central para o processo de desenvolvimento: agentes de IA não apenas conseguem executar regras de negócios, mas também inspecionar e explicar essas regras. Ao depurar uma lógica de faturamento complexa ou ao integrar novos membros à equipe, a capacidade de expor definições de regras pela mesma interface usada pelos workflows de automação torna as regras de negócios significativamente mais fáceis de criar, testar e compreender.