Programmable Money Without Governance Is Just Programmable Risk

Why the hardest part of tokenization isn't the technology, it's everything around it.

Apr 05, 2026

JPMorgan’s Kinexys platform has processed over $2 trillion in notional value, averaging more than $3 billion in daily transactions. BNY is mapping its entire post-trade infrastructure for tokenization. The OCC has issued a string of interpretive letters clarifying that national banks can custody digital assets, hold crypto for gas fees, and engage in riskless principal transactions, all without prior supervisory approval. The vocabulary is becoming more familiar, the pilot programs are stacking up, and the message from regulators and market leaders is increasingly clear: the technology works, the legal framework is forming, and it’s time to move.

I think that’s right. But I also think there’s a conversation that’s probably not happening loudly enough, and it’s the one that matters most for banks entering this space: governance.

Not governance in the abstract sense, not “we need another committee.” Governance in the operational sense: who controls the logic that moves money? Who can change it? What happens when it breaks? What does “it broke” even mean when the code executed exactly as written, but the outcome wasn’t what anyone intended?

In my experience, when banks get this wrong, it’s not the technology that fails. It’s the governance around the technology.

When policy lives in code

I don’t think the industry has fully internalized the shift that programmable money introduces.

In traditional banking, policy lives in documents. A lending policy says “don’t extend credit beyond X.” A treasury policy says “maintain liquidity reserves of Y.” A compliance policy says “file a SAR when you see Z.” Humans interpret these policies, apply judgment, and execute decisions. The gap between policy and execution is filled by people.

In a programmable system, policy lives in code. A smart contract doesn’t interpret a lending threshold, it enforces it. A tokenized deposit doesn’t wait for a treasury desk to assess liquidity, the redemption logic is baked into the contract. A compliance rule embedded in a token’s transfer function doesn’t require a human to flag a suspicious transaction, it either permits the transfer or it doesn’t.

This is powerful. It removes human error, compresses execution time, and creates an auditable record of every action. Of course, that’s the upside everyone talks about.

The downside is that the code becomes the single point of truth. If the logic is wrong, the system doesn’t produce a memo flagging the error for senior review. It executes the wrong thing, immediately, at scale, with finality.

Funny thing is that this isn’t hypothetical. The crypto ecosystem has spent the last five years producing an extraordinary, and extraordinarily expensive, dataset on what happens when programmable logic operates without adequate governance.

The $3.4 billion dataset

In 2025, crypto hacks and exploits resulted in over $3.4 billion in losses, according to Chainalysis, slightly above the $3.3 billion lost in 2024. A single incident, the Bybit breach in February 2025, accounted for $1.5 billion of that total. The FBI attributed it to North Korea’s Lazarus Group. They didn’t exploit a smart contract vulnerability in the traditional sense. They compromised the transaction approval process, the governance layer, by injecting malicious code into the signing interface of Safe{Wallet}, a widely used multi-signature wallet. The signers saw one thing on their screens. The contract executed another.

Multi-sig wallets exist specifically as a governance control, requiring multiple independent approvals before funds move. The technology worked exactly as designed. The governance around it, how signers verified what they were approving, failed completely. $1.5 billion moved in a single transaction because the human verification process was compromised while the cryptographic verification process was technically sound.

The Bybit hack is the most dramatic example, but it’s far from the only one. Halborn’s Top 100 DeFi Hacks report found that off-chain attacks, meaning compromised accounts, phished credentials, manipulated interfaces, accounted for 80.5% of stolen funds in 2024. Only 19% of hacked protocols used multi-sig wallets. Just 2.4% employed cold storage. The technology to prevent these losses existed, the governance to deploy and maintain it didn’t.

Across DeFi, access control vulnerabilities, not exotic cryptographic flaws but basic permission errors, accounted for $953 million in losses in 2024 alone, making them the number one cause of smart contract exploitation for the second consecutive year according to OWASP’s Smart Contract Top 10.

Access control. Permissions. Who can call which function. This is governance 101, and the programmable money ecosystem is still getting it wrong.

Why audits aren’t enough

The natural response from a bank risk officer hearing these numbers is no doubt “We’ll audit the smart contracts.” Fair enough. But the data on audits is also sobering.

