Put payment policy where the transaction happens.

Definition

Programmable payments, in an institutional settlement context, are bounded rules that evaluate a transaction as it happens – counterparties, size, asset, schedule or condition – without moving the money into a separate application to apply the rule. Native ledger primitives come first; custom account-attached logic is only for genuinely custom policy.

Start with the institution’s rule: which counterparties are permitted, what amount may be sent, and which approvals are needed. Then decide where that rule should be evaluated and who may change it.

INFTF contributes technical know-how to place policy at the appropriate layer, keeping custom logic narrow and using native primitives where they meet the requirement.

Three places policy can live.

• Fixed protocol primitives

  Issued currencies, escrow, trust relationships, account flags. Strength: shared protocol behaviour. Tradeoff: the rule has to be one the protocol already knows.

• Separate application contract

  Logic lives in an application the money is sent into. Strength: expressive. Tradeoff: the policy is no longer where the account sits, and the institution now operates another surface.

• Account-attached policy

  Logic evaluates transactions that affect the account holding or moving value. Strength: balance stays with the account; existing transaction types remain usable. Tradeoff: custom code must stay narrow and governed.

Implementation patterns.

These design patterns address common payment rules. Each needs to be scoped to the asset, account permissions and operating model of the participating institution.

• Implementation patternApproved counterparties
• Implementation patternBackend-authorised payment
• Implementation patternPer-payment limit
• Implementation patternDaily aggregate limit
• Implementation patternApproved currency and issuer
• Implementation patternScheduled operations
• Implementation patternEscrow or conditional release
• Implementation patternTreasury mandate

Native scheduling.

Cron lets an account schedule its own logic to run later, once or on a repeating interval, so timed or recurring settlement behaviour does not always require an external scheduler. The design still needs to account for funding availability, failed execution and the operating hours of other participants.

Remit and PriceOracle.

Remit delivers several currencies to one recipient in a single push payment, including any trust lines or account activation the recipient needs. PriceOracle lets price providers publish reference prices as on-ledger objects that FX-dependent logic can read, where the publisher is trusted for that purpose. Both are native primitives: use them before writing custom code that duplicates them.

Use native primitives first. Custom code only where the policy is genuinely custom.