Category: Virtual Assets and Technology

Distributed Ledger Technology

Also known as: DLT, distributed ledger, shared ledger, distributed ledger technologies

Simply put

Distributed Ledger Technology (DLT) is a way of recording and sharing data across many computers in different locations at the same time, rather than keeping it in a single central database. Each participant holds a copy of the records, and those copies are kept synchronized as new information is added. This approach is generally described as decentralized and is intended to support the security and integrity of the shared data.

Formal definition

Distributed Ledger Technology (DLT) refers to the protocols and supporting infrastructure that allow computers in different locations to record, share, and synchronize a common set of digital data across multiple participants, without reliance on a single central authority. In a typical implementation, each participant maintains a replicated and synchronized copy of the ledger, with updates propagated across nodes so that copies remain consistent. DLT is a general category of architecture rather than a single product or standard, and specific implementations vary in their governance, access permissions (for example, permissioned versus permissionless designs), and consensus mechanisms; blockchain is one form of DLT. Within financial services, DLT is the subject of ongoing research and development, and its adoption, configuration, and associated risk and compliance implications depend on the particular deployment. This entry describes the technology in general terms and is not a legal or regulatory definition.

Why it matters

Distributed Ledger Technology matters to financial crime professionals because it changes where and how transactional and ownership records are held. Traditional AML controls have generally been built around centralized intermediaries and central databases, where a single institution controls the records and serves as a natural point for customer due diligence, monitoring, and record-keeping. DLT distributes those records across multiple participants, which can alter the assumptions underlying established compliance architectures and require compliance teams to consider how detection, deterrence, and record integrity are achieved in a decentralized environment.

The compliance implications are not uniform, because DLT is a general category of architecture rather than a single product. As the definition notes, implementations vary in their governance, access permissions, and consensus mechanisms, with permissioned and permissionless designs presenting different visibility and control characteristics. A permissioned deployment among known participants raises different risk and oversight questions than a permissionless one open to unidentified parties. For this reason, the risk and compliance implications of any given DLT deployment depend on its specific configuration, and firms should assess each deployment on its own terms rather than treating DLT as a single category of risk.

DLT is also relevant because, as industry sources indicate, it is developing at pace across the financial services industry, moving from speculation toward concrete research and development. This means compliance functions may increasingly encounter DLT-based systems in payments, settlement, and record-keeping contexts. Understanding the technology in general terms helps professionals ask the right questions about how AML obligations are met in a particular implementation, without assuming that any single architectural feature either eliminates or automatically creates financial crime risk.

Who it's relevant to

Compliance officers and MLROs

Those responsible for AML programs need to understand how due diligence, transaction monitoring, and record-keeping obligations are satisfied when records are held across a distributed network rather than a central database. Because compliance implications depend on the specific deployment, they should evaluate governance, access permissions, and consensus arrangements on a case-by-case basis rather than assuming a single set of controls applies.

Financial intelligence and transaction analysts

Analysts examining flows that touch DLT-based systems need familiarity with how replicated, synchronized ledgers record data and how visibility differs between permissioned and permissionless designs. This affects what data may be available for analysis and how it can be interpreted, though the presence of DLT alone does not establish wrongdoing.

Technology and infrastructure risk teams

Teams assessing operational and technology risk are relevant because DLT is developing at pace across financial services and is being adopted in varied configurations. They are positioned to evaluate how a given deployment's architecture, governance, and consensus mechanism interact with the firm's control environment.

Legal, risk, and policy professionals

Because this entry describes the technology in general terms and is not a legal or regulatory definition, legal and policy specialists are relevant to determining how existing obligations apply to a particular DLT implementation. The applicable requirements and their treatment can vary by jurisdiction and deployment, and specifics should be confirmed against the relevant regulatory framework.

Inside DLT

Distributed Ledger

A shared, synchronized record of transactions or data maintained across multiple nodes rather than by a single central authority. In an AML context, the ledger may provide a persistent transaction history that can support tracing efforts, though the degree of transparency depends on whether the ledger is public, private, or permissioned.

Consensus Mechanism

The protocol by which participating nodes agree on the validity and ordering of transactions before they are added to the ledger. Different mechanisms carry different governance and control implications, which can affect how obliged entities assess counterparty and infrastructure risk.

Cryptographic Security

The use of cryptographic techniques to secure entries and link records so that historical data is generally resistant to alteration. This can support record integrity but does not by itself verify the real-world identity of the parties transacting.

Permissioning Model

The distinction between permissionless (open) ledgers and permissioned (access-controlled) ledgers. This boundary is significant for compliance because it affects who can participate, whether participant identities are known, and which party, if any, functions as an obliged entity under applicable regimes.

Smart Contracts

Self-executing code deployed on certain DLT platforms that automatically performs functions when defined conditions are met. Where present, these may automate transfers or asset movements, which can create operational and monitoring considerations, though their availability and function vary by platform.

Nodes and Network Participants

