Every financial services executive I work with has a blockchain opinion. Some formed it in 2017 during the ICO mania and never updated it. Others formed it last quarter after a board member forwarded a McKinsey report. Neither starting point produces a useful strategy. What produces a useful strategy is a disciplined answer to three questions: what should we build ourselves, what should we access through partners, and what should we deliberately ignore?

That framework — build, partner, ignore — sounds simple. In practice, it is the decision most financial institutions get wrong, because the inputs required to answer it correctly cut across technology, operations, regulation, and competitive positioning simultaneously. Most blockchain strategies fail not because the technology disappointed, but because the institution made a build decision where it should have partnered, or a partner decision where it should have built, or — most commonly — tried to do everything at once and accomplished nothing at scale.

Why the Decision Framework Matters Now

Two years ago, a financial services leader could afford to observe. The production use cases were thin, the regulatory picture was incomplete, and the cost of waiting was low relative to the cost of getting it wrong. That calculus has shifted. Blockchain infrastructure is now operational — not experimental — in settlement, trade finance, cross-border payments, and collateral management. The institutions that built or partnered during the observation period are now running production systems with measurable economics. The institutions that waited are facing a catch-up problem that gets more expensive every quarter.

The catch-up cost is not primarily technical. Deploying a blockchain node or integrating with a distributed ledger network is a well-understood engineering exercise. The catch-up cost is organisational: the regulatory relationships that take eighteen months to establish, the operational workflows that need to be re-engineered, the internal expertise that cannot be hired in a quarter, and the partner ecosystems that have already consolidated around early movers. These are the assets that compound, and they are the ones that late entrants find most difficult to replicate.

This is not an argument for panic. It is an argument for precision. The build/partner/ignore framework exists to prevent both paralysis and overcommitment — to channel investment toward the decisions that will define your competitive position over the next five years, and away from the ones that will not.

When to Build: Proprietary Infrastructure as Competitive Moat

Build when the blockchain capability in question will become a core differentiator in your business — when owning the infrastructure gives you a structural advantage that cannot be replicated by buying access to someone else's platform.

The clearest build case in financial services today is in settlement and clearing. If your business depends on the speed, cost, and reliability of how transactions are settled, then the infrastructure that governs settlement is not a utility to be rented. It is a competitive asset. The institutions that have built proprietary or semi-proprietary settlement infrastructure — JPMorgan's Onyx, Goldman Sachs' Digital Asset Platform, HSBC's Orion — did so because settlement velocity and cost are directly tied to their margin structure. For these firms, outsourcing settlement infrastructure to a third party would be equivalent to outsourcing pricing.

The build case also applies when regulatory requirements demand a level of control over data, custody, and transaction processing that third-party platforms cannot guarantee. If your regulator requires that transaction data remain within a specific jurisdiction, or that custody arrangements meet specific segregation standards, building gives you the control to meet those requirements without dependence on a vendor's architecture decisions.

The cost of building is high — typically $5-15 million for a production-grade settlement or custody layer, with ongoing operational costs of $2-4 million annually. But for institutions where the capability is genuinely strategic, the cost of not owning it is higher.

"The build-versus-partner decision is not a technology question. It is a question about which parts of your value chain you are willing to let someone else control — and which parts you cannot afford to."

When to Partner: Speed, Optionality, and Shared Risk

Partner when the blockchain capability you need is important but not differentiating — when you need access to the functionality without the cost and timeline of building from scratch. This is the correct answer more often than most institutions are willing to admit.

The strongest partner cases are in areas where network effects dominate. Cross-border payments, trade finance consortiums, and multi-party settlement networks are all more valuable the more participants they have. Building a proprietary network for cross-border payments makes no sense if the counterparties you need to reach are already on an existing one. In these cases, the strategic value comes from early participation in the right network, not from building a competing one.

Partnership also makes sense when the regulatory environment is still moving. Locking in a proprietary technology stack when the compliance requirements may shift materially over the next 24 months creates re-platforming risk. A partnership with a specialist provider — particularly one that has invested heavily in regulatory flexibility — gives you the capability you need today with the optionality to adapt as the rules evolve.

The discipline here is in partner selection. The blockchain infrastructure market is consolidating fast. Three years ago there were dozens of credible enterprise blockchain providers; today there are perhaps eight to ten with the institutional backing, regulatory posture, and technical maturity to be viable long-term partners. Choosing the wrong partner is worse than building yourself, because you inherit their technical debt and strategic limitations without gaining the control that building provides.

The Settlement Opportunity: A Client Case

Last year we worked with a mid-market European trade finance firm that illustrates why the build/partner/ignore framework matters in practice. The firm processed cross-border settlements through four intermediary banks — a chain that had calcified over a decade of correspondent banking relationships. Each intermediary added cost, latency, and reconciliation overhead. Settlement on their highest-volume corridors took three to five business days. The firm's treasury team had accepted this as the cost of doing business.

We helped them evaluate and pilot a blockchain-based settlement layer. The question was not whether blockchain could accelerate settlement — that was well established. The question was whether the firm should build its own settlement capability, partner with an existing network, or continue with the status quo and invest elsewhere.

