WO2012162748A2

WO2012162748A2 - Method and system for generating a set of rates

Info

Publication number: WO2012162748A2
Application number: PCT/AU2012/000617
Authority: WO
Inventors: John Paul Edward CROWLEY-CLOUGH; Stewart Barry EVANS; David John Charles WILLIAMS
Original assignee: Rate Validation Services Pty Ltd
Priority date: 2011-06-03
Filing date: 2012-06-01
Publication date: 2012-12-06

Description

Method and system for generating a set of rates

Technical Field

Described embodiments relate generally to methods, systems and computer readable media for generating a set of rates. In particular, such rates include financial market rates for a set of asset classes.

Background

Financial institutions and other financial market organisations rely on market rate data for various assets across a number of asset classes that is published at the end of each trading day. The market rate data may be used by the financial institutions in order to conduct their market risk analyses and profit and loss analyses, for example. Publication of the market rate data is generally done piecemeal by various market makers and/or so-called quote vendors such as Reuters, Bloomberg, Super Derivatives, Markit, and Totem. The published end of day rates released by each organisation for particular assets along with the instantaneous capture for constantly traded assets, need to be collated and validated by a team of people in each organisation prior to being made available for downstream financial systems. Validation of the published end of day rates needs to meet a number of regulatory requirements. The number of people involved in the rate validation process and the different ways that the processes are performed leads to significant inconsistency among the published rates. It is desired to address or ameliorate one or more shortcomings or disadvantages associated with prior methods and systems for collection and/or publication of financial market rates, or to at least provide a useful alternative to prior methods and systems.

Summary

Some embodiments relate to a method of generating a set of financial market rates for a set of asset classes, the method comprising:

receiving at a server system market rate data indicative of market rates for the asset classes, the market rate data being received from multiple market rate data sources; determining a rate set for the set of asset classes from the received rate data, the rate set comprising a rate value for each asset in each asset class in the set of asset classes;

performing a validation process for each rate value;

determining a validated rate set comprising validated rate values; and making at least a subset of the validated rate set available to subscribers via the server system.

The method may further comprise, for each rate value that fails the validation process, flagging that rate value for further processing. The determining and performing may be performed using the server system.

The making available may be performed at a designated time of a financial market trading day. The making available may be performed at more than one time of day. The making available may be performed in response to a subscriber request to receive the validated rate set.

The multiple market rate data sources may include one or more subscribers and one or more financial market rate vendors.

The validation process may include determining an acceptable variation for the rate value and determining whether the rate value is outside the acceptable variation. The acceptable variation may be determined based on at least one previously stored validated value for the market rate indicated by the rate value. The acceptable variation may be determined according to a stored rule accessible to the server system and specific to the market rate indicated by or corresponding to the rate value. The making available may include making available the stored rules used to determine the acceptable variation for the rate values in the subset of the validated rate set made available.

The determining a rate set may include applying a plurality of rate determination rules to the received rate data, wherein the applied rate determination rule for a rate value depends on an asset class or sub-class of the rate value to which the rate determination rule is applied. The making available may include making available the rate determination rules applied to determine rate values in at least the subset of the validated rate set made available. Some embodiments relate to a computer system comprising means for performing any of the methods described herein. Some embodiments relate to a computer system for generating a set of financial market rates for a set of asset classes, the system comprising:

a rate data acquisition module to receive market rate data indicative of market rates for the asset classes, the market rate data being received from multiple market rate data sources;

a rate validation module to determine a rate set for the set of asset classes from the received market rate data, the rate set comprising a rate value for each asset in each asset class in the set of asset classes, to execute a validation process for each rate value and to determine a validated rate set comprising validated rate values; and

an interface module to make at least a subset of the validated rate set available to subscribers over a network.

Some embodiments relate to computer-readable storage storing executable program code which, when executed by at least one process of a computer system, causes the computer system to perform any of the methods described herein.

Brief Description of the Drawings

Embodiments are described in further detail below, with reference to the accompanying drawings, in which: Figure 1 is a block diagram of a system for generating a set of financial market rates;

Figure 2 is a flowchart of a method of generating a set of financial market rates;

Figure 3 is a flowchart of a method of rate validation employed in the method of Figure 2;

Figure 4 is a flowchart of a method of processing unvalidated rate data; Figure 5 is an exemplary screenshot of a GUI display of a validated rate set;

Figure 6 is an exemplary screenshot of a GUI display of a rate uploading function; Figure 7 is an exemplary screenshot of a GUI display of a rate upload status checking function; Figure 8 is an exemplary screenshot of a GUI display of a rate upload history display function;

Figure 9 is an exemplary screenshot of a GUI display of a rate submission function; Figure 10 is an exemplary screenshot of a GUI display of a rate approval function; Figure 1 1 is an exemplary screenshot of a GUI display of a rate override function; Figure 12 is an exemplary screenshot of a GUI display of a rate selection function;

Figure 13 is an exemplary screenshot of a GUI display of a historic rates display function;

Figure 14 is an exemplary screenshot of a GUI display of a user account management function;

Figure 15 is an exemplary screenshot of a GUI display of a client account management function; Figure 16 is an exemplary screenshot of a GUI display of a rate group's management function;

Figure 17 is an exemplary screenshot of a GUI display of a rules management function; Figure 18 is an exemplary screenshot of a GUI display of a tolerance management function;

Figure 19 is an exemplary screenshot of a GUI display of a rules management function; Figure 20 is an exemplary screenshot of a GUI display of a client subscription management function; and Figure 21 is a schematic representation of the hierarchical application of tolerances to rate values. Detailed Description

Generally, the described methods and systems aim to capture market rates from different rate data sources, and through a series of rules transform them into a validated rate set that can be made available (published) at the end of a trading day and possibly another time. In particular, described methods and systems collect source rates from market participants and rate vendors, and apply a set of auditable rules to create a robust independent end-of-day rate set. Banks and other financial institutions can use these rates as input to their P&L and market risk processes in addition to, or substitution for, their existing internal rate collection processes. Described embodiments advantageously allow rate data to be collected from a number of different sources, including entities that are generators and consumers of rate data, such as financial institution, and a number of different rate vendors. For example, embodiments allow 20 or more rate data sources to be used in generating the validated rate set. This has a benefit of allowing a robust and accurate rate calculation to be performed that is not as error-prone or susceptible to spurious rate values as a rate set sourced from a small number of rate data sources. Further, using described embodiments, non-uniform weightings can be attributed to different rate data sources based on reliability and/or market participation of the entity acting as the rate data source.