The distributed set of entities that store, validate, or relay ledger data. Understanding the roles of participants is relevant when determining regulatory responsibility, as many jurisdictions attach AML obligations to specific actors such as virtual asset service providers rather than to the technology itself.

Common questions

Answers to the questions practitioners most commonly ask about DLT.

Is distributed ledger technology the same as blockchain?

No. Blockchain is one type of distributed ledger technology, but the two terms are not interchangeable. DLT is the broader category describing systems in which a shared record of transactions is maintained across multiple nodes without necessarily relying on a single central authority. Blockchain refers specifically to implementations that group transactions into cryptographically linked blocks. Other DLT designs exist that do not use a block-and-chain structure, so treating every DLT system as a blockchain misstates the underlying architecture.

Does the use of DLT mean transactions are anonymous and untraceable?

Not necessarily. Many DLT systems are more accurately described as pseudonymous rather than anonymous: participants are typically identified by cryptographic addresses rather than names, but the transaction history recorded on the ledger may be visible and, in some designs, permanently retained. Whether activity can be linked to an identifiable person generally depends on the specific system, whether it is permissioned or permissionless, and what off-ledger information is available. The transparency and traceability characteristics vary significantly between implementations and should not be assumed.

How does the choice between a permissioned and a permissionless DLT affect an AML program?

The distinction is operationally significant. In a permissioned system, access is generally restricted to identified and vetted participants, which may make it easier to apply customer due diligence, governance, and access controls. In a permissionless system, participation is typically open, which can complicate the identification of counterparties. The appropriate controls should be assessed against the specific system's design and the obliged entity's role within it, rather than assuming one model universally reduces or increases financial crime risk.

Where does an obliged entity's AML responsibility sit when it uses DLT-based systems?

Responsibility generally attaches to the regulated activity and the obliged entity performing it, not to the technology itself. Whether AML obligations apply typically depends on how a given jurisdiction classifies the activity and the participant, for example under the US Bank Secrecy Act and FinCEN rules, the EU framework, or the UK Money Laundering Regulations. The use of DLT does not by itself create or remove obligations; entities should confirm their status and duties against the applicable regime rather than relying on the technology's characteristics.

What practical challenges arise when applying customer due diligence in a DLT environment?

Common challenges include identifying and verifying counterparties who interact via cryptographic addresses, establishing beneficial ownership where control is exercised through keys or code, and reconciling on-ledger data with off-ledger identity information. The immutable or append-only nature of some ledgers may also raise questions about correcting or deleting records. The suitability of any CDD approach should be evaluated against the specific system and the requirements of the applicable jurisdiction, as these vary.

How should transaction monitoring be approached for activity recorded on a distributed ledger?

Monitoring approaches generally need to account for the data that a given DLT system makes available, which may differ from traditional payment rails. Some systems provide a visible transaction history that can support analysis, while others limit visibility through privacy features. Monitoring is best understood as a measure to detect and manage risk rather than a guarantee of prevention, and any typologies or indicators used should not be treated as exhaustive or as establishing wrongdoing on their own. The design of monitoring controls should reflect the specific system and the entity's regulatory obligations.

Common misconceptions

DLT transactions are anonymous, making them untraceable for AML purposes.

Many DLT systems are more accurately described as pseudonymous rather than anonymous: transactions may be recorded on a persistent ledger, but they are typically linked to addresses rather than directly to verified identities. The traceability available in practice depends on the ledger type, the use of privacy-enhancing technologies, and the availability of customer identification at points where the technology interfaces with obliged entities.

Because a DLT ledger is immutable, it inherently prevents money laundering.

Record immutability supports the integrity of stored data but does not verify the legitimacy of underlying activity or the identity of participants. Immutability is a control over the record, not a control that detects, deters, or mitigates the risk of illicit funds moving through the system; no single technical feature eliminates financial crime risk.

DLT is itself regulated and subject to AML obligations.

AML obligations generally attach to defined obliged entities and activities rather than to a technology as such. In many jurisdictions, requirements apply to actors such as virtual asset service providers operating on or around DLT, and the precise scope varies by regime; the applicable regulation should be confirmed for any given actor.

Best practices

Determine which party in a DLT arrangement, if any, qualifies as an obliged entity under the applicable regime, and confirm the specific obligations against the relevant regulation rather than assuming a uniform global standard.

Assess the permissioning model, consensus mechanism, and participant roles as part of a risk-based evaluation, recognizing that public, private, and permissioned ledgers present materially different risk and transparency profiles.

Treat DLT transactions as pseudonymous rather than anonymous, and integrate customer identification and verification at the points where the technology interfaces with your controls, since the ledger alone does not establish identity.

Where smart contracts or automated transfers are in scope, evaluate their functions and monitoring implications, and do not rely on record immutability as evidence of transaction legitimacy.

Apply layered detection, monitoring, and mitigation measures rather than depending on any single technical feature, and document that these measures manage rather than guarantee elimination of financial crime risk.

Confirm exact thresholds, applicable instruments, and jurisdiction-specific requirements against the governing regulation, as scope and terminology may diverge across regimes.