Two Tests for Programmability: Can It Travel? Can It Convert?
A digital payment feature becomes easier to classify when we stop asking whether it contains code and ask two narrower questions about the object created by the program. This chapter applies the New York Fed’s framework to transferability and convertibility: can ownership of the program-created object move to another person, and does satisfying its conditions release ordinary, unrestricted money? The answers explain why a direct debit, a gift card, and a restricted certificate can all involve conditional logic while representing different relationships between programmable payments and programmable money.
The questions are independent. An object may travel but never convert, or it may convert but never be transferable. Treating the two properties separately prevents a common mistake: assuming that anything that can be passed on is money, or that anything triggered by a condition is automatically a programmable payment.
The two axes: movement and release
Transferability: can the condition travel?
In the New York Fed model, a program can lock basic money or specify an account from which money will later be released, then issue a certificate. The certificate represents the rights created by the program. It can tell its holder what actions are permitted, what conditions must be satisfied, and who may exercise those rights.
A certificate is transferable when its ownership can be passed to someone else and the new owner inherits the program’s rights and restrictions. The paper describes this as a bearer-like property: possession or control of the certificate is enough to use the program. A physical gift card is a familiar analogy. The original purchaser can give it to another person, and the recipient receives not just an amount but the right to use it under the card’s terms.
A certificate is non-transferable when the program limits use to the person to whom it was issued or requires an identity check that another holder cannot satisfy. A direct debit illustrates the difference. The payment instruction may be highly useful and automatic, but it is not a circulating asset that the payee can pass to a third party. It is an authorization attached to a particular account relationship.
Transferability matters because it determines whether a condition can move through a chain of transactions. If a restricted certificate can be handed from A to B and then from B to C, each new holder receives the same rights and limits. The condition is now part of what circulates. If the program cannot be transferred, its conditions may still control a payment, but they do not become a property of an asset that later counterparties must accept.
Yet transferability alone does not make an object good money. The New York Fed paper treats it as a necessary condition for an asset to be money in its framework, but not a sufficient condition for it to trade as money. A security can be transferable and still require valuation, carry credit risk, or trade in a market that is not liquid enough for ordinary payment. A transferable certificate can face an additional problem: the next holder may need to understand its program before deciding what price, if any, to offer.
That is the practical test for the first axis: does the recipient receive an asset whose conditions survive the handoff? If yes, the payment may have transferred more than value. It may have transferred a set of rules.
Convertibility: what does the recipient ultimately receive?
The second axis asks whether the certificate can be converted into basic money when its conditions are met. In the paper’s framework, a certificate is convertible when an allowed use causes the basic money behind the program to be released to the recipient. Once released, that basic money can be used without the original restriction.
A gift card is useful again as an analogy. When it is used for the permitted purchase, the merchant receives ordinary money rather than another coffee-only card. The certificate has served as a route through which a condition leads to a transfer of basic money. The merchant can then use that money for a different purpose. Convertibility therefore concerns the nature of the payment outcome, not merely whether the holder can transfer the certificate before using it.
A certificate is non-convertible when satisfying a permitted use does not release basic money or when the restriction remains attached to what the recipient receives. Imagine a card that can be exchanged only for coffee and that gives the barista another coffee-only card. The transfer may be accepted under the rules of the arrangement, but the barista has not received unrestricted money. The asset’s conditions continue into the next transaction.
This makes convertibility an intrinsic property of the payment in the New York Fed framework. When conversion occurs, the receiver obtains basic money and can enter later transfers without carrying forward the original program. When conversion does not occur, the receiver may hold a programmed asset even if the first exchange was valid.
The two axes answer different questions. Transferability concerns who can hold and pass on the program-created object. Convertibility concerns whether the program can end in basic money. A certificate can be transferable without being convertible, or convertible without being transferable. Neither property should be used as a shortcut for the other.
The four combinations—and why hybrids matter
The two properties create four categories. The matrix is not a list of product labels; it is a way to compare what the asset can do and what a recipient receives.
| Convertible | Non-convertible | |
|---|---|---|
| Transferable | Hybrid: potentially programmable money or programmable payment | Pure programmable money within the framework |
| Non-transferable | Pure programmable payment within the framework | Neither money nor payment within the framework |
Transferable and convertible: the hybrid
A transferable and convertible certificate can occupy either side of the distinction depending on how it is used. A gift card can be given to another person, so it is transferable. When the permitted purchase converts the card’s value into basic money for the merchant, it functions as a programmable payment. But if the card is exchanged for another good without satisfying its conversion condition, the recipient receives the certificate itself. In that use, the card functions as programmable money: a restricted asset has circulated as the thing accepted in exchange.
This is not a contradiction. The same certificate supports two different paths. In one path, the condition is fulfilled and basic money emerges. In the other, the certificate changes hands while its conditions remain active. The classification follows the economic result of the transaction rather than the marketing name, interface, or underlying technology.
The hybrid case is important for digital systems because a single instrument may support several kinds of use. A platform could allow a program to move directly into unrestricted settlement in one situation, while allowing the program-created claim itself to be passed on in another. A reviewer who sees only that the certificate is “convertible” may miss the cases in which it circulates without conversion. A reviewer who sees only that it is “transferable” may miss the cases in which it reliably ends in ordinary money.
Transferable and non-convertible: restricted money
A transferable but non-convertible certificate is the clearest example of pure programmable money in the New York Fed framework. It can circulate, but no holder can cause the underlying basic money to be released. The restrictions are not just instructions for completing a payment; they define the object that holders exchange.
The paper uses a certificate that can be used only to purchase coffee and never releases basic money as an illustration. It also places closed-end fund shares and securities in this category as financial examples of transferable, non-convertible certificates. That classification is about their program properties in the proposed framework, not a claim that those instruments are normally accepted in retail shops like cash.
The monetary concern follows directly. A holder who accepts the certificate must care about the next permitted use, the identity of the next counterparty, and the price at which the certificate can be passed on. If different certificates carry different restrictions, a nominal amount no longer tells the whole story. Transferability allows circulation, but it does not guarantee uniformity, fungibility, or no-questions-asked acceptance.
Non-transferable and convertible: a programmable payment
A non-transferable but convertible certificate is the purest programmable-payment case. Direct-debit arrangements fit the paper’s example: the arrangement specifies an account, a condition such as a due date, and an amount, but the authorization itself is not a bearer asset that can circulate. When the condition is met, basic money moves to the payee, who can use it without the original instruction following it.
This category shows why programmable payments need not threaten the ordinary qualities of money. The payment can be automatic, conditional, and sophisticated while the asset received remains basic money. The condition determines when or how the flow occurs; it does not turn the payee’s balance into a purpose-limited certificate.
The distinction does not mean that a direct debit is risk-free. An incorrect amount, an unauthorized instruction, or an execution failure can create disputes. Those are questions about authorization, operation, and remedies. They do not by themselves make the received money a restricted asset. A payment-level condition and a money-level restriction should be analyzed separately.
Non-transferable and non-convertible: neither in this framework
An object that is neither transferable nor convertible does not operate as money or a programmable payment in the paper’s classification. It cannot circulate to a new owner, and satisfying its conditions does not release basic money to a recipient. A non-transferable ownership share is offered as an example.
This fourth category is useful because it prevents the framework from forcing every programmed object into one of the two headline terms. Some programs create rights or records that are not intended to function as money and do not execute a payment. Their existence may matter for finance or contracts, but calling them programmable money would hide the fact that they fail both tests.
Why the distinction changes policy
The axes also reveal why a central bank or platform designer may want to distinguish innovation from monetary fragmentation. Broad permission to issue certificates could support more kinds of conditional arrangements. It could also increase the risk of faulty programs, fraud, or certificates that users do not understand. A conservative approach could restrict issuance to central banks or other authorized institutions, especially for transferable certificates because they have the potential to circulate as money. A more permissive approach could widen experimentation but would need to accept more design and issuer risk. The New York Fed paper presents these as trade-offs, not as a single settled policy answer.
There is a similar tension around par convertibility. If every restricted certificate can always be exchanged for basic money at one-to-one value, the monetary system can preserve NQA and avoid discounting. But guaranteed conversion also removes much of the reason to create a restricted asset: holders can immediately escape its conditions. If conversion is limited, delayed, or unavailable, the certificate may provide a specialized function, but it is more likely to require due diligence and trade at a different value.
Programs can also be layered. A certificate can be issued by one program and then placed inside another program that issues a second certificate. The second certificate may release the first when its own conditions are met; the first may then release basic money under a different condition. This does not invalidate the two-axis test. At each transfer, ask whether the certificate can move and whether the relevant condition releases basic money. More layers may make the path harder to understand, increasing the importance of clear rights and conditions.
The result is a disciplined vocabulary. Transferability tells us whether the condition can travel. Convertibility tells us whether the condition can end in ordinary money. Together they distinguish a restricted asset from a payment instruction, while leaving room for hybrids and for objects that are neither. The next task is to use those tests before judging a real platform: identify the asset, follow the condition to the recipient, and refuse to infer monetary status from the fact that the system uses tokens or shared ledgers.
A useful classification therefore begins with the recipient, not the code. Ask what can move, what can convert, and what remains attached after the exchange. Those answers will become the working test for Project Agorá.