What do building skyscrapers in New York City and building new financial rails on DLT have in common? This was an analogy put forward at an industry event I recently attended, and it works rather well. Let’s look at the construction of  4 World Trade Center in New York City, which happens to be our headquarters. 

This timeline illustrates a truth for many ambitious projects: the foundation is critical but time-intensive. Value and differentiation follow at the later stages and happen rapidly if the foundation is sound. But its success isn’t a function of the building alone. It sits squarely in lower Manhattan, embedding itself in the heart of the financial district, thus being able to offer its tenants connectivity and access to the rest of the city’s businesses. 

To build a sound foundation that supports the rapid value generation at the end, the architects and project planners will have considered almost all the details of the finished building, from location and surroundings to cables, pipes, and surface finishes, before even starting to dig the hole for the foundation. 

This is a mindset we must apply to DLT adoption. Given the context of existing financial systems that any IT innovation needs to embed into, laying the foundation of new financial rails is akin to digging a hole for four years. Such investment is only justifiable if there’s a robust plan in place for the equivalents of the location and ecosystem, the superstructure, and the finish that deliver bottom-line value to the tenants. Each and every DLT project should be undertaken with a view towards a network vision - in most cases a public network vision - to generate value. What does the finished building offer in the context of the city? Everything across use cases, integrations, partnerships, tech choices, and network/ecosystem needs to be thought through to not get stuck with a foundation that doesn’t support a finished building, or a building that nobody wants to move into. Without thinking these matters through, it’s far too easy to end up here:

I’ve seen a number of ambitious DLT projects both from the outside, and the inside over the last few years, and see a clear common trajectory. More often than not, a financial institution’s DLT adoption journey can be broken down into four distinct stages that build on top of each other. Unfortunately, I’ve also seen projects get stuck or falter half way through because they didn’t think through their path to the end goal clearly and made choices early that blocked further progress.

Stage 1: Recreating the Status Quo

A common first stage of adopting DLT is a tech switchout: replicating existing functionality on new technology. This can unlock some value in the way any tech modernization project can, but bystanders often scratch their heads, thinking, “Why did they use a blockchain for this?!”

This stage is akin to laying the foundation of a building. It’s a necessary, but often arduous and unglamorous, process. Unless they know the plans for the glamorous skyscraper that’s going to go up later, digging a giant hole makes no sense to bystanders. 

For example, let’s consider a legacy repo system in which banks currently instruct trades by sending FIX messages. In transitioning to DLT, the first step might involve building a centralized, single-provider DLT network that mirrors the functionality of the legacy system. Stakeholders interact with this new system in the same way they did before, using FIX messages or APIs. Without a few towards the later stages, the application of DLT is practically invisible.

Stage 2: New Integrations and Value via APIs

Once the foundation is laid, the focus shifts to building the superstructure—beginning to introduce new functionality and business models. In this stage, institutions might also start to experiment with connecting their DLT systems to others through APIs or bridges. Such bridges are essentially traditional message-based integrations. They do nothing that traditional systems couldn’t do, but serve to prove out the business cases for integrating lower down in the stack.

For example, the DLT-based repo system may integrate via APIs with innovative payment rails that also run on DLT.

This approach follows standard IT, legal, and operational practices so it’s a quick and easy way to try something new. It also doesn’t require the payment provider and DLT platform provider to have planned this from the beginning and chosen the same DLT rails. But the blockchain itself still remains hidden behind application level APIs to any external parties. Interactions are still mediated through traditional interfaces, and the unique capabilities of DLT, such as real-time synchronization and on-chain connectivity, are not leveraged.

Even more importantly though, anything up to this stage can still be accomplished using traditional technologies. And indeed it doesn’t matter at all which DLT technologies either the repo platform or payments provider use. Any properties the ledger technology lacks - be that privacy or access controls to the apps, for example. - can be added on at the API layer. 

This stage can prove the value and validity of new business models, and deliver new capabilities and new integrations across the market. But PoCs, pilots, or even production systems at this stage do not provide any profound and hard evidence of the value DLT can deliver, or prove the the applicability or lack thereof of any particular blockchain technology.

Stage 3: Open Networks

