AI and Financial Systems

Customers ask the same two questions all the time. Can we use AI to help build our financial systems? And, can we hand off manual financial tasks to AI agents?

Why? I think my friend Derek said it best in his recent appearance at Stripe Connect:

Automation doesn’t reduce risk if the underlying assumptions and data are unreliable. In fact it just amplifies it.

— Derek Shimozawa

So what things do you need in order to have an AI-ready foundation for your financial systems?

A Bulletproof System of Record

AI is a powerful tool, but it’s a non-deterministic and unreliable one. Luckily, a lot of that unreliability can be mitigated by having it double check its work against a source of truth, or having a separate agent whose sole job is to verify work and references. Unfortunately, those strategies don’t work well if the underlying data itself is non-deterministic or unreliable.

The fix is to have a clear and trustworthy system of record for your finances that code, agents, and/or human oversight can all use to verify the work is correct.

A system of record serves as the single source of truth for any arbitrary financial fact. If there is a clearly defined way to ask financial questions, and the answers are deterministic and correct, then you have defined a system of record. You could run a single global system of record (preferred) or multiple, as long as each financial fact is recorded in only one system.

The most common system of record for financial data is a ledger, although it’s not the only option.

Criteria for a Good System of Record

So what does your system of record need to look like in order to be a rock solid foundation?

• It needs to be deterministic

  Determinism is the property of a system that guarantees that given the same inputs, the system always produces the same provable result. See more in our blog on deterministic attribution.

• It needs to be immutable

  Immutability means once data is created it can’t be changed, ever, even for corrections.

• It needs to separate financial facts from expectations

  Financial facts are the actual money changes that have happened or are actively happening. This is different from things you hope will happen, such as a customer paying an invoice on a certain date, or revenue projection for the year. Financial facts are an input to accounting but accounting activity cannot change or produce facts. Accounting is the process of telling a story from financial facts, but the story itself is not a fact.

• It needs to be realtime

  Realtime availability means that the system can actively reject bad things, not just accept all inputs.

• It needs to be uncontested

  Financial facts can’t be in two sources of truth. If they are, it’s impossible to know which one is correct. This is usually rationalized by saying that they are just copies of each other, so they’ll always be in sync. This is not true, they will drift.

Without these pieces in place, asking AI to pull data from your system is very risky. You are likely to end up with incorrect data that can’t be fixed via verification pipelines.

Imagine you ask your agent to create a quarterly report for you. However, instead of the latest data it finds a spreadsheet that was created over a month ago and hasn’t been updated since. The agent creates the report based on the data in the spreadsheet, and you are none the wiser. This is the kind of mistake that is easy to make if you can’t provide your agents with a consistent system of record to reference.

What Bad Looks Like

Here is a quick list of signals we see that almost always indicate that you are not ready for AI to be active in your financial systems.

• If your financial data lives in your product model tables, you aren’t ready.
• If the source of truth for your financial data is mutable, you aren’t ready.
• If you don’t know what your financial source of truth is, you aren’t ready.

Guardrails

The second thing you’ll need are are low level controls. AI coding models and agents are like extremely capable puppies. They are high energy, very eager to please, and overzealous as hell.

Why is that a financial problem? Well, let’s say you spin up an agent and ask it to go out and get you as many new customers as possible. Your new puppy wakes up and sees that it can issue usage credits to new customers, and it does. It issues hundreds of thousands of credits, most of which have no constraints on re-use. An hour later those reusable credit codes end up on Reddit, and now you have $5m in potential losses, most of which are fraudulent.

The puppy didn’t do anything wrong. In fact, it did exactly what you probably wanted it to do by correctly giving credits to new customers, it just did it without any consideration of the financial consequences for your company.

You might think the fix is to tell it about those financial considerations, but that will just muddy the context and make it less effective at what you want it to do. It’s better to have guardrails in place that can put limits on financial risk, and explain to the agent what happened when it runs into a blocker. This is why in the system of record section we talked about the importance of having an online ledger for AI. A traditional offline-only ledger can accurately record the financial losses, but it can’t stop the agent from creating them in the first place.

