We just completed a full security audit with Adevar Labs.
Back to Blog

Banks Are Moving On-Chain: What JPMorgan, HSBC and Citi Are Building and What It Means for Security

Phoebe Duong

Phoebe Duong

Author

August 25, 2026
9 min read
Banks Are Moving On-Chain: What JPMorgan, HSBC and Citi Are Building and What It Means for Security

Bank security is changing before most institutions have finished building their on-chain products. Seven major banks now have live products, granted licenses, or announced launch dates for stablecoins and tokenized deposits, and each one raises the same underlying question: what does it take to secure institutional money once settlement itself becomes programmable. This piece starts with that question, then works outward to what banks are actually building and how the market and regulation around it look today.

Key takeaway:

  • Moving settlement on-chain shifts what banks have to secure, from key custody alone to identity, policy, transaction intent, and recovery across seven distinct layers.
  • MPC and HSM only cover one of those seven layers, the cryptographic signing layer, not identity, policy, compliance, or recovery.
  • Seven major banks are already building or participating in this shift, and regulation across the US, EU, and Hong Kong is real but still incomplete.

Why Banks Are Moving Money On-Chain

Seven major banks, JPMorgan, HSBC, Citi, Standard Chartered, Société Générale, Bank of America, and Wells Fargo, are now building or participating in on-chain money infrastructure, although their approaches differ significantly. Some already move institutional money through live products. Others are still licensing, piloting, or coordinating on shared infrastructure rather than shipping a product of their own. The section on what each bank is building, later in this piece, covers where each one actually stands.

The internet became 24/7 before money did, and that gap, not enthusiasm for blockchain, is what's driving all seven. Money that used to move through ledgers, batch files, and correspondent banking relationships is starting to move through code that executes directly on shared, programmable networks. Our earlier piece on stablecoin adoption traces the same shift from the non-bank side of the market. That shift is what raises the real question this piece is about: not whether banks should do this, but what changes in how they secure it once they do.

How Moving On-Chain Changes the Bank Security Model

Moving money on-chain doesn't just change where the key lives. It changes what the bank has to secure.

Model What Security Has to Protect
Traditional banking Account → Ledger → Payment Instruction → Authorization → Settlement, entirely inside infrastructure the bank controls
On-chain banking Identity → Wallet → Transaction → Smart Contract → Policy → Signature → Blockchain → Settlement, partly on shared, programmable networks

The real competition may not be over whether money moves on-chain. It is over whose balance sheet that money sits on, and who controls the infrastructure around it. That distinction matters for security because the institution is no longer securing a payment instruction alone. It is securing programmable authority over money.

What Changes When Banks Move Settlement On-Chain

Three things change once settlement moves on-chain.

Identity becomes wallet authority. An employee's permission used to be tied to an account. On-chain, it has to be tied to signing authority over a wallet. Losing control of that authority can translate directly into loss of funds, because the blockchain ultimately enforces the cryptographic authorization rather than an internal bank ledger.

A payment becomes an executable transaction. "Transfer $10 million to Company X" is a simple instruction in a traditional payment system. On-chain, the equivalent can be: call contract X, execute function Y, transfer token Z, interact with contract A, change state B. Transaction intent gets harder to verify at a glance.

Policy moves closer to execution. A bank normally checks amount, counterparty, sanctions status, and approval thresholds through back-office review before a payment moves. On-chain, those same checks have to run before a signature is ever produced, because once a transaction is signed and broadcast, there's no back-office left to catch it.

These changes create new attack surfaces across transaction intent, policy enforcement, key management, infrastructure, compliance, and recovery. That is why securing on-chain money requires more than protecting a private key.

Stablecoins vs. Tokenized Deposits: Different Security Implications

The security implications differ depending on whether the token represents a claim on reserves or a direct liability of the bank.

The distinction isn't about who issues the token, it's about whose balance sheet the claim sits on. A stablecoin is a claim against its issuer's reserves. A tokenized deposit is a claim against the bank itself. Our explainer on what tokenized deposits are and why banks are building new settlement rails covers a risk worth flagging here: because a tokenized deposit is minted directly against a bank's own authority, a compromised minting key threatens the bank's solvency in a way a compromised stablecoin key does not.

Why Banks Prefer It What It Means
Stays a bank liability No new instrument outside the balance sheet; simpler accounting and capital treatment
Keeps deposits in-house, can pay interest Avoids deposit flight; unlike a stablecoin under the GENIUS Act or MiCA, which cannot pay yield

The preference isn't universal (HSBC runs both a Tokenised Deposit Service and a licensed stablecoin), and Citi's version shows why the line matters less to customers than it does to balance sheets. Citi Token Services is explicitly designed so clients don't need to set up a wallet or hold any token at all; they log into CitiDirect, their existing banking portal, and the blockchain runs invisibly underneath. The most important institutional blockchain products may be the ones customers barely notice are blockchain products at all.

