Development of a balance consolidation system across multiple exchanges

Why exchange balance aggregation breaks as turnover grows

While turnover is small, exchange balance aggregation relies on a simple scheme: a separate adapter for each venue polls balances, and the service adds them into an overall picture.

As the number of accounts and trades grows, polling can no longer keep up — some venues return data with a delay, and some rate-limit requests. A difference of a few seconds already creates a discrepancy, and the aggregator shows an amount that is not present on the venue.

Hence the first class of failures — balance desynchronization. A trade goes where the aggregator sees available funds, but the balance snapshot is stale, and the order is rejected due to insufficient balance.

When venue unavailability is added, the picture breaks entirely: the adapter is silent, while the service continues to treat the old balance as current and sends it to trading.

Then manual fund transfers kick in: an engineer opens venue terminals, reconciles positions by eye, and moves assets between exchanges. A single run takes hours, the transfer proceeds at its own pace, and the market moves away in the meantime. The more venues there are, the more the procedure depends on a specific person and their attention.

The root of the problem is the lack of balance convergence: the aggregator does not reconcile its data with actual data, does not mark stale values, and does not distinguish an empty balance from an unavailable one.

We explain how this is solved — from the data model and regular reconciliation to reallocating funds between venues without manual operations.

Consolidated balance accounting: what changes in daily work

Before consolidation, consolidated balance accounting relied on routine: exports from exchange dashboards, combining balances in spreadsheets, manual reconciliation of discrepancies after each transfer.

One missed step — and the account balance no longer matches the books, while investigation took half a day and still did not guarantee accuracy.

After moving to a unified liquidity loop, balances for each account are pulled into a single database, operations are recorded on a double-entry basis, and the history is immutable.

Balance reconciliation runs both on a schedule and on events — reconciliation time drops from hours to minutes, and discrepancies surface immediately rather than the next day.

The reduction in manual operations is the most noticeable effect: exports, spreadsheet recalculations, and visual reconciliation leave the daily cycle.

The ledger is maintained in PostgreSQL, where each transaction is linked to its source, so checking a balance is a query, not an investigation with correspondence.

Some failures are eliminated permanently: a repeated request does not create a second operation, a connection loss does not lose a balance — state is restored from the journal, and discrepancies with the exchange are caught by regular reconciliation. Error classes that used to be found after the fact are now cut off before they affect trading.

Methods of pooling funds: comparison of approaches

The choice of approach is determined not by interface convenience, but by how many venues are in the loop, what their withdrawal limits are, and how quickly the balance must return to work.

In practice there are exactly four schemes — from manual to an in-house settlement loop — and all of them run into the same venue limitations.

Venue limitations override any scheme: daily withdrawal limits, confirmation time, separate requirements for each legal entity, and for frequent transfers between own accounts — manual review.

That is why a scheme is chosen not for elegance but for the volume it can withstand without operator intervention.

How implementation proceeds: stages of engineering work

Each stage ends with a verifiable result, not a progress report. Exchange balance aggregation is a loop where a reconciliation error costs more than a release delay: an incorrect balance leads to an order rejection or, worse, opens a position twice.

That is why the work order is structured so that the current picture of fund flows is captured first, and only then is code written.

1. Fund flow audit. We inventory accounts and subaccounts, deposits and withdrawals, fees, internal transfers between the trading and settlement loops. The output is a map of where balances sit, with what delay they appear, and which operations change them without being recorded in history.
2. Fund flow scheme design. We bring balances from different exchanges into a unified accounting model: we separate available and frozen volume, spot and derivatives, determine the source of truth and the procedure for resolving discrepancies.
3. Reconciliation setup. We define polling frequency, the allowed delta threshold, matching transfers by transaction identifiers and hashes, and handling of confirmation delays. Reconciliation must converge on historical data before production mode is enabled.
4. Implementation and adapter connection. Rate limits, queues, retries, and operation idempotency — so that a network failure does not turn into a double transfer.
5. Acceptance checks. We run scenarios: balance discrepancies, loss of connection to an exchange, repeated transfer, stuck confirmation. We record how the system behaves and what goes into the journal.
6. Handover of procedures. We provide the account map, description of reconciliation rules, the procedure for discrepancies and version rollback — so that the on-duty shift can resolve an incident without a developer.
7. Support. Monitoring discrepancies with alerts, enhancements when a new exchange is added or withdrawal conditions change.

Flow diagrams, access policies, and handover procedures

After balance aggregation is launched, the client is left with a set of artifacts that their own team can use to maintain the system — without contacting us for every change.

Each document is tied to a specific failure class: balance desynchronization, a lost transfer, a change of responsible person, a dispute with an exchange over operation history.

• Fund flow diagram: deposit and withdrawal routes for each exchange and network, intermediate accounts, points where the balance may diverge, and mandatory reconciliation points.
• Access policies and roles: a "role — action — limit" matrix showing who initiates a transfer, who confirms with a second signature, and who has read-only access to the journal.
• Operation journal: an immutable record with identifier, initiator, time, and configuration version — any row can be traced back to the original request.
• Reconciliation instruction: step-by-step procedure for exporting snapshots by exchange, matching them with internal accounting, and rules for recording the result for audit.
• Discrepancy procedure: thresholds at which operations stop automatically, who makes the decision, and within what timeframe escalation goes up.
• Shift handover procedure: a checklist with mandatory items — open operations, limit deviations, withdrawal queue status.
• Monitoring map: which metrics are collected, which values are considered normal, who receives a deviation notification and within what timeframe.

