The Working Test: What Exactly Does the Recipient Receive?

The distinction between programmable payments and programmable money becomes useful only when it can guide a judgment about an unfamiliar design. This chapter connects the qualities of good money, the asset/program model, and the transferability/convertibility taxonomy into one working test: identify the asset, locate the condition, follow the condition to the recipient, and ask what remains after the transfer. The result is a disciplined way to classify a feature before judging its benefits, risks, or legal status.

The test is deliberately modest. It does not decide whether a platform is safe, whether a contract is enforceable, or whether a central bank has authority to issue an instrument. It answers a prior question: is the system coordinating a transfer of ordinary money, or is it circulating an asset with conditions of its own?

A four-question path from condition to asset

Start with the asset, not the interface. A screen may show a balance, and a ledger may record a token, but neither display tells us what the holder owns. The relevant object might be basic money, a deposit claim that is readily convertible into central bank money, or a certificate created by a program. The classification depends on the rights and restrictions attached to that object.

1. What is being transferred?

First identify the thing that changes control. If the answer is basic money, the program may be arranging a payment. If the answer is a certificate or token with separate rights, the program may be transferring an asset whose behavior must be examined. “Tokenized” describes a form of representation; it does not tell us whether the represented object is ordinary money or a new programmed claim.

This first question also prevents a second error: treating every balance on a shared platform as the same kind of money. Project Agorá, for example, is described by the BIS as combining tokenized central bank reserves and tokenized commercial bank deposits. Those are distinct monetary components with different issuers and relationships. A reader must keep them separate before asking what the platform’s transaction logic does.

2. Where does the condition live?

Next ask whether the condition governs the payment process or the asset’s later use. A date, delivery confirmation, compliance approval, or completion of another payment leg may determine when ordinary money moves. In that case the condition is part of the program layer. Once the event occurs and the recipient receives basic money, the original condition need not follow the balance.

A use restriction, expiry rule, eligible-holder rule, or continuing redemption condition is different. It changes what the holder can do with the object after receiving it. The recipient may be unable to combine it freely with other money or pass it to a counterparty who cannot satisfy the program. The condition has become part of the asset’s identity.

This is the central fork in the test:

flowchart TD A[Proposed digital payment feature] --> B[Identify the asset received] B --> C{Where does the condition live?} C -->|Payment process| D[Condition governs timing or execution] D --> E[Recipient receives basic money] C -->|Monetary asset| F[Condition governs later use or ownership] F --> G[Restriction remains with the asset] E --> H[Check NQA and par convertibility] G --> I[Check transferability and convertibility] H --> J[Programmable payment candidate] I --> K[Programmable money or hybrid candidate]