The third stage marks a significant shift: opening and distributing the DLT network and allowing stakeholders to participate directly on the DLT rails. This involves giving participants cryptographic access to the network or even allowing them to run their own nodes. At this point, the unique properties of DLT—such as real-time synchronization, decentralized validation, and the removal of reconciliation—begin to play out.

For instance, consider the same aforementioned repo system from stage 1. Instead of relying solely on message-based integrations, the system might allow participants to validate and store data directly on the blockchain. This creates a shared, synchronized ledger where transactions are automatically verified and recorded in real-time. The need for reconciliation is eliminated, reducing costs and operational risks.

It’s at this stage that the properties of the underlying DLT start coming into focus. The most common challenges that prevent use cases from entering stage 3 are privacy and controls.  Without privacy at the blockchain level, the operator of the platform risks exposing sensitive data to others on the network. In the repo example, without privacy features on-chain, any dealer that can read blocks can read all trades of every other dealer. That’s not acceptable. Also, the operator needs to retain controls to the extent the regulator requires - most likely to unilaterally and independently override the rules of the repo platform if and when required to do so. Any technology that follows a “code is law” mantra and doesn’t allow the operator to exert full control over the state and code is unlikely to be compliant. Fully transparent public permissionless blockchains or fully replicated private permissioned blockchains like private Ethereum often struggle to provide these properties, and projects in traditional regulated finance space built on such technologies struggle to progress to this stage.

Stage 4: Interconnectivity and Ecosystem Integration

The final stage of DLT adoption is where the true value of the technology is unlocked: on-chain interconnectivity and ecosystem integration across apps. This level of integration enables entirely new business models and forms of collaboration. For example, the DLT-based repo system and payments system from stage 2 above may now integrate on-ledger, allowing participants to conduct atomic transactions—simultaneously settling payments and securities in a single, synchronized operation. This kind of integration removes partial settlement risk and allows shifting to 24x7 real-time markets. 

At this stage, the network effects become the primary value drivers. As more participants and applications join the ecosystem, the benefits of connectivity and collaboration grow exponentially.

Getting here requires the whole plan to come together. Most importantly, the ecosystem to connect to needs to be there on the same DLT network and the technology needs to support connectivity. The former is a matter of partnering early, in stages 2 or even before, to work together across multiple institutions to build value chains on the same rails - building neighborhoods in our city analogy or building unified ledgers in the terms of BIS’s Finternet paper. And these neighborhoods need to be part of an open and public network to thrive and interconnect further.

The technology supporting such connectivity and openness requires having the forethought in planning to think through what’s needed for stage 4 and having chosen the right stack. I believe three primary properties are needed:

1. 1. Privacy and confidentiality within and across apps and assets. It must be possible to do a swap between a bond and cash, for example, without the cash provider and bond registry finding out about the other side of the settlement.
   2. Independent controls and dynamic consensus. A central bank bringing cash on ledger must be in full control of transactions affecting only central bank money. A CSD must be in full control of a bond movement. Yet they need mutual consensus in the context of a swap. So consensus needs to be dynamic on a transaction-by-transaction basis.
   3. The fidelity and security of on-ledger interoperability must be at the level of typical smart contract chains like Ethereum and Solana where value generation and innovative business through on-chain connectivity is evident.

Choosing an ecosystem that does not allow for open public networks, does not include the right counterparties, or choosing a technology that does not allow for 1-3 above will prevent organizations from realizing network value using blockchain technology.

Building for the Future

The journey of DLT adoption is not unlike the construction of a skyscraper targeting financial businesses. It begins with significant planning, choosing the right location in the right city, and a solid foundation. It progresses through incremental stages of development and ultimately culminates in a fully realized structure that transforms the landscape. However, just as a building must be designed with its final form in mind, so too must DLT projects be planned with a clear vision of their end goal.

Institutions that focus solely on the early stages of adoption risk building costly systems that fail to deliver long-term value. By contrast, those who embrace the full potential of DLT—planning around a network use case and choosing a network that can support it from the outset—can unlock transformative benefits and create new opportunities for innovation.

Successful transformation of finance using DLT depends on the ability to move beyond foundational experiments and into fully integrated ecosystems. By understanding the four stages of innovation and committing to the journey, institutions can build for today and the future.

Let’s build this:

Not this: