Risk reporting for a crypto fund: where manual reconciliations break down
The risk reporting loop of a crypto fund is assembled from heterogeneous sources: wallet and exchange account balances, trades, prices, staking and loan data.
Each source delivers data in its own format and with its own lag — exports via exchange interfaces, files from the custodian, edits in spreadsheets. Already here a bottleneck of the reporting loop appears: data reconciliation is done by people, not a system.
Manual data reconciliation depends on one or two analysts. They match positions, fill in missing transactions, and recalculate fund shares and risk metrics by hand.
While there are few accounts and instruments, this works; as the portfolio grows, one missed transfer or incorrect rate produces discrepancies in reporting that then spread through the entire chain — from positions to final metrics.
The most dangerous part is that a discrepancy surfaces late: during an investor review, an audit, or a fee calculation. Then the data is reassembled from scratch, and trust in the figures falls.
Industry sources such as Chainalysis provide address labeling but do not cover reconciliation with the fund’s internal accounting.
This creates three tasks: a unified data normalization layer, automated reconciliation checks, and reproducible calculation of risk metrics. We break down how this is addressed and what exactly removes manual reconciliation.
What risk reporting delivers: measurable effects for the fund
A single data source removes the main cause of discrepancies in crypto fund reporting: positions, trades, quotes, and reference data reside in one loop rather than being manually assembled from exchange exports, custodian data, and internal spreadsheets.
The report is built on the same mart as intraday limit control, so the figure in the operational summary and in the monthly form matches without manual reconciliations.
Report preparation time stops depending on manual assembly: risk reporting runs on schedule, and recalculation after data clarification takes minutes instead of a shift. The analyst spends time investigating deviations rather than reconciling spreadsheets.
Traceability of calculations means every figure can be traced to the original trade, rate, and methodology version. The value is recalculated from a stored set of input data, so the risk committee and auditor check not the finished result but the entire chain.
Data quality control is built into loading: checks for gaps, duplicates, anomalous quotes, and account balance discrepancies filter out garbage before calculation. An event that fails validation does not silently enter the report — it is flagged and sent to the source for review.
Resilience to source failures relies on the last reliable state: the loop continues calculating from it and marks the data as incomplete.
An exchange export failure or custodian data delay does not stop publication — the report is released with an explicit coverage note, and decisions are made on clear assumptions.
How to collect data for reporting: comparison of approaches
The boundary between manual work and calculation is the main decision in reporting, not the choice of tool. While there are three or four sources and a report is needed once a quarter, exporting to spreadsheets costs less than any implementation.
When dozens of wallets, exchange accounts, and custodian reports appear, manual reconciliation stops reconciling and cannot be reproduced from period to period.
| Option | When it fits | Limitations |
|---|---|---|
| Manual reconciliation and spreadsheet exports | One-off audit, isolated sources, simple strategies | Does not scale, no reproducibility, a formula error becomes visible months later |
| Industry accounting service | Standard assets and strategies, need a quick start | Closed calculation logic, narrow set of sources, cannot add your own risk metrics |
| Proprietary calculation layer | Dozens of sources, own risk metrics, provability of every figure | Requires development, data quality control, and support |
| Automated calculation plus sample-based manual reconciliation | Transition period until trust in automation is confirmed | Double work at the junction, need a process for investigating discrepancies |
We make the choice based on the source map and the list of metrics, not on how “modern” the approach is: first we describe where data comes from and at what frequency, then what exactly we calculate.
A proprietary calculation layer is justified when the report must be assembled using a single formula and reproduced down to the digit; manual reconciliation remains not an alternative but a control checkpoint on a sample.
How we implement the reporting loop: stages of work
The reporting loop is not installed on top of current processes: first you need to understand where data comes from and what happens to it along the way.
Therefore, implementation of the reporting loop begins with an audit of data sources — exchange exports, on-chain addresses, custodian reports, internal trade registries: the same fields in them are almost always described differently. Then the work proceeds in stages.
- Data source audit. Inventory: who provides data, at what frequency, which fields and in what form. We separately record what is still collected manually.
- Flow diagram. The path of a record from source to report mart: where it is normalized, where history is stored, how gaps and retroactive edits are handled.
- Setting up calculations. Definitions of metrics — counterparty concentration, liquidity, leverage, portfolio volatility — rounding and rate recalculation rules. Every figure in the report gets an unambiguous formula.
- Validation on historical periods. A run on past data and reconciliation with current reporting or manual calculations: we investigate discrepancies to the root cause rather than smoothing them over.
- Process and quality control. Reconciliations, discrepancy notifications, reruns, and a change log — the result must be reproducible.
- System acceptance and handover to the team. We test failure scenarios: unavailable source, retroactively corrected trade, connection loss. Then documentation, access rights, and training — the team handles routine edits without us.
What we hand over with the system: configurations and processes
A risk reporting system lives not only by code — its fate is decided by how clear the operating rules are. Therefore, we hand over the release as a single package: from the data flow diagram to the process by which the on-duty analyst publishes the next report.
- Data flow diagram — the path from quote and on-chain event sources through normalization to reporting marts: where data is cleaned and at what point loading most often breaks.
- Metric calculation rules — risk metric formulas, averaging windows, handling of gaps and weekends: the calculation is reproducible, and any discrepancy with the previous report is explainable.
- Report release process — the sequence from data snapshot to publication: control reconciliations, deadlines, responsible roles, and actions in case of failure at each step.
- Access matrix — which roles can see positions, limits, and counterparty data; rights of the analyst, risk manager, and external auditor plus an action log.
- Reporting documentation — description of each metric: source, aggregation logic, limitations. A new specialist enters the loop without developer explanations.
- Discrepancy reconciliation procedures — how the system flags incomplete or contradictory data and what the on-duty analyst does before a figure goes into the report.
The package is updated along with the code: a change in calculation does not pass without updating the process and documentation. Your team maintains the system independently, and we stay in touch for disputed cases.
Case study: how a fund reduced report preparation from a week to hours
A fund with several strategies prepared a monthly risk report for investors and the risk committee: exchange positions, custodian accounts, OTC trades, wallet movements, and counterparty checks via Chainalysis.
Each source had its own export format, its own update lag, and its own way of calculating the cost basis of a position.
What it was
The report took 6–7 business days to assemble: analysts reconciled exports in spreadsheets, manually searching for discrepancies in balances and cost basis.
Reconciliation between the source and the final version held at 92–94%, more than a hundred manual edits made it to release, and the auditor found some discrepancies — the document had to be reissued.
What it became
We built a unified data layer: nightly snapshots of positions and trades are brought to a single asset model and a single cost calculation formula, and every figure in the report stores a link to the source record.
Reconciliation rules are described as rules, not as analyst memory: a balance discrepancy above the threshold blocks release and goes into a review queue, so an error does not survive to the final version, and discrepancies are visible before publication, not after.
Report preparation takes 2–4 hours, manual edits are in the single digits instead of a hundred, and they concern only new instrument types for which no rule has yet been defined.
Data reconciliation is 99.9% for balances and calculated value, and a snapshot for any past date is reproduced from scratch, which removes the question “where did this figure come from.”
What to do if accounting is already deployed across multiple systems?
A conversation about accounting in a crypto fund almost always comes down to one thing: there is no single system.
Positions come from the custodian, trades and commissions — from trading exports, entries and accruals — from the internal ledger, account movements — from the treasury loop.
Everyone has their own formats: somewhere a fixed-width export, somewhere a nested paginated request response, somewhere a table with a delimiter that changes from report to report.
The first thing to record: accounting does not need to be consolidated into one system. A reconciliation layer over existing sources works — each system remains the source of truth for its own loop, while reporting and risk metrics are built on a normalized representation.
Such a layer, for example, removes the main pain of Fireblocks and similar custodian loops: they have their own position granularity, and it does not have to match the internal one.
Next, three engineering rules. An instrument is matched using a single identifier reference, otherwise the same asset arrives under three different tickers.
Each record is tied to a time snapshot, not to the moment of loading, otherwise end-of-day balances diverge by several hours.
Loading is made repeatable: raw exports are stored as is, the calculation is replayed from them, and a balance discrepancy above a given threshold becomes a separate break with an owner, not a silent adjustment.
Processes do not stop: reconciliation runs in parallel, the old period-close procedure is preserved until the new layer confirms its result over several cycles. Migration is done loop by loop — first trading data, then the custodian layer, then treasury.
Manual re-entry between systems does not disappear immediately, but as each source begins to reconcile automatically.
Frequently asked questions about the reporting loop design
Questions about reporting usually arise not at launch but during the second or third close cycle — when figures for past periods stop reconciling with current ones. Below we have collected the technical concerns that most often surface before the loop starts.
Why can figures for the same period diverge on recalculation?
The calculation relies only on an immutable snapshot of input data fixed at the time of period close. If a source later sends a clarification, it does not overwrite the previous report but appears as a separate adjustment line indicating the source and value. As a result, any discrepancy is always explainable and does not look like a calculation error.
What happens if a source is unavailable or delivers data with a delay?
Collection goes through a queue with retries and increasing intervals; until recovery, the last verified snapshot is used. A period collected incompletely is marked as partial — gaps are not filled with zeros, otherwise the report looks plausible but is incorrect.
A separate metric shows how many periods are fully closed and which sources are systematically lagging.
How can you verify the correctness of calculations after a methodology change?
The methodology is stored with versions, and when it changes, historical periods are recalculated in parallel with current ones in shadow mode. Results are reconciled line by line: discrepancies above a given threshold are not published until the cause is investigated. The output includes a reconciliation protocol — it is attached to the report itself.
How is access to data segregated?
Access is separated by levels: summary metrics, position-level detail, external export. Part of the team sees only aggregates without counterparties; exports and methodology edits are logged; rights are granted on a least-privilege basis and reviewed when roles change.
These four topics cover most doubts at the contractor selection stage; the rest are particulars that are addressed using the fund’s specific data.Let’s discuss the task: where to start with the reporting loop
We suggest discussing the task concretely — starting with an audit of the current reporting loop. We look at which data sources already exist (exchange exports, wallet movements, brokerage accounts), how balances reconcile in them, and where discrepancies arise.
This shows the scope of work faster than any general conversation: you can immediately see what can be migrated as is and what will have to be built anew.
Starting with an audit is also advantageous in terms of timelines. It takes limited time and checks whether the requirements for the loop are realistic — for example, daily portfolio valuation with fragmented sources.
After the audit, the timeline estimate stops being a range “from and to” and becomes a plan with stages.
Based on the results, you receive:
- a map of data sources and ways to obtain them regularly;
- a list of risk metrics and calculation rules — what will go into the report;
- an implementation plan by stages with dependencies between them;
- an estimate of timelines for each stage and the team composition for it;
- a diagram of the reporting loop: calculations, integrity control, access segregation;
- a list of decision points where your input is needed — report frequency, history depth, recipient roles.
Describe the task: which assets and strategies we cover, who receives reports and in what form, which checks are mandatory. We will come back with a timeline estimate and an implementation plan where the first step is an audit of your data.