Moneyport
Book a demo

The platform · Synchronisation operator

One operator. Two RTGS systems. Both legs settle together.

The Moneyport platform is a synchronisation operator: it sits between two independent real-time gross settlement systems - for example the BHD RTGS and the USD RTGS - and coordinates the two legs of an FX trade so that they settle at the same moment or not at all. It never holds an account in either system, and it never takes on credit or liquidity risk.

Watch a settlement See the model
0accounts held by the operator in any RTGS. Funds only ever move between participants' own accounts at the central bank.
3stages in every transaction's life cycle: collect and match, earmark, settle. A chain moves to the next stage only when every transaction in it is ready.
2settlement modes side by side: urgent transactions settle gross immediately; normal ones queue and settle with offsetting at the end of a cycle.
SHA-256is all that leaves a node. Payment details stay in the local database; only hashes are written to the shared ledger for matching.

Function

An orchestrator that tracks a chain of transactions through three stages, and triggers the outside world at each one

A chain is a set of transactions that must settle together - at its simplest, the BHD leg and the USD leg of one trade. The operator tracks the status of every transaction in the chain and only advances when all of them are ready.

01

Collect and match data

Each participant submits its own leg to its own operator node. The two submissions are matched - validated as describing the same overall transaction - either in the operator or in one of the two settlement systems, depending on how the corridor is configured. Matching is done on hashes, so neither node reveals its client's instruction to the other.

02

Earmark funds

Each node asks its RTGS to reserve the payer's funds for this transaction and nothing else. An earmark is a promise from the settlement system: those funds cannot be spent elsewhere while the conditions for settlement are being met. If either earmark fails, nothing has moved and the chain stops.

03

Initiate settlement

Once every condition is met, the operator instructs both settlement systems to release their earmarks - the BHD transfer and the USD transfer are made in central bank money, each system confirms finality, and the operator marks the transaction complete on the shared ledger.

State machine, not a script. The workflow drives the operator through a series of states. At each state it makes API calls to the relevant external systems and waits for their responses before moving on.
Adapters absorb the differences. Every settlement system has its own messaging requirements and workflows. An integration layer inside the operator builds each payload, handles API security, signs where required and parses the response.
ISO 20022 wherever possible. Messages between the operator and the settlement infrastructures follow ISO 20022 payment messaging, so the same data structure is understood by an RTGS and by any interoperability service in front of it.

Synchronised settlement, message by message

One BHD/USD trade, from validation to completion

The figure builds itself as the settlement runs. The BHD RTGS is on the left, the USD RTGS on the right, the operator in the middle, with a message interface adapting to each system. Every message is an ISO 20022 pacs.009 instruction or a pacs.002 status report.

01Pre-pairing · validation of accounts 02Pairing 03Value date · earmark and orchestrated release 04Settlement completion BHD RTGScentral bank money · BHD Message interfaceBHD adapter SynchronisationOperator Message interfaceUSD adapter USD RTGScentral bank money · USD BHD leg USD leg USD leg submitted Validate account pacs.009 pacs.009 pacs.009 pacs.009 Valid account pacs.002 · valid account pacs.002 · valid account Valid instruction BHD leg submitted Validate account pacs.009 pacs.009 pacs.009 pacs.009 Valid account pacs.002 · valid account pacs.002 · valid account Valid instruction Pair legs hash match Pairing status pacs.002 · pairing status Pairing status pacs.002 · pairing status Earmark BHD 100,000 Earmark USD 265,200 Earmark status pacs.002 · earmark status Earmark status pacs.002 · earmark status Timeout check both earmarked USD earmarked pacs.002 · earmark BHD earmarked pacs.002 · earmark Release funds Release funds Release status pacs.002 · release status Release status pacs.002 · release status PvP complete Complete status pacs.002 · complete Complete status pacs.002 · complete
Stage 1 · Pre-pairing and validation

  1. The USD leg is submitted first. A pacs.009 credit-transfer instruction travels from the USD RTGS through the operator to the BHD RTGS, which validates the beneficiary account and answers with a pacs.002 carrying valid account. The USD system records the instruction as valid.

    The BHD leg is then submitted and the same exchange runs in the opposite direction: the USD RTGS validates its account and confirms. Both sides now hold a validated, unmatched leg.

    pacs.009
    Financial-institution credit transfer: the settlement instruction for one leg
    pacs.002
    Payment status report: every acknowledgement, from validation to completion

  2. The operator pairs the BHD leg with the USD leg. Each leg was hashed when it was submitted; when the counterparty's submission produces the same pair of hashes, a matching ID is generated and the settlement moves to MATCHED. Both settlement systems receive a pacs.002 with the pairing status.

    From here the pair is treated as one chain: neither leg can proceed to the next stage without the other. Depending on its priority, the chain is processed immediately or placed in the liquidity queue until the next settlement cycle.

  3. On value date each RTGS earmarks the payer's funds - BHD 100,000 on one side, USD 265,200 on the other - and reports earmark status to the operator. The operator runs a timeout check: both earmarks must be in place within the configured window, otherwise the chain is unwound and neither side has paid.

    With both earmarks confirmed, the operator tells each system that the other side is secured. Each RTGS releases its earmark - the funds transfer is made in central bank money - and reports release status back.

    camt.103
    Create reservation: how a node asks an RTGS for an earmark
    camt.049
    Cancel reservation: how an earmark is unwound if the other leg fails

  4. Once both releases have succeeded, the operator updates the transaction status to complete on the shared ledger and sends a final pacs.002 complete status to both RTGS systems. Both participants now hold final, irrevocable central bank money in the currency they bought.

    The whole sequence repeats for every chain. What varies is only the priority - which decides whether the chain waits for a cycle - and whether one of the two systems cannot earmark, which switches the operator to the conditional variant described below.

