WO2015049515A1

WO2015049515A1 - Improvements relating to distributed resource management in real-time systems

Info

Publication number: WO2015049515A1
Application number: PCT/GB2014/052969
Authority: WO
Inventors: Peter Mcintyre; Gary MANNING
Original assignee: Planixs Grp Limited
Priority date: 2013-10-01
Filing date: 2014-10-01
Publication date: 2015-04-09
Also published as: GB201317414D0

Abstract

A system (100) for the allocation and monitoring of resources is described. The system comprises a primary entity (102),a secondary entity (112)and a network (108) for transmitting transaction messages between the primary entity (102) and the secondary entity (112).The secondary entity (112) has a local resource store associated with the primary entity (102), said resource store holding an initial value of resource. The primary entity comprises a resource analysis system (202). The resource analysis system (202) parses transaction messages to identify those that include transaction instructions for transferring resources to or from the resource store. The resource analysis system (202) processes those identified transaction messages to calculate how the value of the resource held by the resource store has changed, and is arranged to display an updated value of resource to a user.

Description

IMPROVEMENTS RELATING TO DISTRIBUTED RESOURCE MANAGEMENT IN

REAL-TIME SYSTEMS

Technical field

The present invention relates to distributed resource management in real-time systems. More particularly, though not exclusively, the present invention relates to providing a real-time view of one of many aggregated states of distributed resources within a realtime system such that use of the resources can be optimised.

Background to the invention

An entity may manage resources which may be exchanged with, transferred or temporarily allocated to other entities in transactions. Resources may include electrical energy, fuel, water, financial assets, computer memory or food. Each transaction typically comprises actions occurring between the entities. For example, in an exchange, resources may be sent from a primary entity to a secondary entity and subsequently, other specified resources may be sent from the secondary entity to the primary entity or other entities. Thus, each resource transaction typically comprises multiple parts.

Figure 1 shows an example prior art environment 100 in which resources are transacted. The environment 100 comprises a primary entity 102 arranged to manage resources. The primary entity comprises a plurality of resource databases 104 and a transaction message gateway 106.

The transaction message gateway 106 is arranged to send and receive transaction messages from a network 108. The network 108 may be, for example, the Internet, a wide area network, a local area network, or a proprietary closed network linking many entities such as SWIFTNet. To carry out resource transactions (exchanges, transfers or temporary allocations of resources) within the environment 100, transaction messages are sent via the network 108. The transaction messages may be in a standardised format and comprise information such as the quantity, type and value of the resource being transacted. The transaction messages may also contain a transaction time (and date). The transaction time may be later than the time that the message is transmitted and/or received, in which case, the transaction time is an indication when in the future a particular transaction should take place. The environment 100 further comprises four customer entities 110a, 110b, 110c, 1 10d that are each connected to the network 108. Each of the customer entities comprises a transaction message gateway, however, these are not shown in Figure 1 for illustrative simplicity, however, typically there are thousands of secondary entities. Each of the customer entities 110a, 1 10b, 1 10c, 110d comprises one or more resource databases 1 12a, 112b, 1 12c, 112d. The customer entities are typically in distinct physical locations.

The resources transacted in the environment 100 each comprise a value and are associated with a plurality of quality parameters that affect the value. Details of the resources, including quantity of the resource held by the entity, the value of the resource and the quality parameters associated with the resource, are stored in resource databases 104, 1 12a, 112b, 1 12c, 1 12d. Typically, millions of transactions of resources occur during a specific time period, typically a portion of a day, and the quality parameters change as a result of external events or the transactions themselves, therefore affecting the value of the resources (including those not being transacted) thousands to millions of times during the specific time period. For each transaction, the resource databases 104, 112a, 1 12b, 112c, 112d are updated to reflect the exchange or temporary allocation of the resources.

The transaction messages that are used to instruct transactions of resources are sent and received via the gateways of the entity that comprises the resource being transacted. The transaction messages are processed at each entity to update that entity's resource databases.

If resources are transacted from the primary entity 102 to a secondary entity (e.g. Customer C 110c), there may be a risk to the primary entity 102 that the secondary entity Customer C 110c does not complete its part of the transaction. For example, it does not take the actions necessary to finalise the transaction. The primary entity 102 can monitor this risk by maintaining awareness of the total value of the resources that have been temporarily allocated to the secondary entity, Customer C 1 10c, and managing the allocation of resources appropriately. The primary entity 102 may define a maximum total value of its resources that can be transacted to the secondary entity without the secondary entity completing its part of the transaction. Once the maximum total value has been reached, no more resources will be transacted from the primary entity 102 to Customer C 1 10c.

Conversely, if resources are transacted from the secondary entity (e.g. Customer A 1 10a) to the primary entity 102, there may be a risk to Customer A 110a that the primary entity 102 does not complete its part of the transaction. Therefore, there is a requirement on the primary entity 102 to maintain awareness of the total value of the resources that have been transacted from Customer A 110a. The primary entity 102 can then collate a set of counter-balance resources in the primary entity's resource databases 104 having a value which is large enough to reduce the risk to Customer A 110a of non-completion of the transaction, and ensure that the primary entity 102 can cover the potential loss of the transacted resources. Should the transaction fail to be completed by the primary entity 102, the set of counter-balance resources can be provided to Customer A 1 10a to mitigate against the non-completion of transactions by the primary entity 102. The set of counter-balance resources form a resource buffer.

Generally, in the prior art environment 100, each entity 102, 110a, 1 10b, 110c, 110d determines the total quantity and the total value of the resources in its corresponding resource database 104, 1 12a, 1 12b, 112c, 112d once between the start of one time period and the next time period. Generally, the time during the specific time period at which the total value of the resources are determined is when transactions using each resource database are not occurring, typically after the period during which transactions using each database has ended. This minimises the demand on the resource databases 104, 1 12a, 1 12b, 112c, 1 12d and prevents any interference with the transactions of resources. The total value in each resource database determined once during the specific time period is also used by the primary entity 102 to maintain awareness of the total value of the resources that have been temporarily allocated to and from the secondary customer entities 110a, 1 10b, 110c, 110d. The millions of transactions of resources each vary the total value of the resources in the resource databases 104, 112a, 1 12b, 1 12c, 1 12d during the specific time period. These variations cannot practically be determined by the primary entity 102 because the millions of transactions each access and modify the resource databases 104, 1 12a, 1 12b, 112c, 1 12d; therefore attempting to determine the quality parameters or the total value of the resources from the resource databases in real-time whilst transactions are occurring could be detrimental to the performance of the transactions. Further, the resource databases 104, 1 12a, 1 12b, 1 12c, 1 12d are not typically designed to enable real-time access to allow monitoring the total value of the resources. Rather, at best, a system may permit ad-hoc access. Additionally, as the customer resource databases 1 12a, 1 12b, 1 12c, 1 12d may be distributed across different locations, it may not be straightforward to consolidate the value of the resources to determine the total value of resources.

