Lightning Network Compliance: The KYC and Routing Gap

The Lightning Network was designed for privacy. Payments route through multiple nodes using onion routing, where each intermediary sees only its immediate predecessor and successor. That architecture creates a fundamental tension with regulatory frameworks that demand sender and receiver identification for every transfer above a threshold. For regulated entities: virtual asset service providers, exchanges, neobanks, and payment processors: this gap between Lightning's design and compliance obligations is now the single largest barrier to institutional adoption.

This article examines the specific compliance challenges Lightning creates, how regulators in the US, EU, and Singapore are responding, the solutions being built to bridge the gap, and the risk that excessive requirements could fragment the network into compliant and non-compliant segments.

The Travel Rule Problem on Lightning

The travel rule requires financial institutions to pass along identifying information about the sender and receiver of a fund transfer. Originally codified in the US Bank Secrecy Act for wire transfers above $3,000, the concept was extended to virtual assets by the Financial Action Task Force (FATF) in its 2019 guidance on virtual assets and VASPs. The FATF benchmark threshold is USD/EUR 1,000, while FinCEN in the US maintains the $3,000 threshold for money transmission involving convertible virtual currencies.

On a traditional blockchain, travel rule compliance is conceptually straightforward: a VASP knows who initiated the transaction (through KYC at onboarding) and can attach originator information to the transfer. The receiving VASP can verify the recipient. Chain analytics firms can trace the on-chain flow.

Lightning breaks this model in three ways.

Onion Routing Hides Endpoints

When Alice pays Bob through a multi-hop path (Alice → Node 1 → Node 2 → Bob), each routing node only knows the identity of the node that forwarded the HTLC and the node it forwards to. Node 1 knows Alice sent the payment but does not know it is ultimately destined for Bob. Node 2 knows it received from Node 1 and is forwarding to Bob, but cannot confirm Alice originated it. This is by design: it is the same privacy architecture that protects users on Tor.

No Central Ledger

Off-chain payments leave no trace on the Bitcoin blockchain until channels are opened or closed. A multi-hop payment that settles successfully produces no on-chain record. This means transaction monitoring tools that rely on blockchain analysis have limited visibility into payment flows between channel open and close events.

Peer-to-Peer Payments Lack Intermediaries

Many Lightning payments occur between peers running their own nodes, without any VASP involvement. When two individuals transact directly over Lightning, there is no regulated entity to enforce travel rule obligations. The FATF framework assumes intermediation: the travel rule binds VASPs, not end users. A fully peer-to-peer Lightning payment exists outside that framework entirely.

The core paradox: The travel rule requires VASPs to identify the originator and beneficiary of every qualifying transfer. On Lightning, the protocol is specifically engineered so that intermediary nodes cannot make that identification. Compliance and privacy are working at cross purposes.

How Different Jurisdictions Are Approaching the Gap

Regulators have taken different approaches to virtual asset compliance, and none has issued definitive guidance on how the travel rule applies to Lightning's multi-hop architecture. The result is a patchwork of frameworks that regulated entities must navigate.

United States: FinCEN and the BSA Framework

FinCEN's 2019 convertible virtual currency guidance remains the primary US framework. It applies BSA obligations to any entity that accepts and transmits value as a business, regardless of the technology used. The guidance does not name Lightning specifically, but it states that a money transmitter cannot avoid regulatory obligations by choosing to provide services using "anonymity-enhanced" convertible virtual currency.

The practical implication: any entity operating a Lightning node as a business that accepts and transmits payments for customers is likely a money transmitter under FinCEN's facts-and-circumstances test. This includes custodial Lightning Service Providers, exchanges offering Lightning deposits and withdrawals, and payment processors routing Lightning payments on behalf of merchants. The US travel rule threshold for these entities is $3,000.

European Union: MiCA and the Transfer of Funds Regulation

The EU's MiCA regulation and the accompanying Transfer of Funds Regulation (TFR, Regulation 2023/1113) went into effect in late 2024, with the MiCA grandfathering period ending on July 1, 2026. The TFR applies the travel rule to crypto-asset transfers with no de minimis threshold: every transfer involving a Crypto Asset Service Provider (CASP) requires originator and beneficiary information.

For transfers to or from self-hosted wallets exceeding €1,000, the CASP must verify that the customer controls the wallet. The Dutch Authority for Financial Markets (AFM) submitted a formal question to the EBA asking whether Lightning Network transactions fall within the scope of the TFR and the EBA Travel Rule Guidelines (EBA/GL/2024/11). According to legal analyses, the EBA has indicated that CASPs offering Lightning transfers fall within TFR scope, while purely peer-to-peer Lightning usage outside CASP involvement does not.

Singapore: The Payment Services Act

