- Agentic AI, payment fraud, and stablecoin rails look like separate tracks with separate owners, but all three depend on a data layer that can make a correct decision while the transaction is still in flight.
- Agents change the load profile. Thousands can hit the same merchant or issuer at once, and every action needs a policy check against current authorization, mandate, and balance, not a cache that is minutes old.
- On instant rails, a fraud score that arrives after authorization cannot stop the loss. Fraud decisioning has to run inside the authorization path, usually within a few milliseconds.
- Stablecoin rails settle 24/7 in seconds, removing the batch windows that end-of-day positions, overnight limit refreshes, and next-day reconciliation were built around.
- The common requirement is to decide in the event: keep state and decision logic together, enforce correctness under concurrency, favor fresh data over big data, and keep analytics separate from decisioning.
TL;DR
If you walked the floor at Money20/20 in Las Vegas last month, you heard three conversations on repeat: agentic AI, payment fraud, and stablecoin rails. I spent much of my time in the blockchain summit sessions, but the same three themes followed me into every hallway and coffee line.
On the surface, they look like separate tracks with separate buyers. The AI team owns agents, the risk team owns fraud, and treasury or a digital assets group owns stablecoins. I came away convinced they share one dependency that got far less stage time than it deserved: the data layer that has to make a correct decision while the transaction is still in flight.
Here is how each track pushes on that layer, and why it may matter more than which model or rail you pick.
Agentic AI changes who is on the other end of the transaction
Most of the agentic commerce discussion centered on trust. How does a merchant know an agent is acting for a real customer? How are spending mandates enforced? Who is liable when an agent buys the wrong thing? Those are real questions. What got less attention is the load profile.
A human checks out a few times a day. An agent can comparison-shop, negotiate, and retry in seconds, and thousands of them can hit the same merchant or issuer at once. Every one of those actions needs a policy check against current state. Is this agent still authorized? How much of the mandate is left? Has the customer’s balance changed in the last second?
If that check runs against a cache that is a few minutes stale, the agent acts on information that is already wrong. Agents do not wait for a nightly reconciliation. They act, and someone has to unwind the result.
Fraud is now an industry, so detection has to be inline
A recurring point in the fraud sessions was that fraud now runs like a business, with its own tooling, playbooks, and even service models. The practical consequence came up repeatedly. Once money moves on an instant rail, there is no clawback window to hide behind. A risk score that arrives after authorization is a report, not a control.
That pushes fraud decisioning into the authorization path itself, usually with a budget of a few milliseconds. The signals that matter are also increasingly contextual: velocity across accounts, links between devices and identities, and behavior in the last few minutes rather than the last few months.
Models are getting better at spotting patterns. The harder part is feeding them fresh, consistent features under peak load, then acting on the answer before the transaction commits. I heard plenty about smarter models and much less about where those features live and how fast they can be read and updated.
Stablecoin rails remove the batch buffer
The blockchain summit had a noticeably more practical tone than the stablecoin talk of a few years ago. The question has moved from whether stablecoins matter to how banks and payment companies connect them to what they already run: on and off ramps, treasury flows, compliance, and cross-border settlement.
What struck me is how much of the traditional stack quietly depends on batch windows. End-of-day positions, overnight limit refreshes, next-day reconciliation. A rail that runs 24/7 and settles in seconds removes the buffer those processes were built around.
If a bank offers stablecoin settlement but still calculates exposure and liquidity on a schedule, it has a gap where risk builds up and nobody can see it. Sanctions screening, limit checks, and ledger updates all have to keep pace with the rail. Otherwise the rail’s speed becomes a liability.
The common requirement: decide in the event, not after it
Put the three tracks side by side and the requirement looks the same. Each one needs the system to take an event, check it against the current state of accounts, limits, and risk, make a decision, and update that state before the next event arrives. That usually means single-digit milliseconds, with no loss of consistency when volume spikes.
That has a few concrete implications for architecture teams:
- State and decision logic belong together. Shuttling data between a stream processor, a cache, and a database adds latency and opens windows where two components disagree.
- Correctness under concurrency is not optional. When agents and instant rails create bursts, two transactions racing against the same limit is a normal day, not an edge case.
- Fresh beats big. A smaller set of current features usually serves an authorization decision better than a large set that is minutes old.
- Analytics and decisioning are different jobs. A data lake is where you learn. It is not where you approve a payment.
My read is that many firms are buying the front end of these trends, such as agent frameworks, fraud models, and stablecoin partnerships, before checking whether their transactional core can keep up.
Where this leaves us
None of this means the models or the rails are unimportant. It means the gap between a good demo and a production system is increasingly a data problem. The firms that pull ahead in agentic commerce, instant fraud prevention, and stablecoin settlement will be the ones whose infrastructure can make a trustworthy decision in the moment, every time.
That is the problem we work on every day at Volt Active Data, helping financial institutions run real-time decisions on live, consistent state at scale. If your team is working through any of these three tracks and wants to compare notes, talk to us.
What does it mean to decide in the event rather than after it?
Deciding in the event means the system checks a transaction against the current state of accounts, limits, and risk, makes a decision, and updates that state before the next transaction arrives. The decision happens while the transaction is still in flight, not in a later batch or reconciliation step. For payments, that window is usually single-digit milliseconds.
What were the biggest themes at Money20/20 2026?
Agentic AI, payment fraud, and stablecoin rails dominated the conversation. Each is usually owned by a different team, but all three depend on a data layer that can make a correct, consistent decision before a transaction commits. That shared dependency got much less attention than the models and rails themselves.
Why does agentic commerce put pressure on payment infrastructure?
Agents generate far more transactions than humans do, and they act in seconds. A single agent can comparison-shop, negotiate, and retry quickly, and thousands can hit the same merchant or issuer at once. Every action needs a policy check against current authorization, remaining mandate, and balance, and a check against a stale cache lets the agent act on information that is already wrong.
Why does fraud detection need to run inline with payment authorization?
On instant payment rails, there is no clawback window, so a risk score that arrives after authorization cannot stop the loss. Fraud decisioning has to sit inside the authorization path, usually with a budget of a few milliseconds. The hard part is less the model and more feeding it fresh, consistent features under peak load.
How do stablecoin rails change bank risk and liquidity processes?
Stablecoin rails run 24/7 and settle in seconds, which removes the batch windows many bank processes rely on, such as end-of-day positions, overnight limit refreshes, and next-day reconciliation. A bank that offers stablecoin settlement but still calculates exposure on a schedule has a gap where risk builds up unseen. Sanctions screening, limit checks, and ledger updates all have to keep pace with the rail.
Can a data lake be used to approve payments in real time?
No. A data lake is built for analysis and model training, not for making authorization decisions in milliseconds against live state. Analytics and decisioning are different jobs, and approving a payment requires current, consistent data at the moment of the transaction.
What happens when two transactions hit the same limit at the same time?
Without strong consistency, both can be approved against a limit that only had room for one. Agent-driven traffic and instant rails make these bursts routine rather than rare. Systems that keep state and decision logic together, and enforce correctness under concurrency, prevent the double approval instead of catching it later.
What should payment teams check before investing in agentic AI, fraud models, or stablecoin settlement?
Check whether the transactional core can make a correct decision on live state within the transaction’s latency budget, even under peak load. Many firms adopt agent frameworks, fraud models, and stablecoin partnerships before confirming that the systems underneath can keep up. If decisions depend on cached data, scheduled refreshes, or data moving between several components, the core is the constraint.
About Author
Featured Resources
