> ## Content Index > Fetch the complete content index at: https://www.dailyferment.com/llms.txt > Use this file to discover other available public pages before exploring further. # The stablecoin number banks are sizing their build against is the wrong one - URL: https://www.dailyferment.com/stablecoin-volume-wrong-number-side-core/ - Published: 2026-09-19T17:13:33.000Z - Updated: 2026-09-19T20:35:37.000Z - Description: Strip the bots and self-transfers out of the $33 trillion and you get $10.2 trillion, of which under 1% is retail. The two numbers justify different systems, and neither is the real reason to build. - Author: Rana Bilal Zafar - Tags: Fintech, Engineering, #long-argument Banks are building stablecoin infrastructure this year, and most of the business cases I have seen quote the same figure to justify it. Stablecoins moved about $33 trillion in 2025, up 72% on the year before. It's a real number from a real source, Bloomberg reported it in January, and it is close to useless for deciding what to build. [Visa, working with Artemis, Allium Labs and Castle Island Ventures, publishes an adjusted version](https://visaonchainanalytics.com/transactions?ref=dailyferment.com) of the same measure. Strip out the trading bots, the exchange treasury rebalancing, the repeated smart-contract calls and the transfers between two addresses owned by the same entity, and the $33 trillion becomes about $10.2 trillion. Roughly 69% of the headline is a wallet talking to itself. Then keep going. Of that adjusted $10.2 trillion, around 36% is people moving money onto and off centralised exchanges. Retail payments, someone actually buying something, come to under 1%. The same volume, measured three ways Stablecoin transaction volume, 2025 Headline gross volume, the figure in most business cases $33T Visa adjusted: bots, self-transfers and exchange rebalancing removed $10.2T Retail payments, someone actually buying something under 1% of the adjusted figure Bloomberg for the gross figure. Adjusted methodology by Visa with Artemis, Allium Labs and Castle Island Ventures. The third bar is not a rendering error. That sliver is the payments use case the build is usually justified by. ## Two numbers, two different systems The obvious reading is that stablecoins are overhyped. That's not my reading, and I don't think it follows. The less obvious reading, and the one that costs money, is this: the headline number and the adjusted number point at completely different engineering. A system sized for $33 trillion of payment flow is a payments platform. A system sized for what is actually happening is something closer to a treasury and settlement tool with a payments path attached that almost nobody uses yet. Build the payments platform on the strength of the gross figure and you will have spent the budget in the wrong place. Not because the technology was wrong, but because you sized the thing against traffic that was mostly a bot rebalancing an exchange's own books. ## The real reason to build is not volume at all Here's what I think the actual case is, and it doesn't need a trillion-dollar number to stand up. A bank's core banking system reconciles on a schedule. There is a cutoff, the books close, a batch runs, and the next morning the numbers are true as of last night. That design isn't a limitation anyone regrets. It's the reason the system is auditable, and it has worked for decades because the things it reconciles also stop at night. A blockchain doesn't stop. There is no cutoff, no close, no end of day. Settlement finality arrives whenever it arrives, sometimes in seconds, sometimes after a reorg you have to handle. Chains have different confirmation semantics from each other, so the same nominal asset on two networks is two different reconciliation problems. Fees move. Bridges fail in ways that leave value in neither place for a while. None of that is a volume problem. All of it is a *time* problem. You have a system that believes in end of day, attached to an asset that has never heard of it. That is what a side core actually solves, and why the pattern is spreading: a layer that watches the chains continuously, holds its own view of state, and hands the legacy core a batch it can understand at the moment the core asks for one. The core keeps its cutoff. The chain keeps its clock. Something in the middle translates between two different ideas of when a thing is true. I have built in this area, so I will say plainly that the hard part is not the integration. Connecting to a chain is a solved problem with libraries. The hard part is deciding what your system claims is true at a moment when the chain has not finished deciding, and being able to explain that decision later to someone who was not there. ## Where I have seen exactly this shape before The thing that made me want to write this down is that I recognised the problem from a completely different room, and the crossing has been useful to me in both directions. Weekly status reporting is batch reconciliation of a continuous process. Delivery doesn't stop at Friday. Work is committed, blocked, unblocked, re-scoped and abandoned continuously across a week. Then there is a cutoff, someone closes the books, and a batch runs that produces a status. And the status is true in exactly the way a bank's overnight position is true: accurate as of the cutoff, and silent about everything that happened between cutoffs. The failure mode is identical too. A team can be genuinely stuck on Tuesday, unstuck itself on Thursday, and report green on Friday. Nothing in the report is a lie. The batch simply cannot represent a state that existed and resolved between two runs. And the thing everyone reaches for when this bites, which is a more detailed weekly report, is the equivalent of reconciling harder at the same cutoff. It doesn't help, because the problem was never the resolution of the snapshot. The version of this that travels beyond banking: when a continuous process is reported through a periodic snapshot, the snapshot cannot represent anything that begins and ends between two snapshots, and no amount of added detail in the snapshot recovers it. The only fix is a layer that observes continuously and produces the snapshot on demand, rather than a snapshot that defines what gets observed. In banking that layer has a name and a budget. In engineering management it usually doesn't, which is why the same problem keeps getting solved as a reporting-template question. What this changed for me practically: I stopped treating the weekly as the place where status is produced and started treating it as the place where a continuously maintained view gets read out. The difference sounds small and isn't. In the first version, nothing is true until Friday. In the second, Friday is just when someone asks. ## What this means if you are the one sizing the build Don't use the $33 trillion. Don't use the $10.2 trillion either without saying which one you mean and what got stripped out, because the two numbers justify different systems and quoting the wrong one to a board is how a project gets approved for the wrong reasons and judged against the wrong targets. Size the reconciliation layer against your own settlement semantics: how many chains, what finality assumptions, what you will tell an auditor happened during a reorg. Size the payments path against the under-1% figure and your own honest estimate of how fast it grows, which is a forecast and should be labelled as one. The build is still worth doing. It's just worth doing for the time problem rather than the volume problem, and those two framings produce different architectures, different budgets and different definitions of success. ## Marking my confidence **Established.** The $33 trillion 2025 figure and the 72% growth are as reported. [Visa's adjusted methodology](https://corporate.visa.com/en/sites/visa-perspectives/trends-insights/making-sense-of-stablecoins.html?ref=dailyferment.com), produced with Artemis, [Allium Labs](https://www.allium.so/blog/visa-x-allium-making-sense-of-stablecoins/?ref=dailyferment.com) and Castle Island Ventures, brings it to roughly $10.2 trillion, of which about 36% is centralised exchange deposits and withdrawals and under 1% is retail. The side core pattern and the reasons given for it are as described in the trade coverage. **Inferred.** That business cases are being built on the gross figure specifically. I have seen the gross figure quoted far more often than the adjusted one, which is not the same as proving it drove a budget decision. **Guess.** That the time problem, not the volume problem, will turn out to be where most of these programmes actually spend their engineering effort, and that this will be visible in about two years when the first wave gets rebuilt. That is a prediction and I will revisit it here. What would change my mind: a bank publishing a post-mortem showing the integration work dominated and the reconciliation semantics were straightforward, or a credible adjusted-volume methodology that lands much closer to the gross figure. ## Before you quote the number at anyone I made a version of this argument about [AEO results that turned out to be mostly platform growth](https://www.dailyferment.com/aeo-results-are-mostly-platform-growth/), and the shape is the same. Every headline number is measuring something. The question is never whether it's real, it's whether the thing it measures is the thing you are about to spend money against. And if you run a team rather than a treasury: your weekly status is a batch job. Ask yourself what it cannot see, and then ask whether the answer is a better report or a different layer.