Stop Monitoring Yesterday’s Transactions. Monitor the One That Happened Three Seconds Ago.
Detection rules don’t fail because they’re badly written. They fail because they receive yesterday’s data. See how webhook-delivered bank data changes automated transaction monitoring from a retrospective reporting exercise into genuine real-time compliance infrastructure.
TL;DR: Most automated transaction monitoring systems optimise detection logic. The real bottleneck is the data layer. Even the best rule engine cannot detect transactions it hasn’t received. If bank connectivity introduces latency or incomplete coverage, automated transaction monitoring analyses history – not live financial activity.
Introduction
Every compliance team asks the same question.
“How good are our monitoring rules?”
Almost nobody asks the question that determines whether those rules work at all.
“When did the data arrive?”
Those sound like the same conversation.
They’re not.
A rule that identifies suspicious activity in 200 milliseconds is still seventeen hours late if the transaction reached the platform through an overnight batch file.
The algorithm succeeded.
The architecture failed.
That’s the distinction regulators, auditors and engineering teams eventually discover the hard way.
“When I review an automated transaction monitoring platform, I don’t begin with the rule engine. I begin with the timestamp on the webhook payload. Detection logic can only analyse the present if the bank data arrives in the present. Otherwise, even perfect rules become historical reporting.” – Yuri, Technical Lead at Finexer
This guide is written from the perspective of the infrastructure layer that powers real-world compliance systems. Rather than focusing on AML theory or rule design, it examines the engineering mechanics, such as Open Banking connectivity, webhook delivery, data normalisation and event latency, which determine whether automated transaction monitoring works reliably in production. The examples reflect how UK platforms build monitoring architectures using FCA-authorised AIS infrastructure and structured bank data.
Why Monitoring Logic Fails Before It Even Runs
Automated transaction monitoring is only as fast as the slowest link feeding it data, and that link is almost always the connection to the bank, not the detection algorithm sitting on top of it.
Most monitoring failures aren’t logic failures. A rule engine that correctly flags rapid fund movement, structuring patterns, or transfers to high-risk counterparties still produces a compliance gap if the transaction data it’s running against is six hours stale. The rule was never wrong. The data arrived too late for the rule to matter.
This is the distinction that separates automated transaction monitoring systems that hold up under regulatory review from ones that only look good in a product demo: event-driven data delivery versus scheduled batch imports.
What the Webhook Payload Actually Looks Like
A real-time transaction event doesn’t arrive as a line in a CSV. It arrives as a structured JSON object, fired the moment the bank posts the transaction, typically within a few hundred milliseconds of settlement.
A representative payload looks like this:
{
“event”: “transaction.created”,
“account_id”: “acc_8f2a91”,
“transaction”: {
“id”: “txn_5c7e13”,
“amount”: 12500.00,
“currency”: “GBP”,
“counterparty”: {
“name”: “Example Ltd”,
“sort_code”: “20-xx-xx”,
“account_number”: “xxxxxx”
},
“category”: “transfer”,
“timestamp”: “2026-07-13T09:41:07Z”
},
“delivered_at”: “2026-07-13T09:41:07.340Z”
}
The delivered_at field matters more than most compliance teams realise. It’s the difference between a monitoring rule that evaluates a transaction as it happens and one that evaluates it after the fact, once someone finally imports the file. A rule engine consuming this payload can flag the £12,500 transfer to a counterparty with no prior history the same second it lands, not the next morning.
Real-Time vs Batch: What Actually Changes
Batch-fed monitoring and event-fed monitoring can run identical detection logic and still produce completely different compliance outcomes, because the input timing changes everything downstream.
A batch import that runs once at 2am means every transaction between 2am yesterday and 2am today is invisible to the monitoring system until the next cycle. If a client moves £40,000 across three accounts at 9am, the monitoring rule doesn’t see it until roughly seventeen hours later. An event-driven system sees it in the payload above, within a few hundred milliseconds of the bank posting it.
This isn’t a marginal latency difference. It’s the difference between monitoring that operates on current financial activity and monitoring that operates on yesterday’s financial activity while calling itself real-time. For platforms building or evaluating the underlying data layer, why webhook reliability matters at the infrastructure layer covers the exact failure mode where a feed works reliably in sandbox testing and then drops events under production load, which is a separate engineering problem from detection logic entirely.
Why Partial Bank Coverage Breaks Detection Regardless of Logic Sophistication
The most sophisticated monitoring rule engine produces incomplete results if it’s only ever fed data from three or four of a client’s bank accounts.
A client holding accounts across a high-street bank and a challenger bank creates a monitoring blind spot the moment the data provider only connects to one of them. The rule engine isn’t wrong: it correctly analyses everything it can see. What it can’t see is the activity moving through the unconnected account, which is precisely where structuring behaviour tends to concentrate once someone is aware a monitoring system exists.
This is a data completeness problem, not a detection-logic problem, and it’s the one compliance teams most consistently underweight when evaluating automated transaction monitoring systems. A monitoring stack is only as good as its weakest bank connection.
The Architecture: Where Detection Logic Sits Relative to the Data Layer
A production automated transaction monitoring system separates into three layers, and each one depends entirely on the layer beneath it working correctly.
| Architecture Layer | Role in Automated Transaction Monitoring |
|---|---|
| Layer 1 – Bank Connectivity | Retrieves transaction data directly from UK banks through Open Banking AIS, with customer consent, and delivers events via real-time webhooks. This layer determines bank coverage and data latency: limitations here cannot be corrected further up the stack. |
| Layer 2 – Data Normalisation | Standardises bank-specific transaction data into a consistent JSON schema, eliminating the need to build and maintain separate parsers for each bank. This creates a reliable data foundation for downstream monitoring systems. |
| Layer 3 – Detection Logic | Applies rule engines, pattern recognition and anomaly detection to the normalised real-time data stream, identifying unusual amounts, rapid fund movements and high-risk counterparties. Although this is the layer most vendors promote, it is only as effective as the connectivity and data quality provided by Layers 1 and 2. |
For platforms building detection that distinguishes normal recurring activity from genuine anomalies, pattern-detection logic covers the adjacent problem of separating expected recurring transactions from the anomalies monitoring is meant to catch. Transaction monitoring and AML screening solve related but distinct problems, and automated AML screening in practice covers how screening at onboarding differs from the continuous monitoring this architecture supports.
Finexer’s Data (AIS): The Layer 1 and Layer 2 Infrastructure
Compliance teams building automated transaction monitoring need Layer 1 and Layer 2 solved reliably before Layer 3 detection logic has any real value.
Finexer’s Data (AIS) product retrieves transaction data directly from a UK bank account once the customer authenticates and consents, delivering structured JSON per transaction via webhook as events occur, rather than a periodic batch import.
Combined with Finexer’s Verification product, which confirms account holder identity at onboarding through bank-based name matching, platforms get a verified starting point for the account before the continuous monitoring feed begins tracking its activity.
- Structured JSON transaction data delivered per bank, so Layer 3 detection logic runs against a consistent schema
- Real-time webhooks firing as transactions post, not on a batch schedule
- Up to 7 years of transaction history for pattern baselines and audit evidence
- Multi-account access from a single consent, closing the challenger-bank blind spot
- 99% UK bank coverage
- FCA-authorised AISP and PISP (FRN925695)
Finexer does not build the rule engine, risk scoring, or suspicious activity reporting tools sitting on top of this feed. Platforms own Layer 3. Finexer provides the data layer underneath it.
What Is Automated Transaction Monitoring?
Automated transaction monitoring is a software system that continuously analyses bank transaction data to detect patterns indicating money laundering risk, fraud, or other compliance-relevant anomalies.
Its accuracy depends entirely on data timing and completeness: a system fed real-time, structured data across all of a client’s accounts will catch what a system fed overnight batch files from two or four accounts cannot, regardless of how the detection rules themselves are written.
Are automated transaction monitoring systems required by law?
Yes, UK platforms with AML obligations under the Proceeds of Crime Act 2002 and the Money Laundering Regulations 2017 must monitor client financial activity throughout the relationship, not only at onboarding. Manual, periodic review does not satisfy the continuous monitoring requirement at any meaningful transaction volume.
What’s the difference between real-time and batch transaction monitoring?
Real-time monitoring analyses transaction data the moment it’s posted by the bank, typically delivered via webhook within a few hundred milliseconds, while batch monitoring processes data on a fixed schedule, such as once overnight. The gap between the two is the exact window during which suspicious activity goes undetected.
Why does bank coverage affect monitoring accuracy?
A client’s transaction activity split across multiple banks means a monitoring system connected to only some of those accounts has a structural blind spot, regardless of how well its detection logic performs on the accounts it can see. Comprehensive coverage is a prerequisite for accurate monitoring, not an optional upgrade.
What does a transaction monitoring webhook payload contain?
A typical payload includes the transaction ID, amount, currency, counterparty details, category, and a timestamp of when the bank posted it alongside when the webhook delivered it, structured as JSON. The gap between the transaction timestamp and delivery timestamp is the practical measure of how “real-time” a system actually is.
Can Open Banking data alone perform transaction monitoring?
No, Open Banking AIS provides the verified, real-time transaction data that automated transaction monitoring systems need for data monitoring, but the detection logic, risk scoring, and reporting tools sit on top of that data layer and are built by the platform. AIS solves data access and timing; it does not make compliance decisions.
See the exact webhook payload and latency your monitoring stack would run on with Finexer’s Data (AIS).
Explore with AI
About the Author
Yuri
Yuriy Yakushko is the Founder of Finexer, an FCA-authorised Open Banking platform that enables businesses to access real-time bank data and Pay-by-Bank payments through secure API infrastructure. With more than 20 years of experience in fintech and software engineering, he focuses on building scalable financial technology that helps businesses modernise payments and financial data workflows.