Track realized and unrealized PnL across Binance, Bybit, and OKX while accounting for fees, funding, open positions, and capital transfers in one view.
A trader can be profitable on one exchange, underwater on another, and still have no clear view of the combined result. Each venue shows its own balances, open positions, realized profit, funding, and fees. The numbers are correct inside that account, but they do not explain the portfolio as a whole.
The need to track PnL across exchanges becomes more pressing once positions are linked. A spot holding on one venue may hedge a perpetual on another. Collateral moves between accounts. One leg closes before the other. Funding accrues on a schedule that has little to do with when the trade was opened.
Adding three headline PnL figures is not enough.
An exchange calculates PnL for its own products and account structure. It does not know why a position exists elsewhere.
One venue may show unrealized PnL based on mark price. Another screen may display the last traded price or let the user switch between reference prices. Realized PnL might include closing fees in one report while fees remain a separate ledger entry in another. Funding can appear under transaction history rather than beside the position.
Account structure adds more friction. Spot, futures, options, earn products, and subaccounts may have separate balance and history pages. Unified accounts reduce some of that separation inside one venue, but they do not consolidate data from other exchanges.
Currency creates another mismatch. A BTC-margined contract may report PnL in BTC, while a USDT-margined position reports in USDT. Converting both into dollars requires a price and a timestamp. Using today's BTC price to value last month's realized PnL changes the historical result.
This is why a combined PnL figure needs a consistent method, not just a calculator.
For active trading, net PnL is usually built from four separate components. They should remain visible even after they are combined.
Unrealized PnL measures what an open position has gained or lost relative to its entry price. It changes with the market and disappears or becomes realized when the position closes.
For a hedged trade, leg-level unrealized PnL can be misleading. A long position may show a large loss while the short position elsewhere shows a similar gain. The position pair is close to flat, but either account looks alarming in isolation.
The tracker should therefore show both the individual legs and the net result.
Realized PnL comes from closed or reduced positions. Partial closes matter. If half of a position is closed, part of the result becomes realized while the rest remains exposed to price movement.
A reliable tracker needs fill-level history rather than the current position alone. The current position tells you what remains. It does not reconstruct how much was opened, reduced, reversed, or closed along the way.
Spot PnL needs extra care because it depends on cost basis. If coins arrived through a deposit, the receiving exchange may not know their original purchase price. A trading dashboard can show position and execution performance without necessarily replacing tax-accounting software.
Trading fees are small per fill but can become material in high-turnover strategies. Maker rebates, taker fees, settlement charges, and conversion costs all change the net result.
Funding is even easier to miss. A basis trade can earn from convergence and still disappoint because the expensive leg paid funding for several days. The reverse is also possible: price PnL is flat, but received funding makes the trade profitable.
Funding should be attributed to the position and venue that generated it. Leaving it in a separate account ledger makes strategy-level analysis harder.
A deposit is not profit. A withdrawal is not a loss.
This sounds obvious, but portfolio charts often misclassify capital flows when they rely only on changes in account equity. Moving 50,000 USDT from one exchange to another reduces the first account and increases the second. The combined portfolio has not changed, apart from transfer fees.
Internal transfers between spot and derivatives wallets need the same treatment. They change where the capital sits, not how much the trading strategy earned.
A spreadsheet can track PnL across a few exchanges if trading is infrequent. Record the starting equity, add current balances, subtract deposits, add withdrawals, and adjust for open positions.
The method gets fragile once the account is active.
A partial fill changes the average entry price. Funding settles while the spreadsheet is closed. A fee is charged in a third asset. Collateral is moved to another wallet. One exchange exports timestamps in UTC, while a manual note uses local time.
The sheet also needs a rule for every edge case. How should it treat a position reversal? Which price converts BTC-denominated PnL into USDT? Does an internal transfer count at initiation or completion? What happens when one API or CSV export omits an old record?
Manual tracking can still work as a periodic reconciliation layer. It is not ideal as the live source of truth.
Read-only exchange APIs remove most manual data entry. They can retrieve balances, positions, fills, funding payments, and transfer history without giving the connected software permission to trade or withdraw funds.
The difficult part is normalization.
A tracker must map different symbols and contract formats, convert timestamps, identify duplicate records, and keep realized and unrealized PnL separate. It also has to preserve the original venue and account, because a combined number without drill-down is difficult to audit.
The sync process needs to handle rate limits and temporary API errors. If one account has not updated, its data should be marked as stale. Showing yesterday's position beside current figures from two other venues creates a number that looks precise but is not.
Historical storage matters too. Exchange APIs may limit how far back certain endpoints can query. Saving fills and funding records as they arrive reduces the risk of gaps later.
A useful PnL tracker should let the trader move between three levels of detail.
The portfolio level shows total equity, realized PnL, unrealized PnL, fees, funding, and net performance. This is the quick answer to whether the combined portfolio is making or losing money.
The venue level explains where that result came from. It should separate each exchange and account without forcing the user back into three native dashboards.
The trade level ties related positions together. A long and a short opened as one hedge should have a combined PnL, even when the legs sit on different venues. Each leg must remain available for inspection, including its fills, funding, fees, and liquidation distance.
The tracker should also make these states clear:
open profit versus profit already realized;
gross trading PnL versus the result after fees and funding;
trading performance versus deposits and withdrawals;
current data versus an account that failed to sync;
paired exposure versus an unhedged leg.
Without those distinctions, a unified dashboard can repeat the same confusion on a larger screen.
The value of consolidation is not the total alone. It is the ability to trace that total back to the positions and cash flows that produced it.
Consider a simple hedge. The long leg gains 4,000 USDT. The short loses 3,200 USDT. The gross spread result is 800 USDT. Trading fees cost 140 USDT, and net funding costs another 210 USDT. The trade made 450 USDT before any transfer costs or slippage not already included.
Looking only at the winning account suggests a 4,000 USDT profit. Looking only at the losing account suggests the strategy failed. The paired view shows the actual result.
The same logic applies at portfolio level. The tracker should consolidate data, then retain enough detail to explain every number.
ArbLens brings supported CEX accounts, perpetual DEXs, and on-chain wallets into one dashboard. It separates free and locked balances and shows open positions, fills, funding payments, PnL, and transfer history.
For arbitrage and hedged trades, long and short legs can be viewed as one position rather than two unrelated entries. The dashboard keeps the venue-level detail, tracks liquidation distance, and flags a leg that is no longer hedged.
ArbLens connects through read-only API keys. It does not require trading or withdrawal permissions and does not execute trades. The purpose is to make fragmented account data easier to monitor and reconcile.
This matters when a trade crosses venues. Instead of comparing separate PnL screens and manually subtracting funding, the trader can inspect the paired position and then drill down into its legs and account history.
Even an automated tracker should be checked when first connected. Start with one account from each venue and compare several items against the native interface:
current equity and available balance;
one open position and its entry price;
the latest realized PnL entry;
recent funding and trading fees;
one deposit, withdrawal, or internal transfer.
Check the reporting currency and timezone as well. A daily PnL report will not match another system if one closes the day at midnight UTC and the other uses local time.
After the initial check, investigate exceptions rather than rebuilding the portfolio every day. A stale sync, missing fill, unexplained equity change, or unpaired leg deserves attention. Small display differences caused by mark-price timing usually do not.
A combined number is useful only when the trader can audit it.
To track PnL across exchanges, keep realized and unrealized results separate, account for fees and funding, and exclude deposits and withdrawals from trading performance. For multi-venue strategies, calculate the result at the position-pair level as well as by account.
The three exchange dashboards still matter, but their separate records should resolve into one result that still shows its work.