Another issue is that each entity 102, 1 10a, 1 10b, 1 10c, 110d only has control over its own systems and databases. It would, in almost all cases, not be possible to send enquiry commands to other entities' systems seeking to query and determine a current state of resources of the other entity. Even if this was allowed, the speed at which such requests would be processed would not be in the querying entity's control, thereby leading to a variation in results and times at which the values were taken. Another problem is that the millions of transactions may cause, at a specific point in time, the total value of the resources in the resource databases to exceed the resource buffer or the maximum limit of resources that are transacted to the secondary entities 1 10a, 1 10b, 1 10c, 1 10d from the primary entity 104. However, when the total value of the resources in each resource database is determined periodically, the total value of the resources in each resource database may have returned to an acceptable level, thereby causing the event to go unnoticed and no action to be taken. However, the fact that this risky situation can arise undermines the security provided by the resource buffer.

One way of mitigating part of this problem is for the primary entity 102 to estimate the resource buffer to be significantly larger than the actual variation of the value of the resources that may be transacted during the specific time period. This reduces the risk to the secondary entity 110a, 1 10b, 110c, 1 10d of non-completion of transactions. However, for the primary entity 102, it results in a loss in the potential use of the resources that are tied up in the resource buffer and thus a restriction on the number of resources available for other transactions.

An object of the present invention is to address at least one of the problems described above. More specifically, it is desired to provide a faster way of determining the quality parameters and the total value of the resources even when resources are being transacted. For example, it may be desirable for the quality parameters to be determined a plurality of times during the specific time period, or in real-time (i.e. immediately after each transition is carried out) but without slowing down performance of the system. By determining the quality parameters and the total value of the resources in real-time, the uncertainty in the variation of the value of the resources is reduced, namely the resources do not have as much time to fluctuate in value. One advantage this would enable is that the resource buffer can be optimised, freeing-up resources which are not required in the set of counter-balance resources.

Summary of the Invention According to a first aspect of the present invention, there is provided a system for the allocation and/or monitoring of resources. Ideally, the system for the allocation and/or monitoring of resources comprises at least one of a primary entity and a secondary entity. Preferably, the primary entity and/or secondary entity, each comprising at least one of:

· a plurality of local resource stores, ideally local to and controlled by the respective entity;

• a resource management system for allocating resources between said plurality of local resource stores;

• a resource database for logging how resources have been allocated between said plurality of local resource stores; and

• a gateway for handling transaction messages originating from and/or targeted to the respective entity, the transaction messages providing instructions how resources are to be allocated between the said local resource stores.

Ideally, the system for the allocation and/or monitoring of resources comprises a network for securely transmitting transaction messages between entities such as the primary entity and the secondary entity. Ideally, the secondary entity has a local resource store associated with the primary entity, said resource store holding an initial value of resource. Ideally, the primary entity further comprises a resource analysis system.

Ideally, the resource analysis system: · has a transaction message database;

• is interfaced with the gateway of the primary entity. Ideally, this is so as to copy to the transaction message database transaction messages that are handled by the gateway of the primary entity; • is arranged to parse messages, which are ideally copied to the transaction message database, to identify those that are targeted to the secondary entity and that include transaction instructions for transferring resources to or from the resource store associated with the primary entity that is local to the secondary entity;

· is arranged to process those identified transaction messages to calculate how the initial value of resource has changed to an updated value of resource that is held by the resource store associated with the primary entity that is local to the secondary entity; and/or

• is arranged to display the updated value of resource to a user.

Ideally, the resource analysis system is arranged to prepare a request for transmission to the secondary entity to reallocate resources between the resource store associated with the primary entity and another resource store.

Ideally, the secondary entity is arranged to transmit to the primary entity a confirmation message that includes the correct value of resource held by the resource store associated with the primary entity that is local to the secondary entity. Ideally, the secondary entity is arranged to transmit the confirmation message at the end of an exchange period. Ideally the secondary entity is arranged to transmit the confirmation message to the primary entity prior to the start of a subsequent exchange period. The confirmation message may be used by the primary entity to set the initial value of resource that is held by the resource store associated with the primary entity that is local to the secondary entity. Ideally, said initial value is that set for the start of the subsequent exchange period.

Ideally, the resource analysis system is arranged to parse the messages copied to the transaction message database to identify those that include a transaction timestamp. Ideally, the transaction timestamp specifies when said transaction instructions contained within the message are to be carried out.

Ideally, the resource analysis system is arranged to assign a delivery timestamp to the messages copied to the transaction message database. Ideally, the assigned delivery timestamp is associated with the time at which a respective message is handled by the gateway. Ideally, the resource analysis system is arranged to order messages for processing chronologically, in dependence on the transaction timestamp and/or delivery timestamp contained within and/or assigned to said messages. Ideally, the resource analysis system is arranged to discard messages having a transaction timestamp or a delivery timestamp in a previously occurring exchange period.

Ideally, the resource analysis system is arranged to generate and/or display a forecasted value of resource that is held by the resource store associated with the primary entity, Ideally, this forecast is generated and/or displayed in response to parsing messages including a transaction timestamp specifying transaction instructions to be carried out in the future.

Ideally, the resource analysis system is arranged to generate and/or display a forecasted value of resource that is held by the resource store associated with the primary entity in response to a draft transaction message. The draft transaction message may be queued for future delivery to the second entity. Ideally, the draft message includes transaction instructions for transferring resources to or from the resource store associated with the primary entity that is local to the secondary entity.

