When a bank decides to offer digital assets to its clients, the first decision is not which assets to offer or on which network. It is who will own the infrastructure. That decision shapes control over keys and data, the relationship with the supervisor, the product margin and how easy it will be to change course a few years from now.
In practice there are three paths. Build the infrastructure from scratch with in-house teams, rent it from an external platform integrated through APIs, or deploy inside the bank an infrastructure that already exists and is adapted to its systems. None of them is correct in the abstract. This article describes what each one involves and the criteria that usually decide the choice.
Build: in-house development from scratch
Building means the bank designs and develops every component internally: key generation and custody, wallets, network connectivity, order execution, reconciliation with the core, monitoring and compliance. Some large institutions have taken this path. JPMorgan, for example, has developed its own blockchain infrastructure through Kinexys since 2015.
The advantage is full control. The institution decides the architecture, the pace and the priorities, and does not depend on anyone else’s roadmap. The drawback is cost and time. It requires a team specialised in applied cryptography, blockchain networks and custody operations, a scarce and expensive profile. And the project competes for resources with the rest of the bank’s technology initiatives for years before reaching production.
For most mid-sized institutions, building from scratch means devoting to infrastructure an effort the market does not reward: clients do not pay more because the bank wrote its own signing system.
Rent: a third-party platform via API
Renting means contracting an external platform that already offers the full service. The bank integrates its app with the provider’s APIs, and the provider handles custody, execution and network connectivity. It is the fastest way to launch a product.
The price of that speed shows up later. The client, their data and part of the margin flow through the provider’s platform. Keys usually sit in the provider’s infrastructure, not the bank’s. The product roadmap depends on what the provider decides to build, and changes in pricing or terms apply to all its clients at once.
Since January 2025 this dependency also has an explicit regulatory dimension. The DORA Regulation (Regulation (EU) 2022/2554) requires financial entities to manage the risk of their technology providers:
- Register of information covering every contract with ICT service providers (Article 28(3)), which supervisors use to identify dependencies and concentration.
- Documented and tested exit strategies for services supporting critical or important functions (Article 28(8)), with transition plans and assessed alternatives.
- Minimum contractual clauses on access, audit, data location and termination (Article 30).
A platform that concentrates custody, execution and client data is unlikely to fall outside the category of critical functions. The institution must be able to show the supervisor how it would exit without interrupting the service, and that is harder the deeper the integration.
Deploy: your own infrastructure, built by others
Deploying means installing an already developed infrastructure inside the bank’s perimeter, adapting it to its systems and operating it alongside its teams. Keys are generated and used in the institution’s HSMs, data stays in its systems and the product is offered under its brand and its licences.
This model combines part of the advantages of the other two. As with in-house development, the bank keeps control of keys, data and the client relationship. As with renting, it does not start from zero: the components exist and the work concentrates on integration with the core, accounting, KYC and the institution’s processes.
It requires more integration work upfront than an API connection, and a team that understands both the infrastructure and banking systems. That is why deployment is usually done with engineers who work inside the institution during integration and then in operation.
Comparing the three models
| Criterion | Build | Rent | Deploy |
|---|---|---|---|
| Key control | Full, in the bank’s HSMs | Usually the provider’s | Full, in the bank’s HSMs |
| Client data | Stays in the bank | Flows through the provider | Stays in the bank |
| Time to production | Long | Short | Intermediate |
| Internal team needed | Large and specialised | Small | Small, supported by the provider |
| Roadmap | Set by the bank | Set by the provider | Set by the bank |
| DORA exit strategy | Not applicable to the core component | Complex if integration is deep | Contained, the infrastructure lives in the bank |
| Product margin | Kept by the bank | Shared with the provider | Kept by the bank |
Modularity: the question that is often forgotten
Whatever the model, there is one question worth asking from the start: what happens when a component changes. The blockchain infrastructure market is young and moves fast. Providers of custody, liquidity, issuance and network connectivity change their pricing and terms, drop support for a network, are acquired by other companies or leave a market. When client keys, wallets and data sit on a third party’s platform, switching provider stops being a technical decision and becomes a migration of client assets, with its own operational risk and cost.
An infrastructure where each external provider is isolated in its own module can replace it without touching the rest of the system. An infrastructure where the provider is wired into every layer turns each change in terms into a project. When assessing any of the three paths, it helps to ask how much time and effort it would take to replace each component.
How to decide
A few questions help guide the choice:
- Where must the keys live? If the risk policy requires them to sit in the institution’s HSMs, renting is limited.
- Which functions will be critical or important? The more there are, the more the DORA exit strategy weighs.
- What internal capacity exists? Building without a specialised team lengthens timelines and increases risk.
- What margin should the bank keep? If the product is strategic for the client relationship, sharing margin and data has a long-term cost.
At Finhattan we work with the third model: we deploy the infrastructure inside each bank, integrated with its systems and HSMs, with our own engineering team supporting integration and operation. It is described in more detail in how we work and security and control. The DORA obligations that apply to technology providers are covered in MiCA and DORA.
For an institution weighing these options, the starting point is contact.