<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Regulation Archives - LadyChain</title>
	<atom:link href="https://www.ladyww.net/tag/regulation/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.ladyww.net/tag/regulation/</link>
	<description>Crypto fees, wallets and offers — checked against the terms page</description>
	<lastBuildDate>Tue, 27 Oct 2026 14:02:30 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1</generator>

<image>
	<url>https://www.ladyww.net/wp-content/uploads/2026/10/mark-512-150x150.png</url>
	<title>Regulation Archives - LadyChain</title>
	<link>https://www.ladyww.net/tag/regulation/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Crypto Tax Basics: What Counts as an Event</title>
		<link>https://www.ladyww.net/crypto-tax-basics/</link>
					<comments>https://www.ladyww.net/crypto-tax-basics/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 14:02:30 +0000</pubDate>
				<category><![CDATA[Regulation]]></category>
		<category><![CDATA[Capital Gains]]></category>
		<category><![CDATA[Cost Basis]]></category>
		<category><![CDATA[Crypto Tax]]></category>
		<category><![CDATA[Disposals]]></category>
		<category><![CDATA[Income]]></category>
		<category><![CDATA[Jurisdiction]]></category>
		<category><![CDATA[Record Keeping]]></category>
		<category><![CDATA[Reporting]]></category>
		<category><![CDATA[Taxable Event]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/crypto-tax-basics/</guid>

					<description><![CDATA[<p>A crypto taxable event is a transaction a tax authority treats as a realisation — a point where you are considered to have given something up and, usually, to have [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/crypto-tax-basics/">Crypto Tax Basics: What Counts as an Event</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>A crypto taxable event is a transaction a tax authority treats as a realisation — a point where you are considered to have given something up and, usually, to have received something in return. The trigger is legal and accounting-based rather than technical, which is why a transfer between two wallets you control is a blockchain event but normally not a crypto taxable event, while a swap between two coins you never withdraw almost certainly is.</p>
<p>Most people meet this rule the hard way, at year end, in front of a list of transactions they have already forgotten making. The cheaper approach is to classify as you go. Once a transaction can be sorted into disposal, income, or neither, the record-keeping becomes mechanical and the annual reconciliation stops being archaeology.</p>
<ul>
<li><strong>Realisation, not movement, is the trigger.</strong> A transfer between wallets you control usually changes nothing; a trade changes ownership twice in one moment.</li>
<li><strong>Income and disposal are separate events.</strong> Earning coins creates income at receipt, and selling them later creates a second, independent event.</li>
<li><strong>Fees belong in the numbers.</strong> Network and trading fees typically adjust either proceeds or basis, and which one depends on the jurisdiction.</li>
<li><strong>Classification is cheapest at the moment of the trade.</strong> A note written that week is worth more than a reconstruction two years later.</li>
</ul>
<h2>The two families of crypto taxable event</h2>
<p>Almost every crypto taxable event falls into one of two families: a disposal, where you give up an asset, or income, where you receive one for work, rewards or a distribution. The families are not exclusive — one transaction can produce both — but they are computed and reported differently, so the label matters before any arithmetic starts.</p>
<h3>Disposals</h3>
<p>A disposal happens when ownership changes: selling for fiat, trading one coin for another, paying for goods or services, and in many jurisdictions spending crypto in any way that transfers it to someone else. The measure is usually proceeds minus basis, with the difference landing as a capital gain or loss. The detail that surprises people is that a coin-to-coin trade generally counts as two disposals in sequence, because you disposed of what you gave and acquired what you received at the same instant.</p>
<h3>Income</h3>
<p>Income events are receipts. Mining rewards, staking distributions, interest paid in kind, airdrops with a determinable value, and salary paid in crypto are commonly treated as ordinary income when received, measured at the value at that moment. That value usually becomes your basis in the coins, which means the same coins generate a second event when you later dispose of them. Nothing is being counted twice; two distinct events exist.</p>
<h3>Why the distinction changes the outcome</h3>
<p>The two families are often taxed under different rules, and in many jurisdictions at different rates. Ordinary income is generally recognised when received, while capital treatment can depend on how long the asset was held in places that distinguish holding periods. Because characterisation drives the result, recording an income receipt as though it were a simple transfer is one of the more expensive bookkeeping errors available.</p>
<h2>Transactions that are usually not crypto taxable events</h2>
<p>Several common actions look like events and usually are not, provided nothing of value changes hands.</p>
<h3>Moving between your own wallets</h3>
<p>Sending coins from an exchange account to a hardware wallet is normally not a disposal, because beneficial ownership did not change. It still matters for basis tracking: the receiving wallet inherits the original cost and date, and the transfer fee is usually treated either as an adjustment to basis or as a small separate disposal, depending on the jurisdiction.</p>
<h3>Buying with fiat and holding</h3>
<p>An acquisition on its own is usually not a taxable event; it establishes basis. The event arrives later, when you dispose. This is why a year of accumulation produces a long list of records and no reportable events at all, and why the disposal year is the one that needs those records.</p>
<p>Two grey areas deserve their own paragraph. Wrapping or bridging an asset, and receiving a new token through a migration or rebrand, are treated inconsistently: some jurisdictions see a continuation of the same holding, others see a disposal followed by a fresh acquisition. Neither view is universal, and the defensible answer depends on facts you should document at the time rather than reconstruct later.</p>
<h2>Sorting transaction types at a glance</h2>
<p>The table below is a starting point for classification, not a substitute for local rules. Every row has exceptions, and the exceptions tend to be where the money is.</p>
<div class="slv-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-800/70 bg-ink-900" data-slv-table><table>
<thead>
<tr>
<th>Transaction</th>
<th>Usual treatment</th>
<th>Record it creates</th>
</tr>
</thead>
<tbody>
<tr>
<td>Buy with fiat</td>
<td>Acquisition, no event yet</td>
<td>Basis, date, fee</td>
</tr>
<tr>
<td>Sell for fiat</td>
<td>Disposal</td>
<td>Proceeds, basis, result</td>
</tr>
<tr>
<td>Coin-to-coin swap</td>
<td>Usually two disposals</td>
<td>Both legs at value on the day</td>
</tr>
<tr>
<td>Staking or mining reward</td>
<td>Usually income at receipt</td>
<td>Value at receipt, new basis</td>
</tr>
<tr>
<td>Transfer between own wallets</td>
<td>Usually not an event</td>
<td>Original basis and date carried over</td>
</tr>
<tr>
<td>Gift sent or received</td>
<td>Depends on jurisdiction</td>
<td>Value, counterparty, date</td>
</tr>
</tbody>
</table></div>
<p>Note what the third column has in common: every row demands a value on a specific day. That single requirement drives most of the operational cost of crypto tax work, because the value has to come from somewhere defensible — a venue statement, a timestamped price source, or a documented convention applied consistently.</p>
<blockquote><p>The question is never &#8220;did the blockchain change?&#8221; It is &#8220;did ownership change, and was anything received in exchange?&#8221; Everything after that is bookkeeping.</p></blockquote>
<h2>How to classify a transaction in seven steps</h2>
<p>Run this on every entry in an export before you look at any totals. Doing it in this order prevents the common mistake of treating a swap as a single line.</p>
<ol>
<li>Identify whether you gave up an asset, received one, or both.</li>
<li>Ask whether ownership changed or only the address holding it changed.</li>
<li>If you received something without paying for it from your own capital, treat it as possible income and record the value at receipt.</li>
<li>If you gave something up, record proceeds — including the value of anything received in kind — and the basis of the specific units disposed of.</li>
<li>Record fees separately and attach them to the correct side; which side is a jurisdictional question.</li>
<li>Tag the entry with the wallet, the venue, and a transaction reference so it can be tied back to a statement.</li>
<li>Review the tagged list monthly rather than annually, while the context is still recoverable.</li>
</ol>
<p>The monthly habit matters more than the tooling. A transaction you cannot explain is a transaction you will eventually have to defend, and the difference between a two-minute note and a two-hour reconstruction is usually whether the browser tab was still open.</p>
<p>The post <a href="https://www.ladyww.net/crypto-tax-basics/">Crypto Tax Basics: What Counts as an Event</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/crypto-tax-basics/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Self-Custody and the Rules Around It</title>
		<link>https://www.ladyww.net/self-custody-rules/</link>
					<comments>https://www.ladyww.net/self-custody-rules/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 08:02:32 +0000</pubDate>
				<category><![CDATA[Regulation]]></category>
		<category><![CDATA[Backups]]></category>
		<category><![CDATA[Compliance]]></category>
		<category><![CDATA[Counterparty Risk]]></category>
		<category><![CDATA[Jurisdiction]]></category>
		<category><![CDATA[Key Management]]></category>
		<category><![CDATA[Record Keeping]]></category>
		<category><![CDATA[Self Custody]]></category>
		<category><![CDATA[Source Of Funds]]></category>
		<category><![CDATA[Wallets]]></category>
		<guid isPermaLink="false">https://www.ladyww.net/self-custody-rules/</guid>

					<description><![CDATA[<p>Self custody regulation is the body of rules that applies when you hold keys yourself, and it mostly does not regulate the act of holding. It regulates the businesses around [&#8230;]</p>
<p>The post <a href="https://www.ladyww.net/self-custody-rules/">Self-Custody and the Rules Around It</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>Self custody regulation is the body of rules that applies when you hold keys yourself, and it mostly does not regulate the act of holding. It regulates the businesses around you: the venues that convert between fiat and crypto, the custodians that hold on your behalf, and the intermediaries that transmit value across borders. The individual holding a hardware wallet is usually at the edge of these rules rather than at their centre.</p>
<p>That framing matters because most self custody regulation debates conflate two different questions. One is whether an intermediary must identify and monitor its customers; the other is whether a private holder owes anything when moving their own assets. The first is heavily regulated in many jurisdictions. The second varies enormously, and often depends on where you are resident rather than where the wallet is.</p>
<ul>
<li><strong>Rules usually attach to intermediaries, not to keys.</strong> The reporting burden sits mostly on businesses that move or hold assets for others.</li>
<li><strong>Your obligations follow your residence and citizenship.</strong> Wallet location is not the test most systems apply.</li>
<li><strong>Self-custody shifts operational risk to you.</strong> With no custodian, there is no recovery process and no support desk.</li>
<li><strong>Documentation is a control, not paperwork.</strong> Records of where funds came from and went are the main defence in any review.</li>
</ul>
<h2>What self custody regulation actually targets</h2>
<p>Most frameworks aim at the points where crypto touches the regulated financial system, because those are the points where an identifiable business can be made responsible for a rule.</p>
<h3>Intermediaries rather than keys</h3>
<p>A venue that lets you buy, sell or transfer assets generally has to identify customers, keep records, and report certain activity. Custodians holding assets for clients take on additional duties around segregation and safekeeping. A person holding their own keys is not performing those functions for anyone else, which is why the rules are usually written around service providers — and why the practical friction shows up at the boundary rather than inside the wallet.</p>
<h3>Obligations that follow the person</h3>
<p>Separately from intermediary rules, tax and reporting duties attach to individuals. Holding assets in self-custody does not suspend those duties, and in several jurisdictions the obligation to report disposals is unaffected by where the assets sat. The mechanism differs by country: some rely on self-declaration, some require specific disclosures, some ask for details of foreign or self-held accounts in particular circumstances. Rules differ by jurisdiction and change, so the only reliable answer is the one for where you are resident.</p>
<h2>Where self custody regulation reaches an individual holder</h2>
<p>For a private holder, the rules mostly appear at three moments: entering the regulated system, leaving it, and explaining the gap between the two.</p>
<h3>On-ramps and off-ramps</h3>
<p>Buying with fiat and selling for fiat are the points where identity checks and source-of-funds questions normally appear. A transfer from a self-custody wallet into a venue may prompt questions about where the assets came from, particularly for large or unusual amounts. These questions are routine in most jurisdictions and are easier to answer with records than with explanations.</p>
<h3>Reporting and record-keeping</h3>
<p>Disposals, income events and sometimes holdings themselves can carry reporting duties, depending on the jurisdiction. The common thread is that the duty is on you, and it does not disappear because the transaction happened wallet-to-wallet. Keeping a dated record of acquisitions, transfers and disposals is the cheapest way to satisfy it later.</p>
<h3>Sanctions and source-of-funds checks</h3>
<p>Venues screen deposits against sanctions lists and may freeze or query funds that arrive from flagged addresses. That screening is a property of the intermediary, not of your wallet, but it means an address&#8217;s history can follow the funds. Using a wallet whose history you cannot explain is a practical risk regardless of what the rules say.</p>
<h2>Custodial and self-custodial compared</h2>
<p>The trade is not &#8220;regulated versus unregulated&#8221;. It is a different allocation of responsibility, and each side has failure modes the other does not.</p>
<div class="slv-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-800/70 bg-ink-900" data-slv-table><table>
<thead>
<tr>
<th>Dimension</th>
<th>Custodial</th>
<th>Self-custodial</th>
</tr>
</thead>
<tbody>
<tr>
<td>Who can move funds</td>
<td>The provider, with your instruction</td>
<td>Whoever holds the keys</td>
</tr>
<tr>
<td>Reporting support</td>
<td>Statements and returns provided</td>
<td>You produce everything</td>
</tr>
<tr>
<td>Recovery after loss</td>
<td>Provider process, subject to terms</td>
<td>Your backup, or nothing</td>
</tr>
<tr>
<td>Counterparty risk</td>
<td>Provider solvency and controls</td>
<td>None from a provider</td>
</tr>
<tr>
<td>Identity checks</td>
<td>At onboarding</td>
<td>At on-ramps and off-ramps</td>
</tr>
<tr>
<td>Access friction</td>
<td>Low, but mediated</td>
<td>High, and entirely yours</td>
</tr>
</tbody>
</table></div>
<p>Neither column is uniformly better. Custodial accounts are simpler for reporting and worse for counterparty exposure. Self-custody removes the counterparty and replaces it with key management, which is a skill rather than a service.</p>
<blockquote><p>Self custody regulation is mostly about what happens at the edges of the system. The middle — the wallet itself — is governed less by rules than by the fact that a mistake there has no appeal process.</p></blockquote>
<h2>A defensive routine for self-custody</h2>
<p>The controls that matter are ordinary and boring. None of them require trusting a third party, and all of them reduce the chance that a technical failure becomes a permanent loss or an unexplained transaction.</p>
<ol>
<li>Write down what each wallet is for, so a balance can be interpreted later without guessing.</li>
<li>Keep at least two independent backups of recovery material, stored in separate physical locations.</li>
<li>Verify a backup by restoring it on a spare device before relying on it, not after.</li>
<li>Test every address with a small transfer before sending a meaningful amount.</li>
<li>Record each transfer with date, asset, amount, counterparty and purpose in a file you control.</li>
<li>Keep the records of where funds originated — exchange statements, purchase receipts — alongside the wallet records.</li>
<li>Review access: who else knows the backups exist, and whether that list is still correct.</li>
</ol>
<p>Steps two and three are the ones people skip, and they are the reason self-custody failures are usually permanent. A backup that has never been restored is a hypothesis, not a backup.</p>
<h2>Common misconceptions about self custody regulation</h2>
<p><strong>&#8220;Self-custody is unregulated.&#8221;</strong> Holding keys is largely outside intermediary rules, but the surrounding activity — buying, selling, reporting — is not. The obligations follow the person, not the wallet.</p>
<p><strong>&#8220;Rules only apply above some size.&#8221;</strong> Thresholds exist in many regimes, but they govern specific reporting duties rather than the underlying tax treatment, which generally applies regardless of size.</p>
<p><strong>&#8220;A privacy wallet removes the obligation.&#8221;</strong> It may reduce visibility, but it does not change what is owed, and unexplained gaps are exactly what a review looks for.</p>
<p><strong>&#8220;Custody terms are the same everywhere.&#8221;</strong> Account terms, segregation practices and recovery processes vary widely between providers, and reading them before depositing is a five-minute exercise with a long tail.</p>
<p>The post <a href="https://www.ladyww.net/self-custody-rules/">Self-Custody and the Rules Around It</a> appeared first on <a href="https://www.ladyww.net">LadyChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.ladyww.net/self-custody-rules/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