Ideally, the primary and secondary entities are located at geographically distinct locations from one another. For example, the primary and secondary entities may be are located in different timezones. Accordingly, the resource analysis system may be arranged to register the differences in timezones and in response harmonise transaction and/or delivery timestamps of messages sent between the primary and secondary entities.

Transaction messages may comprise at least one of:

• an identification of the stores between which a transaction is to be carried out; and

• a quantity, value and/or type of resource to be transferred and/or when it is to be transferred.

Ideally, the resource analysis system further comprises an error handler arranged to determine messages that cannot be parsed successfully. Ideally, the error handling is arranged to report messages that cannot be parsed successfully to an administrative user.

The resource analysis system ideally comprises a quality parameter generator for generating one or more quality parameter for modifying the calculation of how the initial value of resource has changed to an updated value of resource that is held by the resource store associated with the primary entity that is local to the secondary entity.

Ideally, the quality parameter generator imports reference data that reflects how external factors are likely to modify the calculation of the change in value of the resource in the resource store associated with the primary entity.

It will be appreciated that the various features of the system for the allocation and/or monitoring of resources may be combined and/or substituted where context allows. For example, features of the primary entity may be present in addition to, or instead of features of the secondary entity, and visa-versa.

Furthermore, the various features of the system for the allocation and/or monitoring of resources may themselves constitute further aspects of the present invention. For example, according to a second aspect of the present invention there is provided a resource analysis system. Ideally, the resource analysis system is for use with the system according to the first aspect of the present invention.

It will further be appreciated that the actions and functions performable by the features of the systems according to the first and/or second aspects of the present invention may themselves constitute further aspects of the present invention.

For example, according to the third aspect of the present there is provided a method of monitoring a value of a resource. Ideally, this is similar to the function performed by the resource analysis system according to the first and/or second aspect of the invention. Ideally, the method comprises monitoring how an initial value of a resource held by a remote resource store has changed to an updated value. The remote resource store may be equivalent to the resource store of the secondary entity that is associated with the primary entity of the system for the allocation and/or monitoring of resources according to the first aspect of the present invention. Thus, the method may comprise the steps that can be taken by the resource analysis system of the first and/or second aspects of the present invention. For example, the method may comprise at least one the steps of:

o copying transaction messages to a transaction message database;

o parsing the copied transaction messages to identify those that include

transaction instructions for transferring resources to or from said remote resource store;

o processing those identified transaction messages to calculate how the initial value of resource has changed to an updated value of resource;

o displaying the updated value to a user;

o displaying guidance to a user about an optimal value to be held within the remote resource store; and/or

o automatically issuing an instruction to adjust the value of the resource held by the remote resource store.

It will be appreciated that the various features and advantages of the various aspects of the present invention may be combined and/or substituted where context allows.

Brief Description of the Drawings

In order that the invention may be more readily understood, embodiments of the invention will now be described in more detail, by way of example only, and with reference to the following figures in which:

Figure 1 is a schematic block diagram of an example prior art environment;

Figure 2 is a schematic block diagram of an environment according to an embodiment of the present invention;

Figure 3 is a schematic block diagram of the resource analysis system of Figure 2;

Figure 4 is a flowchart of a process according to an embodiment of the present invention;

Figure 5 is a schematic block diagram of an environment according to an embodiment of the present invention; Figure 6 is a schematic block diagram of the Realiti® system and the bank of Figure 5; and

Figure 7 is a schematic block diagram of components of the Realiti® system of Figure 5.

Detailed Description of the Preferred Embodiments

The present invention can be realised in many different ways and is applicable to different types of resource (e.g. electrical energy, fuel, water, financial assets, computer memory or food).

Figure 2 shows an example environment 200 according to an embodiment of the present invention. The environment 200 is substantially the same as the prior art system 100. Additionally, the environment 200 comprises a resource analysis system 202 connected to the transaction message gateway 106 of the primary entity 102.

Figure 3 shows the resource analysis system 202 in greater detail. The resource analysis system 202 comprises a processor 220, a quality parameter generator 222, an analysis module 224 and a transaction message database 226. The quality parameter generator 222, the analysis module 224 and the transaction message database 226 are each connected to the processor 220.

The transaction message gateway 106 in this embodiment is arranged to send copies of transaction messages that is sent from and is received by the primary entity 102.

The transaction message database 226 stores copies of transaction messages sent via the transaction message gateway 106. Instructions in the transaction messages (i.e. that instruct exchanges, transfers or temporarily allocations of resources between entities) are used by the quality parameter generator 222 to determine values of quality parameters, total quantity and the total value of the resources being transacted in realtime.

A benefit of using copies of standardised transaction messages directly from the transaction message gateway 106 is that the resource analysis system 202 can be non- invasively added (i.e. retro-fit) to the primary entity 102. In addition, the operation of the primary entity 102 is not appreciably slowed down by introduction of the resource analysis system 202. In other embodiments, the resource analysis system 202 may be connected to, and receive transaction messages directly from the network 108.

The analysis module 224 is configured to allocate the resources that are in a resource buffer (not shown), based on the quality parameters determined by the quality parameter generator 220 in real-time and predetermined threshold values. In other embodiments the analysis module 224 is arranged to provide information to a user to guide the user on an efficient resource buffer allocation. The analysis module 224 is also arranged with a graphical user interface which acts as a 'front end' for a user.

As millions of transactions typically occur during the specific time period (e.g. intra-day), access to the plurality of resource databases 104, 1 12a, 1 12b, 1 12c, 1 12d may be limited. Further, the resource databases are not typically designed to handle the ad-hoc query access that would be required by the resource analysis system 202. This means that determining the quality parameters, the total quantity and the total value of the resources in the resource databases may not be able to be done directly from the plurality of resource databases external to, or at least removed from the resource analysis system 202. Therefore, in the present embodiment, the quality parameter generator 222 is provided to address this issue. The quality parameter generator 222 uses the copies of the transaction messages stored in the transaction message database to determine values of quality parameters, total quantity and the total value of the resources. In addition, the quality parameter generator 222 may have access to data feeds which provide at least an approximation of the external factors that may also affect the values of the quality parameters.

