How Can Distributed Ledger Technology Be Used in Traditional Financial Markets?

Why DLT in Traditional Financial Markets?

Blockchain and distributed ledger technology (DLT) are often associated with cryptocurrencies. When people think of blockchain, they usually think of a public network where transactions are shared across participants without a central authority controlling the entire system.

But DLT doesn’t have to work that way.

Traditional financial markets have different requirements. Participants need to know who they are dealing with, transaction details must remain confidential, and processes must meet regulatory and operational requirements.

At first, these requirements might seem to go against the idea of a distributed ledger. But a permissioned DLT network can restrict who participates and which parties can see a transaction.

I became interested in this while working on an application connected to FX swap booking. I wanted to understand how the technology behind the platform worked and why it made sense in a traditional banking environment.

One technology that stood out was Corda.

What Is Corda?

Corda is a permissioned distributed ledger technology platform designed for business transactions, including those in financial services.

The important distinction is how it shares information. Unlike a typical public blockchain, Corda doesn’t broadcast every transaction to every participant on the network. Transaction information is shared with the parties that need it.

For example, if two banks transact with each other, they need to agree on the transaction details and maintain records of what they agreed to. Other banks on the network don’t necessarily need access to that transaction.

Corda allows the relevant parties to exchange and verify transaction information while keeping it private from unrelated participants.

Each participant is represented by a node on the network. These nodes communicate with each other to agree on transactions and maintain their respective records.

This is the basic idea behind Corda: participants can maintain verifiable records of shared transactions without every participant having access to the entire network’s transaction history.

The Components Involved

There are a few important components to understand before looking at how a transaction works.

Participants and Nodes

Participants are the organisations conducting business on the network, such as banks or other financial institutions.

A node is the instance of Corda that runs on behalf of a participant. It runs the relevant business applications, communicates with other nodes and stores the transaction information relevant to that participant.

In a typical setup, each participating organisation operates its own node, although the exact deployment can vary.

CorDapps: The Business Applications

A CorDapp is a Corda application that implements the business logic for a particular use case.

Three important building blocks of a CorDapp are states, contracts and flows.

States represent facts recorded on the ledger. A state could represent the terms of a trade or its current status.

States are immutable. If something changes, the existing state isn’t edited in place. Instead, a transaction consumes the existing state and creates a new one representing the updated information.

Contracts define the rules that a transaction must satisfy. For example, a contract can validate whether a proposed transaction follows the permitted rules for updating a trade’s state.

These rules are enforced by code. They help ensure that ledger updates follow the intended business logic, but they don’t automatically guarantee compliance with every applicable regulation.

Flows coordinate the interactions between participants. They define the steps required to complete a business process, such as exchanging a transaction proposal, obtaining the required signatures and finalising the transaction.

Together, these components allow a business process to be implemented on the network.

The Notary

The notary is one of the key components of Corda.

Its main responsibility is to prevent conflicting transactions from consuming the same input state more than once.

Consider a simplified example. Suppose a state represents an asset owned by a participant. That participant shouldn’t be able to use the same state in two different transactions to transfer the asset twice.

Before a transaction consuming that state can be finalised, the notary checks whether the state has already been consumed. If it has, the conflicting transaction is rejected.

This is called uniqueness consensus.

The notary isn’t a central database containing every participant’s complete transaction history. Its primary role is to establish transaction uniqueness, not to act as the source of truth for every business fact.

Network Membership and Identity

A permissioned network needs a way to identify participants and control who can join it.

Corda uses network identity and membership mechanisms to establish recognised participants. This allows nodes to communicate with known counterparties rather than relying on anonymous participants.

The admission process depends on the network’s governance and configuration.

The Corda Firewall

In some Corda Enterprise deployments, the Corda Firewall provides an additional layer of network isolation.

It helps manage communication between the node and external connections, reducing the need to expose the node’s internal infrastructure directly.

The firewall is a deployment-specific component, not something that must be present in every Corda deployment.

The Facilitating Platform

Depending on the use case, there may also be a business platform or operator facilitating the transaction process.

For example, a trading platform might provide the interface through which participants initiate trades and manage the workflow.

This is separate from Corda’s core components. Corda provides the distributed ledger and transaction mechanisms; the surrounding platform implements the business process in which they are used.

How Do These Components Work Together?

Consider a simplified transaction between two banks.

Initiation: One bank initiates a transaction through its application. A flow starts coordinating the process.
Validation: The relevant nodes receive the transaction information and check that it satisfies the applicable contract rules.
Agreement: The required parties provide their digital signatures, indicating their approval of the transaction.
Notarisation: The transaction is submitted to the notary, which checks that the input states haven’t already been consumed.
Finalisation: Once the required checks and signatures are complete, the transaction is finalised and recorded by the relevant participants.

The participants end up with records of the agreed transaction, while unrelated participants don’t automatically receive all its details.

This is how Corda combines transaction verification, controlled information sharing and a mechanism for preventing conflicting updates.

How Does This Fit Into Traditional Trading?

So, what makes this useful in a traditional financial environment?

First, participation is controlled. Institutions can interact with recognised counterparties instead of allowing arbitrary participants to join the network.

Second, transactions aren’t shared with everyone by default. Banks can exchange the information required for a trade without exposing all their transaction details to other participants.

Third, the transaction history is verifiable. Participants can validate the transaction rules and required signatures and check that the relevant updates were recorded correctly.

These features can also help reduce operational work.

In a traditional setup, different institutions may maintain separate records of the same transaction and exchange messages to confirm that their records agree. Differences between those records can lead to reconciliation work and delays.

With a shared transaction process, some of this work can be reduced because the relevant parties follow a common mechanism for agreeing on and recording changes.

That doesn’t mean reconciliation disappears entirely or that DLT automatically makes every transaction faster. The outcome depends on the process, its integration with existing systems and how exceptions are handled.

It’s also important to distinguish between recording a transaction and settling it.

A DLT platform might coordinate the trade and record the agreed terms, while the actual movement of money still takes place through existing payment or settlement infrastructure. These systems may be integrated, but they serve different purposes.

Finally, permissioning and transaction validation can support a regulated workflow, but they don’t make an application compliant by themselves. Institutions still need the appropriate legal, regulatory, risk and operational controls.

Conclusion

I find it interesting that a technology often associated with crypto can also be used to coordinate transactions between traditional financial institutions.

What matters isn’t simply that the ledger is distributed. It’s how the system handles identity, privacy, transaction validation and agreement between participants.

Corda offers one approach to this problem. It allows relevant parties to maintain verifiable transaction records while controlling which information is shared and preventing conflicting updates to the ledger.

Of course, DLT isn’t necessarily the best solution for every problem. If a single trusted organisation can manage a database and provide the required interfaces to everyone else, a traditional centralised system may be simpler.

DLT becomes interesting when multiple organisations need to agree on shared transactions while retaining control over their own systems and data.

For me, that’s the real value of this technology in traditional financial markets. It’s less about bringing crypto into banking and more about finding a better way for institutions to coordinate business processes.