Why Auditra Forensics Dropped Machine Learning for Rule-Based Fraud Triage

I was a stay-at-home mom when I started noticing serious financial problems in my local municipality. I realised there was a massive gap between the complex fraud happening in public funds and the tools available to prove it. I discovered that investigators were trying to trace complex patterns, but they had scarce ways to produce reproducible audit trails that could withstand scrutiny. The standard approach of staring at massive spreadsheets simply doesn't work when you are dealing with thousands of transactions. Trying to manually trace financial anomalies across hundreds of thousands of rows inevitably leads to human error and creates massive delays in the investigation. I decided to use my background in systems architecture and in data analytics to build a tool I felt was missing. I wanted to create an engine that could take a chaotic, multi-million-row ledger and efficiently produce a structured review queue. I didn't just want to flag anomalies; I wanted to build a system that gave investigators a reliable, transparent starting point so they could focus their expertise on actual analysis rather than data wrangling.

What worked was giving every report a permanent, verifiable fingerprint of the results. Our engine stamps each output with a cryptographic digest, so an investigator can prove months later that the analysis they are relying on is the exact one the engine produced. In forensics, trust is the biggest barrier. That feature gives investigators verifiable proof that the data hasn't been altered, which is crucial when their findings are being reviewed. What flopped was building elaborate internal test harnesses to simulate real world data. I spent months constructing realistic test ledgers before realising the only thing that mattered was what happened when the system ingested a genuinely messy file. My test data was too clean and too predictable. It validated code paths but not reality. I wasted the effort, then learned that I needed to test with real historical ledgers. The hard lesson was to trust the mess, not the simulation.

We are currently in pre-pilot, so we are engineering against industry standards rather than firsthand complaints. The gap we see is trust. Investigators need to defend their findings in a court of law, but most modern tools rely on probability scores that are difficult to unpack. When a defense attorney asks why a specific transaction was flagged, saying "the algorithm gave it a high score" is not an explainable answer. This is the exact kind of issue investigators are most likely to struggle with when they are put on the stand. It is for this very reason that we handled this by building a deterministic engine. Every flagged transaction is backed by strict ACFE rule predicates and reproducible math, producing an identical cryptographic hash every time. Instead of giving investigators a probability score that they have to explain away, we give them a transparent, rule-based review queue that they can confidently defend under cross-examination.

Many people think forensic fraud detection is about finding everything that looks suspicious. In reality, finding anomalies is easy; the hard part is the triage. If you flag 65% of a ledger as an anomaly, which standard rules often do on distressed ledgers, the investigator has no idea where to start. They are drowning in data, and a tool that just adds to the noise creates a massive bottleneck for the investigation team. The market gets this wrong by focusing on AI hype instead of workload reality. I solved this by focusing entirely on the investigator's actual review capacity. The engine gives them a narrow "Direct Review" queue of high-confidence leads, and moves the rest to secondary queues. My goal was to provide a tool that respects their time by putting the most critical, high-confidence leads at the top, allowing them to focus their forensic expertise where it matters the most.

We are launching our first official pilot engagements with insolvency practitioners and CFEs. I am focused on getting the engine into the hands of the professionals it was built for so I can refine the workflow based on their real-world investigations. Following that, we will expand the engine's schema-agnostic architecture into the crypto asset domain. We will then be adapting our deterministic triage rules to trace on-chain anomalies with the same cryptographically verifiable chain of custody that we are currently providing for fiat ledgers.

1 million row ledgers processed deterministically in under 15 minutes.

I'm a self-taught systems architect by trade and I have a diploma in Data Analytics. I didn't come from a traditional accounting background, which actually gave me an advantage because I was not constrained by legacy thinking. I discovered that the forensic industry needed rigorous, mathematically sound data engineering, not another AI wrapper. Today, I am proud that I am able to build complex, high-volume data systems where memory management and reproducibility are non-negotiable. I combined that deep technical background with intensive research into ACFE forensic standards. I wanted to build an engine that prioritises mathematical transparency over trendy tech, ensuring that every line of code serves the ultimate goal of creating an auditable, reliable artifact.

I spent months trying to train machine learning models to find anomalies and I kept failing because the models couldn't produce baselines that made sense for an audit-ready system. I eventually realised that while machine learning is powerful for pattern recognition, forensic investigators need strict mathematical transparency so they can verify the results themselves. That was when I pivoted to a deterministic, rule-based architecture. I learned that for this specific market, an algorithm isn't judged by how smart or complex it is, but by whether an independent expert can trace how the output was generated. That realisation fundamentally changed how I engineer advanced auditing systems and data-triage frameworks for diverse global markets.