Additionally, described embodiments allow ad-hoc and/or intra-day generation and publication of validated rates based on the sourced rate data, rather than being restricted to only publishing the validated rate set at the end of the financial trading day. When embodiments are executed in concert across a number of geographically or temporally separated markets, validated rates generated in one market can be used in the validated rate set of another market.

Compared to rate validation procedures previously performed by financial institutions, which rely on varying internal governance protocols (that are generally not made available to third parties), have only limited rate data sources to draw from and perform only limited error checks (e.g. a basic % movement check), described embodiments may employ robust univariate and multivariate time-series based error checks, draw from a number of different rate data sources and employ rate data processing procedures and rules vetted and accepted by financial institution governance bodies, with a transparent governance framework.

Described embodiments further employ an auditing framework and store comprehensive auditing data to allow transparent auditing of rate data validation procedures, data structures, tolerance checks and rules, for example by a self-regulating organisation for financial market participants.

Figure 1 illustrates in block diagram form a system 100 for generating a rate set. The system comprises a rate validation server system 1 10 that has access to a data store 130. The server system 110 is in communication with one or more rate vendors 144, financial institutions 150 and (thin) client devices 148 over a network 140, which includes various different sub-networks, such one or more local area networks, one or more wide area networks and a public network such as the Internet. Server system 1 10 comprises at least one processor 1 12 (referred to herein as processor 1 12 for simplicity) and a memory 114 accessible to the processor 1 12. Memory 1 14 stores a plurality of software code modules executable by the processor 112 to cause the server system 110 to perform normal server functions and the various functions described herein. The stored code modules include, for example, a user interface module 1 16, a management module 118, a rules engine 120, an event notification module 122, a data acquisition module 124, a curve building module 126, reporting engine 125 and an auditing engine 128, all of which are described further below.

Server system 1 10 has access to data store 130 to store and retrieve data relating to rates to be processed by the server system 110 as described herein. In particular, data store 130 stores validated rate data 134 and unvalidated rate data 136, as well as a number of rules 132 to be used by server system to generate a new validated rate set for each financial market trading day.

Each financial institution 150 may comprise a financial institution server system 155 to interact with rate validation server system 1 10 over the network 140. Financial institution 150 may further comprise one or more client devices 158 in communication with server system 155 over a network, such as a local area network or a wide area network, as well as a market risk analysis system 162 and a profit and loss analysis system 164. Financial institution 150 further comprises end-of-day (EOD) rate data stored in a local data store 160. This EOD rate data is provided to rate validation server system 1 10 at least once daily via data acquisition module 124. Rate data is also received by the rate validation server system 110 at least once daily from rate vendors 144 via rate provider interface module 124.

Each client device 148, 158 may comprise any suitable computing device capable of providing suitable user interface functionality to allow the user of client device 148, 158 to meaningfully interact with server system 110 to obtain the benefit of the rate validation systems and methods described herein. Many such client devices 148, 158 may be comprised in system 100 (and across multiple systems 100 in communication with each other regionally and/or globally) and each such device 148, 158 will generally comprise at least one processor, memory, various peripheral devices or components, a display and a browser application executed by the at least one processor. The user will generally use the browser application on one client device 148, 158 to access the functionality of server system 110 over the network 140. The browser application generates suitable interactive displays by executing code served by server system 1 10 and these displays can be navigated according to web-based browsing techniques to access the rate storage, validation and reporting functions shown and described in relation to the drawings.

The user interface module 116 provides a graphical interface to allow end users to view and manage the functions of the described modules and engines depending on the user's role. User interface module 116 is responsible for interacting with other modules and engines as necessary to source data to be displayed on a client device 148/158 and for generating and sending the program code and/or scripts executable by a browser to enable a suitable display to be generated at client device 148/158 in response to user input sent from client device 148/158 to server system 1 10.

The management module 118 enables administrative control by authorised users to view and manage the rate sourcing, validation, publishing, auditing and user interface/reporting functions of the server system 1 10 according to specified user roles and automated rules. The management module 1 18 effectively provides central management functions to govern and control the other modules and engines. For example, management module 118 may conduct a permissions check for each data access sought by a user via user interface module 116. In a further example, management module 1 18 may allow modification of the rate hierarchy, depending on user permissions.

Responsive to management module 118 and/or event notification module 122, the rules engine 120 operates on unvalidated rate data 136 using rate handling and validation rules 132 that are stored in data store 130. Rules engine 120 uses the rules 132 to calculate official rates and revision values based on the raw unvalidated rate data that are sourced by data acquisition module 124 and optionally also historic (stored) validated rate data.

The event notification module 122 executes tolerance rules (stored as part of rules 132) established using the management module 118 and identifies any rates that breach tolerances, triggering an operational workflow to address rates that are in breach of these tolerances. The event notification module 122 and the rules engine 120 effectively communicate and cooperate with each other to act as a rate validation component that performs necessary validation functions in relation to the received rate data to generate a validated rate set.

The data acquisition module 124 operates on agreed and stored collection rules and schedules to collect raw rate data from market data providers and contributors, such as rate vendors 144 and financial institutions 150. The reporting engine 125 is responsible for interrogating the data store 130 and collating the returned data for reporting purposes.

The auditing engine 128 tracks and records all changes to the data and rules in data store 130, as well as changes to data structures and user account records. Thus, almost any change to the data or functionality of the server system 110 is captured by auditing engine and stored as audit data in data store 130 (or possibly a separate secure data store) for later retrieval of essential auditing information.

The server system 1 10 and graphical user interface (GUI) (described in further detail below) provided by user interface module 116 support the following operations: • Creation of a hierarchy of comprehensive end-of-day market rates across a comprehensive range of asset classes using management module 118, with allowance for separate private hierarchies for approved clients (i.e. user accounts).

• Acceptance of source rates from contributors (e.g. Banks or other financial institutions) or rate vendors 144 (e.g. Reuters or Bloomberg) using data acquisition module 124.

• Checking of incoming rate data against defined tolerances using event notification module 122.

• Application of defined rules to received rate data to generate a robust end-of-day rate set using rules engine 120.