The Seven Layers of Institutional On-Chain Security

Layer Question It Answers
Identity & Access Who is allowed to access the system at all?
Transaction Authorization Who is allowed to approve a transaction, and how many parties does it take?
Policy & Controls Which transactions are allowed to happen in the first place?
Key Management How are keys generated, stored, and used?
Infrastructure Is the signing environment and underlying blockchain infrastructure secure?
Compliance & Monitoring Does the transaction violate AML rules, sanctions, or limits?
Recovery & Resilience What happens if a system, key, or signing party is compromised or fails?

A bank doesn't ask "how do we protect the private key." It asks who, using what system, is allowed to authorize what transaction, under what conditions, and whether it can prove, stop, reverse, or recover from it if something goes wrong.

That creates seven distinct security layers: identity, transaction intent, policy, signing and key management, infrastructure, compliance, and recovery.

Each layer answers a different question, but they ultimately converge on one critical moment: the transaction has to be authorized and signed before it can execute on-chain.

That is where cryptographic controls such as MPC and HSM become relevant. They protect the authority that turns an approved transaction into an actual on-chain action.

But they solve different problems, and neither one is the complete answer to institutional transaction security.

MPC vs. HSM: Two Layers of Institutional Key Security

Once a transaction has passed an institution's identity, policy, and approval controls, one question remains: how is the authority to sign that transaction actually protected?

This is where MPC and HSM come in.

MPC and HSM are often discussed as competing approaches to crypto custody, but they solve different problems. MPC is primarily a software-based approach to distributing signing authority, while an HSM is hardware designed to protect cryptographic keys and perform signing inside a secure environment.

For institutions handling large transaction volumes or high-value assets, understanding the difference matters because the signing layer is where an approved transaction becomes a cryptographically authorized transaction on-chain.

MPC: Distributed Signing Authority Through Software

Multi-Party Computation (MPC) is a cryptographic technique that allows multiple parties or environments to jointly generate a signature without any single party ever holding the complete private key.

Instead of storing one complete private key in one location, MPC divides signing authority across multiple key shares. When a transaction needs to be signed, the participating parties use those shares together to produce a valid signature, while the complete private key is never reconstructed in one place.

This changes the security model from:

One private key → one point of failure

to:

Distributed signing authority → multiple independent controls

MPC is particularly useful for institutions that need flexible, programmable controls around transaction signing. The signing workflow can be integrated with role-based access, multi-party approvals, transaction policies, and automated treasury operations.

This is where Fystack fits. Fystack provides self-hosted MPC custody infrastructure for enterprises that need to control their own signing environment rather than rely on a third-party custody stack. Its software layer combines wallet management, policy enforcement, approvals, treasury automation, and audit trails around the signing process.

HSM: Hardware Protection for Cryptographic Keys

An HSM (Hardware Security Module) takes a different approach.

Instead of relying primarily on software controls to protect key material, an HSM uses dedicated, tamper-resistant hardware to generate, store, and use cryptographic keys. The private key remains inside the protected hardware environment, and signing operations are performed there rather than exposing the key to the surrounding application or infrastructure.

In an institutional custody environment, this creates a clear security boundary:

Application → signing request → HSM → signed transaction

The private key does not leave the HSM during the signing process. In the Fystack × Securosys architecture, transaction policies and approvals are handled by Fystack, while the signing operation takes place inside Securosys HSM infrastructure.

HSMs are especially relevant where institutions face strict security, audit, infrastructure, or regulatory requirements. Securosys provides HSM-backed security with options including on-premises and CloudHSM deployment, allowing institutions to keep the signing infrastructure within an environment they control.

The hardware layer also brings formal security certifications and evaluation standards into the architecture. The Securosys solution referenced in the Fystack brochure includes FIPS 140-2 Level 3 and Common Criteria EAL4+, alongside ISO 27001 and ISO 9001 certifications.

MPC + HSM: Software Control Meets Hardware Security

MPC and HSM therefore should not be framed as an either-or decision.

They protect different parts of the signing architecture.

Fystack provides the software and orchestration layer: wallet management, transaction policies, role-based access, multi-party approvals, treasury automation, and audit trails.

Securosys provides the hardware security layer: key generation and storage, cryptographic signing, and tamper-resistant HSM infrastructure.

Together, they create a custody stack where the institution controls the transaction workflow while cryptographic signing remains protected by dedicated hardware.

The flow is straightforward:

Transaction initiated → policy check → approval → HSM signing → on-chain broadcast → audit trail

That separation is important for institutional security. The software layer determines what is allowed to happen. The hardware layer protects the cryptographic authority that makes it happen.

