Mongolian fintech pioneer chooses ThirdEye to power its Australian compliance operations.
As we close out the year, weāve been reflecting on what weāve learned from working alongside dozens of risk and compliance teams through rule reviews, implementations, and optimisation sessions.
One pattern stands out: the teams getting the most value from their AML technology arenāt necessarily the ones with the most sophisticated rules. Theyāre the ones who truly understand what their rules are doing and why.
Hereās what weāve learned, and some practical actions you can take in 2026 to strengthen your financial crime prevention.
The rule understanding problem
Throughout our client reviews this year, weāve seen that the most common challenges arenāt technical. Theyāre organisational. And the biggest of these? Inherited rules that nobody fully understands.
Team members leave, often without a proper handover. The new person is left trying to make sense of rules that exist only in the departed personās head. Weāve found that if you canāt explain a rule to a regulator, youāve usually inherited it rather than created it.
The three-question test
Hereās a simple test for each of your rules:
- What does this rule detect?
- Why was this threshold set at this level?
- What risk in your risk assessment does this address?
If you canāt answer all three for a rule, thatās your starting point for January. And once youāve worked out the answers, document them, so your successor isnāt in the same situation you inherited.
Documentation that actually works
The good news is that documentation doesnāt need to be complicated. Weāve seen clients transform their rule reviews simply by using the More Information section in ThirdEye to record what each rule does, why it exists, and any decisions about changes.
When we return for follow-up reviews with these clients, we spend our time discussing rule effectiveness rather than trying to work out what rules are supposed to do. Thatās time well spent.
One useful trick: if you copy a rule expression into an AI tool like ChatGPT and ask it to explain what the rule does, it will return a plain-language explanation of the code. It wonāt tell you why you have the rule or whether itās effective (that requires your expertise), but itās a helpful starting point for understanding inherited logic.
Getting rule tuning right
Once you understand your rules, the next question is: are they effective?
The teams doing this well use clear, specific closure reasons that tell a story. One client used āinternal transferā to flag alerts when their funds-in-and-out rule triggered on transfers between two accounts held by the same customerāperfectly normal behaviour that wasnāt suspicious.
This gave them the data to demonstrate wasted effort to their IT team and build a case for improving the data sent to ThirdEye. Thatās tuning working as it should.
Compare this to what we see too often: every alert is closed as āfalse positiveā. That tells us nothing. We canāt distinguish between a rule thatās somewhat useful and one thatās completely useless, which means we canāt advise whether to tune it or remove it entirely.
Why tuning doesnāt happen
Weāve seen analysts who know a rule is useless, but nobody does anything about it. The reasons vary: nobody speaking up, nobody listening, overly complex change processes, fear of modifying what a predecessor set up, and concern about what regulators might think.
None of these should stop you. Rules can be changed, and our customer success team is here to help. What matters is having a work environment and process that encourages improvement rather than inhibiting it.
The testing discipline
In our rule lifecycle session, we stressed one message above all: test your changes before making them live.
Hereās what happens when you donāt. One client decided to raise a threshold from $5,000 to $8,000. Theyād reviewed all the lower-value alerts and had sound justification for the change. They figured they didnāt need to test it since the existing rule already picked up transactions over $8,000.
The next day, they got hundreds of alerts. Theyād accidentally set the threshold to $800 instead of $8,000.
A simple test in draft mode would have caught this. Their team was not best pleased having to close all those alerts.
Our advice: take the tortoise approach. Adjust one rule, test it, make it live, then move on to the next. Slow and steady beats chaotic parallel changes every time.
Automation you might be missing
Throughout our ThirdEye Explore sessions this year, we showcased features that are available but underutilised. If youāre in Australia or New Zealand and still manually entering regulatory reports through online portals, youāre doing extra work and increasing your risk of human error.
Australian users can automatically submit SMRs, IFTIs, and TTRs to AUSTRAC. New Zealand users can submit STRs and PTRs directly to the FIU through their B2B interface.
Yes, the initial testing process with AUSTRAC or the FIU can be slow. But itās a one-off setup compared to ongoing manual effort every time you submit a report. Clients whoāve been through this process tell us it was well worth it. Not just for time savings, but for the end-to-end audit trail when regulators come calling. (Learn more about our suspicious activity reporting and regulatory reporting capabilities)
Similarly, if youāre managing cases through Word documents and spreadsheets, that approach might work with a handful of cases. But as financial crime becomes more complex and regulatory expectations rise, case management provides a more streamlined process with full audit capability. Itās simple to enable whenever youāre ready.
The data foundation
Good data is the key to good outcomes. But itās something many AML teams struggle with. They need to work with IT to get suitable, comprehensive data into ThirdEye, and changing personnel can mean the reasoning behind data decisions gets lost.
The key task for AML teams is to take time to understand your data: whatās being loaded, whatās not, and the quality of what you have. Remember that data can be changed: youāre not stuck with what you decided on day one.
One thing we see frequently: clients with lots of transaction properties they never use. Those properties add no value and just create noise in the interface. You can remove them. The same applies to customer and account properties.
Watch your error handling
A data load error indicates a transaction, customer, or account wasnāt loaded, potentially leaving suspicious activity undetected. Errors should be treated seriously.
Weāve seen cases where the AML team isnāt aware of any errors, and IT hasnāt done anything about them. Make sure you have a process to check and rectify errors, then reload the corrected data.
Three actions for January 2026
If you want to start the new year stronger, hereās where to focus:
- Understand your data. Know whatās being loaded, assess its quality, and have a process for addressing errors.
- Understand and document your rules. Use the three-question test, record your answers, and have a process for ongoing tuning.
- Build a culture that encourages change. The most common blockers arenāt technical; theyāre organisational. Make sure your team can speak up about ineffective rules and that thereās a clear path to improvement.
Weāre here to help
If youāre in any of these situations (rules you donāt understand, tuning youāve been putting off, automation you havenāt enabled), get in touch with our customer success team. Weāve helped dozens of teams improve their use of ThirdEye this year, and weāre ready to do the same for you.
Thanks for being part of our ThirdEye community in 2025. Weāll see you in the new year.
This article is based on our latest ThirdEye Explore webinar about AML learnings in 2025. You can watch the full webinar and previous episodes in the ThirdEye Explore series on our website under Resources.