Blockwyse · 7 October 2026
The demo takes a week. The custody engine, the wallet, the dashboard all come together quickly. Then someone asks how the balances get into the general ledger, and the real project starts. We at Blockwyse have spent most of our time on digital asset programmes in that second part.
The 70% is our rule of thumb, not a measured figure, and on some projects it's higher. Either way, in a bank the new digital asset component is the smaller part of the job. Making it behave like part of the bank takes the rest.
Where the time goes
The ledger
Every crypto position has to appear in the general ledger and client books. Deposits, withdrawals, network fees, staking rewards and failed transactions each need a posting rule that finance signs off. The code is simple. Agreeing the rules takes weeks.
Reconciliation
The blockchain and your internal ledger will disagree, sometimes for dull reasons like a pending transaction or a reorganized block, sometimes for serious ones. You need automated reconciliation with breaks routed to someone who investigates. Under MiCA it has to work per client, because you must show client assets are segregated.
Identity and access
Who approves a withdrawal or whitelists an address? That has to run through the bank's existing identity system and access reviews. A separate set of logins will fail the first audit.
Reporting
Regulatory reports, client statements, tax data and the DORA register all need data from the new platform, in formats the bank already uses. Very little of it comes out of the box.
Monitoring and incidents
This is the one people remember too late. DORA gives a bank 4 hours from classifying a major incident to notify its supervisor. The platform's alerts have to feed the same monitoring and ticketing tools as everything else, or nobody sees them at 3 a.m.
Why it takes longer than planned
Architecture diagrams show a clean arrow to core banking. The arrow hides a batch file format, a nightly cut-off and a change freeze in December. Every integration also has a second owner with their own backlog, and most delays I've seen came from waiting for a slot in someone else's release. Controls need evidence too: in a bank, the reconciliation has to leave a record of what it found and who fixed each break. And a custody integration hasn't really been tested until a real withdrawal has gone through approval, signing, confirmation, ledger posting and the client statement.
How we plan for it
We deliver in five stages: architecture, integration, testing and readiness, cutover, and handover. A few habits matter most. We map the client's existing systems before designing the target. Each interface gets a named owner on both sides. We put an API gateway and event bus in early so there are fewer point-to-point links. Documentation and test evidence get written during the work. And we hand over a system the client's own team can run, with code they own.
Vendors lead with the demo because it looks like progress. On the programmes I've worked on, go-live dates were decided by ledger mappings, reconciliation breaks and incident feeds. That's what I'd ask a delivery partner about first.
Frequently asked questions
Why is integration the hardest part of digital asset projects in banks?
Each connection to the ledger, identity, reporting and incident systems involves another team, existing controls and evidence requirements. That takes longer than building the new component.
How does DORA affect digital asset integration?
The platform must feed the bank's incident detection and reporting process, which has a 4-hour notification clock, and its provider must be managed as an ICT third party.
Planning a build and want an honest integration plan? Our engineers will walk through your estate with you before anyone draws a target architecture. Start a conversation or see our delivery approach.
Sources: DORA (Regulation (EU) 2022/2554), Arts 17-19, 28-30; MiCA (Regulation (EU) 2023/1114), Arts 70, 75. General information only, not legal advice.
Disclaimer
Everything here is published openly and written for an undifferentiated audience. It describes markets, protocols, technology and risk, and presents facts separately from opinion. It contains no recommendations about crypto-assets, no price targets, no buy/sell/hold signals and no directional calls, and it is not tailored to the circumstances of any reader; nothing here is investment advice or a personal recommendation. We do not accept payment to publish coverage of any asset, protocol or venue, and neither the author nor any related party holds an undisclosed position in the assets discussed. Sources are cited where used; where none is cited, the analysis is the author's own. This note reflects the position as of the publication date and may become outdated. For more information: Terms of Service.
Transparency note
This article reflects our own views and conclusions. AI tools may have assisted with research, fact-checking, and language editing, but the content, opinions, and final judgment remain ours. Despite reasonable efforts to verify sources, errors or omissions may exist.