KPMG‘s 2026 Banking Technology Survey found cost reduction and operational efficiency (82 per cent) and legacy systems (59 per cent) among the leading factors prompting banks to modernise their payments platforms, alongside regulatory requirements and changing customer expectations.
Compliance sits at the sharp end of that shift: many banks still run monitoring and screening systems designed for a slower, batch-based, rules-driven payments world.
Madhu Nadig is co-founder and chief technology officer of Flagright, an AI compliance platform for real-time transaction monitoring and risk screening. He answered The Fintech Times’ written questions on why patching those systems no longer works.
Many banks are still running compliance systems built for a slower, batch, rules-based world. As real-time payments become the norm, where does that mismatch show up first?
The mismatch appears first at the decision boundary: the payment is ready to move before the bank has assembled enough risk context to judge it. An instant-payment message may be accepted and funds made available within seconds, while an older compliance stack still waits for a batch file, enriches data sequentially or checks separate systems one after another. The bank then either slows an ‘instant’ payment or releases it before its controls have caught up.
This is more than a processing-speed problem. Pre-execution controls such as sanctions screening and certain fraud checks need a fast, resilient decision path, while transaction monitoring may operate during or immediately after execution and must generate actionable alerts without losing context. Both require continuously updated information about the customer, counterparties, devices, prior behaviour and velocity across channels. When those data sources are stale or fragmented, the first symptoms are inconsistent decisions, duplicate alerts, missed behavioural patterns and growing manual exception queues.
Beyond the licence and maintenance line, what are the less visible costs of holding on to ageing compliance infrastructure?
The largest hidden cost is the change tax. Every new payment rail, product, market or regulatory update requires more mappings, interfaces, regression tests, reconciliations and compensating controls. A patch may be inexpensive in isolation, but it increases the number of dependencies that must be understood and retested the next time anything changes.
There is also a substantial people cost. Banks become dependent on a shrinking group of specialists who know why old rules, data fields and exceptions behave as they do. Investigators spend time reconstructing information across systems, engineers support overnight jobs and manual fallbacks, and audit teams gather evidence from multiple sources. Then there is opportunity cost: slower product launches, underused payment data and limited ability to adopt better analytics.
The licence fee is often the most visible but least informative number. The real measure is the total cost of changing, operating, evidencing and recovering the system.
When a bank weighs building in-house, buying off-the-shelf, or modernising what it already has, what should drive that decision, and where do institutions most often get it wrong?
The decision should begin with the target control model, not a preference for build, buy or upgrade. A bank needs to define which decisions must occur before payment, the required response time and throughput, the data and audit evidence each decision needs, who must be able to change controls, and how the new capability will coexist with the wider estate.
Building is defensible when the capability is genuinely differentiating and the bank is prepared to operate it as a permanent product, including security, resilience, validation and 24/7 operations. Buying is often rational for capabilities every institution needs, provided the bank retains ownership of policy, data, validation and vendor oversight. Modernising in place can work when the existing core has a usable data model and interfaces, and components can actually be retired.
Banks most often get this wrong by treating modernisation as software procurement. They compare licence prices and feature lists but underprice data migration, operating-model change, validation, integration and decommissioning. That is where apparently cheap options become expensive.
The KPMG 2026 survey puts legacy systems behind 59 per cent of modernisation efforts. What is the single biggest technical barrier to replacing a core compliance stack while the bank keeps running?
To be precise, KPMG found that 59 per cent of 200 US banking executives cited legacy systems as a driver of payment-platform modernisation. In replacing a compliance stack, the single hardest technical problem is maintaining decision continuity while the meaning and movement of data change.
An old platform contains more than code. It contains years of field mappings, timing assumptions, rule versions, manual exceptions, historical cases and undocumented dependencies. A new system can ingest the same record and still interpret it differently. During coexistence, the bank must be able to prove that both environments saw the same event, used traceable data and produced reconcilable outcomes.
That requires a canonical event model, versioned transformations, reliable timestamps, idempotent processing and an audit trail that spans both systems. Without those foundations, parallel testing gives false comfort and cutover can create a control gap. The safest architecture feeds old and new decision engines from the same replayable data stream, compares outcomes, and moves traffic only after discrepancies are understood.
How is rising real-time payment volume changing what transaction monitoring and risk screening actually have to do, in both latency and accuracy?
Rising volume changes the problem from running rules faster to maintaining an accurate, stateful view of risk at all times. Instant-payment traffic is continuous and bursty; there is no overnight window in which to catch up. Screening services must remain available, produce reproducible decisions within an explicit latency budget and have tested fallback behaviour.
Monitoring must recognise sequences and networks, not just isolated transactions. That means calculating velocity across rolling windows, resolving identities and counterparties, updating customer risk dynamically and linking behaviour across channels. A static threshold tuned for a daily batch will often flood analysts when moved into a stream, while still missing activity deliberately distributed across accounts or time periods.
Accuracy and latency therefore cannot be managed separately. A highly accurate model that returns too late cannot protect the payment flow; a very fast but noisy control simply transfers the problem into the investigation queue. Banks need tiered decisioning: automate clearly low-risk activity, intervene where policy requires it, and route genuinely ambiguous cases to human judgement with the relevant evidence already assembled.
Where is AI genuinely improving real-time monitoring, and where do you think it is being oversold?
AI is genuinely useful where it helps teams find signal in volume. Machine learning can improve alert prioritisation, anomaly detection, entity resolution and network analysis. Natural-language tools can extract facts from unstructured material, summarise case histories and assemble evidence for an investigator. Used well, these capabilities reduce repetitive work and help analysts spend more time on judgement.
It is oversold when presented as an autonomous replacement for controls, clean data or accountable decision-making. A generative model should not become an unexplained gatekeeper for whether a customer’s payment proceeds. Nor will a sophisticated model repair fragmented identities, missing fields or inconsistent labels. Poor data simply produces faster uncertainty.
The defensible model is layered: transparent rules for explicit policy requirements, statistical models for patterns and prioritisation, and human review for consequential or ambiguous decisions. Every component needs versioning, performance monitoring, explainable outputs, auditability and a tested fallback. AI is most valuable when it shortens the distance between a risk signal and informed human judgement; it is least valuable when it makes that judgement harder to reconstruct.
Over the next few years, what will separate the institutions that modernise well from those that keep patching?
The institutions that modernise well will be distinguished less by which vendor they choose than by how quickly they can change controls without losing evidence or resilience. They will treat compliance technology as a continuously managed capability, with clear data ownership, modular architecture, cross-functional product teams and funding for decommissioning as well as implementation.
They will also measure the right things: time to implement and validate a control change, percentage of critical data with traceable lineage, alert-to-decision time, false-positive burden, recovery time and the number of legacy dependencies retired. Those metrics reveal whether the bank is becoming more adaptable or merely adding another layer.
Institutions that keep patching tend to optimise for the uptime of individual systems while the number of interfaces, exceptions and manual workarounds continues to grow. That can look stable until a new rail, regulatory change or incident exposes the accumulated fragility. The durable advantage will not be owning the newest stack. It will be the ability to change safely faster than the risk environment changes.
The post Why Banks Cannot Keep Patching Legacy Compliance Systems appeared first on The Fintech Times.
