Executive Summary

Cross-border payments are evolving from simple fund transfers to outcome-linked transactions. Instead of “pay now,” businesses will increasingly demand payments that execute only when conditions are met — such as proof of delivery, compliance clearance, or an acceptable FX rate.

The foundations for this shift are already in place: ISO 20022 enables richer data exchange, overlay services like Request-to-Pay and Variable Recurring Payments are gaining traction, instant payment systems are being linked across borders, and regulators are pressing for transparency and fraud controls.

Programmable payments do not require replacing existing rails. They can be built today by adding intelligence — APIs, orchestration engines, and liquidity services — on top of current infrastructure. Over time, tokenised forms of money may extend these capabilities, but the immediate opportunity lies in programmable payments on today’s systems.

The benefits are clear: faster cash cycles, fewer disputes, reduced FX exposure, stronger compliance, and new value-added services for providers.

This paper outlines why programmability is timely, the three-layer architecture that enables it, practical design patterns across borders, the standards and governance required, and a phased roadmap from current systems to future programmable networks.

Introduction

Cross-border payments have long been the backbone of global commerce, but they remain slower, costlier, and more complex than their domestic counterparts. Despite ongoing improvements, businesses still face challenges with liquidity management, unpredictable FX costs, and compliance risks across jurisdictions. At the same time, new digital commerce models — from global supply chains to platform-based services — demand payments that are faster, safer, and more flexible.

This is where programmability comes in. By linking payments to outcomes and conditions, it offers a way to address pain points while unlocking new value-added services. Rather than replacing existing infrastructure, programmability builds on the rails already in place, bridging today’s systems to the smarter, more adaptive networks of tomorrow.

Why Now

Several industry shifts make this the right moment to take programmability seriously:

  • ISO 20022 migration: richer, structured data makes it possible to carry conditions and evidence across borders.
  • Request-to-Pay and Variable Recurring Payments (VRP): new overlay services in markets like Europe and the UK show how conditional triggers can be built on top of existing rails. Request-to-Pay lets the payee ask for payment in real time, while VRP allows customers to pre-approve automatic collections of varying amounts within set limits, offering more control and flexibility than traditional standing orders or direct debits.
  • Central bank pilots: experiments like BIS Project Rialto and MAS Purpose-Bound Money show how programmability could work with digital assets.
  • Interlinking of IPS: initiatives like Singapore–Thailand PayNow–PromptPay and India–Singapore UPI–PayNow prove cross-border instant payments are feasible.
  • Regulatory push: governments want more transparency, stronger fraud controls, and better consumer protection—all of which programmability can support.

These changes together create the standards, APIs and governance needed for cross-border conditional payments to scale.

From Payments to Programmable Payments

We make an important distinction:

  • Programmable payments: The payment system applies the rules, not the money itself. For example, a logistics API confirms delivery, and then the payment is released. The logic lives in external orchestration engines or scheme rules. The money being moved is “normal” money.
  • Programmable money: The asset itself enforces rules, often using smart contracts. For example, a tokenised deposit or CBDC could be coded so it can only be spent on food, or only after a certain date. The logic travels with the money, not outside it. This is powerful but requires tokenisation and is further away from mainstream use.

Much of the early work on programmable payments has been tied to blockchains and smart contracts. While these remain powerful enablers for tokenised deposits and CBDCs, programmability is not limited to DLT (Distributed Ledger Technology). The concepts we describe here — Conditions Packs, orchestration engines, and Liquidity-as-a-Service — can be implemented on today’s existing payment rails. This makes programmability a nearer-term opportunity, not just a future vision tied to tokenised money.

Programmable payments are the practical first step for cross-border corridors. They allow businesses and providers to start realising benefits without waiting for CBDCs or tokenised ecosystems.

 

A Three-Layer Architecture

