Most of the working vocabulary of modern AI describes problems payments solved decades ago under different names. Evals are certification. Context windows are authorisation messages. Distillation is what every fraud system already does when it learns in batch and scores in milliseconds. Context rot is rule sprawl. The translation is close enough to be useful and the gaps are where the interesting work is. There is one concept payments has that the AI vocabulary is still missing, and it is the one that matters most when an agent can spend money.
TL;DR
- Modern AI and payments solve many of the same operational problems under different names. Evals resemble certification, context windows resemble authorisation messages, RAG resembles enrichment, and context rot mirrors rule sprawl.
- Payments brings decades of lessons for running probabilistic systems at scale: test independently, re-evaluate after every change, keep decision inputs clean, retire stale rules, and verify what happens in the ledger after a decision.
- The concept AI needs when agents can spend money is finality. Accuracy alone is not enough; evaluations must also measure whether a wrong action can be reversed, because a bad answer can be regenerated, but a settled payment may be impossible to undo.
Why these eight words
Evals. Frontier models. Open weights. Tokens. Context windows. Distillation. RAG. Context rot.
That is the working vocabulary governing how modern AI systems are actually built and run. Most people using these tools every day can name the products fluently and have never needed a single one of these terms. The gap shows up in decisions rather than in conversation, which is what makes it expensive.
If you work in payments, you are in an unusual position. Almost every one of these words describes something you already operate under a different name. One of them is a word you already use, for something close to the opposite.
Payments has spent thirty years building operational discipline around systems that fail quietly, decide probabilistically, and are discovered to be wrong long after the fact. That is the same problem the AI industry is now solving from scratch, with new vocabulary and, in one important respect, less caution.
So this is that translation, term by term, plus the one word I think payments should contribute back.
The translation table
| AI term | What it means | Payments already calls it | What payments learned the hard way |
|---|---|---|---|
| Evals | Structured private tests measuring performance on your specific tasks and data | Certification, test suites | Certification is external and adversarial, not self-graded, and re-run on every release, not once at launch |
| Frontier models | The most capable models available | The premium route | Best available is not the same as right for this transaction. Route by need, not prestige |
| Open weights | Models whose parameters are published, runnable anywhere | Owning the rail vs renting it | For regulated flows, where a system runs often matters more than how well it scores |
| Tokens | The chunks of text a model processes, and the unit you are billed in | Tokens, meaning something else entirely | Same word, opposite job. See below |
| Context window | The maximum a model can hold in view at once | The authorisation message | A decision is only as good as the fields in the request. Absence is not neutral |
| Distillation | Training a smaller, faster model from a larger one's outputs | Learn in batch, score in line | You have milliseconds. Whatever is heavy runs offline |
| RAG | Pulling facts from external sources before answering | Enrichment | BIN lookups, negative lists, account updater. Payments never decided on the message alone |
| Context rot | Accuracy degrading as a session fills with clutter | Rule sprawl, alert fatigue | Systems do not decay from what you added. They decay from what you never removed |
Eight for eight. That is not a coincidence, and it is not because payments people are clever. It is because both fields are trying to run non-deterministic decisioning at scale under time pressure with real money attached, and there are only so many ways to do that.
Four of these deserve more than a table row
Tokens, and the collision nobody warns you about
In payments, a token replaces a card number so the real credential is never exposed. Its entire job is to carry less information than the thing it replaces. It exists to remove risk.
In AI, a token is a chunk of text a model processes, and it is the unit you pay for. Its entire job is to carry information. It exists to meter cost.
Same word. Opposite purposes. One is a security primitive, the other is a billing unit. Say which one you mean. It sounds trivial. It will save you a meeting a month.
Context window, or why the decline-codes argument was an AI argument all along
An authorisation request is a fixed context window. A defined set of fields carrying everything the issuer will ever know about this transaction at the moment it decides. There is no follow-up. There is no clarifying question. Whatever is not in the message does not exist.
Everything payments has learned about that constraint transfers directly. Fill the fields. Send the address data. An incomplete request is not neutral, it is weaker, because the model on the other side reads absence as a lack of evidence rather than an absence of risk. We wrote about the consequences in why international payments fail.
This is exactly the failure mode people hit with language models and long context: assuming that what was not said will be inferred generously. It will not.
Distillation, which fraud teams have done for twenty years
Real-time payments decisioning has always run on a hard latency budget. You cannot run the heavy thing inline. So the heavy thing runs offline, learns the patterns, and produces something small and fast that runs on the wire.
That is distillation. Payments called it scoring, or model deployment, or "the production model", and never thought of it as a technique worth naming. The AI industry named it, and in naming it made it a design choice rather than an accident of infrastructure. That is worth respecting. Naming a thing is what lets you improve it deliberately.
Context rot, which every risk team has lived through
A fraud rule set that has been accumulating for six years contains rules that contradict each other, rules that fire on conditions that no longer exist, and rules nobody will remove because nobody remembers what they were for. Performance degrades not from any single bad rule but from the accumulated noise of all of them.
That is context rot, in production, before anyone had the phrase. The lesson payments learned expensively: you need a retirement discipline, not just an addition discipline. Anyone building long-running agents is about to learn this again.
Where the analogy breaks
Certification is external. Evals are usually not. In payments you do not decide for yourself whether you are ready for production. A scheme hands you a test suite, you run against it, and someone else says yes or no. Most evals today are written by the same team that built the system, graded against criteria that team chose. That is not a criticism of anyone's intentions. It is a structural weakness that payments already learned it could not tolerate, which is why certification exists at all.
Payments has a concept the AI vocabulary is still missing.
The word payments should contribute: Finality
In software, the default assumption is that mistakes can be rolled back. Bad deploy, revert. Bad output, regenerate. Bad answer, ask again. The whole eval discipline is shaped by that assumption: measure the failure rate, iterate, improve.
Payments does not get that. Settlement is final. Once funds have moved and been reconciled, particularly across a border, there is no revert. There is only a slower, more expensive, more adversarial process for trying to move them back, with rules written by someone else and a clock you do not control.
95% is a fine score for a system that drafts text. For a system that moves funds, the question is not how often it is right. It is what the 5% costs, whether any of it is unrecoverable, and how long it takes you to find out.
So here is the framing I would offer back to anyone building agents that transact. Evaluate along two axes, not one. Not just "was it correct?", but "If it was wrong, could we undo it". This is the direct operational consequence of everything in how an AI agent actually pays a merchant.
| Action | Eval intensity required | Reversible |
|---|---|---|
| Draft a message | Low | Fully |
| Send a message | Medium | Socially, no |
| Reserve or authorise funds | Medium-high | Within a window |
| Capture and settle a payment | Maximum | Practically not |
| Settle across a border | Maximum, plus an independent check | No |
What this means if you are building agents that touch money
Four things I would hold to, and they come from certification, not from AI.
- Someone other than the builder should grade it. Payments learned that self-certification does not survive contact with production. If your eval suite and your system were written by the same people, you have a strong opinion, not a test.
- Re-run on every change, including changes you did not make. Model providers update. Payments has run regression suites against every scheme mandate release for decades for exactly this reason: your system did not change, and it now behaves differently.
- Test the reconciliation, not just the decision. Being right in the moment and wrong in the ledger is still wrong. Most agent evals measure the decision and never check whether the record of it is consistent afterwards.
- Budget for the irreversible failure specifically. Not as an average. As its own line. The average is dominated by the recoverable cases and tells you nothing about the case that will actually hurt you.
A closing thought
Using a tool fluently is not the same as understanding it. That is true of everyone right now, and it is the reason this vocabulary matters more than it looks like it should.
For payments people, though, the gap is smaller than it looks. Most of this vocabulary describes machinery you already operate, under names you already use. What you are missing is the words, and words are cheap to acquire.
What the AI industry is missing from us is harder to acquire and more valuable: three decades of operational scar tissue about what happens when a probabilistic system is wrong about money and cannot take it back.
That exchange should run both ways. At the moment it mostly runs one.