• Allowing users with designated privileges to view and download the validated rates and history sets in a predetermined format, for example such as XML or CSV format, using reporting engine 125.

• Allowing users to create and reuse selection criteria for viewing or downloading subsets of rates using user interface module 1 16.

• Generation of rate revisions to allow a full history of rate inputs and corrections using auditing engine 128.

• Maintenance of the rate hierarchy, client and user privileges using management module 118.

· Logging of all activities and of tolerance breaches using auditing engine 128.

These operations and the system components that enable or execute them are described above as code modules stored in memory 114 and are further described below in the context of user interface functionality illustrated with reference to screenshots in Figure 5 to 20.

The system caters for users with different roles. A user with a specific role will use the part of the GUI designed to support that role, supported by the user interface module 116 executing on the server system 110. A super user may actually have multiple roles.

The user roles referenced herein are as follows:

• Consumer of published rates (e.g. a trader, risk manager or back office accountant that needs to use the rates), also called a customer.

• Contributor of source rates, such as a financial institution or rate vendor. The raw rate information received from contributors forms the input into the rules engine 120, which results in the generation of the published rates. Contributor Validator of source rates. Because there is a provision for customers (e.g. banks) to contribute some of the source rates, there is support for checking and revising uploaded rate data by the customer via client device 148/158 before formally submitting the rates to the server system 1 10.

System Validator of source rates. Source rates contributed and validated by the contributor can also be validated by the system validator, before allowing the rates to be processed by the rules engine and stored into the data store 130. In the case of system validation of uploaded rates, the rules engine 120 will apply the rules over the source data and give a preview of any resulting tolerance breaches to determine whether to approve or revoke the source rates.

Rate Override. This role is only available to an authorized administrative user. This user has the authority to override a rate by manual entry, or by forward- filling from yesterday's rate, for example. At times this will be a critical function to allow publication of a full rate set by a certain time of day. The system validator may in fact have a dual role including this override authority. User Administration. This consumer user manages the access rights of other users of the same consumer account. The system allows for a customer to allocate one or more users to this role.

Customer Administration. This role is only available to a system administrator and includes creating customers and assigning their access rights (to some or all rates).

Rate Administration. This role allows a system administrator to change the rate hierarchy by adding new nodes or rate points, moving nodes within the hierarchy and flagging rates as inactive if they are no longer required.

Tolerance Administration. This role is available to a user belonging to a customer to set up tolerances with respect to source rates the customer is contributing. A system administrator with this role will set up tolerances for the rates to be published.

Rules Administration. This role is only available to a system administrator. This user will create or modify rules for generating published rates, including determination of their applicable start and end dates.

Rate Selection Administration. This user maintains public rate selections (filters) for users belonging to the same client. All users can maintain their own private selections.

Role Administration. This system administrator user can create and edit roles, including the permissions associated with each role. • Exception Signoff. This role is only available to a system administrator. This user may comment and signoff on tolerance breaches on the published dataset.

The rate gathering process for an individual organisation has different levels of governance. The described methods and systems create a formal governance framework around key facets of generation of an end-of-day rate set, which can be applied at the industry level as well as to individual subscriber organisations. The governance framework includes several aspects, as follows. Prescriptive Action: During the validation process, certain triggers are activated, which in turn determine prescribed actions to be undertaken by event notification module 122. This may involve a single trigger or multiple trigger points, which determines the severity or type of the action to be taken. The actions are based on an escalation framework, which is determined by the severity of the criteria. It may be as simple as an email notification, through to a formal notice to an Audit committee requiring a response.

For example, an institution may submit a rate that is outside a predetermined threshold. The appropriate action determined by event notification module 122 (based on rules 132) may be to notify via email directly to the contributor for the first occurrence. However, with repeat occurrences of tolerance breaches, rules 132 may require event notification module 122 to execute an escalation process. For example, for three contributions outside the threshold, notification may be sent to the head of the contributing area; ten breaches may require notification to be sent to an oversight committee for the rate product and to the relevant Board Member of the contributor. The notification actions are prescriptively set beforehand and have pre-designated pathways of action and follow-up.

Documentation Manifest and Reporting: A central repository of all the conventions, rules (collection, calculation and tolerance) and governance protocols are held in a relational data store 130 in a linked state that enables seamless reporting, regardless of the interrogation required i.e. by product, by rule, by convention. This allows visual representation of the rate validation process via user interface module 116 from front to back with clear linkages across related areas. It is believed that no prior system houses all the described module and engine components, or has the ability to audit the relationships between applications performing an individual action, so documenting the linkages and the front to back process does not seem to have been done.

Eligibility Criteria: The governance framework includes a clear definition of who can contribute source data for the rates. The entities acting as data sources are graded and selected based on their eligibility to contribute. Eligibility is determined according to the contributor's market position in the rate product they are contributing to. The contributor either has to be a recognized and/or accredited provider of prices (i.e. rates) to the market or a significant participant in the rate product. The stored rate set is organized as a hierarchy. Each node in the hierarchy has a short name which becomes part of the naming convention for nodes below it. In the hierarchy extract below, the highlighted rate has a short name AUDUSD. Its long name is RVS.RATE.FX.VOL.AUDUSD

The top nodes of the hierarchy may be the names of organizations (i.e. the rate publishing organisation or a client name). Clients can see rates in the overall hierarchy (with the top node here called "RVS") and their own private hierarchy if it exists. The next level down represents markets (FX, Interest Rate, Commodity etc). The bottom level has extra "rate" attributes assigned, and the second bottom level has "instrument" attributes. Curve definitions may be built from instruments at the second bottom level.

The management module 118 is designed to allow re-ordering of the rate hierarchy, even though permissions, rules and tolerances are all dependent on the hierarchy. The hierarchy is not constrained to any maximum depth, and can support different depths for different markets. For example the commodities branch may need more levels than the equity branch. Via the GUI provided by user interface module 116, users can define rate selections as a list of nodes in the hierarchy. Selections can also be based on short name matches (e.g. "SWAP" could pick up interest rate swaps and commodity swaps). These selections can be stored and re-used whenever viewing or downloading rates.

Fig 5 is an example screenshot of a rates display 500 through which the server system 110 makes the entire set of currently validated rates available for access by consumers. The official rates screen is available for all users but is specifically designed for users with the role of consumer. The primary purpose of this screen is to allow users to select, preview and download official (validated) rates for a specific date and region. The region may be a country, part of a country or may include more than one country.

