What a Binance account holds, and how we reach it

A Binance account keeps every fill, transfer and Earn subscription as a server-side record — reachable, with the account holder's authorization, through the same signed request protocol the app itself speaks. The interesting part for an integrator is not the price chart. It is the per-user ledger sitting behind the login: balances down to free-versus-locked precision, order records keyed by id and symbol, executed trades with fee and timestamp. That is the data this brief is about, and the authorized way to read it.

The app describes itself as the largest crypto exchange by trading volume, with over 300 million users and more than 500 listed cryptocurrencies (per its Play Store listing). For someone building a portfolio tracker, an accounting sync, or a compliance feed, the size of the catalogue matters less than the shape of one account's records — which is consistent and well-structured.

The route we would take: the account holder issues a read-only credential pair, and we implement the signed request protocol against it to pull balances, orders, trades and wallet history into a normalized interface. Native CSV export from the in-app Data Download Center covers anything better suited to a batch pull. More on why below.

Account surfaces that hold structured data

Each row below is a real surface a Binance user sees inside the app, mapped to what an integrator would do with it.

Authorized routes to the account's records

Three routes genuinely apply here. They are not interchangeable; each reaches a different slice with different durability.

1 · User-consented signed credential access

The account holder generates a read-only credential pair scoped to read user data, and we implement the documented signed request protocol — an HMAC-SHA256 signature over the query string, a millisecond timestamp, and an optional recvWindow (default 5000 ms, max 60000 ms per the documented request rules). This reaches balances, orders, trades and wallet history with high fidelity and is durable, because it rides a stable, versioned request contract rather than a screen layout. This is the route we would build on.

2 · Authorized interface integration / protocol analysis

For surfaces that the credential-scoped read does not cover cleanly — some Earn product detail, certain P2P views — we observe the app's own authenticated traffic under the account holder's authorization and reproduce the request and token flow. More effort, and it needs a re-validation pass when the front end shifts, but it closes the gaps the signed read leaves.

3 · Native CSV export (batch fallback)

The in-app Data Download Center exports transaction records, spot trade history and tax reports as CSV; per Binance's help documentation the download link is active for seven days and exports are capped at roughly fifteen per month. It is slower and human-triggered, but it is a clean, low-friction way to seed historical data on day one while the signed read handles the live feed.

For Binance, the signed credential read is the one to build the integration around — it is the only route that gives a programmatic, low-latency view of balances and fills, and it survives UI changes. Protocol analysis fills the few surfaces it misses, and the CSV export backfills history without writing a line of scraping code.

A signed read against the spot account

This is the shape of the core call — a signed account-balance read. Field names follow the documented request contract confirmed during the build; the signing step is the part that trips most first attempts.

import time, hmac, hashlib, urllib.parse, requests

API_KEY    = "<read-only key the account holder issued>"
API_SECRET = b"<matching secret>"
BASE       = "https://<account-data-host>"   # set during onboarding

def signed_get(path, params):
    params["timestamp"]  = int(time.time() * 1000)
    params["recvWindow"] = 5000            # reject if clock drift > window
    qs   = urllib.parse.urlencode(params)
    sig  = hmac.new(API_SECRET, qs.encode(), hashlib.sha256).hexdigest()
    url  = f"{BASE}{path}?{qs}&signature={sig}"
    r    = requests.get(url, headers={"X-MBX-APIKEY": API_KEY}, timeout=10)
    if r.status_code == 401:
        raise PermissionError("credential revoked or wrong scope")
    if r.status_code == 429:
        raise RuntimeError("rate limit hit — back off and retry")
    r.raise_for_status()
    return r.json()

# Current per-asset balances (free vs locked)
account = signed_get("/api/v3/account", {})
held = [b for b in account["balances"]
        if float(b["free"]) or float(b["locked"])]

# Executed trades for one symbol, normalized
fills = signed_get("/api/v3/myTrades", {"symbol": "BTCUSDT", "limit": 500})
ledger = [{
    "symbol": f["symbol"], "side": "buy" if f["isBuyer"] else "sell",
    "price": f["price"], "qty": f["qty"],
    "fee": f["commission"], "fee_asset": f["commissionAsset"],
    "ts": f["time"],
} for f in fills]

The two failure modes worth handling up front are clock drift (a stale timestamp outside recvWindow is rejected outright) and rate limiting (a 429 means back off, not retry harder). Both are in the delivered code, not left as an exercise.

What lands in your hands

Deliverables are tied to the surfaces above, not a generic checklist:

• OpenAPI specification for a normalized account interface — balances, orders, trades, transfers, Earn — so a caller queries one consistent shape regardless of which Binance surface a field came from.
• Protocol & auth-flow report documenting the HMAC-SHA256 signing scheme, the timestamp/recvWindow validation window, credential scoping, and the token flow for any protocol-analysis surfaces.
• Runnable source in Python or Node.js for the key reads — account balance, trade history, deposit/withdrawal history — with the signing, paging and error handling already wired.
• Automated tests covering signature correctness, drift and 429 handling, and the schema mapping from raw rows to the normalized model.
• Interface documentation plus data-retention and consent-record guidance, so the integration is operable and auditable, not a one-off script.

