Project Meridian FX APAC: Technical Report

1. Objectives

Building on the insights from Project Meridian FX,^{footnote [1]} Project Meridian FX APAC explores synchronisation’s potential to support payment-versus-payment (PvP) settlement across a wider range of currencies, technologies, infrastructures and time zones.

The project focuses on synchronised PvP settlement across wholesale settlement systems based on different technologies and settlement models, reflecting the diversity of approaches being explored by central banks to modernise their payment and settlement infrastructures. Leveraging simulated versions of the central bank participants’ respective Real-Time Gross Settlement (RTGS) and Distributed Ledger Technology (DLT)-based settlement ledger environments, the project tests whether synchronisation can enable interoperability across all participating systems.

The experiment was conducted in controlled environments and configurations established for testing, including the non-production environment of SGD Testnet. The comparison in this report focuses on the settlement architectures and capabilities used in the experiment.

Use cases

Building on this, the experiment focuses on two core use cases in cross-border FX settlement.

1. Real-time gross FX PvP settlement: Testing whether synchronisation can enable atomic PvP settlement^{footnote [2]} of the central bank money legs of FX transactions across different RTGS or DLT-based systems.
2. Multilateral net FX PvP settlement: Testing whether synchronisation can support multilateral net PvP settlement for transactions across three or more systems, to enable liquidity saving.

A further objective is to test synchronisation in conditions that more closely reflect the complexity of real-world wholesale settlement environments. Earlier experiments have largely focussed on technical feasibility in controlled settings. This project introduces greater diversity in system design and operational constraints while maintaining a simulated testing environment.

To that end, the experiment simulated a range of exception scenarios that could arise in a live cross-border environment. These included insufficient funds, invalid account identifiers, and central bank system outages. The SO prototype was designed to maintain the integrity of its PvP mechanism in each of these scenarios by successfully settling or fully unwinding all legs of a transaction. Testing scenarios like these is key to understanding how the synchronisation could operate in practice.

2. Experimental design

The experiment used a SO connected to all three participating settlement systems. The operator reserved funds directly on two systems, while operating a dedicated escrow account to hold funds temporarily on the third. Using simulated FX payment instructions, the SO prototype matched local and foreign currency legs of each FX transaction, and earmarked or escrowed the required funds across the relevant systems. Once all legs were secured, the operator instructed atomic settlement, ensuring that the payments settled together or not at all.

Synchronisation Operator (SO)

The SO prototype built for this experiment co-ordinated settlement across different payment infrastructures and ledger technologies, enabling atomic PvP settlement. Its core functions included matching the payment legs of an FX trade settlement and orchestrating settlement across multiple domestic wholesale settlement systems through two steps: earmarking and settlement. The design builds on the model tested in Project Meridian FX and is intended to be both system- and technology-agnostic.

All FX settlement use cases in the experiment follow the same four-stage process:

Stage 1 – Settlement instruction: Each participant transmits a settlement instruction instructing a credit transfer, corresponding to the sell side of the FX trade to the SO, identifying the currency, amount, counterparty and settlement date, together with a priority that determines whether the transaction settles real-time gross FX PvP or is eligible for multilateral net FX PvP settlement.

Each instruction included the debtor, creditor, amount, currency and value date time of the pay leg, together with the relevant elements of the receive-leg settlement instruction.

Stage 2 – Matching: Matching the sending and receiving leg of an FX trade settlement. See Matching Process for FX Legs in the Technical Annex for further details.

Stage 3 – Fund reservation request. The SO requests each system to earmark the funds required for its leg. Earmarked funds are reserved and cannot be used for other purposes by the account holder unless the SO cancels the earmark.

Stage 4 – Settlement request. Once corresponding systems confirm the required funds have been earmarked, the SO proceeds to request settlement execution. Until the first settlement instruction has been executed, the transaction can still be terminated with no settlement effected, by cancelling the existing earmarks. This provides a mechanism for handling exception scenarios – for example, where a multilateral net PvP settlement cannot be completed because one of the participants lacks sufficient funds. Once the first settlement instruction is executed, the transaction can no longer be unwound by cancelling earmarks. The SO proceeds to complete settlement on each participating system in accordance with that system’s rules. The technical point of commitment is distinct from legal settlement finality, which is considered in the accompanying Policy Report. See Real-Time Gross FX PvP Settlement for further details on the point of commitment and the reversible and irreversible phases of the settlement process.

Integration with settlement infrastructures

