Dev.to Security 🔐 Cybersecurity Tue, 27 Oct 2026 08:51:41 +0000 👁 0 📖 11 min read

Do You Need a Blockchain? Ten Years of Banking Already Answered

Originally published on CloudTales, where the article also has an audio version. Every year or two, someone asks me whether a project should “go on the blockchain”. Sometimes it is a bank, sometimes a public body, and o

Originally published on CloudTales, where the article also has an audio version.

Every year or two, someone asks me whether a project should “go on the blockchain”. Sometimes it is a bank, sometimes a public body, and once it was a loyalty programme. The question always arrives with a lot of enthusiasm and very few requirements.

In financial services we no longer have to guess the answer. Banks, exchanges and central banks ran the experiment at scale for ten years, with real budgets. This post turns those results into a short checklist. Then it shows what I build when the honest answer is “no”: a tamper-evident ledger table on Azure SQL that you can try for free in about fifteen minutes.

The checklist

These are the questions I ask, in this order:

Most requests stop at the first or second box. The rest usually end at the last one: the client does not need a shared ledger at all. They need to show an auditor that nobody, including their own DBAs, quietly changed a record.

What ten years of banking says

In 2016 the World Economic Forum said blockchain would become the “beating heart” of the global financial system. [1] Here is how the big bets turned out.

Bet	Outcome
Rebuild an exchange's settlement on DLT	ASX cancelled its CHESS replacement in 2022 and wrote off A$245–255m before tax. [2] The replacement it chose in 2023 is a conventional platform. [3]
Bank consortia for trade finance	we.trade became insolvent in 2022, Marco Polo in 2023. Contour closed the same year; it was reportedly processing 60–70 transactions a month. [4]
Faster securities settlement	The US moved to T+1 in May 2024 [5] and the EU follows in October 2027. [6] Neither uses a blockchain.
Cross-border payments in seconds, not days	89% of Swift payments already reach the recipient's bank within an hour. [7] Swift is now adding its own ledger for 24/7 settlement. [8]
A bank's own payment network	JPMorgan's Kinexys handled over $2 billion a day in late 2024, next to about $10 trillion a day through conventional rails. [9]
Tokenised funds	BlackRock's BUIDL holds about $2.8 billion, in a tokenised Treasury market of about $15 billion. [10]
Tokenised money between central banks	Seven central banks and over 40 firms delivered a working prototype in Project Agorá. [11]

Three patterns stand out.

The winners are intermediaries. The original pitch was that a ledger would remove middlemen. The networks that actually carry volume are run by a global bank, by Swift and by central banks. Even R3, the bank consortium founded in 2015, now builds bridges to a public chain. [12]

Speed came from process, not ledgers. T+1 came from rule changes and automation. Payments are slow in the last mile, at sanctions screening, local clearing and cut-off times, and a new ledger fixes none of that. Swift's own data shows the gap: only 60% of wholesale payments reach the end customer within that hour. [7]

Consortia die of governance. The trade finance networks worked technically. They failed because every bank had to join at once, keep its own back office anyway, and pay for something the paper process already did well enough.

Where distributed ledgers did stick, an asset and its payment have to move together, around the clock, between parties that already share an operator. That is a narrow and real use case, and it is not the one most projects describe.

Three myths I still hear in meetings

“The network votes unanimously on every block.” It does not. Bitcoin follows the chain with the most proof of work, and permissioned ledgers need a quorum of validators. The design goal is to keep working when some members are faulty or dishonest.
“Blockchain encrypts the data.” It does not by default. Hashes and signatures make tampering visible; a public chain is readable by anyone.
“Put the KYC data on chain.” The EDPB's guidelines, finalised in 2026, say personal data should generally stay off chain. Store hashes or references instead, and choose another technology if you cannot honour the right to erasure. [13]

What I build instead: a ledger table on Azure SQL

Azure once had a managed blockchain service. Microsoft retired Azure Blockchain Service in September 2021. [14] What remained, and what I actually use, is ledger in Azure SQL Database, Azure SQL Managed Instance and SQL Server 2022 and later. Every transaction is hashed with SHA-256 into a Merkle tree, and each block of transactions is chained to the previous one. The latest hash, the digest, belongs outside the database, where a DBA cannot reach it. [15]

You can try it at no cost. The Azure SQL Database free offer gives each subscription up to ten serverless databases with 100,000 vCore seconds and 32 GB of data each per month. Set the database to auto-pause when the allowance runs out, and it never bills. [16] I created one with Microsoft Entra-only authentication and ran everything in the portal's Query editor.