The results from the quality parameter generator 222 are arranged for display and interpretation to a user by the analysis module 224. For example, the analysis module can show the user the variation in the total value of the resources throughout the specific time period. To this end, the analysis module 224 may comprise an electronic display apparatus on which the result may be displayed graphically.

Figure 4 shows an example process 250 that the resource analysis system 202 carries out. The process starts with the processor 220 obtaining at Step 252 a message at the start of the specific time period. The message comprises the total quantity and the total value of the resources that were determined at the end of the previous time period. Naturally, if many different types of resources are available, the message may also specify the type of resource. As described with reference to the prior art environment 100, each entity 102, 110a, 110b, 110c, 1 1 Od determines the total quantity and the total value of the resources in its corresponding resource database 104, 1 12a, 1 12b, 112c, 1 12d once between the start of one time period, and the start of the next consecutive time period. Generally, the time at which the total value of the resources are determined is when transactions using each resource database are not occurring, typically after the period during which transactions using each database has ended.

The quality parameter generator 222 determines at Step 254 the quality parameters of the resources using the start of time period resource details obtained in Step 252.

The resource analysis system 202 then receives at Step 256 copies of transaction messages from the transaction message gateway 106. The received transaction messages are stored in the transaction message database 226. The quality parameter generator 222 then validates and inspects at Step 258 the received transaction message to determine the change in quantity and value of resources.

The quality parameter generator 222 then determines at Step 260 new quality parameters based on the start of time period values and the change in quantity and value of resources.

If the specific time period has not ended, then the process 250 loops back to Step 256. If the end of the specific time period is reached, the process 250 ends. Accordingly, using the resource analysis system 202, the primary entity 102 can determine an aggregated view of its distributed resources over time and use this information to optimise the usage of its resources.

One key advantage of the present invention is that it permits 'retro-fitting', namely no modification of existing systems is required in order to determine the real-time value of aggregated resources. The present invention is simply added to existing arrangements.

An embodiment will be described, by way of example only, with reference to energy supply, wherein the primary entity 102 is an energy utility and the customer entities 110a, 1 10b, 110c, 1 10d are each energy consumers. The resources are gas and electricity, the resource buffer is electrical generation capacity and gas volume. The quality parameters of the resources include the calorific content of the gas and the time required to bring electrical generation online.

Each energy consumer comprises a smart meter that records (into its own local database 1 12a, 112b, 112c, 112d) the gas and electricity that are received from the energy utility 102 and used by the energy consumer 110a, 1 10b, 110c, 110d. Each smart meter periodically communicates the resource usage information from the databases 1 12a, 112b, 112c, 1 12d to the energy utility 102 across the network 108 via standardised transaction messages. Usage summary transaction messages are also communicated to the energy utility 102 at the start of the specific time period. In this example, the time period may be three months. Communication is limited to being periodic to reduce the cost of that communication.

The energy utility 102 comprises resource databases 104 that contain information regarding its resources, such as the volume and calorific value of gas it has available, its installed electrical generation capacity, and its capacity to import gas and electricity from other energy utilities. The energy utility 102 supplies the energy consumers 1 10a, 1 10b, 1 10c, 1 10d with gas and electricity which have value. The energy utility 102 uses the resource usage information received from the customer entities 110a, 1 10b, 1 10c, 1 10d to charge each energy consumer for the value of the resources used within the specific time period.

The energy utility 102 may impose a maximum total value of gas and electricity that is supplied to each energy consumer in order to reduce its risk that the energy consumer fails to pay for the resources used. Further, the energy utility 102 is required to ensure that it comprises sufficient excess energy electrical generation capacity and gas volume in case of a period of high demand from the energy consumers. For example, if there is insufficient electrical generation capacity to meet demand, this could lead to power outages for the energy consumers (i.e. blackouts and brownouts).

The energy utility 102 comprises a resource analysis system 202 that copies the resource usage information messages into a message database 226. The resource usage information messages in the message database 226 are validated and analysed by a quality parameter generator 222 to determine the quality parameters and total values of the resources used by the energy consumers 1 10a, 1 10b, 110c, 1 10d. The resource analysis system 202 enables the energy utility 102 to maintain awareness of the total value of the resources that have been used by the energy consumers in realtime and allows the energy utility to optimise the use of its resources. For example, by requiring a smaller gas resource buffer, fewer gas storage facilities would be required.

In another example embodiment, the primary entity 102 is an energy supply company in France and a customer entity is an energy supply company in the UK. The present invention can be used to enable resource transactions between these companies to be monitored in real-time using the messages which are communicated between computers of the two entities. Energy resources can be temporarily assigned between the entities to accurately manage differences in peak demand in each country.

Figure 5 shows an example environment 300 according to an embodiment of the present invention. In the environment 300, the primary entity 102 is a bank 302, the resource analysis system 202 is referred to as Realiti® system 304, the transaction message gateway 106 is the SWIFT (Society for Worldwide Interbank Financial Telecommunication) gateway 306 of the bank 302, the network 108 is a SWIFT network 308 and the customer entities 110a, 1 10b, 110c, 1 10d are correspondent banks 310. In this embodiment, the resources are financial assets, the resource buffer is a liquidity buffer, the transaction messages are SWIFT messages, and the quality parameters include cash positions, funding requirements and intraday liquidity usage in every currency.

The Realiti® system 304 comprises the processor 220, the quality parameter generator 222, the analysis module 224 and the transaction message database 226. A user can access the Realiti® system 304 via a graphical user interface, for example though a web browser, generated at computer terminal 312 by the analysis module 224.

As SWIFT messages pass through the SWIFT gateway 306, a copy of relevant message types is forwarded to the Realiti® system 304. The message stream copy is then loaded and transformed into the Realiti® system 304 through a series of technology components. Data aggregations and computations are performed in real-time by the quality parameter generator 222 to enable the resource data to be viewed and analysed by the end user. As with most industries internal Information Technology (IT) systems, in the banking industry, solutions and integrations have grown both organically and inorganically over time resulting in an overly complex IT and technology landscape which is difficult, slow and expensive to change and support. This leads to an inherently complex data hairball which is fragmented across the business. This complexity multiplies as data volumes increase and requirements / needs become more demanding (for example, increased levels of detail, increased dimensionality, real time data and flexible schemas). The banking industry has one of the most complicated IT environments and an increasing need for more real-time management information and business analysis. The trend of increased IT complexity and cost is set to continue.

