By 2026, most serious institutions will not be debating whether they “have” AML Transaction Monitoring. They will. What they will not have, in most cases, is a coherent risk operating system: a shared data, analytics, and orchestration layer that sits underneath AML, fraud, onboarding, and credit. Instead, they will have what looks like a mature stack in isolation – a licensed AML Transaction Monitoring platform that has passed several audits, a rules library tuned multiple times, standalone fraud tools, sanctions and screening systems in production, and an operations team working shifts across locations.
Despite this, the macro numbers are uncomfortable. Global financial crime compliance now costs institutions in the region of 200 billion US dollars a year; one recent study put the figure at 206.1 billion for 2023 alone. Large banks routinely spend hundreds of millions of dollars, and in some cases up to a billion per year, just to keep AML and related controls at the regulatory baseline. Yet false favourable rates in traditional TM and screening routinely sit in the 90–95 per cent range, with some vendors reporting that up to 95 per cent of alerts generated by legacy systems are, in fact, benign.
At the same time, reported suspicious activity continues to climb. In the United States alone, institutions filed roughly 4.6 million SARs in fiscal year 2023 – an average of more than twelve thousand reports per day – on top of more than twenty million currency transaction reports. The UK Financial Intelligence Unit received close to 860,000 SARs in a single reporting year. More alerts, more reports, more spend. The question regulators and boards are beginning to ask is simple: Does this translate into proportionately better risk control?
From a distance, a TM function approaching this limit still looks respectable. Policies and procedures exist and are kept up to date. Systems have been implemented, validated, and reviewed by internal audit. Scenario tuning exercises are documented. Governance forums review packs every quarter, and action logs close out on schedule. Training records show analysts completing the required modules. On the surface, nothing obviously fails a checklist.
The day-to-day reality looks different. Alert volumes rise year on year, often faster than the underlying growth in customers or transactions. Most of those alerts are noise. Industry surveys routinely show falsely favourable rates above 90 per cent for traditional AML monitoring; some institutions report that only a small single-digit percentage of alerts ever progress to a SAR. Analysts spend much of their time gathering basic information from multiple systems – KYC and KYB files, account records, device and channel history, fraud tools, sanctions, and adverse media results – instead of actually analysing risk.
The pattern of work becomes monotonous. A high proportion of cases end in the same conclusion: activity within expected behaviour, no additional concerns, case closed. Meanwhile, the small set of genuinely complex patterns that matter most – mule networks spanning products and legal entities, abuse of embedded finance arrangements, corridor-based laundering that plays out over months – cut across organisational boundaries. No single team has explicit responsibility for spotting them early because queues are organised around products and geographies, not around flows of behaviour.
Organisational responses are predictable. New rules are created to plug the perceived gap in the last incident. Thresholds are tweaked to try to stem alert volume without appearing to weaken controls. Business cases are raised for additional headcount to clear backlogs. A proof of concept is launched with an anomaly-detection or AI vendor to “enhance detection”. Each initiative brings some relief. None of them materially changes the trajectory. Cost and complexity increase; internal confidence in the monitoring setup does not. That is what hitting the wall looks like from the inside.
Reaching that wall would be uncomfortable in any era. Around 2026, it becomes actively dangerous because it coincides with structural shifts in payments, business models, and supervisory expectations.
First, real-time and 24×7 payments have moved from the edge to the centre. Globally, real-time payment schemes handled more than 260 billion transactions in 2023, growing at over 40 per cent year-on-year. India illustrates what “maturity” looks like: digital payments already account for more than 99 per cent of transaction volume, with UPI alone handling tens of billions of instant transactions a month and now dominating daily retail payments. The overnight batch cycle that many TM systems were designed around has been compressed into seconds. If you cannot form a view in time to hold, challenge, or step-up checks, there is often no second chance.
Second, embedded and platform-based finance has reshaped where risk sits. Global estimates vary, but most serious forecasts now project embedded finance markets reaching several hundred billion dollars in direct revenue by 2030 and influencing trillions in underlying flows. (Mordor Intelligence) Marketplaces, payment facilitators, BaaS platforms, wallets, BNPL providers, and super-apps sit between balance sheets and end users. The legal customer might be a platform fronting for thousands of merchants or millions of consumers. Transaction patterns, counterparties, and obligations are correspondingly more complex, while many monitoring stacks still assume a simple one-customer, one-account world. The third misuse of financial infrastructure has become more networked. Professional actors understand how rules work, particularly when thresholds and scenarios are stable. They spread flows across accounts, entities, corridors, and time. They rely on mule accounts and synthetic identities precisely to defeat straightforward scenario logic. The typologies that matter most under these conditions are inherently behavioural and relational. They are not easily expressed as a handful of static scenarios running on flat transaction tables.
Fourth, supervisors are increasingly explicit that technical compliance is not enough. FATF’s methodology has, for some time, evaluated countries on whether their regimes are effective at mitigating money laundering and terrorist financing risk, not just whether they have transposed recommendations into law. National supervisors are following suit, asking institutions to evidence that monitoring controls are adequate for their specific risk profile, that models and scenarios are being improved based on outcomes, and that “more alerts and more SARs” is not the only success metric.
Finally, the economy is tightening. Global payments volumes continue to grow – more than three trillion transactions and 1.8 quadrillion dollars in value in 2023 by one estimate – but revenue growth is expected to slow, and cost pressure is acute. At the same time, the direct cost of financial crime compliance is already above the 200-billion-dollar mark, and still rising. TM competes head-on with cyber, fraud, data, and digital initiatives for capital and operating budget. A model that assumes alert queues and headcount can keep growing in line with transaction volumes is not realistic.
Individually, each of these trends can be managed tactically. Together, they expose a deeper misalignment between the environment institutions are required to monitor and the way they have chosen to construct their monitoring.
Across vendors, regions, and business models, transaction monitoring environments tend to share the same implicit design assumptions.
Risk is assessed primarily at the level of individual transactions, sometimes adjusted by a static customer risk score determined at onboarding or periodic review. Monitoring logic is expressed as discrete rules or scenarios, each with its own documentation, owner, and tuning history. The principal object the system emits is an alert. Alerts are routed into queues defined by organisational lines – country, product, segment, sometimes risk band. Staffing models, SLAs, and MI packs are organised around those queues. Banks think nothing of blocking a customer’s account for days.
Data that would materially enrich risk assessment is typically scattered. KYC and KYB files, relationship hierarchies, product usage data, device and channel histories, fraud signals, sanctions and adverse media results, ticketing systems, and SAR repositories all live in separate environments. Investigators pull this data manually while working cases. Feedback from downstream outcomes – which alerts led to SARs, which were consistently closed with no action, which triggered law-enforcement interest or relationship exits – returns to rule and model design only via periodic, human-driven reviews.
This creates predictable weaknesses. The system tends to see suspicious transactions rather than suspicious flows of value over time and across entities. Responsibility for meaningful patterns is fragmented across multiple queues and teams, so no one unit has a full view of how a particular risk actually propagates and evolves. Routing from alert to decision is static mainly; once a case exists, its path through the organisation changes very little, regardless of what is learned along the way. Institutional memory is shallow because lessons from cases are not systematically encoded back into how monitoring operates day to day.
You can overlay point solutions – a graph database in one team, a new scoring model attached to a subset of scenarios, an investigative dashboard used by a specialist group – but if the organising principle remains “rules and models generate alerts, alerts sit in queues, queues are worked manually”, the architecture has not meaningfully changed. Put differently, you have tools for AML, fraud, and credit, but nothing underneath them that behaves like a unified risk operating system. Each domain solves its own local problem. No one is optimising the risk flow end-to-end. You are trying to solve a 2026 problem with a 2006 pattern.
Against this backdrop, the appeal of AI and machine learning is obvious. Done well, advanced analytics can reduce noise, surface non-obvious patterns, and support analysts with complex decisions. Some estimates suggest that the intelligent use of AI could cut compliance costs materially and help recover significant value lost to illicit flows. Supervisors in major markets have also signalled that the use of innovative techniques is acceptable, provided questions of governance, data quality, and explainability are correctly handled.
However, simply adding AI in Transaction Monitoring to an unchanged operating model rarely delivers the transformation sponsors have in mind. In many programmes, machine learning is used primarily as a post-processor to rescore alerts already generated by the rules engine. Anomaly-detection tools are connected in parallel to produce their own stream of “interesting events”, which then require additional queues and procedures. Generative tools are trialled as “copilots” to assemble investigation narratives more quickly. At the same time, the logic that decided to generate and route the case in the first place remains as fragmented as it was.
These efforts can each be sensible. None of them answers the central question: how does the institution express, execute, and adapt its view of risk as an end-to-end process, from the first signal through to the final decision and action, across all the systems and teams that need to be involved?
If that question is left untouched, AI in Transaction Monitoring simply becomes another layer in an already crowded stack. Some local efficiencies are gained. The structural mismatch between modern payment and business models, on the one hand, and a rules-plus-queues architecture, on the other, persists.
If you ask ten institutions whether their TM is “effective, most will say yes. If you ask what they mean by that, the answers start to drift: “the regulator seems satisfied”, “we pass internal audit”, “we filed more SARs this year”, “we upgraded to an AI-based system”.
For 2026, that isn’t precise enough. You cannot build a risk operating system or agentic flows on top of vague comfort.
Effective transaction monitoring is the ability to identify and manage the institution’s material financial crime risks, at an acceptable cost and with demonstrable, auditable outcomes.
Everything else – vendors, models, dashboards, “FRAML”, real-time rails – is secondary.
Most TM programmes today grew up under a compliance lens. The working question was: do we meet the obligations in the local AML law and rulebook?
So you see investment in a patchwork of solutions:
All of that is still necessary. None of it tells you whether the thing you have built works in practice.
That gap is now evident in the numbers. Survey work across banks and fintechs suggests that, on average, around 40% of AML programme resources are still spent on manual alert reviews, and TM programme costs have risen by roughly 20–25% in the last two years, mainly because of that manual work. False favorable rates in traditional systems sit in the 90–99% range; even “leading” solutions regarded as best-in-class talk about bringing that down to just under 50%.
If you are burning almost half your programme capacity just to confirm that the system’s own alerts are harmless, you do not have an effectiveness problem on the margins. You have a structural one.
Regulators are starting to ask the obvious follow-on questions:
That is the pivot from “are we compliant?” to “does this actually work?”. Effective TM in 2026 has to answer the second question cleanly.
Once you strip away vendor language, effective TM comes down to five outcomes.
First, coverage. You are actually pointing at the right risks for your business. A retail-heavy bank with mass real-time payments has a different profile from a cross-border PSP or a B2B platform handling high-value flows. Effective TM is explicit about this: you can see the mapping from business model and risk assessment into scenarios, models, and flows, not just a generic vendor typology deck.
Second, precision. You are not wasting most of your capacity on junk. You will never get to zero false positives, but a world where 19 out of 20 alerts are thrown away is not “effective” by any reasonable standard. The market evidence is that institutions adopting more advanced, data-driven approaches can cut false positives by 40–60% and manual review time by more than 20%. That is not about clever marketing; it is about changing how risk is defined and routed.
Third, timeliness. In a real-time payments world, detection that happens tomorrow is often detection that never mattered. Effective TM has clear latency targets for different channels: what needs a decision in-stream, what can be processed in micro-batches, and what is genuinely suitable for end-of-day. Those targets are engineered into the architecture, not bolted on via SLAs in an operations manual.
Fourth, adaptability. Typologies evolve, products change, and criminals experiment. An effective system is designed to absorb that change. New scenarios, features, models, and flows can be developed, tested, rolled out, and – crucially – rolled back without six-month projects and vendor change orders. This is where thinking in terms of a risk OS starts to matter; adaptability is an architectural property, not a training slide.
Fifth, auditability. You can reconstruct why something happened. For any given case – whether it ended as “no further action” or a SAR – you can walk back through data, rules, models, thresholds, overrides, and human decisions. You can explain it to internal audit, senior management, and a supervisor without hand-waving. That becomes non-negotiable once AI and graph-based techniques sit inside your flows.
If you look at these five outcomes, you can see two patterns. Only one of them is about “how clever the models are”. All of them depend on coherent data, clear policy, and the ability to express risk as a process, not a pile of alerts.
When you look at what buyers say they want from TM, the story lines up with the outcomes above.
In one recent global survey of banks and fintechs, around 90% of respondents put “regulatory compliance” as a top purchasing criterion for TM solutions, which is no surprise. But the following three items on the list were scalability (roughly 88%), data quality (around 86%), and product integration (just over 80%). Those are not cosmetic concerns; they are shorthand for “we’re drowning in volume, “our data is a mess,” and “this thing has to talk to the rest of our stack.
The same set of surveys showed that roughly four out of five institutions now use either AI/ML-enabled or hybrid monitoring approaches; only about a fifth run pure rules-based systems. And close to half of buyers explicitly want platforms that cover more than just TM – they expect account opening, screening, and fraud capabilities to sit alongside AML.
In parallel, around 60% of banks and fintechs either have already merged their fraud and AML teams or plan to do so within the next two years. That is the FRAML story stripped of buzzwords: the market is quietly converging around integrated, lifecycle-wide risk management.
Taken together, these data points tell you how the industry is redefining “effective TM” in practice:
If your internal definition of effectiveness ignores those realities, you are optimising to the wrong target.
A second shift is conceptual. For a long time, transaction monitoring was treated as a discrete box in the middle of the AML chain:
onboarding → KYC → TM → investigations → SAR.
That mental model is still visible in how many systems are deployed and how many policy documents are written. But it is increasingly at odds with how both crime and supervision work.
From a risk perspective, the real lifecycle is continuous. The quality of monitoring depends heavily on what you did at onboarding and periodic review: data captured, segmentation, declared versus observed behaviour. Fraud events, chargebacks, and complaints are risk signals, not “someone else’s KPI”. Screening outcomes, adverse media, device intelligence, and graph analytics all change the context for how you interpret a given payment. SAR outcomes and law-enforcement feedback should feed back into scenario design and model training, not sit in a separate reporting silo.
From a supervisory perspective, you are already being judged on that lifecycle, whether you admit it or not. When regulators criticise “weak TM”, the findings almost always involve gaps elsewhere: poor KYC data, weak risk assessment, inconsistent escalation, low-quality SARs, and no structured learning from previous cases. They don’t care which vendor owns which layer. They care about whether the end-to-end system functions.
In a risk OS world, TM is one workload running on shared infrastructure. Effective TM in 2026 assumes that. It expects to be fed by the same entity graph, feature store, and policy engine that fraud and onboarding use. It expects its outcomes to feed back into that shared layer. It stops pretending that you can achieve effectiveness by tuning a mid-stream engine in isolation.
If you sit with the head of financial crime at a mid-sized bank, a payments company, or an extensive fintech, the picture is remarkably consistent. They are not starting from zero. They have systems, contracts, and sunk costs everywhere. What they do not have is anything that looks like a coherent risk operating system. They have a collection of boxes. From KYC Hub’s vantage point, this is the baseline we see again and again: a lot of technology, tiny that behaves like a shared narrative.
Typically, there is a KYC/KYB platform at the front, often separate tools for consumer and business onboarding. Screening runs somewhere else – sanctions, PEPs, adverse media – with its own queues and outcomes. Fraud has its own stack, frequently bought by a different team, focused on devices, behaviour, and chargebacks. AML transaction monitoring sits in another box, either part of the core banking vendor’s suite or bought as a specialist package. Case management may be embedded in one of these systems or exist as yet another product. Data flows between them in flat files and extracts. Analysts live in all of them at once.
The critical point is not the vendor names. It is that each element was bought and implemented to solve a local problem, at a point in time, under regulatory pressure. The result is a patchwork of rules engines, specialist models, queues, and manual work, stitched together by operations.
At the centre of most TM stacks is still a scenario engine. It takes in transactions, applies a library of rules, and emits alerts.
Those rules are usually written around typologies: structuring, early repayment, unusual cash activity, high-risk corridors, velocity spikes, nested accounts, and so on. Each scenario reflects a risk narrative that once made sense: “customer suddenly starts sending many small payments to a sanctioned country”, “SME account receives multiple third-party deposits inconsistent with profile”, “money moving in and out of a new account too quickly”. Over time, these scenarios are multiplied, tuned, cloned, and extended.
A typical institution will have dozens, sometimes hundreds, of active scenarios. Each has its own parameters, thresholds, segments, and exception lists. These combinations are often the product of negotiation: risk appetite pushing for more sensitivity, operations pushing back against volume, business arguing for less friction in particular segments. Very little of this logic is encoded in a way that a new person can read and understand end-to-end. It lives in configuration screens, spreadsheets, and the memories of a few long-tenured staff.
Because the engine is evaluated per transaction (or per simple aggregation like “number of transactions in X days”), and because the underlying data model is often relatively flat, the rules tend to approximate behaviour crudely. You see a lot of “more than N in period T” or “amount greater than X in segment Y”. As soon as customers adopt real-time payment patterns or fraudsters deliberately fragment activity, these simple boundaries are either overwhelmed with noise or bypassed altogether.
From the outside, you still have “coverage”. On paper, the typology library maps neatly to FATF categories. In practice, the engine is a large, opaque machine throwing off more and more work.
Once the rules engine has done its job, the rest of the system organises itself around queues. Alerts are grouped by geography, product, risk band, or some combination of those. L1 analysts work the simpler queues, L2 and L3 handle escalations and complex cases. Team leads monitor the age of the queue, SLA compliance, and throughput.
This is where the cost starts to bite. One recent market study found that in just two years, average spend on AML transaction monitoring programmes had risen by roughly 23 per cent, primarily because of the cost of manual reviews. In parallel, survey work across banks and fintechs suggests that traditional AML monitoring still throws off false favorable rates above 90 per cent, with only a tiny fraction of alerts ever progressing to a SAR. Leading platforms sell themselves on coming in “under 50 per cent false positives,” which tells you where the baseline is.
The work itself is still heavily manual. An analyst opens a case in the TM system, then hunts for additional information in upstream and downstream tools: KYC profiles, historic account activity, device fingerprints, fraud scores, sanctions hits, and SAR history. They paste screenshots and CSV extracts into a workbench. They write a narrative. If needed, they escalate. If not, they close and move to the next one.
From a distance, you see volume being handled and SLAs being met. Up close, you see a large number of skilled people doing repetitive, low-leverage work to compensate for the fact that the system keeps flagging things it should have been able to dismiss on its own. For KYC Hub, this is the red flag: when most of the human effort is spent undoing the machine’s decisions, the architecture – not the people – is the problem.
The logical end-state of this architecture is what you could call an “alert warehouse”. The rules engine generates alerts. Those alerts become cases. Cases either close or become SARs. Everything is counted: number of alerts, number of cases closed, number of SARs filed.
This produces big numbers. Some jurisdictions are now seeing hundreds of thousands of SARs per year; major economies see millions. Many institutions have responded by automating parts of the case lifecycle. Some vendors now promise up to 80 per cent reduction in alert triage time, and to cut false positives by 60 per cent, by using AI-driven scorers and more intelligent segmentation. Others claim up to 90 per cent reduction in the time analysts spend drafting SAR narratives, through automated summarisation and document assembly.
Those improvements are real at the point of work. A better workbench and a narrative copilot do make life easier. A more intelligent ranking model does help you work on the most urgent cases first. But they do not change the core dynamic: a large, centralised engine producing very high volumes of alerts, most of which are not meaningful, feeding into a process whose primary success metric is “did we file the right paperwork quickly enough”.
You end up with a SAR sausage machine: consistent forms, consistent timelines, but no clear line of sight from all that activity back to the real risks and flows the institution is facing. KYC Hub treats this “alert warehouse” pattern as something to be dismantled, not optimised: the goal is fewer, better-targeted flows tied to fundamental typologies, not ever-faster production.
If you look at today’s transaction monitoring landscape through the lens of a risk operating system, a few things become apparent.
First, TM is not designed as a workload running on a shared OS. It is a product box connected to other product boxes with pipes and spreadsheets. Onboarding, screening, fraud, T, M, and SAR filing are technically linked, but they do not share a clean, central layer of entities, features, policies, and flows.
Second, the basic unit of design is still the scenario and the queue, not the risk flow. Institutions talk about typologies and alert workflows; they seldom speak about end-to-end flows that start at the first signal and run through to the final decision, across systems and teams, with deliberate feedback from outcomes.
Third, the use of AI in Transaction Monitoring, so far, has primarily been tactical. It has improved triage, classification, and documentation. It has not, in most places, rewritten how risk is expressed and orchestrated across the stack.
Finally, the cost and volume problems are not accidental. They are natural consequences of an architecture where detection is decomposed into hundreds of narrow rules, where almost every interesting case requires manual enrichment from multiple systems, and where the only way to “be safe” is to keep generating more alerts and more SARs.
The legacy stack treats a transaction as a row in a table and an alert as a tick in a queue. The modern stack treats both as just one frame in a longer film.
If you want rules, models, and agents to behave like adults rather than noisy children, the foundations are not optional. You need three things under the hood: a continuously maintained view of who you are dealing with, a graph that shows how they are connected, and a way of turning raw exhaust from systems into risk signals that humans and machines can actually work with. Without that, “flows” are just diagrams in PowerPoint. These are not “nice to have” features, but the minimum architecture on which our own risk OS is built.
Everyone has had a “single customer view” on a slide at some point. In most institutions, it quietly turned into a data-cleansing project and a set of merged records in a warehouse. Useful, but not enough.
For transaction monitoring that has to survive 2026, a single customer view has to become a live object. The system needs to be able to say, at any given moment: these accounts, these cards, these devices, these legal entities, these email addresses, and these documents all belong to the same real-world party, and this is the role they are playing here: retail customer, merchant, platform operator, director, UBO, introducer.
That is what entity resolution really means in this context. Records from onboarding, product systems, card processors, PSP rails, CRM, sanctions screening, fraud tools, and external registries all arrive slightly wrong. Names are misspelt. Addresses are formatted differently. Dates are missing. People use different phones or emails for other products. The job of the platform is to keep reconciling all of this into stable entities, all day, every day, not once a year during a remediation.
Perpetual KYC sits on top of that. The risk view of a customer can’t be frozen at onboarding and at a three-year review. Changes in ownership, directors, product mix, counterparties, channels, ticket sizes, devices, screening hits, adverse media, and past SARs all need to flow back into the entity. The “KYC file” becomes more like a state machine than a PDF: something that changes as the fundamental world changes.
For monitoring, this matters because every rule, every model score, every agent decision has to hang off that entity. An alert on a payment from Account A means something very different if you know that Account A belongs to a mule hub tied to ten other flagged entities, than if you think it is a standalone retail customer with a clean history. Without a robust entity layer, the rest of the stack is guessing. In practice, this is where institutions either bend the cost curve or get stuck: a live entity layer is what lets KYC Hub cut wasted alert work instead of just repainting legacy queues.
Once you take entities seriously, it is hard to avoid the next step. Abuse of the system is rarely contained within one customer and one account. It is almost always about how those entities are linked.
Think about how the cases that keep people awake actually look. A director who appears in three different companies, all at the same virtual office address. Those companies receiving funds from the same PSP and paying out to a cluster of personal accounts. Several of those accounts are using the same device, or the same IP range, or the same card to top up wallets in different apps. A corridor where value flows repeatedly through a small set of counterparties, none of whom trigger a rule on their own, but that together form a laundering route.
You can describe these patterns in reports. But operationally, they are not lists. They are graphs.
In a modern monitoring environment, the entity and relationship graph is not a fancy add-on. It is the data structure that everything else should attach to. Customers, businesses, accounts, cards, devices, merchants, platforms, corridors, even cases and typologies if you choose, are treated as nodes. Ownership, control, shared addresses, shared documents, payments, shared devices, co-directorships, common counterparties and shared merchants are edges. Both nodes and edges carry attributes and scores: risk ratings, behaviour tags, screening statuses, historical patterns.
This does not mean you throw away your ledgers, warehouses and data lakes. It means you add a graph layer whose sole job is to represent “how things are connected” from a risk point of view. Transaction monitoring reads from it. So do fraud, screening, collections and investigations. When an agent is asked to triage or investigate, it starts from that graph, not from a raw row in a table.
The practical benefit is that the typologies we care about in 2026 – mule herds, layering chains, nested accounts, abusive merchants, compromised devices – become first-class objects the system can see and reason about. You are no longer trying to infer a network from scattered alerts. The network is there by design.
Even with entities and a graph in place, raw data is still too blunt. You need a way of expressing behaviour and context that rules, models and agents can actually use. That is where feature pipelines come in.
Every payment, login, device change, limit change, dispute, screening hit and case outcome is an event. On its own it says very little. What matters is how those events accumulate around entities and edges over time.
Behavioural features capture how someone or something behaves: how often they transact, in what patterns, with what volatility, at what times of day, through which channels, with what counterparties. They distinguish a stable payroll account from a mule, a normal weekend UPI burst from a panic chain, a merchant with predictable seasonality from one suddenly operating as an unlicensed PSP.
Profile features capture what the entity is meant to look like: declared business, expected turnover, typical ticket size, geography, segment, products used, regulatory classification. They allow the system to ask “is this behaviour consistent with what this customer is supposed to be?”, not just “is this behaviour high or low in absolute terms?”.
Network features capture how the entity sits in the graph: degree of connectivity, proximity to known bad actors, clustering with other high-risk nodes, role in particular corridors or rings. They are what lets you say “this account has low direct risk indicators, but sits in the middle of a mule-like structure” or “this merchant is the common factor in three otherwise separate alerts”.
From an implementation point of view, all of this lives in a feature store that is shared. Rules use it. Models train and score against it. Agents consult it when they have to make decisions. Investigators see it when they open a case. That is what “context” means in practice: not a vague sense that more data exists somewhere, but specific, pre-computed signals attached to entities and relationships that everyone can use.
Without that, each system re-implements its own view of behaviour, and each project rebuilds the same logic from scratch. With it, you have a common language of risk that can be used across fraud, AML and beyond. For buyers, this is where the business case shows up: a shared feature layer is what lets KYC Hub reduce false positives and investigation time in parallel, instead of tuning dozens of rules one by one.
In the legacy stack, an investigation is a checklist. The analyst opens an alert, runs through a procedure, pulls data from various screens, writes up a narrative and closes or escalates. The “journey” they took through the data vanishes the moment they close the case.
In a graph-based stack, an investigation is naturally a path.
You start from a signal: a payment, a pattern, a node, a corridor. You fan out. You look at related accounts, directors, addresses, devices, counterparties, SAR history. You decide which of those branches matter and which are noise. Eventually, you conclude: this looks benign, this should be monitored more closely, this requires a SAR, this relationship should be exited.
That path can and should be captured. Not as a video recording or a screen scrape, but as a set of hops across the graph: which entities and relationships were inspected, in what order, with what intermediate conclusions. Over time, those paths become valuable in their own right. They show you what your best investigators actually do for a particular kind of case. They highlight where missing context forced manual workarounds. They reveal recurring sub-patterns that could become explicit typologies or flows.
This is where agents re-enter the story. An investigation agent does not replace the human. It automates the obvious parts of the path. Given a starting point and a case type, it can walk the relevant neighbourhood of the graph, pull the usual attributes, highlight known risk markers, compare the current pattern to past resolved cases, and assemble a first-cut view that a human can confirm or override. A triage agent can do a lighter version of the same for lower-risk alerts, deciding which ones can be safely closed or deprioritised without human touch.
None of this is science fiction. It is possible when investigations are treated as structured paths through a well-maintained graph, rather than as one-off excursions recorded only in free-text notes.
If you want to rely on richer data, features and graphs, and if you want agents to act on top of them, you need to know where that data came from and how it has changed.
That means being able to answer boring questions confidently. When did this attribute on this entity change, and why? Which upstream system supplied it? Which transformation logic was used? Which version of the feature definition was in force when this model score or rule decision was produced? When an agent closed or escalated an alert, which inputs and thresholds did it see?
In other words: lineage and versioning. Not as an afterthought, but as part of the design.
For transaction monitoring, this plays out in three ways. First, it is the only way to be credible with regulators when you explain why a particular decision was taken, especially if a model or agent was involved. Second, it is how you keep your own risk honest; without lineage, it is impossible to distinguish a genuine change in customer behaviour from a quiet shift in upstream data. Third, it is how you avoid turning every change project into a leap of faith: if you can replay past decisions under a new rule, model, or flow, you can see the impact objectively before you go live.
Once again, the point is not to create bureaucracy for its own sake. It is to make sure that the more powerful parts of the stack – the flows and agents you care about – are standing on something solid enough that you can trust them, defend them, and improve them.
Taken together, these elements – live entity resolution, an explicit graph of relationships, shared behavioural and network features, investigation paths that humans and agents can walk, and clear lineage – are what “foundations” actually means for modern TM. They are not a side project. They are the underlay that makes the rest of the handbook possible. Without them, talk of agentic flows is just rhetoric layered on top of the same old alert warehouse.
Rules and queues on their own won’t survive 2026. The question this section answers is: if you were designing a monitoring stack now, with AI, graphs, and agents in mind from day one, what would it actually look like?
Think in planes, not products. The names of the tools matter less than the roles they play.
A serious TM capability has to operate at three speeds. The architecture above exists to support all three without building three separate stacks.
The online path is the real-time decision loop. A payment authorisation, instant transfer, or wallet payout arrives at the data plane; the relevant entity, features, and graph context are refreshed; the intelligence plane applies fast rules and models; the orchestration plane decides whether to allow, hold, challenge, or block. For instant payments, this may mean a few tens of milliseconds to form a view. Not every check can run here, so you decide which questions you must answer immediately (“Is this safe enough to let through?”) and which can wait for a slower path.
The near-real-time path is the micro-batch loop. Hourly jobs, short windows, or overnight runs look for patterns that need a bit of accumulation: merchants whose refunds explode over a week, corridors that start to show new layering patterns. These accounts slowly evolve into pass-through nodes. Here, the intelligence plane can afford heavier graph operations and more complex models. The orchestration plane can promote interesting findings into complete investigations, adjust risk bands, or change which online flow a customer’s transactions follow.
The offline path is the slow loop. This is where typology discovery, model training, and post-mortems live. Teams explore the graph for new patterns, test new rules and policies on historical data, and replay past traffic under proposed flows to see what would have changed. Once they’re happy, they publish new versions into the live intelligence and orchestration planes, often in shadow mode first.
Almost nobody gets to start from a blank sheet. A reference architecture is only helpful if it can sit next to what you already run.
In practice, that usually means the first step is a “sidecar” rather than a replacement. The new stack ingests the same events as your existing TM engine, builds its own entities, features, and graph, and starts running flows in parallel. Initially, those flows operate in advisory or monitoring mode: they rescore legacy alerts, surface missed patterns, and show what would happen if they were allowed to decide. Over time, specific flows are allowed to take action for narrow slices: a particular instant payments corridor, a subset of merchants, a segment of high-risk accounts.
Existing TM engines are treated as signal generators rather than masters. Their alerts become inputs into flows, enriched and re-prioritised, rather than all being treated as equal work items. Existing fraud and payment orchestration systems are integrated via simple contracts: the TM stack returns a risk band, a recommended action, and the key factors behind it, instead of a binary “yes/no” buried inside proprietary code.
Constraints are dealt with honestly. If specific cores can never support accurate real-time checks, their flows are designed as near-real-time plus batch. If specific external data is only available daily, flows for those typologies reflect that. The architecture does not assume perfection; it gives you one place to reason about where you can be instant and where you cannot. KYC Hub typically deploys in this “sidecar” pattern first, proving lift on top of existing TM and fraud tools before taking over full flows where it is safe to do so.
Agentic flows do not mean “set it and forget it”. They mean the opposite: be explicit about what can be automated and what cannot.
For benign, well-understood patterns, agents can be allowed to close alerts and apply simple actions on their own, under strict thresholds and with regular sampling. For example, an agent might be authorised to dismiss low-risk screening matches where the entity graph and behaviour are strongly inconsistent with the hit, while still flagging anything borderline for human review.
At the other end of the spectrum, flows that lead to SARs, relationship exits, or law-enforcement referrals remain human decisions. Agents can assemble the case pack, walk the graph, compare with similar historical cases, and draft a narrative, but a named person signs off. Those sign-off points are part of the flow definition, not left to custom and habit.
Between those extremes, policy decides how far agents can go. For a given flow, you permit them to apply temporary holds, lower limits, or move entities between risk segments, but forbid them from permanently blocking or closing relationships. Governance agents can monitor how often those powers are used, whether specificc agents or flows are drifting, and whether queue health and SLA performance are within expectations.
From a regulator or internal audit perspective, comfort comes from being able to explain and evidence three things: which parts of a decision were automated and which were not; which version of the flow, rules, and models were in force at the time; and how changes are tested before they are rolled out. A stack built around flows and planes makes those explanations much easier than a tangle of scenarios hidden in configuration screens. KYC Hub encodes these guardrails into the platform: agents have explicit scopes and audit trails, and human checkpoints are defined in the flow itself rather than buried in local procedures.
Agentic flows and a Risk OS are only helpful if your supervisors and internal audit can live with them. By 2026, that bar is not “do you have AI?”; it is “can you show this actually works, is governed, and doesn’t turn into a black box?”
Regulators have already told you what they care about; they just didn’t use the words “agentic flows.
FATF has been clear for years that assessments “focus on two areas, effectiveness and technical compliance. The emphasis of any assessment is on effectiveness.” In other words, it’s not enough to prove that you own a system and have policies; you need to show that, in practice, your monitoring set-up produces the proper outcomes for the risks you actually run.
On AI, supervisors are circling the same themes: governance, explainability, fairness, resilience. Singapore’s Model AI Governance Framework puts it bluntly: decisions made by AI “should be explainable, transparent, and fair,” and systems should remain human-centric. The UK’s FCA has said “AI needs governance to move from fear to trust,” stressing that the agency must not be attributed to systems, because accountability belongs to firms. The European Banking Authority, looking at machine learning in internal models, has flagged that issues around data and explainability are not new, but “may be exacerbated when using ML models.”
Translate that into AML TM, and you get four tests:
An agentic architecture does not get a free pass. It gives you better tools to answer those questions.
Most “explainability” work today happens at the model level: SHAP charts, feature importance plots, a few pages in the model pack. That’s necessary, but in monitoring, it’s not sufficient. What boards, auditors, and supervisors actually want to understand is why a specific payment was blocked, why a particular customer was exited, or why a SAR was (or was not) filed.
Risk flows make that easier because a decision is no longer a mysterious chain of events across half a dozen systems. It is a defined path. You can decompose one outcome into: the incoming signal, the rules that fired, the model scores at each step, the graph evidence pulled in, the agents that acted, and the human overrides. For an instant-payment block, for example, you can show that a device-change rule triggered, a behaviour model produced a high score, the graph engine placed the sender in a mule-like cluster, and policy therefore required a hard block plus case creation.
Visual narratives help here. Instead of a flat log, investigators and auditors see the entities involved, the edges between them, the time sequence, and the key features that drove the scores. Text summaries generated by a copilot become acceptable when they are pinned to that evidence – “this looks like pattern X we have seen Y times before, resolved as SAR in Z per cent of cases” – rather than generic AI in Transaction Monitoring.
The test is simple: could a competent but neutral third party understand, in a few minutes, why this thing happened, and how similar decisions would be made in the future?
KYC Hub surfaces each decision as a flow trace rather than a static log: entities, features, graph context, rules, models, agents, and human actions are visible in one place, so “why did this happen?” can be answered on a single screen.
Once you let models and agents sit inside flows, you need governance that treats them like serious instruments, not side projects.
In practice, that means registries for rules, models, flow, and agents, each with an owner, scope, approvals, and a version history. When a rule threshold changes, a new ML model is deployed, or an agent is given permission to auto-close a particular class of alerts, there is a record of who did it, when, why, and what testing was done. This is not exotic; it is the same discipline expected for credit models, applied to financial crime.
Continuous monitoring then becomes part of the job. You watch for model drift and degradation, shifts in alert and SAR patterns, queues behaving strangely, and unintended feedback loops between agents. A triage agent that starts auto-closing far more alerts than before, or a new flow that quietly starves another queue of cases, should appear on someone’s radar quickly, not six months into a review.
Supervisors are not asking for perfection here. They are asking for seriousness. The message from the EBA’s work on machine learning is essentially: you can use more complex techniques, but only if you can explain them and govern them to the same standard as legacy models. The same logic applies to agents and flows.
The last piece is whether you can defend the system under pressure. That might be a significant case that attracts media attention, a supervisory review, or an internal audit focused on AI in Transaction Monitoring.
Agentic flows actually make life easier if you design them correctly. A complete decision trail is no longer a set of scattered screenshots; it is a structured record from inputs through transformations to actions: which data was used, which features were computed, which rules and models were evaluated, which agents acted, which human signed off. Because flows, models, and rules are versioned, you can say exactly what logic was in force on a given date and replay historical traffic under updated flows to show what would have been different.
For internal audit, this moves the conversation from “show me your scenario list” to “show me how this flow is designed, how it performs, and how you change it. For regulators, it turns AAI in Transaction Monitoring from something mysterious into a better-documented extension of the existing risk-based approach: same objectives, sharper instruments, more observable behaviour.
KYC Hub sets a simple bar before automation is allowed: if a decision cannot be replayed, explained, and challenged after the fact, it does not get handed to an agent. That is what keeps “agentic TM” defensible in front of boards and supervisors, not just operationally attractive.
The architecture gets you halfway. The rest is people and how they spend their day.
If you keep the same operating model on top of an agentic stack, you just create fancier alert factories. The fundamental shift is from “working cases” to “designing and running risk systems”. That operating model shift is the real product KYC Hub is aiming at: not just a new TM tool, but a different way for teams to spend their time.
By the end of 2025, almost every serious institution “has” transaction monitoring. The difference between those who will cope with the next decade and those who will be stuck in permanent remediation is no longer about owning a system. It’s about how they think about risk.
KYC Hub’s view is simple. The institutions that treat transaction monitoring as a living risk system – with architecture, flows, agents, and governance to match – will cope with the next decade of payment rails, business models, and regulatory demands. The ones that stay in the alert-and-queue mindset may survive, but they will spend most of their time explaining why something went wrong, rather than calmly showing how the system is being improved. Our role is to support the first group without pretending the second group is going to disappear; the wall is real either way, and this handbook is intended to make the path through it a little more precise and more practical.
