Reader question: In a foreign-exchange trade, one party owes one currency and receives another. If the two payments travel through different payment systems and time zones, how can a settlement system prevent one side from paying away its currency while never receiving the other?
The core answer is payment versus payment (PvP). CLSSettlement links the two currency legs so that final transfer of one currency occurs only if the corresponding transfer of the other currency can also occur. Around that atomic settlement condition, the system uses instruction matching, multilateral netting, pay-in schedules, liquidity management and central-bank-money settlement to turn a huge gross set of FX obligations into a much smaller set of funding requirements.
This is a particularly useful computational-finance problem because the key protection is not forecasting. It is state coordination across two currencies: either both principal legs settle according to the system’s rules or neither principal leg is released as a completed PvP settlement.
What this page owns — and what it does not
This article owns the computational chain:
matched FX instructions → eligible settlement set → multilateral net positions → pay-in obligations → simultaneous PvP settlement → completion or exception.
It does not replace correspondent-banking routing, general multilateral payment netting, FX-swap and cross-currency funding mathematics, or payment idempotency. Those pages own different layers.
This is settlement-mechanism education, not a payment instruction and not personalized financial advice.
The problem: Herstatt or principal settlement risk
Suppose Bank A sells USD 100 million to Bank B in exchange for EUR. If A sends the USD first and B fails before sending the EUR, A can lose the full principal amount of the trade rather than merely the change in market value.
This is the classic FX settlement-risk problem often associated with the 1974 failure of Bankhaus Herstatt.
The risk is structurally different from ordinary replacement-cost risk. If a counterparty defaults before either payment is made, the surviving party may need to replace the trade at a worse market rate. If one principal leg has already been paid while the other has not, the possible loss is the entire principal delivered.
PvP changes the state machine
Without PvP, the two legs can behave like independent state transitions:
USD leg: pending → paid
EUR leg: pending → paid
Nothing in that simple structure prevents:
USD = paid, EUR = unpaid.
PvP replaces that with a linked settlement rule. Conceptually:
settle(USD leg, EUR leg) only when the conditions for both final transfers are satisfied.
The objective is to exclude the dangerous terminal state in which only one principal leg is irrevocably settled through the PvP mechanism.
Step 1: submit and match settlement instructions
Before settlement, the system needs instructions for both sides of the trade. Relevant fields include:
- counterparties;
- currency pair;
- amount of each currency;
- value date;
- settlement-member or third-party relationships;
- trade and instruction identifiers.
If the parties disagree about USD amount, EUR amount or value date, the trade should not quietly enter a final PvP settlement state as if both sides had instructed the same obligation.
This is a useful distinction from trade execution. A trade can exist economically while the settlement instructions are still unmatched or incomplete.
Matching is a data-consistency gate, not credit protection by itself
Suppose both counterparties submit identical instructions for USD 100 million versus EUR 86 million. Matching proves that the settlement system has compatible records of the obligation.
It does not prove either institution has the necessary liquidity. It also does not by itself remove principal risk.
The principal-risk protection comes later from the PvP settlement condition.
Step 2: build the eligible settlement set
CLSSettlement operates for supported currencies and participants under its legal and operational framework. Current CLS public material states that the service settles payments in 18 actively traded currencies and is used directly by more than 75 settlement members and indirectly by tens of thousands of third-party participants.
A trade in an unsupported currency cannot simply be forced through the same PvP engine. Eligibility therefore behaves like a routing gate:
instruction → eligible for CLSSettlement? → yes/no.
This is why residual FX settlement risk can remain in the global market even when a major PvP system is widely used.
Step 3: multilateral netting compresses funding needs
Imagine one settlement member has many trades during the same settlement cycle:
- pay USD 500;
- receive USD 420;
- pay EUR 300;
- receive EUR 280;
- and thousands of similar obligations against many counterparties.
Funding every trade gross would require enormous intraday liquidity.
Multilateral netting aggregates obligations across the network. For currency c and participant i:
NetPositioni,c = Σ Receiptsi,c − Σ Paymentsi,c.
If the result is negative, the participant is a net payer in that currency. If positive, it is a net receiver.
A small netting example
Suppose Bank A must pay USD 100 to B, receive USD 70 from C and receive USD 20 from D.
Gross payment obligation = USD 100.
Gross receipts = USD 90.
Net position:
90 − 100 = −10.
Instead of funding USD 100 for that simplified set, A’s net funding need is USD 10.
Across a large participant network, the savings can be dramatic. CLS currently states that its multilateral-netting process reduces settlement-member funding requirements by more than 96% on average. Its 2025 work on additional settlement cycles described further liquidity-saving mechanisms that can reduce actual funding needs even more relative to gross settled value.
Netting does not remove the underlying trades
The economic trades remain separate contracts. Netting changes the settlement-funding problem.
This distinction matters for valuation, accounting and lifecycle processing. One cannot infer from a net USD 10 pay-in that the participant executed only USD 10 of FX trades.
Step 4: calculate pay-in schedules
Once settlement obligations are netted, each settlement member receives funding obligations across the supported currencies and settlement window.
A pay-in schedule answers:
How much of currency c must participant i provide, and by what time, so that the settlement process can continue safely?
The schedule is an intraday liquidity-control mechanism. It prevents a system from treating end-of-day net solvency as sufficient when payments must occur at specific times.
Why timing matters even after netting
Suppose a bank is due to receive EUR later in the settlement cycle but must fund JPY earlier.
Its overall economic position can be balanced while its intraday liquidity is not.
Therefore:
net exposure ≠ timed funding requirement.
A settlement engine must track both amount and time.
Step 5: settle the two currency legs on a PvP basis
CLS describes its service as simultaneously settling the payment instructions relating to an FX trade through a payment-versus-payment mechanism.
The conceptual invariant is:
final transfer of currency A occurs if and only if final transfer of currency B can occur under the settlement rules.
This removes principal settlement risk for the trades successfully settled through that PvP process.
Central-bank money matters
Settlement ultimately relies on accounts and payment systems in the relevant currencies, with CLS operating under a central-bank oversight framework. Settlement in central-bank money reduces exposure to the credit risk of a private settlement asset.
The full infrastructure spans multiple currency payment systems. That is one reason the settlement cycle has tightly controlled operating windows and liquidity procedures.
A simple two-trade example
Suppose A and B have two opposite trades:
- Trade 1: A pays USD 100 and receives EUR 90;
- Trade 2: A receives USD 80 and pays EUR 72.
Gross principal across both trades:
- A pays USD 100 and receives USD 80;
- A receives EUR 90 and pays EUR 72.
Net positions:
A: pay USD 20; receive EUR 18.
The economic trades still total far more than the funding amounts. PvP controls the principal settlement of the linked FX obligations while netting reduces how much liquidity must be mobilised.
PvP removes principal risk, not every form of risk
Even after a trade is scheduled for PvP settlement, institutions still face:
- liquidity risk from meeting pay-ins on time;
- operational risk from systems and data failures;
- replacement-cost risk if a trade fails before final settlement;
- market risk on open positions;
- legal risk around participation and settlement finality;
- risk on transactions or currencies that remain outside PvP coverage.
A risk-control system should therefore say principal settlement risk eliminated for successfully completed PvP settlement, not “all FX risk eliminated.”
The 2025 BIS survey shows why residual risk still matters
In July 2026, CLS highlighted the BIS 2025 Triennial Survey’s finding that about 90% of average daily FX settlement in April 2025 used methods that eliminate or reduce FX settlement risk, while roughly 10% by value continued to settle gross bilaterally.
This is time-sensitive evidence. It shows that PvP adoption is broad but not universal.
The FX Global Code places PvP at the top of the settlement-risk hierarchy
The 2025 update to the FX Global Code strengthened its settlement-risk principles and uses a risk-waterfall concept. Where practicable, PvP sits at the strongest level because it can eliminate principal settlement risk. Other methods such as netting can reduce exposures but do not create the same atomic two-currency finality.
Counterexample: bilateral netting is not PvP
Suppose two banks net ten USD obligations into one USD 5 payment and ten EUR obligations into one EUR 4.5 payment.
Netting has reduced the amount at risk.
But if USD 5 is paid first and EUR 4.5 never arrives, principal settlement risk remains on the net amount.
Netting reduces the size of exposure; PvP changes the conditionality of settlement.
Counterexample: matched does not mean funded
A perfectly matched FX instruction can still fail to settle if the participant cannot provide required liquidity under the settlement rules.
Matching solves agreement of data. Funding solves availability of settlement assets.
Counterexample: PvP coverage does not automatically extend to every currency
If a currency is outside the eligible PvP infrastructure, a bank must use another settlement method or risk-control arrangement.
One global policy of “all FX trades are PvP” can therefore be false if it ignores currency eligibility and actual settlement route.
Counterexample: same-day FX creates a timing challenge
CLSSettlement has historically operated one principal settlement cycle each day. Same-day trades executed after relevant cutoffs may not fit naturally into that cycle.
CLS and FNA’s 2025 research on additional settlement cycles examined precisely this issue. It illustrates that settlement-risk mitigation must evolve with trading patterns, time zones and demand for shorter settlement horizons.
Inputs and outputs
A PvP settlement engine can require:
- matched FX settlement instructions;
- trade value dates;
- currency eligibility;
- member and third-party settlement relationships;
- gross payment obligations by currency;
- multilateral-netting rules;
- pay-in schedule and timing;
- available liquidity and nostro balances;
- settlement-window state;
- legal finality and operational status.
Outputs can include:
- matched/unmatched status;
- eligible/ineligible status;
- net funding amount by currency;
- timed pay-in obligations;
- settled instructions;
- unsettled or rescinded instructions under applicable rules;
- liquidity usage;
- exception reason codes.
Evidence polarity: what supports confidence?
Evidence for a reliable settlement process includes bilateral instruction agreement, deterministic netting, pay-ins reconciled to member obligations, legal finality, successful simultaneous settlement of the two currency legs, robust contingency procedures and funding reductions that reconcile to the underlying gross obligations.
Evidence against confidence includes unmatched instructions entering settlement, net positions that do not sum to zero across participants for a closed currency set, pay-in schedules disconnected from actual settlement obligations, one currency leg marked final without the linked PvP condition, or unexplained differences between settlement records and participant nostro records.
Weak links in implementation
Instruction mismatch. Currency amounts or value dates differ between counterparties.
duplicate instruction. The same trade enters the settlement queue twice.
currency eligibility drift. A routing rule assumes a trade is PvP-eligible when it is not.
netting-sign error. Receipts and payments are inverted for one participant.
time-zone error. Settlement cutoffs are interpreted in the wrong local time.
liquidity shortfall. A member has sufficient end-of-day resources but misses a timed pay-in.
exception-state ambiguity. An instruction is neither clearly settled nor clearly returned to an exception process.
route assumption. A trade booked as “CLS eligible” is later settled bilaterally outside PvP.
Diagnostics: how to test the engine
- two-leg atomicity test: simulate failure of one currency payment and verify the linked principal does not complete as a one-sided PvP settlement.
- net-zero network test: across the closed participant set, aggregate net positions by currency must sum to zero before external funding flows.
- gross-to-net reconciliation: every net funding figure must trace to underlying gross instructions.
- duplicate test: duplicate settlement instructions must not double the economic obligation.
- timing test: adequate end-of-day liquidity with insufficient intraday liquidity should trigger the correct exception.
- unsupported-currency test: route an ineligible pair away from the PvP engine.
- member/third-party test: ensure indirect participation maps to the correct settlement member.
- cutoff test: submit instructions just before and just after operational deadlines.
- nostro reconciliation: compare external payment-system movements with internal settlement records.
- business-continuity test: simulate a participant or infrastructure outage and verify controlled fallback states.
What would falsify confidence?
Confidence should be withdrawn if a successfully labelled PvP settlement can leave one principal leg final and the other unpaid; if net funding cannot be reconstructed from gross obligations; if settlement eligibility is stale; if legal finality is unclear; or if repeated operational incidents produce unresolved settlement states.
Alternatives and limits
Bilateral settlement can be reduced through netting, but it does not provide the same principal-risk elimination as PvP. Other PvP arrangements and new technologies can extend coverage to currencies or operating windows not currently handled by one service. The appropriate mechanism depends on legal finality, central-bank access, liquidity design, participant access and currency coverage.
No settlement system can erase market risk created before settlement or operational risks outside its own control perimeter.
How this connects to the surrounding knowledge estate
Multilateral netting supplies the mathematical compression idea. Correspondent routing explains how non-PvP cross-border payments can traverse institutions and accounts. Payment idempotency protects retries. CLS PvP adds the distinct invariant that the two FX principals settle together.
Verification and update triggers
Preserve service-rule version, currency-eligibility list, participant mappings, instruction-matching rules, netting algorithm, pay-in schedule logic, settlement-window configuration and legal-finality assumptions. Revalidate after new currencies join, settlement cycles change, cutoffs change, participant models change or a material settlement incident occurs.
Primary and high-quality references
- CLS Group, CLSSettlement, describing PvP settlement, current currency coverage and liquidity benefits.
- CLS Group, Netting for businesses, including multilateral-netting concepts and funding reduction.
- CLS Group, Reimagining same-day FX, 2025, describing the settlement cycle and liquidity-saving context.
- CLS Group, Statement on the BIS 2025 Triennial Survey’s assessment of FX settlement risk, 10 July 2026.
- Bank for International Settlements / CPMI, publications on foreign-exchange settlement risk and payment-versus-payment arrangements.
- Global Foreign Exchange Committee, FX Global Code, including the 2025 settlement-risk principles.
Educational boundary: This article explains public FX settlement architecture. It does not instruct any reader how to settle a real trade, choose a settlement route or provide personalized financial advice.