Enterprise blockchain: when it is justified and when a simpler alternative solves the problem better

A logistics operator is weighing a proposal of two hundred and fifty thousand dollars to connect its hauliers, customs brokers, terminals and cargo owners on a blockchain network. The promise is to end the manual reconciliation of documents and to have complete traceability without depending on a central entity. Nine months later the project has stalled, although the technology worked: three of the four hauliers would not run a server of their own, nobody agreed who would pay for storage, and the lawyers refused to share operating data with companies that compete for the same routes.

The case is a composite of situations we have seen in the sector, and its outcome keeps repeating for one reason: the question of how to implement blockchain came before the question of what trust problem existed between the parties.

Three conditions that must hold at the same time

The United States National Institute of Standards and Technology, NIST, reviewed the published decision diagrams on whether an organisation needs blockchain, and observed that most of the paths end in no (NIST IR 8202). Our filter gathers the questions in those diagrams into three conditions, and blockchain is justified only when all three hold at once:

• Several independent companies need to write to the same record.
• None of them accepts that another, or a single third party, should hold that record.
• The rules must be verifiable by all of them, without relying on the word of whoever records.

If one is missing, the answer is simpler: a relational database, a direct integration between the systems or a verifiable seal, which proves to a third party that a document has not changed since a given date. They are cheaper to run, and the relational database has been in production for decades.

What the closures of B3i, Marco Polo and TradeLens taught

Between 2022 and 2023, three of the most visible enterprise networks closed. B3i, the network of the large European insurers and reinsurers, filed for insolvency in July 2022 because it did not reach the volume that would justify further investment (Insurance Journal). Marco Polo, a network of banks for financing foreign trade, went into liquidation in February 2023, when its funds ran out (Global Trade Review). TradeLens, the Maersk and IBM platform for ocean shipping, came to cover close to half of the world’s container capacity (Supply Chain Dive), and even so Maersk announced its closure because full collaboration across the industry was not achieved (Maersk).

None of the three attributed its closure to the technology. In our reading, what failed at TradeLens was governance: much of the chain did not want to depend on a network run by one of the largest shipping lines in the world, which was also its competitor or its supplier. A consortium between competitors cannot start out under the control of one of them.

Five questions before the first specification

Before specifying anything, the consortium must have a written answer to five questions:

• Who pays for each participant’s servers. What works: a common fund with fees in proportion to use, and smaller partners connecting through the server of a larger partner or a neutral operator.
• By what majority a member is admitted or removed. What works: a qualified majority set in the statutes and written grounds for removal.
• How the business rules are changed without the network splitting. What works: an agreed release calendar and a technical committee with a quorum.
• How a piece of data that went in wrong is corrected, if nothing can be deleted. What works: recording a rectification linked to the original.
• Who keeps the history if the consortium is dissolved. What works: a complete, exportable copy for each partner, with its format and legal validity set in the agreement.

If the consortium cannot answer them in writing, the project is not ready, however good the technical demonstration was.

When a single company records, a verifiable seal is enough

In our experience, many cases put forward as blockchain projects have a single owner of the data: a terminal that records its weighings, a company that invoices its services. There is nobody to share the record with, and the real risk is internal: that someone with privileges alters a piece of data after it was recorded and erases the trail.

All that is needed is to compute the cryptographic fingerprint of each sensitive event at the moment it happens (a code that changes completely if a single comma is altered) and register it with a digital certification authority, which certifies its date and time. That dated fingerprint is the verifiable seal. Any later change becomes evident, even if the system administrator makes it. This is, in essence, what Estonia has used since 2012 with the KSI system, presented as a blockchain, to protect its public records on health, property and justice (Policy and Society).

Blockchain in public procurement: a precedent and a warning

In August 2026, Asoblockchain, the industry association, proposed to the Government that blockchain be used in public procurement, with the School Feeding Programme as the first case (Semana). The idea has a precedent. Between 2019 and 2020, the Inspector General’s Office, the IDB and the World Economic Forum, with engineers from the National University of Colombia, built a proof of concept to select the programme’s suppliers in Medellín. The Forum’s report concluded that, with the technology of the time, the case for implementing it was inconclusive (WEF report).

Corporate experience leaves a useful warning for that case. Blockchain guarantees that a record does not change after it is written, but it does not check that what was written is true. If whoever certifies a delivery and whoever charges for it collude, the network turns the fraud into a permanent record. The control has to come first: who certifies, with what evidence and which other sources it is checked against.

Before approving the budget, the question for the committee is what problem blockchain solves that cannot be solved better in another way.