When new requirements for information are generated within the bank 302, whether internal or regulatory, the bank 302 will seek the data it needs from its internal set of IT systems and buy or build solutions that meet the requirements. The data therefore comes from this 'hairball' of banking systems and as such is very complicated and costly to source, cleanse and ensure accuracy.

At the heart of the Realiti® system 304 is the way this data complexity issue is solved and to develop solutions that deliver significant value to the bank 302 in terms of bottom line cost savings. Realiti® system 304 makes use of pre-existing external financial messaging services (e.g. SWIFT) that contain the source of data truth to capture, analyse and optimise data in real time to deliver banking insight and capabilities. To date, the SWIFT messaging services have been used as a source of data input to the IT systems of the bank 302 but not as a method as described in the present embodiment to deliver direct, unobtrusive functionality to the banking industry.

The Realiti® system 304 delivers a set of solutions to the banking industry globally that solve complicated high value business issues that cannot be readily solved by conventional methods.

The Realiti® system 304 delivers real-time, intra-day data liquidity analysis enabling the bank 302 to lower its actual liquidity buffer, saving significant financing costs and freeing- up more resources. In addition, wide adoption of the Realiti® system 304 in the banking industry would aid greater stability of the overall banking industry since banks would have a much clearer insight into their real-time cash positions and be able to improve management of their operations and resource usage. Additionally, as banks utilise more appropriate liquidity buffers, they would be able to better cope with stress scenarios.

Banks typically find it impossible to consolidate cash flow data in real-time to provide a timely and accurate view of their actual global cash positions, funding requirements and intraday liquidity usage in every currency. The challenge becomes more complex for Banks that operate through many legal entities which use extensive networks of correspondent banks to settle business across the main currencies. A number of issues arise:

1. Intraday Liquidity Buffer

This buffer is designed to cover a bank's group-wide intraday liquidity usage. For example, a top 20 global bank could have a resource buffer of $20bn, but lack the insight as to how to reduce the buffer requirement. Therefore, significant financing costs could be involved - a $20bn buffer could cost greater than $200m annually even at today's very low interest rates.

2. Intraday Overdraft Charges

Correspondent banks are increasingly seeking to charge interest on intraday balances. Therefore, banks with little to no insight are unable to optimise their intraday balances, and hence will see costs rise significantly.

3. Exposure

Banks require a group-wide view of their real-time exposure to correspondent banks, which varies intraday across all its relevant nostro accounts held at the correspondent banks. Therefore, exposure to correspondent banks could significantly exceed approved limits.

4. Credit Line Efficiency

Lack of insight into intraday balances prevents banks operating within credit limits. Therefore, banks are unable to make payments while nostros at maximum credit limit.

5. Clearing Bank Specifics

Clearing banks wishing to charge intraday interest will need insight to charge appropriately, to provide transparency over charges and to identify clients causing intraday exposure issues. Currently, clearing banks have to apply estimates to determine interest rates and so they cannot maximise their revenue opportunities with clients and may also lose market share.

The bank 302 may have hundreds of correspondent bank 310 relationships, with potentially thousands of nostras operating independently but that together to form a complex set of intraday balances. The bank 302 cannot rely on a particular correspondent bank 310 to provide transparency over its relationship, as that would only provide a partial view of the bank's intraday positions. Typically the operational IT architecture of the bank 302 has developed over time and is now extremely complicated with systems from a range of vendors, with limited integration as described above. No existing system is likely to be able to provide a broad intraday view, as it would only have a partial view of the bank's global activities. Creating an in- house tool to extract consolidated management information from the bank's existing systems without the present invention would be a very complex task. Such a tool would have to cope with vast data volumes, deliver analytics in real time, be available to multiple users in multiple locations, and be able to cope with underlying system changes as the bank's IT architecture evolves. In summary, the intraday challenge is currently generating significant costs (>$100m) for banks and contributes to major risk issues for individual banks and the broader financial system. Banks that address the challenge early will generate huge competitive advantage, but approaches that rely on in-house solutions or as extensions of third-party systems are unlikely to be successful.

The Realiti® system 304 is based on the SWIFT messaging architecture and uses the lowest level of information provided in SWIFT messages to build up a picture of every nostra balance in the correspondent banks 310 every minute of every day in real-time. SWIFT is a banking co-operative that provides the ability for banking institutions to exchange financial information every day and is highly secure and reliable. The system records the final payment of funds and confirmation of debits i.e. the Realiti® system 304 is based on the actual movement of money across the global financial system as it occurs. The Realiti® system 304 can summarise this data at any level of the bank 302 or correspondent banks' 310 hierarchies with filtering and drill-down capabilities provided to allow focus on specific currencies or combinations of the bank's 302 operations and networks. Data is available real-time so the bank 302 can understand its positions as they evolve throughout the banking day. Live alerting is provided by the analysis module 224, with credit, exposure and liquidity buffer information available to view and report. As the transaction message database 226 of the Realiti® system 304 can store billions of data points, historical trending and regulatory reporting by the analysis module 224 become straightforward and drive direct business improvement.

The Realiti® system 304 is non-invasive to the bank's 302 internal IT operational systems and hence can easily be implemented in a no-risk, incremental rollout across the bank's geographies and business units. Accordingly, a major advantage of the Realiti® system 304 is the short timeframe within which it can be implemented.

Using the Realiti® system 304 will provide the bank 302 with the ability to:

· Understand the bank 302 intraday liquidity usage and hence set its buffer requirements;

Identify and address those areas driving intraday liquidity usage, and then reduce the size of the buffer;

Identify and reduce excessive credit exposures;

· Optimise use of intraday credit and hence minimise both intraday and end-of-day interest charges; and

Figure 6 shows the bank 302 and the Realiti® system 304 in greater detail. The SWIFT gateways 306 are part of the bank's 302 systems. The bank further comprises (SWIFT and non-SWIFT) message queues 324, a currency rates file 320 and a reference data load file 322.

