The compliance officer who bought their current transaction monitoring system probably saw a very good demo. Alert accuracy was 90% in the sandbox. Implementation was "6–8 weeks." The vendor had a case study from a Tier-1 bank.

Eighteen months later, the team processes 600 alerts per day, 530 of which are false positives. Two analysts have left. The backlog is three weeks long. An AUSTRAC examination is booked for Q4.

What happened between the demo and now is usually the same story: the sandbox didn't reflect production data, the rules weren't tuned for the actual customer base, and the implementation timeline quietly became six months.

This guide is not a vendor comparison. It is a diagnostic framework for telling effective transaction monitoring software from systems that look good until they're live.

Why Most TM Software Evaluations Go Wrong

Most procurement processes ask vendors to list their features. That is the wrong test.

Features are table stakes. What matters is performance in your specific environment — your customer mix, your transaction volumes, your risk profile. And vendor demonstrations are optimised to impress, not to replicate reality.

Three problems appear repeatedly in post-implementation reviews:

Alert accuracy drops between demo and production. Sandbox environments use curated, clean datasets. Production data is messier: duplicate records, legacy fields, missing counterparty data. Alert models calibrated on clean data degrade when they hit the real thing.

Rule libraries built for someone else. A retail bank in Sydney and a cross-border remittance operator in Singapore do not share transaction patterns. A rule library tuned for one will generate noise for the other. Most vendors deploy the same library for both and call it "risk-based."

"Transparent" models that cannot be tuned. Vendors frequently describe their ML systems as transparent and auditable. The test is whether your team can actually adjust the models when performance drifts, or whether every change requires a vendor engagement.

What "Effective" Means to Regulators

Before comparing systems, it is worth knowing what your regulator will assess. In APAC, the standard is consistent: regulators do not want to see a system that exists. They want evidence it works.

AUSTRAC (Australia): AML/CTF Rule 16 requires monitoring to be risk-based — thresholds must reflect your specific customer risk assessment, not generic defaults. AUSTRAC's enforcement record is specific on this point: both the Commonwealth Bank's AUD 700 million settlement in 2018 and Westpac's AUD 1.3 billion settlement in 2021 cited inadequate transaction monitoring as a direct failure — not the absence of a system, but the failure of one already in place.

MAS (Singapore): Notice 626 (paragraphs 19–27) requires FIs to detect, monitor, and report unusual transactions. MAS supervisory expectations published in 2024 flagged two recurring weaknesses across supervised firms: inadequate alert calibration and insufficient documentation of monitoring outcomes. Both are failures of execution, not of system selection.

BNM (Malaysia): The AML/CFT Policy Document (2023) requires an "effective" monitoring programme. Effectiveness is assessed through examination — specifically, whether the alerts generated correspond to the actual risk in the institution's customer base.

The practical consequence: an RFP that evaluates features without assessing tuning capability, calibration flexibility, and audit trail quality is not evaluating what regulators will look at.

7 Questions to Ask Any TM Vendor

1. What is your false positive rate in a live environment comparable to ours?

This is the single number that determines analyst workload. A false positive rate of 98% means 98 of every 100 alerts require investigation time before the analyst can close them as non-suspicious. At a mid-sized bank processing 500 alerts per day, that is 490 dead-end investigations.

The benchmark: well-tuned AI-augmented systems reach false positive rates of 80–85% in production. Legacy rule-only systems routinely run at 97–99%.

Ask the vendor to show actual data from a comparable client, not an anonymised case study. If they cannot, ask why.

2. How are alerts generated — rules, models, or a combination?

Pure rules-based systems are easy to validate for audit purposes but brittle: they miss patterns they were not programmed to detect, and new typologies go unnoticed until the rules are manually updated.

Pure ML systems can detect novel patterns but are harder to validate and explain to regulators who need to understand why an alert was raised.

Hybrid systems — rules for known typologies, models for anomaly detection — are generally more defensible. Ask specifically: how does the vendor update the rules and models when the regulatory environment changes? What happened when AUSTRAC updated its rules in 2023, or when MAS revised its supervisory expectations in 2024?

3. What does the analyst workflow look like after an alert fires?

Detection is only the first step. Analysts spend more time on alert investigation than on any other compliance task. A system that generates 200 precise, context-rich alerts is worth more operationally than one that generates 500 alerts requiring 40 minutes of manual research each before a disposition decision can be made.

Ask to see the actual analyst interface, not the executive dashboard. Check whether the alert displays customer history, previous alerts, peer comparison, and relevant counterparty data — or whether the analyst has to pull all of that separately.

4. What does a MAS- or AUSTRAC-ready audit log look like?

When a regulator examines your monitoring programme, they review the logic that generated each alert, the analyst's disposition decision, and the written rationale. They check whether high-risk customers received appropriate monitoring intensity and whether there is a documented escalation path for uncertain cases.

