When a bank considers building blockchain infrastructure in-house, the first estimates tend to revolve around engineering. The team maps out the required integrations, calculates development capacity, and sets a target for production.
Production changes the nature of the job. From that point forward, the bank is running infrastructure connected to blockchain networks that operate on their own schedules and under their own technical rules. Availability, security, upgrades, monitoring, compliance integrations, and incident response all become recurring responsibilities. The development budget covers the build. It doesn’t capture the full cost of operating what has been built.
Engineering Doesn’t End at Launch
An internal team needs to connect selected blockchains to the bank’s existing technology environment. Depending on the architecture, that can involve transaction processing, internal APIs, monitoring, compliance systems, security controls, and key-management infrastructure.
Each additional network requires its own integration work. Bitcoin and Ethereum, for example, differ in transaction structure, confirmation mechanics, node software, fee calculation, and other operational details. Engineers familiar with one network still have to account for the technical behavior of another.
The workload continues after an integration reaches production. Node software needs maintenance, internal interfaces may require updates, and changes to a blockchain can affect systems built around it. Supporting several networks means retaining enough network-specific expertise to deal with those changes as they occur.
Cost comparisons with a blockchain infrastructure provider need to account for that continuing workload. Developer salaries and external software costs are only part of the calculation. Staffing for maintenance, security, monitoring, and incident response can remain on the budget for as long as the bank operates the infrastructure.
Availability Requires an Operating Function
A node failure at 2 a.m. requires someone to respond, regardless of when the development team last touched the system.
Monitoring has to provide enough visibility to identify node failures, connectivity problems, stalled transaction processing, and other abnormal behavior. Once an issue is detected, someone needs to investigate it, restore normal operation, and determine whether any transactions were affected.
In practical terms, an in-house setup leaves the bank responsible for:
- Infrastructure availability and monitoring
- Security and key protection
- Network-specific integrations
- Upgrades and blockchain forks
- Incident detection and response
- Compliance integrations
- Ongoing maintenance
Transaction volume can influence capacity requirements, but it doesn’t make those functions optional. Even a relatively small production operation needs defined procedures for failures, security events, and network disruptions.
Key Management Changes the Security Equation
Cryptographic keys can authorize digital asset transfers, so their lifecycle requires controls designed specifically for that risk. An internal operation needs procedures covering key generation, storage, access, use, backup, and recovery.
Those procedures sit within a wider security environment. Access management, logging, vulnerability management, system hardening, and incident response still apply, while key-management systems introduce additional controls and dependencies.
Security teams also have to deal with an environment that changes over time. Employees change roles, permissions need adjustment, software is updated, and new threats emerge. Controls that were appropriate when the platform launched may need to be reviewed later as the infrastructure and its use evolve.
Network Maintenance Runs on Someone Else’s Clock
Public blockchains don’t follow a bank’s internal release calendar. Node software is updated, protocol rules can change, and forks may require infrastructure operators to make decisions according to timelines set by the network.
Engineers need to keep track of developments across every blockchain the bank supports. A new release may call for compatibility testing and a routine node update. Another change could require modifications to an integration or more extensive production testing.
Forks introduce a different operational problem because teams may need to determine how the infrastructure should handle the resulting network conditions. Whatever the required response, the bank needs the expertise to assess the event and implement the necessary changes without disrupting its own systems.
The maintenance load grows with network coverage. Supporting 10 blockchains means following 10 separate technical ecosystems, each with its own software, releases, protocol developments, and operational quirks.
Compliance Integrations Need to Keep Pace
Blockchain transaction processing has to connect with the bank’s compliance processes. Relevant systems need the information required to apply the institution’s controls, which puts compliance integrations directly into the production environment.
A change in a compliance process can require engineering work. New data requirements, modified controls, or changes in transaction handling may affect the integrations around the blockchain stack. Engineers then have to make those adjustments while preserving the stability of the underlying transaction infrastructure.
The organizational boundaries can become less clear in production. A network upgrade may require engineering and security input. A change involving transaction data may bring compliance into the same discussion. An incident can involve operations, engineering, and security at once. Running the stack internally means maintaining the people and processes needed to handle those overlaps.
The Cost of Building Is Only the Beginning
A bank can put a date and a budget against an implementation project. The longer-term commitment is harder to reduce to a single figure.
One year after launch, engineers still need to maintain network integrations and respond to protocol changes. Security teams still need to protect keys and review controls. Operations staff still need to monitor availability and handle incidents. Compliance integrations still need to work as the bank’s requirements develop. The same obligations remain 3 or 5 years later if the infrastructure is still in use.
For executives and industry professionals such as Pavel Kashuba, the relevant question extends beyond whether a bank has the engineering capacity to deliver an internal blockchain platform. The decision commits the organization to running it afterward.
That operating commitment is what makes an in-house build fundamentally different from a finite software project. The bank isn’t only funding an implementation. It is taking ownership of the engineering, infrastructure, security, integrations, monitoring, incident response, key protection, and maintenance required to keep the platform running year after year.