Singapore regulates virtual assets primarily under the Payment Services Act (PSA), with additional provisions under the Financial Services and Markets Act (FSMA). Amendments effective in stages from 2024 extended licensing to digital payment token transmission and safekeeping services. The Monetary Authority of Singapore (MAS) requires licensed DPT providers to segregate customer assets, maintain detailed books and records, and comply with AML and counter-terrorism financing obligations. While MAS has not issued Lightning-specific guidance, any custodial Lightning service operating in Singapore would need a PSA license and must implement travel rule procedures.

Enforcement gap: As of the FATF's 2025 targeted update, 83% of surveyed jurisdictions have enacted travel rule legislation, up from 73% the prior year. But only 34% of assessed jurisdictions (51 of 149) are rated largely compliant with Recommendation 15 on virtual assets. Roughly 60% of jurisdictions with travel rule legislation have not yet taken enforcement action specifically related to travel rule compliance.

Compliance Solutions Being Built

The industry is not waiting for regulators to solve the problem. Several approaches have emerged to make Lightning payments compatible with compliance requirements, each with distinct tradeoffs.

Node-Level KYC: Compliance at the Edges

The most common approach today is applying KYC at the edges of the Lightning Network rather than trying to identify participants at every hop. Regulated entities: exchanges, custodial wallets, and payment processors: require identity verification when users onboard. When a KYC-verified user sends or receives a Lightning payment through that service, the regulated entity knows the identity of its own customer and can fulfill its travel rule obligations for that leg of the transaction.

This "compliance at the edges" model is analogous to how traditional banking handles wire transfers: each bank knows its own customer, and the correspondent banking network passes information between institutions. The difference is that Lightning's routing layer does not natively carry that information, so compliance messaging must be added on top.

Universal Money Address (UMA)

Universal Money Address (UMA) is an open-source standard developed by Lightspark that extends LNURL and Lightning Addresses to add compliance messaging. UMA addresses look like email addresses with a leading dollar sign (e.g., $alice@vasp.com). Before a payment settles, the sending VASP contacts the receiving VASP to exchange compliance information: recipient identity, preferred currency, and applicable regulatory requirements.

The payment then settles over standard Lightning rails, but the transaction is logged with a compliance provider for record-keeping and post-transaction analysis. UMA supports both pre- and post-transaction risk assessment, enabling sanctions screening and SAR filing within the payment flow. Early adopters include Bakkt, a US-licensed money transmitter that launched an UMA-capable Lightning service.

Compliance-Aware LSPs

Lightning Service Providers already manage channels on behalf of mobile users, positioning them as natural compliance gatekeepers. A compliance-aware LSP can require identity verification before opening channels, monitor payment patterns for anti-money laundering purposes, and share originator and beneficiary information with counterpart LSPs when both ends of a payment touch regulated infrastructure.

The tradeoff: LSPs that collect and share user data create centralized points of metadata collection. Users who choose a regulated LSP for convenience sacrifice some of the privacy that makes Lightning attractive in the first place. For a deeper analysis of Lightning privacy in this context, see our Lightning Network privacy analysis.

Chain Analytics for Lightning

Blockchain analytics firms have expanded their tooling to cover Lightning. Elliptic, for instance, offers node risk attribution and transaction monitoring focused on the points where regulated entities touch Lightning: channel opens and closes, on-chain funding transactions, and interactions with known service-provider nodes. Their approach combines deterministic rules (threshold triggers, known-bad exposure) with probabilistic methods (anomaly detection, clustering, relationship analysis).

The fundamental limitation remains: off-chain payments between channel open and close events are largely invisible to on-chain analytics. These tools are most effective at the regulated perimeter, not within the routing layer itself.

The Network Fragmentation Risk

A growing concern in the Lightning community is that compliance requirements could split the network into two disconnected segments: a "compliant" network of regulated nodes that enforce identity requirements, and a "permissionless" network of nodes that do not. If compliant nodes refuse to route payments to or from non-compliant nodes, the unified payment network that gives Lightning its value could fracture.

This scenario has not materialized yet, but the structural conditions exist. Lightning's source routing requires a public channel graph: if regulated nodes began advertising only connections to other compliant nodes, non-compliant nodes would lose routing paths through the regulated network. Academic research on Lightning's topological stability already shows declining density and clustering in the network graph, though this reflects natural structural evolution rather than policy-driven segregation.

Who Loses in a Fragmented Network

Network fragmentation would harm both sides. Compliant nodes would lose access to liquidity and routing paths through the non-compliant segment, increasing payment failure rates and routing costs. Non-compliant nodes would be cut off from the on- and off-ramps that connect Lightning to the traditional financial system, limiting the network's utility for real-world payments.

