How CLS Payment-versus-Payment Algorithms Settle FX Trades: Multilateral Netting, Pay-In Schedules, Settlement Queues, Short-Position Limits and Finality

Reader question: In an FX trade, one bank owes one currency and expects another in return. How can a settlement system prevent the first currency from being delivered while the second never arrives?

CLSSettlement uses payment versus payment (PvP): the final transfer of one currency occurs if and only if the final transfer of the other currency occurs. The system matches eligible instructions, calculates multilateral net funding needs, issues pay-in schedules, places settlement-eligible instructions into a processing queue, checks account and risk constraints, settles both currency legs across members’ CLS accounts, and pays out through central-bank accounts.

The crucial distinction is that funding is net while settlement is gross at the instruction level. Members need not prefund the full gross value of all their FX trades, yet each accepted pair of currency obligations still settles under PvP.

What this page owns — and what it does not

This page owns the public computational mechanism:

matched FX instructions → net funding requirements → pay-ins → constrained settlement queue → simultaneous currency-leg settlement → pay-outs/finality.

It does not replace FX forward pricing, payment-message validation, or ordinary bilateral netting. This is settlement-risk infrastructure.

This is public payments-system education, not trading advice or a recommendation to use any particular settlement venue.

Why FX settlement risk exists

Suppose Bank A sells USD 100 million to Bank B for EUR 90 million.

If A sends the USD first and B fails before sending the EUR, A can lose the full principal amount, not merely a mark-to-market spread.

This is FX settlement risk, historically associated with the 1974 failure of Bankhaus Herstatt.

PvP as a logical invariant

The settlement condition can be written conceptually as:

Settle(USD leg) ⇔ Settle(EUR leg).

Neither leg should become final without the other leg becoming final under the PvP mechanism.

This is stronger than bilateral timing controls or pre-settlement netting, which can reduce but do not necessarily eliminate principal settlement risk.

Step 1: submit and match instructions

Counterparties submit payment instructions describing the currencies, amounts, value date and counterparties.

Before settlement, the system must establish that the two sides agree. A mismatch in amount, currency, value date or counterparty prevents the pair from becoming a clean settlement obligation.

This is a data-integrity layer before the liquidity algorithm begins.

Step 2: determine settlement eligibility

Not every FX instruction can enter the settlement queue. Eligibility depends on the service rules, eligible currencies, participating members, value date and operational status.

CLS currently supports PvP settlement for 18 actively traded currencies and maintains central-bank accounts in the relevant currencies.

A currency outside the eligible set cannot be made safe merely by pretending it is inside the same algorithm.

Step 3: calculate net funding requirements

Suppose a member has many trades in USD:

• pay USD 100;
• receive USD 70;
• pay USD 40;
• receive USD 50.

Gross payments are 140 and gross receipts 120, but the net short position is only 20.

CLS calculates funding needs on a multilaterally netted basis across eligible instructions. The member funds the net amount needed in each short currency rather than the entire gross payment value.

Net funding is not net settlement

This distinction is essential.

The member may pay only a small net funding amount into CLS, but the system still settles the gross paired FX instructions under PvP.

So:

liquidity obligation can be net; legal settlement of accepted instructions remains instruction-specific and final.

Why multilateral netting saves so much liquidity

If every FX trade had to be prefunded gross, the largest banks would need enormous intraday cash balances in many currencies simultaneously.

CLS reported in a March 2025 study that multilateral netting reduced gross payment requirements by about 96%, and additional liquidity-saving mechanisms reduced total funding requirements by about 99% on average for its settlement cycle.

Those percentages are operational observations, not mathematical constants. They can change with trade mix and market conditions.

Step 4: issue pay-in schedules

Before settlement, CLS calculates how much each settlement member must pay in each currency and by which deadline.

A pay-in schedule converts the member’s net short positions and risk controls into timed funding obligations.

Members or their nostro agents send funds to CLS’s accounts at the relevant central banks.

Why timing matters

Funding all currencies at the end of the day would not work because the settlement process needs enough account value to continue safely throughout the settlement window.

Pay-in schedules therefore turn a static net amount into an intraday liquidity path.

Step 5: build the settlement processing queue

CLS’s public rules describe a settlement processing queue containing settlement-eligible instructions for the relevant session.

Large instructions can be split subject to published rules before entering the queue, and the queue is processed under ordering and randomisation procedures.

The objective is not simply “oldest trade first”. Settlement must respect funding and risk constraints across multiple currencies.

