Fireblocks’ Financial Grid survey asked financial institutions what is hardest about building wallet infrastructure, the foundation of any digital asset operation. Compliance and regulatory requirements came first, at 52%. Integration with core banking systems followed at 47%, then security architecture and key management at 44% and 24/7 operational readiness at 39%.
Financial and regulatory reporting came last of nine, at 3%.
That makes sense to us. During the build, banks are working through the problems in front of them, in the order they arrive. The test of audit readiness arrives with the first close, the first audit and the first regulatory filing, and it arrives with a deadline attached. Regulatory appears at both ends of the chart: the requirement to operate compliantly leads at 52%, and the requirement to evidence that operation to auditors and regulators trails at 3%.
When reporting does arrive, the question is no longer technical. An auditor or a regulator asks: do the bank’s records agree with the chain, and who verified it?
Core Systems Cannot See the Chain
Integration with core banking systems sits second on that list for a reason. Core banking and general ledger systems were built to record money that moves between banks. They do not read a blockchain natively. Whatever the wallet holds, the books cannot see it.
This gap lands on specific desks. Finance cannot post a position the core does not hold. Operations has no ledger in the core to reconcile the wallet against, and internal audit has no record there to sample. This means that a bridge needs to be built. The bank needs a system of record that translates onchain activity into entries the core can post.
Why a Bank Cannot Certify Its Own Records
A bank can build that system of record itself. Operations can reconcile it to the custodian’s statement every day. However, neither step tells anyone whether the chain agrees. A self-built system of record and the custodian’s report both describe the activity second-hand, and a control that relies on the system it is testing has tested nothing.
Everywhere else in the bank, the bank’s own records are the evidence. An auditor who needs the detail behind a payment or a loan goes to the bank’s systems for it. Onchain activity changes that, because what settled is recorded on the chain, outside any system the bank controls, and the bank’s records hold only part of it. Pulling data straight from the chain does not close the gap either. Raw chain data has no SOC reporting framework around it, so an auditor cannot rely on it as evidence.
Risk and audit teams already know the principle from the rest of the bank. The team that runs an activity does not certify it, and the check comes from a source that this team does not control. Onchain activity does not suspend that principle, so the verified data an auditor relies on has to come from a third party that reads the chain directly and has certified controls around the data it produces.
When the bank’s records and the chain disagree, the bank does not decide on its own which governs. Regulators have already set some of the rules for how onchain activity maps to the bank’s records, and banks are still waiting on clarity for the rest. The chain records what settled, and a third-party check that reads it directly gives the bank an independent third position, whichever custodians and venues it uses. Operations routes the variance through the exception process, finance adjusts and documents the accounting record, and no one overwrites it silently.
What Third-Party Verified Financial Data Looks Like
Financial data counts as third-party verified only if four conditions hold. Together they separate evidence from a reporting feed.
1. Direct source: The party running the check reads the chain from nodes it operates itself, not through a custodian’s API or an aggregator. Raw custodian data is a copy. An auditor needs the original, collected under SOC controls.
2. Self-reconciliation: Before anything is compared to the bank, the sum of every transaction up to a date must equal the balance the chain reports for that date. That balance comes from an archive node, which keeps full history and can state any wallet’s balance at any past block.
3. Point-in-time answers: An auditor can ask for holdings by client, asset and wallet at close of business on any past date and receive an answer tied to a specific block. An audit trail of every action in the system and a roll-forward of each movement between opening and closing balance come with it. Auditors cannot pull this data from the chain themselves either. When they run their own checks against verified data, the bank’s figures are validated on both sides.
4. Certified controls: SOC 1 Type II covers how balance and transaction data is collected, validated and stored. That is why an external auditor can rely on the output instead of re-deriving it. Auditors generally rely only on data covered by a SOC report. A bank could put its own onchain data through that audit, but it is a long process for a single data set, and buying from a provider that already holds the report is faster and already trusted.
What the Bank’s Records Are Tested Against
With those four in place, the bank’s own records become usable. They can be tested against verified data from everything that holds or moves the bank’s assets, on and off chain:
- Blockchains
- Custodians
- Banks and open banking
- Trading venues and fintech rails
A control that covers only the custodian’s records misses the venue and bank legs of the same transaction. The comparison runs daily, at transaction and balance level, with exceptions routed to a queue under named ownership. Many banks also have to keep data on customer transactions in their own jurisdiction. Blockchain data is not held in any one jurisdiction, so the verified data has to be hosted where the bank’s regulators require it.
One System of Record Behind Reconciliation, Accounting and Client Reporting
When built from the chain, not from the bank’s own systems or the custodian’s reports, the same verified data can serve as the bank’s system of record and be delivered into its core systems. Three functions draw on it.
- Reconciliation: Operations and audit test the bank’s records against it daily.
- Accounting: Finance gets journal entries mapped to the bank’s own chart of accounts, with connectivity to any general ledger in the market. Cost basis applies under the bank’s accounting policy, with continuous valuation from the bank’s chosen pricing source. The data arrives by API, Snowflake data share, S3, or camt.053 (MT940) files, landing in the TMS, ERP or warehouse in the bank’s own jurisdiction, like any other financial data.
- Client-level reporting: Tax and regulatory teams get position by client, asset and wallet, evidenced from the chain and produced independently of the bank’s records. One system of record feeds every regime, so figures reconcile across them. The data set supplies the per-lot cost basis, proceeds and holding-period data behind 1099-DA, and prepares CARF and DAC8 output. The bank reviews and files.
Because all three draw on one system of record, finance, risk, compliance and operations look at the same numbers.
Start With One Use Case, Add the Next Without Rebuilding
A bank’s onchain financial operations have to carry their second and third use case without a rebuild, and so does the verification behind them. In our survey, banks start in different places: transaction banks with cross-border payments, digital banks with 24/7 settlement, commercial and private banks with treasury and liquidity. Wherever they start, the next use case is already on the list, and tokenized securities still scored high even at banks whose first priority is payments.
A bank should build its control layer once so that it only needs to change what sits on top of it, whether that is collateral pledging, deposit settlement or card settlement. The verification of the bank’s records has to work the same way. Each new use case brings new assets, counterparties and reporting requirements, and each extends the same system of record. A verification rebuilt for every use case reopens the audit conversation every time.
- Custody: Client holdings are reconciled daily to the chain by client, asset and wallet, so the bank can show that every client balance is backed onchain.
- Trading: Fills are tied out across venues and custody. P&L and cost basis are calculated under the bank’s accounting policy and posted to its ERP, with internal sweeps kept out of P&L.
- Tokenization: Mints, burns and redemptions in the issuance subsystem are reconciled to the chain and back to the core banking ledger, so issued supply, onchain supply and the books agree.
Western Union shows the sequence. In May 2026 it selected Fireblocks to provide the infrastructure behind USDPT, its U.S. dollar-backed stablecoin, starting with settlement with agents in the Philippines and Bolivia. The release describes the infrastructure as the foundation for a broader set of financial services.
Reporting is part of that first use case. Fireblocks’ financial data platform consolidates onchain data from USDPT’s wallet operations, treasury management and qualified custody, and translates it into Swift camt.053 and camt.052 (MT940 and MT942) bank statement formats, the formats Western Union’s treasury and finance systems already run on. USDPT operates inside Western Union’s reporting environment from day one.
That is the test of a bank’s first use case: whether the second can be added to the same reporting environment, with the same verification behind it, without starting again.
See how Fireblocks Financial Data turns onchain activity into entries your core can post.
Get a personalized demo
See how Fireblocks helps your digital asset business to grow fast and stay secure
