Michael Shmulevich, CEO of Superscript Systems specializing in payment infrastructure and AI for financial operations.
Most AI projects in financial operations stall rather than fail outright. A team builds an agent that reads invoices or proposes payouts, the demo goes beautifully and then the project sits for two quarters while risk, compliance and an enterprise customer’s vendor assessment all ask the same question in different words. What happens when the model is wrong?
The team usually has an answer, and it is rarely one that survives an auditor’s scrutiny. The model is almost never the reason. Nobody designed the boundary between the part of the system that reasons and the part of it that moves money.
Wiring a language model to a payment API is a day of work. Deciding where the reasoning stops is the part that takes real thought.
Two Systems With Opposite Tolerance For Being Wrong
A language model is probabilistic by design, and that is the reason to use one. It handles the invoice that arrived as a photograph, the contract clause a lawyer wrote in 2019, the statement that does not quite line up with your ledger. Run it twice on the same input and you may get two slightly different answers.
Payment infrastructure is the opposite. Same input, same output, every time. Splits sum to the cent or the batch does not go out. There is no confidence interval on a settled wire.
Put those two things in direct contact and you get something impressive that cannot go to production. No prompt fixes that. It is an architecture question, and it turns on one rule: The agent proposes, and nothing else.
Six Responsibilities, Kept Separate
• The agent interprets and recommends. Its output is a structured proposal rather than an action. Type, counterparty, amount, source account, the evidence used and a rationale a person can read in 10 seconds. Give it an explicit way to say it does not have enough to decide, or it will fill the schema with something.
• A policy layer decides what is permitted. Teams get this wrong by putting policy in the system prompt. A prompt is guidance, and it arrives through the same channel as the untrusted document the agent is reading. Policy is enforcement. It lives in code, it is versioned and it denies by default.
• Deterministic code does the money math. Splits, fees, currency conversion, withholding, rounding. Arithmetic that is right almost every time is a rounding error factory, and those errors surface months later in a partner’s statement. This layer also validates. Do the parts sum to the whole? Is this a duplicate? Is the amount plausible against what this counterparty has been paid before?
• Approval thresholds decide when a human steps in. Most teams make this about dollar amount, which is weak on its own. What predicts trouble is novelty, change, deviation, evidence quality and irreversibility. First payment to this counterparty. Bank details modified in the last 30 days, which is the shape of nearly every successful vendor payment fraud.
• An execution layer absorbs reality. Providers time out and services restart mid-batch. Idempotency keys derived from the business event mean that a retry produces one payment, not two. Payment state is a state machine, never a boolean, and reversals are compensating entries rather than deletions.
• An audit trail records what happened. The bar is reconstruction, not logging. A year from now, someone with no context should be able to rebuild the decision: what the agent saw, what it proposed, which model and policy versions were live, who approved it and what they were shown. Append only.
Two Things That Happened
Here are two examples that happened recently in my own work.
An invoice arrived with the total written the European way, using a comma as the decimal point. The agent misread the separators and proposed an amount about a hundred times too large. It is a formatting convention, ambiguous in isolation, and a tired clerk makes the same mistake at five in the afternoon. The proposal never reached a payment provider. The amount was nowhere near anything that vendor had been paid before, a plausibility check fired and it went to a person with the anomaly attached to it.
The second one cuts the other way. An invoice total differed from our internal time tracker by more than the rounding amount. The deterministic checks did their job, which was to notice and stop, and they had no way to say why. The reconciliation agent went and read the actual invoice rather than the extracted fields, and came back with a proposal: the invoice was denominated in Canadian dollars and everything downstream had assumed USD. Correct, as it turned out, and a person confirmed it in about a minute.
Neither half gets there alone. The check found a discrepancy and had no theory about it. The agent had a theory and no authority to act on it. That split is the design.
What To Ask Your Team
If you have an agent near money right now, four questions will tell you most of what you need to know. Where does the model’s output stop being a suggestion? Is your policy written in code or written in a prompt? Which numbers does the model calculate that end up on a ledger? And could someone reconstruct a specific decision from six months ago using only what the system stored?
If those answers come slowly, the architecture is the problem. Better to find that now than in the middle of a compliance review, when the cost is a delayed deal and a customer who has started asking harder questions.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
