Why banks can't retrofit their way to programmable money

 Nik Milanović, founder of This Week in Fintech and Stablecon, pens today's guest column for the FR.

Everyone talks about stablecoins as digital dollars, a way to hold value on-chain without the volatility or make payments easily across borders.

That framing isn't wrong, but it undersells one of the most valuable features that makes stablecoins genuinely novel: their programmability.

Traditional money, the kind that lives in your bank account, is essentially read/write: you can send it and receive it. The logic governing how it moves lives somewhere else, in bank middleware, payment rails, and legal contracts that are slow, expensive, and opaque. Stablecoins collapse that separation. The money and the rules governing it can live in the same place: a smart contract.

What ‘programmable money’ actually means

When a developer deploys a stablecoin-based payment contract, in addition to routing value, they're encoding the conditions under which that value moves.

Consider a few concrete examples:

Streaming payments. Instead of paying a contractor in monthly lump sums, a contract can release funds continuously — per second, per block — based on work completed or time elapsed. Protocols like Superfluid have demonstrated this works at scale. Traditional ACH or wire infrastructure cannot do this without substantial custom engineering on top.

Solidity smart contract, showing how to view a contract’s balance

Conditional disbursements. A grant or escrow contract can hold funds and release them only when there is pre-defined confirmation that a condition is met: a delivery confirmed, a milestone reached, a vote passed. The contract is the escrow agent. There's no intermediary taking a cut for holding the keys and funds.

Composability. This is where stablecoins diverge most sharply from anything in traditional finance. A USDC balance sitting in a wallet can, with a single transaction, be deposited into a lending protocol, used as collateral, borrowed against, and routed into a yield strategy — all atomically, in one block. The equivalent in TradFi requires custodians, prime brokers, settlement windows, and legal agreements that take weeks to negotiate.

Traditional finance can't just ‘add programmability’

Banks aren't oblivious to this.

There have been years of investment in programmable money initiatives like JPMorgan's Onyx, central bank digital currency (CBDC) pilots, and various tokenized deposit experiments. The results have been instructive: it's genuinely hard to retrofit programmability onto systems built for a world where settlement finality takes days and identity is managed out-of-band.

The core problem is layering. In legacy payment systems, the value layer (the money itself) and the logic layer are separated by design. Adding programmability means building a translation layer between them — and every translation is a point of latency, failure, and cost. Stablecoins on smart contract platforms don't have this problem because they were built with the logic layer as a first-class citizen.

There's also the question of permissioning. A bank-issued programmable instrument will almost certainly require whitelists, KYC gates, and compliance hooks baked in at the protocol level. This isn't inherently bad. After all, it reflects regulatory reality, but it also constrains composability. You can't drop a permissioned token into an arbitrary decentralized protocol, or even one built by another bank, and expect it to work. Public stablecoins like USDC and USDT, despite their own compliance mechanisms, operate in a vastly more 

open environment.

Caveats

None of this comes without tradeoffs.

Smart contract bugs are a real attack surface. Programmability that enables legitimate logic can also enable exploits. The history of DeFi is littered with protocols that had sound economic logic but nuanced vulnerabilities that left them vulnerable to exploits.Audits help but don't eliminate risk.

There's also the oracle problem: contracts that depend on real-world conditions need reliable data feeds, and those feeds are themselves attack vectors. (Just look at what happened recently with the Polymarket Paris weather bet.) Conditional programmability is only as trustworthy as the data it conditions on.

And for most mainstream use cases, the UX overhead and difficulty of interacting with smart contracts still exceeds the benefits. Programmable stablecoins are powerful in the hands of developers building on top of them — but remain relatively inaccessible to non-native users.

Why this matters

The stablecoin narrative has been dominated by macro questions: are they a threat to monetary policy? Can they survive a bank run?

These are legitimate questions, but they distract from something more fundamental at the technical layer. Stablecoins are the first monetary instruments where the asset and the logic governing it are natively unified. That may look like a marginal improvement on wire transfers, but it is a different abstraction entirely. Developers who understand that are building infrastructure the traditional financial system will spend a decade trying to replicate.