Step 6: test account-balance constraints

Settling an instruction changes a member’s currency balances.

A stylised state update is:

Balance_c,new = Balance_c,old + Receipts_c − Payments_c.

The system cannot settle an instruction if doing so would violate the applicable account-value and short-position constraints.

Short-position limits are safety constraints

A member can be temporarily short in a currency inside the settlement system, but only within prescribed limits.

CLS uses currency-specific and aggregate short-position controls described in its public framework and rules.

These limits prevent the liquidity-saving algorithm from becoming an unlimited intraday credit engine.

A simple queue example

Imagine three instructions are waiting:

• Trade 1 would improve the member’s USD balance but worsen EUR;
• Trade 2 would improve EUR but worsen JPY;
• Trade 3 would improve JPY but worsen USD.

Individually, one trade might fail a short-position test. But after another trade settles, the balance state can change enough for the blocked trade to become eligible.

The queue is therefore dynamic: settlement of one instruction can unlock another.

Step 7: settle both currency legs under PvP

When the applicable conditions are satisfied, the two sides of the FX instruction are settled together across CLS accounts.

The member’s account is debited in the sold currency and credited in the bought currency as part of the PvP operation.

The system’s legal framework makes settlement final and irrevocable once the applicable finality point is reached.

Step 8: pay out long currency balances

Members that are net long in a currency receive pay-outs from CLS’s central-bank account in that currency to the member or its designated nostro agent.

Under normal completed settlement, CLS aims to return long balances and end the business day with members’ CLS accounts and CLS central-bank accounts appropriately flattened under the rules.

Central-bank money reduces settlement-asset risk

CLS holds accounts with the central banks of its eligible currencies.

Using central-bank money for pay-ins and pay-outs avoids substituting a private commercial-bank settlement asset for the core PvP mechanism.

This does not eliminate operational or liquidity risk, but it removes one important source of settlement-asset credit risk.

In/Out swaps are a liquidity optimisation layer

CLS also uses an In/Out Swap programme for participating members to reduce funding requirements further.

The basic idea is to identify offsetting currency funding needs that can be shifted outside the core settlement cycle while preserving the required risk controls.

This is a liquidity tool, not a relaxation of PvP finality for instructions that remain inside CLSSettlement.

PvP eliminates principal settlement risk, not every risk

Even with PvP, participants can still face:

• liquidity risk from large pay-in calls;
• operational risk;
• nostro-agent failure;
• market risk while replacing unsettled trades;
• legal and membership risk;
• currency-eligibility limits.

“PvP eliminates FX settlement risk” refers specifically to the principal risk that one currency settles finally without the other.

What happens if a member fails to pay in?

A missing pay-in can prevent instructions from satisfying settlement constraints.

CLS can issue additional pay-in calls and invoke failure-management procedures under its rules. Liquidity facilities and other controls can support orderly completion where permitted.

The precise response depends on the nature of the failure and current rules, so a public model should not invent an undocumented fallback sequence.

Nostro agents are another operational dependency

Many settlement members use nostro agents to send and receive central-bank payments in currencies where they do not directly operate the relevant payment account.

If a nostro agent fails operationally or financially, the member can miss a CLS pay-in even though the member itself remains solvent.

This is why CLS publishes nostro contingency best practices and why backup funding arrangements matter.

Coverage remains incomplete across global FX

BIS data published in 2026 from the April 2025 Triennial Survey estimated that roughly $5.2 trillion, or 36% of average daily FX settlement value measured in the survey, settled through PvP. Other methods mitigated some risk, while a material share remained gross bilateral.

This is a useful limit: a strong PvP mechanism does not eliminate settlement risk in currencies, products or participants that do not use it.

Inputs and outputs

A public CLS-style settlement model can require:

• matched instruction pairs;
• settlement date;
• eligible currencies;
• member/account mappings;
• currency amounts;
• current account balances;
• net funding requirements;
• pay-in schedules and deadlines;
• short-position/risk limits;
• queue state;
• central-bank payment confirmations;
• failure or suspension flags.

Outputs can include net pay-ins by currency, settled/unsettled instruction states, account balances, queue diagnostics, additional pay-in calls, pay-outs and finality status.

Evidence polarity: what supports confidence?

Evidence for a correct settlement implementation includes matched instructions, net funding that reconciles to member currency positions, pay-in schedules that reconcile to short balances, central-bank payment confirmations, queue state transitions that respect limits, and final settled currency legs that remain balanced under PvP.