Programmable payments can be understood as a simple three-layer model:

  1. Trigger Layer – where the event happens. This could be a Request-to-Pay, an e-invoice, a logistics update, or a compliance check.
  2. Orchestration Layer – where the policy engine lives. It validates conditions, checks compliance, applies FX rules, and decides when to release funds.
  3. Settlement & Liquidity Layer – where the money moves. This could be domestic IPS, Swift, Cards, or RTGS systems, supported by Liquidity-as-a-Service (LaaS) and corridor liquidity hubs to ensure funds and FX are available instantly.

 

Design Patterns for Programmable Payments

Programmability can be made real through specific, practical design patterns. These patterns show how conditional logic can reduce risk, improve efficiency, and add new value in cross-border corridors.

  1. Delivery-Gated Settlement: Funds are reserved when goods are shipped and released only when proof of delivery or customs clearance is received. This reduces days sales outstanding (DSO) and minimises disputes.
  2. Rate-Capped FX: Payments execute only if the FX rate stays within the payer’s tolerance band. If rates move outside the band, the payment waits or triggers a hedge automatically. This reduces FX losses and gives predictability to both buyers and sellers.
  3. Milestone-Based Release of Funds for Services: For services trade, programmable rules can release payments in stages. For example, partial payment is made when a code module is delivered, and the balance is paid on final acceptance. This builds trust across borders.
  4. Compliance-Ready Payments: Before releasing a payment, the orchestration layer can check that all required KYC, AML, or VAT information is present and correct before sending the payment. This reduces regulatory risk and avoids downstream rejection.
  5. Sanctions-Aware Routing: If any party (beneficiary or intermediary bank) involved is on a sanction or watch list, the payment can automatically reroute or be placed in escrow until the issue is resolved, ensuring compliance without manual intervention
  6. Liquidity-on-Demand (LaaS): Instead of prefunding large amounts, the orchestration layer can call on corridor liquidity hubs to provide just-in-time liquidity and FX. This makes instant settlement possible without tying up working capital.

Interoperability and Standards

For programmable payments to work across borders, different systems need to “understand” the conditions in the same way. This is where standards come in.

A practical solution is to use a Conditions Pack – a structured digital object that carries the rules of a transaction. While not yet an industry standard, “Conditions Pack” is a practical way to think about how conditions can be shared across corridors.

The pack could contain:

  • The condition to be checked (e.g., proof of delivery, FX tolerance, milestone met).
  • The evidence required (e.g., an API callback from customs, a timestamped receipt, or a market FX rate).
  • The corridor rules that apply (jurisdiction-specific compliance or data requirements).

Conditions Packs could be aligned with ISO 20022 fields, ensuring compatibility with the global payments data standard. But instead of being locked inside the payment message, they can be shared via APIs, allowing more flexibility and richer business logic.

Each corridor could publish certified policy templates—predefined sets of conditions that are recognised by regulators and schemes. This allows payment providers to “plug and play” with confidence, knowing that the same Conditions Pack will be understood and enforceable on both sides of the transaction.

Governance and Liability

For programmable payments to succeed, participants must know who is responsible for what at each stage of the process. Without clear roles, disputes and liability risks could quickly undermine trust.

A practical governance model could look like this:

  • Orchestrator liability: The orchestrator (bank, PSP, or scheme provider running the policy engine) is responsible for evaluating the conditions, applying corridor rules, and deciding when a payment is released.
  • Evidence provider liability: The party providing evidence (e.g., a logistics company confirming delivery, or an FX provider confirming a rate) is responsible for the accuracy and integrity of that data.
  • Liquidity provider liability: If a corridor liquidity hub or bank supplies just-in-time funds or FX, it is responsible for ensuring availability and accurate execution of those funds at the agreed price.
  • Participant liability: Each bank or PSP participating in the payment flow is responsible for the correctness of the data they submit, such as KYC or invoice details.

Shared rules for dispute handling should also be defined. For example, if a payment fails because of missing or incorrect evidence, the liability may fall on the evidence provider. If an FX mismatch occurs, it may be the liquidity provider’s responsibility. The goal is to avoid finger-pointing and give all parties confidence that accountability is clear.

Corridor-specific governance frameworks will be essential. Different jurisdictions may require regulators, scheme operators, or trusted third parties to oversee certification of Conditions Packs, evidence providers, and orchestrators. This ensures trust is built into the system from the start.