Documents are handed over in editable form and versioned: when logic changes, not only the configuration but also related instructions are updated.

Case study: how balance convergence grew after consolidation

The client is a service that holds capital on three exchanges simultaneously (Binance and two regional venues).

Each venue kept its own records, and transfers between them were done manually based on morning exports: an operator matched amounts, waited for network confirmations, and manually closed discrepancies.

Reconciliation took 4–6 hours per day, and a discrepancy was discovered a day later — when the position had already moved the other way.

What it was like before consolidation

Discrepancies accumulated for three reasons. First, a deposit arrived with a delay of several confirmations, and the venue balance did not match the journal for some time. Second, operation statuses were named differently, so the same transfer was counted twice.

The third source was rounding on partial withdrawals: amounts converged within a percentage, but discrepancy control caught them as an error.

What was changed and which metrics were achieved

We assembled a unified accounting model: an append-only operation journal, an idempotency key based on the transaction hash, and normalization of statuses to a single reference.

Reconciliation runs at checkpoints every few minutes; a discrepancy above the set threshold immediately raises an alert linked to the operation.

• Balance convergence: 97.2% → 99.94%.
• Reconciliation time: 4–6 hours of manual work → up to 10 minutes to confirm the report.
• Share of operations without manual intervention: 38% → 94%.
• Discrepancy investigation: 3–5 incidents per week → 1–2 per month, each with a ready edit history.

Rolling back any balance change is now reproduced step by step from the journal — instead of searching for the cause in exports.

What to do if accounts are already spread across multiple systems?

Spread accounts are not a task of "putting everything in one pile," but a state that must be carefully preserved during the transition.

First we describe the current loop: which venues are connected, by which keys, where the free balance is calculated, and where it is locked under open positions.

Inheriting the old scheme is normal: there is no need to rewrite it entirely; the aggregator sits above it as a separate layer and continues to read the same sources.

The connection order is built from reading to trading. The first venue is connected in balance read-only mode; then we reconcile the snapshots with what the exchange itself shows and resolve discrepancies down to zero. Only after that do we enable the trading loop and repeat the cycle for the next venue.

Phased connection of venues provides predictability: at each step one new source appears in the unified picture, and it is always clear whose balance "drifted" if reconciliation did not converge. A failure on one exchange does not bring down the others and does not prevent order execution.

Balance migration proceeds in batches, not in a single move. We transfer each batch, reconcile on both sides, and only then take the next one — if there is a discrepancy, rollback affects one step, not the entire scheme.

Work does not stop: the old loop continues trading while the new one gains completeness, and the switch is made when the data converges.

Technical concerns before launch: common questions

Before launch, questions concern not features but system behavior in non-standard modes: loss of connection to a venue, different accounting rules, storage of access keys. Below are answers to the concerns that come up most often.

How are different venue accounting rules compared?

Spot, futures, and yield products calculate the available amount differently: some funds are locked under orders, some are in settlement, some are held as collateral.

We bring everything to a unified "available / locked / in settlement" model — the summary shows the manageable volume, not the sum of heterogeneous report fields.

Where are venue access keys stored?

Keys are issued with read and trade permissions; withdrawal of funds is disabled on the venue side. Storage is only on our infrastructure, encrypted, with separate permissions, an access log, and scheduled rotation: compromise of one key does not open access to assets.

What about discrepancies during transfer and connection of new venues?

Balance transfer is controlled by delta reconciliation: venue data converges with operation history; if there is a mismatch, the operation goes into quarantine until manual review.

A new venue is connected as a module on top of the common core — this takes days, not months, since the accounting and reconciliation logic is already implemented.

Let's discuss the task: how joint work begins

Discussion of the task begins with inventory, not with an assessment: to calculate the scope of work for exchange balance aggregation, we need to understand how many venues are in the loop, which assets circulate on them, and how the system will be used — for arbitrage, treasury, or market making.

At this step we need from the client a list of exchanges and priority pairs, withdrawal rules and account limits, access to venue test environments, and a person who makes decisions on disputed points.

Then the work proceeds in a transparent order — at any moment you know what stage the project is at and what the output will be.

• Task analysis. One or two meetings with your team: we capture scenarios, differences in venue response formats, and requirements for balance reconciliation accuracy.
• Assessment and work plan. We break the system into parts — data collection, normalization, local storage, interface delivery — and estimate each by effort.
• Team composition. We name engineers for specific parts, assign a person responsible for integrations and an escalation point.
• Stage timelines. We agree on a calendar with interim demos, not a single final show.
• Reporting format. Once a week — a short status: what was done, what is blocking, what was decided; access to the task tracker and test environment is open to you.
• Acceptance and handover. A run on historical data, reconciliation of balances with venues, handover of schemes and documentation to your team.

After the analysis, we come back with an assessment, plan, and team composition — then all that remains is to agree on the start.