The Lightning Network's value depends on its reach. Every node that disconnects from the main graph reduces the probability that any given payment can find a viable path. For an examination of how these dynamics play out in practice, see our analysis of Lightning routing and the state of Lightning in 2026.

Avoiding a Split

The industry's best defense against fragmentation is building compliance solutions that operate at the application layer rather than the routing layer. If identity exchange happens between VASPs (as UMA proposes) rather than being enforced at every routing hop, the underlying network can remain unified. Routing nodes would not need to make compliance decisions: they would simply forward payments as they do today, while the compliance obligation would rest entirely on the originating and beneficiary VASPs.

What the FATF Update Means Going Forward

At its June 2025 plenary, the FATF agreed on changes to Recommendation 16, expanding the travel rule's stated objectives beyond money laundering and terrorist financing to include fraud prevention and proliferation financing. While this revision primarily targets banks and traditional payment providers, the FATF's technology-neutral approach means the principles will influence how national regulators treat Lightning and other Layer 2 networks.

The FATF's 2025 targeted update also found that while legislative adoption has accelerated, technical implementation and enforcement remain weak across much of the global network. Of 124 jurisdictions surveyed, the majority have laws on the books but lack the supervisory infrastructure to enforce them. For Lightning, this means the window for the industry to establish workable compliance standards is still open: but it is closing.

For a broader view of how these regulatory frameworks affect stablecoin and crypto compliance, see our stablecoin travel rule compliance guide and 2026 regtech compliance stack overview.

An Alternative Architecture: Known Entities

Some of Lightning's compliance challenges are architectural, not regulatory. The protocol was designed so that intermediary nodes cannot identify transacting parties. Any compliance solution built on top of Lightning must work around this design rather than with it.

Spark offers an instructive contrast. Statechains transfer ownership of Bitcoin by rotating key shares between the user and the Spark Entity: a federation of known operators. Unlike Lightning's multi-hop routing, where payments traverse an unpredictable path through anonymous intermediaries, Spark transfers are bilateral interactions between a user and the operator set. The operator always participates in every transfer, creating a clear compliance touchpoint without requiring additional messaging layers or protocol extensions.

This does not mean Spark eliminates compliance work. Operators still need to implement KYC/AML procedures, file SARs when required, and comply with travel rule obligations. But the architecture makes compliance more tractable: the operator knows who is transferring because they are a direct participant in every state transition, not an anonymous routing hop. For regulated entities evaluating Bitcoin Layer 2 options, this architectural clarity can significantly reduce the compliance engineering burden.

Architecture matters for compliance: Lightning requires compliance to be layered on top of a privacy-preserving protocol. Spark builds compliance compatibility into the transfer mechanism itself: the operator is always a known counterparty. Neither approach is inherently better: they serve different use cases and user profiles.

What Regulated Entities Should Do Now

The regulatory landscape for Lightning compliance is still forming, but regulated entities cannot afford to wait for clarity. Based on the current state of guidance across jurisdictions, several practical steps are available.

• Implement KYC at the edges: verify user identity at onboarding and tie Lightning invoices to verified accounts. This is the minimum viable compliance posture.
• Adopt travel rule messaging standards like UMA for VASP-to-VASP Lightning payments. The standard is open source and already supported by licensed US money transmitters.
• Monitor regulatory developments in your jurisdiction, particularly the EBA's ongoing work on how TFR applies to Lightning and any FinCEN rulemaking that addresses Layer 2 payment protocols.
• Evaluate architecture-level compliance by considering whether your use case is better served by a protocol where the operator is always a known participant. Spark's developer documentation and SDK provide integration paths for regulated entities.
• Engage with chain analytics providers that offer Lightning-specific monitoring for channel funding and closure transactions.

For a broader comparison of compliance models across Bitcoin Layer 2 solutions, see our trust model comparison and VASP licensing guide.

Conclusion

Lightning's privacy is a feature, not a bug. But for regulated entities, that privacy creates a compliance gap that current frameworks do not fully address. The travel rule assumes intermediaries can identify senders and receivers. Lightning's onion routing is designed to prevent exactly that. Bridging this gap requires solutions that add compliance capabilities without breaking the underlying protocol.

The most promising approaches work at the application layer: VASP-to-VASP messaging standards like UMA, node-level KYC, and compliance-aware LSPs that enforce identity at the edges while leaving the routing layer intact. The alternative: enforcing compliance at the routing layer: risks fragmenting the network and destroying the connectivity that makes Lightning useful.

As the FATF tightens its standards and jurisdictions move from legislation to enforcement, the window for the industry to establish workable compliance norms is narrowing. Regulated entities that invest in compliance infrastructure now will be better positioned than those that treat it as a future problem. And for use cases where compliance clarity is a priority, architectures like Spark: where the operator is always a known party to the transfer: offer a structurally simpler path.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.