Banks Going On-Chain Doesn't Mean Going Open

The Rails Are Changing. The Walls Aren't.

A CFO asked me last week whether JPMorgan was "going crypto."

I understood the question. The bank just put a deposit token live on Base — a public blockchain built by Coinbase. Citi's building its own chain. BNY Mellon's right behind them. If you're a finance leader trying to make sense of the headlines, it looks like the dam finally broke.

But buried in that question was an assumption that's causing more confusion than clarity: on-chain means open.

It doesn't. And understanding the difference isn't semantic hair-splitting — it's the line between strategic insight and expensive miscalculation.

What JPMorgan Actually Shipped

JPMorgan didn't ship "crypto" in the way most people understand the term. They shipped regulated dollars moving on blockchain rails with identity verification, sanctions screening, and AML controls fully intact. Programmable money inside a fence the regulators already approved.

JPMorgan didn't join the revolution — they made the revolution fill out a KYC form.

The technology changed. The compliance perimeter didn't budge. This isn't a bank walking away from gatekeeping — it's a bank discovering that blockchain infrastructure solves real operational problems (atomic settlement, programmable liquidity, 24/7 availability) without requiring them to abandon the regulatory frameworks that define their existence.

I've watched three clients in the past year wrestle with this exact confusion. They read "blockchain" and hear "decentralized" and start planning for a world where intermediaries disappear. Then they hit the actual implementation details and discover that permissioned chains look a lot more like upgraded databases than revolutionary new paradigms.

The Intranet Parallel Nobody's Talking About

We've seen this movie before. It was called the intranet.

In the mid-1990s, companies discovered they could run on the internet's plumbing — TCP/IP, HTTP, all of it — inside their own walls. Same technical rails. Private network. The IT department got all the efficiency gains of standardized protocols without exposing anything sensitive to the open web.

For years, "internet technology" and "internet access" were completely different conversations. One was about infrastructure. The other was about trust boundaries.

Banks are running the exact same play today with blockchain. Tokenized deposits aren't banks becoming DeFi — they're DeFi's rails getting a bank's rulebook bolted on top. The plumbing changed. The walls stayed up.

And just like the intranet era, this isn't a temporary hedge. Companies ran private IP networks for years before they trusted the public internet with anything that mattered. Some still do. The question was never "will we use these protocols?" — it was "where do we put the firewall?"

Two Strategies Hiding Inside One Word

Here's the uncomfortable part: when someone tells you a financial institution went "on-chain," you have no idea what they actually mean until you ask the second question.

On-chain and open? Or on-chain and walled?

Those are opposite strategies. One is about joining a permissionless network where anyone can participate. The other is about adopting new infrastructure inside existing control structures. For a regulated institution, the difference isn't philosophical — it's existential.

Open blockchains optimize for censorship resistance and permissionless access. Every design choice flows from that. Permissioned chains optimize for compliance, throughput, and deterministic finality. They're not better or worse — they're solving completely different problems.

I was on a call last month with a CPA firm evaluating "blockchain solutions" for a manufacturing client. Half the team thought they were talking about supply chain transparency on a public ledger anyone could audit. The other half thought they were talking about a private consortium database with cryptographic receipts. Same word. Incompatible mental models. The meeting went nowhere until we drew the distinction explicitly.

What This Means for Your Monday Morning

If you're advising clients on digital asset strategy — or building one for your own firm — the "are we going on-chain?" question is the wrong starting point.

Start here instead:

What problems are we solving, and what control structures can't we compromise? If the answer involves regulatory reporting, customer identity, or transaction reversibility, you're almost certainly talking about permissioned infrastructure. That's not a limitation — it's a design requirement.

Who needs to participate, and what do they need permission to do? A three-bank settlement network has different trust requirements than a global supply chain with hundreds of participants. The rails might look similar. The governance models are night and day different.

What's our actual risk if this data becomes public? Some transparency is a feature. Some is a breach. Be specific about which category your use case falls into before you pick your architecture.

The uncomfortable truth: most enterprise blockchain projects aren't preparing for a permissionless future. They're discovering that distributed ledger technology solves coordination problems between known parties more elegantly than the systems we built in the 1970s.

That's not hype. That's not revolution. That's just better plumbing with a more confusing vocabulary.

The Line Your Firm Needs to Draw

I've watched four complete technology disruption cycles in my career. The pattern that repeats isn't "new technology replaces old institutions." It's "new technology gets absorbed by old institutions faster than anyone expects, in ways that preserve more of the status quo than the revolutionaries predicted."

Nobody gets fired the day the railroad arrives. The town just slowly empties out — or it doesn't, because the railroad company decided the economics worked better running through somewhere else.

JPMorgan's deposit token isn't the beginning of banks disappearing into DeFi. It's evidence that the rails are genuinely changing while the control structures adapt and persist. Some walls will come down. Most will just get relocated.

Where's your firm drawing that line?

Not "are we exploring blockchain?" — everyone's exploring blockchain. The question that matters: are you clear about which problems require open rails and which ones require walls? Because the technology can do both. Your regulatory environment, your risk appetite, and your client relationships will tell you which one you actually need.

Here's what to ask your team Monday morning: "When we say 'blockchain,' are we talking about the same architecture?" Make them draw the trust boundaries. Make them name who can see what, who can participate, and who has override authority when something breaks.

The rails are changing. Make sure you know where the walls are.

---

What's your firm's actual use case — efficiency inside existing trust boundaries, or participation in new ones? The answer determines everything that follows.