Merchant risk scoring: the patterns one customer can never see
TL;DR: key takeaways
- Some fraud is only visible above one customer's data. A merchant taking one payment from each of 200 agents looks unremarkable to all 200.
- Four cross-account patterns matter: fan-in, fan-out, coordinated bursts and confirmed bad counterparties.
- This is an architectural boundary, not a pricing one. Single-account scoring cannot compute these at any price.
- Confirmed fraud should propagate. One customer's settled claim is the strongest possible signal for everyone else.
There is a category of payment fraud you cannot detect, ever, using your own data. Not because your analysis is weak, but because the evidence is not in your logs. A merchant that takes exactly one £180 payment from each of 200 different agent operators has done nothing suspicious in any single operator's history. Merchant risk scoring across accounts is the only place that pattern exists. This piece sets out the four cross-account shapes worth detecting, why they are an architectural boundary rather than a pricing tier, and how to judge whether a provider's version is real.
The information that is not in your data
Start with the plain version of the problem.
Your agent pays a merchant £180. In your logs: one payment, sensible amount, settled without incident. Nothing to see, and nothing any model trained on your data could find, because there is genuinely nothing there.
Now widen the frame. That merchant registered eleven days ago. In the fortnight since, 200 distinct agent operators have each sent it one payment averaging £180. None of them repeats. None of them is large.
The shape is unmistakable; it exists only at a level of aggregation no single customer occupies.
This is not a subtle point but it is a widely ignored one, because it is uncomfortable. It means a class of merchant risk scoring is simply unavailable to anyone working from their own history, regardless of how good their engineering is.
It matters more on agent rails than it ever did on card rails. An agent discovers counterparties mid-task and pays them seconds later, so "first time we have seen this merchant" is its ordinary working day rather than a red flag. Both x402 and AP2 make that discovery-then-pay loop faster and more routine, which widens the window in which a new counterparty can collect from many payers before any of them compares notes.
Four patterns worth detecting
Cross-account merchant risk scoring comes down to four shapes. Spend7 computes them as graph signals on paid plans, and their weights are published like everything else in the ruleset.
Fan-in: many payers, one recipient
An unusual number of distinct accounts paying the same counterparty in a short window. This is the pattern above: the merchant harvesting one small payment from each of many victims, keeping every individual relationship unremarkable.
Weighted at up to 20 points. It is a strong hint and rarely conclusive: a genuinely popular new API service also has high fan-in. It is a reason to look, not a reason to refuse.
Fan-out: one agent, many recipients
The mirror image. An agent suddenly paying a much wider set of counterparties than its own history suggests.
This is the shape of a compromised credential being drained, or of an injection that produced a scattergun of purchases. Up to 15 points.
Coordinated bursts
Several unrelated accounts paying the same counterparty within minutes of each other. Genuine demand does not synchronise like that; a campaign does.
Up to 25 points.
Confirmed bad counterparties
The strongest signal available, and the simplest. Somebody raised a claim, it was investigated, it was confirmed fraudulent. That merchant is now known-bad for every account on the platform.
Weighted at 100, decisive on its own. There is no probability left to estimate.
| Signal | Max points | Requires |
|---|---|---|
| Confirmed bad counterparty | 100 | A settled claim from any account |
| Coordinated burst | 25 | Many accounts, tight time window |
| Merchant denial rate across accounts | 25 | Denials from multiple accounts |
| Fan-in | 20 | Many distinct payers, one recipient |
| Fan-out | 15 | One agent, unusual counterparty spread |
Table: cross-account graph signals in Spend7 ruleset 2026.08.2. All require visibility across accounts and are computed on paid plans only.
Why this is architecture, not a paywall
Worth being direct, because "the good detection is on the paid tier" is a familiar and often cynical arrangement.
Here it is a consequence of what the signals are. Fan-in is defined as a count of distinct payers. A single-account scorer cannot compute a smaller or worse version of it; it cannot compute it at all. The input does not exist inside one account's data.
Contrast that with a feature genuinely behind a paywall (an amount-anomaly check that works fine on free and is throttled to make you upgrade). That is a business decision dressed as a limit.
The test is simple: could the free tier compute a degraded version of this if the vendor felt generous? For fan-in, no. For a rate limit, obviously yes.
"We would rather say plainly that a signal needs data one customer does not have than pretend the free tier is doing something it structurally cannot. The upgrade path here is the architecture, not a switch we flipped."
the Spend7 engineering team
An honest note on maturity
A section most vendors skip.
These signals get stronger with the number of distinct accounts, not the volume of transactions. A graph built from one enormous customer is a single-account graph in disguise; you cannot manufacture fan-in from one payer, however many payments it makes.
Spend7's production graph started clean, deliberately: the verification data created during launch testing was deleted afterwards so the graph would not be seeded with synthetic activity that never happened. That is the right call for evidence integrity, and it means the graph signals strengthen over the coming months rather than arriving fully formed.
We would rather say that than publish a study on data we do not have. If a young platform shows you rich cross-merchant findings on day one, the reasonable question is where the merchants came from.
A worked illustration
The following is a model, not a measurement: a walk-through of how the signals compose, using round numbers chosen for clarity.
A merchant appears. Over twelve days, 200 accounts each send it one payment of roughly £180.
Account 47's view. One payment, £180, first-seen counterparty. First-seen scores 12 points; the amount is ordinary for that agent. Total maybe 12–20. Allow. Correct on the evidence available.
The graph's view. 200 distinct payers in twelve days on a counterparty with no prior history. Fan-in fires: up to 20 points. The 41 refusals across those accounts push the cross-account denial rate signal: up to 25.
Account 201 now attempts its payment. Same £180, same first-seen 12, plus 20 fan-in and up to 25 denial rate. It lands in flag territory rather than allow.
Then account 63's claim is confirmed. The merchant becomes a confirmed bad counterparty: 100 points, decisive, for every account at once. Account 202 is denied outright.
Nothing about account 202's own history changed. What changed is what the platform knew.
Common pitfalls
Assuming your model is the problem. If the signal is not in your data, a better model does not help. Get more data or accept the blind spot, but know which one you are doing.
Treating fan-in as proof. A popular new service has high fan-in. This is a reason to look, not a reason to refuse, which is exactly why it caps at 20 rather than 100.
Letting confirmed-bad flags accumulate forever. Merchants change hands and get compromised temporarily. A permanent flag with no review is a slowly-growing false-positive problem.
Not feeding claims back. If your confirmed fraud never propagates, you are contributing nothing to the graph you are relying on. The chargeback-assist workflow exists so that a settled claim becomes a signal rather than just a closed ticket.
Confusing aggregates with records. Ask precisely what crosses the account boundary. Derived counts and rates: fine. Another customer's transactions: not fine.
Where merchant risk scoring fits
Cross-account merchant risk scoring sits on top of everything else, not instead of it. Your own caps still bind first; they are decisive and they are yours. Your own behavioural signals still score. The graph adds the layer none of that can reach.
If you need to place this inside a recognised control framework, the NIST AI Risk Management Framework is the vocabulary most compliance teams work from, and counterparty scoring maps onto its measurement and traceability functions reasonably cleanly.
For the single-account layer, start with agent payment fraud detection and autonomous agent payment monitoring. For what the graph actually returns in a response, the fraud detection API page lists the signals, and pricing says plainly which tier computes them.
Frequently asked questions
- What is merchant risk scoring?
- Assessing the counterparty rather than the payment. Instead of asking whether this transaction looks odd, it asks what is known about the party receiving the money: how many distinct payers have sent to it, how recently it appeared, how often payments to it get refused, and whether anyone has ever confirmed it fraudulent. For agent payments this matters more than usual, because agents pay counterparties they discovered seconds earlier.
- Why can't I do this with my own transaction data?
- Because the patterns are defined by breadth you do not have. A merchant collecting one modest payment from each of 200 different agent operators has done nothing unusual in any single operator's logs: one payment, normal amount, settled fine. The shape only exists when you can see all 200 at once. No amount of analysis on your own data recovers information that was never in it.
- Does cross-account merchant risk scoring leak my data to other customers?
- It should not, and the distinction is between aggregates and records. What propagates is derived: a denial rate, a distinct-payer count, a confirmed-bad flag. What must not propagate is any other account's transactions, amounts or identities. If a provider cannot explain which of those two categories crosses the boundary, that is the question to press on.
- How long before a merchant graph is useful?
- It scales with the number of distinct accounts, not the number of transactions. A graph built from one very large customer is still a single-account graph wearing a costume, because the fan-in signal needs many payers by definition. This is why the honest answer for any new platform is that these signals strengthen over time, and why claiming otherwise on day one should be treated sceptically.
Score a payment before it settles
Spend7 returns allow, flag or deny in one call, with the signals that produced it. The free tier covers a single agent, its spend caps and its full decision log.