On the coding side, let’s say that you are vibe coding an app to pay your suppliers. Your instructions are simple: have it wake up once a day and pay your suppliers what they are owed. The AI builds exactly what you asked for - in fact it adds in some great resiliency features you didn’t even think of, like retrying the job if it fails. The first week, everything goes fine, it wakes up and does the payouts. Then, on the 8th day, it processes half of the payments and then runs into a supplier that actually owes you money instead of the other way around and the code can’t handle it.

Uh oh. The program crashes.

Not to worry though, the AI built in retries! So the job wakes up again, and starts the payouts from the beginning again, paying out all the suppliers until it once again hits the bad one and crashes. Then it wakes up and starts over again, and again, and again… By the time the retries are exhausted you’ve paid out the first half of your suppliers dozens of times the amount they were owed.

Again, this isn’t the puppy’s fault. It built the app you asked it to, and even built in retries which are a best practice for programs like this. It did the right thing…it just hit a case neither of you ever expected. If the underlying financial infrastructure was built on idempotency, or had limits on actions that caused financial losses, it would have greatly limited the impact of the mistake.

Here is a high-level overview of the guardrails we recommend:

• Budgeting for all intentional losses (promotions, discounts, etc.)
• Idempotency checks for all financial actions (including credits, coupons, etc.)
• Blocking, or escalating to human oversight, financial actions that would cause an unintentional loss (over-payments, internal miscalculations, etc.)

On Double-Entry Ledgering

The traditional standard in ledgering tends to be double-entry ledgering, and there is some really solid software (like TigerBeetle) that can help you build a very performant double-entry ledger. However, as a system of record double-entry struggles with several of these requirements. Some are just harder to implement, some are not possible at all in double-entry. If you are choosing double-entry as your system of record here are some rough categorizations of the difficulty of implementing each of the requirements.

Let’s dig just a little bit into each of the ones listed as hard or impossible.

Financial facts vs expectations separation

While double-entry can be a fact-only store, it is traditionally used in accounting where expectations (often called payables and receivables) are very important and are intentionally mixed in with financial facts to tell an accounting story. Due to this, most of the material you read (and double-entry software) will actively expect you to mix financial facts and expectations together and won’t even call out the distinction between the two.

Budgeting

Budgeting is the process of creating a pool of money that can be used to cover losses that is limited by its funding. These could be intentional losses due to a marketing campaign, or operational losses due to mistakes. While it is possible to create budget accounts in double-entry, the process is unintuitive and requires careful administration. Here are some top pain points:

• A budget account has to be funded from somewhere. You’ll need to create a “fake” inbound account that is strictly negative which funds the budget.
• Negative amounts and balances have no special meaning in double-entry. There is no built-in concept of a bad negative balance (as it depends on if the account is credit-normal or debit-normal). This is a problem because your budget accounts need to have a minimum balance of zero to be effective, but the inbound account has to be strictly negative, so you can’t have a single rule for the whole system.
• Since double-entry doesn’t keep track of money past the most recent transaction it is easy to accidentally create scenarios where money budgeted for a loss can actually be refunded as cash.

Determinism

Determinism in this context means that given the same inputs, the system always produces the same provable result. This is true of an individual transaction in double-entry, but not true once accounts or balances are involved in any way. The proof for this is somewhat complex, but it hinges on two main concepts:

• Double-entry loses all traceability after the most recent transaction
• Due to offsets being crucial to double-entry, it produces different results for different time windows

If you are interested in a more detailed breakdown of these problems check out our blog on the attribution problem.

Blocking Losses

Double-entry was designed to be an after-the-fact recording of things that happened. It doesn’t care if something cost your company money, so long as it has a record of it happening. You can achieve something that looks like a lossless system by enforcing strictly positive balances for all accounts, but that will greatly complicate trying to represent money that you are owed in the system, as you will need accounts with positive balances that represent debt.

Overall summary: it can be done, but it’s a bad fit. See our blog on lossless systems for more information on what a system needs in order to provide loss prevention.

Conclusion

If you are thinking about letting AI loose in your system either for coding, or agentic operations, make sure that you have the right foundation in place to help make it successful. Things like a solid system of record, guardrails, and determinism are all critical to gaining the productivity of AI while not risking your business.

The good news is that you don’t have to build all of these things yourself. String Theory has all of these properties out of the box, and those aren’t even the coolest parts.