Audio editionListen to this book7 chapters · 50 min
01
An AI-generated analysis of a payments foundation model, and a specification cited four times that no first-party material contains.
A research report crossed my desk describing a new payments foundation model. Among its specifications was a latency figure: the model delivers inference decisions within an ultra-low latency budget of 29 milliseconds. The figure appeared four times. Once in the prose. Once in a comparison table, against a conventional-pipeline baseline of 200 to 800 milliseconds. Twice more in the sections on serving infrastructure, where it was used to reason about what hardware such a budget would demand.
Each instance carried a superscript citation marker.
The number does not exist.
Not in the vendor’s product page, not in its engineering blog, not in the launch press release, not in the chief executive’s interview with a national newspaper.c-008 Those materials describe the model’s decision speed the way marketing describes speed: “decisions made in milliseconds” on the product page, “real time” and “instantly” everywhere else. None of them states a numeric latency figure of any kind. Two targeted searches turned up nothing further.
The 200-to-800-millisecond baseline it was measured against does not exist either.
I want to be careful about what I am accusing here, because the interesting part is not that someone lied. Nobody did. A language model produced a document about a real system, with real numbers in it, and somewhere in the generation a plausible latency landed in a slot that wanted one. The citation marker came along because the surrounding sentences had citation markers. The comparison table needed a left-hand column, so a range appeared. Everything downstream then treated it as a specification, including the paragraphs that reasoned about GPU requirements from it.
That is the failure worth understanding. Not fabrication as an act, but fabrication as a shape: a document that looks cited, reads as technical, and carries one load-bearing quantity that came from nowhere. The apparatus of rigor survives intact while the thing it is attached to evaporates.
I checked the number because a verification pass forced me to. Every factual sentence in this paper is bound to a passage in a source captured to disk, and a gate refuses to publish when a binding is missing. The 29 milliseconds had no binding available, which is a different experience from doubting it. I was not suspicious of the figure. I liked the figure. It was the most concrete thing in the document.
Why this opens a paper about architecture
Because the same document, on the strength of numbers assembled that way, made a recommendation: that payment infrastructure should consolidate its many task-specific models into a single shared transformer backbone. One model for routing, fraud, risk, and checkout personalization, learning jointly, serving every decision in the path.
That is not a small suggestion. It is a proposal to re-couple a system that an industry spent the better part of two decades learning to decouple, in the one place where failure is most expensive, on the authority of a document containing an invented specification.
The recommendation might still be right. Architecture is not decided by the provenance of the arguments made for it, and I will spend most of this paper taking the case seriously. But there is a burden-of-proof question underneath, and the 29 milliseconds is a useful way in, because it shows how little friction there now is between a claim about a system and a specification a reader will design against.
What the rest of this paper does
The next section sets out what was actually announced, separated from what was asserted about it. Then the argument proper: what decoupling was for, why a shared backbone in the payment path is a single point of failure by construction, and what the evidence does and does not settle.
The conclusion, stated here so you can disagree with it early: a domain foundation model is a strong supporting system and a poor primary one, and the distinction is not about model quality. It is about what you can reason about when it is three in the morning and the thing is wrong.
02
What the company put on the record, what it left out, and the disclosure bar its own peers already clear.
Razorpay, an Indian payments company, announced a transformer-based foundation model for payments called Vulcan. Stripped of the commentary that accreted around it within forty-eight hours, here is what the company itself put on the record.
The gains. Its product page states three: an 8–10% improvement in success rates, five times more disputed transactions identified, and eight times more international card fraud detected.c-001
The scale. Three trillion data points across four billion digital payments, attributed to the company’s chief executive in a newspaper interview.c-003 The training and inference hardware is reported as NVIDIA H100 GPUs with AWS supplying the cloud infrastructure.c-004
The deployments. Blinkit, redBus and Bachatt are named in the launch release.c-007
All of that is real, correctly quoted, and worth taking seriously. A company processing that volume has access to a signal nobody outside it has, and the architectural idea — that a shared representation of transaction behavior could serve routing and fraud and risk at once — is a genuinely good idea that several serious engineering organizations are pursuing.
What is missing is the method
There is no baseline. No measurement window. No control. No confidence interval. Not in the product page, not in the launch release, and not in the company’s own engineering blog, which contains no benchmark, holdout, test set, precision or recall figure at all.
This is not only my reading. Independent trade analysis reached it directly, noting that enterprises “still lack baselines, testing methodology, confidence intervals and independent validation needed for assessment,”c-005 and that the baseline for the 8–10% figure has not been released — leaving open what the improvement was measured against.c-006
Take the fraud figure, because it is the one that sounds most impressive. Eight times more international card fraud detected. Against what detection rate? Measured over what period? And — the question that decides whether the number means anything — at what false-positive rate?
A fraud model can always detect more fraud. Decline everything and you detect all of it. The only version of that claim which carries information is one that holds the false-positive rate fixed, and no published Razorpay material does.
The disclosure bar its peers clear
I originally wrote this section as a criticism of the category. That was wrong, and three sources corrected it.
Plaid, publishing on its own sequential foundation model, states results at named operating points: 26.5% more dollar value in returns prevented at a fixed 1% action rate, and default risk reduced 13.6% at a 70% approval rate.c-019 Both are vendor-published, exactly like Razorpay’s. The difference is the clause after the comma. An operating point is what makes a detection number readable, because it fixes the thing that could otherwise be traded away to manufacture the headline.
Stripe, writing first-hand about its own payments foundation model, names a baseline and a specific attack class rather than a bare multiplier: “our detection rate for attacks on large users significantly increased—from 59% to 97%”c-028 for card-testing attacks. Same kind of company, same kind of announcement, same commercial incentive. The difference is that a reader can tell what improved and from where.
A consultancy survey of the category reports its figures with a stated sample of 60 enterprise pilots, though it reports ceilings — “up to” — rather than typical results.c-020 And practitioners observe that firms in this space have been putting methods, and failures, on the public record.c-023
So the honest finding is narrower and harder than the one I first reached. Transactional foundation models are not inherently unverifiable. Razorpay’s disclosure sits below a bar its own peers already clear.c-024
Why launch coverage does not help
Something worth noticing about the trade articles that appeared alongside the announcement: they are one source. Each restates the same release. Counting them as corroboration is a category error, and NVIDIA and AWS — both named commercial partners in the launch — are participants rather than validators.
There is also a recency problem that cuts in Razorpay’s favor, and it should be said plainly. The model was announced days before this research. Nothing has had time to be independently verified. That is an absence of scrutiny, not evidence of failure, and if a merchant publishes its own before-and-after next quarter, much of this section becomes obsolete in the best way.
03
Service boundaries were not fashion. They were an answer to a question about what happens when one part of a system is wrong.
On my reading, the last fifteen years of payment engineering come down to one long argument about boundaries. Where to put them, what to pay for them, and what breaks when they are removed. The argument was not about elegance and it was not about fashion, though both were used as ammunition at various points. It was about a single question that every senior engineer eventually learns to ask before any other:
When this part is wrong, what else is wrong?
That question is the whole of it. Everything the industry built between the mid-2000s monolith and the service topologies of today — the circuit breakers, the timeouts, the bounded contexts, the separate deployment pipelines, the independent scaling groups, the per-service on-call rotations — is machinery for producing a narrow answer to it.
The pattern has a name
The name is the bulkhead. It is defined as a technique “for isolating parts of an application into pools or compartments so that failure of one component will not cascade to other components,”c-030 and the metaphor is naval: a ship’s hull is divided into watertight sections so that a breach floods one compartment rather than the vessel.
I should say where that definition comes from, because this paper opened by objecting to a citation that pointed at nothing. The pattern’s canonical source is Michael Nygard’s Release It!, published in 2007. I did not open that book. What I am citing is an encyclopedia’s account of the pattern the book introduced, which is a weaker citation than the book itself would be, and it is the one I actually have.
The definition is enough for the argument, because the argument turns on a single word in it: cascade. A bulkhead does not prevent failure. Nothing prevents failure. A bulkhead determines the extent of failure — it converts an unbounded event into a bounded one. The ship still has a hole in it. It is a hole in compartment four.
Blast radius is the entire argument
Once you see boundaries as blast-radius machinery, most of the microservices debate collapses into something considerably less interesting than it was made to sound.
Service decomposition was never primarily about development velocity, though that was the pitch on the conference circuit and it is what most organizations bought. Velocity is a second-order benefit and, for a large number of teams, it never arrived at all — distributed systems are harder to change than local ones, and a great many companies discovered this the expensive way. The durable benefit was narrower and less exciting: when the fraud scorer degrades, checkout still completes. When the routing optimizer starts returning nonsense, authorization still runs on a fallback path. When one model’s feature pipeline goes stale, the other three do not.
Call that a containment property rather than a performance one. It is the property that decides what three in the morning looks like.
A payment system is unusual in how sharply this matters. Most software fails softly: a page renders wrong, a report is late, a recommendation is poor. Payment infrastructure fails in money, in both directions, as fast as traffic arrives, and it fails while the merchant is watching a real-time dashboard of transactions not completing. The cost of a failure is not the failure. It is the failure multiplied by the minutes it takes to work out which component is wrong.
Boundaries are how you divide that multiplication down.
What a shared backbone does to the boundary
Now put the proposal from Section 1 against that.
One transformer, trained jointly, serving routing, fraud, risk and checkout personalization. Every decision in the payment path drawing on the same learned representation of transaction behavior. The efficiency case is real and I do not want to be cute about it: shared representation genuinely is more sample-efficient, genuinely does let a signal learned in fraud inform routing, and genuinely does cut the number of independently maintained feature pipelines from four to one.
The architectural cost is the exact thing the bulkhead was for. A shared backbone serving all four decisions removes the compartment boundary that separates them, which makes its failure a single point of failure by construction rather than by misconfiguration.c-031
The distinction between those two phrases is the reason this section exists.
A single point of failure by misconfiguration is a bug. Somebody put the replica in the same availability zone as the primary; somebody forgot the timeout; somebody scaled the group down to one. Bugs of that class get found, filed and fixed, and the architecture is unchanged afterward.
A single point of failure by construction is not a bug. It is the design working as intended. There is no configuration change that restores the compartment, because the compartment was traded away deliberately in exchange for the shared representation. You can add redundancy — more replicas of the same model, more regions, faster failover — and none of it touches the failure mode that matters here, which is not the model being down but the model being wrong.
Redundancy protects against a component that has stopped answering. It does nothing whatsoever against a component that is answering confidently and incorrectly across every decision it serves. Five replicas of a drifted model produce the same drifted answer five times, quickly.
The failure mode that has no page
Consider how each architecture behaves under a subtle degradation — not an outage, but a distribution shift that moves the model’s calibration.
In the decomposed system, the fraud model’s false-positive rate climbs. Somebody notices, because the fraud model has an owner, a dashboard, a precision metric and an alert threshold. The routing optimizer is unaffected, because it is a different model with different inputs. The blast radius is one decision type, one team, one rollback.
In the consolidated system, the shared representation shifts. Fraud gets worse. Routing gets worse. Risk gets worse. Checkout personalization gets worse. They get worse together, and correlated degradation across four unrelated metrics is precisely the signal monitoring is worst at attributing, because every downstream dashboard moves at once and none of them points at the cause. The first hypothesis in the incident channel will not be “the backbone drifted.” It will be “something is wrong with traffic,” and it will take a while.
Rollback is worse still. In the decomposed system you roll back one model and the other three keep their current versions. In the consolidated system, rolling back the backbone reverts every improvement every team shipped through it since the last known-good checkpoint. The unit of reversion has stopped being a change and become the whole brain.
The honest counter-case
There is a real argument on the other side and it deserves stating at full strength, because a paper that only argues one way is doing the same thing as the document that started this one.
Boundaries are not free, and their cost is also paid in incidents. A decomposed system has four feature pipelines that can independently go stale, four sets of training-serving skew, four deployment paths, and a coordination problem whenever a signal needs to cross a boundary. Distributed systems introduce failure modes that monoliths simply do not have: partial failure, network partitions, cascading timeouts, and the delightful class of bug where two services disagree about the state of the same transaction. Nobody who has operated one believes the boundaries are pure benefit.
And “four models” is not four bulkheads. In most real payment stacks those models already share a feature store, a streaming platform, an inference cluster and an identity graph. The compartment walls are thinner than the architecture diagram suggests. Consolidating the models may remove less isolation than this section implies, because a good deal of it was already gone.
I accept both points, and they narrow the claim rather than defeat it. Decomposition is not safe and consolidation is not dangerous; the narrower thing worth saying is that consolidation moves a specific, well-understood, containable class of failure into a class that is none of those things, and that this trade should be made deliberately, with the containment cost named, rather than as a side effect of adopting an architecture because it is the shape of the moment.
Which raises the obvious question, and it is what Section 4 is about: has anyone actually tried this?
04
A payments platform at comparable scale attempted the consolidation, published what broke, and intends to try again.
The argument in Section 3 is deduction. It reasons from what a boundary is to what removing one costs, and deduction is the weakest kind of evidence this paper deals in. So the honest next move is to go looking for somebody who actually attempted the consolidation in production and said what happened.
One did, and published it. The account is more useful than the argument, and it is more useful in a direction I did not expect.
What Adyen reported
Adyen — a payments platform serving card traffic in the same synchronous position this paper is about — has written publicly about the machine learning behind its authorization-optimization work. Buried in that write-up is a sentence that does more work than anything else in this corpus.
The company reports having “tried with bigger artifacts and complex deep learning models” that combine multiple decisions, and having found that these would often “compromise the engineering requirements (latency, uptime) of online deployments in a critical flow.”c-025
Read that slowly, because the specific words matter and I got them wrong the first time. I originally reached this through a practitioner’s summary, which rendered it as tried it, failed, kept trying. That rendering was directionally right and lost the part that decides the question.
What failed was not accuracy. Adyen does not report that the consolidated model predicted worse. It reports that the consolidated model compromised latency and uptime, and that this happened in a critical flow.
Those are the two axes on which payment infrastructure is actually judged, and “critical flow” is the precise scope condition. Nobody is arguing that a large shared model is a bad idea for a nightly batch scoring job or an offline merchant-risk review. The claim under examination is specifically about the synchronous path, where the transaction is waiting and the timeout is real, and that is exactly the scope in which a company operating in it reports the approach failing.
This is the closest thing in the entire corpus to a measurement of the Section 3 argument. It arrives from a first-party engineering write-up rather than a benchmark, which makes it a vendor source and imperfect evidence — but it is a vendor reporting a failure of its own preferred direction, which is the kind of vendor claim worth the most.
The half a selective reader would drop
Immediately alongside it, Adyen says something that cuts the other way, and this paper would forfeit its standing if it printed the first quote without the second.
The company states that it keeps investigating that line of thinking and is “expecting to move the whole pipeline to deep learning architectures in the short future.”c-026
So Adyen is not a witness against consolidation. Adyen is a witness that consolidation is operationally hard in a critical flow today, while intending to get there. The engineering constraint is real and current; the company treats it as a constraint to be engineered past, not a law.
Quoting only the first sentence would have made this section much stronger and much less true. It would also have been the same move Section 1 spent two pages criticizing: taking a real source and rendering it into the shape the argument wanted. The difference between a citation and an argument is that a citation still says what it says after you have finished needing it.
What they run instead
The third thing Adyen discloses is the one most useful to a team making this decision on Monday, and it is not a negative result at all. It is an architecture.
The system, as described, “consists of a collection of machine learning models of various natures that share awareness and knowledge,”c-027 optimized globally toward a shared objective rather than merged into a single model.
That sentence is worth more than the two before it. It describes a third option which the monolith-versus-microservices framing tends to hide, because that framing presents the choice as binary: one model that knows everything, or several models that know nothing about each other.
The middle position is shared objective, separate artifacts. The models are coordinated — they see each other’s signal, they optimize toward a common outcome rather than four locally optimal ones, they are trained with awareness of the whole — and they remain independently deployable, independently rollbackable, independently ownable, independently degradable. You get most of the joint-learning benefit that motivates a shared backbone. You keep the compartment.
It is a harder system to build than either extreme. It requires deciding what “awareness” means between models, keeping shared representations from silently drifting apart, and holding a global objective that four teams can each move toward without one team’s improvement showing up as another’s regression. Nobody should pretend this is the easy path. It is, however, the path the company that tried both ends of the spectrum currently operates.
Single point of failure, single point of intelligence
Put Sections 3 and 4 together and the shape of the objection sharpens.
The problem with a shared backbone in the payment path is not that transformers are unsuited to transaction data. The evidence on that question is genuinely thin in both directions, which Section 5 is about. The problem is a governance one wearing an architecture costume.
When one model serves routing, fraud, risk and checkout, four decisions with four different owners, four different regulatory exposures, four different tolerances for error and four different definitions of “wrong” all become one deployment.
Ask the ordinary operational questions of that arrangement and they stop having ordinary answers:
That last one is not rhetorical. A model jointly trained on fraud and conversion has a shared representation in which those objectives are entangled by design, and “entangled by design” is a difficult phrase to use in a compliance conversation.
None of these are model-quality problems. A better transformer does not fix any of them, because none of them are about the transformer being wrong. They are about what happens to accountability when four decisions stop being four things.
That is the case against putting it in the critical path. Section 5 asks the fairer question: what does the published evidence actually settle about whether it belongs there at all?
05
Every published benchmark in this literature stops five orders of magnitude short of where these systems run.
Here is the sentence this paper would most like to write, and cannot:
In a controlled comparison on production payment traffic, a consolidated transformer backbone serving routing, fraud, risk and checkout was measured against an equivalent set of task-specific models, and the result was X.
That study does not exist. Not in a form I could find, not from any of the companies building these systems, not in the academic literature, and not in the trade analysis that covers them. The most consequential architectural decision in this category has no published head-to-head measurement behind it, on either side.
I want to be precise about what kind of absence that is, because the distinction governs how much weight the rest of this paper can carry. There are three states that get mistaken for each other constantly:
The consolidated-versus-decomposed comparison is the third. Every company in a position to run it has run some version of it internally — you do not deploy one of these without an A/B test — and none of them has published the design. What reaches the outside is the outcome of the winning arm, stated as a product claim.
The literature that gets cited instead
When the case for a transformer backbone needs academic support, it reaches for the tabular deep learning literature, and this is where the argument quietly breaks.
The benchmark most often cited for the opposing position — that gradient-boosted trees still beat neural networks on structured data — scopes its own finding explicitly. It reports that “tree-based models remain state-of-the-art on medium-sized data (~10K samples).”c-009 Ten thousand samples. The parenthesis is the authors’ own, in their own abstract, and it is a scope condition rather than a hedge.
The system under discussion in this paper is trained on four billion payments and three trillion data points.c-003
That is a gap of roughly five to eight orders of magnitude depending on which quantity you compare, and it means the literature cited to justify a transformer backbone measures a data regime so far from the deployment regime that it neither supports nor refutes the payments architecture.c-016
This cuts both ways, and I should be explicit that it does not rescue my position either. The “trees beat neural nets on tabular data” result is the single most commonly deployed objection to models like these, and at four billion samples that result is out of scope. Anyone using it as an argument against a payments foundation model — and it gets used that way constantly — is citing a finding about ten thousand rows to dispute a system trained on four billion. My argument in Sections 3 and 4 has to stand on containment, not on accuracy, because the accuracy literature does not reach.
The other pillar has a similar problem. The leading tabular foundation model’s strong results were established largely in closed evaluation settings, and its authors state plainly that “the majority of this research remains confined to closed environments,” leaving its robustness in open ones an open question.c-010 A closed evaluation is a benchmark where the distribution is fixed and known. A payment network is the opposite of that by definition: adversaries adapt, merchants change mix, issuers change policy, and the distribution moves because someone is being paid to move it.
The one measured comparison, and why it is not about payments
There is exactly one study in this corpus that measures a monolithic architecture against a modular one on the same task. It is in network configuration repair, and it found that “agentic architectures outperform base LLMs in repair efficacy (by 12% on average) and safety (by 17% on average).”c-013
That result runs against the consolidation thesis: the decomposed, coordinated design beat the single-model baseline on both quality and safety. It is also, I must say clearly, a different class of system in a different domain, and I would not accept it as evidence if it pointed the other way.
I raise it for one reason. The source documents that started this inquiry cited the monolithic-versus-modular question as settled in favor of consolidation, resting that on an untraceable claim and on evidence drawn from a different class of system — while the one measured comparison actually present in the corpus found modular designs winning.c-018 The evidence on this question is genuinely mixed and thin. That is the finding. Anyone telling you the direction is established, in either direction, is telling you about their priors.
What the vendors have shown, which is not nothing
Set the academic literature aside, because the strongest evidence in this category is operational and comes from the companies themselves.
Stripe reports that after deploying its payments foundation model, “our detection rate for attacks on large users significantly increased—from 59% to 97%”c-028 for card-testing attacks. Plaid reports its sequential model “prevented 26.5% more dollar value in returns at a fixed 1% action rate.”c-019 A consultancy analysis of the category reports conversion uplift of up to 6% and an 86% reduction in manual risk rules across 60 enterprise pilots, though it reports ceilings rather than typical results.c-020
These are vendor-published and they are real. A jump from 59% to 97% on a named attack class, against a stated baseline, is a substantial result that no amount of architectural argument talks away. Something is working.
But notice what none of them measures. Every one is a capability result: the model detects more, prevents more, converts better. Not one is a containment result. None of them reports what happened when the model was wrong, how long attribution took, what the rollback cost, or how correlated the degradation was across the decisions it served.
That asymmetry is not a conspiracy. Capability results are what a launch post is for, and containment results are what a post-incident review is for, and companies publish the former far more readily than the latter. It does mean the public evidence base is structurally biased toward the case for consolidation, because the costs this paper is about are the costs that do not get written up.
What would settle it
The study is not hard to specify, which is part of why its absence is frustrating. Take production traffic. Serve one arm from a consolidated backbone and one from task-specific models with equivalent training data. Report:
The last three have never been published by anyone in this category. Until they are, the architectural argument is settled by whoever writes more confidently, which is how the document in Section 1 came to recommend re-coupling a payment system on the authority of a latency figure that did not exist.
06
A representation layer feeding specialists, and the five conditions that should gate anything moving into the path.
Everything so far has been an objection. Objections are cheap, and a paper that stops at one is asking an engineering organization to do nothing, which is never the right answer when a technology is this obviously useful.
So here is the position stated constructively.
A payments foundation model is a strong supporting system and a poor primary one — the position Section 1 stated up front, now with the reasoning behind it. What decides it is where in the path the artifact sits, and what still works when it is wrong.
That sentence needs unpacking into something a team can act on, because “supporting system” on its own is the kind of phrase everyone agrees with and nobody implements.
Three places it belongs, and one it does not
As a representation layer. This is the highest-value position and the one with the most evidence behind it. The model learns a compressed encoding of transaction behavior; downstream task-specific models consume that encoding as features and make the actual decisions.
Stripe describes exactly this shape. Its foundation model “compresses payments into atomic embeddings, which we then leverage across multiple card testing use cases, such as training classifiers on sequences of embeddings.”c-029 The foundation model produces representations. Classifiers, plural, consume them and decide.
I want to flag a correction here rather than bury it, because I made the error this paper exists to catch. I had originally written that Stripe positions its model as “an addition, not a replacement” — a clean, quotable phrase that fit the argument perfectly. It is not Stripe’s phrase. The word replace does not appear in either of Stripe’s primary write-ups; the phrasing came from a practitioner’s summary of them, and I repeated it as though it were the company’s own. What the primary sources support is narrower and, as it turns out, architecturally stronger: not a positioning statement about what the model is not, but a description of what it actually is — a representation layer feeding specialists.
The containment properties follow directly. Each classifier keeps its own owner, threshold, deployment and rollback. If the embeddings drift, the classifiers can be retrained or pinned to a previous embedding version independently. The compartment survives, because the shared thing produces inputs rather than verdicts.
As a coordinated peer. The Adyen shape from Section 4: “a collection of machine learning models of various natures that share awareness and knowledge,”c-027 optimized toward a global objective. Harder to build, and it preserves the property that matters — separate artifacts, separate deployment, shared purpose.
Out of the synchronous path entirely. A large amount of what these models are genuinely best at does not need to answer while a transaction waits: post-hoc fraud review, chargeback prediction, merchant risk scoring, dispute triage, reconciliation anomaly detection, batch retry strategy. In asynchronous positions the latency and uptime constraints Adyen ran intoc-025 stop binding, and a wrong answer is caught by a human or a later pass rather than by a declined transaction.
Where it does not belong is the position the source document recommended: sole authority over routing, fraud, risk and checkout in the synchronous path, with no independent fallback for any of them.
Promotion criteria
A supporting system can earn its way into the critical path. It should have to, and the bar should be written down before the model is built rather than negotiated afterwards by whoever is most enthusiastic.
Five conditions. I would not promote without all five, and the third is the one almost nobody has.
1. A fallback that is exercised, not documented. Every decision the model serves must have a rules-based or simpler-model path that produces an acceptable, if worse, answer. The fallback must run in production regularly — a percentage of live traffic, continuously — because an untested fallback is a comment in a runbook and will not work on the night it is needed. This is what makes the failure containable rather than catastrophic.
2. Per-decision observability, not per-model. The model’s health must be measurable separately for each decision it serves: fraud precision, routing success, risk calibration, conversion. Aggregate model metrics are useless here, because the failure mode of a shared backbone is one decision degrading while the average holds.
3. A measured mean time to attribution. Induce a degradation in a staging environment carrying replayed production traffic. Measure how long it takes the on-call rotation to identify the shared backbone as the cause. If that number is unknown, the organization does not know what an incident costs and is not ready to take the trade. This is the number Section 5 asked for and nobody publishes.
4. Independent rollback. It must be possible to revert one decision path to its previous behavior without reverting the others. In practice this usually means versioned embeddings with pinning, since rolling back the backbone itself cannot be made granular.
5. Regional and segment validation before scale. A model trained predominantly on one market’s behavior can skew where regional payment behavior is under-represented, producing both false positives and negatives.c-012 Cross-border and long-tail segments need their own operating-point measurements before the model governs them, not after.
Why the burden of proof runs this way
There is a fair objection to all of the above: it is conservative, it is expensive, and taken literally it would have blocked most of the good infrastructure of the last decade.
The response is about asymmetry of consequence, and it is the reason this paper does not generalize beyond its domain.
If a payments foundation model is deployed as a supporting system and turns out to be excellent, the cost is a slower rollout and some duplicated inference spend. The organization arrives at the same place, later, having spent more.
If it is deployed as the primary decision-maker and turns out to be subtly wrong, the cost is money moving incorrectly, as fast as traffic arrives, across four decision types simultaneously, with attribution slowed by the very correlation that made the architecture attractive.
Those two errors are not the same size, and where the errors are not the same size, the burden of proof belongs on the side with the larger one. That is not conservatism about machine learning. It is the ordinary standard for infrastructure where failure is expensive, and it is the standard this industry already applies to databases, ledgers, and settlement systems without anyone finding it controversial.
The model is not the problem. The model is good. The question is only whether it is load-bearing, and load-bearing is a decision about the building rather than about the material.
07
The evidence that would change this position, named in advance.
A position that cannot be dislodged by evidence is not a position but a preference. So this section names, in advance, what would move mine — written before anyone gets the chance to produce it, which is the only time such a list is worth anything.
Five things that would change the conclusion
A published attribution measurement. If any company operating a consolidated backbone in the payment path published mean time to attribution during induced degradation, and it were comparable to a decomposed system’s, the containment argument in Sections 3 and 4 would be substantially weakened. This is the single piece of evidence that matters most, and its absence is the load-bearing gap in the whole category. I would rather have this than any accuracy result.
A production A/B on architecture rather than capability. Consolidated backbone against task-specific models, same traffic, same training data, decision quality reported at fixed operating points, plus latency at p99 and correlated-error rate across decision types. If consolidation won on quality and held on containment, Section 6’s promotion criteria would be the right process arriving at the opposite answer, and I would accept that.
Adyen’s stated plan working. Adyen says it expects “to move the whole pipeline to deep learning architectures in the short future.”c-026 If that happens and the company reports the latency and uptime constraints resolved in a critical flow, the strongest piece of empirical evidence in this paper turns into evidence for the other side. I have written this paper knowing that the company whose failed attempt anchors my argument intends to try again, and I would consider their success a more informative result than my reasoning.
Regulatory clarity that entangled objectives are acceptable. A good deal of Section 4’s governance objection assumes that jointly optimizing fraud and conversion in one representation creates an explainability problem for a declined transaction. If supervisors examined this arrangement and found it adequate for adverse-action reasoning, the accountability half of my objection loses most of its force, leaving only the operational half.
Cheap, granular rollback. If versioned representations with per-decision pinning become standard tooling rather than bespoke engineering, the “unit of reversion is the whole brain” problem stops being structural and becomes a solved one. Much of Section 3 is contingent on rollback being coarse. It does not have to stay that way.
What would not change it
Symmetrically, and more importantly: better headline numbers would not change it.
Another vendor reporting another multiplier — more fraud caught, more conversion, higher detection — is evidence about capability, and this paper has not disputed capability once. Stripe’s move from 59% to 97% on a named attack classc-028 is a genuinely strong result and it is compatible with every word of my argument, because the argument was never that the model predicts badly. A capability result cannot answer a containment question, and the accumulation of capability results does not eventually add up to one.
Nor would an appeal to inevitability. “Everything consolidates eventually” is a prediction, not a measurement, and it has been right about some layers of the stack and wrong about others.
The disclosure point, restated as a request
The finding this research changed its mind on partway through deserves to be the last substantive thing said, because it is the most actionable.
I began by treating unverifiability as a property of the category — that transactional foundation models are inherently unmeasurable from outside. Three sources corrected that. Plaid states results at fixed operating points, naming the action rate and the approval rate its numbers hold at.c-019 Stripe names a baseline and a specific attack class.c-028 Adyen published an approach that did not work. Practitioners observe that companies in this space “are putting their methods, and even their failures, on the public record.”c-023
So the honest, narrower finding is that Razorpay’s disclosure sits below a bar its own peers already clear.c-024 That is a fixable problem, and fixing it costs nothing but a clause.
An 8–10% success-rate improvement, measured against what baseline, over what window. Eight times more international card fraud detected, at what false-positive rate. Five times more disputes identified, on what merchant segment. Each of those is one subordinate clause away from being a number a reader can use, and the company has the data, because you cannot claim the multiplier without it.
And the recency defense granted in Section 2 still stands: none of this has had time to be checked by anyone, and one merchant publishing its own before-and-after would retire most of that section.
Back to the number
Which returns us to the 29 milliseconds.
It was never the important thing. It was a symptom, and the disease is that the distance between a claim about a system and a specification a competent reader will design against has collapsed to nearly nothing. A document can now be generated that is fluent, technical, cited in appearance, internally consistent, and load-bearing on a quantity that came from nowhere — and the parts of it that are true make the invented part harder to see, not easier.
The defense is not skepticism, which does not scale and which I did not have – Section 1 is the record of me admiring that number, not doubting it. The defense is mechanical: a rule that a claim without a locator in a captured source does not get made, applied by something that does not care how good the sentence sounds.
This paper was written under that rule. It has thirty-one claims in its ledger; one of them failed verification and is therefore cited nowhere in these pages, which is the system working rather than a defect in it. Two claims I originally wrote were withdrawn and replaced when I found the primary sources and discovered that the secondhand renderings had improved on them.
That is what verification actually feels like from the inside. Not catching a liar. Catching yourself, holding a number you liked, that turned out to have no source.
The architectural argument may be wrong. The containment reasoning in Section 3 is deduction, its central claim is marked low confidence in the ledger for that reason, and Section 5 is an admission that the measurement which would settle the question has never been published by anyone. If someone runs that study and it goes the other way, this paper was a well-sourced argument for the wrong conclusion.
But it will have been checkable, and the thing it argued against was not.
Anuj Sadani builds AI systems and the teams that build them. He spent a decade at NVIDIA, has worked inside AI-first organizations, and has led multicultural engineering pods across Europe — sixteen-plus years, most of them on the AI era's unglamorous half: turning hype into systems that ship, and systems that ship into outcomes that hold up in production. That work has fed into industry recognition from Gartner and Everest Group, and an Innovator of the Year nod.
He is the author of The Clean Vibe Coder: A Code of Conduct for Programmers in the Age of AI Agents and Borrow the Line. Own the Move., and writes about engineering, leadership, and what stays human when the tools get good. He still believes the best technology is the kind that makes the people around it braver.
anujsadani.in
tech.anujsadani.in