Ask the vendor to show you a sample audit log from a recent client examination. It should show: the rule or model that triggered the alert, the analyst who reviewed it, the decision, the rationale, and the time between alert generation and disposition. If the vendor cannot produce this, the system is not regulatory-examination-ready.

5. What does implementation actually take?

Ask for the implementation timeline — from contract to production-ready performance — for the vendor's most recent three comparable deployments. Not the standard brochure. Not the best case. Three actual recent clients.

Specifically: how long from contract signature to go-live? How long from go-live to the point where alert accuracy reached its steady-state level? Those are two different numbers, and the second one is the one that matters for planning.

6. How does the vendor handle model drift?

ML models degrade over time as transaction patterns change. A model trained on 2023 data will underperform against 2026 transaction patterns if it has not been retrained. Ask how frequently models are retrained, who initiates the review, and what triggers a retraining event.

Also ask: who holds the model validation documentation? Model governance is an emerging examination focus for MAS, AUSTRAC, and BNM. The validation record needs to sit with the institution, not only with the vendor.

7. How does the system handle regulatory updates?

APAC's AML/CFT rules change more frequently than in other regions. AUSTRAC updated Chapter 16 in 2023. MAS revised its AML/CFT supervisory expectations in 2024. BNM issued a revised AML/CFT Policy Document in 2023.

When these changes occur, who updates the system — and how quickly? Some vendors treat regulatory updates as professional services engagements billed separately. Others maintain a regulatory content team that pushes updates to all clients. Ask which model applies and get the answer in writing.

Banks vs. Fintechs: Different Needs, Different Priorities

A Tier-2 bank with 8 million retail customers and a PSA-licensed payment institution handling cross-border transfers have different TM requirements. The evaluation criteria shift accordingly.

For banks:

Volume and integration architecture matter first. A system processing 500,000 transactions per day needs different infrastructure than one processing 5,000. Ask specifically about latency in real-time monitoring scenarios and how the system handles peak volumes. Integration with core banking — particularly if the core is a legacy platform — is where implementations most commonly fail.

For fintechs and payment service providers:

Real-time detection weight is higher relative to batch processing. Cross-border typologies differ from domestic banking typologies — the vendor's rule library should include patterns specific to cross-border payment fraud, structuring across multiple jurisdictions, and rapid account cycling. Customer history is often short, which means models that require 12+ months of transaction data to perform will underperform in fast-growing books.

Total Cost of Ownership: The Number Most RFPs Undercount

The licence fee is the visible cost. The actual costs include:

• Implementation and integration: Typically 2–4x the first-year licence cost for a mid-size institution. A vendor that quotes "6–8 weeks" for implementation should be asked for the last five clients' actual implementation timelines before that number is used in any business case.
• Analyst capacity: A high false positive rate is not just an accuracy problem — it is a staffing cost. At a 97% false positive rate, a team processing 400 daily alerts spends approximately 85% of its investigation time on non-suspicious transactions. A 10-percentage-point improvement in accuracy frees roughly 2,400 analyst-hours per year at a 30-person operations team.
• Regulatory risk: The cost of an enforcement action should be in the risk-adjusted total cost of ownership calculation. Westpac's 2021 settlement was AUD 1.3 billion. The remediation programme that followed cost additional hundreds of millions. Against those figures, the difference between a well-tuned system and an adequate one looks very different on a business case.

What Tookitaki's FinCense Does Differently

FinCense is Tookitaki's transaction monitoring platform, built specifically for APAC financial institutions.

The core technical differentiator is federated learning. Most ML-based TM systems train models on a single institution's data, which limits pattern diversity. FinCense's models learn from typology patterns across the Tookitaki client network — without sharing raw transaction data between institutions. The result is detection capability that reflects a broader range of financial crime patterns than any single institution's data could produce.

In production deployments across APAC, FinCense has reduced false positive rates by up to 50% compared to legacy rule-based systems. In analyst workflow terms: a team processing 400 alerts per day at a 97% false positive rate could reduce that to approximately 200 alerts at the same investigation standard — roughly halving the time spent on non-productive reviews.

The platform is pre-integrated with APAC-specific typologies for AUSTRAC, MAS, BNM, BSP, and FMA regulatory environments. Regulatory updates are included in the standard contract.

Ready to Evaluate?

If your institution is reviewing its transaction monitoring system or implementing one for the first time, the seven questions in this guide are a starting framework. The answers will tell you more about a vendor's actual capability than any feature demonstration.

Book a discussion with Tookitaki's team to see FinCense in a live environment calibrated for your institution type and region. Or read our complete guide to "what is transaction monitoring? The Complete 2026 Guide" before the vendor conversations begin.