The answer, after a four-month assessment, was to partner. The firm's transaction volumes were significant but not large enough to justify the cost of proprietary infrastructure. More importantly, the counterparties they needed to settle with were already reachable through an existing institutional settlement network. Building a separate system would have required convincing those counterparties to join it — a sales cycle that would have taken longer than the technology build itself.

Through the partnership, the firm reduced its intermediary chain from four banks to one. Settlement on the target corridor moved from three-to-five days to same-day. The annual cost saving on that single high-volume corridor was approximately EUR 2.4 million — split roughly between direct intermediary fees, reduced FX exposure from faster settlement, and lower reconciliation overhead. The pilot took five months. The firm is now extending the model to three additional corridors.

The important detail is what the firm chose not to do. They did not build a proprietary ledger. They did not attempt to tokenise the underlying trade instruments — that was a different problem, for a different phase, requiring a different set of capabilities. They did not try to disintermediate all four banks simultaneously. They identified the single decision — partner on settlement infrastructure for one corridor — that would produce the largest measurable return in the shortest time, executed it, and used the results to build the internal case for broader adoption.

When to Ignore: The Discipline of Saying No

The most undervalued component of blockchain strategy is the explicit decision to ignore certain applications — not because they lack potential, but because they are not material to your business within a relevant time horizon.

For most financial institutions, decentralised finance protocols, public chain yield strategies, and speculative token economics fall into this category. They are interesting. They are developing. For a regulated institution with fiduciary obligations, they are not where your next dollar of blockchain investment should go. The risk of distraction is real: I have seen institutions spend twelve months evaluating DeFi lending protocols when the highest-return blockchain investment available to them was a straightforward upgrade to their settlement infrastructure.

Similarly, central bank digital currencies are important to monitor but premature to build for in most jurisdictions. The ECB's digital euro, the Bank of England's exploration, and the various Asian CBDC programs will eventually create new infrastructure requirements for financial institutions. But the timelines remain uncertain, the design decisions are unfinished, and the cost of maintaining CBDC-ready architecture before the specifications are stable is a poor use of capital. Monitor. Do not build. Revisit quarterly.

The ignore list should be reviewed regularly — what belongs on it changes as the technology, the regulation, and your competitive environment evolve. But the existence of the list is what prevents blockchain strategy from becoming an unfocused collection of pilots that consume budget without producing strategic position.

"The institutions with the best blockchain strategies are not the ones doing the most. They are the ones that made the sharpest decisions about what to do, what to access through others, and what to leave alone."

Building the Decision Capability

The build/partner/ignore framework is not a one-time exercise. The blockchain infrastructure market is moving fast enough that the correct answer for a given capability can change within eighteen months. An application that belonged on the ignore list in 2023 — say, tokenised collateral management — may now be a clear partner or build case. An application where you partnered in 2024 may have matured to the point where bringing it in-house is justified.

This means the most important investment is not in any specific blockchain application. It is in the organisational capability to make these decisions well and quickly. That requires three things.

First, a cross-functional evaluation team that includes technology, operations, legal, compliance, and business strategy. Blockchain decisions made by technology teams alone produce solutions in search of business problems. Decisions made by business teams alone underestimate technical and regulatory complexity. You need both perspectives in the room, with a mandate to make recommendations that the executive team will act on.

Second, a clear assessment criteria. For each blockchain capability under consideration, the team should be able to answer: What is the measurable business impact? Is this differentiating or table-stakes? What is the total cost of ownership for build versus partner? What is the regulatory risk profile? What is the competitive timeline — how long before this capability becomes a market expectation rather than an advantage? If these questions cannot be answered with numbers and evidence, the capability is not ready for a build or partner decision. It belongs on the monitor list.

Third, a willingness to move. The most common failure mode in institutional blockchain strategy is not making the wrong decision. It is deferring the decision until the options narrow and the costs increase. The European trade finance firm I described above could have started their settlement evaluation two years earlier. The economics would have been the same. They would now be operating on four corridors instead of one, with cumulative savings approaching eight figures. The delay was not caused by a lack of information. It was caused by a lack of decision-making structure.

Positioning for What Comes Next

The blockchain infrastructure layer in financial services is approaching a tipping point. The early production systems are proving their economics. The regulatory frameworks — MiCA in Europe, MAS guidelines in Singapore, the evolving UK sandbox — are providing enough clarity to act on. The institutional participants are no longer just the technology-forward banks; they include the asset managers, custodians, and market infrastructure providers whose participation signals that this is now standard competitive territory.

The question for financial services leaders is no longer whether blockchain matters. That debate concluded quietly while many institutions were still having it. The question is whether you have a decision-making framework that allows you to act with the right combination of speed and precision — to build where building creates advantage, partner where partnership provides access, and ignore where discipline prevents distraction.

The institutions that built that framework two years ago are now compounding the returns. The institutions that build it today will be well positioned for the next wave of infrastructure decisions. The window is not closed. But the cost of the framework — and the cost of the decisions that flow from it — increases with each quarter of inaction.