How TMNZ builds auditable decision management into its tax payment platform

The starting point

TMNZ's platform processes tax pooling transactions that must comply with the Income Tax Act 2007, Tax Administration Act 1994, and AML/CFT Act 2009 - simultaneously. Unlike most fintechs, where compliance is an overlay, TMNZ's core product is inseparable from the regulatory framework: every transaction is auditable against primary legislation, and every rule governing pricing, billing, and payment matching must be traceable to its legislative basis. When those rules lived in code, spreadsheets, or undocumented processes, the result was constrained scalability, rising cost-to-serve, and an inability to evolve rules with the confidence that the audit trail would hold.

The team adopts a clear architectural principle: keep business rule logic de-coupled from application code wherever possible, so that rules can be authored, audited, and evolved independently of feature releases.

Why TMNZ evaluated DecisionRules

TMNZ assessed several rule engines, both open-source and commercial. The shortlist had to clear a strict bar on data sovereignty, integration with the existing AI-native tool stack, cross-team accessibility, and security. DecisionRules met the criteria the team prioritised:

How it was set up

DecisionRules was deployed self-hosted on TMNZ's Azure environment with SSO and database integration. The team connected it to .NET microservices through API calls to the DecisionRules solver, and integrated it into n8n agentic workflows - including via MCP (Model Context Protocol) - so that AI agents and automation workflows could invoke the same central rules as the application layer. The intent was straightforward: one source of truth for rule logic, callable from anywhere in the stack, whether that caller is a microservice, an automation workflow, or an AI agent.

The setup was designed so that DMN tables could be authored and updated outside of application code, with developers handling data inputs and API integration. Process flows were modelled with Decision Task shapes linking through to the underlying DMN tables.

The recently added features around native database integration and automated testing have uplifted the platform to where it can meet all the key controls like ISO27001.

What was built

Two areas progressed furthest during the build:

Billing logic

Rules for automating customer intent determination when TMNZ receives an inbound payment, including validation of client activity, matching payment references to invoices, and handling overpayment, underpayment, full payment, escalation, and edge cases.

Pricing logic

Pricing and discount rules designed for consistent, auditable pricing decisions across the platform.

In both cases, the model was the same: the rules sat in DecisionRules, the .NET services and n8n workflows called them when needed, and the underlying decision tables stayed editable without going through application releases.

Reflections from the build

TMNZ's experience is a useful look at where decision platforms fit naturally - and where they connect to AI-native tooling. A few observations from the team:

The separation of business logic from code delivered measurable benefits: complex billing and pricing rules that previously took days to define and test could be authored in hours using DecisionRules' visual decision flows, and the same rule could be reused across .NET and n8n without duplication.

The traceability and versioning that come with a managed decision platform mattered more than the team initially expected, particularly in a context where every transaction needs to be auditable against legislation. Self-hosting the rule engine on TMNZ's own Azure infrastructure also delivered the low-latency execution required for real-time financial services transactions - an important consideration for any fintech evaluating cloud-hosted alternatives.

Integrating DecisionRules with agentic workflows and MCP became a core requirement for the development process: AI agents can not only execute business rules but also introspect and explain them. When debugging complex billing logic or onboarding new team members, the ability to surface rule definitions through the same interface used by automation workflows makes business rules significantly easier to build, test, and reason about.