If your AI model cannot see relationships, it is not doing anything a rule engine could not already do faster.
That is a difficult sentence to say to a vendor who has just walked you through a 40-slide deck on machine learning capabilities. But it is the right question to ask, and most payment aggregators never think to ask it during the evaluation process.
Here is why it matters.
A transaction-level model scores individual events: amount, merchant category, velocity, time of day. It is genuinely good at this. It learns patterns a static rule would miss and adapts as fraud tactics shift over time.
What it still cannot do - by design - is answer a relationship question. Does this merchant's beneficiary account already appear under a different name elsewhere on the platform? Does this device fingerprint connect to three other merchants onboarded the same week?
A model trained on transaction features has no relationship data to learn from, because nobody gave it a graph to learn on. This is not a limitation of AI as a technology. It is a limitation of what most AI-powered monitoring is actually built to model. Feeding more transaction history into the same feature set produces a better version of the same narrow question. It does not produce the ability to ask a different one.
Graph-native models are trained on connections, not just events: shared devices, shared beneficiary accounts, shared ownership structures, proximity to confirmed fraud nodes. The features are relational - which means the model can surface a network even when no single transaction in it looks unusual on its own. This is what makes graph-native network risk intelligence a different capability category, not just a better version of the same one.
This matters most exactly where fraud rings are designed to hide - in coordination that stays invisible from inside any one merchant's transaction history. Five merchants distributing volume to avoid triggering a threshold produce five clean-looking transaction feeds and one obvious network, visible only once the relationships between them are modeled directly.
RBI's Master Direction on Regulation of Payment Aggregators expects ongoing, connected merchant monitoring rather than isolated point checks. A transaction-only AI model, however sophisticated, cannot satisfy that expectation on its own - because the expectation is fundamentally relational. A model built on transaction features was never designed to see it. The same challenge applies across markets - from RBI requirements in India to FCA expectations in the UK to FinCEN guidance in the US. Continuous transaction monitoring means something different once regulators expect you to monitor relationships, not just events.
Take a specific scenario. Five merchants are onboarded over three months - different legal names, different business categories, different KYC documents. Each one passes verification. Each one processes modest transaction volumes that stay well below any threshold.
To a transaction-level model: five clean merchants. No alerts fire.
To a graph-native system: five merchants sharing a single beneficiary account, two of them sharing a device fingerprint with a previously flagged entity, and one with a director linked through a phone number to a confirmed fraud ring investigated six months prior. One obvious network.
The transaction-level model was not wrong about what it saw. It was correct about every transaction. It simply could not see the thing that mattered.
This is the specific gap Verafye was designed to address.
Transaction-level AI models remain effective at catching anomalous individual behaviour. They are not designed to ask whether two merchants with clean transaction histories are coordinating through a shared beneficiary account. Verafye's graph-native network risk intelligence layer sits across both signal streams, connecting the outputs from your transaction monitoring systems with relationship intelligence - shared devices, shared accounts, proximity to confirmed fraud nodes - into one investigation-ready case.
The analyst sees a connected picture, not two separate outputs from two separate systems that happen to involve the same merchant. When a case is opened, the relationship context is already assembled. Every connection is documented. The investigation trail is audit-ready from the moment the case is created.
For payment aggregators building or refreshing their monitoring stack, the Verafye Risk Shadowing Review is a practical way to see where your current signal coverage has relationship blind spots - before fraud exploits them.
A transaction-only stack will keep catching the fraud it was built to catch: unusual amounts, odd timing, velocity spikes. It will keep missing the fraud specifically engineered to avoid all three - because that is exactly what a coordinated network is designed to do.
The cost shows up later, at examination, when the question is not whether the model caught anomalies but whether the programme could see coordination at all. A model that only understood transactions has no answer, because coordination was never in its training data to begin with.
Ask any AI-powered monitoring vendor one specific question: can this model surface a network where no individual transaction looks suspicious?
Most will describe better anomaly detection. That is not the same answer.
The vendors who can actually answer yes are the ones modeling relationships, not just events. That distinction is the one worth spending your evaluation time on - because it is the one that determines whether your system can see the fraud that is actually growing.
Vasuki
Co-Founder & CPO, Verafye
Verafye is a graph-native network risk intelligence platform built for lean fraud, AML, and risk teams at payment aggregators, PSPs, MSBs, and regulated fintech platforms.
See where your monitoring stack has blind spots
The Risk Shadowing Review maps your current coverage against relationship-level gaps.
