Guest contributors: Ashley Harris, Thomas Scott, and Isabelle Corbett Sterling, BakerHostetler
This is the final article in our three-part series focused on a key question: as bank-fintech partnerships continue to play a vital role in driving financial services, how does the industry make this system safer and better?
In this final part of our series, we propose a DLT-based account ledgering model designed to prevent failures like Synapse while offering broader benefits. Previously, we examined Synapse’s collapse, the misplaced trust in its ledgers, and potential regulatory responses,[1] including concerns about the Federal Deposit Insurance Corporation’s (FDIC) proposed recordkeeping rule (Records NPR).[2]
Our model addresses the Synapse problem, and more generally, the issues managing what we refer to as third-party ledger accounts (TPLAs). It would provide banks, service providers, and regulators with a real-time, tamper-resistant single source of truth. It would also enhance compliance and improve efficiency. Banks would always have real-time visibility into funds, eliminating end-of-day reconciliations and dependency on third-party middleware. Fintech partners would access consistent account records to support customers, and regulators could monitor deposit flows in real time, aiding liquidity management and deposit insurance determinations.[3]
Section I outlines the current ledgering system’s limitations and provides a primer on distributed ledger technology (DLT), also known as blockchain technology. Section II details the design principles of a permissioned ledgering model. Section III addresses anticipated questions associated with our model, including cost, risk, governance, and adoption challenges. Finally, Section IV explores how DLT’s benefits extend beyond preventing another Synapse-like failure.
I. Background
a. Existing account ledgering challenges
Account ledgering is complex, leading many banks to outsource it to third-party core providers. It requires meticulous classification, double-entry bookkeeping, and integration with multiple payment networks — ACH, cards, wire, and check clearing — each with varying settlement and reversal times.
This complexity grows when banks partner with fintechs that serve end-user customers. As discussed in Part 1, some banks delegate ledgering to fintechs, creating TPLAs. Synapse attempted to manage this process, but instead became a single point of failure.
We previously explained how Synapse worked with multiple partner banks, and no individual partner bank knew the total deposits managed in Synapse-related accounts. Synapse could have, for example, told a fintech that only half of its users’ deposits were at a partner bank, while at the same time told the partner bank that the deposits there represented all of that fintech’s users’ deposits. Any one bank’s understanding of end-user account balances was based entirely on the ledger reconciliation data provided by Synapse, which could be (and ultimately proved to be) inaccurate. Partner banks lacked visibility into total deposits, relying on Synapse’s potentially inaccurate reconciliations.
The FDIC’s Records NPR emphasizes recordkeeping and internal controls but assumes a simple bank-to-fintech model. It fails to address transparency issues when fintech intermediaries aggregate multiple bank partnerships. Instead of solving reconciliation challenges, the NPR merely dictates when and how reconciliation must occur. As a result, it fails to address the systemic vulnerability exposed by the Synapse failure.
b. What is DLT?
Our proposal assumes a basic understanding of DLT, a system for recording and synchronizing data across multiple locations rather than relying on a centralized database.[4][BA1] While first popularized by Bitcoin and other cryptocurrencies, DLT has broader applications for transaction and information management.
Bitcoin addressed the double spend problem without needing a trusted party to maintain the ledger. In traditional electronic transactions, banks serve this role — i.e., verifying funds before completing purchases and transfers.
With DLT, typically every network participant maintains a copy of the ledger, ensuring consistency through a consensus mechanism. The key innovation of DLT is the way it ensures that each copy of the ledger remains identical to all the others. The decentralized structure improves security and transparency by distributing the information across multiple nodes, which store, validate, and propagate transactions.
The consensus mechanism is the programming and process used to resolve conflicts among copies of the ledger and obtain agreement on the correct data. Once an entry is added to the ledger through the consensus mechanism, it cannot be changed. This feature makes a DLT ledger highly resistant to tampering and errors. As a result, participants can trust the ledger’s accuracy without relying solely on another party’s records.
c. Key DLT Concepts and Terms
Permissionless vs. Permissioned
Distributed ledgers known as blockchains batch transactions into blocks, with each block linked to the previous one, creating a secure, transparent chain. There are two main types: permissionless and permissioned.
Permissionless blockchains (e.g., Ethereum, Bitcoin), also referred to as public blockchains, are open to anyone, allowing unrestricted participation and decentralization, with security ensured by cryptographic algorithms and consensus mechanisms like Proof of Work or Proof of Stake.
Permissioned blockchains are controlled by a central authority that pre-selects validators and limits participation. These are more centralized and allow on-chain data to remain non-public, making them better suited for use as account ledgering solutions for banks.
Tokenized Deposits
Tokenized deposits are digital representations of bank deposits recorded on a blockchain. While tokenized deposits can support various use cases, such as cross-border payments or linking the trading and settlement of assets, in the DLT account ledgering model, tokenized deposits play a relatively simple recordkeeping function. To work, deposit tokens would be “minted” (i.e., created under the rules of the blockchain) by the participating bank.[5] In essence, tokenized deposits ensure that the amounts on the DLT ledger represent actual deposits at the bank.[6]
Smart Contracts
Smart contracts are automated programs built on top of the architecture of a particular blockchain; they are written into a decentralized application (or dApp). They are typically programmed to execute a series of actions once a specific trigger occurs. A smart contract can be as simple as a command to transfer funds on a particular date, but often these contracts are designed to complete a complex series of transactions among multiple parties.
The distinguishing feature of smart contracts is that they are immutably written to the blockchain or dApp. Therefore, no unpermissioned person can change or interfere with the execution of a smart contract, unless that capability is preprogrammed into the smart contract itself (as discussed below in III.c.). Overriding or disabling a smart contract requires consensus from the network, just as with writing new transactions. Smart contracts are powerful features of DLT, but there is potential for malicious actors to abuse smart contracts in permissionless blockchains.[7]
Regulatory Nodes
Permissioned blockchains may enable the central authority to create read-only “observer nodes” that do not process transactions or participate in consensus. These nodes can, through a Merkle tree cryptographic approach, be customized to restrict data access based on fields such as transaction type, customer type, date, location, or other criteria.
Banks using DLT ledgers could grant regulators observer nodes tailored to their jurisdiction, ensuring access only to relevant data within defined parameters. This approach enhances oversight while maintaining data privacy and control.
Privacy Considerations
The benefits of speed, transparency, and accuracy in a DLT account ledger would be meaningless without robust protection of customer privacy. We must avoid creating a single point of failure where a breach could expose millions of transactions and accounts.
In traditional finance, privacy is safeguarded by controlled access to sensitive information. In DLT, data encryption is key. Even if unauthorized access occurs, encrypted data would remain unreadable and secure. Advanced cryptographic techniques in DLT can offer a level of privacy that surpasses current financial services standards.
II. DLT Account Ledgering Model
Below are the design principles that would form the foundation of a DLT account ledgering model.[8] This model could be used for fintech partnerships or any arrangement with TPLAs.
a. Permissioned Access
A permissioned blockchain is best suited for an account ledger, balancing DLT’s benefits with regulatory compliance, privacy, and control. While public blockchains have advantages in other contexts, limiting access to authorized entities helps ensure compliance, privacy, and operational control.
Role-based access control would restrict transaction visibility and updates to approved users. Advanced privacy features, including encryption and selective sharing, would protect sensitive data. One-time keys would further safeguard confidentiality, preventing banks from exposing all transaction information in real time to other banks on the network.
b. Smart Contract Controls
Smart contracts will be a critical component of the model, for example, to mint, burn (i.e., remove from the system), and transfer tokenized deposits. Although we propose a permissioned blockchain, every smart contract implemented must still undergo rigorous testing and validation to ensure reliability and security. It will be especially important to include mechanisms for updating or canceling smart contracts, including identifying which participants are authorized to initiate such changes.
c. Interoperability and Composability
The model DLT ledger must be able to integrate with legacy banking systems and other platforms to enable seamless data and asset exchange. Many financial institutions still rely on outdated systems; the DLT ledger could use application programming interfaces (APIs) for communication, with a focus on data standardization and transformation tools.
The ledger would focus on interoperability, allowing different blockchains to exchange data and interact effectively. While there are solutions that provide bridges between particular chains, the model DLT ledger should be built on standards to facilitate cross-chain communication.
Composability, or the ability of blockchain elements like smart contracts and applications to work together, is also key. Designing the DLT system with composability in mind ensures flexibility and adaptability as needs evolve.
d. Scalability and Efficiency
A DLT account ledgering model for high-volume bank deposits must emphasize speed and efficiency. This can be achieved by optimizing consensus mechanisms, simplifying node structures, implementing data pruning, and reducing storage requirements.
In a permissioned blockchain, efficiency improves by limiting data replication and sharing transaction details only with relevant parties. This approach speeds up processing and reduces node size, as consensus does not require every node’s participation in each transaction.
e. Defining the Role of a Private Sector Central Authority
A central authority, which could be a private consortium or other committee structure, is critical to risk management and governance in a permissioned blockchain. It should be representative of its key users — i.e., the banks — and operate under a governing document outlining its structure and responsibilities.
This authority would permission (authorize) entities on the blockchain, ensuring they meet organizational and technical standards. It would also: (i) identify and implement security controls; (ii) approve changes to administer key smart contracts; (iii) oversee the functioning of the blockchain, fixing bugs, troubleshooting, and approving or rejecting updates to the blockchain; and (iv) contract and coordinate with service providers to assist with these functions. While some tasks may be outsourced, a single trusted entity must remain accountable.
Advisory committees could include representatives from participating banks, ensuring broader input. Each bank would sign a participation agreement, adopted by the central authority with member input.
III. Anticipated Questions
a. Costs
Investing in new technology, collaboration across banks, and negotiating an entirely new governance model will require significant time and money. We recognize this challenge, especially because the benefits of using DLT for this purpose may not be immediately evident. Regulatory skepticism about blockchain could also raise perceived costs. Therefore, it is crucial that regulators understand DLT’s potential and encourage the development of DLT account ledgers, among other efforts. This could include exploring public-private partnerships, issuing guidance and policy statements, and sponsoring interagency tech sprints focused on DLT’s application to recordkeeping.
b. Risk Management
A permissioned blockchain enhances security by restricting public access. Due diligence, third-party oversight, and Bank Secrecy Act compliance would occur off-chain. Initially, transactions would settle via standard card and ACH procedures, with the DLT ledger serving as a secondary “shadow” ledger, in keeping with the “backup recordkeeping” requirements in the Records NPR requirements. This approach allows for error detection and correction before full reliance on DLT.
c. Reversibility of Transactions
Immutability is a key feature of DLT, ensuring data cannot be altered or deleted once recorded. While it enhances security and trust, it also poses risks when errors or fraud occur. In private, permissioned blockchains, governing bodies can mitigate these risks by establishing rules for handling erroneous or unauthorized transactions. For example, the governing body might implement protocols for appending corrective transactions to the ledger, thereby preserving the integrity of the chain while ensuring errors are addressed transparently. This approach would maintain the benefits of immutability while providing a practical mechanism for managing exceptions. Alternatively, the smart contracts themselves could include optional settings allowing the central authority under certain circumstances to pull back or reverse transactions done in error or determined to be fraudulent.[9]
d. Building Toward Broader Adoption
To fully leverage DLT, a DLT account ledger could eventually replace current recordkeeping methods as the authoritative transaction record. Banks could adopt it gradually, starting with a “shadow ledger” for contingency planning. In this phase, deposits would not be tokenized, and DLT would serve as a synchronized secondary ledger, offering benefits like near real-time deposit visibility, enhanced regulatory transparency, and greater resilience against data loss.
As adoption progresses, tokenizing deposits would unlock DLT’s full potential, ensuring real-time consistency between records and activities. This phased adoption could begin within each bank, allowing each institution to build confidence, appropriate risk management, and expertise with DLT. Once established, DLT could then be extended to interbank transactions, starting with a limited set of activities. Initiatives like the Regulated Liability Network (RLN) are already testing this concept in the United States.
e. Regulatory Acceptance
The United States is increasingly focused on enhancing its leadership in digital financial technology. On January 23, 2025, the White House issued an executive order supporting the responsible growth and use of digital assets and blockchain technology.[10] “Digital asset” refers to any digital representation of value that is recorded on a distributed ledger.
Federal banking agency representatives have also weighed in. Governor Waller of the Federal Reserve Board recently noted:
. . . DLT may be an efficient and faster way to do record keeping in a 24/7 trading world . . . Undertaking the process to tokenize assets and use distributed ledgers like blockchain can speed up the transfers of assets and take advantage of another innovation: smart contracts.[11]
DLT offers regulators valuable tools for accessing critical information. Initially, regulators and banks could implement DLT through a low-risk shadow system to gradually build familiarity. However, without regulatory encouragement, the adoption of this promising technology is likely to stall. Historically, regulatory hesitancy about DLT has slowed progress, which has discouraged banks from moving forward. While banks have been consulting with regulators and experimenting safely with permissioned DLT for several years, some banks may no longer require a written supervisory non-objection for deploying it.[12][13]
To advance adoption, we recommend that regulators establish an interagency working group to explore the potential of the DLT Account Ledgering model. This topic could, at the appropriate time, also form part of a reinvigorated FDiTech tech sprint.[14] Such a structure would benefit from insights from the private sector, including from banks piloting DLT solutions and the USDF Consortium.[15]
IV. DLT Account Ledgering Benefits Beyond Fintech Partnerships
There are at least two additional advantages with a DLT account ledgering system: reduced compliance costs for banks and visibility into real time deposit-flow data for bank supervisors.
a. Reduced Compliance Costs
Under FDIC Part 370, the largest U.S. banks must configure their IT systems to calculate insured and uninsured deposit amounts by ownership type and maintain accurate records to ensure swift access to insured funds in a bank failure. Compliance is costly and complex, as demonstrated by the fact that there is an entire section of Part 370 and accompanying FDIC “Guidelines for Relief” dedicated to describing the procedures for covered institutions to follow when submitting requests for relief from the rule.[16]
A DLT-based account ledgering model could reduce compliance costs by eliminating annual reporting requirements. Currently, covered banks must certify compliance and submit deposit insurance reports each year. This certification is required to, among other things, confirm that the bank has tested its IT system and summarize the number of deposit accounts, number of different account holders, and dollar amount of deposits by ownership right and capacity code (as described in Part 370’s Appendix A).[17]
A DLT ledger with an API could provide real-time deposit data at the level of granularity required by Part 370, enabling continuous supervision and eliminating the need for manual testing. The DLT-enabled API could be configured to provide real-time end-user balances across multiple partner banks. Over time, this capability would moot the need for manual-based periodic testing of a bank’s compliance with the rule, promoting lower cost and “real time” supervision. This approach would embed compliance into the ledgering system, allowing banks to meet reporting obligations more efficiently, reducing costs, and minimizing the risk of penalties.
b. Real Time Deposit Data
Regulators still do not appear to have access to real-time deposit data, including in a bank failure. While the Federal Reserve’s access to confidential, high-frequency interbank payments data allows the Fed to retroactively trace deposit flows through Fedwire and ACH,[18] this data – at least as of July 2024 – was unavailable for purposes of tracking deposit movements in real time.[19] This information gap was made plain by Acting Chairman Travis Hill of the FDIC, who stated:
[After March 12, 2023], I asked officials at the Federal Reserve whether this type of data was available to see deposit movements, and I was told it was not. It would be very helpful if the Federal Reserve can find a way to make this data available in real time for key decision-makers, along with capabilities to rapidly analyze it. Among other benefits, better visibility into real-time deposit movements across the system could significantly improve our ability to monitor for runs and contagion, and reduce the risk of unnecessarily invoking the system risk exception (and vice versa).
Regulators using observer nodes could gain several advantages. Access to the DLT ledger would enable earlier detection of issues, such as unusual deposit flows. With real-time data, regulators could also build new tools to monitor broader system-wide trends, enhancing their ability to proactively address emerging risks.
Conclusion
2025 has marked a new era of openness by regulators towards blockchain technology. At the same time, it is nearly one year after the bankruptcy of Synapse, and we still do not have a satisfactory response (regulatory or otherwise) to adequately address the risks that could prevent the next Synapse-like failure.
While there are varied ways to address these risks, we invite regulators to consider our proposed DLT account ledgering model and explore how it could strengthen bank-fintech partnerships, consumer protection, regulatory compliance, and safety and soundness. This effort could help further propel innovation for banks and fintechs.
[1] Part 1 of our series is here; Part 2 is here.
[2] Recordkeeping for Custodial Accounts, 89 Fed. Reg. 80135 (proposed Oct. 2, 2024) (to be codified at 12 CFR pt. 375).
[3] See Travis Hill, Vice Chairman, FDIC, Recent Bank Failures and the Path Ahead, Speech at the Bipartisan Policy Center (Apr. 12, 2023) (available at https://www.fdic.gov/news/speeches/2023/spapr1223.html) (“In 2020, the FDIC initiated a ‘Rapid Phased Prototyping’ competition to develop technologies to provide the FDIC with more granular and frequent data from banks that chose to participate. This type of tool not only could help expedite populating a data room for a failed bank, it also would give the FDIC access to much higher quality data to monitor broader trends, such as deposit flows in times of stress. Unfortunately, this project was discontinued.”)
[4] Much of the discussion of DLT in this article is necessarily simplified. For more detailed information, we recommend reading: U.S. Gov’t Accountability Off., GAO-19-704SP, Blockchain & Distributed Ledger Technologies (2019), https://www.gao.gov/assets/gao-19-704sp.pdf.
[5] See, e.g., Regulated Liability Network U.S., Business Applicability Report 17 (2023), https://www.rlnuspoc.org/home#subpage/introduction/overlay/203321984 (discussing minting of deposit tokens in the domestic interbank payments design context).
[6] Tokenized deposits are different from “stablecoins,” which circulate as digital bearer instruments and therefore may lend themselves to alternative models alongside or even outside the traditional banking system. See generally Garratt & Shin, “Stablecoins versus tokenized deposits: implications for the singleness of money,” BIS Bulletin, No. 73, 11 April 2023 (available here).
[7] Dikla Barda et al.,Unveiling the Scam: How Fraudsters Abuse Legitimate Blockchain Protocols to Steal Your Cryptocurrency Wallet, Check Point Research (July 23, 2024), https://research.checkpoint.com/2024/unveiling-the-scam-how-fraudsters-abuse-legitimate-blockchain-protocols-to-steal-your-cryptocurrency-wallet/; How to Spot a Scam in Smart Contract Functions?, Coinbase, https://www.coinbase.com/learn/tips-and-tutorials/how-to-spot-a-scam-in-smart-contract-functions (last visited Apr. 1, 2025).
[8] DLT-based solutions have been shown to work across varying use cases. One prominent example is the Spunta Case Study in Italy. See Project Leonidas: R3 is Delighted to be Joining Forces with ABI Lab, ABI and NTT Data Italia to Revolutionize Italy’s Financial Landscape, R3 (May 26, 2023), https://r3.com/project-leonidas-r3-is-delighted-to-be-joining-forces-with-abi-lab-abi-and-ntt-data-italia-to-revolutionize-italys-financial-landscape/. When reconciling interbank transactions, Italian banks were facing many of the same issues that currently plague the banking as a service ecosystem: inconsistencies, a lack of transparency, and a lack of standardization. Compounding these concerns were fragmented communication, which led to transaction mismatches that were labor- and time-intensive to resolve. The DLT-based solution, Spunta Banca DLT, is a private permissioned DLT-based project developed for interbank reconciliation. SIA, a national interbank network, provides the network infrastructure through its SIAchain network. Each Italian bank has a node on the SIAchain network. Corda Enterprise from R3 serves as the blockchain powering Spunta Banca DLT, streamlining and automating the reconciliation of transactions. Through the application, banks can share data securely, use standardized processes and a single communication channel, and have visibility into transaction information. The Corda platform’s design includes a key feature that allows the platform to segregate data on the distributed ledger and control information access. This feature allows sensitive information, including personal data, to be kept confidential, facilitating compliance with local General Data Protection Regulation requirements.
[9] Cf. How Stellar works: a quick, non-technical guide,” p. 7 (describing the Stellar network’s clawback mechanism) available here: https://resources.stellar.org/hubfs/Proof%20of%20Agreement%20explainer.pdf
[10] The White House, Strengthening American Leadership in Digital Financial Technology (Jan. 23, 2025), https://www.whitehouse.gov/presidential-actions/2025/01/strengthening-american-leadership-in-digital-financial-technology/.
[11] Governor Christopher J. Waller, Centralized and Decentralized Finance: Substitutes or Complements?, Speech at the Vienna Macroeconomics Workshop, Institute of Advanced Studies, Vienna, Austria (Oct. 18, 2024) (available at https://www.federalreserve.gov/newsevents/speech/waller20241018a.htm).
[12] See, e.g., Matthew Bornfreund et al.,OCC Clarifies Bank Authority to Engage in Certain Cryptocurrency Activities, Troutman Pepper Locke: Fin. Servs. Blog (Mar. 12, 2025), https://www.troutmanfinancialservices.com/2025/03/occ-clarifies-bank-authority-to-engage-in-certain-cryptocurrency-activities/.
[13] See id.; see also Letter from the American Bankers Association to David Sacks, Special Advisor for A.I. & Crypto (Feb. 20, 2025) (available at https://bpi.com/wp-content/uploads/2025/02/Digital-Assets-Letter-to-PWG-on-Digital-Assets-2-20-25vfinal.pdf).
[14] Travis Hill, Vice Chairman, FDIC, Charting a New Course: Preliminary Thoughts on FDIC Policy Issues, Speech (Jan. 10, 2025) (available at https://www.fdic.gov/news/speeches/2025/charting-new-course-preliminary-thoughts-fdic-policy-issues) (“Another step is reinvigorating the innovation lab, FDiTech, which was established by Chairman McWilliams to directly engage with the private sector, examine the challenges banks face with technology adoption, and help develop solutions.”).
[15] See USDF Consortium,https://usdfconsortium.com/ (last visited Apr. 1, 2025).
[16] See e.g., Letter from Phoebe Papageorgiou, Vice President, Am. Bankers Ass’n, & Robert Strand, Vice President & Senior Economist, Am. Bankers Ass’n, to John P. Conneely, Dir. Div. Complex Inst. Supervision & Resol., FDIC (Sep. 16, 2021) (available at https://www.aba.com/advocacy/policy-analysis/letter-to-fdic-on-part-370-compliance) (noting major challenges faced by all covered institutions regarding obtaining complete information for certain types of accounts); The Final Say: Preparing for the FDIC’s Final Deposit Insurance Recordkeeping Requirements, KPMG: Regulatory Points of View 5 (June 2018), https://assets.kpmg.com/content/dam/kpmg/us/pdf/2018/06/the-final-say.pdf (noting Part 370 compliance difficulties associated with “compiling, aggregating, and reconciling across existing and new customer accounts . . . multiple deposit products, and mismatched unique customer identifiers across systems”).
[17] These certifications detail, for example, the total number of fully-insured deposit accounts and the total dollar amount of deposits in all such accounts; the total number of deposit accounts with uninsured deposits and the total dollar amount of uninsured amounts in all of those accounts; and by deposit account type, the total number of, and dollar amount of deposits in, deposit accounts for which the covered institution’s information technology system cannot calculate deposit insurance coverage using information currently maintained in the covered institution’s deposit account records. See 12 CFR § 370.10.
[18] See Marco Cipriani et al., Tracing Bank Runs in Real Time, Fed. Rsrv. Bank of N.Y. (May 2024) (available at https://www.newyorkfed.org/medialibrary/media/research/staff_reports/sr1104.pdf) (relying, in part, on interbank payments data and concluding that runs in March 2023 were driven by a small number of large depositors and were related to weak balance-sheet characteristics).
[19] See Travis Hill, Vice Chairman, FDIC, Reflections on Bank Regulatory and Resolution Issues, Speech (July 24, 2024) (available at https://www.fdic.gov/news/speeches/2024/reflections-bank-regulatory-and-resolution-issues#footnote27).