Risk and Fraud Management

Programmability also changes the way risk and fraud can be managed. By embedding rules and conditions into the flow of payments, detection and prevention become proactive rather than reactive.

  1. Pre-transaction controls
  • Payments can be automatically checked against sanctions, blacklists, and fraud patterns before funds move.
  • Smart conditions (e.g., proof of delivery, verified invoices) reduce the risk of false claims or duplicate payments.
  • FX caps and liquidity checks prevent execution under unfavourable or manipulated market conditions.
  1. Real-time monitoring

Because programmable payments rely on APIs and orchestration, every action can be logged and monitored in real time. This creates a detailed audit trail that regulators and participants can use to track compliance and detect anomalies.

  1. Dynamic fraud detection

Conditions Packs could be linked with AI-driven risk engines. If unusual behaviour is detected (e.g., a payment triggered outside normal business hours or by an unexpected party), the transaction can be paused automatically until further checks are completed.

  1. Post-transaction assurance

Programmability also strengthens reconciliation. Since evidence and conditions are captured upfront, disputes are fewer and easier to resolve. Post-event audits become simpler because every rule that was applied is recorded alongside the payment.

In effect, programmability moves risk and fraud management into the design of the payment flow. This increases trust not only between counterparties but also with regulators, who gain greater visibility and control.

KPIS and Value Measurement

For adoption to grow, providers must show measurable outcomes. Several KPIs demonstrate value:

  • Reduced disputes and chargebacks: thanks to delivery-gated or compliance-checked conditions.
  • Faster cash cycles: reductions in Days Sales Outstanding or quicker supplier payments.
  • FX cost savings: fewer losses from unfavourable FX rates due to rate-capped payments.
  • Compliance efficiency: fewer rejections, lower manual intervention.
  • Fraud prevention: number and value of prevented attempts.
  • Liquidity optimisation: reduced prefunding needs, enabled by LaaS and corridor hubs.

By tracking these metrics, programmable payments can be shown as a proven value creator rather than an experiment.

How RS Software is positioned to enable Programmable Payments and Money

While the ideas explored in this paper are presented in a rail-agnostic and market-neutral manner, RS Software is uniquely positioned to turn them into reality. Over the past two decades, RS has built and scaled some of the world’s most demanding payment infrastructures — from real-time retail payment systems to national fraud monitoring platforms. This foundation has shaped a product suite that aligns naturally with the three-layer programmable payments model.

RS DigitalEdge™ provides the trigger layer capabilities — request-to-pay, variable recurring payments, proxy resolution, and API-driven onboarding — that allow business events to initiate payments seamlessly. RS RealEdge™ acts as the orchestration layer, embedding programmable rules for routing, FX guardrails, and conditional execution while being natively ISO 20022-compliant. RS IntelliEdge™ brings intelligence into the flow with real-time fraud, AML, sanctions, and confirmation-of-payee checks, ensuring that every programmable rule is enforced within a compliant framework. At the settlement and liquidity layer, RS SettleEdge™ offers real-time clearing, netting, and liquidity management that can integrate directly with corridor hubs or Liquidity-as-a-Service models. Finally, RS AssureEdge™ provides a safe test-and-learn environment, enabling regulators, operators, and participants to simulate programmable rules, measure KPIs, and refine conditions before they are deployed at scale.

Together, these products allow programmability to be delivered today on existing payment rails, while also being future-ready for tokenised deposits and CBDCs as programmable money becomes mainstream. This dual capability — near-term enablement and long-term readiness — positions RS Software as a trusted partner for corridors, regulators, and financial institutions seeking to make programmable cross-border payments a reality.

Conclusion

Programmable payments represent the next step in the evolution of cross-border finance. They build on existing rails but add intelligence, transparency, and trust. With clear standards, governance, and measurement, they can shift payments from simply moving money to executing business outcomes. For banks, PSPs, and corporates, the question is not whether to adopt programmability, but how quickly they can use it to unlock efficiency and competitive advantage.