This is why Fystack and Securosys fit together: Fystack provides the orchestration and policy layer; Securosys provides the hardware-backed signing layer. Together, they give institutions a self-controlled custody stack without forcing them to build the entire security infrastructure from scratch.

What JPMorgan, HSBC, Citi and Other Banks Are Building On-Chain

Here's where each of the seven stood as of August 2026.

Bank What They're Building Status (Aug 2026)
JPMorgan JPMD, a USD deposit token on Coinbase's Base network, plus expansion to the Canton Network Piloted June 2025, available to institutional clients since Nov 12, 2025; Canton rollout in phases through 2026
HSBC Tokenised Deposit Service (corporate) plus a licensed HKD stablecoin TDS live in HK, Singapore, UK, Luxembourg, US, UAE; one of only 2 HKMA stablecoin licenses; stablecoin still targeting H2 2026, not yet live
Citi Citi Token Services (tokenized deposits) plus a Coinbase partnership on stablecoin rails CTS live in the US, UK, Singapore, Hong Kong, Dublin; own stablecoin still under evaluation
Standard Chartered HKDAP, an HKD stablecoin via Anchorpoint Financial, a JV with Animoca Brands and HKT Licensed April 2026; began limited institutional beta Aug 12, 2026 (after missing its original Q2 2026 target); retail access targeted as early as end-2026
Société Générale EUR CoinVertible and USD CoinVertible stablecoins via subsidiary SG-FORGE Live since 2023 (EUR) and 2025 (USD), MiCA-licensed, expanding to Canton and MetaMask
Bank of America No standalone stablecoin; co-building the Tokenized Deposit Network Publicly cautious on stablecoins (CEO has warned of $6T deposit-flight risk); TDN targeting H1 2027
Wells Fargo Co-building the Tokenized Deposit Network No solo tokenized-deposit product confirmed; participant in the shared network only

The pattern is notable: Bank of America and Wells Fargo are participating in a shared tokenized-deposit network alongside JPMorgan and Citi rather than launching standalone products. That suggests the competition may be shifting from bank vs. bank toward banking infrastructure vs. external stablecoin rails.

Stablecoin Regulation in the US, EU and Hong Kong

Regulation is moving quickly, but implementation is uneven across markets.

Region Framework Status (Aug 2026)
United States GENIUS Act (signed July 18, 2025) Rulemaking milestone passed; OCC, FDIC, Treasury, FinCEN/OFAC proposals out, comment periods through Aug 2026
European Union MiCA, Titles III & IV (in force since June 30, 2024) Fully in force; bank/EMI-only issuance, no yield, reserve rules enforced by national regulators and the EBA
Hong Kong Stablecoins Ordinance (in effect Aug 1, 2025) 2 of 36 applicants licensed; Anchorpoint live in beta since Aug 12, 2026, HSBC still targeting H2 2026

A signed law or a granted license is not the same as a live product; teams building for this space should track launch dates as closely as legislation.

Beyond Key Custody: The New Security Model for Banks

Banks are moving settlement on-chain faster than their security models are evolving. The next phase will be less about choosing between MPC, HSM, or another custody technology, and more about integrating identity, policy, transaction authorization, compliance, and recovery into a single control plane.

If you are building custody or signing infrastructure for institutional stablecoin and tokenized deposit flows, Fystack builds open-source, self-hosted MPC custody with a policy engine that enforces spend rules before signing.

About Fystack

Fystack is an enterprise-grade, self-hosted MPC custody platform for fintech teams. The core signing infrastructure, mpcium, is open-source and Fystack supports multi-chain wallet operations across TRON, ETH, BNB, Solana, Polygon, and more.

FAQ

What is the difference between a stablecoin and a tokenized deposit?

A stablecoin is a tokenized claim against its issuer's reserves, and that issuer can be a bank, a bank subsidiary, or a non-bank company. A tokenized deposit is a claim against the bank itself, with no new instrument created.

Is JPMorgan's JPMD a stablecoin?

A stablecoin is a tokenized claim against its issuer's reserves, and that issuer can be a bank, a bank subsidiary, or a non-bank company. A tokenized deposit is a claim against the bank itself, with no new instrument created.

What is the difference between MPC and HSM for crypto custody?

MPC distributes signing authority across multiple parties or environments so no single participant ever holds the complete private key. HSM keeps key material inside certified, tamper-resistant hardware. They answer different questions in a signing architecture and are often combined rather than chosen between.

Could MPC or HSM have prevented hacks like Bybit or Ronin?

Not on their own. Both incidents involved a valid signature approving an action the signer didn't actually intend, a gap between cryptographic validity and business intent that transaction simulation, policy engines, and multi-party approval are specifically designed to catch.

Share this post