The tree view of the rate hierarchy shows all official rates available to the customer account that the logged-in user belongs to. A search box is provided to help the user find relevant nodes in the tree. The user can choose a public or private rate filter so that the tree only displays a subset of the rate hierarchy.

A rate table displays the rates under the node selected from the tree view, including the previous day's rate and relative movement (e.g. in percentage, absolute or other type of value change). The rates shown are applicable to the selected date and revision. The display defaults to showing the current date and latest revision.

Rates can be saved to a file on the client device 148, 158 in xml or csv format, for example. Rates that are not licensed to a client (or otherwise permitted to be seen) are greyed out in the tree view.

A rate contributor (which may be a bank, for example) has two roles available to it: "contributor" and "validator". The contributor loads the rates into the system and does some tolerance checking before setting the status from "checking" to "uploaded". This functionality is in place to offer to contributors the ability to run validation tests over their rate data contribution before it is submitted to form part of the industry rate. The business value is to reduce the number of threshold breaks, which in turn will cause fewer notification actions under the governance protocols.

The validator may also invoke a tolerance checking preview function (executed by rules engine 120 and event notification module 122) via the GUI (including checks between the source rate and the most recent validated rate) before setting the status to "submitted".

In addition to automated processing of the submitted rate data by rules engine 120 and event notification module 122, submitted rates may be viewable by a system administrator tasked with approving the rates. This user can apply the rules in preview mode and see tolerance breaches on rates that would result from approving these rates. As a supplement or substitution of the automated rate processing, the system administrator can choose to approve some or all of the Bank's contributed rates.

A system administrator has the ability to manually override rates, or forward fill rates from the most recent validated rate. The forward fill operation may be automatically performed by the rules engine under certain circumstances and would typically be applied to any last remaining missing rates before setting the "IsOfficial" flag on the dataset for the day. Users at each authority level are able to effectively intervene in the automated rate processing and stop rates progressing further in the validation process. This action can be automated on the basis that there are predetermined courses of actions that are taken in the event of an erroneous rate. The validation process is shown and described in further detail below with reference to Figures 2 to 4.

Rate vendors 144 are set up in the system as clients (eg RVSReuters, RVSBloomberg) with the IsRateSource flag set to true to indicate their status as a rate data source. One outcome of this is that rules can apply non-uniform weighting to rates received from different sources (e.g. 60% Reuters rate + 40% Bloomberg rate) when determining the putative (unvalidated) rate for a particular rate type.

When rates are loaded (via the data acquisition module 124), the server system 1 10 will recognize them as rate vendor rates and immediately upgrade their status to "Submit". This only leaves the internal approval stage whereby tolerances can be checked before allowing the rules to be applied to create the relevant validated rates.

The Upload screen 600 shown in Figure 6 is designed for users with the role of Contributor. The tree view and rate selections work in the same fashion as in Figure 5. Rates can be loaded from a file in a specified (e.g. xml) format to the GUI using the rate provider interface module 124. Clicking the check rates button will load the rates into the data acquisition module 124 for private viewing and performance of a tolerance check against the previous trading day's validated rates. Rates for which tolerance breaches are determined may be highlighted or otherwise visually emphasized in the table, for example in light red. The user can select which rates to "upload". These rates will change status on the server from "checking" to "uploaded" and will then be viewable by users from the same client that have the Validator role. Based on feedback from the tolerance checks, the user may choose to delete the rates. This is the last stage in the process where the rates will be physically deleted from the system. After this point, all rates are stored in data store 130 and can only change status (e.g. to Deleted or Revoked).

A list of pending rates can be displayed. These are rates that the client is contracted or expected to contribute but that have not yet been contributed for the selected date. As shown in Figure 7, under a display 700 accessed via the upload screen 600, selecting the "Provider Rate Current State" tab shows the user which rates that the client is supposed to contribute have not yet been loaded. For rates that have been loaded, this tab page shows the Status reached for each rate. It also shows cases where a rate from an earlier revision has reached approval level but, perhaps due to a correction, a replacement rate is being processed.

As shown in Figure 8, under a display 800 accessed via the upload screen, selecting the "History by Date" tab lists the rates that have been loaded for a selected date, by which users and when. For this function, the user interface module 1 16 invokes functions of the reporting engine 125 to query data in data store 130.

The Submit screen display 900 shown in Figure 9 is designed for users with the role of Validator. The Submit screen's tree view and tab pages perform the same role as in the Upload screen. The user can check tolerances for rates that are ready to be submitted. A user with the role of validator can use the submit screen to sign off on rates. These rates are then given the status of "submitted", at which point they will become viewable by a system administrator validator. Based on feedback from the tolerance checks, the user may choose to reject the rates. All submitted but rejected rates are stored in data store 130 and form part of the reporting process along with the actions that need to be undertaken as part of the governance protocols. This is a significant piece of feedback information provided to the rate contributors to ensure that their rate data submission maintains quality and integrity. When a group of source rates are approved (the third stage in the rate loading process), validation rules are applied, and as a result, the rates that have passed the required validation tests are added to the validated rate data set 134 in data store 130. Source rates submitted but not validated are stored or flagged as unvalidated rate data 136. A system administrator who approves rates can elect to approve any or all of the submitted rates in a single batch. Alternatively, part or all of the rate validation process can be automated. Each batch is called a revision because it will add to and in some cases modify the latest rates available to consumers. The revision mechanism does not delete any pre-existing rates. Instead, a new revision ID is created and tagged to the new rates. Each revision has a timestamp so each new revision will become the "latest" revision.

Available validated or unvalidated rates may be generated by rules engine 120 during the day as the source data becomes available (or enough source rates are received and approved to run the rule that generates a given rate, for example where the rate is calculated as a weighted or simple average of multiple source rates). This gives consumers and rate loading personnel a clear view of which rates have and haven't been loaded for the day. There may be occasions where some rates are unable to be sourced in time for the official cut-off time (which may be around 4:30 to 5pm). The server system 1 10 has a "fill from yesterday" function designed to allow event notification module 122 to complete the rate set (by setting the previous day's validated value as the current value for the missing rate) just before flagging the "official" revision for the day. When a user is looking at rates up to a particular revision, what they are actually seeing is the latest instance of each rate with a revision ID equal or less than the selected revision. Table 1 shows an example: Table 1