The Realiti® system 304 includes a message handler 350 arranged to receive transaction messages, a Realiti® engine 352, an MT950 message balance logic module 354.

The technology platform that Realiti® system 304 uses is a platform referred to herein as "Graphite" that has been developed specifically for the real-time analysis and optimisation of big data sets. The Graphite platform has been developed using a set of proven industry technology components (NGINX, Linux, BloxWeb, Measure Services, LogicBlox, Sencha, javascript) that have been combined together to provide a highly scalable, big data analysis and optimisation platform.

The Graphite platform comprises the processor 220, the quality parameter generator 222, the analysis module 224 and the transaction message database 226.

An overview of the data processing into and out of the Realiti® system 304 is set out in the following steps one to six: 1. Messaging uses the SWIFT SQS messaging services through the bank's SWIFT gateway(s) 306. The architecture has been built to scale to additional SWIFT message types and non-SWIFT message architectures.

2. Messages are transferred to the Realiti® message handler 350 from SWIFT gateway(s) 306 and are then in the control of the Realiti® system 304, at this point they are parsed and filtered.

3. A transform and load service carried out by the Realiti® message handler 350 enables the appropriate transformed data to be loaded into the Realiti® engine 352.

4. The Realiti® engine 352 manages, controls and analyses the transformed data and provides the visual technologies for end user access.

5. The Graphite platform provides the base technology to support all required Realiti® engine 352 capabilities.

6. Client side services provide the user with front end access through their browser of choice (Safari, Explorer, Firefox, Chrome ... ) on the computer terminal 312.

The message handler 350 provides the real-time interface between the external financial message source and the Realiti® engine 352. The message handler 350 is configured with an architecture designed to handle any SWIFT message and different external message types. The message handler 350 performs the following functions, some of which depend on the type of the SWIFT message: 1. The message handler 350 runs an automated script is run every X seconds (e.g. 30 seconds) to takes messages from the SWIFT message queue or file transfer facility. This capability can be varied based on the real time needs of the service. 2. In the present embodiment of the Realiti® system 304, the automated script links securely to a Bank's FTP (file transfer protocol) server, and looks in the nominated SWIFT AFT (automated file transfer) folder for any newly received MT (message type) files. 3. The message handler 350 moves all files in from this SWIFT folder to the Realiti® /Processing folder and includes restart/recovery capabilities.

4. The message handler 350 then invokes the MT Message Parser service of the Realiti® system 304. The Message Parser reads its configuration file (Parser Config) on startup to understand where to pick up the MT files to process and where to move them once processed.

5. Based on the contents of the Realiti® Parser Config file, the message handler 350 links to the /Processing folder on the Mounted Disk and reads each file in the order of its date-time stamp.

6. The message handler 350 parses the message using a parsing tool such as the MT2XML SDK (software development kit) from SWIFT. It logs any parsing information or errors to the Realiti® Msg Parser Log. If there are any unrecoverable file level parsing errors, the Msg Parser moves that file to the Failed folder, and moves on to the next file.

7. The message handler 350 prepares a JSON (JavaScript Object Notation) file for the SWIFT-JSON service in Realiti® and invokes it. The service is invoked with a unique token which it will respond asynchronously to help the Msg Parser relate to the file being processed.

8. The JSON service responds for each message with one of three statuses: added, updated, failed. In case of failure, no data is inserted. In case of transaction failures, it will respond with service failure status. 9. The Msg Parser looks if any message got no status and marks that as "silently failed". It logs all failed and silently failed messages to the Msg Parser log.

10. If one or more messages succeed, Msg Parser moves the file to the Processed folder and writes the appropriate to the Msg Parser Log. In case the transaction failed, or none of the messages succeeded, Msg Parser writes as appropriate to the logs and moves the file to the Failed folder.

1 1. Every time the message handler 350 script is run, it checks the /Processed folder on the Mounted Disk to see if any files there is more than 3 days old. All such files are deleted.

12. Every time the message handler 350 script is run, it checks for new files in the Failed folder since the last run. If new files are found, an email is sent to the IT operations administration team. It also checks the Msg Parser log for any new errors since the last time it checked. If any new errors have appeared, an email is sent to the IT operational administration team.

As a result of the message handler 350 steps 1 to 12, data will have been through the initial loading into the Realiti® system 304 or held for error processing. The Realiti® engine 352 now runs several calculations and aggregations that ultimately form the running balances for all the nostros held in the system. The Realiti® engine 352 executes the following core elements on the transactions instructions in the transaction messages:

1. Time zone shifting (chronological awareness)

Intelligently converts messages into actual transaction time for their originating time zone. The Realiti® engine 352 does this based off the Value Date (date of transaction) and the arrival timestamp from the receiving SWIFT gateway 306, coupled with knowledge of the relevant account ID and appropriate currency. If the transaction message does not comprise the arrival date and time, the timestamp is assigned by the gateway 306 as the time of arrival at the gateway.

It should be noted that certain messages may also include a transaction time and date, and this may be a time and date in the future at which the transaction specified by the message is to be carried out. Through the time zone shifting the Realiti® engine 352 then knows how to handle the message in terms of it being historic, today or future and as such updates the running balances accordingly.

2. Display computations of running balances

All display time zone and currency (so called 'base' currency and timezones, i.e. those that a user will select to look at) running balance data points are calculated via aggregations at the point the transaction is inserted into the workspace.

3. Reconciliation analysis

The Realiti® engine 352 constantly checks the state of accounts compared to the time a message should be inserted at to ensure that reconciled accounts remain untouched, this maintains a reconciled bank account that means it will match up to the bank's 302 external systems.

4. Balance Pool/Group calculations

The Realiti® engine 352 has the capability to work out and calculate in real-time the relationships between its legal entities and each correspondent legal entities of the bank 302 such that balance netting can be performed. This gives a much more enhanced view of the real liquidity position of the bank 302 and is a useful feature of the Realiti® system 304 that is new to the industry.

5. Dimensional aggregation

Further automated aggregation of all data messages across all predicates (e.g. month/year) and dimensions (e.g calendar) are then carried out real time