Due to differences in system architectures and implementation approaches, the SO prototype included an adapter layer. This layer accommodated technical interface and functional design differences across systems, that impacted how participating systems supported the capabilities required for synchronised settlement. For example, the degree of support for third-party access for SOs and multilateral net settlement varied across the systems. See System Capabilities in the Technical Annex for further details on how the different systems supported these capabilities.

The SO implemented synchronised settlement through system-specific adapter layers across participating systems, as summarised below:

• Bank of England Synchronisation Lab. The SO submitted payment instructions directly to the Synchronisation Lab on behalf of the simulated participants. Funds were earmarked in the participants’ accounts and settled only once the SO had confirmed that the corresponding payment legs in the other systems were also ready. For multilateral net FX PvP settlement, the SO calculated the net outflow per account holder for a transaction set, and submitted a single multilateral net settlement instruction with this net amount, instead of every gross instruction within the set.
• Bank of Thailand Project SAN. The SO connected to Project SAN through its interoperability layer, which passed settlement instructions to the underlying settlement system and returned responses to the SO as transactions passed through their lifecycle. Similarly to earmarking, funds were placed in escrow within the Project SAN arrangement and released conditionally, effectively replicating the role of a technical account without the SO taking custody of the funds. For multilateral net FX PvP settlement, the SO calculated the net individual obligations and submitted them without the underlying gross obligations.
• Monetary Authority of Singapore SGD Testnet. The SO used a dedicated bank-owned wallet, managed under the bank’s authorisation, to emulate liquidity reservation on behalf of the participant it represented. Tokens were transferred into and out of a technical escrow wallet held by the SO, authorised by acquiring participant digital signatures. As with the Project SAN adapter, multilateral net settlement was enacted with the SO offsetting the underlying payment obligations and only submitting net amounts.

See the Adapter Layer in the Technical Annex for further details on the technical design of these adapter layers.

3. Real-Time Gross FX PvP settlement

The first use case tested settles a single matched FX transaction across two participating systems.

The SO executes this flow through a pre-commitment reversible phase followed by a post-commitment irreversible phase, separated by a point of commitment:

1. Reversible phase: The SO requests an earmark on each leg in turn. A failure at any point during this phase, such as an earmark request being rejected due to insufficient funds or an invalid account, causes the SO to release any earmarks already obtained and terminate the settlement process.

• Point of commitment: At this point, the SO knows that every leg required for the transaction is earmarked and available.

2. Irreversible phase: The SO issues settlement instructions against the earmarked funds. Once the first settlement instruction has been issued, the SO does not attempt to reverse the transaction. If a system becomes unavailable during this phase, the SO continues to retry the settlement instruction on the unavailable system, until that system comes back online.

Figure 2 shows how this process is executed for individual currency legs on each system.

4. Multilateral net FX PvP settlement

To enable multilateral net FX PvP settlement across the three systems, the SO prototype developed a mechanism that deferred non-urgent transactions and grouped them together in settlement cycles. Eligible transactions were matched as usual but held in a queue rather than settled immediately. For each cycle, the SO calculated each participant’s net position for the candidate batch and constructed instructions to reserve liquidity and execute the resulting settlement movements.

Once a batch was constructed at the end of the cycle, the steps outlined below were enacted:

Step 1 – Collective earmark and cross-system negotiation: The SO must secure earmarks on all three systems for the same set of transactions, and it cannot determine in advance which transactions every system will accept. The process was therefore an iterative negotiation.

Negotiation process

1. The SO builds the per-system instructions for the current batch.
2. The SO requests earmarks system by system, in a fixed order.
3. A decision point checks whether every system has earmarked.
   1. If successful, the candidate set has been agreed by all systems, and the cycle proceeds to settlement.
   2. If the earmark on one of the systems fails, the SO uses the available failure information to identify the affected participant, removes an eligible transaction associated with that participant and retries the earmark. In the prototype, this generally involved removing that participant’s smallest transaction. It will continue this process until a successful earmark is placed.
   3. After a successful earmark is placed, the SO will then align the transaction set and subsequent systems and complete the earmarking process.

This process continues until a batch is calculated that all three systems accept. See Multilateral Liquidity Saving in the Technical Annex for further details on the negotiation process implemented in this experiment.

Step 2 – Settlement: Once a common set is earmarked across all three systems, the SO proceeds to instruct settlement.

5. Resilience and exception handling

When exceptions occur – such as insufficient funds, invalid account numbers, or network failures – the SO has two options it can pursue:

