<?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>Operational Risk — tagged coverage - FogChain</title>
	<atom:link href="https://www.fogment.com/tags/operational-risk/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.fogment.com/tags/operational-risk/</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>Operational Risk — tagged coverage - FogChain</title>
	<link>https://www.fogment.com/tags/operational-risk/</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>Moving Between Exchanges Without Losing Money</title>
		<link>https://www.fogment.com/moving-between-exchanges/</link>
					<comments>https://www.fogment.com/moving-between-exchanges/#respond</comments>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Tue, 27 Oct 2026 19:21:59 +0000</pubDate>
				<category><![CDATA[Exchanges]]></category>
		<category><![CDATA[Capital Efficiency]]></category>
		<category><![CDATA[Crypto Exchanges]]></category>
		<category><![CDATA[Deposit Memo]]></category>
		<category><![CDATA[Network Fees]]></category>
		<category><![CDATA[Operational Risk]]></category>
		<category><![CDATA[Settlement Time]]></category>
		<category><![CDATA[Trading Spreads]]></category>
		<category><![CDATA[Transfer Between Exchanges]]></category>
		<category><![CDATA[Transfer Costs]]></category>
		<category><![CDATA[Withdrawal Fees]]></category>
		<guid isPermaLink="false">https://www.fogment.com/moving-between-exchanges/</guid>

					<description><![CDATA[<p>A transfer between exchanges is cheap when you plan it and expensive when you improvise. The cost has four parts: the withdrawal fee, the network fee embedded in it, the [&#8230;]</p>
<p>The post <a href="https://www.fogment.com/moving-between-exchanges/">Moving Between Exchanges Without Losing Money</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>A transfer between exchanges is cheap when you plan it and expensive when you improvise. The cost has four parts: the withdrawal fee, the network fee embedded in it, the spread you cross on both ends, and the price you miss while the funds are in transit.</p>
<p>Most people count only the first part. A transfer between exchanges that looks free at the withdrawal screen can still cost more than a percent once you account for the round trip through two order books and the hours your capital spent moving instead of working.</p>
<ul>
<li>Total cost is withdrawal fee plus both spreads plus the price move while funds are in transit.</li>
<li>Wrong network and missing memo are the two failures that lose funds outright rather than eroding them.</li>
<li>Send a small test transfer first whenever the route or destination address is new.</li>
<li>Compare moving the asset against selling, transferring the quote currency, and buying back.</li>
</ul>
<h2>Where the money actually goes on a transfer between exchanges</h2>
<p>Four cost lines apply, and only one of them appears as a fee on screen.</p>
<p>The withdrawal fee is what the venue charges to send. It often bundles the network fee, sometimes with a markup. The deposit side is usually free but not always. Then there is the trading cost: you sell on venue A at its bid and buy on venue B at its ask, paying two spreads. Finally there is the time cost — the interval when your capital is neither earning nor hedgeable.</p>
<h3>The two spreads, not one</h3>
<p>Arbitrage comparisons frequently count the destination spread and forget the origin. You pay both. If venue A&#8217;s book is thin, the sale itself moves the price, and that slippage belongs in the transfer&#8217;s cost, not in a separate line item.</p>
<p>For a large transfer, this dominates. A withdrawal fee of a few units is trivial next to a percent of slippage on the sale. Size the trade before you size the fee.</p>
<h3>The time cost nobody budgets</h3>
<p>Funds in transit are exposed to price movement with no ability to react. On a fast chain that is minutes. On a congested one, or during a venue&#8217;s manual review, it can be hours.</p>
<p>Estimate it explicitly: exposure equals position size multiplied by the expected move over the transit window. If you are moving 10,000 units and the asset routinely moves 2 percent in an hour, the expected cost of a one-hour transit is roughly 200 units of variance — often larger than every fee on the route.</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>Route</th>
<th>Cost profile</th>
<th>Speed</th>
<th>Main failure mode</th>
</tr>
</thead>
<tbody>
<tr>
<td>Native chain transfer of the asset</td>
<td>Withdrawal fee plus network fee</td>
<td>Depends on chain congestion</td>
<td>Wrong network selection</td>
</tr>
<tr>
<td>Stablecoin transfer</td>
<td>Similar fees, narrower price exposure</td>
<td>Comparable</td>
<td>Issuer or chain-specific liquidity issues</td>
</tr>
<tr>
<td>Convert to quote, transfer, rebuy</td>
<td>Two spreads plus fees</td>
<td>Comparable</td>
<td>Paying spread twice on size</td>
</tr>
<tr>
<td>Internal or off-chain transfer, where supported</td>
<td>Lowest fees</td>
<td>Fast</td>
<td>Availability depends on the venues</td>
</tr>
<tr>
<td>Leave assets and trade elsewhere with derivatives</td>
<td>Funding and basis costs</td>
<td>Immediate</td>
<td>Added instrument risk</td>
</tr>
</tbody>
</table></div>
<blockquote><p>The cheapest transfer is usually the one you did not need to make. Check whether the exposure can be adjusted on the venue where the collateral already sits.</p></blockquote>
<h2>Step by step: a transfer between exchanges without avoidable loss</h2>
<p>Follow the order below. Each step exists because skipping it has a known failure mode.</p>
<ol>
<li>Confirm the destination venue supports the asset on the network you intend to use, and check whether deposits are currently enabled. Support for an asset is not the same as support for every network carrying it.</li>
<li>Compare total cost across at least two routes, including both spreads and the estimated transit exposure.</li>
<li>Check the destination address and, where required, the memo or tag. Copy them from the destination venue&#8217;s deposit page at the moment of sending, never from history.</li>
<li>Send a small test amount first, confirm it credits, then send the remainder.</li>
<li>Whitelist the destination address if the venue supports it, and expect a delay before the first use.</li>
<li>Keep the transaction hash until the deposit credits, and monitor both sides rather than assuming the send completed.</li>
<li>Reconcile the received amount against the sent amount and record the real cost, so the next transfer is planned with a number instead of a guess.</li>
</ol>
<h3>A worked cost comparison</h3>
<p>You want 8,000 units of an asset on a second venue. Route one: sell on venue A at a 0.10 percent spread, withdraw the quote currency for a fee equivalent to 0.05 percent, then buy on venue B at a 0.10 percent spread. Trading cost is 0.25 percent, or 20 units on 8,000.</p>
<p>Route two: transfer the asset directly. The withdrawal fee is 0.30 percent equivalent, but you avoid both spreads — total 0.30 percent, or 24 units. Route one is cheaper by 4 units on paper. Now add transit exposure: route one is stablecoin, effectively no price drift; route two carries an hour of asset volatility, with an expected absolute move around 1 percent, or 80 units. Route one wins once the exposure is priced, even though its headline fee looks worse.</p>
<h2>Ways a transfer between exchanges loses money outright</h2>
<p>Fee erosion is gradual. These failures are not.</p>
<p>Wrong network is the common one. An asset can exist on several chains, and a deposit sent on a chain the destination does not support may be unrecoverable, or recoverable only through a manual process the venue may decline. The interface usually warns; the warning is easy to dismiss when you are moving quickly.</p>
<p>Missing or incorrect memo is the second. Some chains and some venues require a tag to route a deposit to the right account. Without it, the funds arrive at the venue but not at you, and recovery depends entirely on the venue&#8217;s process and its willingness to help.</p>
<p>The third is a stale address. Some venues rotate deposit addresses, and an old saved address may belong to a closed or reassigned account. Always take the address from the live deposit page.</p>
<h2>Making the decision cheaper next time</h2>
<p>Record the real cost of each route you use, including the received amount. In two or three transfers you will have a small table that beats any general advice, because it reflects your sizes, your venues and your timing.</p>
<p>Then reduce the number of transfers. Consolidating trading onto fewer venues, or keeping a working balance on each, usually beats optimising a route you use twice a month.</p>
<p>The post <a href="https://www.fogment.com/moving-between-exchanges/">Moving Between Exchanges Without Losing Money</a> appeared first on <a href="https://www.fogment.com">FogChain</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.fogment.com/moving-between-exchanges/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
