The Clearing House picked a vendor. The hard part is the rulebook

The announcement is the least important decision

A payment network is not a piece of software. It is a set of promises about what happens when something goes wrong: who is out of pocket, at what precise second a payment stops being reversible, and what a small bank pays to sit on the same rails as a large one. The Clearing House has now named the software. Everything else is blank.

The item is short and the claim is large. The Clearing House, which operates payment systems used by American banks, has picked Quant, a British programmable-money infrastructure firm, to power a new interoperable network letting US financial institutions “of all sizes” clear and settle tokenised deposit transactions. Strip the adjectives and you have a vendor contract. The adjectives are the part worth arguing about.

A tokenised deposit is an ordinary bank deposit — your claim on your bank — recorded in a form that can be moved on a shared ledger and attached to conditions, so a payment can be made to execute only when a document arrives or a delivery is confirmed. The appeal to banks is obvious: it keeps the money inside insured deposits rather than migrating to instruments issued outside the banking system. The appeal is real. It is also not what determines whether the network works.

“Of all sizes” is a price, not a feature

The most consequential phrase in the announcement is the one that sounds like boilerplate. “Institutions of all sizes” is an access commitment, and access commitments are made in fee schedules, minimum volume requirements, technical certification costs and the terms on which a community bank can join through a third party rather than directly.

None of that is engineering. A ledger that is technically open to a two-branch bank in Oklahoma is closed in practice if joining requires an integration budget that bank does not have, or if pricing tiers make per-transaction costs fall sharply with volume. This is not hypothetical territory: the same week brought a Florida start-up bank opening on forty-three million dollars raised locally, and a Federal Reserve approval of one Oklahoma bank absorbing another. Those are the institutions the phrase is aimed at, and they are the ones with the least bargaining power over the terms.

So publish the terms. A network that intends to be universal should be able to state its price list before it states its technology stack, because the price list is the thing that determines whether universality happens.

Clear and settle are two different verbs

The summary says the network will let institutions “clear and settle” tokenised deposit transactions. Clearing is working out who owes what. Settlement is extinguishing the obligation. They are not synonyms, and conflating them is how payment systems accumulate hidden credit risk.

If Bank A’s tokenised deposit is transferred to a customer of Bank B, Bank B now holds a claim on Bank A. Something has to discharge it. Either there is an interbank settlement leg — in central bank money, on a defined cycle — or Bank B carries exposure to Bank A until one arrives. Both designs can be made to work. They are radically different products with radically different risk, and an announcement that uses one compound verb for both has told you nothing about which one is being built.

This is precisely the question a rulebook answers and a vendor contract cannot. Quant may build exactly what is asked of it. What is asked of it is the open question.

The case for doing it this way

The honest counter-argument is that this is how infrastructure actually gets built. You cannot draft a finality rule in the abstract; you need a working ledger to discover what finality even means on it. Standards bodies that write rules before anyone has run a transaction produce documents nobody implements. Pick a partner, build a pilot, then write rules that describe something real. The Clearing House has run production payment systems for a long time and knows this better than its critics.

There is force in that. But it cuts the other way too. Technology choices constrain rulebooks. Once a ledger is built with a particular model of how a token is held, transferred and frozen, the liability rules that can be written on top of it are already narrowed. The reason to publish a draft rulebook alongside a pilot is not legal tidiness; it is that participants can then tell you the design forecloses something they need, while changing it is still cheap.

And the pilot-first defence only works if the pilot participants are representative. If the institutions in the room while the rules are being discovered are the largest ones, the rules will be discovered to suit them, and the smaller banks will arrive later to a finished document and a take-it-or-leave-it fee.

What would make this credible

One test, available now: does the network’s governing document exist in draft, and can a bank that is not in the pilot read it? If the answer is no, the interoperability claim is a marketing statement about software rather than a commitment about rules — and the difference will show up years later, in who is connected and on what terms.