6. Block and streak copy

This service provides the optimum method of calculating historic and future run total balances (all predicates and dimensions) through the use of a truncated version of the run-total. The truncated version of the run balance automatically works out the optimum forward time phase required to simultaneously calculate the run balances and optimise performance. At the end of the specific time period (in this embodiment, a market's trading day) a different type of SWIFT message is sent by correspondent banks 310 that essentially contain each correspondent bank's end-of-day statement, these are SWIFT MT950 messages. These messages do not need time zone shifting as they are treated the same no matter the day they are delivered on. The MT950 message balancing logic 354 carries out the following process:

1. The Realiti® parser ascertains if the last page in the MT950 statement has been received, if not then it ignores and disregards the message. 2. Once the last page is received it parses the message and forwards the contents on to the workspace.

3. The elements of the MT950 message required are then loaded into the Realiti® engine 352.

4. The Realiti® engine 352 checks the statement date of the MT950 message, if an MT950 message has already been processed for the associated account after or on said statement date then the MT950 message is ignored, if not then it continues. 5. It then looks at the Realiti® calculated End of Day balance (using the local timezone for the relevant account) for the day that the MT950 message relates to.

6. The Realiti® engine 352 then creates a balancing transaction for the relevant account. a. If the Realiti® End of Day balance is different to the MT950 message final balance then a positive or negative balancing transaction is created so that the Realiti® closing balance matches the 950 message final balance.

b. If the Realiti® End of Day balance is the same as the MT950 message final balance then the system still creates a balancing transaction, but it is zero, this is so the system has a record of a reconciliation taking place.

7. The balancing transaction is then posted on the relevant day, 2 hours after the local closing time of the associated currency's market (i.e. if the Nostro that is being balanced is Japanese Yen, then it will post the balancing transaction 2hrs after the closing time of the Japanese exchange). 8. Entries are also created in the appropriate log files detailing the balancing transaction and associated attributes.

Once an MT950 message is processed, if any MT900 or MT910 messages arrive for a date further back than the day of the processed MT950 message, then those messages will not be uploaded or inserted (i.e. upserted) into the workspace, this is so a fully reconciled account is maintained at all times.

Finally, it should be noted that because the application is built on a datalog code base, steps 3 to 7 carried out by the MT950 message balancing logic 354 (the steps that occur inside the Realiti® engine) are essentially executed all at the same time.

A series of delimited files are sourced externally (either from external systems or from users where appropriate) which get loaded into the system. There will be an initial data load on system setup and then nightly batch updates. These files contain the reference data that is relevant to the needs of the processing Realiti® performs during message loading, calculations/aggregations and real time analysis. This includes the following types of information:

Nostro (account) IDs and attributes

· Bank hierarchies

Currencies and rates

• Timezones

Client default data

Liquidity buffers, credit limits, operating bands etc.

Some of the data (e.g. currency rates) will be loaded on a regular batch such that they are kept up to date. These will be validated before loading in. In addition some of the reference data is held historically so that it can be referenced when historical data is loaded or viewed.

The Realiti® system 304 has a number of logging frameworks in place that hold all success or error messages relevant to the end-to-end process, essentially allowing operators to trace messages and failure reasons etc. The data itself is retrieved by a component called the 'measure service' which effectively takes the request from the user interface, based on all of the selected filters, and determines the fastest and most optimal path to retrieving the required data from within the Realiti® system 304. Once the data is retrieved it then packages the data up and sends it back to the user interface (Ul) in JSON format which is then converted ready for display via the Ul framework to the user. Given the large amounts of data this service is an essential component of the overall solution and enables rapid, real time data analysis of the underlying big data.

Figure 7 shows the technology components used in the data processing of the Realiti® system 304. The technology components comprise a real-time message parser 380, an intelligent loader 382 and a front end service framework 384.

The real-time message parser 380 filters the relevant message types required by the Realiti® system 304, strips the message into individual constituent data components and reformats into a Protocol Buffer (Protobuf) JavaScript Object Notation (JSON) format.

The intelligent loader 382 loads messages into the Graphite data workspace and simultaneously performs a number of activities:

• Time zone shifting - converts messages into actual transaction time for their originating time zone.

· Display computations - all time zone and currency (base currency) display data points are calculated.

Chronological awareness - insertion of individual and aggregated messages dependent on actual time zone shifted stamp and currency value.

Dimensional aggregation - automatic aggregation of all data messages facts across all predicates (e.g. month/year) and dimensions (e.g. calendar).

Block and streak copy - optimum method of calculating historic and future run total balances (all predicates and dimensions) through the use of a truncated version of the run-total. The front end service framework 384 is arrange to carry out intelligent optimisation of the real-time parameterisation of front end message requests. This takes the parameters of a front end data request and works out the best way to retrieve the data through leveraging a LogicBlox™ measure service. The Realiti® system 304 focuses on the core principle of capturing key intraday information, this gives the bank 302 transparency over its actual intraday positions and provides the necessary insight to optimise operations, decrease liquidity buffers and provide detailed high resolution reporting as follows:

1. Real time minute-by-minute analysis across the hierarchy

This capability provides a view of the real time and historic cumulative intraday balance across a selected time period, currency and level of the banking hierarchy.

2. Intraday and multiday peak liquidity usage position

This capability calculates the actual intraday and multi-day peak liquidity usage position with chronological awareness.

3. Credit line limit analysis

This analyses the credit limit for a given nostro against the real time balance for the nostras throughout the day in real time.

4. Multi-day intraday balance

This service shows the minimum and maximum running balance for up to a 90 day period. 5. Intraday turnover

This capability provides hourly summaries of total debit and credit turnover for each hour.

6. Balance groups and pools

This concept enables Banks to net exposures against nostras that can be netted within specific legal entities.

Many modifications may be made to the above examples without departing from the scope of the present invention as defined in the accompanying claims. For example, in the embodiment described above, the transaction utilises SWIFT messages over the SWIFT network. However, in other embodiments, other networks may be used, for example Clearstream, Fedwire, Swiss Interbank Clearing, CHIPS, or a bank's proprietary network used exclusively for its activities. These networks may use SWIFT message standards or proprietary message standards. These networks can provide additional data input into the Realiti® system 304 to develop new banking functionality and capabilities. The core Realiti® engine 352 may remain substantially the same as it has been developed to handle multiple message types.

Another example modification may be related to analysis capabilities. Further functionality may be added to the analysis module 224 of the Realiti® system 304, including:

Stress testing - scientific algorithms model the impact of key stress scenarios against a Bank's intraday history, to test robustness of core operations and identify areas of improvement;

· Predictive analytics - the system uses algorithms and historical trend analysis to identify where real-time behaviour is tracking away from anticipated patterns; and Optimisation - the system identifies corrective actions such as managing flows of outgoing payments to optimise usage of liquidity and/or exposure to correspondents.

In addition to utilising the messages sent from secondary entities to confirm transactions have completed (which enables accurate views of resource values to be calculated) another example modification may be related to incorporating information generated within the primary entities resource databases. Transaction information is generated when transactions are instigated by the primary entity, those transactions being ultimately performed by one or more of the secondary entities. This information, typically in the form of messages moving around internal and external networks, could be utilised to form projected or forecasted resources values. These forecasts can then be compared to actual values as the time period progresses, aiding understanding of performance during the time period and optimising operations.

Claims

A system for the allocation and monitoring of resources comprising:

o a primary entity and a secondary entity, each comprising at least one of:

^■ a plurality of local resource stores, local to and controlled by the

respective entity;

^■ a resource management system for allocating resources between said plurality of local resource stores;

^■ a resource database for logging how resources have been allocated between said plurality of local resource stores; and

^■ a gateway for handling transaction messages originating from and/or targeted to the respective entity, the transaction messages providing instructions how resources are to be allocated between the said local resource stores;

and

o a network for securely transmitting transaction messages between the

primary entity and the secondary entity;

o wherein:

^■ the secondary entity has a local resource store associated with the primary entity, said resource store holding an initial value of resource; and

^■ the primary entity further comprises a resource analysis system; o wherein

^■ the resource analysis system:

• has a transaction message database;

• is interfaced with the gateway of the primary entity so as to copy to the transaction message database transaction messages handled by the gateway of the primary entity;

• is arranged to parse the messages copied to the transaction message database to identify those that are targeted to the secondary entity and that include transaction instructions for transferring resources to or from the resource store associated with the primary entity that is local to the secondary entity;

• is arranged to process those identified transaction messages to calculate how the initial value of resource has changed to an updated value of resource that is held by the resource store associated with the primary entity that is local to the secondary entity; and

• is arranged to display the updated value of resource to a user.

The system of claim 1 , wherein the resource analysis system is further arranged to prepare a request for transmission to the secondary entity to reallocate resources between the resource store associated with the primary entity and another resource store.

The system of claim 1 or claim 2, wherein the secondary entity is arranged to transmit to the primary entity a confirmation message that includes the correct value of resource held, at the end of an exchange period, by the resource store associated with the primary entity that is local to the secondary entity, the confirmation message being sent to the primary entity prior to the start of a subsequent exchange period, and being used by the primary entity to set the initial value of resource that is held, at the start of the subsequent exchange period, by the resource store associated with the primary entity that is local to the secondary entity.

The system of any preceding claim, wherein the resource analysis system is arranged to parse the messages copied to the transaction message database to identify those that include a transaction timestamp specifying when said transaction instructions contained within the message are to be carried out.

The system of any preceding claim, wherein the resource analysis system is arranged to assign a delivery timestamp to the messages copied to the transaction message database, the assigned delivery timestamp being associated with the time at which a respective message is handled by the gateway.

The system of claim 4 or claim 5, wherein the resource analysis system is arranged to order messages for processing chronologically, in dependence on the transaction timestamp and/or delivery timestamp contained within and/or assigned to said messages.

The system of any one of claims 4 to 6, when dependent on claim 3, wherein the resource analysis system is arranged to discard messages having a transaction timestamp or a delivery timestamp in a previously occurring exchange period.

8. The system of any one of claims 4 to 7, wherein the resource analysis system is arranged to display a forecasted value of resource that is held by the resource store associated with the primary entity in response to parsing messages including a transaction timestamp specifying transaction instructions to be carried out in the future.

9. The system of any preceding claim, wherein the resource analysis system is

arranged to display a forecasted value of resource that is held by the resource store associated with the primary entity in response to a draft transaction message queued for future delivery to the second entity, the draft message including transaction instructions for transferring resources to or from the resource store associated with the primary entity that is local to the secondary entity.

10. The system of any preceding claim, wherein the primary and secondary entities

located at geographically distinct locations from one another.

1 1. The system of claim 10 when dependent on any one of claims 4 to 9, wherein the primary and secondary entities are located in different timezones, and the resource analysis system is arranged to register the differences in timezones and in response harmonise transaction and/or delivery timestamps of messages sent between the primary and secondary entities.

12. The system of any preceding claim, wherein one or more transaction messages

comprises at least one of: o an identification of the stores between which a transaction is to be carried out; and

o a quantity, value and/or type of resource to be transferred and/or when it is to be transferred.

13. The system of any preceding claim, wherein the resource analysis system further comprises an error handler arranged to determine messages that cannot be parsed successfully and report them to an administrative user.

14. The system of any preceding claim, wherein the resource analysis system further comprises a quality parameter generator for generating one or more quality parameter for modifying the calculation of how the initial value of resource has changed to an updated value of resource that is held by the resource store associated with the primary entity that is local to the secondary entity.

15. The system of claim 14, wherein the quality parameter generator imports reference data that reflects how external factors are likely to modify the calculation of the change in value of the resource in the resource store associated with the primary entity.

16. A resource analysis system for use with the system for the allocation and monitoring of resources according to any preceding claim.

17. A method of monitoring how an initial value of a resource held by a remote resource store has changed to an updated value, the method comprising the steps of:

o copying transaction messages to a transaction message database;

o parsing the copied transaction messages to identify those that include

o processing those identified transaction messages to calculate how the initial value of resource has changed to an updated value of resource; and o displaying the updated value to a user.

18. A method according to claim 17, further comprising:

o automatically issuing an instruction to adjust the value of the resource held the remote resource store.