Most digital asset initiatives in banking do not stall because of the network technology, but because of integration. According to The Financial Grid 2026, a survey of 638 executives, 88% of financial institutions have committed budget for digital assets, yet only 16% have reached production. Much of the gap between those two figures is the work of connecting what happens on-chain with the systems the bank already uses to operate, account and report.
This article describes that integration in practical terms: how on-chain operations map to core banking, how records are reconciled, how accounting and tax data are produced and which operational events need to be handled.
How an on-chain operation maps to the core
Every operation on the network has a counterpart in the bank’s systems. Designing the integration means defining that correspondence explicitly and without ambiguity.
- Client identity. The operation is linked to the client the bank has already identified. KYC does not change and no parallel identity is created; addresses or wallets are tied to the client’s internal identifier.
- Accounts. Each wallet, individual or omnibus, relates to the client’s accounts or to the bank’s technical accounts. In the omnibus model, the per-client breakdown lives in the internal ledger, not on the network.
- Cash movements. An investment involves a debit on the client’s currency account and, where applicable, a conversion into stablecoin. Both movements must be reflected in the core with the same operation reference.
- Positions. Digital assets and tokenised stocks are recorded as client positions, with quantity, cost and valuation, so they appear in the client’s overall position alongside other products.
The rule behind all of this is simple: the bank’s systems of record remain the source of truth for the client, for accounting and for the supervisor. The network is an additional record that must agree with them.
The reconciliation problem
Operations with on-chain assets rely on three records: the network’s, the infrastructure’s internal ledger (operations, positions and balances per client) and the core banking system. All three must match, and in practice they do not always match at the same moment.
The differences have known causes: operations awaiting confirmation, network fees not yet allocated, incoming movements without a reference, or timing gaps between the core’s end-of-day close and the network’s continuous activity. Reconciliation must distinguish expected, transitory differences from real ones.
The sound approach is therefore for the infrastructure to keep a complete history of operations and positions and reconcile it continuously with the network, while the bank defines the tolerance thresholds and the exceptions process: who reviews, within what timeframe, with what information and how the resolution is documented.
Accounting entries and valuation
The accounting model is the bank’s decision. The infrastructure should not impose a treatment; it should produce data in the format the institution needs to book its entries.
The minimum data per operation usually includes the execution and on-chain confirmation timestamps, the client, the asset, the quantity, the price, the amount in currency, bank and network fees, and cross-references to the core. With that information, the accounting team applies its model and books the entries in its own systems.
Valuation requires a defined pricing policy: sources, frequency, cut-off time and treatment of illiquid assets. The same policy should apply to pre-trade checks, to the position the client sees and to the accounting valuation, so that different areas do not diverge.
Tax and regulatory reporting
Directive (EU) 2023/2226, DAC8, introduces reporting obligations on crypto-asset transactions from 1 January 2026. The bank therefore needs a complete, traceable history per client: acquisitions, disposals, transfers and values at each point in time. If that history is built from day one with the right granularity, tax reporting is an extraction; if not, it is a reconstruction.
The same applies to regulatory reporting. The travel rule under Regulation (EU) 2023/1113 requires originator and beneficiary information on crypto-asset transfers, and Regulation (EU) 2022/2554, DORA, requires incident and ICT third-party management and records. In both cases, the bank produces the reporting from data the infrastructure must deliver complete and consistent.
Operational events the core does not know about
The network introduces events with no direct equivalent in traditional operations, and the integration must handle them explicitly.
- Network fees. Variable and paid in the network’s native asset. The bank must decide who bears them, how they are allocated and in which account they are recorded.
- Confirmations and finality. A submitted operation is not settled until it reaches the defined finality. The core must distinguish between initiated, confirmed and final.
- Failed transactions. An operation can fail after it has been initiated. Provisional movements in the core must be reversed in a controlled way.
- Continuous availability. The network runs 24/7; the core may have closing windows. The bank must define how out-of-hours operations are recorded.
Why deploy inside the bank
These integrations are simpler and safer when the infrastructure is deployed within the bank’s perimeter. Client and operation data do not leave the institution, keys are held in its HSMs, and integration is made directly against the core, monitoring systems and accounting, without external intermediaries. The bank’s systems of record remain the reference, and the bank retains operational and regulatory control.
For the same reason, a proof of concept should validate integration from the start, not only the operation on the network. These are the points worth checking:
- Linking wallets to the client’s existing identity and accounts.
- Reflecting each operation in the core with a unique reference.
- Reconciliation between the network, the internal ledger and the core, with thresholds and exceptions.
- Producing accounting data in the format the institution requires.
- A single pricing policy for checks, client position and valuation.
- A per-client tax history compatible with DAC8.
- Handling of network fees, failures and finality.
- Key custody in the bank’s HSMs and signing policies.
At Finhattan we work through this process alongside the bank’s team, always starting from a proof of concept; the details are in the solution and how we work.
For institutions wishing to review their own case, a technical conversation can be arranged through contact.