1. retry the activity; or
2. cancel the earmark and fully roll-back the settlement process.

The response taken by the SO will depend on the error type received. For example, where a sending bank has insufficient liquidity, the transaction will be fully cancelled and never retried. A central bank system outage, on the other hand, is seen as transient and the transaction can be retried. See Resilience Scenarios in the Technical Annex for further details on scenario classification.

The experiment tested how the SO prototype responded to different exception scenarios, as described below:

Scenario 1 – Insufficient funds

This scenario occurs when one of the participants lacks sufficient funds to secure an earmark during a PvP settlement.

The SO successfully earmarks one leg. However, the system rejects the second leg’s earmark request due to insufficient funds. Since this occurs during the reversible phase, it releases the first leg’s earmark and terminates the settlement, recording the reason for termination across both legs. Both participants return to their initial state, with the first participant's funds earmarked only for the brief duration of the failed request.

Scenario 2 – Invalid account identifiers

This scenario occurs when a settlement instruction includes an account identifier that does not exist in the destination system, triggering an immediate rejection on one leg.

As the settlement instruction cannot be processed with an invalid account identifier, the SO determines that the transaction cannot be retried. Any earmark obtained on the other leg is immediately cancelled and the settlement process terminated.

Scenario 3 – Multilateral net FX PvP settlement with insufficient funds and an invalid account identifier

This scenario occurs when a single cycle contains multiple errors across participants, testing the SO’s ability to isolate and process distinct issues within the same batch.

In this example, one participant submits an invalid account identifier, while another lacks sufficient funds for their leg. The SO handles each error independently based on how it is detected:

• Invalid account triggers an immediate rejection upon submission.
• Insufficient funds will cause a failed earmark attempt.

The SO correctly identifies both the invalid account ID and insufficient funds errors as non-retriable. It cancels any associated earmarks, isolates the failing transactions, and retries by processing the remaining transactions in the cycle.

Scenario 4 – Infrastructure outage

This scenario occurs when a settlement system becomes unavailable after both legs are fully earmarked and settlement instructions have been issued, moving the workflow past the point of commitment.

Because the workflow has passed the point of commitment, the SO does not initiate a rollback. Since the status of the instruction on the unresponsive system is uncertain, unwinding could release one leg while the other settles, threatening the integrity of the PvP mechanism. Instead, the SO retries the instruction at progressively increasing intervals until the unresponsive system comes back online or the workflow reaches the threshold for operator intervention described under Resilience Scenarios in the Technical Annex.

6. Findings

Interoperability

The experiment successfully demonstrated that real-time gross FX PvP settlement could be executed across the test environments of three central bank settlement systems with materially different architectures and capabilities. This required each test environment either to provide the necessary functionality directly or to support an alternative integration model.

The workflow relied on several key capabilities: allowing a third-party FMI to connect and reserve funds on behalf of account holders, providing timely and reliable transaction-status information and enabling the SO to initiate settlement once the required conditions had been met.

Where these capabilities were not available within the test environment, the SO used adapter layers and/or alternative operating models to support atomic settlement. For example, for SGD Testnet, funds reservation was replicated by transferring funds into a dedicated bank-owned wallet managed by the SO under the bank’s authorisation, rather than placing a direct earmark on participant funds. This demonstrated that atomic settlement can be achieved across infrastructures with different design choices through alternative implementation approaches.

However, these alternatives come with trade-offs, as they may require additional integration logic or changes to the operating model. In the case of SGD Testnet, the SO assumed responsibilities that would not typically arise in a conventional synchronisation model where SOs co-ordinate settlement without holding funds. This alternative arrangement, where SOs manage participant funds in a dedicated escrow wallet, was specifically driven by differences in system design, and comes with operational and legal considerations.

For central banks, the findings suggest that greater alignment in capabilities for SO connectivity and funds reservation could be one approach to reducing integration complexity and reliance on bespoke solutions. SOs are envisaged as non-custodial entities, and it is the intention of central banks to uphold this model to maintain a proportionate operational and legal risk profile. The relevance and suitability of such approaches will depend on infrastructure, policy objectives and risk appetite, and may require a degree of co-operation amongst central banks.

The accompanying Policy Report considers how an SO’s policy and risk profile may change where it holds or controls funds, rather than acting solely as a non-custodial co-ordination layer.

Multilateral net PvP settlement

