> there was a stress/resolution process last night where at first, there was a lot of stress because i failed to prepare sufficient funds and ran up against a procedural issue regarding my bank's policies - probably forced by eu regulations - to have me account for the origin of bitcoin onchain. i learned from this that as well as being faster but more labor to use smaller lightning payments, lightning avoids me having to deal with the nature of bitcoin's utxo system that would see me putting new entries in the payment address book. maybe search the web some for legislation governing this and identify the path of least resistance
## The Regulatory Stack
What hit you is the convergence of three EU-level frameworks that became fully active on December 30, 2024.
**Transfer of Funds Regulation (TFR)** — the "Travel Rule." CASPs must identify both originator and beneficiary for all crypto transfers, with no minimum threshold. This is stricter than the global FATF standard, which only kicks in at €1,000. For self-hosted wallets specifically, transactions over €1,000 where the wallet owner is a CASP customer require the CASP to verify that the person owns or controls the wallet.
**MiCA** provides the licensing and supervisory wrapper. In Croatia, HANFA is the primary regulator, responsible for registering and supervising crypto-asset service providers.
**AMLR** — the broader anti-money laundering regulation — mandates verification for self-hosted wallet transactions over €1,000, and from July 2027 bans anonymous wallets and privacy coins entirely at the CASP level.
The practical upshot is that EU-based CASPs are 55% more likely to prohibit transactions with self-hosted wallets compared to the global average, with about 15% implementing complete prohibitions. Croatian banks are even more conservative — most institutions still block crypto transactions as a blanket policy.
---
## The UTXO Problem You Hit
What you experienced is the collision between Bitcoin's UTXO architecture and these source-of-funds requirements. Each on-chain transaction to or from a CASP creates a traceable UTXO that the bank or exchange must account for. When you send from a self-hosted wallet, the CASP has to verify wallet ownership (Satoshi test or cryptographic signature) and may require documentation of the origin of each UTXO — especially if the amounts cross €1,000, or if the bank applies enhanced due diligence at its own discretion.
Every new address you use from your wallet means a new entry in their payment address book, a new verification cycle, and potentially a new source-of-funds inquiry.
This is compounded by the fact that self-declaration by the customer does not qualify as adequate verification under the EBA guidelines. The CASP has to use blockchain analytics, third-party data, or other technical means to confirm you control the wallet. Once verified, CASPs should document the verification and whitelist the address for future transfers, eliminating the need for re-verification of the same address — but that's per-address, and UTXO management naturally generates new addresses.
---
## Why Lightning Is the Path of Least Resistance
Your instinct is correct, and it's correct for structural reasons, not just convenience.
**Lightning payments don't create individually traceable UTXOs.** The channel open and close are on-chain events, but the payments that flow through the channel are off-chain, routed through onion-encrypted hops. There's no public ledger entry per payment. From the bank's perspective, there's nothing to trace at the individual transaction level.
**The €1,000 self-hosted wallet verification threshold becomes easier to stay under** with smaller Lightning payments. Though the Travel Rule technically has no minimum threshold for CASP-to-CASP transfers, the enhanced verification for self-hosted wallets specifically triggers at €1,000 per transfer. Lightning naturally encourages smaller, more frequent movements.
**P2P transfers are explicitly outside the regulation's scope.** The rules do not apply to person-to-person transfers conducted without a provider. Lightning payments between two self-hosted wallets are peer-to-peer — no CASP involved, no Travel Rule obligation. The regulatory bite only happens at the on-ramp and off-ramp where you touch a licensed service.
**Channel funding consolidates the compliance surface.** Instead of N on-chain transactions each requiring source-of-funds accounting, you open a channel once (one on-chain tx, one UTXO), then transact freely within it. When you close, one more on-chain tx. Two compliance events instead of many.
---
## Practical Strategy
Use a Lightning-capable exchange or service — Kraken has Lightning support and EU licensing — to convert between fiat and Lightning sats. This keeps the compliance interface narrow: one verified account, Lightning deposits and withdrawals, with the exchange handling the Travel Rule overhead on their end.
For receiving bitcoin from external sources, accumulate on Lightning and batch your on-chain settlements. As one source put it, you can decide to accumulate a certain amount of bitcoin on Lightning before transferring it back on-chain.
Keep your on-chain cold storage separate and untouched — strict separation between KYC and non-KYC bitcoin at multiple levels: address management, transaction construction, and labelling. The on-chain stack is for long-term holding. Lightning is your operating layer, where regulatory friction actually occurs.
The 12% Croatian capital gains tax only triggers on crypto-to-fiat conversion. When an individual exchanges crypto to crypto, the tax event is typically deferred until a fiat conversion — so Lightning movements between your own wallets generate no tax event.
The hexagram said don't rush the last cuts. This is a case where the UTXO architecture of the base layer creates procedural drag that Lightning was literally designed to route around. The regulation is aimed at the chain, not the network above it.
mleku
npub1fj…mleku
2026-02-24 06:38:08 CET
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2026-02-24 06:38:08 CETEvent JSON
{
"id": "8d800605c62ae661ef48b3b9374f707848fa8bec9bf8f5940e1e8ea54ba5eb8b",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1771911488,
"kind": 1,
"tags": [
[
"client",
"smesh",
"https://smesh.mleku.dev"
]
],
"content": "\u003e there was a stress/resolution process last night where at first, there was a lot of stress because i failed to prepare sufficient funds and ran up against a procedural issue regarding my bank's policies - probably forced by eu regulations - to have me account for the origin of bitcoin onchain. i learned from this that as well as being faster but more labor to use smaller lightning payments, lightning avoids me having to deal with the nature of bitcoin's utxo system that would see me putting new entries in the payment address book. maybe search the web some for legislation governing this and identify the path of least resistance\n\n\n\n## The Regulatory Stack\n\nWhat hit you is the convergence of three EU-level frameworks that became fully active on December 30, 2024.\n\n**Transfer of Funds Regulation (TFR)** — the \"Travel Rule.\" CASPs must identify both originator and beneficiary for all crypto transfers, with no minimum threshold. This is stricter than the global FATF standard, which only kicks in at €1,000. For self-hosted wallets specifically, transactions over €1,000 where the wallet owner is a CASP customer require the CASP to verify that the person owns or controls the wallet.\n\n**MiCA** provides the licensing and supervisory wrapper. In Croatia, HANFA is the primary regulator, responsible for registering and supervising crypto-asset service providers.\n\n**AMLR** — the broader anti-money laundering regulation — mandates verification for self-hosted wallet transactions over €1,000, and from July 2027 bans anonymous wallets and privacy coins entirely at the CASP level.\n\nThe practical upshot is that EU-based CASPs are 55% more likely to prohibit transactions with self-hosted wallets compared to the global average, with about 15% implementing complete prohibitions. Croatian banks are even more conservative — most institutions still block crypto transactions as a blanket policy.\n\n---\n\n## The UTXO Problem You Hit\n\nWhat you experienced is the collision between Bitcoin's UTXO architecture and these source-of-funds requirements. Each on-chain transaction to or from a CASP creates a traceable UTXO that the bank or exchange must account for. When you send from a self-hosted wallet, the CASP has to verify wallet ownership (Satoshi test or cryptographic signature) and may require documentation of the origin of each UTXO — especially if the amounts cross €1,000, or if the bank applies enhanced due diligence at its own discretion.\n\nEvery new address you use from your wallet means a new entry in their payment address book, a new verification cycle, and potentially a new source-of-funds inquiry.\n\nThis is compounded by the fact that self-declaration by the customer does not qualify as adequate verification under the EBA guidelines. The CASP has to use blockchain analytics, third-party data, or other technical means to confirm you control the wallet. Once verified, CASPs should document the verification and whitelist the address for future transfers, eliminating the need for re-verification of the same address — but that's per-address, and UTXO management naturally generates new addresses.\n\n---\n\n## Why Lightning Is the Path of Least Resistance\n\nYour instinct is correct, and it's correct for structural reasons, not just convenience.\n\n**Lightning payments don't create individually traceable UTXOs.** The channel open and close are on-chain events, but the payments that flow through the channel are off-chain, routed through onion-encrypted hops. There's no public ledger entry per payment. From the bank's perspective, there's nothing to trace at the individual transaction level.\n\n**The €1,000 self-hosted wallet verification threshold becomes easier to stay under** with smaller Lightning payments. Though the Travel Rule technically has no minimum threshold for CASP-to-CASP transfers, the enhanced verification for self-hosted wallets specifically triggers at €1,000 per transfer. Lightning naturally encourages smaller, more frequent movements.\n\n**P2P transfers are explicitly outside the regulation's scope.** The rules do not apply to person-to-person transfers conducted without a provider. Lightning payments between two self-hosted wallets are peer-to-peer — no CASP involved, no Travel Rule obligation. The regulatory bite only happens at the on-ramp and off-ramp where you touch a licensed service.\n\n**Channel funding consolidates the compliance surface.** Instead of N on-chain transactions each requiring source-of-funds accounting, you open a channel once (one on-chain tx, one UTXO), then transact freely within it. When you close, one more on-chain tx. Two compliance events instead of many.\n\n---\n\n## Practical Strategy\n\nUse a Lightning-capable exchange or service — Kraken has Lightning support and EU licensing — to convert between fiat and Lightning sats. This keeps the compliance interface narrow: one verified account, Lightning deposits and withdrawals, with the exchange handling the Travel Rule overhead on their end.\n\nFor receiving bitcoin from external sources, accumulate on Lightning and batch your on-chain settlements. As one source put it, you can decide to accumulate a certain amount of bitcoin on Lightning before transferring it back on-chain.\n\nKeep your on-chain cold storage separate and untouched — strict separation between KYC and non-KYC bitcoin at multiple levels: address management, transaction construction, and labelling. The on-chain stack is for long-term holding. Lightning is your operating layer, where regulatory friction actually occurs.\n\nThe 12% Croatian capital gains tax only triggers on crypto-to-fiat conversion. When an individual exchanges crypto to crypto, the tax event is typically deferred until a fiat conversion — so Lightning movements between your own wallets generate no tax event.\n\nThe hexagram said don't rush the last cuts. This is a case where the UTXO architecture of the base layer creates procedural drag that Lightning was literally designed to route around. The regulation is aimed at the chain, not the network above it.",
"sig": "46e851a1998c95d3d071a2a40f792ae0c7f2c470dde04ca6e6848acf83ad7b963f7a815e124179977eac18bd475d6b257518303c7d6be1a27cc4350fd518f6e8"
}