Your Fraud Rules Assume the Same Input Every Time. Your AI Agents Don't Play By That Rule.

I’ve been battling with my preferred AI model these last couple of weeks. Even though I have rules and prompts and reference material, it seems to have taken a backward slide. Every time I upgrade my software I have to figure out what’s broken this time. Then, because I’m not sure I can trust the output, I’ll take it over to another AI model and have it check for holes in the logic.

Ask an AI agent the same question twice and you can get two different answers. That's how they work, whether it's drifting after an update like the one I just described, or simply reasoning its way to a different path in the same session. And that is how the software initiating payments on your rails is going to work.

Your controls are expecting consistent inputs. They were not designed for results that change each iteration. They were built on the design principle that the same input produces the same output. The rule should fire the same way every time, defined thresholds should not be changing day to day. These used to be the most dependable pieces of your payment architecture, but with agentic AI, it becomes the least reliable service in your tech stack.

Over the last two issues I have been painting a picture to show you that the payment instruction has changed underneath us. It used to be the record of a decision a person already made. Now, it can carry the decision itself, brought into existence by software acting on a goal. The thing is, most financial institutions aren’t even close to defining how to understand whether these agentic-initiated transactions are good before the transaction settles. So in this article, we’re going to explore this a little more.

For most of banking history, every single transaction was the result of a prior series of events. A batch ran, the same records went in, the same postings came out. A fraud rule that flagged a pattern on Monday flagged it the same way on Friday. Grounded and predictable. When something went wrong you could trace it, because the system was designed for a consistent, repeatable output. Predictability was the name of the game.

With agentic solutions that grounding is gone. AI agents are not following a script. They interpret goals and choose a path, and each time it runs, it picks a different path. You can’t predict what instructions your rails might receive. You can’t look at the code and check to make sure it’s still running right. It’s no longer black and white where you go back and point specifically to a decision that was made and why. You are governing a space you cannot fully explain.

We see the same shift across the fraud ecosystem. Attackers and defenders are increasingly using the same kinds of generative models that power your customer’s agents.

The difference is what they are asking those models to do.

An attacker can use AI to keep changing the payment instruction, the language around it, the transaction pattern, or even the apparent reason for the payment. The moment one version starts triggering a fraud rule, the next version can look slightly different while still appearing perfectly legitimate.

Instinctively we want to make the technology “behave” like the systems we already understand.

Constrain the model. Add more rules. Try something else to make the agent’s behavior predictable. Keep tightening and reworking the boundary criteria, until every possible outcome has been accounted for.

Of course, while that sounds reasonable, it also implies that you’ll eventually be able to make it predictable (likely not!).

Every serious conversation I’ve heard about agentic AI this year talked about the challenges of non-deterministic models. The hallucinations. The differing outputs, different explanations, the need to have agents monitor agents.

But since this is our new world, even though the instruction to the rail is non-deterministic, you still need to have rules in place to differentiate the good actors from the bad.

You obviously can’t control what is in an inbound transaction, but you can make sure that you have a consistent approach to analyzing the transaction.

The same policy should be applied at the same point in time, to the transaction path. The same evaluation criteria should be applied (approve, decline, step up, hold, route for human review, etc.)

You, not the agent, need to be applying that discipline consistently.

This is where the Real-Time Control Layer™ comes in. It brings together the context carried by the instruction, the account and customer history, the financial institution’s risk appetite, fraud signals, permissions, limits, and any other information that is needed to give you confidence to disposition the payment before it becomes final.

Its goal is to ensure that every payment instruction is reviewed by a decision rule process that your financial institution designed, and can explain. You aren’t redesigning your whole system, just this one point in the flow that is completely dependable.

You are never going to be able to design a solution that accounts for every transaction variation, whether human-initiated or bot. But by starting to treat the information in the payment instruction as valuable signal, and then enriching it with other contextual data, you can mitigate some of the risk.

The most expensive thing for your financial institution to do, like many in the industry today, is to delay. You can’t afford to wait until agentic-initiated transactions become mainstream. Waiting for things to be standardized. Waiting for someone to hand you the “golden template.” Waiting for the environment to feel safe enough to take action.

The successful financial institution will start treating the context inside the payment instruction as useful decision material rather than extra data to be stripped away. They will define which decisions can be automated, which require additional evidence, and which should involve a person. And keep human judgment “in the loop” where it adds value.

By acknowledging the non-deterministic nature of AI agents, your financial institution can build differently: read the instruction as the raw material of a real-time decision rather than data to be stripped, and keep the human in the loop by design, not as a stopgap. It is not a temporary crutch. It is a critical part of the process.

That is how you will be able to defend your organization as the technology scales.

Here is the question worth taking into your next architecture conversation: if your institution’s controls only work when the same input produces the same output, what happens the first time it does not, and where in your stack does that get decided?

If your leadership team would benefit from this perspective in the room, I’d welcome the conversation.

If your leadership team would benefit from this perspective in the room, I’d welcome the conversation.