How global banks are implementing tokenized deposits in practice - revealing deep regulatory, architectural, and conceptual divergences across regions and companies.
- Introduction
- JPMorgan
- Citi
- BNY Mellon
- HSBC’s Tokenized Deposit Service (TDS)
- Swiss Banks’ Deposit Token (Swiss Banking Association Initiative)
- Monetary Authority of Singapore’s Project Guardian (Multi-Bank Consortium)
- Tokenized Deposits from R3
- Deutsche Bank’s Blockchain-Based Money Initiatives (DAMA)
- Conclusion
1. Introduction
In Part 1, we examined what tokenized deposits are, how they differ from other crypto technologies, and their advantages compared to traditional deposits. In this part, we’ll explore how tokenized deposits are being implemented by banks and what progress has been made.
Commercial banks play a major role here since they’re interested in improving capital efficiency and are actively researching new technologies and niches. This, incidentally, is one reason why it might seem like only commercial banks are interested in tokenized deposits while central banks only care about CBDCs - which isn’t actually true.
After defining the general properties and criteria for tokenized deposits, it’s time to look at practical implementations that various sources characterize as tokenized deposits. Do they actually match what we discussed in Part 1?
BRRR DAO is a team of experienced Web3 enthusiasts with diverse expertise, committed to actively participating in the evolution of the blockchain industry.
For context, a KPMG article notes that EMEA and ASPAC regions are more focused on developing and launching digital currencies and tokenizing real digital assets than the US (though this doesn’t specifically address tokenized deposits). Is the same situation true for tokenized deposits?
This is actually a rather complex question. So let’s dive deeper.
2. JPMorgan
Let’s start with JPMorgan since this case demonstrates the duality between tokenized deposits and deposit tokens that we analyzed in the previous part. JP has already implemented a pilot - in June 2025, through their Kinexys division, they launched a trial deposit token called JPMD on Base.
JPMD is a deposit token - a digital representation of a dollar deposit held at J.P. Morgan. It operates on Base but is only accessible to permissioned institutional clients (permissioned model). This is implemented through a smart contract with “whitelists” instead of creating a separate environment.
JPMD and deposit tokens generally align with novel and distinctive stablecoin properties - particularly p2p transaction capabilities with programmability. Thus, deposit tokens and stablecoins can be applied in similar scenarios. However, deposit tokens differ from stablecoins in key areas, including interest payments and deposit processing (which isn’t possible with stablecoins and CBDCs).
In plain language: when clients deposit dollars at JP Morgan, the bank records these amounts as deposits on its balance sheet. JP Morgan then issues a corresponding amount of JPMD on the public blockchain. It also retains legal rights to claims on bank deposits. Token holders can exchange tokens for real dollars at a 1:1 ratio. They can also claim deposit protection and interest income - one of the characteristics of tokenized deposits.
Currently, since this is a pilot project, only institutional JPMorgan clients can access JPMD (which is why the diagram shows Company A and Company B rather than individual clients), ensuring control and regulatory compliance (source).
What further amplifies the duality and uncertainty around deposit token and tokenized deposit regulation - on one hand, JP draws a distinction between deposits and tokens:
On the other hand, they note that despite deposit tokens potentially exhibiting behavioral characteristics different from traditional deposits (since they have new features), they can be regulated under existing banking norms. The view that these are capable of adequately covering deposit token issuance is also reflected in recent public consultations from MAS. This means the same liquidity, capital, and risk management standards apply - Basel Committee methodologies, anti-money laundering and counter-terrorism financing rules, technology risk management, and other aspects.
But here again the duality and terminology ambiguity problem emerges regarding clear correspondence to specific terms and norms. According to the diagram and overall JPMD paper context, JP Morgan’s product is specifically a token that isn’t the same entity as a deposit in the bank account sense. And according to most definitions in various crypto regulations, it should fall under regulation as a crypto token.
This fact may become a differentiating factor toward developing specifically tokenized deposits as DLT accounts fully analogous to bank accounts. Why change laws in a dynamic industry - a long and laborious process - if you can do it differently?
3. Citi
Among other banks, R&D related to tokenized deposits without formulation ambiguity between CBDCs and asset tokenization was only found at Citi. Citi is actively developing its own tokenized deposit platform (CTS, Citi Token Services for Cash) and payment instruments. Unlike JPMD, it’s focused on cross-border transfers.
Unlike JPMD, Citi’s solution represents tokenized bank deposits. But there are positioning nuances: Citi leadership, including CEO Jane Fraser, positions it as a more advanced alternative to stablecoins thanks to less friction and direct connection to banking infrastructure.
The publication “Liquidity Keeping Pace with the Real-Time World: What’s Next” notes:
“The tokenized deposits of Citi Token Services for Cash are digital representations of Citibank’s interbranch liabilities, and do not represent a deposit claim between a customer and Citibank. No token is issued by Citibank to any customer, nor does any customer hold or use any tokens, in relation to Citi Token Services for Cash.”
So on one hand, public sources draw associations between CTS and tokenized deposits. On the other - it’s designated as essentially internal infrastructure that doesn’t relate to deposit claims and obligations, which removes this implementation from bank deposit regulation.
CTS is built on a private Hyperledger Besu implementation, despite being functionally more open overall compared to JPMD. But generally - it operates in a closed environment, emphasizing corporate security and scalability without entering public networks. This configuration supports EVM compatibility for smart contract execution, while Besu’s enterprise capabilities provide stricter access control mechanisms, enhanced privacy features, and the ability to interact with the broader Ethereum ecosystem.
Key points:
- The system received the “Model Bank Award for Digital Asset Innovation 2024” from Celent
- CTS already operates as a pilot in four jurisdictions, processing billions of dollars in transactions
- Later, Citi integrated this technology with its traditional 24/7 USD Clearing solution, expanding its use to interbank payments (from late 2025)
- The pilot Citi Token Services for Trade uses smart contracts to fulfill specific conditions (e.g., conditional payment released only when certain conditions are met)
- Another interesting point regarding Citi: they’re testing fractional bond trading based on tokenized deposits together with BondbloX - which theoretically falls under crypto-asset regulation.
- Unlike JPMD, interest accrual capability isn’t indicated in the basic description - emphasis is on liquidity for payments without yield accrual.
CTS doesn’t work as a standalone system - it’s integrated into CIDAP (Citi Integrated Digital Assets Platform) for scalable industrial use. CIDAP is a platform that brings together all of Citi’s digital asset efforts in one place. Through CIDAP, CTS is connected to multiple Citi systems (for liquidity management and cross-border transfers) and integrated with tools like 24/7 USD clearing for real-time settlements. It supports digital asset storage and wallet management, providing a user-friendly interface for accessing services.
The closed Besu-based implementation allows CIDAP to form one of the foundational principles for such systems in the tokenized deposit context - centralized management. The WEF publication “Asset Tokenization in Financial Markets: The Next Generation of Value Exchange” indicates that CIDAP uses permissioned ledgers with governance models described as:
“Moderately centralized: Governance through permissioned entities who validate the network” or “Highly centralized: Even narrower onboarding of permissioned entities to validate the network.”
CTS uses smart contracts for automation, particularly in related initiatives like Citi Token Services for Trade, where they process conditional payments (e.g., automating processes in the logistics ecosystem to reduce processing time). These contracts allow embedding programmable logic into transactions - rules for fractionalization, using tokens as collateral in lending, or liquidation triggers. This also enables embedding compliance rules (e.g., investor status verification or jurisdictional restrictions) directly into tokens, enabling atomic settlements and programmability.
And here the regulatory instability of tokenized deposits becomes visible again. As mentioned above in the quote from “Liquidity Keeping Pace with the Real-Time World: What’s Next”, CTS and CIDAP are essentially internal infrastructure - they don’t issue tokens to clients and aren’t depository relationships between bank and client. The “Introducing Citi Integrated Digital Assets Platform (CIDAP)” article also mentions that CIDAP operates within Citi’s corporate governance and acceptable risk level. Thus, CTS falls under neither MiCA-like regulations nor bank deposit regulation rules.
Meanwhile, an interview article with Ryan Rugg, Head of Digital Assets at Citi’s Treasury and Trade Solutions, mentions that everything operates in accordance with various jurisdictional rules:
“Citi follows U.S. law as a U.S.-domiciled bank, but we also work closely with global regulators in key markets like the UK, Singapore, and the EU. In each jurisdiction, we ensure regulatory compliance before launching new services. For example, Citi Token Services for Cash (CTS) operates in the U.S., UK, and Singapore, aligning with regional regulatory frameworks.”
But this doesn’t provide a definitive answer about which specific rules and regulations (beyond corporate ones) govern CTS. Despite Citi’s implementation partially meeting tokenized deposit criteria (centralized management, transfer functionality, integration into 24/7 banking infrastructure, programmability) - it doesn’t fall under traditional bank deposit regulation. Theoretically, these are tokenized deposits, but practically, they’re not legally connected for users.
This prompts a question: is regulation even needed for tokenized deposits if it’s an internal infrastructure implementation? Perhaps this is fair in this specific case. But ideally, tokenized deposits should be interoperable - just as cross-chain interactions are enabled between different chains (in this context, between different banks’ infrastructures).
4. BNY Mellon
Bank of New York Mellon (BNY) launched a pilot tokenized deposit project in October 2025 to enable blockchain-based payments. The main focus is 24/7 instant settlements for institutional clients, integrating with traditional custodial services to reduce friction in high-value transactions. The pilot was launched to modernize existing infrastructure.
In this case, one of the most important tokenized deposit properties is highlighted - 24/7 operation, which is an advantage compared to traditional correspondent bank networks limited to standard business hours.
There aren’t many technical details available yet. But judging by the absence of loud marketing announcements from public chains, we can assume their technology is based on a permissioned blockchain to ensure regulatory compliance and controlled access.
Separately noteworthy: BNY is also working on tokenization - in collaboration with Goldman Sachs, they launched a tokenized MMF project using Goldman Sachs Digital Assets Platform (GS DAP), a private permissioned blockchain based on Canton Network (likely using DAML for smart contracts). This is used as part of BNY’s LiquidityDirect platform.
In broad strokes, this could be a precursor to tokenized deposits since it partially resembles Citi’s technology for internal use. With BNY LiquidityDirect, investors select tokenized MMF share classes through the platform (e.g., TKNXX for Dreyfus Treasury Securities Cash Management). Subscriptions and redemptions occur as usual in traditional systems. Then BNY, acting as shareholder servicer, custodian, and tokenization manager, initiates minting or burning of mirror tokens on GS DAP. These tokens reflect anonymized holdings synchronized with BNY’s accounting records for double-entry bookkeeping - somewhat similar to the idea of representing deposits in tokenized form on DLT (or more precisely, the deposit token idea).
Additionally, BNY participates in developing the SWIFT shared blockchain ledger prototype, which uses Linea for its first pilots - an Ethereum L2 developed by ConsenSys. Linea uses zero-knowledge (zk) proofs for transaction privacy, ensuring scalability while maintaining Ethereum compatibility.
Thus, despite limited information about BNY’s deposit tokenization platform, we can assume that in this case, the difference between tokenized assets and tokenized deposits is clear to internal developers. It may also become part of BNY LiquidityDirect. Moreover, SWIFT’s shared blockchain ledger technology could serve as a foundation for future interaction between different banks’ tokenized deposit DLTs.
5. HSBC’s Tokenized Deposit Service (TDS)
There’s relatively little information about this case, but some interesting details exist. TDS operates on HSBC’s proprietary DLT-based platform, described as a private blockchain network ensuring controlled access, high security, and regulatory compliance. It was created in collaboration with Ant International on their Whale DLT platform for blockchain-based treasury management.
The architecture allows integration with various client systems (e.g., ERP or treasury platforms) via API, facilitating on-demand fund movement. Notably - despite the Asia focus, it’s initially oriented toward US dollars, with expansion to other currencies for global treasury centers in Asia (e.g., Hong Kong, Singapore).
In September 2025, HSBC expanded its tokenized deposit offering to support cross-border transactions for corporate clients. This enables programmable real-time transfers of fiat-backed tokens.
For blockchain interoperability, TDS integrates with platforms like the Hong Kong Monetary Authority’s (HKMA) Project Ensemble Sandbox, which includes an interoperability platform for token transfers between different financial institutions’ blockchains.
In related HSBC initiatives (e.g., through Project Ensemble), tokens support composability for use in payments, settlements, and asset tokenization. Tokens are issued upon deposit conversion, with minting executed via smart contracts in the private ledger. This process is automated and complies with local regulatory requirements, including AML/KYC whitelisting.
6. SBDT - Swiss Banks’ Deposit Token (Swiss Banking Association Initiative)
Unlike previous implementations, the Swiss Banks’ Deposit Token has extensive details, including regarding regulation. It is also worth noting that this may be viewed as a variant of interchangeable definitions between Tokenized Deposits and Deposit Tokens; however, the two technologies are delineated in this context while being applied in conjunction.
The Swiss banks’ deposit token initiative, led by the Swiss Banking Association (SBA) in collaboration with PostFinance, Sygnum Bank, and UBS, culminated in a Proof of Concept (PoC) completed in September 2025. This PoC tested the feasibility of a blockchain-based deposit token as a digital representation of a payment order under Swiss law (Art. 466 et seq. CO, Swiss Code of Obligations) - not as a new form of money or crypto-asset.
Notably, it avoids complex constructs like registry-based securities or assignment of claims, instead functioning as a standardized trigger for debiting and crediting traditional bank accounts. And moreover - this infrastructure enables p2p transactions within banking infrastructure between different banks:
How the process works:
- Client initiation: The payer instructs their bank (issuing bank) to transfer deposit tokens to the payee’s wallet held at another bank (receiving bank)
- Transfer initiation by issuing bank operator: The issuing bank operator initiates a transfer request from the payer’s wallet to the payee’s wallet; the transaction receives “pending” status
- Mirror account debit (payer): The issuing bank debits funds from the payer’s mirror account and credits them to its SNB account, reserving the token amount for transfer and ensuring consistency between its internal ledger and blockchain
- Compliance verification at issuing bank: The transaction doesn’t proceed if these checks fail
- Interbank settlement via SIC
- Compliance verification at receiving bank: Before completing the transfer, the receiving bank conducts its own compliance verification
- Mirror account credit (payee): The receiving bank debits funds from its SNB account and credits them to the mirror account corresponding to the payee. This confirms internal fund receipt and ensures the incoming deposit token fully matches the account balance
- Smart contract completion: After all checks and SIC settlement complete, the receiving bank operator calls the smart contract to accept the deposit token transfer
- Transaction finalization
The PoC used the public Ethereum blockchain for its distributed ledger capabilities, providing transparency and immutability. A permissioned layer was added on top for access control, restricting participation to authorized financial institutions and clients. This hybrid “public-permissioned” model balances openness for interoperability with security for institutional use. Future expansions may include integration with wholesale CBDCs (wCBDC) or real-time gross settlement (RTGS) systems for on-chain settlements.
The deposit token is implemented as a fungible token using a modified ERC-20 standard with role-based access control (RBAC). It represents a mapping of wallet addresses to balances, issued and burned synchronously with external debits/credits to mirror accounts within core banking systems.
Key features:
- Fungible between participating banks through a single shared smart contract
- Wallet addresses uniquely linked to authorized entities (e.g., banks or clients)
- Not a bearer security; relies on external authoritative records for value confirmation
- Open source under MIT license, available on GitHub for transparency and collaborative development
Why the Deposit Token definition fits here: The main component is a permissioned ERC-20 contract with upgradeable proxies (logic and storage separation for V1 implementations). It handles token issuance/burning, transfer initiation, role management, and transaction status updates (e.g., from “pending” to “completed”). The system processes conditional settlements, referencing deposit tokens and tokenized assets for Delivery-vs-Payment (DvP).
The system includes role separation: Platform Admin (deploys/upgrades), Bank Authority (approves roles, issues/burns), Bank Operator (whitelists wallets, initiates transactions), and Bank Client (initiates approvals).
SBDT is also the most constructive and well-developed solution in terms of regulatory compliance. Regulation partially follows norms for both token issuance and deposits - Swiss Code of Obligations (CO) Articles 466 (deposit token as standardized digital payment order), 470(2 bis - payment irrevocability and finality), Swiss Banking Act Article 1b (deposit token issuance only by licensed banks), 37a and 37h (deposit insurance), plus anti-money laundering, due diligence, and data transfer regulations - AMLO-FINMA.
Regulatory bodies involved in deposit token operations are clearly identified:
- Swiss Financial Market Supervisory Authority (FINMA): Primary regulator overseeing AML/CTF compliance (via AMLO-FINMA), transaction monitoring, and sanctions procedures
- Swiss National Bank (SNB): Provides settlements through the SIC system and considers future integration with wCBDC or RTGS
Using this implementation as an example - which appears deeply developed from multiple angles - the differences from commercial bank solutions become clearly visible. Where BNY Mellon and Citi use DLT-based solutions as internal infrastructure, SBDT offers an implementation that considers both traditional banking principles with DLT interaction nuances and is built with original regulatory compliance in mind.
The SBDT example, which complies with numerous regional rules and norms, clearly shows how much regulation can differ for tokenized deposits and deposit tokens.
7. Monetary Authority of Singapore’s Project Guardian (Multi-Bank Consortium)
Project Guardian is one of the oldest initiatives, launched by the Monetary Authority of Singapore (MAS) in 2022 and evolving through 2025. It’s a sandbox project involving various companies with different implementations - a testing ground for practical implementations and their interoperability. The goal is solving real problems like traditional system inefficiencies, settlement risks (e.g., Herstatt risk), and lack of interoperability through experimental use cases, shared frameworks, and standardized protocols that promote adoption and compatibility across different DLT platforms.
One key feature of Project Guardian projects compared to all previous solutions: support for ISO 20022 and SWIFT MT with tight interaction with traditional banking infrastructure instead of replacing it (though not all participants in this program have implemented this).
This project relates to both Deposit Tokens and Tokenized Deposits since it essentially covers different implementations. Moreover, MAS uses the term “Tokenized Funds”, which seems close to RWA. But with RWA there’s an important nuance: it’s asset tokenization within crypto/web3. With Tokenized Funds in MAS’s current context, it means tokenization within banking infrastructure - so this can be attributed to Deposit Tokens.
According to documentation, Project Guardian recommends using a hybrid model - distributed ledger technology (DLT) combined with traditional infrastructure to ensure controlled access, backward compatibility, and regulatory compliance.
Tokenized deposits/deposit tokens represent tokenized bank obligations (e.g., SGD or USD tokens) that are either digital twins (linked to off-chain deposits) or native on-chain tokens backed 1:1 by fiat in bank accounts. They use ISO 20022 for messaging, UTI/UPI for identifiers, and LEI for entity identification.
According to another document, the following technical implementation is proposed for Project Guardian: Ethereum-compatible network integrating standards like ERC-20/721 for fungibility, ERC-3643 for compliance, and protocols like Hash Time-Locked Contracts (HTLC) for cross-chain operations.
For FX (cross-border currency exchanges between different banks), the following standards are proposed (which we’ve seen before):
- Hash Time-Locked Contracts (HTLC) for cross-ledger exchange
- Multi-Token Swap (MTS) - smart contracts for atomic currency swaps
- Payment versus Payment (PvP) - orchestration enabling continuous 24/7 settlements without dependence on centralized intermediaries
As mentioned, Project Guardian isn’t implementing a single technology. Various banks participate in this project, many of which are developing their own tokenized deposit and deposit token technologies with case analyses. These include JPMorgan, DBS, Standard Chartered, Ant International, BNY, OCBC, and HSBC, who collaborate in related pilot projects on tokenized bank obligations (including deposit tokens) across areas like foreign exchange (FX), transaction banking, asset and capital management, and debt instruments.
Beyond companies, this includes global policymakers - the United Kingdom’s FCA, Switzerland’s FINMA, and Japan’s FSA.
8. Tokenized Deposits from R3
R3’s Corda technology deserves attention because they’re one of the oldest DLT solution providers for financial infrastructure since 2016. R3’s tokenized deposit solution is a permissioned digital currency platform (based on the private Corda blockchain) enabling banks to issue tokenized versions of client deposits while fully retaining funds within the regulated banking system.
And here again the duality between tokenized deposits and deposit tokens is visible. In practice, each token represents a 1:1 claim on a fiat deposit held at the issuing bank. The further technology description leans more toward “deposit tokens” (each deposit token is represented as a separate UTXO-like state in Corda) since the main functionality relates not so much to Account as to tokens - though at an abstract level it looks like a tokenized deposit.
R3 builds this solution on its Corda distributed ledger platform, using Token SDK to model deposit balances as ledger tokens. In R3’s architecture, banks run nodes in a shared Corda network: when a client deposits or withdraws fiat, a smart contract (called a “flow”) issues or redeems the corresponding token.
R3’s product called Digital Currency (part of the Digital Markets package) manages the full token lifecycle - issuance, transfer, interest accrual, and redemption - with customizable rules (e.g., spending limits or expiration) embedded in contract logic. Programmability is implemented at the protocol level: tokens can contain conditions (e.g., “spend only at specific merchants” or “automatic coupon payments”), and these rules are automatically removed when the token leaves the controlled environment.
Another interesting nuance regarding the tokenized deposit/deposit token duality: interest accrual isn’t implemented through the token itself (rebalancing) but through smart contracts. Smart contracts enable automating interest accrual, compliance verification (KYC/AML integration), conditional payments; fractional ownership for liquidity optimization; immutable ledgers for transparency without exposing sensitive data in public environments; and much more.
R3’s solution has one of the main tokenized deposit characteristics - direct connection between DLT account and bank account. R3’s tokenized deposits are tightly integrated into existing banking infrastructure. The issuer (bank) retains control over fiat backing, and each token is fully backed by a deposit obligation on the bank’s balance sheet.
In practice, token issuance and redemption are linked to accounting records: when a token is issued, the bank debits funds from its own liquidity pool; upon redemption, the bank credits fiat to the client’s account. This model “keeps deposits within the banking system” even if ownership rights are recorded on-chain. And APIs (R3 Digital Connect) are used to implement another tokenized deposit characteristic - programmability.
R3’s solution connects tokenized and traditional systems through an Orchestration Layer and extensive APIs, ensuring seamless integration with banks’ core accounting systems, real-time gross settlement (RTGS) systems, and payment channels like Open Banking.
In the UK’s Regulated Liability Network (RLN) project, Corda is used as the foundation for a multi-issuer tokenization platform interacting with simulated RTGS and initiatives like Project Rosalind, while using Quant’s Overledger for extended programmability. Partnerships with banks (e.g., HSBC, Barclays, Citi) and companies (e.g., DXC Technology, Mastercard) provide regulated interoperability, allowing tokenized deposits to inherit fiat backing, deposit insurance, and client base.
This two-tier approach - tokens for peer-to-peer transfers, settlements through wholesale CBDCs or RTGS - enables interaction with current infrastructure without any intervention or adaptations on its side.
9. Deutsche Bank’s Blockchain-Based Money Initiatives (DAMA)
Despite the name suggesting a blockchain system, Deutsche Bank’s technology relates to tokenized deposits and deposit tokens. Deutsche Bank’s blockchain-based initiatives as of October 2025 focus on tokenized deposits, stablecoins, and unified ledgers for modernizing payments, settlements, and asset management. And in November 2025, DBS jointly with JPMorgan began R&D toward tokenized deposit interoperability.
These efforts emphasize regulatory compliance, interoperability, and integration with traditional finance, with key projects like Project DAMA (Digital Assets Management Advancement) and participation in global consortiums. While specific proprietary code details (e.g., full smart contract implementations) aren’t publicly available, available information reflects a hybrid approach combining private and public-permissioned blockchains.
Deutsche Bank primarily uses Ethereum (ETH) for pilots, including Project DAMA 1 (launched 2023) and Project DAMA 2 (MVP presented 2024), which already operates on a public-permissioned configuration: Ethereum L1 + private L2 (Memento ZK Chain).
Memento is a permissioned Validium rollup built on the ZKsync stack (from Matter Labs) with Prividium enhancements for privacy. It handles core smart contract execution, offering high throughput (up to 2,000 transactions per second), low costs, and off-chain data availability for scalability. Features include whitelisted wallet access, private RPC endpoints, a private block explorer, and a single sequencer for near-instant finality. It’s fully compatible with ERC standards and Solidity, enabling programmable asset lifecycle management (e.g., issuance, transfers, redemptions) in a controlled environment.
For future interaction with different ledgers, Axelar Network support is integrated. It uses Axelar’s Interchain Token Service (ITS) portal, which deploys Token Manager smart contracts (supporting lock/unlock or mint/burn mechanisms) on DAMA 2’s Layer 2 and destination chains. Compliance rules (e.g., for blacklisted addresses) are enforced via smart contracts on Axelar. This facilitates a “hub-and-spoke” model for 1:M (one-to-many) token distribution, maintaining fungibility and modularity without requiring custom code on target chains.
And what’s most unusual - the DAMA 2 whitepaper mentions the phrase “Transaction originating on Memento ZK Chain Layer 2 and distributed to 77+ EVM and non-EVM Layer 1 and Layer 2 public chains,” which may mean public chain support too. But for banking ledgers, as we’ve seen earlier, separation from crypto is important for risk mitigation. Moreover, this document even discusses MEV.
The hybrid architecture combines on-chain elements (token lifecycle, transfers) and off-chain elements (authoritative records in core banking systems) - as proposed in Project Guardian. This again adds contradictions to understanding DAMA 2 - it’s unclear which direction it leans: DeFi and stablecoins, or banking infrastructure. Perhaps as joint pilot initiatives expand, the contours of DBS’s solution will become clearer.
Also, despite DAMA 2 being implemented within Project Guardian, ISO 20022 compatibility isn’t stated. SWIFT support in the current implementation also isn’t mentioned. Banking participants connect directly without SWIFT messaging. The project is oriented toward open-API connection of existing roles (transfer agents, fund administrators) but through digital interfaces rather than SWIFT. Thus, interaction with legacy systems is achieved through integration solutions rather than SWIFT protocols.
10. Conclusion
In Part 1, we outlined the contours of what tokenized deposits and deposit tokens could be. Among the main characteristics was tight connection with bank accounts along with corresponding regulation as for regular bank deposits. And in real examples, quite strong divergences from these theses are noticeable.
American banks prefer using DLT as internal infrastructure where users won’t even know their funds are moving using blockchain technology - without explicit references to public standards.
European banks - conversely - are trying different forms: from DAMA with clear nods toward “regular crypto” (which gives it an opaque regulatory status) to the complex, thoroughly considered SBDT.
Asian consortiums prefer a middle position combining regulatory compliance necessity with an avant-garde approach to new technologies.
Initiatives such as Project Guardian represent an important milestone not only in the creation of, but also in the connection between, different banking DLT infrastructures. In this context, a composability problem arises: a connection may be established between DLT X and DLT Y, but it does not extend to DLT Z, which must also be compatible with both.
Accordingly, a question arises about either creating some common DLT framework or a cross-chain technology that can connect them. Such cross-chain technology shouldn’t be subordinate to anyone, must have stable infrastructure and be independent, and become the main standard (like ISO 20022). But this creates censorship risk. Perhaps that’s why pilot solutions consider atomic swaps as a somewhat natural interaction method. Given that participants have tacitly chosen EVM as the main framework - there likely won’t be complications like when connecting completely different blockchains (EVM, SVM, Aptos, Algorand, etc.).
Nevertheless, messaging standard support can’t be excluded from such infrastructure for communication between banking structures - ISO 20022 and the obsoleting SWIFT MT API (SWIFT is transitioning to ISO 20022 standard). This is visible in pilot examples from various organizations in Project Guardian.
This has a dual role:
- Compatibility with traditional banking infrastructure
- Communication capability between different DLTs through traditional infrastructure without creating cross-chain frameworks requiring lengthy testing
Moreover, cross-chain frameworks may turn out to be proprietary and censorable due to dependence on specific jurisdictions. Additionally, as notable, most listed Tokenized Deposits/Deposit Tokens implementations are used either for internal infrastructure of individual commercial banks or as pilots in separate jurisdictions where different structures use one DLT technology with atomic exchange capability. In this context, communication capability between different DLT-based banking infrastructures through ISO 20022 and/or SWIFT looks like a logical solution. Especially since banks likely won’t quickly transition to new technologies, and connection with legacy infrastructure will be needed - which this can precisely provide.
For example, SWIFT has been gradually transitioning to ISO 20022 format since 2023, while DLT implementation across all banking systems may take more than one decade.
BRRR DAO
Is a team of experienced Web3 enthusiasts with diverse expertise, committed to actively participating in the evolution of the blockchain industry. Deep in our vision: Introducing ₿RRR DAO: Frontier Founders.