ai financial systems cannot afford to be stochastic

ai fintech architecture reconciliation

published 2026-08-27

AI is pushing probabilistic systems deeper into financial infrastructure, and I believe that's freaking cool.

I want to be clear about where I stand, because the title says the opposite. I am not against AI in finance. I want LLMs and agents in production, reading evidence, classifying exceptions, and investigating failures.

My argument is about the order you build it in. A financial system is already uncertain before any model touches it:

Bank references get truncated.
Settlement dates shift.
Providers retry and send the same event twice.
Callbacks arrive out of order.
Workers crash in the middle of a write.
Records from two systems rarely agree completely.
And so on.

And then when you add a probabilistic layer on top of that, you are not getting intelligence. You are getting more chaos.

Financial systems can reason probabilistically. But the evidence, the decisions, and the financial actions that come after that reasoning need deterministic records.

Most of the time, when a team says it wants AI in a financial system, what it wants is automation. So between the deterministic layer and the AI layer, there needs to be an automation layer.

start with the layer that does not guess

Before adding an intelligence layer to financial infrastructure, I would ask a simpler question:

Can a human understand what happened without the AI?

If the answer is no, the model is being asked to compensate for missing infrastructure. That never ends well, because you cannot debug a system where the evidence and the reasoning are both uncertain.

A financial system should already expose enough evidence for an engineer, a payment operator, or a finance team to reconstruct what happened to an operation: where the money started, which systems it crossed, what outcome was expected, what actually occurred, and which step diverged.

Every financial operation has an intent. For example, money moves to fund a wallet, settle an obligation, or pay a merchant. The infrastructure should preserve that intent and the events that describe how the operation progressed.

At minimum, you would want to record the following for every financial operation:

Stable operation and event identities, so you follow one operation across services without guessing which record is which.
Exact amounts and currencies, so a rounding difference reads as a rounding difference and not as a mismatch.
occurred_at and received_at, so a late event does not look like a failed one.
Expected stages and deadlines, so the system knows something is missing before a customer tells you.
References across providers, wallets, and ledgers, so you reconcile without asking a human to remember the mapping.
Correlation and causation where they are explicitly known, so nobody has to infer later why a second credit exists.
Immutable or append-oriented evidence, so a correction adds a fact instead of destroying the one you were wrong about.
An audit trail for every evaluation, correction, and action, so you answer why the system reached a conclusion at a point in time.

Every line there exists because somebody eventually has to answer a question about money without guessing.

You also want the tooling around that evidence to be deterministic. Given the same evidence snapshot and the same rule version, the system should produce the same evaluation. If a correction happens later, you record it as a new fact rather than a rewrite of what the system previously knew.

You should test that layer against the ugly cases: duplicates, missing events, out-of-order delivery, conflicting evidence, one-to-many relationships, amount drift, late settlement, and partial operations. Its failures should be engineering failures you can find and fix, not ambiguous model behavior you cannot reconstruct.

That layer also has to be fast. Financial evidence gets large quickly, and your tooling needs to inspect and reconcile millions of records without forcing a model to reason over millions of raw rows.

financial truth changes as evidence arrives

Take a payment, for example. The provider marks it succeeded at 14:02. The wallet is credited at 14:04. But that wallet event does not reach your monitoring system until 14:12.

Two timestamps matter here.

occurred_at is when the financial fact happened.
received_at is when another system learned about it.

So if you ask your system at 14:07 whether the payment completed, it tells you the wallet credit is missing. If you ask again at 14:12, it tells you the payment completed late. Same question, same rules, two answers.

Two evaluations of the same payment. Asked at 14:07, the evidence holds payment.initiated and provider.succeeded, and the answer is missing_wallet_credit. Asked at 14:12, the evidence also holds a late wallet.credited, and the same rules answer completed_late.

part of finance runs on judgment calls

Take reconciliation, for example. Exact identifiers give you clean matches when the reference arrives intact. Often it does not, because banks truncate it and providers reuse it after a retry. So the rest of the time you match on tolerances, fuzzy references, and scores.

So a matcher gives you a candidate match at 0.94, not a yes or no. Nothing is wrong with that. The mistake is letting that 0.94 collapse silently into a yes.

