WO2018192931A1

WO2018192931A1 - Delivery versus payment mechanism

Info

Publication number: WO2018192931A1
Application number: PCT/EP2018/059795
Authority: WO
Inventors: David Campbell BRIERLEY; Kenneth Michael John TREGIDGO; Katherine Louise WEBBER
Original assignee: Calastone Limited
Priority date: 2017-04-19
Filing date: 2018-04-17
Publication date: 2018-10-25

Abstract

A computer-implemented method for providing a delivery versus payment mechanism for settlement of transactions on a distributed consensus ledger platform, a settlement comprising the exchange of an amount of an asset from a first party for the payment of purchasing tokens from a second party, the computer-implemented method comprising: storing the amount of the asset for the settlement at a first address in the distributed consensus ledger platform associated with a first smart contract; storing the purchasing tokens for the settlement at a second address in the distributed consensus ledger platform associated with a second smart contract; providing an authentication period for the identities of the first party and second party to be authenticated using an authentication procedure; and when a time lock period expires, if the identities of the first party and second party have been positively authenticated by the authentication procedure during the authentication period, releasing from the first address the amount of the asset to the second party and from the second address the purchasing tokens to the first party.

Description

Delivery Versus Payment Mechanism

Technical Field

The present application relates to systems and methods for providing a delivery versus payment mechanism.

Background

Delivery versus payment (DVP) is a settlement procedure in which the payment for an asset (e.g. units of a fund) is due at the time of delivery. DVP stipulates that cash payment must be made prior to or simultaneously with the delivery of the asset.

DVP is also known as delivery against payment (DAP), delivery against cash (DAC) and cash on delivery and, as used herein, includes receipt versus payment (RVP) which is the same concept from the seller's perspective as opposed to the buyer's.

A DVP settlement mechanism ensures that delivery of the asset to one party will occur only if a payment occurs by the other party.

The present invention seeks to provide a computer-implemented DVP settlement mechanism.

Summary

Accordingly, the inventors have developed an improved computer-implemented method for providing a delivery versus payment mechanism for transactions on a distributed consensus ledger platform.

A transaction may involve an exchange of of an amount of an asset from a first party (which can, although not always, be referred to as the seller) for a payment of purchasing tokens from a second party (which can, although not always, be referred to as the purchaser). A typical transaction comprises two stages: (i) the order being placed and (ii) the settlement (including payment in exchange for the amount of the asset). Typically, DVP features as part of the settlement.

It will be apparent that a wide variety of potential assets exist. These may include, but are not limited to, funds, bonds, shares, property, goods and provisions of services.

