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.

• Sub-accounts separate margin and positions, but not always the custody risk of the venue itself.
• Most venues let you scope API keys per sub-account, which limits the blast radius of a leak.
• Transfers between sub-accounts are usually internal and free, unlike withdrawals to an external chain.
• Segmentation fails if the master account keeps withdrawal rights or shared collateral enabled.

What an exchange sub-account actually isolates

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.

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.

The four things that are separated

Balance, margin, positions and API credentials are what typically move into a sub-account. Each one has its own consequences.

• Balance — the collateral available to that container only. A loss elsewhere cannot touch it, and vice versa.
• Margin — leverage is calculated per account, so a heavily used strategy does not consume the borrowing capacity of a conservative one.
• Positions — netting happens within the container. Two opposing positions in different sub-accounts stay open instead of offsetting.
• API credentials — keys issued to a sub-account normally cannot read or trade the master account, which is the single most useful property.

What stays shared

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.

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.

Why separating risk with an exchange sub-account pays off

Because the most common account failure is not theft — it is one strategy consuming the collateral that another strategy needed.

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’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.

Operational separation beats mental separation

Keeping strategies apart “in a spreadsheet” is not separation. If they share one balance, one liquidation engine treats them as one portfolio. The engine does not care about your labels.

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.

How sub-account models compare

Models differ in where the boundary sits, and the differences change what you can safely automate.

Segmentation is only real when the failure of one container cannot reach the collateral of another. Everything else is bookkeeping.

Setting one up without creating new failure modes

Setup takes minutes, and the ordering matters more than the clicks.

1. Decide the boundary first: one sub-account per strategy, per client, or per risk budget. Mixed boundaries produce containers nobody can reconcile.
2. Create the sub-account and fund it with only the collateral that strategy needs, not a round-share of your total.
3. Disable master-level withdrawal rights over the sub-account if the venue allows it, or remove withdrawal permission from every key.
4. Issue a fresh API key scoped to that sub-account, with IP allowlisting where available and no withdrawal permission.
5. Set a notional cap in your own code as well, because venue-side limits are the second line of defence, not the first.
6. Record which key belongs to which container in one place, and test the separation with a small deliberate transfer.
7. Review monthly: dormant sub-accounts accumulate balance and become an unmonitored attack surface.

A simple allocation example

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.

The arithmetic is the argument. Containment converts an unbounded portfolio event into a bounded, pre-agreed loss.

Mistakes that quietly undo the separation

Most failures come from configuration drift rather than from the model itself.

• Shared collateral switched on for convenience, which links every container again.
• One master key reused across bots, so a single leak reaches everything.
• Sub-accounts used as a filing cabinet, with balances left idle in containers nobody watches.
• Withdrawal permission granted to a trading key “just in case”, which turns a trading bug into a full loss.

Each of these is reversible, and each is worth checking before the next deposit rather than after the next incident.

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.

The post Sub-Accounts: Separating Risk appeared first on FogChain.

That is a different risk from a debit card, and the difference only becomes visible in a downturn. A debit card that declines a payment is an inconvenience. A card secured by crypto card collateral that falls below its maintenance threshold will sell your coins, at the moment you least want to sell them, to repay a loan you may have intended to keep open.

• Collateral changes the failure mode. The card does not just stop working; it liquidates the asset behind it.
• Liquidation is mechanical. Thresholds are calculated automatically and rarely wait for a human review.
• The sale happens into weakness. Forced selling coincides with thin liquidity and wider spreads.
• The risk is measurable in advance. A single ratio tells you how far the price can fall before the selling starts.

What crypto card collateral actually secures

It secures an advance. The issuer lends fiat to pay merchants and holds your pledged balance as security, which means the balance is not yours to withdraw while the loan is outstanding. Understanding what is pledged, and at what ratio, is the whole of the risk assessment.

Pledged balances versus sold balances

On a conversion card, the balance is spent: coins are sold at settlement and the position shrinks. On a collateral card, the balance is locked: coins stay in place, a debt is created, and the position remains exposed to price. The second arrangement keeps your upside and adds a downside that did not previously exist.

Some programmes combine the two, converting for everyday spending and lending only above a threshold. The terms decide which mechanism applies to a given transaction, and the boundary is not always obvious from the interface.

The loan-to-value ratio

Loan-to-value is the debt divided by the value of the collateral. A 5,000 dollar advance against 10,000 dollars of collateral is a ratio of 50 percent. Two thresholds matter: the initial ratio, which caps how much you can borrow, and the maintenance ratio, which triggers a response when the debt becomes large relative to the collateral.

Because the denominator moves with the market, the ratio is not a fixed property of your account. It rises when the collateral falls, even if you never spend again.

How a downturn turns crypto card collateral into a forced sale

A downturn raises the ratio through the denominator. Nothing you do has to change for the liquidation condition to be met; the price does the work.

Maintenance thresholds and margin calls

When the ratio crosses the maintenance threshold, the programme either issues a margin call or liquidates automatically. Many crypto cards skip the call entirely, because the position is small and the monitoring is automated. Where a call exists, the notice period is often measured in hours rather than days, which makes it impractical to fund from a bank account.

What gets sold, and in what order

Liquidation sells collateral to repay part of the debt, usually until the ratio returns to a target below the threshold. The sale is executed at market, which during a drawdown means thin order books and wider spreads, so the realised price is worse than the quoted one. A penalty fee is commonly added, and it is charged in the same event.

The result is that you lose the coins at the low, keep a residual debt in some cases, and receive no benefit from any later recovery. That asymmetry is the cost of the leverage, and it is not covered by any cashback rate.

A debit card can only spend what you have. A collateral-backed card can spend what you have and then sell the rest to cover the difference.

Worked example: a 35 percent drawdown on a 5,000 dollar advance

Assume 10,000 dollars of pledged collateral, an initial limit of 60 percent, a 5,000 dollar advance, a maintenance threshold of 75 percent, and a 5 percent liquidation penalty.

The breach arrives at a fall of roughly 33 percent, not 35, because the threshold is met as soon as collateral drops below 6,667 dollars. The liquidation then sells about 3,143 dollars of collateral, repays roughly 2,986 dollars after the 5 percent penalty, and leaves 2,014 dollars of debt against 3,357 dollars of remaining collateral.

Compare the two cards on the same drawdown. A debit card holding the same 10,000 dollars would be worth 6,500 dollars and would still spend normally, with no debt and no forced sale. The collateral card ends the episode with 3,357 dollars of collateral, 2,014 dollars of debt, and a realised loss that a recovery in price cannot undo.

How to reduce liquidation risk on a collateral-backed card

The controls are simple and mostly about distance from the threshold.

1. Calculate the price fall that would breach the maintenance ratio: one minus the ratio of your current loan-to-value to the maintenance threshold.
2. Decide whether that fall is plausible within your holding period, and borrow well below the initial limit if it is.
3. Keep the borrowed amount under half of the initial capacity, which doubles the cushion before a breach.
4. Hold additional collateral in reserve that you can add without selling anything else.
5. Repay a fixed amount each month so the debt falls even if the price does not.
6. Set a price alert at the level that produces the breach, not at a round number that feels comfortable.
7. Read the liquidation clause for the penalty, the target ratio and whether a margin call is issued at all.

The post Crypto Card in a Downturn: Collateral and Liquidation appeared first on FogChain.