Once it collapses, nobody can tell later whether a human accepted the match, an automated rule accepted it, or the matcher accepted it by default. So you keep the score, and you record the decision next to it, with the matcher version and who or what decided.

Left, what the matcher produced: candidate_match, score 0.94, and its signals. Right, what the system records: the same match and score, plus matcher_version 4.2, decision accepted, decision_source human_review.

And if the decision turns out wrong, you record a reversal instead of editing it.

most teams wanting ai need automation with reasoning

Once the deterministic layer exists, a lot of what people wanted the AI for turns out to be automation.

So you should build the automation layer on purpose, and not leave it as whatever happens between the data and the model. And the model should not sit inside the live process.

Take reconciliation again, for example. At 02:00, your automation layer gathers the provider files and the ledger export, runs the matching passes, and produces a result: what matched, what did not, which records are duplicates, and which exceptions need a human.

That run writes an artifact, and you decide what goes into it. For this reconciliation, the artifact carries:

operation identifiers.
amounts and currencies.
reason codes.
match scores.

It does not carry customer names or raw statement lines.

At 06:00, a model reads that artifact. It groups four hundred exceptions into twelve likely causes, drafts the morning digest for the operations team, and proposes which exceptions to review first.

Left, deterministic and inside the financial process: automation runs at 02:00 and writes a result artifact containing only the fields you chose. Right, stochastic and hours later: a model reads that artifact at 06:00 and returns a proposal for review. The artifact is the compliance gate.

The model is off the hot path. It never sits inside a payment flow. If it is slow, unavailable, or wrong, the reconciliation already ran and the evidence is already recorded. You lose the digest, not the money.

You also decide what the model sees. That is data minimization, and it happens in the automation layer because the automation layer is the last deterministic step before the model.

Under GDPR you share the minimum personal data needed for the purpose, which in practice means filtering before the data leaves. Large language models rarely meet anonymisation standards, and a financial institution has to assess the legality of sending sensitive data to a third party even transiently. The automation layer is where you make sure that transfer never carries what it should not. It is the difference between hoping a prompt does not leak something, and knowing the model never received it.

Compliance is only one example. The automation layer buys you three other things:

It makes the AI affordable, because a model reading four hundred grouped exceptions costs almost nothing and a model reading two million ledger rows does not.
It makes the AI better, because the model spends its capacity on the hard cases instead of finding them.
It keeps the model replaceable, because the artifact is a contract and the pipeline does not move when the provider does.

your stochastic layer should be the smallest one

Once the artifact exists, the model finally has real work to do. And the temptation is to give it more work than it deserves.

I would not. Before you hand any job to a model, ask three questions:

Does this job need to be reproducible? If yes, it stays deterministic. A matcher at version 4.2 reproduces its output from its inputs. A hosted model does not, and eventually it is retired.
Can you tell when the answer is wrong? A model returns valid output that is wrong. It pairs the wrong two transactions and writes perfectly plausible reason codes for the pairing. If you cannot catch that, the job is not ready for a model.
Does the job move money? Then it is not a job for a model. Not yet, and not because the model is bad at it.

Everything else, the model can have. In the reconciliation run, it groups exceptions, explains likely causes, and ranks what to review first. That is real value, and it is nowhere near the ledger.

At the end of the day, your model is allowed to be uncertain. Your system is not. That is why financial truth should never be probabilistic. If it is, you lose money, and then you pay fines on top of what you lost.

where i land

The biggest phase of AI in finance is not the AI. It is the deterministic tools and the automation layer underneath it. At the end of the day, the model only reasons on the data you hand it, so the quality of that layer sets the ceiling on everything above it.

I think we should treat that as its own problem, as an industry, and not as plumbing you finish before the interesting work starts.

Most of what I wrote here comes from my work on reconciliation and accounting systems, and from what I am building now with Reconify, a payment monitoring platform. When I talk to teams putting AI into finance, the conversation lands in the same place almost every time. The deterministic layer underneath is not fast enough, or not complete enough, or not queryable enough. The model is not the problem.

So yes, AI in finance is the future, and I want it. But the transition happens step by step. Evidence first, then automation, and then the model.

If you are working in this space, I would like your opinion. This blog is deliberately simple and there is no comment box, so email is how I have these conversations.