Evidence against confidence includes one currency leg marked final while the paired leg remains revocable, net funding that does not reconcile to gross instructions, negative balances beyond approved limits, stale nostro routing, or settlement states that change after finality.

Counterexample: netting alone is not PvP

Two banks can net ten USD obligations into one USD payment and ten EUR obligations into one EUR payment. That reduces liquidity needs.

But if the USD net payment becomes final before the EUR net payment and the counterparty fails, principal risk remains.

Netting reduces amount at risk; PvP links finality.

Counterexample: simultaneous messages are not enough

Sending two payment messages at the same clock time does not guarantee atomic legal settlement across two independent systems.

PvP requires a mechanism that makes final transfer in one currency conditional on final transfer in the other.

Counterexample: a settled trade can still create liquidity stress

A member may have enough resources to satisfy PvP but need a very large intraday pay-in in one currency.

The trade can settle safely from a principal-risk perspective while still creating funding pressure.

Counterexample: 99% funding reduction is not guaranteed

CLS’s reported average funding efficiency depends on offsetting flows and liquidity-saving mechanisms.

A member with one-directional flows in a stressed currency can require much more than 1% of its gross value.

Weak links in implementation

Instruction mismatch. Currency amount or value date differs between sides.

Netting-set mismatch. Ineligible instructions enter the funding net.

Currency-code error. Similar codes or decimal conventions corrupt balances.

Queue-state race. Two instructions update the same account balance without atomic state control.

Limit-version drift. Short-position controls do not match current rules.

Pay-in confirmation error. A scheduled payment is treated as received before central-bank confirmation.

Finality confusion. Operational completion is mistaken for legal settlement finality.

Nostro dependency omission. Funding assumptions ignore the bank actually making the central-bank payment.

Diagnostics: how to test the engine

• PvP invariant: no final state should contain exactly one final currency leg.
• netting reconciliation: sum gross debits/credits by currency and reproduce each member’s net funding requirement.
• zero-sum currency test: across all member CLS accounts, internal currency debits and credits should balance for settled instructions.
• queue-block test: force a short-position breach and ensure the instruction waits rather than settles.
• unlock test: settle an offsetting instruction and verify the blocked trade can become eligible.
• late pay-in test: withhold scheduled funding and verify unsettled states/failure procedures.
• central-bank confirmation test: do not credit a member account merely because a payment message was sent.
• finality test: after final settlement, ordinary cancellation should be impossible.
• nostro failure test: simulate a pay-in agent outage and verify contingency handling.
• coverage test: reject or reroute currencies/products outside the eligible settlement set.

What would falsify confidence?

Confidence should be withdrawn if the model can settle one FX leg without the other; if pay-ins do not reconcile to account positions; if queue processing breaches published risk limits; if final settlement can be casually reversed; or if the same inputs produce materially different funding requirements without a rule-based reason.

Alternatives and limits

Non-PvP settlement can use bilateral netting, intragroup settlement, correspondent-bank timing controls or gross settlement. These approaches can reduce funding or timing risk but do not necessarily eliminate principal risk.

New PvP arrangements may extend coverage to additional currencies, time zones or 24/7 operating models. Their design still has to solve the same core problems: legal finality, linked settlement, central-bank or safe settlement assets, liquidity, interoperability and failure handling.

How this connects to the surrounding knowledge estate

The FX trade value can originate from FX pricing algorithms. Message quality connects to ISO 20022 validation. Exact currency arithmetic connects to banking money arithmetic. The settlement state then feeds liquidity and intraday funding management rather than changing the original trade price.

Verification and update triggers

Preserve the CLS rules/member-handbook version, eligible-currency list, settlement timelines, queue rules, pay-in logic, risk limits, nostro mappings and central-bank account interfaces. Revalidate after currency additions, settlement-window changes, T+1-related timeline changes, rule amendments, major operational incidents or changes to PvP standards.

Primary and high-quality references

• CLS Bank International, Rules, 21 July 2025, including settlement processing queues and funding procedures.
• CLS Group, Necessary ingredients for PvP, including multilateral net funding and finality.
• CLS Group, Reimagining same-day FX, 6 March 2025, including funding-efficiency statistics.
• CPMI, Facilitating increased adoption of payment versus payment — final report, 27 March 2023.
• BIS, Uncovering FX settlement risk: new measures from the 2025 BIS Triennial Survey, published 2026.

Educational boundary: This article explains public FX settlement mechanics. It does not provide trading, liquidity-management or legal advice.