Exchange and Wallet Data: Matching Deposits, Withdrawals and Ledger Records
Combine account-based exchange records with on-chain observations while preserving their different identities, timestamps and coverage boundaries.
Overview
When translating these concepts into an integration, keep the scope described by the normalized transactions api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
Exchange and wallet records can describe related activity from different perspectives. An exchange ledger may record an account deposit or withdrawal, while a network transaction describes technical movements and execution context. Their timestamps, identifiers and quantity conventions need not be identical.
A useful integration keeps both datasets intact and adds supported relationships between them. This helps a reporting application distinguish a confirmed match from a candidate, preserve fees and explain missing records. It also prevents equal amounts or familiar asset symbols from becoming an automatic cross-system identity rule.
Qualify exchange records by their account context
Retain the exchange account or connection identity with the native record identifier. Two customers or subaccounts can have similarly shaped records without sharing an ownership relationship. A service-level API credential does not replace the application's customer authorization checks.
Keep trade, ledger, deposit and withdrawal record types distinguishable. Their identifiers and quantity semantics can differ. The Kraken ledger documentation is one primary example of an account-based record contract. A generic connector should preserve the actual fields and scope supplied by its interface instead of assuming every exchange exposes identical history, pagination, fee conventions or timestamp meanings under one universal ledger schema.
Keep chain observations as separate technical records
A network transaction reference needs its network qualification and relevant movement identity. An exchange account entry may link to that transaction, but it is not necessarily identical to one network movement. One transaction can serve several records or include several relevant observations.
Preserve the original chain record and exchange entry independently, then record the supported relationship. This allows a consumer to inspect both sides even when one system later corrects descriptive metadata. A synthetic example can contain several ledger entries referring to a shared transaction. The match should not collapse them into one account entry or multiply a single observed movement merely because several related records point to its transaction reference.
Compare compatible quantities and fee conventions
A withdrawal amount, delivered amount and fee can be represented differently across systems. Keep native fields and units before deriving a comparison quantity. Do not assume that every interface's amount is either gross or net without reading its contract.
For a synthetic operation, a declared gross quantity of 100, a same-asset fee of 2 and a delivered quantity of 98 can reconcile under that explicit convention. Another interface may report the delivered amount directly. Preserve the rule used by the comparison. Fees in another asset require a separate unit-aware treatment. A match that relies only on formatted display values can hide rounding differences or a genuinely incompatible quantity convention.
Accept links using supported references and scope
A network reference, account relationship or documented transfer identifier can support a match. Equal quantities and nearby timestamps can help identify candidates but are not proof of identity. Retain which evidence accepted the link and which interpretation version applied.
Test two equal-sized deposits near the same time, only one of which has a confirmed counterpart reference. The workflow should preserve one accepted relationship and one unresolved candidate. Avoid silently merging both to make a comparison close. Where an identifier is missing, retain the missing prerequisite as a review question. A clear unresolved state is more useful than an apparently complete match whose evidence cannot be reproduced later.
Retain the meaning of each timestamp
An exchange timestamp can describe account processing, a status change or another event defined by its contract. A block timestamp describes a network observation. Preserve their separate meanings rather than overwriting one with the other to align a report.
Use a documented representation and timezone policy; RFC 3339 provides a primary format reference. A reconciliation window should retain its selection rule and actual accepted records. Test delayed account processing and a movement near an interval boundary. The application should explain why related observations appear in different time buckets without automatically declaring one missing or changing the original evidence to force identical dates.
Make connector imports and revisions repeatable
Retain requested scope, continuation and durable processing checkpoints for each account connection. A page arriving successfully does not establish complete account history. Repeated retrieval should preserve stable identities without duplicating accepted ledger records.
Test interrupted imports, missing pages, revoked access in an isolated fixture and a later corrected record. Keep secrets out of diagnostic exports and preserve account ownership through background processing. Useful exchange and wallet reconciliation provides compatible observations and inspectable relationships, not an automatic authority to rewrite balances. Downstream reporting can then apply its own classification policy using clear inputs, accepted matches and a list of unresolved questions whose causes remain visible across retries and revisions.
Questions about the topic
Frequently asked questions
Is an exchange ledger entry the same as a blockchain transaction?
Not necessarily. They are different records that can have a supported relationship. Preserve account-qualified ledger identity and network-qualified movement identity separately.
Can equal amounts and close timestamps establish a match?
They can identify candidates, but acceptance needs the documented evidence and scope. Keep ambiguous cases unresolved instead of merging similar observations automatically.
Why might matching records have different dates?
Their timestamps can describe different events, such as network observation and account processing. Retain both meanings and apply a documented comparison-window policy rather than overwriting either timestamp.
Standards & technical documentation
