Programmable payments

The European term for the same idea is the conditional payment. The Commission proposal for a digital euro defines a conditional digital euro payment transaction as one "instructed automatically upon fulfilment of pre-defined conditions". Article 24 lets the ECB set rules and standards that payment service providers can use for interoperable conditional payments, and lets it provide functions in the settlement infrastructure, including the reservation of funds.

The ECB drew the line early. In its hearing in the European Parliament it described conditional payments as automatic payments that people authorize when conditions of their own choosing are met, with rent as the example, and with no limit on what the payee does with the money. The same article that allows them says that the digital euro shall not be programmable money.

Most programmable payments in Germany today run without a blockchain. A standing order is the oldest form. Bank APIs under PSD2 let a company trigger a transfer from its own software, and variable recurring payments extend that to amounts that change within a mandate. The Federal Reserve Bank of Atlanta gives the API case as an example: the payment runs and the invoice is marked paid in the accounting system in the same step.

The second way is the smart contract. Funds are locked on a ledger and released when an agreed data source confirms the condition, which is how escrow and delivery-versus-payment pilots work. A hybrid checks the condition on a ledger and moves the money over an existing rail such as SEPA Instant. The Bundesbank tested this link between ledgers and central bank money with its trigger solution, which wholesale CBDC covers.

The clearest business cases are in supply chains and in usage-based pricing. A supplier is paid when the goods receipt is posted, or a leasing rate follows the hours a machine ran. Machine-to-machine payments and agentic payments are programmable payments in which software starts the transfer.

The limits are legal more than technical. A payment that runs automatically still needs the payer's authorization, and under PSD2 that means a mandate whose scope the bank can check. A condition fed by a data source also needs a rule for the case where the source is wrong, so dispute handling belongs in the design from the first day.

Programmable payments are transfers that run automatically when a predefined condition is met. The condition can be a date, an event in another system or data confirmed on a ledger. The money itself carries no restriction.

With programmable payments the payer sets a rule for when a transfer happens. With programmable money the rule is part of the money and limits how the receiver can spend it. The EU digital euro proposal allows the first and rules out the second.

No. Standing orders, bank APIs and payment platforms can run conditional payments over existing rails. A ledger becomes useful when the asset and the payment have to settle together, as in delivery-versus-payment.