Wie TMNZ auditierbares Decision-Management in seiner Steuerzahlungsplattform aufbaut

Der Ausgangspunkt

Die Plattform von TMNZ verarbeitet Tax-Pooling-Transaktionen, die gleichzeitig dem Income Tax Act 2007, dem Tax Administration Act 1994 und dem AML/CFT Act 2009 entsprechen müssen. Im Gegensatz zu den meisten Fintechs, bei denen Compliance nur als Overlay aufgesetzt ist, ist das Kerngeschäftsprodukt von TMNZ untrennbar mit dem regulatorischen Rahmen verbunden: Jede Transaktion muss anhand der Primärgesetzgebung nachverfolgbar auditierbar sein, und jede Regel, die Preisgestaltung, Abrechnung und Zahlungsabgleich steuert, muss auf ihre gesetzliche Grundlage zurückführbar sein. Als diese Regeln in Code, Tabellenkalkulationen oder nicht dokumentierten Prozessen lebten, ergab sich eine eingeschränkte Skalierbarkeit, steigende Kosten für den Betrieb sowie die Unfähigkeit, Regeln mit der Gewissheit weiterzuentwickeln, dass der Audit-Trail standhält.

Das Team verfolgt ein klares architektonisches Prinzip: Geschäftsregel-Logik so weit wie möglich vom Anwendungscode entkoppeln, damit Regeln unabhängig von Feature-Releases verfasst, auditierbar und weiterentwickelt werden können.

Warum TMNZ DecisionRules ausgewertet hat

TMNZ hat mehrere Rule Engines bewertet – sowohl Open Source als auch kommerzielle. Die Vorauswahl musste strenge Kriterien erfüllen, darunter Datenhoheit, die Integration in den bestehenden AI-nativen Tool-Stack, die Zugänglichkeit für Teams übergreifend sowie Sicherheit. DecisionRules erfüllte die Kriterien, die das Team priorisierte:

So wurde es eingerichtet

DecisionRules wurde self-hosted in der Azure-Umgebung von TMNZ mit SSO und Datenbankintegration bereitgestellt. Das Team verband es über API-Aufrufe an den DecisionRules-Solver mit .NET-Microservices und integrierte es in n8n agentische Workflows – einschließlich über MCP (Model Context Protocol) – sodass AI-Agents und Automations-Workflows dieselben zentralen Regeln aufrufen konnten wie die Anwendungsschicht. Die Absicht war unkompliziert: eine Quelle der Wahrheit für die Regel-Logik, die von überall im Stack aufrufbar ist – unabhängig davon, ob der Aufrufer ein Microservice, ein Automations-Workflow oder ein AI-Agent ist.

Das Setup war so ausgelegt, dass DMN-Tabellen außerhalb des Anwendungscodes erstellt und aktualisiert werden können, während Entwickler die Dateninputs und die API-Integration übernehmen. Prozessabläufe wurden mit Decision-Task-Shapes modelliert, die mit den zugrunde liegenden DMN-Tabellen verknüpfen.

Die kürzlich hinzugefügten Funktionen rund um native Datenbankintegration und automatisiertes Testen haben die Plattform so weit angehoben, dass sie alle wichtigen Kontrollen wie ISO27001 erfüllen kann.

Was gebaut wurde

Zwei Bereiche kamen beim Aufbau am weitesten:

Abrechnungslogik

Regeln zur Automatisierung der Bestimmung der Kundenintention, wenn TMNZ eine eingehende Zahlung erhält – einschließlich der Validierung der Aktivität des Clients, des Abgleichs von Zahlungsreferenzen mit Rechnungen sowie des Umgangs mit Überzahlungen, Unterzahlungen, vollständigen Zahlungen, Eskalationen und Sonderfällen.

Preislogik

Preis- und Rabattregeln, die für konsistente, auditierbare Preisentscheidungen über die gesamte Plattform hinweg entwickelt wurden.

In beiden Fällen war das Modell gleich: Die Regeln lagen in DecisionRules, die .NET-Services und n8n-Workflows riefen sie bei Bedarf auf, und die zugrunde liegenden Decision-Tabellen blieben editierbar, ohne durch Anwendung-Releases zu müssen.

Reflexionen aus dem Aufbau

Die Erfahrung von TMNZ zeigt sehr anschaulich, wo Decision-Plattformen natürlich passen – und wie sie mit AI-nativem Werkzeug-Setup verbunden sind. Ein paar Beobachtungen aus dem Team:

Die Trennung von Geschäftslogik vom Code brachte messbare Vorteile: Komplexe Abrechnungs- und Preisregeln, die zuvor Tage brauchten, um sie zu definieren und zu testen, konnten in Stunden mithilfe der visuellen Decision-Flows von DecisionRules erstellt werden – und dieselbe Regel konnte ohne Duplikate über .NET und n8n hinweg wiederverwendet werden.

Die Nachverfolgbarkeit und Versionierung , die mit einer verwalteten Decision-Plattform einhergehen, waren wichtiger als das Team anfangs erwartet hatte – insbesondere in einem Kontext, in dem jede Transaktion gegen die Gesetzgebung auditierbar sein muss. Das Self-Hosting der Rule Engine auf der eigenen Azure-Infrastruktur von TMNZ lieferte zudem die geringe Latenz, die für Echtzeit-Transaktionen im Finanzdienstleistungsumfeld erforderlich ist – ein wichtiger Gesichtspunkt für jedes Fintech, das cloud-gehostete Alternativen evaluiert.

Die Integration von DecisionRules in agentische Workflows und MCP wurde zu einer zentralen Anforderung an den Entwicklungsprozess: AI-Agents können nicht nur Geschäftsregeln ausführen, sondern sie auch untersuchen und erklären. Beim Debuggen komplexer Abrechnungslogik oder beim Onboarding neuer Teammitglieder macht die Möglichkeit, Regeldefinitionen über dieselbe Oberfläche bereitzustellen, die auch von Automations-Workflows genutzt wird, Geschäftsregeln deutlich leichter, sie zu bauen, zu testen und zu durchdenken.