Authorization, MiCA, and the consent record

The working basis for everything here is the account holder's own authorization over their own data — a read-only credential they issue, scope, and can revoke without us in the loop. That basis does not hinge on any one licensing outcome. On the regulatory side, MiCA is the EU framework Binance has been seeking authorization under; reporting through early 2026 has its pan-European application pending in Greece, and the picture is still moving. We treat MiCA as where the rules may settle rather than a fixed obligation to cite as present-tense law, and we keep consent capture and logging portable so a jurisdictional shift does not break the build. In practice: every pull is logged, the credential scope stays read-only, data is minimized to what the use case needs, and an NDA covers the work where the client wants one.

Engineering details we plan for

A few things about Binance specifically that shape how we build:

• Clock discipline and the signing window. Signed reads reject any request whose timestamp falls outside recvWindow, so we build a server-time sync and a drift guard into the client rather than assuming the host clock is good enough. On a busy sync this is the difference between a clean run and a wall of rejections.
• Distinct record sets, one schema. Spot, wallet history, convert, and Earn are separate surfaces with different field shapes and paging. We scope each read independently and normalize them into a single account model, so the symbol-level paging on trade history and the asset-level shape of balances both arrive as one consistent interface to the caller.
• History backfill versus live feed. The CSV export and the signed read overlap. We design the seam so the seven-day export link bootstraps history once, then the signed read owns the live feed, with de-duplication on trade id and transfer txid so nothing is counted twice.

Access to a consenting account or read-only credential is arranged with you during onboarding — the build runs against that, so none of this is a hurdle you clear before we start.

Working with us, and what it costs

You hand us the app name — Binance — and what you want out of its data; we work out the route, build it, and deliver. The commercial side runs one of two ways. Source-code delivery starts at $300: you get the runnable integration, the spec, tests and docs, and you pay after delivery once you are satisfied with it. Or run it as a pay-per-call hosted API — we host the endpoints, you call them and pay only for the calls, with no upfront fee. Either way the cycle is one to two weeks. If you want to talk through which fits your case, tell us what you need and we will scope it.

Screens we mapped

Store screenshots we referenced while mapping the account surfaces. Select one to enlarge.

How this was put together

Mapped in June 2026 against the documented spot account and trade endpoints, the in-app Data Download Center export flow, and current reporting on Binance's MiCA application. Sources opened while writing this:

• Spot account & trade endpoints
• Signed request rules (HMAC, timestamp, recvWindow)
• Transaction history / tax export flow
• Binance & MiCA compliance reporting

Mapped by OpenBanking Studio's integration desk, reviewed 2026-06-19.

Other exchanges in the same integration picture

A unified crypto-account interface usually spans several venues. Same-category apps an integrator tends to meet alongside Binance:

• Coinbase — US-listed exchange holding spot balances, trades and transfer history behind a consumer account.
• Kraken — exchange with spot and margin records, deposits and staking positions per account.
• OKX — exchange and Web3 wallet with order, trade and funding history.
• Bitget — exchange known for copy-trading, holding spot and derivatives records.
• KuCoin — broad-catalogue exchange with sub-account balances and trade ledgers.
• Bybit — derivatives-heavy exchange with positions, orders and wallet history.
• Crypto.com — exchange and card app combining trades, Earn and card-spend records.
• Bitstamp — long-running EU exchange with spot trade and transfer history.

Naming them is about ecosystem reach, not ranking — each holds the same kind of per-account ledger, and a single normalized schema can front all of them.

Questions integrators ask about Binance data

Which account records can actually be reached, and at what granularity?

Per-asset spot balances split into free and locked amounts, individual order records keyed by order id and symbol, executed trades with price, quantity, fee and timestamp, plus deposit, withdrawal, convert and Earn subscription history. Each row carries a millisecond timestamp, so the data is fine-grained enough to rebuild a full position and cash-flow ledger rather than just a current snapshot.

Do you need the account password to read this data?

No. The account holder issues a read-only credential pair scoped to USER_DATA, and we sign each request with it. We never ask for or store the login password, and the credential can be revoked at any time without involving us. Access and the consent record are arranged with you during onboarding.

How do you handle the EU MiCA situation when the regime is still in flux?

The dependable basis for the work is the account holder's own authorization over their own data, which does not depend on the outcome of any single licensing decision. MiCA is the forward-looking EU framework Binance has been pursuing authorization under; we treat it as where the rules may settle, not as a fixed obligation we cite as present-tense law, and we keep the consent and logging design portable so a jurisdictional change does not break the integration.

Spot, P2P and Earn read differently — can one integration cover them?

Yes, but they are distinct surfaces and we scope them separately. Spot balances, orders and trades come from the signed account and trade endpoints; deposits, withdrawals and convert sit on wallet history; Earn and recurring-buy positions are their own record sets. We map each to a normalized schema so a caller sees one consistent shape even though the origins differ.