From Instruction to Settlement: The Operational Life of a Programmable Payment

Project Agorá’s distinction between programmable payments and programmable money becomes clearest when we follow one payment through its states. This chapter traces the reported real-value testing path from token issuance and payment preparation to compliance checks, cross-currency coordination, fund locking, atomic settlement, redemption, and fallback. The aim is to show where the condition acts on the payment flow, what persists at each transition, and why a technically successful transfer still needs a clear finality and loss framework.

A programmable payment is not a single instruction that appears at the end of a design process. It is a chain of dependent events. Value must be represented, the parties must be authorized, the relevant conditions must be checked, the linked payment legs must be coordinated, and the result must be connected back to the systems that record the underlying money. Each transition creates a different failure surface. It also creates a different opportunity to confuse a condition on the payment with a restriction on the asset.

The transaction moves through several linked states

Value is represented before a payment begins

In the reported testing environment, central banks used Project Agorá suites to issue and redeem tokenized reserves and monitor settlement on jurisdictional ledgers. The issuance of tokenized reserves was triggered outside the real-value testing environment, typically after the requesting financial institution paid into a dedicated RTGS account. Financial institutions used their suites to issue and redeem tokenized deposits, manage tokenized reserve holdings, submit payments, and monitor account balances and activity. For tokenized deposits, the corresponding funds were earmarked or the equivalent amount was booked to a designated account in the institution’s core banking system.

This is the first important transition. A token enters the platform only after the surrounding institution has connected it to a monetary value or reserve relationship. The tokenized representation is not the whole payment. It is a platform-ready form of a claim that must later be redeemed or reconciled through an external system. The reserve side and deposit side also remain distinct: the central bank manages tokenized reserves, while financial institutions issue and manage tokenized deposits. Treating them as one generic balance would hide the institutions responsible for each side of the transaction.

At this state, nothing has yet been paid to the final counterparty. The platform holds representations that can participate in a transaction. Their existence does not tell us whether they are ordinary money or restricted programmable assets. That depends on their rights, their transferability, their convertibility, and what the recipient receives after settlement.

Payment preparation turns an agreement into a candidate transfer

A debtor, a debtor’s agent in a corporate transaction, or an initiation service provider in a payment-versus-payment transaction prepares the payment instruction. Project Agorá’s testing used established ISO 20022 formats, including pacs.008 and pacs.009, for payment instructions and camt.053 for end-of-day statements. The significance is not the message names themselves. It is that the programmable platform was designed to interact with the language already used by payment and banking systems.

The instruction is still a candidate transfer at this point. It states what should happen, but the platform has not necessarily committed the relevant value. For a dual-currency transaction, a cross-currency provider manually confirmed the corresponding amount. Participating financial institutions completed compliance checks before submitting the instruction.