Crypto regulatory reporting: where data collection breaks
Reporting breaks not at the submission form, but earlier — where a transaction from the accounting system turns into a report line. A client is onboarded in one service, trades in a second, withdraws funds through a partner, and each has its own identifiers. Data collection for reporting begins with manually matching these records by email and phone.
A separate gap is between on-chain transactions and off-chain movements: fiat deposits and withdrawals, transfers between client accounts, and asset custody operations.
The FATF recommendations and local regulator requirements demand transaction traceability — an end-to-end line from payment to address and back.
As long as there is no link between a bank statement and a ledger entry, an analyst reconstructs it by time and amount, and the report becomes approximate.
The third area is the valuation point and the audit trail. Exchange rates are taken from different sources and at different times, amounts diverge by fractions of a percent, and the reconciliation total does not match.
It often turns out that access logs for client data are not written or are rotated: it is no longer possible to restore who edited a record and when.
All three have the same cost: submission turns into emergency reconciliation, and during an audit the company cannot show the origin of a figure. We build data collection with a single client key, change logging, and versioning of extracts — let's break down how this is closed.
What a unified reporting and transaction reconciliation loop provides
Reporting is assembled from different places: the exchange core, the custody module, clients' external wallets, and extract files from partner banks.
As long as each department provides data in its own format, transaction reconciliation turns into manually merging tables: discrepancies are found by eye, report preparation timelines stretch to weeks, and by the submission deadline no one can vouch for the completeness of the sample.
A unified data loop removes this gap.
Events from the blockchain and from internal systems are normalized into a single transaction model, where a record is identified by the pair "transaction hash + internal operation number." Transaction reconciliation becomes a comparison of two streams by a single key, rather than comparing extracts — a discrepancy is immediately tied to a specific ledger entry and a specific block.
Next, reporting automation turns on: scheduled regulatory runs, unified templates for each regulator, and input data quality control.
Completeness, uniqueness, and referential integrity rules filter out broken records before they enter the report, while address risk scoring via Chainalysis labels sources of funds before a ledger entry is created, not after.
The share of discrepancies falls from tens of percent to fractions of a percent, and period preparation fits into hours.
A separate class of extract failures is also closed. An idempotent run does not double ledger entries on a repeated launch, chain reorganization and a missing exchange rate at the time of the operation are handled by a rule, not an emergency scenario.
Any period is reproduced from the event log — when reviewing a regulator's request, it is clear which data and by which rule entered the report.
System design options: manual collection, automation, hybrid
The choice here is determined not by technology maturity, but by where the data currently lives: in the transaction log, custody accounting, or an internal ledger.
Regulatory reporting is not one form, but a set of slices by clients, transactions, and balances with different deadlines, formats, and levels of detail. Hence four realistic schemes from which to choose at the start.
| Option | When it fits | Limitations |
|---|---|---|
| Manual reporting collection | Few transactions, one-off submission, extracts are already done manually | Each reconciliation takes hours; a discrepancy in an extract is visible only at submission; no versions or change trail |
| Automated loop | Transaction volume is stable, data sources are localized, mapping rules are described | Requires a formalized data model and transformation rules; changing the reporting format means modifying the loop |
| Hybrid scheme | The main bulk is collected automatically, disputed transactions are handled manually | Need an exceptions queue and a review procedure — without them the manual tail grows |
| Outsourced reporting preparation | No in-house reporting team, deadlines are one-off or irregular | Responsibility for accuracy remains with you; data handling and access rules must be agreed in advance |
Practical rule: automate what repeats from period to period, and leave manual review for exceptions — transactions with a non-standard counterparty, amount splitting, or incomplete details.
A hybrid scheme almost always proves workable during the transition stage: the loop collects and reconciles the main bulk, and an engineer sees only those records that failed the rules.
Then it remains to decide how many exceptions are acceptable to keep in manual mode — and that determines where to go next.
Implementation stages: from data audit to handover of the loop
Reporting reconciles not when the form generator is ready, but when all the data it is assembled from has been described and reconciled. Below are the implementation stages we go through on every project: from source analysis to handover of the loop.
- Data source audit. We inventory everything involved in the calculation: network nodes, trading platform extracts, internal accounting, custody wallets. The output is a registry of sources with owner, completeness, and arrival latency.
- Data flow diagram. We trace the path of a transaction to the report line: where addresses and reference data are normalized, how records in the network and in internal accounting are matched, where exchange rates and fees diverge.
- Data model and aggregation rules. We version reference data, maintain an immutable transaction log, and incorporate recalculation for past periods — otherwise a methodology change turns into manual reconciliation.
- Report configuration. We map metrics to the regulator's form fields and add automated completeness checks and reconciliation of totals with accounting systems before extraction.
- Test run of the report. We run it on historical periods and compare with previously submitted forms; we investigate discrepancies down to the cause. The acceptance criterion is consistency across several consecutive periods.
- Procedure and monitoring. Generation schedule, notifications about incomplete data, run log, and roles — so that submission does not depend on one person.
- System handover. We hand over the loop with documentation, accesses, and team training, review typical incidents, and support the first submission periods.
The output is a reproducible process: the report is assembled according to procedure, and new requirements fit into the described scheme rather than requiring a rewrite from scratch.
Set of documentation and procedures for audit preparation
An auditor looks not at code but at the process: first of all, they ask how the report is generated, who has access to the data, and what confirms its completeness.
Therefore, at the end of the project, the client retains not only a working system but also an associated set of documents — it is used to operate the system, hand it over to a new team, and defend it during an audit.
- System documentation — component composition, deployment diagram, external dependencies, failure points, and recovery procedure after an incident.
- Data flow diagram — the path of a record from the trade source to the reporting mart: where data is normalized, at which step it enters the immutable log, and how double counting is excluded.
- Calculation rules description — mapping of source event fields to report metrics: handling partial fills, duplicates, exchange rate and transaction time discrepancies.
- Reporting preparation procedure — period close calendar, who confirms the completeness of the slice, when the extract is generated, and how to act when reconciliation diverges.
- Access policies — roles, record- and field-level permissions, procedure for granting and revoking access, and logging of administrator actions.
- Team instructions — how to bring up a local loop, run reconciliation on test datasets, connect a new data provider, and roll back a rules version.
- Data model and reference data — entities, transaction types, statuses, currency codes, and links to the counterparty registry.
- Rules version log — from which date each revision is in effect, so the report state can be restored for any past period.
The set is versioned together with the system: when rules change, the corresponding section is updated, so by the time of an audit the documents describe exactly the state that is running in the loop.
Case study: transaction reconciliation discrepancies reduced threefold
The client is a crypto exchange with a brokerage license: client assets are held in custody wallets, and part of trading is outsourced to external platforms.
Regulatory reporting was assembled manually — extracts from the trading core, wallets, and networks were merged into tables, and transaction reconciliation was done from logs.
It took nine business days to reach the first version of the report, and revisions after an audit stretched the deadline by another week.
What we changed
We separated three independent sources: the trading core, custody wallets, and network data itself. Each transaction was normalized to a single form and matched by transaction reference, addresses, and amount with a rounding tolerance.
Separate rules were introduced for internal transfers and fees so they would not enter the report as client fund movements. For address screening we connected Chainalysis — risk flags enter the same reconciliation rather than living in a separate file.
Results in numbers
| Metric | Before | After |
|---|---|---|
| Time to assemble the report to first version | 9 business days | 2 business days |
| Records not reconciling | 6.3% | 2.1% |
| Lines with manual edits | 68% | 12% |
| Investigation of one discrepancy | 30–40 minutes | 5–7 minutes |
The remaining 2.1% are not "noise" but a specific class of cases: exchange rate differences at the time of crediting and transfers between own accounts. After two closed periods, edits concerned only classification rules, and no new manual work appeared.
The report became reproducible: identical extracts produce an identical result, and the reconciliation trail is stored together with the report version.
How a regular report differs from a one-off extract on request
Scheduled submission is built around a procedure: the report form, data cut-off point, and submission deadline are known in advance.
One-off extracts on request do not work that way — the regulator names the period and question of interest, and only a few business days are allotted for the answer.
The difference between the approaches shows not in data volume, but in whether the system can restore state as of an arbitrary date.
In regular submission, the key is repeatability: the same period, reassembled from the transaction log, must produce an identical result.
Therefore, versions of reference data, exchange rates as of the transaction date rather than the report date, and rules for classifying transactions are fixed. Such a loop makes it possible to catch incomplete records and unclosed client files before the deadline, not after it.
A report on request tests the depth of history storage. If data on transactions and client checks is stored only in an operational storage with a short lifespan, there is nothing with which to restore the picture for a past period.
An archive is needed from which a one-off extract is assembled deterministically, with an access log and traceability from the report line to the source record.
Another difference is verifiability: scheduled submission is accompanied by reconciliations with custodian statements, checks for duplicates and transactions without confirmed address ownership, while an unscheduled request exposes gaps in address labels and manual edits in accounting tables.
In essence, regular submission is a contract on form and deadlines, while a one-off is a test of whether an immutable event log has been maintained from the very beginning.
Technical concerns: data, access, verifiability
Technical concerns about regulatory reporting come down to three things: where source data comes from, who retains access, and how to later prove that the figure in the report is the right one.
All of this is established before the first line of code: source schema, permission matrix, calculation traceability.
What access to our systems will you need, and who manages it?
Read-only, and only on loops with calculation data. Permissions are granted personally to an engineer, not to a "team," are described by a role matrix, and are revoked in one step — the log shows who had access to what. Keys do not move into our environments: work happens in your loop or on an anonymized copy.
What should be done if source data is incomplete or diverges between systems?
Before calculation, we profile extracts: share of empty fields, duplicates by key, amount discrepancies between the trading and accounting loops, broken timestamps.
We agree matching rules and source priority in advance, and every adjustment leaves a trail — otherwise the report formally reconciles but has no data behind it.
How can the verifiability of records be proven to an external auditor?
Every aggregated value can be decomposed down to primary records. We store the calculation rules version, the checksum of the input dataset, and the change log — recalculating on the same dataset yields the same result. A discrepancy is visible at a specific step, not "somewhere in the reporting."
Let's discuss the task: what is needed for an estimate and work plan
The timeline for implementing a regulatory reporting system is determined not by the volume of code, but by the state of the data and the number of external sources.
Therefore, project estimation begins with analyzing your current scheme: where transaction logs are stored, how clients are labeled, and which forms are already assembled manually. The fewer gaps in these places, the shorter the path to the first correctly submitted reporting.
To discuss the task concretely and come back with a work plan rather than a broad range, we need the following snapshot from you:
- List of reports and regulator requirements: forms, field composition, frequency, and submission deadlines.
- Data sources: exchange logs, custodian records, network transactions, internal accounting system.
- Client identification scheme and the "wallet — account — client" link for each jurisdiction.
- Field matching rules: how internal transaction statuses map to reporting form fields.
- Current process: what is prepared manually, where reconciliation is performed, who signs and submits documents.
- Access and limitations: test loops, regulator sandboxes, personal data retention policy.
- Checkpoints: for which reports we confirm correctness before production launch.
Based on this set, we assemble a work plan with stages, sequence, and implementation timelines — without hidden dependencies or reworking timelines midway.
The first practical step is reconciling historical data over a limited period: it shows the real effort more accurately than any rough estimate "by eye." Describe the task — and we will come back with an estimate and work plan.