Rules-based transaction monitoring applies fixed, human-written conditions to transactions, while AI transaction monitoring uses statistical or machine-learning models to score behaviour and surface anomalies. Neither replaces the other in a supervised bank. Most programmes should keep rules for known typologies and regulatory floors, add models where patterns are too complex to write down, and govern both.
No BSP rule reviewed for this comparison requires or prohibits machine learning in monitoring. BSP's AI governance principles are a voluntary guidance paper, and the figures vendors quote for model performance are rarely comparable across institutions. This piece compares the design trade-offs and the evidence an examiner can ask for, and it does not rely on any benchmark number.
The comparison is written for CTOs and heads of AML who are weighing a model-based product against the rule engine they already run. If you need the basics first, start with our guide to transaction monitoring.
What is the difference between rules-based and AI-driven monitoring?
Rules decide on conditions a person wrote down, and models decide on patterns learned from data.
| Dimension | Rules-based monitoring | AI-driven monitoring |
|---|---|---|
| How it decides | Fixed conditions, such as amount, count, window or counterparty | A model scores behaviour against learned patterns or peer groups |
| Explaining one alert | Direct: the rule, the threshold and the breach | Harder: needs reason codes or feature contributions the analyst can read |
| Known typologies | Strong, because each typology can be written as a scenario | Adequate, but no better than a well-built rule |
| Unknown or complex patterns | Weak, because someone has to imagine the pattern first | Stronger, especially for networks and gradual behaviour change |
| Tuning | Manual threshold changes, tested above and below the line | Retraining and revalidation, with drift monitoring |
| Data needs | Modest | Higher, with clean history and reliable outcome labels |
| Main failure mode | Noise, and evasion by staying under thresholds | Opaque errors, drift and over-trust |
| Governance burden | Rule change control and calibration records | Rule governance plus model validation, inventory and oversight |
The table hides one asymmetry: a rule that is wrong is easy to find and easy to fix, while a model that is wrong may look confident for months.
Where do rules still do the better job?
Rules remain the better tool wherever the requirement is deterministic or the pattern is already understood.
Reporting thresholds are the clearest case, and they sit on the transaction side of the line described in our comparison of payment screening and transaction monitoring. A covered transaction report is triggered by an amount, and no institution wants a probabilistic score deciding whether a fixed threshold was crossed. Structuring below such a threshold is also a known typology, and a rule built on an aggregated variable, such as the sum of outbound transfers over seven days, catches it directly and can be explained in one sentence.
Rules also win on speed to deploy. When BSP or AMLC issues new typology guidance, a rule can be written, tested against historical data and activated within days. A model needs labelled examples that a new typology does not yet have. For institutions with short transaction history or a new product line, rules are often the only option that works on day one.
Where does AI add value that rules cannot?
It adds the most where the signal is spread across many accounts, many weeks or many weak indicators.
Machine learning transaction monitoring suits money-mule networks, for example. Each transfer is small and ordinary alone, and the pattern appears only when many unrelated senders, a new account and fast outbound movement are viewed together. Models can also compare a customer with a peer group, feed on a current customer risk rating, rank alerts so analysts see the likeliest risks first, and help identity and account-opening checks keep pace with synthetic profiles.
The FATF has made a similar point at the policy level. Its report on opportunities and challenges of new technologies for AML/CFT says new technologies can improve the speed, quality and efficiency of AML/CFT measures, and it stresses informed oversight and technology-neutral, outcomes-based policy. That framing matters for a bank. The test is whether the control works and can be evidenced, not whether it is labelled AI.
What do examiners expect to see for either approach?
The same core evidence applies: testing before go-live, documented calibration and independent review.
BSP's Memorandum M-2023-013 is a guidance paper on an effective AML/CTPF transaction monitoring system. It covers system design and pre-implementation testing, risk-based and holistic monitoring, alert and case management, red flags and scenarios, and independent testing. In our reading, a model-based component is part of that system, so the same evidence applies to it.
The AI layer adds a second set of expectations. BSP's Memorandum M-2026-031, Governance Principles for AI in Financial Services, is dated 24 June 2026 and recommends that institutions develop their own AI governance policies and risk management frameworks. It asks for risk interventions across planning, development, validation, deployment and monitoring. Under the Accountability principle, management and stakeholders remain accountable for decisions despite recommendations given by AI systems. GMA's report on the memorandum adds that the principles are voluntary, but BSP describes them as minimum supervisory expectations and applies a shared-responsibility model to outsourced providers.
One caution on explainability. Commentary on the memorandum notes that it does not define a required standard of model explainability. That leaves each institution to set its own test, and a practical one is whether an analyst can say, in plain words, which inputs drove a particular alert.
How should you test a vendor's AI monitoring claim?
Ask for evidence that a compliance officer can verify, not a headline figure.
- 01What was the baseline? Any claimed improvement needs a stated comparison, on a population similar to yours.
- 02What data does the model use, and what does it need from you? Check history length, field quality and how outcome labels are built.
- 03Can it explain one alert? Ask to see the reason an analyst would read for a single case.
- 04What happens when it is wrong? Look for an override path and a record of how often analysts use it.
- 05Who validates it, and how often? The validator should be independent of the team that selected the product.
- 06Can it run in shadow mode? A model that scores live transactions without generating alerts shows its behaviour before it touches the queue.
- 07How are model changes versioned? Retraining should leave a record, the same way a rule change does.
These questions apply equally to a model you build and one you buy, and with a bought model the contract has to give you access to the documentation, because the accountability stays with the institution.
What does a sensible hybrid look like?
Rules handle the floors and the known typologies, models handle prioritisation and the patterns nobody has written down, and analysts make the decisions.
A workable sequence for most institutions has four steps. First, fix the rules, because a model trained on noisy, badly calibrated alerts inherits the noise. Second, use AI in assistive roles where a human still decides, such as alert summaries, triage suggestions and suggested dispositions. Third, run any detection model in shadow mode and compare it with the live rules. Fourth, promote it only after independent validation and a documented review.
Dispositions should feed back into both layers. Closed cases and their outcomes tell you which rules produce only false positives, and they supply the labels a model needs.
How does the choice change for a lean compliance team?
A team of five to fifteen gets more from AI that speeds up investigation than from a detection model that needs data science staff to maintain.
Small teams rarely have the volume of confirmed suspicious cases needed to train a supervised model, and they rarely have a model validation function. They do have a queue to clear. Assistive AI, such as a plain-language summary of why an alert fired or a suggested disposition the analyst confirms, shortens the time per alert without changing what the examiner is shown. Detection models can follow once the data and the validation capacity are in place.
For the wider examination context, see our BSP Circular 950 compliance guide, and for the broader view of AI in banking see from experimentation to execution.
How does Fyscal ARCX approach rules and AI together?
Fyscal ARCX Transaction Monitoring is built as a hybrid. Compliance teams build and own rules in a no-code engine, test them against historical transaction data with a dry run before activation, and can validate them on live transactions in shadow mode, which is available to select clients. Aggregation variables let a team define the window and the count for patterns such as structuring. The AI layer supports analysts with alert summaries, first-pass triage recommendations and suggested dispositions that the analyst confirms or overrides, and it suggests where a rule may need recalibration.
If you want to see how rules, testing and AI assistance fit together in one monitoring workflow, book a walkthrough of Fyscal ARCX and bring a rule set you want to test.