BitGo and ZKsync Are Bringing Banks Onchain. Here Is What That Means for Fintech Compliance.

The Infrastructure Play That Changes Bank Tokenization

In March 2026, BitGo and ZKsync announced a partnership to build tokenized deposit infrastructure designed to bring traditional financial institutions onto a public blockchain. As reported by CoinDesk, the platform is currently in testing and aims to enable programmable payments while simplifying blockchain adoption for banks that have historically treated digital assets as a compliance problem rather than a product opportunity.

This is not another proof-of-concept announcement. BitGo is a qualified custodian with an established institutional client base. ZKsync is a zero-knowledge rollup network built for scalability and low transaction costs. Together, they are building the rails that would allow a bank to issue a tokenized deposit — a digital representation of a bank deposit on a blockchain — and make that deposit programmable. That combination carries real consequences for every fintech startup, bank, and compliance officer watching the tokenization space.

Here is what happened, why it matters, and what your organization should be doing about it right now.

Tokenized Deposits vs. Stablecoins: The Distinction That Matters

Most coverage of this announcement treats tokenized deposits as a variation of stablecoins. That framing is wrong, and the distinction matters enormously for regulatory exposure.

A stablecoin is a liability of the issuer — typically a non-bank entity — backed by reserves held off-chain. The holder has a claim against the stablecoin issuer, not against a regulated depository institution. Regulatory treatment is unsettled, and the GENIUS Act, signed into law on July 18, 2025, imposes a new federal licensing framework specifically for payment stablecoin issuers.

A tokenized deposit is a liability of the bank itself. The depositor's claim remains against the insured depository institution. The token is simply a new representation of that existing relationship — one that can be programmed, transferred on a blockchain, and settled in real time. This means tokenized deposits sit inside the existing bank regulatory framework rather than outside it.

That distinction has three immediate implications:

• FDIC insurance coverage likely follows the deposit, not the token, which changes the risk profile for institutional holders.
• Money transmitter licensing requirements at the state level may or may not apply to the bank itself, but they almost certainly apply to any non-bank fintech that touches the token in the payment flow.
• Bank Secrecy Act and AML obligations attach to the bank, but any middleware platform or wallet provider in the stack faces its own compliance obligations under FinCEN guidance.

The Regulatory Terrain for Programmable Payments in 2026

The BitGo-ZKsync infrastructure arrives at a moment when federal regulators are actively reshaping the rules for digital assets. The Office of the Comptroller of the Currency issued Interpretive Letter 1183 in 2025, confirming that national banks may engage in certain cryptocurrency activities — including holding crypto assets as custodians and participating in blockchain networks — without prior OCC approval. That letter opened the door. BitGo and ZKsync are walking through it.

What "Programmable Payments" Actually Means for Compliance

Programmable payments are not simply faster payments. They are payments with embedded logic — conditions that must be met before a transfer executes. Think escrow that releases automatically upon delivery confirmation, or payroll that distributes based on hours logged in a separate system.

That programmability creates new compliance surface area:

• Smart contract risk: The code governing payment conditions is itself a legal instrument. If the logic is wrong, the payment executes incorrectly. Who bears liability — the bank, the infrastructure provider, or the fintech deploying the contract — is not yet settled by statute or case law.
• OFAC screening: Automated payments must still screen against sanctions lists in real time. A smart contract that executes without a human approval step needs sanctions screening baked into the contract logic or the underlying infrastructure.
• Consumer protection: If a programmable payment fails or executes incorrectly, the CFPB's error resolution rules under Regulation E may apply, depending on how the product is structured and who the end user is.

Fintech startups building on top of this infrastructure need to understand that the bank's regulatory compliance does not flow downstream to them automatically.

What Fintech Startups and Banks Must Do Before Building on This Stack

The BitGo-ZKsync platform is in testing. That testing window is the right time to do legal and compliance groundwork — not after the product launches.

First, map your money transmitter exposure before you write a single line of code. If your fintech application will receive, hold, or transmit tokenized deposits on behalf of users, you are likely operating as a money transmitter in most states. That means licensing obligations in up to 49 jurisdictions. The BitGo-ZKsync infrastructure does not absorb that obligation. Your terms of service cannot disclaim it away.

Second, your terms of service and privacy policy need to reflect the actual product architecture. A tokenized deposit platform that stores transaction data on a public blockchain creates data permanence that a standard privacy policy does not contemplate. If your privacy policy promises users the right to delete their data, and that data is embedded in an immutable ledger, you have a legal problem that no indemnification clause resolves.

Third, conduct a smart contract audit before treating the code as a legal instrument. Courts have not yet established a consistent framework for smart contract liability. Until they do, the audit trail — showing that the contract logic was reviewed, tested, and documented — is your primary defense in a dispute.

Fourth, assess your SEC exposure if the tokenized deposit carries any yield or investment characteristic. The SEC has been consistent: if a digital asset looks like a security, it is treated like a security. A tokenized deposit that pays interest above the bank's stated deposit rate, or that is marketed as an investment product, invites securities law analysis.

Fifth, build your AML and OFAC compliance infrastructure into the product, not onto it. Retrofitting compliance onto a live payment system is expensive and operationally disruptive. The fintech startups that will scale on this infrastructure are the ones that treat compliance as a design constraint from day one.

Key Takeaways

• Tokenized deposits and stablecoins are legally distinct instruments. Treating them as interchangeable will produce the wrong compliance analysis and expose your organization to regulatory risk that a stablecoin framework does not address.
• The BitGo-ZKsync partnership signals that institutional-grade tokenization infrastructure is no longer theoretical. Banks and fintechs that have been waiting for the technology to mature need to begin compliance planning now, not after the platform goes live.
• Money transmitter licensing is the first regulatory hurdle for any non-bank fintech in this stack. State-by-state licensing requirements apply regardless of whether the underlying asset is a tokenized deposit issued by an FDIC-insured bank.
• Programmable payments create new compliance surface area that existing frameworks do not fully address. Smart contract logic, OFAC screening, and Regulation E error resolution all require deliberate design choices before a product launches.
• Your terms of service and privacy policy are regulatory documents, not boilerplate. A tokenized deposit product built on a public blockchain requires legal documentation that reflects the actual data architecture and user rights — not a recycled SaaS template.