AI transaction monitoring uses machine learning and other analytical techniques to assess financial activity in context. It can identify unusual behaviour, connect related transactions and help teams prioritise investigations. The strongest approach combines that intelligence with clear rules, reliable data and a defined response when risk is detected.
For a payment provider, a bank or a growing fintech, the problem is familiar. Transaction volumes increase, new payment routes appear and the alert queue keeps expanding. Adding another rule may address one fraud pattern, but it can also create more work for analysts. Eventually, the question becomes whether the monitoring process helps people make better decisions or simply produces more alerts.
AI can help change that balance. Its value comes from recognising relationships that a single threshold cannot explain, while keeping each decision traceable.
Why rules alone leave gaps
A rule checks whether an event meets a predefined condition. It might flag a transfer above a certain amount or several payments within a short period. Rules are useful because teams can understand, test and change them. They also provide a practical way to enforce specific policies.
The difficulty is context. A large transfer may be normal for a wholesale business and unusual for a personal account. Several payments in one evening might indicate account misuse, or they might reflect a customer buying travel tickets. Treating both situations alike creates unnecessary friction.
Rules can become difficult to maintain as exceptions accumulate. One team adds a threshold for a new channel. Another changes a customer segment. An older rule continues running without a clear owner. The result can be overlapping alerts and uncertainty about which controls still contribute to detection.
Moving beyond rule-based monitoring therefore starts with reviewing the existing rules. AI cannot repair unclear policies or missing transaction data by itself.
How AI transaction monitoring works
The process begins with transaction information such as amount, time, currency, channel and counterparty. Customer history and account relationships add context. Where available and appropriate, device or session signals can contribute to the assessment.
These inputs become features: measurable descriptions of behaviour. Examples include how much a payment differs from a customer’s usual amount, how quickly funds leave an account after arriving, or how many previously unseen beneficiaries receive transfers. A model uses those features to estimate risk or identify unusual activity.
The output then enters a decision process. A score might prioritise a case, trigger additional checks or contribute to an immediate payment decision. The action depends on the use case, the institution’s policy and the point at which the monitoring system operates.
This distinction matters. A model can identify an unusual transaction without proving fraud or money laundering. An investigator still needs evidence, and the organisation needs a proportionate response.
The difference between fraud monitoring and AML monitoring
Fraud monitoring often asks whether a transaction is legitimate and whether intervention is needed before a loss occurs. Anti-money laundering monitoring asks whether activity may indicate the movement or concealment of illicit funds. These questions overlap, but their timelines and outcomes can differ.
A stolen-account payment may require an immediate challenge. A series of transfers between related businesses may require analysis over a longer period. The same transaction can be relevant to both teams, yet each team may need different evidence and a different escalation route.
Connecting transaction monitoring with the wider AML and KYC process helps preserve this context. The objective is a coherent view of activity without treating every risk as the same type of problem.
What AI adds to the investigation
Behavioural context
A model can assess activity relative to a customer’s history or a relevant peer group. This helps distinguish unusual behaviour from behaviour that is simply high in volume. Peer groups need care: a newly established exporter should not automatically be compared with a domestic retail customer.
Relationships between accounts
Graph analysis represents connections between entities. Investigators can examine shared beneficiaries, devices or transaction paths. A relationship is a reason to investigate, not proof of wrongdoing. Shared infrastructure and legitimate business relationships can create similar patterns.
The BIS Project Aurora research explored machine learning, network analysis and privacy-enhancing technologies using synthetic payment data. Its proof-of-concept setting matters when interpreting results.
Alert prioritisation
AI can help order alerts according to their likely relevance. This is valuable when analysts have limited time, but prioritisation must not quietly become deletion. Lower-ranked activity still needs an appropriate review strategy, sampling or another control that helps identify missed risk.
A practical example of contextual monitoring
Consider an illustrative payment business that monitors outgoing transfers. A long-standing customer receives several deposits and sends funds to a new beneficiary shortly afterwards. Each transfer sits below the business’s existing amount threshold.
A rule looking only at individual amounts may not react. A broader assessment could consider the sequence, the change from previous behaviour and connections between the receiving account and other activity. Together, these signals may justify review.
The investigation could still reveal a legitimate explanation, such as a customer collecting money for a group purchase. That outcome is useful feedback. The system should record why the case was closed so the team can distinguish a valid behavioural exception from a weak detection pattern.
This example illustrates a workflow, not a measured Formica customer result. The benefit depends on the quality of available data and the controls used in deployment.
How to reduce false positives without hiding risk
A smaller alert queue is not enough to demonstrate improvement. Teams should ask what happened to detection coverage, investigation quality and customer outcomes at the same time.
Start with a baseline that captures alert volumes, review time and confirmed outcomes. Test the proposed model against historical periods that were not used for training. Keep the time order intact so the model cannot benefit from information that would have been unavailable when a transaction occurred.
Then compare performance across meaningful segments. A result that looks strong overall may be weak for new customers, cross-border activity or a recently introduced product. False positives and missed cases should be reviewed together.
The FATF report on new technologies for AML/CFT discusses potential efficiency gains alongside the conditions needed for responsible adoption.
Introducing AI without losing control
A practical rollout begins with a defined problem, such as repetitive alerts in one payment channel. Running the model in shadow mode allows the team to compare its outputs with existing decisions before it affects customers.
Investigators should see the relevant signals, the source information and the version of the model used. They also need a way to challenge an output and record their reasoning. An explanation that says only “high risk” is not enough to support an investigation.
Models require monitoring after deployment. Customer behaviour changes, fraud tactics evolve and data feeds fail. A system that performed well during a pilot can become less reliable later. Define who reviews performance, when retraining is considered and how a previous version can be restored.
Self-learning should not mean uncontrolled production changes. Training, validation and release are separate decisions, even when parts of the process are automated.
Bringing intelligence into the monitoring workflow
Formica AI supports hybrid monitoring that combines rules with AI models, alongside graph-based analysis. Explore Formica AI Transaction Monitoring to discuss how those capabilities could fit your transaction flows.
Begin that conversation with the decisions your team needs to improve. Which alerts consume the most time? Where is customer context missing? Which actions must happen before payment completion? Clear answers make it easier to design monitoring that is useful in daily operations.
Frequently asked questions
Can AI transaction monitoring replace rules?
It can complement or replace selected detection rules where testing supports the change. Many organisations retain a hybrid approach because explicit policies and learned patterns serve different purposes.
Does an AI alert prove money laundering?
No. It identifies activity that may need investigation. A model score is an analytical signal, and conclusions require supporting evidence and the appropriate compliance process.
Is all AI transaction monitoring real time?
No. Monitoring can operate before a transaction completes, shortly afterwards or across longer historical periods. The architecture and business objective determine the timing.
What data is needed to start?
Consistent transaction records, reliable customer identifiers and usable historical outcomes are a strong foundation. The exact requirements depend on whether the goal is detection, prioritisation or investigation support.
