Self-Custody Meets Compliance: Spark's Regulatory Position

Self-custodial Bitcoin protocols occupy an unusual position in financial regulation. They are not banks. They are not money transmitters in the traditional sense. Yet they facilitate value transfer, which puts them squarely in the sightline of regulators worldwide. For protocols like Spark, which use cooperative signing between users and operators, the regulatory picture is more nuanced than for either fully custodial services or purely peer-to-peer networks.

This article examines how self-custodial protocols fit into the global compliance landscape: what the GENIUS Act means for stablecoin self-custody, how the Travel Rule applies at protocol boundaries, and how jurisdictions from the EU to Asia are drawing the line between custody and software.

What Makes a Protocol Self-Custodial

The regulatory treatment of any crypto protocol depends on a fundamental question: who controls the private keys? Regulators across jurisdictions use some variation of a "control test" to determine whether a service provider is acting as a custodian, and therefore subject to licensing, capital requirements, and AML obligations.

In a fully custodial model, the service provider holds the user's keys and can unilaterally move funds. In a fully peer-to-peer model like on-chain Bitcoin, no intermediary touches the transaction at all. Spark sits between these poles: it uses a two-of-two multisig arrangement where the user holds one key and a set of operators collectively hold the other via FROST threshold signatures. Neither party can move funds alone.

The control test: FinCEN's 2019 virtual currency guidance states that multi-signature providers who cannot unilaterally execute transactions are not money transmitters. The EU's MiCA regulation draws a similar line: providers that neither control nor hold themselves out as controlling private keys fall outside the CASP (Crypto Asset Service Provider) regime.

The cooperative signing model

Spark's architecture creates a specific regulatory profile. Every transfer requires cooperative participation from both the user and the Spark operator set. Operators cannot initiate, redirect, or reverse transfers without user authorization. Users receive pre-signed exit transactions that allow unilateral withdrawal to Bitcoin L1 without operator cooperation.

This design means the operator never has unilateral control over user funds: a key distinction that separates cooperative custody models from traditional custodial services. Companies like Unchained and Casa operate under a similar principle in their multisig offerings, though Spark's statechain architecture applies the concept at the protocol level rather than as a product wrapper.

Are Statechain Operators Money Transmitters

In the United States, the money transmitter question turns on whether a party "accepts and transmits" value on behalf of another. Under FinCEN's 2019 guidance, this analysis has specific implications for multi-key arrangements.

Section 4.2.2 of the guidance addresses multi-signature wallet providers. As interpreted by Coin Center, providers of multisig arrangements that cannot unilaterally transact are not money transmitters. The reasoning is straightforward: if a provider holds one key in a two-of-two scheme but cannot move funds without the user's signature, it is not "transmitting" value in the regulatory sense.

Statechain operators have not been specifically addressed by FinCEN. But the functional analysis tracks closely with the multisig guidance. A Spark operator participates in signing but cannot execute a transfer independently. It never takes possession of funds and cannot redirect them. Users maintain their own key material and can exit to L1 at any time.

State-level variation

Federal classification is only half the picture. Each US state maintains its own money transmitter licensing regime, and interpretations vary significantly. New York's BitLicense regime casts a wide net over virtual currency businesses. Montana and South Carolina do not require money transmission licensure at all. Most states fall somewhere in between, with the "control" analysis remaining central to classification.

How the Travel Rule Applies to Self-Custodial Transfers

The Travel Rule (FATF Recommendation 16) requires financial institutions to pass originator and beneficiary information alongside transfers. For crypto, this obligation falls on VASPs: exchanges, custodial wallets, and other regulated intermediaries. The question for self-custodial protocols is where the Travel Rule boundary sits.

The VASP perimeter

FATF's position is that the Travel Rule applies when at least one party to a transfer is a VASP. Transfers between two unhosted wallets fall outside the rule's direct scope. In practice, this means that a Spark-to-Spark transfer between two self-custodial users does not trigger Travel Rule obligations, because neither party is a VASP.

The obligation arises at the interface with regulated services. When a user moves funds from a regulated exchange to their Spark wallet (or vice versa), the exchange bears Travel Rule responsibilities. FATF's June 2025 best practices document reinforces this: VASPs should collect originator and beneficiary information when transferring funds involving an unhosted wallet.

Jurisdictional implementation

