Moneyport
Book a demo

How it works · Orchestration · Integration

One workflow. Every settlement system.

The operator orchestrates payments across different external systems, ensuring that transactions involving two or more parties are completed consistently. Those systems vary in what they can do and in how their transactions live and die - so the operator drives every transaction through a state machine, and lets one adapter per system absorb the differences.

Watch a settlement See the platform
1state machine per transaction. The workflow moves to the next state only upon receipt of a success or failure response from the external system.
1adapter per settlement system, responsible for the message payload, the API security and the parsing of the response.
3API calls to settle through a trigger service - create, approve, submit - with the approval digitally signed by the node on behalf of the payer bank.
0steps taken on assumption. The operator awaits a response from each system before progressing to the next state.

Orchestration

A state machine drives the transaction; adapters do the talking

To manage the complexity of many external systems, the operator employs a state-machine-driven workflow. It guides the operator through a series of states, triggering API calls to the relevant external systems at each step, and awaits their responses before progressing to the next state.

01

State-machine workflow

Every transaction is a state machine. Upon receipt of a success or failure response, the workflow moves to the next state and the next action is processed. A failure is a state too - one with its own exit, never an ambiguity.

02

Integration layer

An integration layer within the operator handles the unique characteristics of each external system - its messaging requirements, its workflow, its security model. It implements a different adapter for every system the operator connects to.

03

Adapters

Each adapter constructs the message payload, handles the API security - including digitally signing requests where the system requires it - and parses the responses based on the capabilities provided by that system. The workflow above only ever sees states and outcomes.

One settlement, two kinds of system

Reserve where you can, trigger where you must, and record everything on the ledger

On the left, the BHD RTGS exposes APIs for funds reservation and settlement. On the right, the USD side is reached through a trigger service: REST APIs to create, approve and submit a payment instruction and to query its status. The operator nodes sit between them and the shared ledger. Press play to follow one BHD/USD settlement.

01Submission and matching on the shared ledger 02Reserve on the BHD side · prepare on the USD side 03Settlement · trigger side first, then release of the BHD earmark 04Settlement completed BHD RTGSreservation + settlement APIs Operator nodeBHD adapter Shared ledgermatching · reservation · settlement Operator nodeUSD adapter USD trigger APIcreate · approve · submit Leg 1 · BHD Leg 2 · USD Leg 1 submitted Leg 2 submitted Matching leg 1 hash leg 2 hash Match confirmed Match confirmed camt.103 · reserve funds create · prepare payment camt.047 · reserved Prepared Fund reservation FRC · leg 1 reserved FRC completed Settlement approve · signed by the node Approved submit Submitted Completed SC · leg 2 settled pacs.009 · release earmark pacs.002 · final SC · leg 1 settled Settlement completed Settlement completed
Submission and matching

  1. Leg 1 arrives at the BHD adapter from the RTGS side; leg 2 arrives at the USD adapter from the trigger side. Each node hashes its leg and writes the hash to the ledger's matching contract. When the two hashes correspond, the ledger emits match confirmed to both nodes and the transaction moves to MATCHED. No payment details have left either node.

  2. Here the two systems differ. The BHD RTGS supports reservations: the BHD adapter sends a camt.103, receives a camt.047 confirming the earmark, and records fund reservation complete for leg 1 on the ledger, which answers FRC completed.

    The USD trigger service does not reserve. Instead the USD adapter calls create to prepare the payment instruction and receives prepared. The instruction now exists in the trigger service, but nothing has moved.

  3. Because only one side holds a reservation, the side without one pays first. The USD adapter calls approve - the trigger's approve function translates the payer bank's approval of the payment into its literal meaning; the node calls it on behalf of the payer bank and digitally signs the request. It then calls submit, and periodically queries the trigger until it returns completed. The node records settlement complete for leg 2 on the ledger.

    Only now does the BHD adapter release its earmark with a pacs.009. The BHD RTGS answers with a pacs.002 final status, and the node records settlement complete for leg 1.

  4. With both legs recorded as settled, the ledger emits settlement completed to both nodes and each updates its own status. Had the trigger side failed at approve or submit, the BHD earmark would have been cancelled with a camt.049 - no BHD would have moved.

Why the trigger side goes first

A reservation is a promise the operator can rely on; a prepared instruction is not. So the leg that cannot be reserved is executed first, and the reserved leg is released only once the other has completed. Both are paid, or neither is.

Polling is part of the life cycle

The trigger adapter creates the payment instruction, follows its life cycle and periodically calls the trigger to query the result. The workflow does not advance until the status it is waiting for arrives.

Hashes on the ledger, data at home

Only the hash of each leg and the status transitions - matched, reserved, settled, completed - are written to the shared ledger. The instruction itself stays in the node that owns it.

Two adapters

Same workflow, different conversations

The RTGS adapter and the trigger adapter answer the same questions from the state machine - can you reserve, can you settle, did it work - with entirely different messages.

StepRTGS adapter · BHDTrigger adapter · USD
How the node reaches itInvokes the API endpoints the RTGS exposes for operations such as funds reservation and settlement. Payload formatting, generation and response parsing are handled by the adapter.REST APIs offered by the trigger service to create and interact with payment instructions and to query their statuses.
Reservecamt.103 create reservation → camt.047 confirmation. Fund reservation complete is recorded on the ledger.Not supported. The adapter calls create to prepare the instruction instead; the leg is settled conditionally, first.
Settlepacs.009 releases the earmark → pacs.002 final status.approve - signed by the node on behalf of the payer bank - then submit; the adapter polls for status until completed.
ConfirmSettlement complete for leg 1 recorded on the ledger.Settlement complete for leg 2 recorded on the ledger; the trigger returns a complete status to the node.
If it failsReservation cancelled with camt.049; the transaction moves to its failure state.Approve or submit fails → no payment made; the other side's reservation is cancelled.

The trigger life cycle

Create, approve, submit: three calls and one signature

createpreparedapprove · digitally signedapprovedsubmitsubmittedpoll statuscompleted

Create

The node creates a payment instruction in the trigger service. From here it follows the instruction's life cycle, state by state, rather than firing and forgetting.

Approve

The trigger's approve function translates the payer bank's approval of the payment into its literal meaning. The operator calls it on behalf of the payer bank and digitally signs the request - the signature, not the operator's word, is what authorises the payment.

Submit and query

The node submits the instruction for settlement, then periodically calls the trigger to query the result. Upon success the trigger returns a complete status back to the node, and the workflow moves 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