Technical Field The present application relates to systems and methods for processing instruction records for a network. In particular, the present application relates to the use of one or more distributed consensus ledgers to process information.

Background

In the world there are many ordered and unordered networks. For example, when purchasing a house there is a network comprising buyers, sellers, solicitors, estate agents, searching authorities and so on. As estate agents and solicitors act for multiple clients the network is large. Each party in the network can be considered as a node on the network. In the world of finance, the nodes can include individuals, independent financial advisors (IF As) and fund managers for example. In these and a whole host of other examples the networks may comprise intermediaries (for example estate agents, IF As) acting for many clients. The intermediaries themselves can be linked to other intermediaries. The intermediaries themselves may link to multiple other intermediaries. These ordered and unordered networks can be vast and complex.

For a given instruction in a network, e.g. an instruction from one node to another or an instruction from one node updating the status of an event relating to another node, each node concerned will typically keep their own computer record. However, there is typically no central record. Keeping local records involves data redundancy, and can involve errors at the local level and therefore inconsistencies between data held by different nodes. Furthermore, errors can propagate to the computer records of other nodes in the network.

One example of a network is a transaction network. A transaction network may be thought of as a collection of nodes and relationships between pairs of nodes, the relationships defined by the transactions and instructions carried out. For example, a transaction may comprise a transfer of an asset, such as knowledge of a client's stock holding, from one intermediate unit holder institution to another. A transaction may comprise, for example, purchase and sale of an asset flowing between nodes of a network comprised of an unlimited number of actors. An example of an instruction flow network is the global funds market. For example, over the 10-15 years, there has been a growth in UK platforms and a decline of direct sales from Fund Managers (who create and liquidate units/shares of a fund on a main register) to the investor. The main register is the ultimate shareholder record.

Funds are open ended instruments, meaning that they operate through a primary market - the only source for buying and selling funds is the main register. In essence this means that whilst there are multiple options to access the market, all trading must flow back to the main register for the transaction to take place. Fund subscriptions (buy) or redemptions (sale) must be registered through the main register in order to create the correct number of units in issue for the fund. Between the ultimate investor and the main register sits a number of platforms enabling investors to access the funds and hold their investments under efficient product wrappers across multiple fund managers. The consequence of this is that there are sets of shareholder records at each and every step in the intermediate unitholder chain. These records need to be administered and reconciled against the records on either side of the value chain.

In other words, the transaction and instructions between parties create a network representing the UK funds market comprising a number of nodes corresponding to investors or institutions, and relationships between the nodes defined by the direction of the flow of orders through the order flow network.

Figure 1 shows a representation of a typical transaction or instruction path / distribution chain for the UK funds market. In practice, an investor 110 may or may not use an independent financial advisor (IF A) 112 who stores a local client record/register for the investor 110 and other investors (not shown). If the investor 110 wants to buy into a fund, the IFA 112 makes a record of this locally. The IFA 112 may then use an intermediate unit holder (IUH) 114 (or go directly to the main register) to perform various functions, particularly market access across multiple fund managers and some administration functions. The IUH 114 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 116 for market access (which themselves are a further IUH). Once aggregated, the fund manager 120 is typically unaware of the investor 110 and is instead aware of the nominee position of which the investment for investor 110 is part of. The fund manager 120 may outsource the daily management of the shareholder record to a transfer agency 118 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, IF As, IUHs, 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.

The funds industry is typical of many other industries, where there are client records at multiple layers with data being re -keyed continually and reconciliation of each record being complex and irregular. Furthermore, multiple records results in a lot of data redundancy. There is a need for new and improved computer systems and methods to efficiently process instructions for a transaction network and for reconciling transaction records.

Summary The inventors have recognised that instruction records self-describe the nodes of the network and the relationships between the nodes. The inventors have further recognised that the records further self- describe the relationships between the nodes of the network and the resources or assets to which the instructions relate. Accordingly, the inventors have developed an improved method and computer system for processing new instructions based on efficiently handling previous instructions to describe the underlying network. The methods and computer systems described herein have many advantages as will become apparent. Furthermore, the inventors are able to create a network which enables entries relating to additional nodes to be created as and when those additional nodes are discovered. This facilitates a migration path from the status quo. A computer system is provided 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 preexisting 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 blockchain 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.

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.

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 11 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.

Throughout the description and the drawings, like reference numerals refer to like parts. Detailed Description The present invention seeks to provide an improved computer system and method for processing transaction records for a transaction network. Whilst various embodiments of the invention are described below, the invention is not limited to these embodiments, and variations of these embodiments may be made without departing from the scope of the invention. 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 315, 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.

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 order. 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 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 ISINl from FundManagerX. At 512 it is shown that DistributorX orders £1 ,000 worth of ISINl 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.

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/ISINl" is selected. The key value pair "DistributorX/ISINl" 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/ISINl" is selected. The key value pair "FundManagerX/ISINl" 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/ISINl" and "FundManagerX/ISINl" 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 "ISIN1" 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 "Distrbutorl/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 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 1112, 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 1114, 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 1120. If one or more of the nodes, assets or relationships are not accounted for in the address map then the process continues to step 1116.

At step 1116, 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 1118. The mapping of the identifier from the new order request message to the respective address using the "set" functionality described above. At step 1120, the amount information is read from the new order request message. For the current example, the amount is "12,000".

At step 1122, 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/ISINl" and "FundManagerX/ISINl" (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 1124 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 1126, 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 110 decides to move to a different IFA 112, 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 IFA (first order giver, "FOG" ,1210) to another IFA (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 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 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.