The Condition Is Not the Currency
Programmable payments and programmable money are often treated as two names for the same technological ambition. They are not. This series examines the difference through a precise question: does a condition govern the movement of ordinary money, or does it become a restriction attached to the monetary asset itself? The answer determines what a recipient can accept, transfer, or spend—and gives us a way to judge Project Agorá’s wholesale payment design and the legal choices surrounding central bank digital currencies.
The distinction matters because money is not valuable merely because a computer can record it. People accept ordinary money without inspecting each unit, asking where it came from, or checking whether the next person will take it. A new digital instrument may be fast and technically sophisticated yet still be a poor substitute for money if every recipient must investigate its conditions. The central challenge is therefore not to make money “smart” in the abstract. It is to add useful conditional behavior without quietly turning the thing received into a restricted claim.
The promise of conditional money—and the hidden question
A conditional payment is easy to imagine. Rent could move automatically on a specified date. A payment could be released when goods arrive. Two sides of a foreign-exchange transaction could settle together instead of relying on one party to pay first and trust the other to follow. These arrangements use rules to coordinate a transfer. The rule may check a date, an event, a confirmation, or the completion of another leg of the transaction.
The same digital machinery could be used for a different purpose: to create money that can be spent only on certain goods, by certain people, or before a deadline. In that case, the condition does not end when the payment is made. It travels with the asset. The recipient may receive something that looks like money in a ledger but behaves more like a certificate with special rights and limits.
That is the hidden question behind the title. When a payment instruction succeeds, does the recipient receive basic money that can be used without restriction, or a programmed object whose use remains conditional? Looking only at the presence of code cannot answer this. A ledger, token, or smart contract describes how a system operates; it does not by itself tell us what legal or economic object has changed.
The distinction is already visible in the work of the New York Fed, which frames digital monetary systems as having an asset layer and a program layer. It also appears in the IMF’s legal analysis of central bank digital currencies, which separates restrictive “programmable money” from user-initiated conditional payments. Project Agorá provides a concrete wholesale setting in which the question matters: its prototype places tokenized central bank reserves and tokenized commercial bank deposits on a shared platform and uses programmable workflow for cross-border payments.
These sources do not describe one single product. The New York Fed offers a conceptual test. Project Agorá documents a platform experiment. The IMF examines the legal foundations and risks that arise when a digital form of central bank money is issued, distributed, and used. Their common value is that they let us ask whether conditionality improves the payment process while leaving the monetary object dependable.
Three ideas that are often bundled together need to be separated. Automation means that a rule can execute without a person pressing the final button. Tokenization means that a claim or balance is represented in a digital token or ledger structure. Programmability concerns what the rule is allowed to do to the asset or its transfer. A system can be automated without creating a new asset, and it can tokenize a monetary claim without placing spending restrictions on it. The presence of all three in one platform still does not tell us whether the resulting payment is programmable money or a programmable payment.
Imagine a wholesale buyer whose payment is released when a delivery record is confirmed. If the seller receives ordinary money after that condition is met, the rule has coordinated the timing of the transfer. The seller can use the received money for an unrelated transaction, and the condition does not need to be explained to the seller’s next counterparty. Now change only one feature: instead of releasing ordinary money, the system transfers a claim that can be used only with approved merchants or before a fixed date. The delivery condition may still be automated, but the object now carries restrictions. The seller must evaluate the claim itself, not merely the reliability of the payment rule.
At a small scale, the second arrangement may look like a specialized voucher. At monetary-system scale, the question becomes more serious because many differently conditioned objects could command different levels of acceptance or liquidity. A recipient might need to know not only whether a unit is authentic, but also which conditions it carries and whether those conditions survive another transfer. That is the due-diligence burden the New York Fed’s account of good money brings into view. It is also why the IMF connects currency status and par convertibility to the legal design of digital central bank money.
Project Agorá makes the distinction especially useful because its platform is wholesale and multi-currency. The BIS describes tokenized central bank reserves and tokenized commercial bank deposits working together, not a single undifferentiated digital coin. The question is consequently twofold: how does the platform coordinate the payment, and what rights remain attached to each monetary claim after settlement? Answering the first may show that a workflow is feasible. Answering the second is what tells us whether any restriction has become a property of the money itself.
Two layers, two different objects
The simplest way to avoid confusion is to separate the thing held from the instruction that moves it.
The asset layer records ownership of an asset. In the New York Fed framework, basic money sits here as an unprogrammed monetary asset. The program layer contains the instructions that users may access to change control or balances. A payment is a transfer from one account to another: a flow executed through the program layer, but involving money recorded on the asset layer.
This distinction explains why “programmable” can describe two very different outcomes. If a rule says, in effect, “send ordinary money from A to B when condition X is satisfied,” the rule controls the transfer. Once B receives the money, the money can be used for another purpose. The conditionality has done its work and does not need to remain embedded in the asset.
If the rule instead says, “lock this value into an object that may be used only for purpose Y,” the resulting asset carries the restriction. The holder must care about the conditions, and a later recipient may not value it at face value. A coffee gift card makes the intuition familiar: it can represent real value, but the person accepting it must consider where it can be used and whether they want to hold that claim. It is not interchangeable with cash in every context simply because a cash balance backs it.
The difference is not that one arrangement uses software and the other does not. Both can be automated. The difference is whether the condition changes the payment path or changes the rights attached to what circulates.
This is why a shared platform for tokenized payments should not be labeled “programmable money” merely because it contains smart contracts. The relevant inquiry is narrower and more demanding: what is represented on the asset layer, what does the program authorize, and what does the counterparty receive at the end?
The test this series will apply
The New York Fed’s framework adds a second distinction that makes the question operational. A program-created certificate can be transferable: its ownership can pass to another person, who inherits its rights and restrictions. It can also be convertible: when the specified conditions are met, the certificate releases basic money to the recipient. These properties are separate.
A transferable certificate that never converts can circulate as restricted money. A non-transferable certificate that converts when a condition is met resembles a programmable payment. A certificate that is both transferable and convertible is a hybrid: it can function as programmable money when passed on without conversion, or as a programmable payment when the relevant event releases basic money. The classification depends on what happens in the transaction, not merely on the label attached to the instrument.
This test matters because good money has demanding qualities. The New York Fed describes “no questions asked” acceptance: households and merchants should not need costly due diligence to determine an asset’s value or likely acceptance. Uniformity means that units of the same denomination have the same value. Fungibility means that units and portions are interchangeable. Convertibility helps a payment preserve these properties by giving the recipient basic money rather than a claim whose conditions remain active.
The IMF reaches a related conclusion from law rather than monetary theory. Retail CBDC is generally conceived as a central bank liability available to the public and intended to serve as money. If it is to function like digital cash, legal treatment must support features such as currency status, face-value treatment, legal tender, and par convertibility with other forms of money. Restricting where a unit may be used, who may receive it, or when it expires can raise different questions about property, autonomy, contractual freedom, and discrimination from those raised by an automatic payment instruction.
Project Agorá brings the distinction into wholesale cross-border payments. The BIS describes a shared programmable platform that combines tokenized central bank reserves with tokenized commercial bank deposits and aims to support atomic, multi-currency settlement. Its smart-contract logic can encode workflow, compliance requirements, and conditional triggers. That is important evidence about how payment-level programmability might operate. It is not, by itself, evidence that the platform creates a new form of money whose restrictions travel from holder to holder, nor is a prototype the same as a finished production system.
The useful question is therefore not “Should money be programmable?” That formulation hides two different choices. The better questions are: What exactly is the recipient receiving? Can the asset travel? Can it convert into unrestricted basic money? When is the transfer final? Which institution is authorized to issue, operate, or regulate the system? And who bears the loss if the condition, code, platform, or external connection fails?
The next step is to examine why ordinary money can be accepted without those questions in the first place. Once that foundation is clear, the difference between a payment instruction and a restricted monetary asset becomes more than a semantic distinction: it becomes a test of whether a digital system adds useful coordination while preserving the trust that makes money work.