<?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>Margin Trading — tagged coverage - FogChain</title>
	<atom:link href="https://www.fogment.com/tags/margin-trading/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.fogment.com/tags/margin-trading/</link>
	<description>Blockchain news, exchange data and press releases — independently verified.</description>
	<lastBuildDate>Wed, 28 Oct 2026 01:21:56 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.2</generator>

<image>
	<url>https://www.fogment.com/wp-content/uploads/2026/10/cropped-39cb25f161f59e8c-raccoon-6-32x32.png</url>
	<title>Margin Trading — tagged coverage - FogChain</title>
	<link>https://www.fogment.com/tags/margin-trading/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Sub-Accounts: Separating Risk</title>
		<link>https://www.fogment.com/exchange-sub-accounts/</link>
					<comments>https://www.fogment.com/exchange-sub-accounts/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Wed, 28 Oct 2026 01:21:56 +0000</pubDate>
				<category><![CDATA[Exchanges]]></category>
		<category><![CDATA[Account Structure]]></category>
		<category><![CDATA[Api Security]]></category>
		<category><![CDATA[Crypto Exchanges]]></category>
		<category><![CDATA[Exchange Sub-Accounts]]></category>
		<category><![CDATA[Liquidation Risk]]></category>
		<category><![CDATA[Margin Trading]]></category>
		<category><![CDATA[Operational Risk]]></category>
		<category><![CDATA[Position Sizing]]></category>
		<category><![CDATA[Risk Management]]></category>
		<category><![CDATA[Trading Infrastructure]]></category>
		<guid isPermaLink="false">https://www.fogment.com/exchange-sub-accounts/</guid>

					<description><![CDATA[<p>An exchange sub-account is a separate trading balance that sits under one master account but keeps its own positions, margin and, usually, its own API keys. It is the cheapest [&#8230;]</p>
<p>The post <a href="https://www.fogment.com/exchange-sub-accounts/">Sub-Accounts: Separating Risk</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>An exchange sub-account is a separate trading balance that sits under one master account but keeps its own positions, margin and, usually, its own API keys. It is the cheapest risk control available on a centralized venue, and most traders never turn it on.</p>
<p>The point of an exchange sub-account is containment. If one strategy blows up, the loss stays inside the container instead of reaching the balance that funds everything else. The mechanics are simple, but the details vary by venue, and the differences matter more than the marketing suggests.</p>
<ul>
<li>Sub-accounts separate margin and positions, but not always the custody risk of the venue itself.</li>
<li>Most venues let you scope API keys per sub-account, which limits the blast radius of a leak.</li>
<li>Transfers between sub-accounts are usually internal and free, unlike withdrawals to an external chain.</li>
<li>Segmentation fails if the master account keeps withdrawal rights or shared collateral enabled.</li>
</ul>
<h2>What an exchange sub-account actually isolates</h2>
<p>It isolates margin, positions, order history and permissions. It does not isolate counterparty risk. Funds on the same venue share the same custodian, the same operational failures and the same withdrawal queue.</p>
<p>That distinction should drive how you use them. Sub-accounts are excellent at stopping one strategy from liquidating another. They are useless against the venue itself freezing withdrawals, and they do not protect you if the entity holding the assets fails. For that risk you need a different venue, not a different sub-account.</p>
<h3>The four things that are separated</h3>
<p>Balance, margin, positions and API credentials are what typically move into a sub-account. Each one has its own consequences.</p>
<ul>
<li><strong>Balance</strong> — the collateral available to that container only. A loss elsewhere cannot touch it, and vice versa.</li>
<li><strong>Margin</strong> — leverage is calculated per account, so a heavily used strategy does not consume the borrowing capacity of a conservative one.</li>
<li><strong>Positions</strong> — netting happens within the container. Two opposing positions in different sub-accounts stay open instead of offsetting.</li>
<li><strong>API credentials</strong> — keys issued to a sub-account normally cannot read or trade the master account, which is the single most useful property.</li>
</ul>
<h3>What stays shared</h3>
<p>KYC identity, fee tier treatment, deposit addresses, and the legal relationship with the venue usually remain at master level. Some venues aggregate volume across sub-accounts for fee tiers; others do not. Some allow internal transfers instantly; others batch them.</p>
<p>Check three settings before you rely on the structure: whether the master can withdraw from sub-accounts without approval, whether negative balances in one sub-account can be covered from another, and whether margin is shared by default. Any of these enabled quietly defeats the purpose.</p>
<h2>Why separating risk with an exchange sub-account pays off</h2>
<p>Because the most common account failure is not theft — it is one strategy consuming the collateral that another strategy needed.</p>
<p>Consider a funding-rate position that is correctly hedged but temporarily underwater, running in the same account as a directional position with a tight stop. The hedge needs margin to stay open. The directional trade&#8217;s losses reduce available margin. The venue liquidates whichever position is closest to the line, which may be the hedge you intended to keep. Two sub-accounts make that interaction impossible.</p>
<h3>Operational separation beats mental separation</h3>
<p>Keeping strategies apart &#8220;in a spreadsheet&#8221; is not separation. If they share one balance, one liquidation engine treats them as one portfolio. The engine does not care about your labels.</p>
<p>This is also why sub-accounts matter for automation. A bot with a key that can only touch its own container cannot drain the rest of your account through a bug, a bad config, or a compromised API secret. That is a real limit, not a theoretical one.</p>
<h2>How sub-account models compare</h2>
<p>Models differ in where the boundary sits, and the differences change what you can safely automate.</p>
<div class="fog-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-200/70 bg-surface" data-fog-table><table>
<thead>
<tr>
<th>Model</th>
<th>Isolation</th>
<th>Typical trade-off</th>
</tr>
</thead>
<tbody>
<tr>
<td>Single account, tags only</td>
<td>Reporting only</td>
<td>No margin separation; simplest to operate</td>
</tr>
<tr>
<td>Sub-accounts under one master</td>
<td>Balance, margin, positions, keys</td>
<td>More setup; some venues restrict transfers</td>
</tr>
<tr>
<td>Separate accounts, separate logins</td>
<td>Strongest on-platform separation</td>
<td>Duplicated KYC; harder to aggregate collateral</td>
</tr>
<tr>
<td>Separate venues</td>
<td>Counterparty separation too</td>
<td>Extra fees, transfer time, more operational surface</td>
</tr>
<tr>
<td>Self-custody plus venue trading</td>
<td>Asset separation until deposit</td>
<td>Deposit and withdrawal costs, key management burden</td>
</tr>
</tbody>
</table></div>
<blockquote><p>Segmentation is only real when the failure of one container cannot reach the collateral of another. Everything else is bookkeeping.</p></blockquote>
<h2>Setting one up without creating new failure modes</h2>
<p>Setup takes minutes, and the ordering matters more than the clicks.</p>
<ol>
<li>Decide the boundary first: one sub-account per strategy, per client, or per risk budget. Mixed boundaries produce containers nobody can reconcile.</li>
<li>Create the sub-account and fund it with only the collateral that strategy needs, not a round-share of your total.</li>
<li>Disable master-level withdrawal rights over the sub-account if the venue allows it, or remove withdrawal permission from every key.</li>
<li>Issue a fresh API key scoped to that sub-account, with IP allowlisting where available and no withdrawal permission.</li>
<li>Set a notional cap in your own code as well, because venue-side limits are the second line of defence, not the first.</li>
<li>Record which key belongs to which container in one place, and test the separation with a small deliberate transfer.</li>
<li>Review monthly: dormant sub-accounts accumulate balance and become an unmonitored attack surface.</li>
</ol>
<h3>A simple allocation example</h3>
<p>Suppose 10,000 units of quote currency are split three ways: 5,000 for a spot core position, 3,000 for a hedged basis trade, 2,000 for a high-turnover experimental strategy. If the experimental container loses its entire 2,000, the other two are untouched, because the liquidation engine never saw them. In a single account, that same loss would have reduced shared margin by 20 percent and could have forced a partial unwind of the hedge at the worst moment.</p>
<p>The arithmetic is the argument. Containment converts an unbounded portfolio event into a bounded, pre-agreed loss.</p>
<h2>Mistakes that quietly undo the separation</h2>
<p>Most failures come from configuration drift rather than from the model itself.</p>
<ul>
<li>Shared collateral switched on for convenience, which links every container again.</li>
<li>One master key reused across bots, so a single leak reaches everything.</li>
<li>Sub-accounts used as a filing cabinet, with balances left idle in containers nobody watches.</li>
<li>Withdrawal permission granted to a trading key &#8220;just in case&#8221;, which turns a trading bug into a full loss.</li>
</ul>
<p>Each of these is reversible, and each is worth checking before the next deposit rather than after the next incident.</p>
<p>Reconciliation is the other quiet failure. Once balances live in several containers, your total exposure is no longer visible on one screen, and a position you believe is hedged may be hedged in a container that no longer holds enough collateral. Export balances on a fixed schedule and add them up yourself.</p>
<p>The post <a href="https://www.fogment.com/exchange-sub-accounts/">Sub-Accounts: Separating Risk</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.fogment.com/exchange-sub-accounts/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Exchange Insurance Funds: What They Cover</title>
		<link>https://www.fogment.com/exchange-insurance-fund/</link>
					<comments>https://www.fogment.com/exchange-insurance-fund/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 21:21:58 +0000</pubDate>
				<category><![CDATA[Exchanges]]></category>
		<category><![CDATA[Auto-Deleveraging]]></category>
		<category><![CDATA[Bankruptcy Price]]></category>
		<category><![CDATA[Counterparty Risk]]></category>
		<category><![CDATA[Crypto Exchanges]]></category>
		<category><![CDATA[Derivatives Risk]]></category>
		<category><![CDATA[Exchange Insurance Fund]]></category>
		<category><![CDATA[Leverage]]></category>
		<category><![CDATA[Liquidation]]></category>
		<category><![CDATA[Margin Trading]]></category>
		<category><![CDATA[Risk Disclosure]]></category>
		<guid isPermaLink="false">https://www.fogment.com/exchange-insurance-fund/</guid>

					<description><![CDATA[<p>An exchange insurance fund is a pool of capital the venue uses to cover losses when a trader&#8217;s position is liquidated at a price worse than the point at which [&#8230;]</p>
<p>The post <a href="https://www.fogment.com/exchange-insurance-fund/">Exchange Insurance Funds: What They Cover</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>An exchange insurance fund is a pool of capital the venue uses to cover losses when a trader&#8217;s position is liquidated at a price worse than the point at which their collateral ran out. It protects the venue&#8217;s other traders from absorbing that shortfall, not the trader who was liquidated.</p>
<p>That last clause is where most confusion starts. An exchange insurance fund is not deposit insurance, it does not cover hacks, and it does not reimburse you for a bad trade. It covers one narrow gap in the derivatives plumbing, and understanding that gap tells you a lot about how liquidation actually works.</p>
<ul>
<li>The fund absorbs shortfalls between a liquidation price and the price the venue actually got.</li>
<li>It covers the venue&#8217;s book, not your deposit, and not losses from theft or insolvency.</li>
<li>Fund size is a rough buffer estimate, not a guarantee, and published figures vary in what they include.</li>
<li>When the fund is exhausted, venues typically fall back to auto-deleveraging other traders&#8217; positions.</li>
</ul>
<h2>What an exchange insurance fund is for</h2>
<p>Liquidation is supposed to be solvent: the position is closed while collateral still covers the loss. Sometimes it is not. A fast move, a thin book, or a gap through several price levels can leave the venue holding a position that is worth less than zero after the trader&#8217;s margin is gone.</p>
<p>That negative balance has to land somewhere. It can land on the venue&#8217;s balance sheet, on other traders through a clawback, or on a pre-funded pool. The exchange insurance fund is the third option, and most large derivatives venues use it.</p>
<h3>Where the money comes from</h3>
<p>Funding rules differ by venue, but the common sources are liquidation penalties charged to the liquidated trader and any residual value left after their position is closed.</p>
<p>When a position is liquidated, the venue typically closes it and keeps a penalty from the remaining margin. Some of that flows into the fund. In a well-behaved liquidation where the fill is better than the bankruptcy price, the surplus goes to the fund too. The fund therefore grows in calm conditions and drains in violent ones, which is exactly the opposite of when you want a buffer to be large.</p>
<h3>How it differs from the bankruptcy price</h3>
<p>The bankruptcy price is the price at which the trader&#8217;s margin is exactly exhausted. Liquidation tries to close the position before that price is reached. If the market moves through it faster than the venue can close, the difference is the shortfall the fund exists to cover.</p>
<p>This is why the fund matters most for high-leverage positions in thin markets. Low leverage and deep books make shortfalls rare. High leverage and a gap make them routine.</p>
<h2>What an exchange insurance fund does not cover</h2>
<p>It does not cover theft, operational failure, insolvency, or your own losses. Those are separate risks with separate (often absent) protections.</p>
<div class="fog-table not-prose my-6 overflow-x-auto rounded-2xl border border-ink-200/70 bg-surface" data-fog-table><table>
<thead>
<tr>
<th>Event</th>
<th>Covered by insurance fund</th>
<th>What actually protects you</th>
</tr>
</thead>
<tbody>
<tr>
<td>Liquidation shortfall beyond your margin</td>
<td>Usually yes</td>
<td>The fund, plus the venue&#8217;s liquidation engine</td>
</tr>
<tr>
<td>Your position losing money normally</td>
<td>No</td>
<td>Nothing; that is the trade</td>
</tr>
<tr>
<td>Exchange hack or key compromise</td>
<td>No</td>
<td>Your own key hygiene and custody choices</td>
</tr>
<tr>
<td>Venue insolvency or withdrawal freeze</td>
<td>No</td>
<td>Diversification across venues and self-custody</td>
</tr>
<tr>
<td>Stablecoin or collateral failure</td>
<td>No</td>
<td>Collateral selection</td>
</tr>
</tbody>
</table></div>
<blockquote><p>The fund is not there to make you whole. It is there to stop one trader&#8217;s bad fill from becoming every trader&#8217;s bad fill.</p></blockquote>
<h2>Reading an exchange insurance fund&#8217;s published numbers</h2>
<p>Published fund sizes are indicative, not audited in the way a bank balance sheet is. Read them as a rough measure of buffer, and read the methodology before you read the number.</p>
<p>Three questions make a figure meaningful. What is it denominated in — one stablecoin, a basket, or the venue&#8217;s own token? Does the venue publish a live figure or a periodic snapshot? And is the fund actually segregated, or is it an accounting entry the venue can draw on for other purposes?</p>
<h3>Scale the fund against open interest, not against your feelings</h3>
<p>A fund of any given size means little without a denominator. Compare it to open interest on the same venue, and to the venue&#8217;s typical daily liquidation volume during volatile periods. A fund that looks large relative to a quiet day can look thin relative to a cascade.</p>
<p>None of these ratios are published consistently across venues, and definitions vary, so cross-venue comparison is approximate at best. Treat the comparison as a sanity check on order of magnitude rather than a precise ranking.</p>
<h2>What happens when the fund runs out</h2>
<p>Venues need a second mechanism, because a large enough move can exhaust any pool. The common answer is auto-deleveraging, usually shortened to ADL.</p>
<p>ADL closes profitable positions at the bankruptcy price of the failing position, ranked by leverage and profit. You do not choose it. It happens to traders who are winning, which is the part people find surprising: a correct position can be closed early because someone else&#8217;s position went wrong.</p>
<ol>
<li>Liquidation engines close the failing position and consume its margin.</li>
<li>If a shortfall remains, the fund absorbs it.</li>
<li>If the fund cannot absorb it, ADL closes opposing profitable positions at the bankruptcy price.</li>
<li>If that is still insufficient, the venue may apply a clawback or socialised loss across the book, depending on its rules.</li>
<li>Any of these steps can occur within seconds during a fast move, so read the venue&#8217;s rules before you need them.</li>
</ol>
<h3>A short worked example</h3>
<p>A trader holds a long with 500 units of margin at 10x, so the position is 5,000 notional. The bankruptcy price is 10 percent below entry. A gap takes the market 13 percent below entry before the engine can close. The loss is 650 against 500 of margin: a shortfall of 150. The fund absorbs the 150, the trader&#8217;s margin is gone, and no other account is touched. If twenty such positions fail in the same minute, the shortfall is 3,000, and whether the fund covers it depends entirely on its size at that moment.</p>
<h2>Using fund information sensibly</h2>
<p>Treat fund size as one input among several, and never as a reason to increase leverage.</p>
<p>The more useful signal is the venue&#8217;s overall risk design: how liquidation is triggered, whether ADL is disclosed clearly, how transparent the fund&#8217;s accounting is, and whether the venue publishes open interest and liquidation data. A large fund with opaque rules is less informative than a smaller fund with clear mechanics.</p>
<p>For your own positions, the practical controls are lower leverage, wider distance to liquidation, and collateral you can top up quickly. Those reduce the chance that you ever become the shortfall the fund has to cover.</p>
<p>The post <a href="https://www.fogment.com/exchange-insurance-fund/">Exchange Insurance Funds: What They Cover</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.fogment.com/exchange-insurance-fund/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