Purchasing tokens may optionally comprise any form of money, which includes physical currency, online currency and crypto-currency. Alternatively, purchasing tokens may be any tokens suitable for payment or exchange in a transaction. There may be one or more purchasing tokens, or the purchasing tokens may be broken down into fractional increments. The computer-implemented method may comprise storing the amount of the asset for the settlement at a first address in the distributed consensus ledger platform associated with a first smart contract and storing the purchasing tokens for the settlement at a second address in the distributed consensus ledger platform associated with a second smart contract. The first and second addresses may be the same address or they may be different addresses. The first and second smart contracts may be the same contract or different smart contracts, though in a particular embodiment the same smart contract is used. This storing means that both the asset and purchasing tokens are stored in a location not directly associated with either party to the transaction (i.e. a first party (e.g. a seller and a second party (e.g. a purchaser)). A time-lock may be implemented which locks the asset and purchasing tokens at the first and second address until a defined or pre-determined time or for a defined or pre-determined time period.

The method may further comprise providing an authentication period for the identities of the parties to the transaction to be authenticated using an authentication procedure. The authentication procedure may comprise the use of one or more digital signatures. Other authentication methods may be utilised, for example authentication using hashing algorithms.

When the time lock period expires, if the identities of the first party and the second party have been positively authenticated by the authentication procedure during the

authentication period, the method may comprise releasing, from the first address, the amount of the asset to the second party and, from the second address, the purchasing tokens to the first party. When the time lock period expires, if the identities of both the first party and the second party have not been positively authenticated by the authentication procedure during the authentication period, the method may further comprise initiating an exception process.

The time lock period may be, for example, an industry-standard time period that is fixed for all or some settlements. Such a fixed or standard time period may be suitable when the asset comprises, for example, one or more funds. Alternatively, the predetermined time lock may be variable and specific to a particular settlement. Such a variable time lock may be suitable when the asset is a physical good, such as a house.

The distributed consensus ledger platform may comprise one or more distributed consensus ledgers comprising ledger entries. Each ledger entry may have a respective address in the one or more distributed consensus ledgers and the ledger entries may comprise respective addresses representing respective current amounts of assets of respective first parties and respective addresses storing respective current balances of purchasing tokens of respective second parties, in particular, purchasers.

The computer-implemented method may further comprise moving the amount of the asset for the settlement from an address in the distributed consensus ledger platform associated with the first party to the first address and moving the purchasing tokens for the settlement from an address in the distributed consensus ledger platform associated with the second party to the second address. The first and second addresses may be different addresses, or they may be the same address.

Releasing the amount of the asset for the settlement to the second party may comprise moving the amount of the asset for the settlement from the first address to an address in the distributed consensus ledger platform associated with the second party. Releasing the purchasing tokens for the settlement to the first party may comprise moving the purchasing tokens for the settlement from the second address to an address in the distributed consensus ledger platform associated with the first party. The address associated with the second party from which the purchasing tokens for the settlement are moved may be the same as the address associated with the second party to which the assets are released. Alternatively, the addresses may be different.

The address associated with the first party from which the amount of the asset for the settlement is moved may be the same as the address associated with the first party to which the purchasing tokens are released. Alternatively, the addresses may be different.

The delivery versus payment mechanism on the distributed consensus ledger platform may be initiated in response to receiving an order instruction. The order instruction may specify the amount of the asset and a corresponding amount of purchasing tokens for the settlement. The order instruction may be produced by the first party or the second party. A settlement instruction may be created from the order instruction, wherein the settlement instruction specifies the amount of the asset and a corresponding amount of purchasing tokens for the settlement, the address in the distributed consensus ledger platform associated with the first party and the address in the distributed consensus ledger platform associated with the second party. The settlement instruction may initiate the moving of the amount of the asset and the purchasing tokens for the settlement.

The settlement may relate to a buy order and/or sell order, or a transfer of ownership. A computer system is disclosed and may be configured to perform any of the features of the computer-implemented method described above.

A computer network is disclosed and may be configured to perform any of the features of the computer-implemented method described above.

A computer program comprising computer readable instructions may be configured to cause one or more computer systems to perform any of the features of the computer- implemented method described above. Brief Description of the Figures

Illustrative embodiments of the present disclosure will now be described, by way of example only, with reference to the drawings. In the drawings:

Figure 1 shows a representation of a typical order flow path through an order flow network;

Figure 2 is an illustrative example of the computer systems used to process instructions in a network;

Figure 3 shows the architecture of an example apparatus or device;

Figure 4 is a flowchart of a method of configuring a computer system to process instructions;

Figure 5 is an example table of order request messages;

Figure 6 is a flowchart of a method for establishing the nodes and relationships between nodes of a network from the order flow request messages of Figure 5;

Figure 7 is a graph showing the nodes, assets, node-node relationships and node-asset relationships for the data of Figure 5; Figure 8 is a flowchart of a method for configuring a distributed consensus ledger of a computer system to store entries relating to nodes and relationships between nodes of a network;

Figure 9 illustrates entries stored in a distributed consensus ledger;

Figure 10 illustrates an address map;

Figure 1 1 is a flowchart of a method for processing a new instruction record;

Figure 12 is a diagram showing the transfer of data between nodes; and

Figure 13 shows a plurality of distributed consensus ledgers.

Figure 14 shows a flowchart of a method of providing delivery versus payment for settlement of a transaction.

Throughout the description and the drawings, like reference numerals refer to like parts.

Detailed Description

The present invention relates to a computer-implemented method for providing a delivery versus payment mechanism for settlement of transactions on a distributed consensus ledger platform. A settlement comprises the completion of a transaction where an amount of an asset is exchanged for the payment of purchasing tokens. As well as the method, the invention also relates to a computer system configured to perform the method, a computer program comprising computer readable instructions to cause one or more computer systems to perform the method, and a computer network configured to perform the method. The method for providing a delivery versus payment mechanism for a settlement of a transaction will be described with reference to Figure 14. The method uses a distributed consensus ledger platform. Different implementations of a distributed consensus ledger platform can be used and, before describing the method of Figure 14, one particular implementation of a distributed consensus ledger will be described with reference to Figures 3 to 13.

Whilst a particular implementation of a distributed consensus ledger and particular embodiments of the invention are described below, the invention is not limited to this implementation and these embodiments, and variations of this implementation and these embodiments may be made without departing from the scope of the invention. Before describing Figures 3 to 14, some background will be given with reference to Figures 1 and 2. Figure 1 shows a representation of a typical transaction or instruction path / distribution chain for the UK funds market although it is applicable to multiple market structures. In practice, an investor 1 10 may or may not use an independent financial advisor (IFA) 1 12 who stores a local client record/register for the investor 1 10 and other investors (not shown). If the investor 1 10 wants to buy into a fund, the IFA 1 12 makes a record of this locally. The IFA 1 12 may then use an intermediate unit holder (IUH) 1 14 (or go directly to the main register) to perform various functions, particularly market access across multiple fund managers and some administration functions. The IUH 1 14 typically holds a sub-register with investor named holdings. There can be more than one IUH in the chain. The IUH will aggregate the investors' trade with other trades on any given trade date and may use a platform 1 16 for market access (which themselves are a further IUH). Once aggregated, the fund manager 120 is typically unaware of the investor 1 10 and is instead aware of the nominee position of which the investment for investor 1 10 is part of. The fund manager 120 may outsource the daily management of the shareholder record to a transfer agency 1 18 who manages the shareholder record and instructs the custodian who creates or liquidates units/shares of the fund on the main register accordingly. Each party - the IFA, the IUH, the platform, the fund manager and the transfer agency - can be thought of as nodes of the network. The flow of instructions from one node to another defines the activity between each pair of nodes.

As can be imagined, when there are a large number of institutions involved in the value chain, with multiple investors, IFAs, lUHs, platforms, fund managers and transfer agencies represented, the network is very large and, similarly, the number of separate locally held records and registers is very large making it difficult to reconcile the various records.

Figure 2 is an illustrative example of the computer systems used to process transaction records along a path through a transaction network, in particular, between a plurality of fund managers 212, 214, a plurality of platforms 216, 218 and a plurality of transfer agencies 232, 234, 236. Transactions are communicated over a network 220 via a server 240. The transaction records are often sent in any of many different formats and so there is a lot of computational complexity in processing the records.

Moving away from the background of Figures 1 and 2, a distributed consensus ledger, sometimes known as a blockchain, is a type of distributed database. A distributed consensus ledger enables tamper-resistant and decentralised storage of data. A copy of the ledger can be stored on each of multiple nodes of a network and is accepted as a single version of the truth.

A distributed consensus ledger typically comprises data structure blocks that may contain data or computer-executable instructions, with each block holding one or more individual data entries or computer-executable instructions. In this way, if the ledger is used, for example, to record instructions such as transactions, then a complete history of transactions can be established on the ledger. Each block contains a link to the preceding block, for example, a hash value of the information in the preceding block. The hash value is typically determined by using the information in the preceding block as the input to a hash function which outputs the hash value. Each data structure block of the distributed consensus ledger links back to the preceding block.

Although the hash value is typically simple to compute, there are usually one or more validity requirements imposed on the hash value. For example, the hash value may have to be below a certain threshold value. In addition, the hash value is normally based on a special type of mathematical function that is not reversible and so one cannot readily know which input will give a desired output without trialling numerous inputs. A valid hash value can be found by repeatedly adjusting a changeable value, or nonce, in the most recent block on the ledger, and recalculating the hash until it meets the validity requirements.

When a valid nonce for the most recent data block is found for which the validity requirements or proof standard is met, a new block can be added to the ledger. Each node can independently verify that the nonce is valid for the block and thereby accept the new block as a valid extension of the ledger. A copy of the extended distributed consensus ledger may therefore be stored on each of the nodes.

Once a block has been added to the distributed consensus ledger, if anyone attempts to tamper with the information in the block then this will change the hash value of that block, which for the tampering to go undetected must be recomputed and stored in the next block. This would change the hash value of the next block, which for the tampering to go undetected must also be recomputed and so on until the end of the chain. Accordingly, once a block is written to the distributed consensus ledger, the computing power and speed required to rewrite the data in the block and each subsequent block of the ledger makes tampering highly infeasible. A distributed consensus ledger may have permissions set so that any given user may only be able to view a particular subset of data within the ledger. Furthermore, a distributed consensus ledger may be protected through encryption. The data structure blocks of a decentralised consensus ledger may contain any data, for example, a data record indicating a transaction between two parties. A block may additionally or alternatively contain computer-executable instructions, sometimes referred to as a smart contract, which can be activated by a call to an address within the ledger at which the block containing the computer-executable instructions resides to perform a defined function and, as the instructions are contained within the distributed consensus ledger, the defined function is an immutable function. In this way, the distributed consensus ledger may act as a consensus-based globally executable virtual machine.

Smart contracts may be used for a number of purposes. The smart contract may be activated by calling the address in the distributed consensus ledger at which the smart contract is stored and providing any required inputs for the function. A smart contract may in turn call one or more other smart contracts or make reference to other data entries within the ledger by referring to the address at which the other smart contracts or data entries are located.

Smart contracts may be written in any suitable programming language, for example Solidity. A contract in the sense of Solidity is a collection of code (its functions) and data (its state) that resides at a specific address on the distributed consensus ledger. The smart contract can be thought of as a computer-implemented program at an address on the ledger that can be queried and "updated" by calling functions of the code that manage the database. In practice, due to the nature of the distributed consensus ledger, even if data is "overwritten", the number will still be stored in the history of the distributed consensus ledger as the overwriting will not entail changing data stored earlier in the distributed consensus ledger but will entail creating a new entry at an associated address in the ledger.

Figure 3 shows the architecture of an example apparatus or device 300. The apparatus or device 300 comprises a processor 310, a memory 3 5, and a display 335. These are connected to a central bus structure, the display 335 being connected via a display adapter 330. The example apparatus or device 300 also comprises an input device 325 (such as a mouse and/or keyboard) and a communications adapter 305 for connecting the apparatus or device to other apparatuses, devices or networks such as network 220 which may be the Internet. The input device 325 and communications adapter 305 are also connected to the central bus structure, the input device 325 being connected via an input device adapter 320. In operation the processor 310 can execute computer-executable instructions stored in the memory 315 and the results of the processing can be displayed to a user on the display 335. User inputs for controlling the operation of the computer may be received via input device(s) 325. The memory 315 may be used to store a copy of a distributed consensus ledger, and the device 300 may process instruction records in order to add data entries to the distributed consensus ledger.

Figure 4 is a flowchart of a method of configuring a computer system to process instruction records for a network comprising a plurality of nodes. Each instruction record relates to a corresponding instruction and is indicative of a first node and a second node in the network. Each instruction record comprises a first identifier which identifies the first node, a second identifier which identifies the second node, and data relating to the instruction. The data relating to the instruction may comprise a resource identifier which identifies a resource. The resource may be an asset and the resource identifier may be an asset identifier. The data relating to the instruction may further comprise an amount, indicating the amount of the asset to be processed with the instruction.

The computer system may comprise one or more computing devices such as the computing device shown in Figure 3. The computer system has at least one computer processor and at least one computer memory, the at least one memory comprising one or more distributed consensus ledgers of the distributed consensus ledger platform.

At step 410, a set of instruction records is used to identify nodes and relationships between nodes in the network. The nodes are identified from the first identifiers and the second identifiers of the set of instruction records and the relationships are identified from the first identifier and second identifier of each individual message. The set of instruction records may also be used to identify assets to which instructions in the network relate. The assets are identifiable from their corresponding asset identifiers. The combination of the first identifier and the asset identifier may be used to identify a node-asset relationship between the first node and the asset. The combination of the second identifier and the asset identifier may be used to identify a node-asset relationship between the second node and the asset.

Step 410 may be referred to as "pre-baking".

At step 420, a ledger entry is created at a respective address in the one or more distributed consensus ledgers for each node of the network and for each relationship between nodes within the network. A corresponding ledger entry may also be created at a respective address in the one or more distributed consensus ledgers for each asset. A corresponding ledger entry may also be created at a respective address in the one or more distributed consensus ledgers for each identified node-asset relationship. That is, for a node-asset relationship between a first node and an asset, a corresponding ledger entry may be made at a respective address in the one or more distributed consensus ledgers and, for a node-asset relationship between a second node and an asset, a corresponding ledger entry may be created at a respective address in the one or more distributed consensus ledgers.

At step 430 an address map is created. The address map maps a node identifier for each node to the respective address of the corresponding ledger entry for the node. The address map further maps a relationship identifier for each relationship between nodes to a respective address of a respective ledger entry. The address map may further map an asset identifier for each asset identified from the instruction records to a respective address of a corresponding ledger entry, and may further map a node-asset relationship identifier for each identified node-asset relationship to a respective address of a corresponding ledger entry.

At step 440, a smart contract is created in the distributed consensus ledger, the smart contract for processing an instruction relating to an instruction record. The smart contract is configured to use the first identifier and second identifier from the instruction record to identify the node identifiers for the instruction. The smart contract is further configured to use the combination of the first identifier and second identifier to identify the relationship identifier for the instruction. The smart contract is further configured to use the address map to look up the respective address for each of the node identifiers and relationship identifier. The smart contract is further configured to process the instruction to obtain processing output for each of the node identifiers and relationship identifier. The smart contract is further configured to store the processing output for each of the node identifiers and relationship identifier at an associated address in the one or more distributed consensus ledgers. The smart contract may further be configured to use the address map to look up the respective address for the asset identifier, process the instruction to obtain processing output for the asset identifier, and store the processing output for the asset identifier at an associated address in the one or more distributed consensus ledgers. The smart contract may further be configured to use the combination of the first identifier and asset identifier and the combination of the second identifier and the asset identifier to identify the node-asset relationship identifiers for the instruction, use the address map to look up the respective address for each node-asset relationship identifier, process the instruction to obtain processing output for each of the node-asset relationship identifiers, and store the processing output for each of the node-asset relationship identifiers at an associated address in the one or more distributed consensus ledgers.

Steps 420-440 comprise an example of "baking". Figure 5 shows a table of instruction records for a network. In this example, the network is an order flow network and the instruction records comprise order instructions which, in this example, are referred to as order request messages. In particular, Figure 5 shows a table of six simulated buy order request messages in a small order flow network comprising two distributors and two fund managers. At 510 it is shown that DistributorX orders £3,000 worth of ISIN1 from FundManagerX. At 512 it is shown that DistributorX orders £1 ,000 worth of ISIN1 from FundManagerX. At 514 it is shown that DistributorX orders £4,000 worth of ISIN2 from FundManagerY. At 516 it is shown that DistributorX orders £22,000 worth of ISIN3 from FundManagerY. At 518 it is shown that DistributorY orders £18,000 worth of ISIN3 from FundManagerY. At 520 it is shown that DistributorY orders £7,000 worth of ISIN1 from FundManagerX. The skilled person would appreciate that the order request messages may be buy messages or sell messages. In other words, the settlements for the transactions may be buy settlements or sell settlements and the order instructions may be buy instructions or sell instructions. By analysing the data, one can build up knowledge of the underlying order flow network including the nodes of the network and the relationships between them. One can also build up knowledge of the assets to which the order request messages relate and the relationships between a given node of the order flow network and the asset. For each order request message, the amount information can at this stage be disregarded and is not required for capturing the structure of the order flow network in a distributed consensus ledger. However, entries corresponding to the qualitative data concerning the items in the order list, e.g. entries corresponding to each of the distributors, fund managers and ISINs, are recorded onto a distributed consensus ledger. Accordingly, an entry for each distributor, each fund manager and each ISIN is written to the distributed consensus ledger and can subsequently be referred to by a corresponding address on the ledger.

The skilled person would appreciate that Figure 5 shows a simplified table of data and that other data may be included and processed. Alternatively, data such as the amount information may be excluded from some of the order request messages. With reference to Figures 5 and 6, an example of pre-baking 410 is demonstrated.

Starting at steps 602, an identifier list is initiated. At step 604 a relationship list is initiated. The simulated dataset of Figure 5 is received at step 606.

At step 608, an order request message from the dataset is read in, for example the order request message 510. An identifier within order request message 510, "Distributor 1 " is selected at step 610. A check is performed at step 612 to determine whether the identifier has already been stored in the identifier list. As "Distributor 1 " is the first identifier of the order request message to be selected, a determination is made that the identifier has not already been stored in the identifier list. Accordingly, "Distributor 1" is output to the identifier list at step 616. At step 618 a check is performed to see whether or not there are further identifiers in order request message 510. In this case example there is a previously identified node and so the process returns to step 610, at which the identifier

"FundManagerX" is selected. "FundManagerX" is stored in the identifier list (612, 614) and the process returns (via step 618) to step 610 at which "ISIN1 " is selected. "ISIN1" is stored in the identifier list (612, 614). There are no more identifiers in order request message 510 and so at step 618, the process continues to step 620.

At step 620, a relationship is selected. In particular, the relationship is a key value pair comprising a pair of identifiers. The key value pair "DistributorX/FundManagerX" is selected. At step 622 a check is performed to determine whether or not the key value pair "DistributorX/FundManagerX" has already been stored in the relationship list. As the key value pair "DistributorX/FundManagerX" has not already been stored in the relationship list, the key value pair is output to the relationship list at step 626. At step 628 a check is performed to determine whether or not there are further key value pairs to select and the process returns to step 620 where the key value pair "DistributorX ISI N 1 " is selected. The key value pair "DistributorX/ISIN1 " is also output to the relationship list (622, 626) and the process returns to step 620 via step 628. At step 620, the key value pair "FundManagerX/ISIN1 " is selected. The key value pair "FundManagerX/ISINT is also output to the relationship list (622, 626). At step 628, a determination is made that there are no further identifier pairs to be stored in the relationship list and the method proceeds to step 630 at which point it is determined that there are further data entries to read and the process returns to step 608.

At step 608, the second order request message 520 is read in. Order request message 520 comprises a second buy order having the same sender, receiver and ISIN.

Accordingly, at step 610 the identifier "DistributorX" is selected but at step 612 a determination is made that "DistributorX" is already stored in the identifier list and so no action is taken (step 614) and the process returns to step 610. Each of "FundManagerX" and "ISIN1 " are already stored in the identifier list and so ultimately the process proceeds to step 620 without storing further identifiers in the identifier list. At step 620 the node-node relationship, or key value pair, "DistributorX/FundManagerX" is selected. At step 622 a determination is made that this key value pair is already stored in the relationship list and so no action is taken concerning the key value pair (step 624) and the process returns to step 620. For each of the node-asset relationships

"DistributorX/ISIN1 " and "FundManagerX/ISI 1 " no action is taken (steps 622, 624) and so the method proceeds to step 630. At step 630, a determination is made that there are further order request messages to be read (entries 530, 540, 550 and 560) and so the process continues for order request message 530 at step 608.

The skilled person would appreciate that the various steps shown in Figure 6 may be performed in another order. For example, the relationships may be recorded before the nodes and so on.

After reading all of the order request messages, the process ends (step 632). In this way all of the identifiers from order request messages 510, 520, 530, 540, 550 and 560 are stored in the identifier list and all key value pairs/ identifier pairs are stored in the relationship list. Accordingly, the identifier list and the relationship list now contain information relevant to the structure of an order flow network that the order request messages 510-560 define and also captures the node-asset relationships between each node of that order flow network and each asset (see Figure 7). Figure 7 shows a graph representing the identifiers and the relationships between the identifiers. In particular, the identifiers are shown as nodes on the graph of Figure 7 while the key value pairs are shown as edges of the graph of Figure 7. Figure 8 is a flowchart describing the baking process according to an example. At step 802 the identifier list is read. An identifier from the identifier list is selected at step 804. As this is the first time that the identifier list has been read the first entry "DistributorX" is selected.

At step 806, a ledger entry is created at a respective address in the one or more distributed consensus ledgers for a node "DistributorX". The block of the distributed consensus ledger may contain node-specific information about an entity "DistributorX". For example, the block of the distributed consensus ledger may contain the

name/identifier "DistributorX". The block of the distributed consensus ledger may further comprise a link to another address in the one or more distributed consensus ledgers relating to a digital wallet for the entity "Distributor 1. Accordingly, by referencing the address at which the entry relating to node "DistributorX" is written, a program may also, with the correct permissions, access a digital wallet relating to that node.

At step 808 a check is performed to determine whether or not there are further identifiers in the identifier list. The process returns to step 804 and the node identifier

"FundManagerX" is selected. A ledger entry is created at a respective address in the distributed consensus ledger for the node "FundManagerX". Node-specific information concerning network node "FundManagerX" may be written to the entry. After an entry has been created at a respective address in the distributed consensus ledger for each of the identifiers in the identifier list, the process proceeds to step 810. At step 810 the relationship list is read. A relationship / key value pair is selected from the relationship list at step 812. In this example, the first selected key value pair is the

"DistributorX/FundManagerX" key value pair. A ledger entry is created at an address of the distributed consensus ledger for the key value pair at step 814. The process repeats (step 816) until ledger entries are created at respective addresses in the distributed consensus ledger for each of the relationships listed in the relationship list.

Figure 9 illustrates the entries stored in a distributed consensus ledger after the baking process of Figure 8. As is shown, after step 816, each network node and asset has a ledger entry at a respective address on the distributed consensus ledger (blocks 902, 904, 906, 908, 910, 912, 914) and each relationship / key value pair has an entry at a respective address on the distributed consensus ledger (blocks 916, 918, 920, 922, 924, 926, 928, 930, 932, 934, 936). At step 818, a smart contract called AddressMap is written to a block 938 of the distributed consensus ledger. The block 938 contains an address map comprising a list of entities (representing the identifiers and relationships between identifiers) and the respective addresses of the ledger entries corresponding to each of the entities.

Accordingly, if a smart contract were to access the address map, it could use the address map to find the address on the distributed consensus ledger of information specific to that entity, and/or could use the address map to find an entity for a given address. For example, if the address map were accessed with "ISIN1" as an argument, the program that called the address map can determine that the entry corresponding to ISI N 1 " can be found at the address corresponding to block 906. Similarly, if the address map were accessed with "DistributorX/ISIN3" as the argument, the program that called the address map can determine that the entry corresponding to the entity "Distrbutor1/ISIN3" can be found at the address on the distributed consensus ledger corresponding to block 926.

The smart contract AddressMap can be implemented using the following Solidity code: contract AddressMap{

mapping (string => address) entities;

mapping (address => string) readentities;

uint count; function AddressMap(){ count = 0; }

function setEntity( string name ){

if ( entities[name] == 0x0 ){

entities[name] = new Entity(name);

count++;

readentities[ entities[name] ] = name;

}

function getEntity(address adr) constant returns(string){ return readentities[adr];} function getAdr(string name)constant returns(address){ return entities[name];}

Within the code, mapping (string => address) entities is a state variable. The address of the string "string" can be accessed by entities[string]. The state variable uint count is a variable called "count" that is of type unsigned integer of 256 bits. The function setEntity acts to define a new variable "name" as an entity based on a further smart contract function "Entity" and to increment the entity count by 1. The Entity function links to an address in the distributed consensus ledger at which a template defining properties of an entity to be stored as entity-specific information in the ledger. The entity function is able to create a ledger entry in the distributed consensus ledger for each node, relationship between nodes, asset and node-asset relationship. The Entity function can be implemented using the following Solidity code: contract Entity{

string name; function Entity(string _name) { name = _name; }

function set(string _name){ name = _name; }

function get() constant returns(string){ return name;}

}

As is shown in the Entity contract code, the entry corresponding to an entity in this example comprises a name of the entity. The name of the entity is set using the "set" function and the name is recalled using the "get" function.

The function getEntity takes an address of the distributed consensus ledger as an argument and returns the corresponding entity name. The function getAdr takes the entity name as argument and returns the address at which the ledger entry corresponding to that entity is defined.

A schematic of the information found in the address map can be seen in Figure 10.

At step 820, a smart contract OrderFactory is written to a block 940 of the distributed consensus ledger. The smart contract OrderFactory is used for processing supplementary orders as will be discussed below. The OrderFactory smart contract is configured to receive information pertaining to new orders and to identify, from the new orders, the respective node identifiers, asset identifier and amount plus any other information contained in the received information. At step 822, a smart contract Balance is written to a block 942 of the distributed consensus ledger. The smart contract Balance is configured to use a received sender identifier and receiver identifier to identify node identifiers of an order and use the combination of the sender identifier and receiver identifier to identify the relationship identifier for the order. The smart contract Balance is further configured to call the AddressMap smart contract in order to look up the respective address for each of the node identifiers and relationship identifiers. The smart contract balance may be configured to use the AddressMap contract to look up the respective address for the asset identifier. The smart contract Balance may be further configured to use the node identifiers and the asset identifier to identify the node-asset relationship identifiers for the order and use the AddressMap contract to look up the respective address for each node-asset relationship identifier.

The smart contract Balance is further configured to perform the order processing to obtain processing output for each of the node identifiers and relationship identifiers, and for the asset identifiers and the node-asset relationship identifiers, and to store the processing output for each of the node identifiers, relationship identifiers, asset identifiers and node- asset relationship identifiers at associated addresses in the distributed consensus ledger.

In particular, the smart contract balance is configured to update a balance associated with each node, asset, and node-node and node-asset relationship based on the amount provided in the order. Accordingly, on calling the smart contract balance with the node identifiers and asset identifier as arguments, a balance associated with each of the node identifiers is updated accordingly, an asset associated with each relationship between nodes is updated accordingly, a balance associated with an asset is updated accordingly and a balance associated with each node-asset relationship is updated accordingly. The Balance smart contract maps the address of each entry corresponding to the various nodes and relationships to an associated address at which the balance for that node or relationship is stored.

Figure 1 1 shows a flowchart of a method for processing a new transaction record, in this case an order instruction in the form of an order request message. The method for processing a new transaction record may be referred to as "rippling".

At step 1 1 10, a new order request message is received, the order request message relating to a new order and comprising a first identifier identifying a first node of the order flow network and a second identifier identifying a second node of the order flow network. The new order request message further comprises data relating to the order. The data related to the order further comprises an asset identifier relating to the asset about which the order is concerned and an amount identifier identifying the amount of the asset to which the order relates.

As an example, the new order request message comprises a buy order request from DistributorX to FundManagerX for £12,000 worth of ISIN1.

At step 11 12, the first identifier and the second identifier from the order request message are used to identify the node identifiers of the new order. The combination of the first identifier and the second identifier is used to identify the relationship identifier for the order, the relationship identifier identifying the relationship between the first node and the second node.

At step 4, a check is made to determine whether or not each of the node identifiers, relationship identifiers and asset identifiers is accounted for in the address map. If a respective address is provided in the address map for each of the nodes, assets and relationships identified from the new order request message then the process continues to step 1 120. If one or more of the nodes, assets or relationships are not accounted for in the address map then the process continues to step 1 1 16. At step 1 1 16, for each node identifier, asset identifier, node-node relationship identifier or node-asset relationship identifier which is not mapped in the address map to a respective address in the distributed consensus ledger, a respective ledger entry is created in the distributed consensus ledger for the node, asset, node-node relationship or node-asset relationship to which the identifier relates. The identifier is then mapped to the respective address of the respective ledger entry for that node, asset, node-node relationship or node-asset relationship in the address map at step 1 1 18. The mapping of the identifier from the new order request message to the respective address using the "set"

functionality described above. At step 1 120, the amount information is read from the new order request message. For the current example, the amount is "12,000".

At step 1 122, the address map is used to look up the respective address for each node identifier, each asset identifier, each node-node relationship identifier and each node- asset relationship identifier. In the present example, the address map is used to find the addresses of blocks 902 and 904 of Figure 9 which correspond to the node identifiers for DistributorX and FundManagerX. The address map is used to look up the address for the key value pair "DistributorX/FundManagerX" (block 916), the address for the asset identifier "ISIN1" (block 906) and the node-asset relationships / key value pairs

"DistributorX/ISIN1 " and "FundManagerX/ISIN1 " (blocks 918 and 920 respectively). The respective address for each identifier is associated via the smart contract with a corresponding address storing the current balance for that identifier. Accordingly, for the address associated with the "DistributorX/FundManagerX" ledger entry, there is a corresponding address in the ledger which holds the current balance for the

"DistributorX/FundManagerX" key value pair, and similarly there are corresponding addresses storing the current balance associated with each of the other identifiers.

At step 1 124 a smart contract Balance is used to compute a new balance associated with each identifier. That is, the balances corresponding to each node, asset and relationship are updated.

At step 1 126, the respective new balances for each node, asset, node-node relationship and node-asset relationship are stored at new associated addresses in the distributed consensus ledger. Due to the nature of the distributed consensus ledger the old balance associated with each identifier is not erased from the distributed consensus ledger and will remain in the history of the ledger. The smart contract associates the address in the distributed consensus ledger for the respective entry corresponding to each respective node, node-node relationship, asset and node-asset relationship with the corresponding address showing the updated balance for that entry. In order to view a balance associated with a node, asset, or relationship, one can use the respective address of the entry for that node, asset or relationship in the distributed consensus ledger as an argument to a smart contract to view the balance stored at the corresponding address. One may also view previous balances. The consequences of baking transaction network information into one or more distributed consensus ledgers then using the ledgers to process new orders is very efficient and has far reaching effects. Another use case will now be described with reference to Figure 12.

As discussed above in relation to Figure 1 , typically any units belonging to an ultimate owner are held in staging nominee accounts across the IUH value chain. If the investor 1 10 decides to move to a different I FA 1 12, this results in the asset being moved from one nominee holding to another. In the example shown, an investor has decided to switch from one I FA (first order giver, "FOG" ,1210) to another I FA (first order giver 1212). The ceding first order giver 1210 is linked through an IUH value chain (1214, 1218, 1222) to the main register 1226 which is the ultimate record of ownership. At each stage in the IUH value chain, the records of what the investor owns need to match up, and this is denoted "M" in the figure. The acquiring first order giver 1212 is linked through an IUH chain (1216, 1220, 1224) to the main register 1226.

Traditionally, the transfer of the asset ownership records from one IUH value chain to another is a time-consuming and tedious task and it can take weeks for the records of an investor's ownership to be reconciled between all of the parties involved.

However, using methods such as those described herein, each of the institutions can be considered as nodes of a transaction network and are accordingly represented by a corresponding entry in a distributed consensus ledger. Similarly, the relationships between the institutions comprise key value pairs of the institutions which are also represented by corresponding entries in the distributed consensus ledger. Accordingly, to record the transfer of client information concerning the investor's holdings from one chain to another can be accomplished efficiently and quickly by updating the respective entries of the distributed consensus ledger.

In the specific examples described above, a single distributed consensus ledger has been used to store entries relating to nodes and relationships between nodes of a network, and to store smart contracts such as an address map and a balance contract. However, the skilled person would appreciate that more than one distributed consensus ledger may be used, and smart contracts stored within any of the distributed consensus ledgers may get or set entries in other distributed consensus ledgers by referring to an address of the requested entry in another distributed consensus ledger. This idea is now discussed with reference to Figure 12. Figure 12 shows a plurality of distributed consensus ledgers. In particular, Figure 13 shows an address ledger 1310, an instruction log ledger 1320, an object ledger 1330 and a fast ledger 1340.

The address ledger 1310 comprises a plurality of ledger entries at respective addresses. The plurality of ledger entries comprises respective ledger entries for corresponding nodes of a network and respective ledger entries for corresponding relationships between nodes within the network. The plurality of ledger entries may further comprise respective ledger entries for corresponding assets and respective ledger entries for corresponding node-asset relationships. Accordingly, for a network, each node, each relationship between nodes, each asset and each node-asset relationship is represented by a ledger entry in the address ledger 1310. The address ledger may be slowly built up after acquisition of new data concerning the network. The address ledger may also map identifiers to entries stored in other distributed consensus ledgers such as the object ledger 1330 or the instruction log ledger 1320.

The order log ledger 1320 comprises a plurality of ledger entries at respective addresses. The plurality of ledger entries comprises ledger entries for corresponding transaction records, each transaction record relating to a respective order. In particular, each of the plurality of ledger entries stored on the transaction log ledger 1320 stores all information pertaining to a respective transaction record. Accordingly, the transaction log ledger 1320 provides a record of all processed transaction records. The transaction log ledger can be built up slowly and each entry of the transaction log ledger can be represented in the address ledger.

The object ledger 1330 comprises a plurality of ledger entries at respective addresses. The plurality of ledger entries comprises ledger entries for corresponding objects and, in particular, smart contracts and other data produced through the operation of smart contracts, for example updated balances etc. The object ledger comprises information that is not necessarily required for all instructions and accordingly does not need to be quickly updated. Each entry of the object ledger may be represented in the address ledger. The fast ledger 1340 may contain a series of smart contracts, which are operable to reference entries of other ledgers to process transaction records. The fast chain 1340 processes the bare minimum information required to process an instruction record and accordingly can be used to process instructions in almost real time. In particular, one or more of the smart contracts may be configured to identify nodes, assets, relationships and other data stored in the order log ledger 1320, to access the address ledger to look up a respective address for each of the nodes, assets and relationships, and to process the input to the smart contract according to computer-executable instructions stored within the smart contract in order to store the processed output in the object chain. Accordingly, the fast ledger 1340 may be used for performing actions quickly, whereas the address ledger, instruction log ledger, and object ledger may be used to store data that is not required in immediately. Accordingly, by storing addressable ledger entries across a plurality of distributed consensus ledgers, the entries can be grouped such that operations can be performed efficiently. In this way, operations that should be performed quickly are performed quickly, while operations that may be performed slowly can be performed slowly. In this way, trading, for example, can be recorded in almost real time while the detailed information pertaining to each trade can be updated/recorded at a slower pace.

The description above which has been given with reference to Figures 3 to 13 provides a detailed description of one implementation of a distributed consensus ledger platform in which the distributed consensus ledger platform comprises one or more distributed consensus ledgers comprising ledger entries. Each ledger entry has a respective address in the one or more distributed consensus ledgers. The ledger entries can comprise respective addresses representing respective current amounts of assets of respective first parties (in particular sellers) and respective addresses storing respective current balances of purchasing tokens of respective second parties (in particular purchasers).

A computer-implemented method for providing a delivery versus payment mechanism for settlements of transactions on a distributed consensus ledger platform, in accordance with an embodiment of the invention, will now be described with reference to Figure 14.

At step 1410 a new order instruction in the form of a new order request message is received. The new order request message relates to a new order and comprises a first identifier identifying a seller (a first party), which can be a node of an order flow network, and a second identifier identifying a purchaser (a second party), which can also be a node of the order flow network. The new order request message also comprises data relating to the order. The data related to the order comprises an asset identifier relating to the asset about which the order is concerned and an amount identifier identifying the amount of the asset to which the order relates. An example of a new order request message is a buy order request from DistributorX to FundManagerX for £10,000 worth of ISIN1.

At step 1412, a settlement instruction is created. The settlement instruction specifies the amount of the asset and the corresponding amount of purchasing tokens for settlement of the transaction, which are provided in the order request message. The settlement instruction also specifies the address in the distributed consensus ledger platform associated with the seller (the first party e.g. FundManagerX) and the address in the distributed consensus ledger platform associated with the purchaser (the second party e.g. DistributorX). These addresses are determined from the first identifier and second identifier, respectively, as has already been described with reference to Figure 1 1.

At step 1414, amount of the asset for the settlement is moved from the address in the distributed consensus ledger platform associated with the seller to a first address in the distributed consensus ledger platform associated with the a smart contract. The smart contract stores the amount of the asset for the settlement.

At step 1416, the purchasing tokens for the settlement are moved from the address in the distributed consensus ledger platform associated with the purchaser to a second address in the distributed consensus ledger platform associated with a smart contract. The smart contract stores the purchasing tokens for the settlement. It is not necessary that the smart contract that stores the purchasing tokens is the same smart contact as the one that stores the amount of the asset. One or more smart more smart contracts may be used.

By storing the purchaser's purchasing tokens at an address associated with the smart contract, as opposed to an address associated with the seller, the purchaser is protected because the seller never owns both the tokens and asset(s) at the same time. By storing the amount of the asset at an address associated with the smart contract, as opposed to an address associated with the purchaser, the seller is protected because the purchaser never owns both the tokens and asset(s) at the same time. This provides protection for both parties i.e. to both the first party and the second party.

At step 1418, a period is provided in which the identities of purchaser and seller can be authenticated via an authentication procedure. In this embodiment, the distributed consensus ledger platform uses public/private key encryption to authenticate the identities of the purchaser and seller. The seller can authenticate itself by signing a piece of data provided by the authentication procedure (e.g. a randomly generated piece of data) and the identity of the seller can be positively authenticated using the seller's public key. A similar process can be used for the purchaser to authenticate itself. As is known in the art, alternative approaches can be used.

The data for the authentication procedure in this embodiment is stored within the smart contract that stores, at associated addresses, the amount of the asset and the purchasing tokens. The time period provided by step 1418 enables each party (the purchaser and the seller) to confirm that they wish to proceed with the settlement by going through the

authentication procedure. If, for example, the purchaser has entered incorrect details (by, for example, adding an extra zero onto the amount of the asset he wishes to purchase) then he can elect not to go through the authentication procedure. Similarly, if for some reason the seller does not wish to proceed with the settlement then they can elect not to go through the authentication procedure. Also, it is possible that third parties try to approve the settlement, but they will be unable to as they will not be able to achieve positive authentication.

At the end of the time period provided for the authentication procedure to be used, the result of the procedure can be positive authentication (i.e. both parties can have positively identified themselves through the authentication procedure) or not, i.e. non-positive authentication. Non-positive authentication comprises negative or no authentication i.e. one or both parties have failed the authentication procedure or one or both parties have not proceeded with the authentication procedure.

At step 1420, a check is made to determine if the time lock period has expired. The time lock period defines time at which the settlement will complete (or not) depending on whether (or not) the two parties have been positively authenticated using the

authentication procedure. Although not necessarily the case, the time lock period can define the end of the time period provided by step 1418.

The time lock period in the present embodiment is defined within the same smart contract that stores the purchasing tokens and the amount of the asset (at the addresses in the platform associated with the smart contract). A timer for the time lock period is initiated at a relevant stage in the process, for example during step 1412.

At step 1422, a check is made to determine whether or not the authentication of the identities of both of the parties was positive.

If the authentication was positive, the settlement completes and at steps 1424 and 1426 are performed. At step 1424 the amount of the asset for the settlement is released from the first address to the purchaser. In this embodiment, this comprises moving the amount of the asset for the settlement from the first address to the address in the distributed consensus ledger platform associated with the purchaser. This is the same address that was provided in the settlement instruction, though this need not necessarily be the case.

At step 1426 the purchasing tokens for the settlement are released from the second address to the seller. In this embodiment, this comprises moving the purchasing tokens for the settlement from the second address to the address in the distributed consensus ledger platform associated with the seller. This is the same address that was provided in the settlement instruction, though this need not necessarily be the case. If at step 1422 it is determined that the authentication was not positive then an exception procedure (step 1428) is triggered. The exception procedure is handled off-ledger in this embodiment. Reasons for validation not taking place - and the exception procedure therefore being triggered - can include, for example, incorrect trade sums being lodged, cancellation being required and insufficient tokens being available for the purchase. Given the variety of possible causes for the exception procedure, there may be a variety of resultant off-ledger resolutions. In an alternative embodiment, one or more exception procedures are automated on the ledger. An example automated exception procedure involves the rolling back of the purchasing tokens to the address associated with the purchaser and the rolling back the amount of assets to the address associated with the seller. Rules to account for any charges that may need to be paid can also be implemented.

In the described embodiment, the functionality of Figure 14 is provided on the distributed consensus ledger platform using one or more smart contracts.

Another example of a new order request message is a sell order request from DistributorX to FundManagerX to sell £5,000 worth of ISIN1 , the processing of which is similar to that described with reference to Figure 14 except the movement of the amount of the asset is from DistributorX to FundManagerX and the movement of the purchasing tokens is from FundManagerX to DistributorX.

The skilled person would appreciate that more or fewer distributed consensus ledgers may be used. Variations of the described embodiments are envisaged, for example, the features of all the disclosed embodiments may be combined in any way. The methods and systems described herein may be used in any number of settings. For example, house conveyancing is a market in which the methods of the present application may be used. In particular, the postal addresses of properties may be recorded as entries in one or more distributed consensus ledgers and the transfers of properties from one owner to another may be recorded efficiently using the methods disclosed herein.

In the detailed descriptions shown above, a smart contract for calculating the balance associated with entities in the distributed consensus ledger was shown as recorded into the distributed consensus ledger. The skilled person would understand that any suitable smart contract may be recorded, for any specific purpose. The functionality of the

OrderFactory contract may also be provided in some other contract, or included with the Balance contract, and so on. The skilled person would appreciate that a link to a respective address at which entity-specific data, such as the balance associated with that entity, is stored, may be recorded into the entry related to that entity. For example, an entry in the one or more distributed consensus ledgers for a node, asset or relationship may contain a link to another associated address at which information relating to that node, asset or relationship is stored.

The skilled person would appreciate the addresses within the one or more distributed consensus ledgers may be represented in any suitable way. For example, the address may be a hexadecimal address pointing to a particular block. The address may be a block number, pointing to a specific block e.g. the block height.

The method of providing a delivery versus payment mechanism for settlement of transactions on a distributed consensus ledger platform has been described with reference to a particular implementation of the distributed consensus ledger platform. Embodiments of the present invention do not require all of the features of this

implementation, although these features can be used in some embodiments of the invention. These features are summarised below, and may be combined with the features set forth in the accompanying claims.

A computer system for processing instruction records for a network. The transaction network comprises a plurality of nodes. Each transaction record relates to a

corresponding transaction. Each transaction record comprises a first identifier identifying a first node in the network, a second identifier identifying a second node in the network and data relating to the transaction. For example, the instruction may indicate that a node of the network is a bank or financial institution. The computer system has a computer processor and a computer memory. The memory comprises one or more distributed consensus ledgers. The one or more distributed consensus ledgers comprise a plurality of ledger entries, each ledger entry having a respective address in the one or more distributed consensus ledgers. The plurality of ledger entries comprises respective ledger entries for respective nodes of the network and ledger entries for respective relationships between nodes within the network. The one or more distributed consensus ledgers further comprise an address map which maps a node identifier for each node to the respective address of the respective ledger entry for the node and which maps a relationship identifier for each relationship between the nodes to the respective address of the respective ledger entry for the relationship. Accordingly, the nodes of the network and the relationships between the nodes are "baked" into the one or more distributed consensus ledgers. The ledger entries may contain any information specific to their respective nodes or relationships, such as names, account details, passcodes and so on. The ledger entries may further comprise links to other addresses in the one or more distributed consensus ledgers.

The one or more distributed consensus ledgers further comprise at least one smart contract for processing an instruction from an instruction record. The at least one smart contract is operable, using the computer processor, to use the first identifier and second identifier from the transaction record to identify the node identifiers for the instruction. The smart contract is further operable to use the combination of the first identifier and second identifier to identify the relationship identifier for the instruction. The smart contract is further operable to use the address map to look up the respective address for each of the node identifiers and relationship identifier. The smart contract is further operable to process the instruction to obtain processing output for each of the node identifiers and relationship identifier. The smart contract is further operable to store the processing output for each of the node identifiers and relationship identifier at an associated address in the one or more distributed consensus ledgers.

By providing such a computer system, information relating to a network is baked into the one or more distributed consensus ledgers and accordingly, any new instructions may be efficiently processed by referring to the mapped addresses of entities in the one or more ledgers, the entities comprising the nodes or relationships of the network. When processing the new instructions (sometimes known as "rippling"), the stored ledger entries relating to entities can be accessed and used to view entries stored at associated addresses. For example, the one or more distributed consensus ledgers may store information concerning current balances associated with each node or relationship and so this information can be recalled quickly and efficiently. The use of distributed consensus ledgers means that data held locally at each node can be reconciled easily by reference to the one or more distributed consensus ledgers.

The baking of the network into the one or more distributed consensus ledgers leads to a significant speed-up in the time taken to process blocks of new instruction records. In particular, when compared to known distributed ledger technologies, at least a four-fold increase in the speed of throughput of new information/new records can be achieved using the systems and methods disclosed herein. As nodes and relationships are logged on the one or more distributed consensus ledgers before the rippling process begins, the amount of information required to be processed in relation to new instruction records in order to update the one or more distributed consensus ledgers is greatly reduced.

Furthermore, by baking the network into the one or more distributed consensus ledgers, the various nodes and relationships are already represented as addressed entities within the one or more ledgers before any operations are performed with respect to new information / instructions. This provides an added benefit that one can view the current status of any node and/or relationship (such as, for example, a holding for that node or relationship) at any time without the need to create new entries after the initial baking process, thereby reducing the computational complexity associated with data retrieval.

Even in large networks and situations in which instruction records comprising an aggregation of sub records are generated, the disclosed system and methods can efficiently process instruction records in an appropriate and meaningful timeframe.

The data relating to the instruction for at least some of the instruction records may comprise at least one asset identifier which identifies a respective asset to which the instruction relates. The plurality of ledger entries may comprise respective ledger entries for respective assets. The address map may further map an asset identifier for each asset to the respective address of the respective ledger entry for the asset. The smart contract may be further operable to use the address map to look up the respective address for the asset identifier. The smart contract may be further operable to process the instruction to obtain processing output for the asset identifier. The smart contract may be further operable to store the processing output for the asset identifier at an associated address in the one or more distributed consensus ledgers. The plurality of ledger entries may comprise respective ledger entries for respective node- asset relationships, and the address map may further map a node-asset relationship identifier for each node-asset relationship to the respective address of the respective ledger entry for the node-asset relationship. The at least one smart contract may be further operable to use the combination of the first identifier and asset identifier and the combination of the second identifier and the asset identifier to identify the node-asset relationship identifiers for the instruction. The smart contract may be further operable to use the address map to look up the respective address for each node-asset relationship identifier. The smart contract may be further operable to process the instruction to obtain processing output for each of the node-asset relationship identifiers. The smart contract may be further operable to store the processing output for each of the node-asset relationship identifiers at an associated address in the one or more distributed consensus ledgers.

The data relating to the instruction may comprise an amount identifier identifying the amount of the asset to which the instruction relates. The at least one smart contract may be operable to use the amount identifier when performing the instruction processing to obtain the processing output.

An instruction record may relate to a transfer of ownership of an asset from the first node of the network to the second node of the network.

At least one of the instruction records may comprise a transaction record related to a corresponding transaction. At least one of the first node and the second node may be a party to the transaction.

The network may be an order flow network. At least one of the instruction records may be an order request message relating to a corresponding buy order and/or sell order. For example, the order request message may comprise both buy and sell and therefore be a switch order.

At least one transaction record may relate to a monetary transfer from a first party to a second party. Processing the transaction may comprise recording a transfer of a monetary unit from the first party to the second party on a distributed consensus ledger. For example, a digital currency may be used, and processing the transaction may comprise transferring units of a digital currency from the first party to the second party. An instruction record may relate to an income payment. The income payment may be from a pre-existing asset. For example, the instruction record may relate to a dividend payment.

The one or more distributed consensus ledgers may comprise a plurality of distributed consensus ledgers. An advantage of using multiple distributed consensus ledgers is that transactions can be processed even more efficiently and each ledger can reference entries in other ledgers. Known distributed ledger technology is too slow to facilitate the required processing speeds for some markets, such as the funds market. Fast- and slow- throughput distributed consensus ledgers can be used to enable the logging of an instruction such as a transaction at a point in time, followed by data completion to build up the full instructions data within the slow chain. Each of the plurality of distributed consensus ledgers may comprise a dedicated smart contract for a specific function. The specific functions may include one or more of: (i) fast instruction logging; (ii) storing the instruction records; and (iii) processing the instructions.

The computing system may be configured to provide view access to data stored in the one or more distributed consensus ledgers to one or more parties in the network. This may be implemented by, for example, public key cryptography or other security measures, and can enable the various actors in the network to only view data which is pertinent to them.

The at least one smart contract may be operable to determine that a node identifier, relationship identifier, asset identifier or node-asset relationship identifier is not stored in the address map. In response to the determination, the at least one smart contract may be operable to create a respective ledger entry for the node, relationship, asset or node-asset relationship in the one or more distributed consensus ledgers. The at least one smart contract may further be operable to update the address map to include the corresponding mapping between the identifier and the respective address of the created ledger entry.

The at least one smart contract may be operable to validate the node identified by the node identifier not stored in the address map. The at least one smart contract may be operable to, in response to the validation, create the respective ledger entry for the node in the one or more distributed consensus ledgers and update the address map to include the corresponding mapping between the node identifier and the respective address of the created ledger entry. In this way, if a new instruction or transaction is processed and a new potential node of the network is identified, potential node may be approved for being considered part of the network. Accordingly, validation requirements such as security requirements may be used to validate the newly identified node. The at least one smart contract may be operable to perform aggregation of data. For example, through the use of a smart contract, an investors' trade may be aggregated with other trades, and this may be recorded onto the one or more distributed consensus ledgers. This is similarly true for settlements of transactions, which may include net settlement of one or more trades.

The one or more distributed consensus ledgers may further comprise at least one smart contract for processing a node update. The at least one smart contract may be operable, using the computer processor, to receive new information concerning the first node (or the second node). The at least one smart contract may be operable, using the computer processor, to use the address map to look up the respective address for the respective ledger entry for the first identifier (or the second identifier). The at least one smart contract may be operable, using the computer processor, to process the new information concerning the first node (or the second node) to obtain updated node information for the first identifier. The at least one smart contract may be operable, using the computer processor, to store the updated node information for the first identifier (or the second identifier) at an associated address in the one or more distributed consensus ledgers.

The one or more distributed consensus ledgers may further comprise at least one smart contract for processing a monetary transfer from the first node to the second node. The monetary transfer may relate to a respective instruction record - the processing of the monetary transfer may take place after or concurrently to the respective instruction record. The at least one smart contract may be operable, using the computer processor, to use the first identifier and second identifier from the respective instruction record to identify the node identifiers for the monetary transfer. The at least one smart contract may be operable to use the address map to look up the respective address for each of the node identifiers. The at least one smart contract may be operable to process the monetary transfer to record a transfer of a monetary unit from the first node to the second node on a distributed consensus ledger. The at least one smart contract may be operable to store the data relating to the recorded transfer for each of the node identifiers at an associated address in the one or more distributed consensus ledgers. The method may further comprise receiving a new instruction record and processing the new instruction using at least one smart contract on the one or more distributed consensus ledgers. A computer program medium is provided. The computer program medium comprises computer executable instructions which, when executed by a computer, configure the computer for processing instruction records for a network. The network comprises a plurality of nodes. Each instruction record relates to a corresponding instruction. Each instruction record comprises a first identifier identifying a first node in the network, a second identifier identifying a second node in the network and data relating to the instruction. The computer executable instructions comprise instructions to configure one or more distributed consensus ledgers on the computer. The one or more distributed consensus ledgers comprise a plurality of ledger entries. Each ledger entry has a respective address in the one or more distributed consensus ledgers. The plurality of ledger entries comprises respective ledger entries for respective nodes of the network and respective ledger entries for respective relationships between nodes within the network. The one or more distributed consensus ledgers further comprise an address map which maps a node identifier for each node to the respective address of the respective ledger entry for the node and which maps a relationship identifier for each relationship between the nodes to the respective address of the respective ledger entry for the relationship. The one or more distributed consensus ledgers further comprise at least one smart contract for processing an instruction from an instruction record. The at least one smart contract is operable, using the computer processor, to use the first identifier and second identifier from the instruction record to identify the node identifiers for the instruction. The at least one smart contract is further operable to use the combination of the first identifier and second identifier to identify the relationship identifier for the instruction. The at least one smart contract is further operable to use the address map to look up the respective address for each of the node identifiers and relationship identifier. The at least one smart contract is further operable to process the instruction to obtain processing output for each of the node identifiers and relationship identifier. The at least one smart contract is further operable store the processing output for each of the node identifiers and relationship identifier at an associated address in the one or more distributed consensus ledgers.

A computer-implemented method is provided, the computer-implemented method for configuring a computer system as disclosed herein. The method comprises identifying nodes and relationships in a network using a set of instruction records. The nodes are identified from the first identifiers and the second identifiers of the set of instruction records. The relationships between nodes of the network are identified from the first identifier and second identifier of each individual instruction record. The method further comprises configuring the computer system. The method may further comprise identifying one or more assets to which instructions in the network relate by identifying the one or more assets from the asset identifiers of the set of instruction records. The method may further comprise identifying node-asset relationships from the combination of the first identifier and the asset identifier and the combination of the second identifier and asset identifier of each individual message.

A computer program medium is provided. The computer program medium comprises computer executable instructions which, when executed by a computer, perform a method for configuring a computer system as disclosed herein. The systems and methods disclosed herein lead to a number of further advantages. Firstly, through appropriate application programming interfaces (APIs) and with appropriate permissions, the local systems used at the various nodes of a network can access the information recorded in the one or more distributed consensus ledgers.

Accordingly, users of the local systems used at the various nodes of the network may not need to change the ways in which they currently record information locally. The systems disclosed herein are therefore interoperable with the legacy systems currently in place. This negates the need for complex reconciliation processing as users are operating from a single version of the truth. As the users already have access to the data in the one or more distributed consensus ledgers, if they subsequently choose to migrate to directly use the systems and methods disclosed herein, then they can do so smoothly and efficiently.

Further advantageously, the different possible uses for the systems disclosed herein can be carried out using the same set of distributed consensus ledgers. One may therefore process instruction records relating to order request messages, transfers of assets, monetary transfers, income payments and so on using the same distributed consensus ledgers. Accordingly, multiple systems are not required for multiple purposes.

The above embodiments have been described by way of example only, and the described embodiments are to be considered in all respects only as illustrative and not restrictive. It will be appreciated that variations of the described embodiments may be made without departing from the scope of the invention.

Claims

1 . A computer-implemented method for providing a delivery versus payment mechanism for settlement of transactions on a distributed consensus ledger platform, a settlement comprising the exchange of an amount of an asset from a first party for the payment of purchasing tokens from a second party, the computer-implemented method comprising: storing the amount of the asset for the settlement at a first address in the distributed consensus ledger platform associated with a first smart contract;

storing the purchasing tokens for the settlement at a second address in the distributed consensus ledger platform associated with a second smart contract;

providing an authentication period for the identities of the first party and second party to be authenticated using an authentication procedure; and

when a time lock period expires, if the identities of the first party and second party have been positively authenticated by the authentication procedure during the

authentication period, releasing from the first address the amount of the asset to the second party and from the second address the purchasing tokens to the first party.

2. A computer-implemented method according to claim 1 , wherein the distributed consensus ledger platform comprises one or more distributed consensus ledgers comprising ledger entries, each ledger entry having a respective address in the one or more distributed consensus ledgers, the ledger entries comprising respective addresses representing respective current amounts of assets of respective first parties and respective addresses storing respective current balances of purchasing tokens of respective second parties, the method comprising:

moving the amount of the asset for the settlement from an address in the distributed consensus ledger platform associated with the first party to the first address; and

moving the purchasing tokens for the settlement from an address in the distributed consensus ledger platform associated with the second party to the second address.

3. A computer-implemented method according to claim 1 or claim 2, the method comprising:

initiating the delivery versus payment mechanism on the distributed consensus ledger platform in response to receiving an order instruction that specifies the amount of the asset and a corresponding amount of purchasing tokens for the transaction.

4. A computer-implemented method according to claim 3 when dependent on claim 2, the method comprising:

creating a settlement instruction from the order instruction, wherein the settlement instruction specifies the amount of the asset and a corresponding amount of purchasing tokens for settlement of the transaction, the address in the distributed consensus ledger platform associated with the first party and the address in the distributed consensus ledger platform associated with the second party; and

initiating from the settlement instruction the moving of the amount of the asset and the purchasing tokens for the settlement.

5. A computer-implemented method according to any previous claim, wherein releasing from the first address the amount of the asset for the settlement to the second party comprises moving the amount of the asset for the settlement from the first address to an address in the distributed consensus ledger platform associated with the second party, and wherein releasing from the second address the purchasing tokens for the settlement to the first party comprises moving the purchasing tokens for the settlement from the second address to an address in the distributed consensus ledger platform associated with the first party.

6. A computer-implemented method according to any previous claim, the method comprising:

when the time lock period expires, if the identities of both the first party and the second party have not been positively authenticated by the authentication procedure during the authentication period, initiating an exception process.

7. A computer-implemented method according to any previous claim, wherein the time lock period is a generic time for a set of settlements of transactions.

8. A computer-implemented method according to any of claims 1-6, wherein the time lock period is specific to the settlement.

9. A computer-implemented method according to any preceding claim wherein the first address and the second address are different addresses.

10. A computer-implemented method according to any previous claim, wherein the authentication procedure comprises the first party and the second party using digital signatures.

1 1. A computer-implemented method according to any preceding claim, wherein the settlement relates to a buy order and/or sell order.

12. A computer-implemented method according to any preceding claim, wherein the asset comprises one or more of:

funds;

bonds;

shares;

property;

goods; and

provision(s) of services.

13. A computer system configured to perform the computer-implemented method according to any preceding claim.

14. A computer program comprising computer readable instructions to cause one or more computer systems to perform the computer-implemented method of any of claims 1 to 12.

15. A computer network configured to perform the computer-implemented method of any of claims 1 to 12.