Users downloading rates can see the list of revision timestamps in the GUI tabular rates display 500 (Fig. 5). A user may opt to see the latest rates available but may alternatively opt to see the rate set as it appeared as at some earlier revision. In particular, there will be an "official" revision each day (possibly around 5pm) at which point the server system 110 will have attempted to ensure the rate set is fully available and, through tolerance checking, contains no major errors.

The revision date should not be confused with a value date. It is possible to load rate values for dates well in the past in order to strengthen the historical database. Even these rates will be tagged with a new revision ID. The system supports loading rates across multiple value dates in a single revision.

When requesting a history set, the user can request a history of "official" rates, or a "best available" history, and will usually choose the latter. This is because, as improved data becomes available, the data sets for past days will continue to be improved and expanded by new revisions.

As shown in Figure 10, the Approve screen display 1000 is designed for users with the roles of System Validator and Rate Override. The Approve screen's tree view and tab pages perform the same role as in the Submit and Upload screens 600, 700, 800, 900, with the exception of a new tab "Override Rates" described below.

The system validator can check rates before approval. The rules engine 120 identifies the established rate for which the rate data is submitted and determines one or more rules from the stored set of rules 132 (e.g. by a lookup operation) and applies the appropriate rule or rules against the source rate data. These rules might involve combining newly received rates with previously received rates from other contributors, for example in a weighted average calculation. The user can preview the official rates which will be generated if these client rates are approved. The user interface module 116 (in cooperation with event notification module 122) will also generate a display to show any tolerance breaches that would occur in the approval process. Any such tolerance breaches will be logged by the auditing engine 128 in audit data 139 if the user goes ahead and approves the rates. An identification of the user who approved the rates will also be logged in audit data 139.

Based on feedback from the tolerance checks, an authorised user may choose to revoke the calculated rates before they are accepted as official validated rates. Revoked rates are retained in the unvalidated rate data 136 (and logged in audit data 139) in data store 130 for recording and audit purposes. These unvalidated rates can then be subsequently processed as part of the reporting process and governance and audit protocols.

Still on the Approve screen, as shown in display 1 100 of Figure 1 1, the Override Rates tab is designed for users with the role of Rate Override. A user with this role can delete a previously approved rate, for example due to new information concerning its accuracy.

Missing rates can be copied forward from the validated rate set from the previous trading day, either by a rate processing rule or triggered by a user request. This may be necessary at times to allow the server system 1 10 to satisfy its service level agreement with customers - that is, to make a full end of day rate set available by a certain time (eg 5pm) for a particular jurisdiction.

If there are no missing rates, a user with the Rate Override role has the authority to flag the approved rate set as official. This approval action may be performed automatically upon certain criteria being met (e.g. no recorded tolerance breaches). If suitable approval input is received via the GUI, the user interface module 116 will cooperate with management module 118 to cause a new revision of the rate data set to be created that authorised users will be able to identify as the official revision for the current trading day. This approved rate data set thus becomes the validated set of rate data to be made available to subscribers. This approval action cannot be reversed, however improved rates for this value date can still be loaded into "post-official" revisions at any time in the future.

All users have access to the rate selections screen 1200, which is shown in Figure 12. Here they are supported by the user interface module 1 16 to create private selections. Users with the role Rate Selection Administration have the added ability in this screen to make a selection publicly viewable for all users belonging to the same client. The screen allows a user to add, edit or delete a rate selection. Selecting a node within the search tree makes all of the rates under that node available in that selection. Deselecting a node (see the cross against base metals in the screen shot of Figure 12) means that this node is not available in the selection even though a node above it has been checked. Besides fixed nodes, selections can also contain dynamic query elements. For example, adding 'SWAP' as a dynamic query will include all 'SWAP' nodes in the tree. This can be thought of as a cross-section of the tree (e.g. SWAP could occur under Commodity, Interest Rate etc, and under multiple currency nodes). The Historical Series screen 1300 shown in Figure 13 is available for all users but is specifically designed for users with the role of consumer. The primary purpose of this screen is to allow users to select and preview historic rate series, supported by the user interface module cooperating with the reporting engine 125. The user is able to choose the historic period (start and end date) and can choose between the official rate series or the "latest" series, meaning it includes improvements to rates that may have occurred after the official revisions on some of the historic dates.

The user can choose between tabular or graphical view, the latter giving the user an easy way to see outliers. Hovering the cursor over (or otherwise selecting or shifting user focus on) a plotted data point on the graph causes page code executing on the browser of client device 148/158 to provide further details relating to that data point, such as the date, rate amount and optionally bid and offer amounts. The Users screen 1400 as shown in Figure 14 is designed for creation and maintenance of user information by a user with the role of User Administration. Each client can allocate one or more people with this role to maintain their own user base. This function is supported by the user interface module 1 16 cooperating with the management module 118. The Client screen 1500 as shown in Figure 15 is used for adding new clients or modifying existing client records. The user of this screen must have the role of Customer Administration. Clients can be set up as providers (i.e. contributes rates to a rate source), consumers or both. This function is supported by the user interface module 116 cooperating with the management module 1 18.

The "RateSource" check box allows a rate provider 144 to be included as a client. This allows the rate vendor's rates to be captured and tracked in an equivalent way to rates being collected from other contributors, such as financial institutions 150. The Rate Groups screen 1600 as shown in Figure 16 allows the rate hierarchy to be extended and modified by users with the role Rate Administration. This function is supported by the management module 118 in cooperation with the user interface module 1 16. Management module 118 automatically updates the rate hierarchy data structures stored in data store 130 to reflect any changes made to it.

Drag and drop functionality in the tree structure simplifies modification of the hierarchy, and placing new nodes. The dialog on the right makes it simple to add or edit nodes. The bottom two layers in the tree are recognized as special cases, and support entry of extra details via the fields displayed on the right side of the display for the highlighted node, which in this case is the 1 year AUD swap rate. For example, these fields allow entry of additional information that is part of the asset that is needed in terms of what the asset represents, such as: Maturity Date; frequency; Strike; Currency.

The Rate Group screen allows the user to preview any changes before committing them to the server system 1 10.

