Networkmap

The Network

The RLN creates and maintains a map of settlement connections between partitions for each instrument maintained in the RLN. This map allows the RLN to work out which partitions are involved in a transaction. For example, if a corporate user who banks with a UK commercial bank wants to send money to a corporate user at a US commercial bank, the RLN determines which partitions need to be updated and which entities need to approve the transaction. Similarly it can be used to map connections to settle daily/intraday variation margin for two parties who have entered into a futures contract via a Central Counter Party (CCP).

A transfer in the RLN can be summarised as below. A transfer is first proposed to the RLN, which uses the network map to determine the impacted partitions. The RLN publishes the request, which is sent to the relevant partition operators for approval. Once approved by all impacted partition operators the transfer is executed and all ledgers are updated.

Network Implementations

- Multi Consumer / Multi Partition / Multi Cluster

• A Scalable And Resilient Deployment
• Single Kafka Cluster
• Able to have multiple partitions per Kafka topic therefore increasing messaging throughput.
• Multiple Scheduler / Assembler / Sequencer instances or threads to match partition configuration.
• No requirement to tag messaging with cluster or topic metadata.
• Consistent message keying to allow Assembler interfaces to ensure consistent message allocation to partitions.
• Assembler understands and constructs topic name routing to individual participants for proposal and finalisation messaging.
• Privacy model – proposals and finalisation messages only visible to specific parties.
• Utilises a comprehensive Kafka permissioning model – certificate based identity and topic ACLs (Access Control Lists).

- Segregated Settlement Groups

• This evolution of the LedgerSwarm architecture introduces the concept of separate 'settlement contexts'
• A settlement context is a discrete instance of the core components required to process settlement (i.e. the Validator, Scheduler, Assembler and Sequencer).

• The participants remain the same, but each transfer may be directed to a specific context. The key benefits of this this are that it allows:

  • Configurable geography
  • Increased privacy
  • Increased capacity
    

• Key Features

  • Universal or separate Kafka cluster per context
  • Single or multiple partitions per topic – as per architectures V1 & V2.
  • Single or multiple Scheduler / Assembler / Sequencer instances or threads to match partition configuration.
  • Ability to tag messaging with cluster and topic metadata. Settlement contexts use separate Kafka clusters and / or distinct Kafka topic names. LedgerSwarm components observe and respect Kafka cluster and topic indicators in message bodies or headers.
  • Consistent message keying required for Assembler interfaces to ensure consistent message allocation to partition.
  • Assembler understands topic name routing to individual participants for proposals and finalisation messaging.
  • Improved privacy / pegulatory model – Settlement contexts can be established for regulatory, geographic, data protection or privacy reasons.
  • Improved capacity – allows participants to alleviate networking, storage or computational constraints within the settlement process.
  • Allows for a more complex Kafka permissioning model – Certificate based identity and topic ACLs.

- Private Domains

• The Ledger Swarm architecture can be extended to allow the inclusion of Private Sub-Domains.

  • Each domain can operate independently of each other but, when required, a settlement across domains can be orchestrated.
  • Each domain must maintain a list of participants addressable within that domain and must feed that information into the public Domain network mapping so that the public domain has an awareness of all participants across all domains.
  • Private domains identify a single scheduling context that the public domain uses for interactions with the sub-domain.
  • If a participant in a sub-domain requests settlement to a party outside of their domain, then the scheduler will pass the transfer request to the public domain.
  • The public domain scheduler will build a settlement path, requesting information directly, or indirectly, from the relevant participants.
  • The same protocol can be used if a transfer request is initiated from the public domain that involves participants in sub-domains.
  • After scheduling, the Assembler interacts with the settlement participants either directly or through a relay within the sub-domain to both request and receive the necessary approvals.
  • Once approved, the finalisation message is propagated to the transaction participants directly or through the domain relays.
    

• Key Features

  • Kafka cluster, topic and partitioning options as per previous architectures.
  • Message keying requirements as per previous architectures.
  • Kafka permissioning model as per previous architectures.
  • Requirement to tag messaging with domain, cluster and topic metadata.
  • LedgerSwarm components observe and respect message routing indicators in message bodies or headers.
  • Advanced privacy / regulatory model – Institutions can maintain complete privacy and security for internal settlements whilst leveraging the global network.
  • Improved capacity – as localised settlements have no impact on the public network.