Smart contract audits grew by over 40% in 2025, driven by regulatory pressure and institutional adoption. Yet audited protocols continue to be exploited. Euler Finance was reviewed by six different security firms, including Certora, Halborn, Solidified, ZK Labs, Sherlock, and Omniscia, before a $197 million flash loan exploit in March 2023. Sherlock, one of the auditors, acknowledged responsibility for missing the vulnerability and paid a $4.5 million claim. Ronin Bridge was exploited in August 2024, its second major breach, because a contract was deployed without the latest audit-recommended initialisation, leaving a critical parameter set to zero. The first Ronin breach, in 2022, cost $600 million.

The gap isn’t in the quality of audits, it’s in what audits cover. A smart contract audit reviews code correctness, so does this function do what it’s supposed to? What it doesn’t typically assess is business logic risk, operational process, governance over upgrades, or the interaction between the contract and everything around it. Euler’s auditors reviewed the code. The exploit targeted a business logic flaw that only manifested through a specific sequence of flash loan transactions that the auditors hadn’t modelled.

This is the equivalent of a bank conducting a thorough credit risk review of a loan portfolio while ignoring the operational risk of how loans are originated and serviced. The analysis is rigorous within its scope. The scope is too narrow.

For banks entering the programmable money space, the lesson isn’t “don’t trust audits.” It’s that audits are a necessary component of a governance framework, not a substitute for one. The OCC’s July 2025 joint statement with the Fed and FDIC on crypto-asset safekeeping makes this explicit: banks must demonstrate “effective governance and subject-matter expertise across all levels of the enterprise.” That’s not a line item on an audit report. That’s an organizational capability.

You can’t patch what’s immutable

Smart contracts on public blockchains are, by default, immutable. Once deployed, the code can’t be changed. This is a feature for trust, and a disaster for operational management. Banks can’t operate with code they can’t fix.

So most institutional implementations use upgradeable proxy patterns, where the contract’s logic can be swapped out by an authorized party. This solves one problem and creates another: who authorizes upgrades? What’s the testing and approval process? What happens if an upgrade introduces a new vulnerability?

The Ronin Bridge exploit happened precisely because an upgrade was deployed without proper initialization. The upgrade mechanism, the governance mechanism, was the attack surface. Same technology, different context, catastrophic outcome.

When the data feed lies, the contract doesn’t care

Many smart contracts depend on external data feeds: asset prices, interest rates, reference data, all provided by oracles. If the oracle delivers bad data, the contract executes faithfully on wrong information. Oracle manipulation caused $52 million in losses across 37 incidents in 2024, and attacks surged 31% year over year.

For a bank running tokenized repo or automated collateral management, an oracle failure isn’t an IT incident. It’s a potential balance sheet event. Who selects the oracles? What’s the fallback if a feed fails? How do you reconcile a smart contract’s on-chain state with your offchain books when the oracle data was wrong for 45 minutes?

Traditional settlement systems have reconciliation breaks all the time, and there are entire teams dedicated to resolving them. Programmable settlement with atomic finality doesn’t give you the same grace period.

The cascading failure nobody modeled

The FSB flagged this one most explicitly in its October 2024 report on tokenization risks. Programmability and composability, the ability for one smart contract to interact with another,

“may lead to unintended systemic interconnections and create opaque interdependencies that could affect financial stability.”

Your contract talks to another contract, which talks to another contract, and a failure three layers down cascades back to you in ways nobody modelled. Cross-chain bridges, which connect different blockchains, account for 40% of all Web3 hacks and over $2.8 billion in cumulative losses, precisely because they create complex interdependencies across systems with different security assumptions.

The FSB put it directly: roles that traditional finance separates, issuance, custody, secondary trading, can be “blurred and intermingled in tokenized systems.” That blurring is a governance gap.

Who actually controls the protocol?

In DeFi, protocol governance is typically managed through token holder voting. In July 2024, a group called the Golden Boys pushed through a Compound DAO proposal directing $24 million in COMP tokens to a vault they controlled. The proposal passed 682,191 to 633,636, with voter turnout of just 4–5% of total token supply. In April 2025, a GreenField DAO attacker flash borrowed 9 million governance tokens, passed a malicious proposal, and drained $31 million from the treasury in a single block.

Banks obviously won’t be running DAOs. But they will be participating in multi-party tokenized platforms, shared ledgers, consortium networks, industry utilities, where governance decisions about protocol rules, upgrade schedules, and risk parameters affect every participant. Who votes? How are changes approved? What’s the dispute resolution process when a smart contract executes correctly but produces an outcome one party considers unfair? The technology doesn’t answer these questions.

Banks have the muscle. They haven’t pointed it at the right problems yet.

