Why Good Money Must Feel Ordinary
The question in this chapter is why some forms of money can be accepted without investigation while a restricted digital claim cannot. To answer it, we need to examine the qualities that make money dependable—no-questions-asked acceptance, uniformity, and fungibility—and then separate the asset that is held from the instructions that move it. This distinction supplies the mechanism behind the difference between programmable payments and programmable money.
Money’s most important service is easy to overlook because it usually works quietly. When a person receives a unit of ordinary money, they normally do not ask which particular unit it is, who held it before, or whether the next shop will accept it. They rely on the monetary system to make those questions unnecessary. Programmable payments can preserve that convenience, but only if their conditions control the transfer rather than changing the object that arrives.
The invisible service money provides
The New York Fed paper describes this quality as “no questions asked” acceptance, or NQA. Money has NQA when households and merchants do not need to perform costly due diligence about its value, provenance, or likely acceptance before taking it. The phrase does not mean that users never check for fraud or obey no rules. It means that, once an instrument is recognized as money in the relevant system, its ordinary use does not require a separate investigation of the properties of each unit.
NQA is closely connected to two more familiar properties: uniformity and fungibility. Uniformity means that different units with the same denomination have the same value. A ten-dollar note is worth ten dollars whether it is crisp or worn, and ten dollars in a bank account is treated as the same amount for ordinary payment purposes. The system does not ask a merchant to price one dollar differently from another dollar merely because the dollars have different histories.
Fungibility means that units, and portions of a balance, can substitute for one another. Ten dollars in one note is equivalent to ten one-dollar notes. If an account contains ten dollars, no particular dollar is normally singled out as the one that must be spent first. Fungibility lets people reason about the amount rather than track the identity and special conditions of every component.
Together, these properties create a form of trust that is practical rather than sentimental. A recipient can accept money because the monetary system has already done much of the valuation work. The recipient does not need to know whether the funds came from one account or another, whether the sender obtained them yesterday or last year, or what the recipient’s next transaction will be. The money’s denomination and the rules of the system are enough.
NQA does not mean that money is anonymous, immune from fraud controls, or free of every kind of risk. A bank or merchant may still need to authenticate a payment, comply with law, or protect an account. The narrower point is that the recipient does not have to perform a separate valuation of the monetary unit itself. A ten-dollar balance is not ordinarily split into “easy-to-spend dollars” and “dollars whose history must be investigated.” The system’s common rules absorb that distinction.
That absorption is valuable because payments are chained together. A seller who receives money may use it to pay a supplier, who may use it to pay an employee, who may use it elsewhere. Uniformity and fungibility allow each participant to reason about the amount received without reconstructing the earlier transaction. The money can move through the economy without carrying a narrative that every later holder must read. If conditions remain attached to each unit, the chain becomes more fragile: every later recipient may need to know which rules still apply.
This is also why a nominal promise of one-to-one value is not enough by itself. A restricted certificate might represent one dollar of basic money, yet still be worth less than one dollar to a counterparty who cannot use it for the intended purpose or cannot easily convert it. In the New York Fed framework, convertibility matters because the qualifying use releases basic money. In the IMF’s legal analysis, convertibility at par supports the singleness of money. Both ideas point to the same practical test: can the person receiving the asset use it as ordinary money, or must they first satisfy another rule?
Now consider a digital claim that is restricted to particular goods. It may be backed by an equal amount of ordinary money, but the backing does not make the claim interchangeable with cash in every situation. A coffee gift card is useful because a coffee seller can redeem it for ordinary money under the card’s rules. A hot-dog seller, however, may receive only a card that can be used for coffee. The second seller must ask a new set of questions: Is the card transferable? Where can it be redeemed? Will its value survive another transfer? Those questions are evidence that the claim is not offering the same NQA experience as ordinary money.
This is where asset-level programmability creates a problem. If each unit can carry a different purpose, expiry date, eligible holder, or redemption condition, the recipient cannot value the unit solely by its denomination. They must understand the program attached to it. A transferable instrument may still circulate, but circulation does not guarantee that it will trade at face value or be accepted without hesitation. The New York Fed paper therefore treats transferability as important but not sufficient for an asset to function as money.
Program complexity can increase this burden even when no explicit restriction is intended to be hostile. A simple condition—release the funds on a stated date—may be easy to understand. A more elaborate condition may depend on several external events, different authorities, or an interpretation of code. The recipient’s cost is not only the time needed to read the rule. It is also the uncertainty about whether the rule will be recognized and whether the asset can be used in the next transaction. If the answer changes from one counterparty or jurisdiction to another, the asset becomes more information-sensitive.
That does not mean every conditional arrangement destroys money’s usefulness. It means the arrangement must be located carefully. A condition that determines when ordinary money moves can be invisible to the recipient once the payment completes. A condition that determines where the received asset may go remains visible in every later transaction. The first changes the timing or path of a payment; the second changes the object that circulates.
Asset layer and program layer
The New York Fed framework makes this distinction precise by separating a digital monetary system into two conceptual layers. The asset layer is the ledger or record of ownership. It may contain central bank money, as in a reserve-account system, or deposit balances that can be converted into central bank money. The program layer is the universe of programs users can access to change control or balances under specified conditions. The paper is deliberately agnostic about whether these layers are implemented on a blockchain, a distributed ledger, or a conventional database. The separation is about economic function, not a prescribed technology.
In this model, money is a stock: an asset recorded on the asset layer. A payment is a flow: a transfer of that money from one account to another. Programs that transfer money belong to the program layer, but the existence of such programs does not make the money in the asset layer a different kind of money.
A recurring rent payment illustrates the point. The user may authorize an instruction that says, in effect, “on the due date, transfer this amount from my account to the landlord’s account.” The instruction is programmable because it specifies a condition and an action. Yet when the condition is met, the landlord receives ordinary money. The landlord is not required to spend those funds on rent, and the landlord’s next counterparty does not inherit the original instruction. The program has controlled a payment event; it has not created a restricted monetary object.
The same logic can be expressed with a delivery condition. Suppose two parties agree that payment should occur when a specified delivery record is confirmed. A program may wait for that record, authorize the transfer, and then move basic money to the seller. The program coordinates the exchange, but the seller receives an asset that can be used for any subsequent purpose. The condition is external to the money and terminates when the payment is made.
Change the design so that the seller receives a digital certificate that can be spent only on an approved class of goods. The settlement event may be just as automatic, but the asset has changed. The certificate’s use depends on conditions that remain after the original payment. It may be transferable, but every later recipient must consider the same limitations. The program is no longer merely a way to move basic money; it has created an object whose behavior is part of its identity.
The difference becomes clearer if we follow the two designs beyond the first payment. In the first design, the landlord or seller receives a balance that can be combined with other balances. The source of the funds may matter for compliance or account security, but the original rent or delivery condition does not accompany the balance as a spending rule. In the second design, the recipient cannot simply combine the certificate with unrestricted funds and treat the total as one fungible amount. The certificate’s purpose, expiry, or eligible counterparty remains relevant at the next transaction.
This is why the asset/program distinction is more than a way of drawing a system diagram. It identifies where a failure or disagreement will be experienced. If the condition is in the program layer, a failed date check or missing delivery confirmation may delay the transfer while leaving the underlying money unchanged. If the condition is in the asset, the holder may have received the wrong kind of claim for the intended use, even though the ledger recorded the transfer correctly. Technical success and monetary equivalence are separate questions.
The distinction also matters for the issuer’s promise. An issuer can say that a restricted certificate is backed by basic money, but the recipient still needs to know when conversion is available and whether another holder can invoke it. If conversion is automatic at the permitted use, the condition may serve as a route into ordinary money. If conversion is unavailable, or available only to a narrow person or merchant, the certificate’s restrictions remain part of the asset. The same backing can therefore support different economic experiences depending on the program’s rights.
The distinction can be summarized without treating the diagram as a technical architecture:
This model also explains why a broad definition of programmable money becomes unhelpful. If every instruction that moves money counts as programming the money, then direct debits, recurring payments, and many familiar payment arrangements would already be programmable money. That wording would erase the distinction the policy debate is trying to make. The useful question is not whether a program can affect a balance. It is which features of the program alter the rights and behavior of the asset that can circulate.
The distinction between stock and flow also prevents a common category error in tokenized systems. A token may be a representation of an existing monetary claim, a new certificate with its own conditions, or an instrument whose legal and economic status depends on how it can be converted and transferred. A shared ledger can record any of these. To classify the arrangement, the reader must inspect the relationship between the token, the underlying asset, and the payment rule—not infer the answer from the word “token.”
There is a further reason to keep the layers separate. A payment can fail even when the underlying money remains perfectly ordinary: the condition may not occur, a required confirmation may be delayed, or the platform may be unavailable. Those are questions about execution and settlement. They are different from the question of whether the recipient receives a restricted asset. A trustworthy design must answer both, but solving one does not solve the other.
The asset/program model therefore gives us a causal chain. If the program changes only the route or timing of a transfer, the recipient can receive basic money and retain its ordinary properties. If the program changes what the recipient may do with the asset, the recipient must evaluate the asset’s conditions. That additional evaluation can weaken NQA, uniformity, and fungibility even if the system remains technically reliable.
The next distinction makes this causal chain easier to apply. It asks two direct questions about a program-created certificate: can ownership travel to another person, and does satisfying the program release basic money? Those questions will show why a direct debit, a gift card, and a hybrid instrument can all contain conditional logic while occupying different positions between programmable payment and programmable money.