The experiment demonstrated that multilateral net FX PvP settlement could be incorporated into a synchronised cross-border settlement workflow to reduce liquidity requirements by settling multiple transactions together. This was a notable outcome of the experiment, demonstrating that SOs can combine PvP cross-border settlement with liquidity saving techniques, potentially improving liquidity efficiency while preserving atomic settlement outcomes.

Liquidity reservation as a critical enabler

A key requirement of participating systems was the ability to reserve funds, or earmark, while the SO co-ordinated settlement across multiple systems. Earmarking ensured that the liquidity is reserved sequentially and remains available while negotiating a settlement set that all participating systems could support. If the required funds could not be reserved in one system, the SO could release any reservations made in other systems, revise the settlement set, and initiate a new settlement attempt.

Implications of different processing models

The experiment demonstrated that multilateral net settlement could be achieved across test environments with different processing models. In the experimental workflow, the SO accommodated these differences by adapting how the settlement instructions were constructed and submitted. The SO calculated the net positions within each batch, with the resulting settlement instructions reflecting the processing model of each participating system.

Whilst the set-up of the participating systems did not prevent co-ordinated settlement, they affected implementation complexity and the responsibilities assumed by the SO. Where an SO is responsible for calculating offsetting positions and generating settlement instructions, it may begin to assume functions traditionally associated with a clearing house, rather than acting solely as a settlement co-ordinator. One possible approach that could be explored is for central bank systems to both accept multilateral net settlement messages and perform netting themselves, which could reduce the role and risk profile of an SO. More granular status and failure information from central banks could further reduce complexity by enabling the SO to identify and remove problematic transactions more efficiently.

The experiment therefore illustrates another trade-off: whilst central banks can take a less active approach to supporting liquidity saving use cases, doing so increases technical and operational complexity and places greater responsibility on the SO.

The accompanying Policy Report considers how additional functions of this kind may affect the SO’s legal characterisation, regulatory perimeter, governance and accountability arrangements.

Resilience and exception-handling

The experiment provided encouraging evidence that synchronisation workflows could respond to a range of failure scenarios while preserving the integrity of the PvP mechanism. Across the exception scenarios tested, the SO was able either to complete settlement successfully or to fully unwind the transaction without leaving individual payment legs to proceed independently. This demonstrates the potential for synchronisation to support atomic settlement without requiring a particular infrastructure design.

While the scenarios tested demonstrated the SO prototype’s ability to recover from a range of failures, the scope of testing remained intentionally limited. For example, the experiment did not examine non-overlapping operating hours for central bank systems or earmark expiry. These represent important sources of real-world recovery complexity, particularly where settlement systems operate across materially different time zones and do not support continuous settlement.

Several approaches were identified as worthy of future investigation. For example, one potential approach would be to maintain an overnight earmark in one system, while another system re-opens for settlement. Future experimentation could assess the feasibility of this approach, and compare it with alternatives, such as common settlement windows. This would help establish how resilience can be maintained, without reserving liquidity for excessive periods or excluding participants whose operating hours do not align with other jurisdictions.

The accompanying Policy Report considers the distinction between operational atomicity in the technical workflow and a legally certain settlement outcome across separate domestic systems.

7. Implications for future work on cross-border payments

For central banks, the experiment demonstrated that atomic FX settlement could be achieved across participating wholesale settlement test environments with materially different technologies and operating models. This provides evidence that interoperability does not necessarily require convergence towards a common infrastructure design or technology stack. Instead, jurisdictions may be able to pursue different technologies and settlement models while remaining interoperable, provided their infrastructures support the capabilities needed to enable synchronisation. The experiment also demonstrated the SO prototype’s ability to preserve atomicity across a range of exception scenarios, including by fully rolling back all legs of an FX transaction if one leg failed. Further experimentation could explore a broader range of scenarios to more comprehensively assess the resilience of synchronisation arrangements.

At the same time, the findings highlight that such flexibility may involve trade-offs. Where key synchronisation capabilities were not supported directly, additional integration layers and alternative operating arrangements were required, increasing complexity and, in some cases, expanding the responsibility of SOs. As wholesale payment systems continue to evolve, further work could explore how greater alignment in settlement system capabilities could support cross-border use cases, while accommodating domestic policy objectives.

For prospective SOs looking to support cross-border payments, the experiment suggests that synchronisation can be implemented across a range of settlement system designs. However, doing so may require accommodating substantial differences across jurisdictions’ settlement systems, including varying approaches to access, fund reservation, and liquidity-management. This may require SOs to perform different functions within the same payment flow, ranging from a relatively lightweight co-ordination role to a more active role involving a temporary custody of funds. As discussed in the accompanying Policy Report, these differences have implications for the operational complexity, risk management and governance arrangements in any future synchronisation services.