Banks are actually very good at governance. Operational risk management, three lines of defence, model risk governance, vendor risk management, business continuity planning. These are mature disciplines. The Basel framework, the OCC’s supervisory expectations, the UK’s operational resilience regime. The scaffolding exists.

In December 2025, the Basel Committee published its Principles for the Sound Management of Third Party Risk, explicitly addressing the growing dependence on technology vendors and fintech firms. The framework covers the full lifecycle of third-party arrangements: rigorous governance by the board and senior management, maintenance of a comprehensive risk management framework aligned with operational risk and resilience standards, and heightened expectations for critical services. The EU’s Digital Operational Resilience Act, DORA, went live in January 2025, requiring documented ICT risk frameworks, incident reporting within hours, regular resilience testing, and formal oversight of technology vendors.

These frameworks weren’t designed for programmable money. But the principles translate directly. The problem is that most banks haven’t yet mapped them onto the specific risks that smart contracts and tokenized systems introduce.

There’s a historical parallel worth considering. When banks started trading derivatives in the 1980s and 1990s, they didn’t have governance frameworks for the instruments. They had governance frameworks for risk. The work was in the mapping: applying what they knew about counterparty exposure, netting, and portfolio risk to a new instrument class. The same thing happened with algorithmic trading, and again with cloud migration. The governance wasn’t built from scratch. It was translated.

Programmable money is the same kind of translation problem. But the speed makes it harder. Consider the CrowdStrike outage in July 2024. A single content-configuration update from a cybersecurity vendor disabled 8.5 million Windows systems worldwide, including bank payment platforms and ATM networks. The root cause wasn’t a sophisticated attack, it was a failed quality-assurance process at a critical third-party vendor. The OCC subsequently found that half of the largest US banks lack a strong grasp of operational risks.

Now imagine that kind of concentration risk in programmable money infrastructure. A shared smart contract library used by multiple tokenized deposit systems. An oracle provider feeding data to every bank’s automated collateral management. A blockchain network where a consensus failure halts settlement for all participants simultaneously. The operational risk isn’t new in kind, it’s new in speed and scope. When code executes in milliseconds and settlement is atomic, the window between “something went wrong” and “irreversible loss” is essentially zero.

What running this safely actually takes

I don’t think the answer can be to slow down. I’ve written before about how the settlement friction subsidy that funds cheap deposits is eroding whether banks participate or not. But I do think the industry needs to be more honest about what safe adoption requires.

Smart contract risk needs its own governance framework, separate from but integrated with existing operational risk. It needs to cover code development, testing, audit, deployment, upgrade authority, monitoring, and incident response. The Basel Committee’s third-party risk principles provide a starting point, but smart contracts aren’t just third-party services. They’re automated decision-making systems that execute with finality. I’m increasingly convinced that model risk management, specifically the Fed’s SR 11-7 guidance, is a closer analogue than traditional vendor risk. A smart contract is, functionally, a model: it takes inputs, applies logic, and produces outputs that drive financial outcomes. It should be governed accordingly.

Resilience testing needs to include smart contract failure scenarios. Not just “what if the blockchain goes down,” which is the easy scenario. What if an oracle feeds stale data for an hour? What if a token’s transfer function blocks a legitimate transaction? What if a contract upgrade introduces an unintended interaction with another contract in the same ecosystem? DORA already requires threat-led penetration testing for critical systems. Programmable money systems should be held to the same standard, and the scenarios need to be designed by people who understand both the technology and the business logic it’s encoding.

The industry needs shared standards for governance of multi-party tokenised platforms. When banks join consortium networks, and they will because the economics of shared infrastructure are compelling, they need frameworks that address upgrade authority, dispute resolution, liability allocation, and incident coordination. This is a legal and operational design problem, and it needs to be solved before the platforms scale, not after.

And banks need people who can work across both domains. People who can read a Solidity contract and a Basel III capital requirement and understand how they interact. This talent barely exists today, and it’s the tightest constraint on safe adoption.

Banks are moving anyway

This is genuinely, structurally hard. The governance frameworks banks have built over decades, battle tested through financial crises, refined across three lines of defence, don’t map cleanly onto smart contracts and tokenized systems. Nobody has a complete answer. Not the regulators, not the consultants, not the technology vendors.

But banks are moving anyway. I think that matters more than having the perfect framework.

JPMorgan’s Kinexys has processed over $2 trillion in notional value on a permissioned network with centralised governance, controlling the participants, the upgrade process, who can call which function. That’s not a shortcut. It’s a legitimate design choice that manages risk by limiting scope, and it’s proving the economics work at scale.

