Where an OKX Balance Sits: Funding, Trading and Earn Accounts

One login, several pockets

The mental model that causes the most support tickets on OKX is a single wallet with a single number. The platform does not work that way. It reports balances per account, and the accounts have different jobs.

Read from the balance response, the pockets are:

A second layer sits inside the trading account: the account mode. OKX documents four modes that change how collateral is shared across positions, which is a separate subject covered in OKX account modes explained. The point here is narrower — whatever the mode, the trading account is where the order is debited from.

The transfer is the missing step

Moving funds between the funding and trading accounts is an explicit operation, not something the platform infers. In the API it is POST /api/v5/asset/transfer, with the source and destination named by codes: 6 for the funding account and 18 for the trading account.

The documented properties are worth reading closely because each one is a place where an automated process fails:

• Permissions. Only API keys carrying the transfer privilege can call it. A key created for trading will not move funds.
• Directions. The endpoint transfers between funding and trading, and from the master account to sub-accounts. A sub-account can transfer out to the master by default; transferring to another sub-account requires the transfer-out permission to be granted first, and both must belong to the same master.
• Rate limit. Two requests per second, limited per user id and per currency. This is not a generous budget for a bot that sweeps balances on every fill.
• Confirmation. OKX states that the success or failure of the request does not necessarily reflect the actual transfer result, and recommends checking the transfer state with a separate endpoint. For a reconciliation job, that means reading balances after the transfer rather than logging the response as a ledger entry.

The last point is the one that changes how a system should be built. A transfer API that returns success is reporting that the instruction was accepted. The balance is the evidence.

Reading the balance response

The verification step needs the right fields, because a balance response reports several numbers per currency and only one of them answers “can I use this”.

A reconciliation that reads cashBal will overstate what the account can do; one that reads availBal answers the operational question. When the two differ, the gap is usually an open order or a pending operation rather than a missing transfer, which is the single most common reason a bot reports “funds lost” after placing a resting order.

The transfer’s own record is available too. OKX’s transfer-state endpoint takes either the transfer ID returned by the transfer call or a client-supplied ID of up to 32 alphanumeric characters, and returns the amount, the currency, the from and to account codes and a state. Passing a clientId of your own — a run identifier, say — makes the lookup possible from a log line rather than from a database row, which is what makes the “confirm by state, then by balance” habit practical at scale.

Deposits, withdrawals and the direction of travel

The rules on either end of the account point in opposite directions, which is the source of most confusion:

• A deposit arrives in the funding account, except where an entity rule says otherwise. A deposit also passes through states: OKX distinguishes “waiting for confirmation”, “credited but not yet withdrawable”, and “successful”, which is the state where the funds can actually leave. A credited-but-locked balance looks like money and behaves like a pending item.
• A withdrawal leaves from the funding account. The withdrawal documentation says so directly, and adds that a common sub-account does not support withdrawal at all. Funds in the trading account, or locked as margin, are not available to it.
• Regional rules override the default. OKX documents that users under some entities, Brazil named as the example, support deposit to the trading account only. That single line changes where a deposit lands, and therefore changes which transfer a bot has to perform before the funds become tradable.
• Internal transfers are the alternative to withdrawals. For currencies that carry a memo or tag, OKX recommends an internal transfer between OKX users instead of an on-chain withdrawal, which skips the network entirely and the memo risk along with it.

The memo mechanics, for the cases where an on-chain transfer is the right choice, are set out in deposit memos and destination tags. The two-stage delay — a venue-side hold before broadcast, then block confirmations — is what withdrawal holds versus confirmations separates.

Converting, earning, and where the interest settles

Two adjacent products reinforce the same pattern.

Convert operates from the trading account. OKX’s convert documentation states that only assets in the trading account are supported, so a conversion of a funding-account balance requires a transfer first.

Earn products subscribe from the funding account, and the documentation for at least one of them — Stable Rewards — states that rewards and redemptions settle to the trading account by default. That default is a design decision worth knowing: the principal leaves one pocket and the redemption arrives in another, so a user who expects the balance to return where it started will read the result as a partial loss.

The comparison between earn products, including what redemption actually costs in time and fees, is covered in OKX Simple Earn versus onchain earn. The account-routing question is upstream of that: no matter which product you pick, the principal has to be in the right pocket before the subscription is accepted.

A reconciliation habit that survives all of it

Because balances live in several places and transfers are asynchronous, the only reliable check is a full read. Four habits cover most of it:

1. Read every pocket, not the headline number. A balance response that reports one total is hiding the detail that decides what you can do.
2. Confirm transfers by state, then by balance. The endpoint exists; the balance is the proof.
3. Check the entity rule once per account. A deposit that lands in trading when the documentation promised funding is a regional difference, not a bug.
4. Separate “credited” from “withdrawable”. A deposit in the confirmation stage is real money that cannot move, and a plan that assumes otherwise will look like a platform failure.

None of this is unique to OKX, but OKX publishes it more explicitly than most: the per-account balance fields, the transfer rate limit, the asynchronous-result warning and the entity exception are all in the API reference, which is the right place to read them before automating anything. The withdrawal side of the same picture — the fee charged per network and why it is fixed rather than proportional — is set out in withdrawal fees versus network fees.

Risk note. Account structure, transfer rules, rate limits, withdrawal routing and entity exceptions in this article were read from OKX’s API documentation on 2026-10-30. Banking and entity rules change; the separation between funding, trading and earn has been stable. Nothing here is investment advice.