Where matching happens is configurable


The two requests can be matched inside the operator or inside one of the two settlement systems. In the figure the operator does it, which is the default when both RTGS systems are conventional and neither offers a pairing service of its own.


The operator waits, it does not assume


At every state the workflow makes its API call and then waits for the external system's response before advancing. There is no step at which the operator proceeds on the assumption that a settlement system will succeed.


Failure leaves nothing half-done


If an account is invalid, liquidity is insufficient, a system is closed or a reservation fails, the chain stops before release. Earmarks already placed are cancelled with camt.049. Only after both releases succeed does anyone's balance change.

The synchronisation operator model

Two banks, two nodes, two RTGS systems - and the five steps between them

The operator is built as a distributed platform: one node per jurisdiction, each integrating with its own settlement system, sharing a ledger for matching and status. Press play to follow a BHD/USD trade through the model.

Synchronisation Operator BHD Bank 1Sell BHD / Buy USD BHD Bank 2Sell USD / Buy BHD USD Bank 1Sell USD / Buy BHD USD Bank 2Sell BHD / Buy USD 1 2 2 BHD RTGS central bank money Idle USD RTGS central bank money Idle Messageinterface BHD adapter Messageinterface USD adapter 3 4 3 4 Execution · Communication · Authentication Storage · Consensus Platform layer · shared ledger between nodes Node 1 · BHD PvPMatching LiquidityQueue FundsReservation FundsSettlement Node 2 · USD PvPMatching LiquidityQueue FundsReservation FundsSettlement hash match · MATCHED
Step 1 · The trade is agreed

  1. Outside the operator and outside both settlement systems, two direct participants agree an FX transaction: BHD Bank 1 sells BHD 100,000 and buys USD; USD Bank 1 sells USD 265,200 and buys BHD. Each has an account in the RTGS of the currency it is paying.

  2. The debtor in each jurisdiction sends a request to its own operator node through the message interface. The two requests are matched by comparing hashes on the shared ledger - a settlement is MATCHED when the counterparty submits identical values.

    The liquidity queue then decides timing: a high-priority transaction is processed immediately; a normal-priority one waits in the queue for the next settlement cycle, where it can be resequenced or offset against incoming flows.

  3. Variant 1 - both systems support reservations. Each node requests a funds reservation from its own RTGS and waits for a successful response. BHD 100,000 is earmarked in the BHD RTGS; USD 265,200 in the USD RTGS.

    Variant 2 - only one system supports reservations. Only the node configured for reservations requests one and waits for confirmation. The other side proceeds conditionally in step 4.

  4. Variant 1. Each node initiates the funds transfer in its own wholesale settlement system - the release of the earmark - and waits for the RTGS to confirm finality.

    Variant 2. The node without a reservation initiates its transfer first. Only once that transfer has completed does the node holding the reservation release it and await confirmation. If the first transfer fails, the reservation is simply cancelled.

  5. Both nodes update the transaction status to complete on the shared ledger. Each participant now holds final central bank money in the currency it bought, and the record of the settlement - hashes, matching ID, status - is immutable.

Data locality

Settlement data for the BHD side is stored in the BHD node; USD data in the USD node. Jurisdictions with strict data-residency rules keep their data at home. The model also allows a trusted service provider to run a node for itself or on behalf of other banks, in one or more jurisdictions.

Data privacy

Full settlement instructions are persisted locally and hashed globally for matching and synchronisation. The core synchronisation function does not leak information to the operators of other nodes - which may be commercial banks with whom a participant would never share its FX instructions.

Immutability

Once a transaction's state is recorded on the shared ledger it cannot be altered or tampered with. Status transitions - matched, reserved, settled, complete - form a permanent, verifiable record that both jurisdictions can rely on.

See it on your corridor

Minutes, BHD/USD, one live synchronised settlement.

We will run a settlement end to end in the sandbox - both RTGS legs, your approval limits, your failure cases - then leave you to decide.

Book a demo