Programmable Digital Money

“Programmable money” refers to three different things. Anyone who does not keep them apart is negotiating about something other than what the provider is offering — and notices only in the contract.

Three meanings in one word

The first meaning is the oldest and the least spectacular: the trigger is automated. A standing order pays monthly, a payment run in the ERP bundles due invoices, a rule releases amounts below a threshold without asking. The money involved is ordinary commercial bank money. What is programmed is not the means of payment but the prompt.

The second meaning is the one usually at stake today: the condition sits in a layer beside the money. A program checks whether an event has occurred and then triggers a payment. That can be a smart contract or a trustee arrangement along the lines of escrow. Here too the money is unchanged. What is new is that the condition is checked by machine rather than by a person.

The third meaning is the only one that touches the money itself: the rule sits in the amount. Such an amount can be spent only for a defined purpose, only within a period, only with certain recipients. That is the design of a voucher, not of money — and it is precisely where the political debate ignites.

Where the rule sits, the discretion sits

The table reads like a technical classification but is one about power. With each level, the ability to change a rule moves a step further away from the company.

A release threshold in your own system can be set differently on Monday than on Friday. A condition both parties agreed and lodged can no longer be touched unilaterally. That is both its purpose and its price. If the rule sits in the means of payment, the issuer decides and the payer has to accept it.

This sequence is the real subject of the topic. Reliability and discretion are the same quantity seen from two sides. Buying more commitment means giving up room to manoeuvre; keeping that room means getting no hard promise.

The trigger solution: programmable without changing the money

That the second level is not a future sketch can be shown with a German example. The Deutsche Bundesbank operates a connection, called the Trigger Solution, between market DLT platforms and the Eurosystem's payment system. An event on the platform triggers the corresponding payment. The booking happens on accounts in the T2 service — that is, in ordinary central bank money.

The solution goes back to a first version from 2021. The Bundesbank developed and successfully tested it back then together with Deutsche Börse and the German Finance Agency. In the Eurosystem's exploratory phase from May to November 2024 it was available alongside solutions from Banca d'Italia and Banque de France.

The point of it is the design. No new money was created in order to achieve programmability. The logic sits in the layer beside it, and settlement stays where it belongs.

The digital euro draws the line explicitly

The European Central Bank has separated the three meanings cleanly in its digital euro FAQ — and has committed itself. It describes programmable money as a digital form of money for a predefined purpose, comparable to a voucher. Limits apply to where, when and with whom it may be spent. The digital euro is expressly not meant to be that.

Conditional payments, by contrast, it is meant to carry. That is not a paper reservation: in the closing report on the preparation phase from October 2025, the ECB describes practical tests in a simulated environment. Among the things tried were the reservation of funds and waterfall mechanisms; the finding was that the current design can support conditional payments.

For terminology work this is the most useful statement on the subject. The institution issuing the money says itself that the second level is wanted and the third ruled out. Anyone discussing “programmable money” should therefore first establish which of the three meanings is intended.

What it means in plant engineering

A plant engineering firm supplies a production line for 2.4 million euros. The payment plan is staged: thirty per cent on design approval, forty after factory acceptance, the rest after commissioning at the customer's site. Today every instalment runs through invoice, review and payment run. Several weeks routinely pass between a milestone being reached and the money arriving.

As a conditional payment the same process looks different. The amount is reserved, and its release hangs on an event both sides agreed on beforehand — the acceptance protocol signed by both, for example. Once it exists, the money flows, and every step sits in the audit trail.

The gain here is not speed. It is that the dispute moves forward in time. Until now the argument about whether a milestone was reached happens after delivery. With a conditional payment, both sides have to agree beforehand on what evidences it, because otherwise the condition cannot be written. That agreement is the actual work, and it belongs in the contract negotiation, not in accounting.

From the CFO's perspective there is a flip side that is easily overlooked. A reserved amount is committed liquidity. It stops being available earlier than it would under an invoice with payment terms. What the supplier gains in security, the buyer pays in tied-up funds — and that belongs in liquidity planning before it goes into the contract.

Where automation gets expensive

The first risk is reliability itself. A badly written rule is executed just as reliably as a good one. The reviewing glance of a person used to sit at the end and now falls away. With it goes the last chance to spot a mistake before finality.

The second risk lies with the trigger, not the payment. Who tells the rule that factory acceptance has taken place? A person, a signature, a sensor, an outside system. The chain is only as strong as that evidence, and at design time it is routinely treated as given.

The third risk concerns the third level. Whoever can bind an amount to a purpose can later bind it differently. That is not a technical question but one of trust in the issuer — and the reason the ECB draws the line so clearly. For a company it means that earmarked funds are an instrument with their own fine print, not better money.

What remains

The word “programmable” says little on its own. It becomes useful only with the follow-up question of which of the three meanings is intended — and who can still change the rule afterwards. Two of the three levels are available today and require no new means of payment.

How the same mechanics turn into a business model in industrial data spaces, billed per data record and per event, is covered in Programmable Money in Data Spaces. And because every automated release is ultimately a signature, the question of who may provide it belongs beside it: Custody & Safekeeping.

For your own planning, then, the sequence matters more than the technology. First comes the agreement on what evidences an event. The payment is the easier part afterwards.