System

Key architectural concepts and key elements of transaction flow

Submit

• Transactions are submitted, in various formats, to the network.
• After Validation, these Transfer Requests are forwarded for Scheduling.

Schedule

• After message validation, each Transfer request is separated into individual transactions and each transaction is resolved to a number of ledger updates along a settlement path.
• The scheduler accesses a network map of participants and will use this information, together with information retrieved from the individual participants, to construct a settlement path that allows for the transfer of a particular asset from Sender to the Beneficiary along a derived settlement path.

Approve

• Each party (participant) in a settlement chain will receive details of the intended settlement and must respond positively or negatively with regard to their ability to process this settlement.
• The approval state will ultimately resolve to yes or no, but the actual state can include a context, (e.g. 'Lack of Funds', 'AML Hold' etc.) to provide users with additional actionable steps to facilitate settlement.

Assemble / Sequence

• The role of the Assembler is, for each Transaction in each Transfer request, to tally the Approvals and Rejections.
• Additionally the assembler will also send a Transaction message to the Sequencer.
• The Sequencer can commit the completed transaction identifiers to a blockchain so that parties may reconcile ledgers based on a common understanding of transaction ordering.

Finalise

• Once all parties have submitted Approvals, an 'Approve' message will be sent to all parties signalling that they must now commit this Transfer to their respective ledgers.
• In the event of receiving a Reject message, the Assembler will immediately send a 'Reject' message to each party signalling the failure of this Transfer – this can then be remediated and resubmitted to the network.