Citi moved its tokenized cash service from pilot to live production in late 2024, processing multimillion dollar transactions for institutional clients across US dollars, euros, sterling, and Singapore and Hong Kong dollars. HSBC is already running tokenized deposits in Singapore, Hong Kong, the UK and Luxembourg, with US and UAE rollouts planned for the first half of 2026. BNY launched a tokenized deposit service in early 2026, with Baillie Gifford, Circle, Citadel Securities, Galaxy, Ripple, Invesco and WisdomTree among the early participants. Goldman Sachs built a tokenization platform, partnered with BNY to enable the first tokenized MMF subscriptions in the US, and is now spinning the platform out as an independent entity so it can scale across the industry.

And it’s not just the G-SIBs. In March 2025, Custodia Bank and Vantage Bank issued America’s first bank-issued stablecoin on a permissionless blockchain, Ethereum mainnet, using ERC-20 tokens backed by tokenized demand deposits. They walked through the full lifecycle: mint, transfer into self-custody, business to business transaction outside the banking system, transfer back, redemption into dollars. They did it while complying with BSA/AML/OFAC requirements, which meant building documentation, policies and procedures from scratch. Nobody had done it before.

Five regional banks, KeyBank, Huntington, First Horizon, M&T, and Old National, have joined the Cari Network to move tokenized deposits on ZKsync infrastructure anchored to Ethereum, with a pilot rollout planned for Q3 2026. The Independent Bankers Association of Texas launched a consortium of community banks building a shared tokenized deposit network. The Texas Bankers Association is offering pilot access to member banks through its Innovation Magnet programme. U.S. Bank created an entirely new organisational unit, Digital Assets and Money Movement, to build stablecoin issuance, crypto custody, and tokenization capabilities.

Meanwhile, infrastructure providers like Stablecore are pre-integrating digital asset rails into existing core banking platforms, so community banks can launch stablecoin payments and tokenized deposits without internal engineering teams. TruStage, the financial services arm of the credit union movement, announced a fully reserved stablecoin for credit unions, with a pilot launch in the first half of 2026.

None of these institutions waited for perfect governance. They started with what they could control, permissioned networks, known counterparties, existing regulatory relationships, and began building the operational muscle for programmable money in a contained environment. Kinexys didn’t launch with public-chain composability risk. Custodia didn’t try to solve oracle dependency in its first transaction. Cari Network chose a private Layer 2 anchored to Ethereum, not raw mainnet deployment. Each of these is a deliberate design choice that scopes the governance problem to something manageable.

The harder question, and I think this is the one that’s going to define the next few years, is what happens as the ecosystem moves further onto public infrastructure. The tokenized Treasury market, the instant redemption MMFs, the stablecoin settlement layer, much of that lives on Ethereum, Solana, Avalanche. Public chains introduce every governance problem I’ve described: upgrade authority is diffuse, oracle dependency is real, composability is the whole point, and there’s no single party you can hold accountable when something goes wrong. The Basel Committee’s third-party risk principles weren’t designed for systems where the “third party” is a decentralized network with no legal entity behind it. DORA sets the right expectations for resilience testing, but the specific failure scenarios for public-chain programmable money haven’t been codified anywhere.

I don’t have a clean answer for that. I’m not sure anyone does just now. But I think the banks that are moving now, building governance for the permissioned end, learning what breaks, developing the institutional muscle, are the ones that will be best positioned when the public-chain question can no longer be deferred. The crypto ecosystem’s $3.4 billion a year in governance failures has produced a detailed map of what goes wrong: access control, upgrade authority, oracle dependency, composability risk, multi-party governance. These are known problems with known shapes. Banks have the institutional discipline to address them. What they haven’t had, until recently, is enough operational experience with the technology to know which of their existing frameworks apply and which need to be rebuilt.

That’s what’s being built right now. Not perfectly, not completely, but the pace is accelerating. The frameworks always get built in motion. That’s how derivatives governance worked. That’s how algo trading oversight worked. That’s how cloud migration worked.

The ones that treat programmable money as a technology problem with a governance appendix will learn the same lesson DeFi has been teaching at $3.4 billion a year.

References

Crypto losses and security data

Specific incidents

OWASP and vulnerability classification

Regulatory and governance frameworks

Financial stability and systemic risk

Institutional adoption and bank initiatives

DeFi governance failures

Operational risk and CrowdStrike

Atomic Settlement

Discussion about this post

Ready for more?