While FATF sets the framework, implementation varies dramatically. According to FATF's own reporting, as of mid-2026 roughly 85 of 117 monitored jurisdictions had passed or were in the process of passing Travel Rule legislation. But of those, over half had not yet taken any supervisory or enforcement action.

Key distinction: The Travel Rule creates obligations for regulated entities that interact with unhosted wallets. It does not create obligations for the self-custodial user or the protocol itself. The burden falls on the exchange, not on the wallet software or the user holding their own keys.

The GENIUS Act and Self-Custodial Stablecoins

The GENIUS Act (Guiding and Establishing National Innovation for U.S. Stablecoins), signed into law as P.L. 119-27, represents the first comprehensive US regulatory framework for payment stablecoins. It takes effect on January 18, 2027, with the OCC finalizing its regulatory framework in October 2026 and the Federal Reserve and FDIC issuing parallel rulemaking.

For self-custodial protocols, the Act contains several provisions that directly affect how stablecoins like USDB can be held and transferred on networks like Spark.

Self-custody is explicitly preserved

The GENIUS Act does not prohibit self-custody of payment stablecoins. The OCC's final rule, along with the Federal Reserve and FDIC proposals, each exclude providers of self-custody tools from custody requirements. To qualify for this exclusion, the provider must neither control nor hold itself out as controlling the relevant private keys.

Peer-to-peer stablecoin transfers also remain permissible. A Congressional Research Service analysis reads the Act's exclusions as relatively broad, permitting self-custody transactions in all stablecoins, including those that are noncompliant or foreign-issued, provided the transactions are for lawful purposes.

Implications for Spark and USDB

USDB, issued by Brale on the Spark network, operates as a dollar-denominated stablecoin backed by US Treasury securities. Under the GENIUS Act framework, a user holding USDB in a self-custodial wallet and transferring it to another self-custodial user falls within the Act's personal-use exemption. The regulated obligations (reserve requirements, reporting, licensing) attach to the issuer, not to the protocol layer facilitating transfers or to end users holding their own keys.

This is a meaningful distinction for stablecoin-enabled protocols. For deeper analysis of stablecoin regulatory frameworks, see our coverage of the GENIUS Act's full scope and global stablecoin regulation.

The Unhosted Wallet Debate

The term "unhosted wallet" entered regulatory discourse through FATF's 2021 updated guidance on virtual assets. It describes any wallet where a third-party service provider does not control the private keys: hardware wallets, software wallets, and protocol-level self-custody alike.

FATF's targeted report on stablecoins and unhosted wallets identifies peer-to-peer transfers as the primary vulnerability in the stablecoin ecosystem. Suggested mitigations include limiting transfer amounts to unhosted wallets, applying enhanced due diligence, and using blockchain analytics to assess counterparty risk.

These recommendations fall on jurisdictions and VASPs, not on individual users or protocol developers. The report explicitly frames the issue as risk management for the regulated sector, not as a prohibition on self-custody. Still, the direction of travel is toward more friction at the regulated boundary: stricter verification when a VASP customer withdraws to or deposits from a self-hosted address.

EU: the strictest approach

The EU's Transfer of Funds Regulation (2023/1113), which took full effect alongside MiCA on July 1, 2026, imposes the most detailed requirements globally. For any transfer between a CASP and a self-hosted wallet, the CASP must attempt to verify whether its customer controls the destination address. Above EUR 1,000, verification is mandatory, and the EBA guidelines allow methods such as requiring the customer to sign a specific message with the private key controlling the address.

Importantly, MiCA's Recital 66 preserves an individual's right to hold crypto-assets in their own wallet without using a regulated service provider. The regulation targets the services, not the act of self-custody itself.

US: proposed but unfinalized

FinCEN proposed a rule in December 2020 that would require banks and money service businesses to collect and retain identity information for counterparties in transactions involving self-hosted wallets above $3,000, with reporting to FinCEN for transactions above $10,000. The proposal drew significant opposition and has not been finalized as of late 2026. In the meantime, the GENIUS Act's self-custody provisions may reduce the legislative appetite for more restrictive approaches.

How Spark's Architecture Creates a Nuanced Regulatory Profile

Spark does not fit neatly into existing regulatory categories because it is neither fully custodial nor fully peer-to-peer. Understanding this distinction matters for operators, wallet developers, and users building on the protocol.

Compared to custodial services