More broadly, the findings suggest that synchronisation could potentially contribute to the interoperability objectives of the G20 Roadmap. The experiment provides further evidence of synchronisation’s potential to support safer and more efficient FX settlement even as central banks modernise their infrastructures in different ways.

At the same time, the results suggest that achieving interoperability through bespoke adaptations, rather than common capabilities, may introduce additional complexity, costs, and dependencies. The experiment identified several capabilities that could be considered in further exploration as follows:

• Third-Party FMI access – to enable SOs to orchestrate payments on behalf of account holders, without holding funds themselves.
• Earmarking – to enable atomic settlement and, importantly, efficient negotiation across 3 or more platforms for multilateral liquidity saving.
• Pacs.029 support – to enable more straightforward reconciliation for multilateral net settlement instructions when, for example, banks have insufficient funds for settlement.
• Pacs.029 support and central bank netting – to enable a more lightweight model that avoids SOs performing clearing/netting functions themselves.

While adaptations may enable interoperability in the short term, the experiment suggests that greater alignment in core capabilities and settlement models could reduce implementation frictions, simplify integration, and improve scalability over time. In this context, further work could explore the potential role international co-operation and standard-setting efforts in supporting the G20’s cross-border payments objectives.

8. Technical environment and assumptions

Design assumptions

The experiment was conducted as a proof-of-concept in a non-live test environment and deliberately simplified several aspects of real-world operation. The scope focused on testing synchronised settlement across different central bank wholesale settlement systems rather than modelling the full end-to-end FX transaction lifecycle.

Commercial bank activity was represented using stylised participants, but the experiment focused on the interactions between the SO and participating wholesale settlement systems. It did not simulate the submission and settlement of FX trades in commercial bank money. Instead, the experiment assessed how settlement instructions could be co-ordinated and settled in central bank money across the participating systems.

Liquidity arrangements were simplified, using configurable account balances and a limited set of simulated transactions, rather than modelling realistic payment volumes and liquidity dynamics.

In addition, the experiment assumed overlapping system availability and did not model differences in RTGS operating hours across jurisdictions or the expiry of earmarks. This allowed the project to focus on the core interoperability challenges associated with synchronised settlement. However, co-ordinating settlement across jurisdictions with non-overlapping operating hours remains an important challenge, particularly where systems do not support 24/7 settlement, and is worthy of further investigation.

SO prototype

This experiment builds on the SO model tested in Project Meridian FX. The SO prototype built for this experiment was a centralised system, rather than a DLT-based solution. The prototype included several components:

• API Layer for commercial banks to submit settlement instructions.
• UI Layer to monitor transaction lifecycles.
• Matching Engine that pairs each leg of a payment and routes them based on priority for either immediate gross or deferred net settlement.
• Workflow Orchestration enforces atomic execution by earmarking and settling funds.
• Adapter Layer abstracts the differences in central bank integration requirements.

System capabilities

For a SO, the availability of certain capabilities within the participating test environments reduced the integration effort required to support atomic settlement across wholesale settlement systems. These include authorised third-party access, reservation (or earmarking) of funds and settlement execution. For liquidity saving use cases, additional capabilities may be beneficial, including support for cross-system liquidity reservation and status information on individual gross transactions.

A key finding from the experiment is that synchronisation did not require each central bank system to implement these capabilities in an identical way. Where a functionality was not available within the configuration used for the experiment, the SO used a system-specific adapter layer or alternative settlement arrangements to achieve the same functional outcome. This enabled interoperability across heterogeneous systems, but increased integration complexity and, in some cases, the role and responsibilities of the SO.

Technical annex

Matching process for FX legs

For each leg, the SO computes a SHA-256 digest over the concatenation of the debtor agent, amount, creditor agent, currency and settlement date and time, separated by the pipe character.

The digest inputs and outputs are:

If no existing record satisfies the match condition, the instruction is persisted with status UNMATCHED.

Participant B then submits the mirror instruction, in which the GBP leg is the owner leg and the SGD leg is the counterparty leg. Its matchKey is therefore 34e5eff… and its targetKey is 406767…. The match condition is satisfied against Participant A's record. The SO assigns a shared match identifier and a match timestamp to both records, and applies the priority rule:

• If both instructions were submitted at NORMAL priority, both records are set to MATCHED_QUEUED and held for the next cycle.
• Otherwise, both records are set to MATCHED and a bilateral PvP workflow is started.

Adapter layer

The SO introduced an adapter layer to reconcile the differences between the systems. The core settlement workflow is implemented once, and the different integration patterns are handled in the respective adapter implementation.

Difference in how execution status is returned

The three underlying platforms report step completion through different technical mechanisms:

• The Synchronisation Lab requires active polling until the state updates.
• Project SAN submits an asynchronous callback after confirming request receipt.
• SGD Testnet emits a ledger event to be observed.

The SO handles all three mechanisms using a single common implementation. Initiating a settlement step suspends the workflow until a corresponding completion signal is received. This leaves the core settlement logic agnostic to the transport layer, delegating the responsibility of polling, event monitoring, or callback processing entirely to the adapters.

Difference in how instructions are authorised

The Synchronisation Lab and Project SAN authorise the SO as an instructing party at the interface level, whereas the SGD Testnet requires a cryptographic signature from the account holder for every asset movement. To avoid taking custody of participant keys, the adapter constructs the unsigned instruction, routes it to the participant's external key custodian for signing and submits the signed transaction. As a result, the SO holds only its own operator key, acting strictly in a purpose limited capacity.

To support this architecture, all adapters implement two additional features:

• Deterministic Instruction Identifiers: Instructions include deterministic IDs derived from the settlement systems requirements. This guarantees idempotency, ensuring that retried requests are recognised by receiving systems as duplicates rather than new instructions.
• Durable Correlation State: Before sending any instruction, the SO persists the link between the outstanding request and its workflow step. This prevents race conditions and ensures that completion signals arriving out-of-order or after an SO process restart reliably resume the correct settlement.

Multilateral liquidity-saving

The algorithm defers non-urgent transactions and settles them together in batch cycles. Eligible transactions are matched as usual but held in a queue rather than settled immediately.

• Cycle trigger and batch lock: A cycle runs on a schedule or on demand. It takes a snapshot of all queued transactions and locks them into the batch. Both legs of every transaction always enter the same batch.
• Per-system batch construction: For each system, the SO constructs the instruction that system can act on.

The respective liquidity-saving batches are then submitted to their respective wholesale settlement system. Across all systems, the SO computes each participant's multilateral net position and each participant requires a single debit or credit regardless of the number of counterparties. On Project SAN the netted batch is submitted as one instruction carrying one movement record per participant. On the SGD Testnet, the SO executes the same netted positions as a sequence of individual movements.

Removing the offending transactions: where transactions within the batch cannot be executed, the SO identifies which to remove, depending on the failure information the system provides.

• The Synchronisation Lab reports status at the level of the individual movement record. The SO reads the status of each debit movement, identifies the records awaiting liquidity, and attributes them to specific participants. It then cancels the existing earmark, removes a transaction belonging to the identified participant, and submits a fresh earmark request for the reduced list.
• Project SAN reports failure at the level of the instruction. Where the SO can attribute the failure to a participant, it removes that participant’s smallest transaction and retries, repeating until the earmark is secured.
• The SGD Testnet reports failure at the level of the participant’s instruction. SO removes the participant’s smallest transaction from the list.

Resilience scenarios

The failure types set out below are classified as definitive and are therefore not retried.

Every other failure – connection failure, timeout, unavailability, unparseable response – is treated as transient and retried.

Recovery mechanisms

The design relies on four distinct recovery features, applied based on the nature and phase of the failure:

• Automatic Retry with Backoff (Transient Faults): Handles temporary outages, timeouts, and connection dropouts. The Settlement Operator (SO) retries operations at progressively increasing intervals to avoid compounding load on a degraded system.
• Compensation (Business Failures in Reversible Phase): Handles irrecoverable business errors like insufficient funds or invalid account identifiers. The SO automatically releases all existing earmarks in reverse order.
• Cross-System Negotiation with Targeted Removal (Multilateral Cycles): Handles batch-level failures. The SO cancels batch earmarks across systems, strips out the minimal set of failing transactions, rebuilds the instructions, and retries the cycle—converting a complete failure into a slightly smaller settlement round.
• Unresolved and Persistent Failures: Handles edge cases that bypass automated recovery, such as system outages persisting beyond the maximum retry horizon. The SO holds the workflow in a defined, persistent state with earmarks intact and alerts an operator for manual intervention.