The Manage Roles screen 1700 shown in Figure 17 allows a user with Role Administration role to create roles and set the permissions associated with each role. This function is supported by the management module 1 18 in cooperation with the user interface module 1 16. A screenshot 1800 of tolerance-setting functions is shown in Figure 18. Tolerances may include checks (executed by rules engine 120) against the prior trading day's rate being either too large or zero (staleness check). Some tolerances may use more than one day's history for comparison (e.g. compare today's rate with a formula, such as a (uniform or non-uniform) weighted or non-weighted average, applied to the last 30 days history for that rate).

Tolerances may also apply to source rates or loaded/validated rates. The following combinations are supported, as illustrated in Table 2 below.

Table 2

Breaches of one or more types of tolerance checks may be logged by the auditing engine 128 in audit data 139. In one example, only the third type of tolerance breach (type 3) is logged. Type 1 and 2 tolerance checks are tools to help users to verify rates at different stages in the load process but may not need to be recorded. Only when a rate approval results in a tolerance breach in a loaded and submitted rate should it be logged. The rate approver has the ability to see breaches that will occur before approving rates (preview mode) and therefore is presumed to be consciously deciding to approve the rates anyway. By logging these breaches, further follow up and audit of the process is possible.

Rates received from rate vendors 144 are subject to tolerance checks. Vendor rates loaded through the data acquisition module 124 may be automatically set to "submitted" status. However, the final approval step can still be subject to tolerance checks, so the server system 1 10 does not have to rely on the vendor systems' quality control processes. It also protects against mapping errors that might occur in the rate vendor interface provided by data acquisition module 124. Named tolerance types are stored as part of the rules 132 in data store 130 (e.g. "PercentMovement" or "Staleness"). Instances of these tolerances can be set up at different levels in the hierarchy. A tolerance set at a high level in the hierarchy will act on many rates. Figure 21 illustrates how the tolerances are applied by default to all lower nodes in the hierarchy.

Tolerance rules may be configured to generate a description of a tolerance breach. E.g. "RateDef: Copper Spot has breached the 10% daily tolerance with a movement of 14.6%". This description is stored in the tolerance log (i.e. audit data 139), along with details such as the Value Date, Revision and User who approved the rate.

Tolerances can be limited to operating between a user defined start and end date. They can also be permanently deactivated. The diagram of Figure 21 shows how tolerances have been placed within the hierarchy. The general rule is that a tolerance will act on all rate level (bottom) nodes below it. If the same tolerance ID appears more than once, the one closest to the rate node takes precedence. It is also possible to block the action of a high level node. In this example, the staleness tolerance is blocked from operating against the CPI forecasts because they are only updated periodically and would fail that tolerance check. Table 3 below lists which tolerance check is applied to each of the end rate nodes.

Table 3

The Tolerances screen 1800 shown in Figure 18 allows tolerances and their parameters to be set up at different levels within the hierarchy. A user must have the role of Tolerance Administration to make changes in this screen. Creation and modification of tolerances (as rules 132 to be stored in data store 130) is supported by user interface module 116 in cooperation with management module 118. A tolerance set up at a given node in the hierarchy will be applied to all rate nodes below the node at which the tolerance is specified. There are two exceptions to this; firstly the same type of tolerance may be set up at a lower node (thereby taking precedence for rates below that node), or a "block" might be set up so that a tolerance that is generally applied is blocked from a subset of the tree.

A rate can be subject to multiple tolerance checks (e.g. a % move check and a staleness check), but only one tolerance of each type can affect a rate. Rules are applied to source rates (that have passed tolerance checks) to generate validated rates. Just like tolerances described above, rules make use of the hierarchy to avoid repetition. So a single rule created at a high level in the hierarchy can be used to generate many rates that descend from it. Only one rule will be used to generate each rate. This is the first rule found at a node of the hierarchy when ascending the rate hierarchy from the bottom (rate node) level.

Whenever a rule is used to generate a rate, its ID is stored with the rate in the data record for the rate. Rules are never changed in the system, but instead are replaced by a newer version. It is therefore possible to see exactly which rule was applied to generate a rate, thereby allowing easy auditing of the rate. This is true even for rates generated long ago by rules no longer in use.

It may be necessary to apply a different formula depending on the source data available. For example, if two source rates are available to generate a rate, the rule might be to take the average, or possibly taking the median when three or more source rates are available. This cascade effect may be coded into the rule itself. An alternative would be to allow simple rules to be linked together for specific rates or rate groups. Rule Clusters

The gathering of market data has previously followed a well-worn path of attempting to acquire the best rate data possible at the time of collection. This process of acquisition identifies and sets the best rate source from where to gather rate data. Failure to obtain this data may result in manual intervention in an attempt to re-direct the rate data acquisition to the next best data source. The server system 1 10 automates this via simultaneously sourcing from multiple sources where possible, including rate vendors 144 and consumers for those, rates, such as financial institutions 150, combined with a concept of "rule clustering". Collection rules are grouped together to create a cascading of rate processing rules based on what is available at the time of collection. This has multiple implications:

• Automation of the daily collection process;

• Each subsequent collection rule is triggered as a result of the higher value collection rule conditions not being able to be met, and the result can be tagged as to the quality of the data source;

• Different calculations of the derived rate can be applied depending on which collection rule has been triggered, which assists in the classification of the quality of the data source.

The cascade means that the rule clusters allow for the automated execution of a data collection run at any point in time, without the need for specific rules for specific times. The rules cluster has created a priority for the data collection management and subsequent actions. Current market practice is that this is only managed via human intervention. The process flow will always begin with attempting to source the best data and then move down the quality scale dependent on availability.

The Rules screen 1900 shown in Figure 19 is designed for users with the role oi Rules Administration. By "rules" we are specifically referring to the calculation algorithms used to convert the raw input rates contributed to the system into the official end of day dataset. Once the raw data has been validated for errors via the tolerance rules, the algorithm applied will reflect the best calculation methodology based on the collection rule that has been executed (e.g. if all contributions are received then apply a weighted average based on the contributors, but if only 2 contributions are received then apply a simple average).

This screen 1900 shown in Fig. 19 allows the user to attach rules to rates on higher up nodes. The higher up the rate tree a rule is placed, the more rates it can potentially be applied to. However, rules placed at lower levels in the rate tree will take precedence over the higher up ones. This is illustrated generally in Figure 22, where tolerance rules 1 and 2 are applied at the top level in the tree structure, but can be modified at lower nodes, as described above.

Only one calculation rule can be applied to any given rate although, as described above, this rule might use different calculation algorithms, depending on the contribution data collected. For example, where rate data has been sourced from only two different sources (e.g. a rate vendor 144 and a financial institution contributor 150), a simple average calculation of the rate based on the two source rate values received for that rate may be performed, whereas a weighted average may be calculated for rates where three or more source rate values were received. Weights may be determined according a historical measure of reliability and/or the level of market participation of the source (if it is a financial institution), whereby sources shown to provide rate data that is reliably complete and validated are allocated an increased weight over those shown to be less complete and reliable. Where a source of rate data is a financial institution having a significant share of the trading market, this may support an increased weight being given to rate data from that source. However, different weights may be applied across different asset classes for the same rate data source, reflecting differing market participation levels and/or reliability across different sectors. The rule that is used to generate a rate is stored alongside (or linked to) the official rate in the data record for that rate and such rules can never be deleted or edited. This ensures that a clear audit trail will always exist to show exactly which rule was applied to generate an official published rate. The Subscription screen 2000 shown in Figure 20 allows a system administrator with the role of Customer Administration to define permissions for a customer. This screen should reflect the scope of a customer's subscription, allowing users from this customer to see only the rates specified. The second box in the screenshot 2000 of Figure 20 is for defining the rates for which a customer has agreed to contribute source rates on a daily basis. This allows both the customer and server system 110 to track whether they have in fact supplied all the rates they were supposed to on any given day. Referring now to Figure 2, a method 200 of generating a set of financial market rates for a set of asset classes is described in further detail. Method 200 begins at step 205, in which rate data is sourced from rate vendors. Independently and over the same period, rate data is sourced from contributors, such as financial institution 150, at step 210. While steps 205 and 210 are performed contemporaneously, they are not necessarily performed at exactly the same time and, in fact, will generally be performed independently during one or more periods of each financial market trading day. The sourcing of rate data from rate vendors and contributors at steps 205 and 210 may involve processing threads of data acquisition module 124 automatically querying, interrogating or otherwise downloading the rate data from the various rate vendor and contributor sources. Alternatively or in addition, data acquisition module 124 (which executes steps 205 and 210) may transmit requests to the source from which the rate data is desired to be obtained and then wait to receive the requested data in a format specified for the particular rate data source.

At step 220, rate data received by data acquisition module 124 in steps 205 and 210 is validated by event notification module 122 in corporation with rules engine 120. Optionally, results of the validation process, either preliminary or finalized results, can be displayed at client device 148 via user interface module 116.

At step 225, event notification module 122 identifies any rate data that is not validated and, if any such rata data exists among the sourced rate data, then that data is flagged at step 230 by event notification module 122 for further processing at step 232. Rate data that is validated at step 220 or as a result of the further processing at step 232 is stored as validated rate data 134 at step 235. The data sourced at steps 205 and 210 is time stamped and is stored in validated rate data 134 with an indication of the date and time at which it was received. In fact, all rate data that is sourced at steps 205 and 210 (and that is not a null data set) is stored in data store 130, either as unvalidated rate data 136 or validated rate data 134.

At step 240, management module 118 determines via user interface module 1 16 whether an intra-day request for a validated rate set has been received and, if so, then step 250 is performed under the control of management module 1 18 to generate an intra-day rate set from the current validated rate data 134 in data store 130. This is primarily performed by event notification module 122 acting in concert with rules engine 120 (together as a rate validation component). Where validated rate data 134 does not exist for the trading day on which it is requested to be provided as part of an intra-day rate set at step 250, event notification module 122 and rules engine 120 will apply predetermined rules to generate a rate value for that rate to be provided with the intraday rate set. This may involve using a rate value from a previous trading day's validated rate set or may involve sourcing a validated rate value for the rate from another trading region, where the asset in question is traded across multiple markets.

Whether or not an intra-day rate set is generated at step 250, management module 118 controls event notification module 122 and rules engine 120 to generate an end of day rate set from the validated rate data 134 current as of the time of day in the local country and/or region serviced by server system 110 or as specified by the consumer.

The "end of day" rate set may not actually be established at the time of close of business and in fact may be established at or around a particular time before close of business. For example, where close of business occurs at 5.00 p.m., the "end of day" rate set may be determined as of 4.00 p.m. or 4.30 p.m., for example. Steps 260 and 250 further involve making the intra-day or end-of-day rate set available to subscribers according to their authorized access level. In this regard, not all rate data will be available to subscribers who have chosen to subscribe to only a subset of the rate data generated by system 100. Referring now to Figure 3, a process according to step 220 of validating sourced rate data is described in further detail. The validation process begins at step 310, at which the unvalidated rate data is loaded into temporary storage in memory 1 14 of server system 110. At step 320, for each rate value of the received rate data, rules engine 120 determines the applicable rule or rules 132 to be used in validating that rate data. That is, rules engine 120 determines the rule or rules 132 to be applied for validating the rate for which the data value is received. This may be done by parsing metadata associated with the received rate values to identify the rate for which the rate data value was provided, for example. At step 330, the rules engine 120 looks up the stored (historical) validated rate data 134 for the rate under consideration and accesses the validated rate values stored for one or more previous trading days. At the same time or before or after step 330, rules engine 120 applies one or more rules 132 to determine one or more acceptable variations of the values for the rate under consideration. At step 350, rules engine 120 determines whether the received rate data value for the rate under consideration is within the one or more acceptable variations and, if so, flags the rate data value as being validated at step 370. Otherwise, the rate value is flagged at step 360 as not being validated. Following steps 360 and 370, the process returns to method 200 at step 225.

Referring now to Figure 4, a method 232 of processing unvalidated rate values is described in further detail. Method 232 begins at step 410, at which event notification module 122 determines, for each rate for which unvalidated rate data was received, whether manual or automatic processing is required to be performed. At 420, if the rate data is to be automatically processed, then event notification module 122 cooperates with rules engine 120 to ascertain and apply one or more further processing rules to the rate data for the rate under consideration. If, following step 430, rules engine 120 can validate the rate data, then that rate data is added to the validated rate data 134 at step 470. Otherwise, following either step 420 or 440, the unvalidated rate data may be presented for user review (by a user with a validation role) at step 450 in order to be processed according to established manual validation protocols. The actions of the user in manually inspecting and validating (or not validating) the rate data is saved in audit data 139. At 460, all rate data that is validated by the user as a result of step 450 is added to the validated rate data 134 for the current trading day at step 470, while rate data that is unvalidated is rejected at step 480 but is kept and stored in unvalidated rate data 136.

Because of the nature of rate data sourcing, at any point during the financial trading day a rate may for any number of reasons be unavailable, resulting in the sourced rate data being incomplete. Such events can result in process failure, needing data to be resent (if possible) and would historically require manual intervention to address the problem. However, an intervention after the initial failure of the data, which for some systems may only be discovered once the data has been consumed by the end system, results in inaccurate reporting and may require the data to be resent or rekeyed, wasting time and resources.

Described embodiments allow the identification of the best rate for a particular financial product at a particular point in time. The rates are influenced by two significant issues: liquidity and availability. To best value an asset, one must use a price that reflects a "normal" market. The term "normal" is subjective as it depends on individual products, but is best described as "an asset's ability to be sold without causing a significant movement in the price and with minimum loss of value." An asset's liquidity may vary during a 24hr period, dependent on the available market participants. For example, US Dollar based foreign exchange (FX) deals can be executed at almost any point in a 24 hr period, whereas equities on a national exchange are limited to the opening hours of the exchange they are listed on. Further, technical issues may occur from time to time that hinder the collection of the best available rate at the time of collection. Described embodiments may employ global, regional and national rate validation constructs according to the stored rules 132, so that server system 110 can be aware of, and communicate with, another server system 110 (e.g. over public network 140), regarding certain rate data. This means that server system 1 10 can have a specific rule (such as a collection, calculation or tolerance rule) based on the region or country. Server system 110 may thus employ rules 132 to collect the rate at a relatively liquid point, and then for temporally succeeding regions where the product is not as liquid, the applicable sourcing rule can be set to obtain the relevant rate data from the prior (most liquid) region. If the product is one that is traded constantly through the 24hr trading period, then either a global collection rule or one or more regional collection rules can be used. Thus, the published benchmark rate can reflect the product at its most liquid point during the 24hr trading day period.

In prior rate validation processes where there was a technical fault resulting in a failure to collect a rate, the only option available to operators in the usually limited time was to copy forward the rate from the prior trading day. Thus, the collected rate data is at least 24hrs old and may have no metadata attached to it to indicate that the rate is stale. The regional rate collection construct, combined with the priority order of the collection rules executed by the rules engine 120 means that the lowest ranked collection rule for products traded globally is always to copy forward the rate from the previous region. This means that the published rate is no more than about 4hrs old. As the information is available as to which collection rule has been executed, this metadata instantly provides the reference information that there has been an issue with the rate that was not previously solved in the time needed to publish the benchmark rate. By providing the functionality to produce a benchmark rate at multiple times during a global 24hr trading period, server system 1 10 can account for differing levels of liquidity among different regions during the 24hrs, and as such can utilise the same function to copy forward rates in the event of disruption rather than simply using the rate from the prior trading day.

Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present invention as it existed before the priority date of each claim of this application.

Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Claims

CLAIMS:

1. A method of generating a set of financial market rates for a set of asset classes, the method comprising:

receiving at a server system market rate data indicative of market rates for the asset classes, the market rate data being received from multiple market rate data sources;

determining a rate set for the set of asset classes from the received rate data, the rate set comprising a rate value for each asset in each asset class in the set of asset classes;

performing a validation process for each rate value;

2. The method of claim 1, further comprising for each rate value that fails the validation process, flagging that rate value for further processing.

3. The method of claim 1 or claim 2, wherein the determining and performing are performed using the server system.

4. The method of any one of claims 1 to 3, wherein the making available is performed at a designated time of a financial market trading day.

5. The method of any one of claims 1 to 4, wherein the making available is performed at more than one time of day.

6. The method of claim 5, wherein the making available is performed in response to a subscriber request.

7. The method of any one of claims 1 to 6, wherein the multiple market rate data sources include one or more subscribers and one or more financial market rate vendors.

8. The method of any one of claims 1 to 7, wherein the validation process includes determining an acceptable variation for the rate value and determining whether the rate value is outside the acceptable variation.

9. The method of claim 8, wherein the acceptable variation is determined based on at least one previously stored validated value for the market rate indicated by the rate value.

10. The method of claim 8 or claim 9, wherein the acceptable variation is determined according to a stored rule accessible to the server system and specific to the market rate indicated by the rate value.

11. The method of claim 10, wherein the making available includes making available the stored rules used to determine the acceptable variation for the rate values in the subset of the validated rate set made available.

12. The method of any one of claims 1 to 1 1, wherein the determining a rate set includes applying a plurality of rate determination rules to the received rate data, wherein the applied rate determination rule for a rate value depends on an asset class or sub-class of the rate value to which the rate determination rule is applied.

13. The method of claim 12, wherein the making available includes making available the rate determination rules applied to determine rate values in at least the subset of the validated rate set made available.

14. The method of any one of claims 1 to 13, wherein the making available includes making at least a subset of the validated rate set available to another server system in another region or country for use in generating a set of financial market rates in that region or country.

15. Computer-readable storage storing executable program code which, when executed by at least one processor of a computer system, causes the computer system to perform a method of generating a set of financial market rates for a set of asset classes, the method comprising:

performing a validation process for each rate value;

16. A computer system to generate a set of financial market rates for a set of asset classes, the system comprising:

means for receiving at a server system market rate data indicative of market rates for the asset classes, the market rate data being received from multiple market rate data sources;

means for determining a rate set for the set of asset classes from the received rate data, the rate set comprising a rate value for each asset in each asset class in the set of asset classes;

means for performing a validation process for each rate value;

means for determining a validated rate set comprising validated rate values; and means for making at least a subset of the validated rate set available to subscribers via the server system.

17. A computer system for generating a set of financial market rates for a set of asset classes, the system comprising:

18. A computer system comprising means for performing the method of any one of claims 1 to 14.

19. Computer-readable storage storing executable program code which, when executed by at least one processor of a computer system, causes the computer system to perform the method of any one of claims 1 to 14.