A custodial exchange or wallet holds user keys and can unilaterally move funds. It is clearly a money services business and a VASP. It must register with FinCEN, obtain state licenses, implement KYC/AML programs, and comply with the Travel Rule. Spark operators do not fit this description: they cannot move funds without user participation and do not take custody of user assets.

Compared to peer-to-peer protocols

A purely peer-to-peer protocol like on-chain Bitcoin involves no intermediary at all. There is no entity to regulate at the protocol level. Spark is different: operators actively participate in every state transition through cooperative signing. They see transfer metadata (amounts and participants), and they can refuse to process transactions (censorship). This operational involvement creates potential touchpoints for regulation even though operators lack custodial control.

The emerging middle ground

Spark's model aligns most closely with what the industry calls cooperative custody: arrangements where a service provider participates in transaction authorization but cannot act unilaterally. Products from companies like Unchained and Casa operate on the same principle, typically using two-of-three multisig where the provider holds one key.

Under FinCEN's 2019 guidance, these arrangements likely fall outside the money transmitter definition. Under MiCA, they fall outside the CASP perimeter if the provider does not control keys. But "likely" is not "certainly," and no regulator has specifically addressed the statechain model. The legal analysis is inferred from analogous structures, not from precedent directly on point.

Jurisdictional Differences in Treating Self-Custodial Protocols

The global regulatory landscape for self-custodial protocols varies substantially. While no major jurisdiction has banned self-custody outright, the friction imposed at the interface between regulated and unregulated activity differs dramatically.

United States

The US approach is fragmented across federal and state levels. At the federal level, FinCEN's multisig guidance favors non-custodial models, and the GENIUS Act explicitly preserves self-custody rights. State-level licensing remains a patchwork, with New York's BitLicense as the most restrictive. For a broader view of VASP licensing requirements, see our global VASP licensing analysis.

European Union

The EU has the most developed framework. MiCA establishes clear boundaries: self-custody is protected, but CASPs face significant obligations when interacting with unhosted wallets. The Transfer of Funds Regulation adds verification requirements at the CASP boundary. For protocols operating in the EU, the practical impact is that regulated on-ramps and off-ramps must implement additional checks for self-hosted wallet transfers, creating UX friction but not prohibiting self-custody itself.

Asia-Pacific

Asian jurisdictions generally focus regulation on custodial services and exchanges while leaving self-custody unrestricted. Japan's Financial Services Agency requires registration for exchanges under the Payment Services Act. Singapore's MAS licenses digital payment token services. Hong Kong's SFC operates a VATP (Virtual Asset Trading Platform) licensing regime. In each case, the regulatory burden falls on intermediaries that take custody, not on self-custodial tools or protocols.

What Self-Custodial Compliance Looks Like in Practice

For wallet developers and businesses building on self-custodial protocols, the compliance picture focuses on three areas: where you incorporate, what services you offer beyond the wallet, and how you handle the interface with regulated entities.

• Wallet software that only provides key management and signing capabilities typically falls outside VASP and money transmitter definitions
• Adding fiat on-ramps, exchange functionality, or custodial features crosses into regulated territory
• Operators participating in cooperative signing should monitor jurisdictional guidance as the statechain model gains more regulatory attention
• Travel Rule obligations attach to regulated counterparties, not to the protocol or the self-custodial user
• The GENIUS Act's self-custody carve-out provides a clear US framework for stablecoin-holding wallets

For wallet developers: The regulatory position of self-custodial software is generally favorable, but the boundaries shift the moment a product adds custodial features, exchange services, or fiat on-ramps. The protocol layer and the product layer face different regulatory analyses.

Building on Self-Custodial Rails

The regulatory trajectory across major jurisdictions points in a consistent direction: self-custody is preserved, but the interface with regulated services faces increasing scrutiny. For protocols like Spark, this creates a favorable position: the protocol itself provides self-custodial infrastructure, while compliance obligations attach to the regulated entities (exchanges, on-ramps, issuers) that connect to it.

Developers building on Spark can start with the Spark SDK documentation to integrate self-custodial Bitcoin and stablecoin functionality. For users looking to experience self-custodial stablecoin payments on Spark today, General Bread provides a Spark-powered wallet with support for both BTC and USDB. For more on the broader compliance landscape around stablecoins, see our stablecoin Travel Rule compliance guide.

This article is for educational purposes only. It does not constitute financial, investment, or legal advice. Regulatory frameworks for digital assets are evolving rapidly and vary by jurisdiction. Always consult qualified legal counsel for compliance decisions. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.