az sql db create -g rg-ledger-lab -s <server> -n ledgerlab `
    -e GeneralPurpose -f Gen5 -c 2 --compute-model Serverless `
    --use-free-limit --free-limit-exhaustion-behavior AutoPause `
    --backup-storage-redundancy Local

Two things that cost me twenty minutes

On a subscription that has never used Azure SQL, az sql server create fails with MissingSubscriptionRegistration in every region, which looks a lot like a capacity problem. Run az provider register -n Microsoft.Sql --wait first. After that, West Europe and North Europe still refused a new server (“not accepting new customers”); Sweden Central accepted it. Remember that all free-offer databases in a subscription share the region of the first one.

1. A table that remembers

An updatable ledger table is an ordinary table with two options:

CREATE TABLE dbo.Account
(
    AccountId INT            NOT NULL PRIMARY KEY CLUSTERED,
    Owner     NVARCHAR (100) NOT NULL,
    Balance   DECIMAL (18,2) NOT NULL
)
WITH
(
    SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.AccountHistory),
    LEDGER = ON
);

INSERT INTO dbo.Account VALUES (1, N'Alpha Ltd', 1000.00), (2, N'Beta SA', 250.00);

Before touching anything, I took a digest, the fingerprint of the database at that moment:

EXECUTE sys.sp_generate_database_ledger_digest;

It is a small JSON document. This one covers block 0, the block that holds my two inserts:

{"database_name":"ledgerlab","block_id":0,
 "hash":"0xA4E6F87689936B87EF74738E65C3F851546B653BE1FA244EA93AF0BD80428014",
 "last_transaction_commit_time":"2026-10-26T19:48:03.3433333",
 "digest_time":"2026-10-26T19:48:44.0689525"}

In production you would not copy this by hand. The database writes digests automatically to immutable storage, which I come back to below.

2. A quiet correction, and who made it

Then I made the kind of change that ends up in fraud investigations:

UPDATE dbo.Account SET Balance = 9000.00 WHERE AccountId = 2;

The application sees only the new balance. The ledger view, generated automatically, shows the whole story:

SELECT t.commit_time AS CommitTime, t.principal_name AS ChangedBy,
       l.AccountId, l.Owner, l.Balance, l.ledger_operation_type_desc AS Operation
FROM dbo.Account_Ledger AS l
JOIN sys.database_ledger_transactions AS t ON t.transaction_id = l.ledger_transaction_id
ORDER BY t.commit_time, l.ledger_sequence_number;

The update is not stored as an overwrite. It appears as a DELETE of the old row (250.00) and an INSERT of the new one (9000.00), in the same transaction, with the exact commit time and the Entra identity that made it. I blurred my address here; in your database it is the real user principal name.

3. Trying to cover the tracks

A DBA's first instinct would be to clean up the history table, or to switch versioning off as you can on a normal temporal table:

DELETE FROM dbo.AccountHistory;
ALTER TABLE dbo.Account SET (SYSTEM_VERSIONING = OFF);

Neither works:

Cannot update ledger history table 'ledgerlab.dbo.AccountHistory'.
System Versioning cannot be altered for Ledger Tables.

And that was with the server admin account. The history is not a convenience copy that someone with enough rights can tidy up.

For data that should never change at all, such as audit events, an append-only ledger table refuses updates outright:

CREATE TABLE dbo.AuditEvent
(
    EventId   INT            NOT NULL,
    Detail    NVARCHAR (400) NOT NULL,
    EventTime DATETIME2      NOT NULL
)
WITH (LEDGER = ON (APPEND_ONLY = ON));

INSERT INTO dbo.AuditEvent VALUES (1, N'Limit raised for account 2', SYSUTCDATETIME());
UPDATE dbo.AuditEvent SET Detail = N'Nothing happened' WHERE EventId = 1;

The insert succeeds. The update does not:

Updates are not allowed for the append only Ledger table 'dbo.AuditEvent'.

4. Proving it to an auditor

Verification recomputes the hashes from the data and compares them with a digest you kept. My first attempt used a placeholder hash by mistake, which turned out to be the most useful screenshot of the evening. This is what an auditor sees when the data and the digest disagree:

With the real digest from earlier, the same call succeeds:

EXECUTE sys.sp_verify_database_ledger N'[
  {"database_name":"ledgerlab","block_id":0,
   "hash":"0xA4E6F87689936B87EF74738E65C3F851546B653BE1FA244EA93AF0BD80428014",
   "last_transaction_commit_time":"2026-10-26T19:48:03.3433333",
   "digest_time":"2026-10-26T19:48:44.0689525"}
]';

last_verified_block_id
0

The result is the last block the digest vouches for: block 0, which holds the two inserts. The balance change and the audit event live in a later block, so proving those needs a later digest. To finish the lab, I generated a fresh digest and verified against it in one batch:

DECLARE @latest TABLE (latest_digest NVARCHAR(MAX));
INSERT INTO @latest EXECUTE sys.sp_generate_database_ledger_digest;

DECLARE @digests NVARCHAR(MAX) = N'[' + (SELECT latest_digest FROM @latest) + N']';
EXECUTE sys.sp_verify_database_ledger @digests;

last_verified_block_id
1

Every block up to and including the one with the 9000.00 update now checks out. In a real system, a digest you just generated proves little on its own: its value comes from being stored somewhere the DBA cannot reach before anyone has a reason to tamper. That is why production setups write digests automatically to immutable storage instead of relying on someone to copy JSON.

Keep the two tools apart. Verification proves that nobody has altered what the ledger recorded. Whether a recorded change was legitimate is a different question, and the ledger view is where you answer it.

Tamper-evident, not tamper-proof

Someone with access to the underlying files could still change data. Ledger cannot stop that, but verification will detect it. In production, store digests automatically in Azure Blob Storage with an immutability policy or in Azure confidential ledger, so that nobody with database access can reach them. [15]

That is the property most “blockchain” projects I have reviewed were actually after: anyone can check the history, nobody can rewrite it unnoticed, and you need no consortium, tokens or new infrastructure. Your existing application, backups and SQL skills all still work.

The short version

Use a distributed ledger only when several organisations must move an asset and its payment together, and no operator they already trust can do it for them. In 2026 that means joining networks the market already runs, not building your own. For everything else, start with a database, and if the requirement is proof, make it a ledger table.

References

World Economic Forum (12 August 2016). Blockchain Will Become ‘Beating Heart’ of the Global Financial System. Press release. https://www.weforum.org/press/2016/08/blockchain-will-become-beating-heart-of-the-global-financial-system/
The Block (16 November 2022). ASX cancels years-long blockchain settlement and clearing system project. https://www.theblock.co/post/187809/asx-cancels-years-long-blockchain-settlement-and-clearing-system-project
Markets Media (20 November 2023). ASX Chooses CHESS Replacement. https://www.marketsmedia.com/asx-chooses-chess-replacement
Ledger Insights (1 November 2023). Blockchain trade finance network Contour to shutter. https://www.ledgerinsights.com/contour-blockchain-trade-finance-network-shutter/
U.S. Securities and Exchange Commission (21 May 2024). Chair Gensler statement on the upcoming implementation of the T+1 settlement cycle. Press release 2024-62. https://www.sec.gov/news/press-release/2024-62
A&O Shearman FinReg (14 October 2025). Regulation to shorten settlement cycle to T+1 published. Regulation (EU) 2025/2075 amending the CSDR. https://finreg.aoshearman.com/regulation-to-shorten-settlement-cycle-to-t1-publ
Swift (22 August 2023). Swift’s cross-border payments processing speed surpasses G20 target. Press release. https://www.swift.com/news-events/press-releases/swifts-cross-border-payments-processing-speed-surpasses-g20-target
Treasury Management International (29 September 2025). Swift to Add Blockchain-Based Ledger to Its Infrastructure Stack in Groundbreaking Move. https://www.treasury-management.com/news/swift-to-add-blockchain-based-ledger-to-its-infrastructure-stack-in-groundbreaking-move
Ledger Insights (6 November 2024). JP Morgan rebrands blockchain unit to Kinexys. https://www.ledgerinsights.com/jp-morgan-rebrands-blockchain-unit-to-kinexys/
Bitcoin.com News (31 August 2026). Blackrock’s BUIDL Hits $2.8B, Reclaims Treasury Crown. https://news.bitcoin.com/blackrock-buidl-2-8-billion-tokenized-treasury-crown/
Bank for International Settlements (27 May 2026). Project Agorá: a shared programmable platform for wholesale cross-border payments. https://www.bis.org/publ/othp110.htm
R3 (22 May 2025). R3 signals strategic shift to lead the convergence of public and private blockchains, through collaboration with Solana Foundation. https://r3.com/r3-signals-strategic-shift-to-lead-the-convergence-of-public-and-private-blockchains-to-deliver-internet-capital-markets-through-collaboration-with-solana-foundation
Slaughter and May, The Lens (21 July 2026). EDPB finalises guidelines on GDPR and blockchain. On EDPB Guidelines 02/2025 on processing of personal data through blockchain technologies. https://thelens.slaughterandmay.com/post/102ndb2/edpb-finalises-guidelines-on-gdpr-and-blockchain
Redmond Magazine (13 May 2021). Azure Blockchain Service Ending in September. https://redmondmag.com/Articles/2021/05/13/Azure-Blockchain-Ending-September.aspx
Microsoft Learn. Ledger overview (SQL Server 2022 and later, Azure SQL Database, Azure SQL Managed Instance). https://learn.microsoft.com/en-us/sql/relational-databases/security/ledger/ledger-overview
Microsoft Learn. Deploy Azure SQL Database for free. https://learn.microsoft.com/en-us/azure/azure-sql/database/free-offer