WO2014008573A1

WO2014008573A1 - Banking server, networked system and method

Info

Publication number: WO2014008573A1
Application number: PCT/CA2012/000738
Authority: WO
Inventors: John George Bruce Mclean
Original assignee: Ftse Tmx Global Debt Capital Markets Inc.
Priority date: 2012-07-13
Filing date: 2012-07-31
Publication date: 2014-01-16

Abstract

A banking server, networked system and method for processing data records are provided. The banking server includes a network interface and a processor in communication with the network interface configured to receive a request data-message and to send a response data-message. The networked system includes a plurality of banking servers, a plurality of client machines and a central server all connected by a network. The method involves receiving request data-messages, sending response data-messages, and maintaining and updating a data record.

Description

BANKING SERVER, NETWORKED SYSTEM AND METHOD

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to of U.S. Patent Application No. 61/671 ,475 filed July 13, 2012, the contents of which are incorporated herein by reference.

FIELD [0002] The present specification relates generally to servers, and more particularly to servers maintaining data records.

BACKGROUND

[0003] Electronic financial transactions are offered in many different contexts. Electronic platforms use technical resources in order to effect these electronic financial transactions. Ongoing optimization of the hardware and software resources of electronic platforms has the technical effect of reducing loads on those hardware and software resources, and at the same time leading to an overall improvement in quality of fulfillment of those electronic transactions, such quality being indicated by speed (e.g. reduced network latency), efficiency (e.g. reduced processing resources on a central processing unit, reduced electronic memory consumption), accuracy (e.g. the actual quoted value for a given item is correct) and the like.

[0004] While electronic financial transactions offer many advantages, it has also had the result of making financial markets extremely complex and fast moving, with the ability to move huge amounts of capital in less than a second. This can lead to an effective lack of transparency for unsophisticated consumers of financial services, as extremely sophisticated professionals can be required to understand and utilize financial markets. One example of where such a lack of transparency can arise is in relation to markets for short term borrowing such as banker's acceptances. In particular, the determination of baseline interest rates for short term borrowing can be particularly complex. Non-limiting examples of short term baseline interest rates are reflected by the London Interbank Offered Rate (LIBOR), Euro Interbank Offered Rate (Euribor), Tokyo Interbank Offered Rate (TIBOR), London Interbank Bid Rate (LIBID), Mumbai Inter-Bank Offer Rate (MIBOR), Johannesburg Interbank Agreed Rate (JIBAR), Sterling OverNight Index Average (SONIA) or the Canadian Dealer Offered Rate (CDOR). Such rates generally involve conducting a survey of posted submitted by certain dealers who are known market makers in an economy. While it can be easy to combine the posted rates, the determination of the posted rate by each individual dealer is often complicated and time consuming.

[0005] For example, CDOR rates are set at a predetermined time (10:30am, Eastern Time) with the input of nine Canadian Dealers who independently submit their levels each business day for the terms of 1 month, 2 month, 3 month, 6 month, and 1 Year banker's acceptances. In the CDOR, the highest and lowest are removed with a median calculated from the resultant pool of 7 remaining values.

[0006] Although the accuracy and fairness of the posted versions of rates can be well monitored by sophisticated financial institutions, these rates are also used by commercial borrowers to operate their business. Such commercial borrowers can lack the inside information and expertise to verify the accuracy of the posted version of these rates, while a sophisticated financial institution is more likely to have such information and expertise. This imbalance of knowledge can lead to situations where market manipulation can occur.

[0007] For example, the CDOR can be manipulated by having two Canadian Dealers collude to submit artificially high rates knowing that only one will be knocked out. Similarly, two Canadian Dealers can collude to submit artificially low rates knowing that only one will be knocked out. In addition, Canadian Dealers can maliciously decide to not change the rates due to inputs being held stale and submitted day after day at previously submitted levels instead of changing with the market to reflect changing market conditions.

[0008] Recent allegations against some banks for knowingly submitting inaccurate actual figures during the credit crisis provide a further example of the types of market manipulation that can occur. Therefore, the lack of market transparency, or even the perception of such lack of transparency, can have deleterious effects.

SUMMARY

[0009] In accordance with an aspect of the specification, there is provided a banking server for processing data-messages. The banking server includes a network interface in communication with a network. The banking server also includes a processor in communication with the network interface. The processor is configured to receive a request data-message from a plurality of client machines via the network. The processor is further configured to send a response data-message via the network. The request data-message includes a request for a banker's acceptance. The response data-message is configured for updating a baseline banker's acceptance rate at a central server.

[0010] The processor can be further configured to send the response data-message to a client machine of the plurality of client machines from which the request data-message was received.

[0011] The response data-message can include a response data field representing a response to the request for a banker's acceptance.

[00 2] The processor can be further configured to indicate whether the request is approved using a Boolean value stored in the response data field.

[0013] The processor can be further configured to represent a quantity of funds requested by the request data-message using a quantity data field.

[0014] The processor can be further configured to represent a repayment deadline requested by the request data-messages using a deadline data field.

[0015] The processor can be further configured to represent an interest rate based on the baseline banker's acceptance rate requested by the request data-messages using a rate data field representing.

[0016] The request data-message can be directed at the banking server.

[0017] The processor can be further configured to receive a rate data-message via the network. The rate data-message can include the baseline banker's acceptance rate.

[0018] The response data-message can be configured to update a data record on the central server.

[0019] In accordance with an aspect of the specification, there is provided a networked system for processing data-messages. The networked system includes a plurality of banking servers connected to a network. Each of the banking servers is configured to receive request data-messages from the network and to generate response data-messages for delivery over the network. The networked system further includes a plurality of client machines connected to the network. Each of the client machines is configured to generate the request data-messages for delivery over the network to at least one of the banking servers. The request data-messages include requests for a banker's acceptance. The networked system also includes a central server connected to the network and configured to maintain a data record storing a baseline banker's acceptance rate. The central server is configured to update the baseline banker's acceptance rate based on the response data-messages.

[0020] The plurality of banking servers can be configured to deliver one of the response data-messages to a client machine of the plurality of client machines from which an associated request data-message was received.

[0021] Each of the response data-messages can include a response data field representing a response to the request for a banker's acceptance.

[0022] The response data field can include a Boolean value for indicating whether the request is approved by a banking server of the plurality of banking servers.

[0023] Each of the request data-messages can include a quantity data field representing a quantity of funds requested.

[0024] Each of the request data-messages can include a deadline data field representing a repayment deadline.

[0025] Each of the request data-messages can include a rate data field representing an interest rate based on the baseline banker's acceptance rate.

[0026] Each of the request data-messages can be sent to one banking server of the plurality of banking servers.

[0027] Each of the request data-messages can be sent to each banking server of the plurality of banking servers.

[0028] The central server can be further configured to generate a rate data-message for delivery over the network to the plurality of banking servers and to the plurality of client machines. The rate data-message can include the baseline banker's acceptance rate.

[0029] The central server can be configured to update the baseline banker's acceptance rate by extracting interest rates from at least two of the response data-messages and by calculating a normalization of the interest rates.

[0030] The central server can be configured to update the baseline banker's acceptance rate by further writing a result of the normalization to the data record.

[0031] The central server can be configured to update the baseline banker's acceptance rate periodically.

[0032] In accordance with an aspect of the specification, there is provided a method for processing data-messages. The method involves receiving, at a plurality of banking servers, request data-messages from a plurality of client machines via a network, the request data- messages comprising requests for a banker's acceptance. The method further involves sending, from the plurality of banking server, response data-messages via the network. The method also involves maintaining, at a central server, a data record storing a baseline banker's acceptance rate. In addition, the method involves updating the baseline banker's acceptance rate based on the response data-messages.

[0033] The method can involve sending one of the response data-messages to a client machine of the plurality of client machines from which an associated request data-message was received.

[0034] Each of the response data-messages can include a response data field representing a response to the request for a banker's acceptance.

[0035] The method can further involve indicating whether the request is approved by a banking server of the plurality of banking servers using a Boolean value stored in the response data field.

[0036] The method can further involve representing a quantity of funds requested by each of the request data-messages using a quantity data field.

[0037] The method can further involve representing a repayment deadline requested by each of the request data-messages using a deadline data field.

[0038] The method can further involve representing an interest rate based on the baseline banker's acceptance rate requested by each of the request data-messages using a rate data field representing.

[0039] The method can further involve receiving comprises receiving a directed request data-message at one banking server of the plurality of banking servers.

[0040] The method can further involve sending, from a client machine of the plurality of client machines, identical request data-messages to each banking server of the plurality of banking servers.

[0041] The method can further involve generating a rate data-message for delivery over the network to the plurality of banking servers and to the plurality of client machines, the rate data- message comprising the baseline banker's acceptance rate.

[0042] Updating can involve extracting interest rates from at least two of the response data- messages, and calculating a normalization of the interest rates.

[0043] Updating can involve writing a result of the normalization to the data record.

[0044] Updating can involve updating the baseline banker's acceptance rate periodically.

BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Reference will now be made, by way of example only, to the accompanying drawings in which:

[0046] Figure 1 is a schematic of a system in accordance with an embodiment;

[0047] Figure 2 is a flow chart of a method for processing data messages in accordance with an embodiment;

[0048] Figure 3 is a schematic of the system shown in Figure 1 carrying out a step of the method shown in Figure 2;

[0049] Figure 4 is a schematic of the system shown in Figure 1 carrying out another step of the method shown in Figure 2;

[0050] Figure 5 is a schematic of the system shown in Figure 1 shown a function of a server in accordance with an embodiment;

[0051] Figure 6 is a schematic of the system shown in Figure 1 carrying out a step of a method in accordance with another embodiment;

[0052] Figure 7 is a flow chart of a method for processing data messages in accordance with another embodiment;

[0053] Figure 8 is a schematic of the system shown in Figure 1 carrying out a step of a method in accordance with another embodiment;

[0054] Figure 9 is a schematic of the system shown in Figure 1 carrying out a step of a method in accordance with another embodiment;

[0055] Figure 10 is a schematic of the system shown in Figure 1 carrying out a step of a method in accordance with another embodiment; and

[0056] Figure 11 is a schematic of a plurality of connected systems in accordance with an embodiment.

DETAILED DESCRIPTION OF THE EMBODIMENTS [0057] Referring now to Figure 1 , a system for networking to update a baseline banker's acceptance rate is generally shown at 50. It is to be understood that the system 50 is purely exemplary and it will be apparent to those skilled in the art that a variety of systems are contemplated. The system 50 includes a plurality of banking servers 54-1 , 54-2, 54-3, and 54-4. [Generically, banking server 54, and collectively banking servers 54. This nomenclature is used elsewhere herein]. The system 50 also includes a plurality of client machines 58-1 , 58-2, 58-3, and 58-4, and a central server 62 interconnected by a network 66.

[0058] In the present embodiment, each of the plurality of client machines 58 can be any type of computing device that can be used to communicate with a banking server 54. For example, each client machine 58 can be a personal computer, a laptop computer, a portable electronic device, a mobile computing device, portable computing device, a tablet computing device, a laptop computing device, a desktop phone, a personal digital assistant, a cellphone, a smartphone or the like. In the present embodiment, each client machine 58 is configured to send a data-message to comprising a request for a banker's acceptance from a banking server 54. A banker's acceptance is a future payment accepted and guaranteed by a banking institution and based on a deposit at the bank. Therefore, each client machine 58 is configured to generate a request data-message over the network 66 to a banking server 54 for requesting a banker's acceptance. In particular, the request data-message includes data fields representing a request for a quantity of funds, a repayment date, and an interest rate. In the present embodiment, the interest rate is based on a baseline banker's acceptance rate calculated by the central server 62. Alternatively, the baseline banker's acceptance rate used by the client machine 58 can be London Interbank Offered Rate (LIBOR), the Canadian Dealer Offer Rate (CDOR), or some other rate based on the LIBOR or CDOR. In other embodiments, the baseline banker's acceptance rate can be generated by the client machine 58 and based on other criteria or a combination of several criteria. [0059] Although the present embodiment describes requests for a banker's acceptance, it is to be understood that the client machine 58 can be modified to perform other transactions with the banking servers 54. [0060] In the present embodiment, each banking server 54 can be any type of computing device associated with a bank. For example, the banking servers 54 can include high performance server systems such as HP BladeSytem servers having a plurality of ProLiant server blades. Another example of servers can include the Sun Fire V480 (Sun Microsystems, Inc.) running a UNIX operating system, and having four central processing units each operating at about 900 megahertz and having about four gigabytes of random access memory and a nonvolatile storage device such as a hard disc drive. Alternatively, the banking servers 54 can include desktop personal computers configured to carry out similar functions. It is to be appreciated that a banking institution is not limited to a single banking server and the banking institution can be associated with more than one banking server of the plurality of banking servers 54. In some embodiments, more than one banking institution can also be associated with a single banking server such as the banking server 54-1 so that the banking institutions can share resources. Furthermore, in some embodiments, each of the banking servers 54 can also function as a client machine to send request data-messages to other banking servers.

[0061] Each banking server 54 has a processor and a network interface (not shown) for communicating with the network 66. The processor of each banking server 54 is generally configured to receive the request data-message from a client machine 58. Furthermore, the banking server 54 is configured to generate a response data-message for delivery over the network 66, via the network interface. In the present embodiment, when the request data- message is received from the client machine 58-1 , the response data-message is sent over the network 66 to at least one of the client machines 58-1 and the central server 62. In the present embodiment, the response data-message includes a data field representing a response to the request from the client machine 58-1. The response includes a Boolean diary field with a binary value (or another structural equivalent) indicating whether the banking server 54 has approved (ie. accepted) or denied the request for a banker's acceptance from the client machine 58-1. It is to be appreciated that although a Boolean data field is used in the present embodiment, any other type of data field capable of distinguishing an approved banker's acceptance from a denied banker's acceptance can be used. Furthermore, the response data-message also includes a data field representing an interest rate if the banker's acceptance is approved. The determination of whether to approve or deny the request for a banker's acceptance from the client machine 58-1 is not particularly limited. For example, the determination can be based on whether the interest rate in the request data-message is within a threshold value associate with a baseline banker's acceptance rate. In other embodiments, the response can also include a rate data field representing a different interest rate from the interest rate associated with the request data-message. The different interest rate can include a variation on the interest rate associated with the request data-message which represents a counteroffer from the banking server 54 to the client machine 58-1.

[0062] In the present embodiment, the central server 62 can be any type of computing device including but not limited to the computing environments mentioned above in relation to banking servers 54 and client machines 58. The central server 62 is generally configured to maintain at least a data record 70 representing a list of interest rates, where each interest rate corresponds to the interest rate of an approved banker's acceptance. (Examples of such interest rates of approved banker's acceptances are discussed below in relation to the contents of data field 128). In addition, the central server 62 is also configured to generate a rate data- message. (To provide more understanding, a specific, but not limiting example of a rate data- message is discussed below in relation to Figure 5 as indicated at reference character 140). The rate data-message can be delivered over the network 66 to the plurality of banking servers 54 and the plurality of client machines 58. The rate data-message 140 includes a calculated baseline banker's acceptance rate, which can be used by the plurality of banking servers 54 and the plurality of client machines 58 as discussed below.

[0063] Each client machine 58 can be configured to utilize the calculated baseline banker's acceptance rate in the rate data-message 140 is to be to generate a request data-message 100 according to local predetermined policies on each client machine 58. (Examples of such calculated baseline banker's acceptance rate are discussed below in relation to the contents of data field 144).

[0064] Similarly, each banking server 54 can be configured individually to utilize the calculated baseline banker's acceptance rate in the rate data-message to determine of whether to approve or deny a request for a banker's acceptance in the request data-message. The determination of whether to approve or deny the request is not particularly limited and based on predetermined local policies stored on each banking server. For example, a banking server 54 can make the determination base solely on the calculated baseline banker's acceptance rate relative to a predetermined threshold value. In another example, a banking server 54 can use the calculated baseline banker's acceptance rate in combination with other factors such as such as a credit rating associated with the client machine 58. In yet another example, a banking server 54 can disregard the calculated baseline banker's acceptance rate and use other predetermined factors.

[0065] In general terms, it will now be understood that the calculated baseline banker's acceptance rate in the rate data-message is provided to the banking servers 54 and the client machines 58, but actual determination as to how to use the calculated baseline banker's acceptance rate in the rate data-message is based on local policies of the individual client machines 58 and banking servers 54.

[0066] In other embodiments, the central server 62 may not be configured to send a rate data-message to each banking server 54 and each client machine 58. Instead the central server 62 can respond to individual requests from any banking server 54 or client machine 58 requesting the calculated baseline banker's acceptance rate. In further embodiments, the central server 62 can also be configured to automatically send a rate data-message to specific predetermined banking servers 54 and client machines 58 such as ones having a subscription to a service.

[0067] The procedure for generating the rate data-message is not particularly limited. In the present embodiment, the central server 62 is configured to extract the interest rate from each response data-message sent over the network 66 that indicates the approval of a request for a banker's acceptance. The central server 62 then calculates a normalized rate from interest rates sent over the network 66 over a period of time to calculate a banker's acceptance rate. In the present embodiment, the period of time is about 24 hours; however other embodiments can include periods of time greater or less than about 24 hours. Furthermore, it is to be appreciated that as the period of time is reduced, the information in the rate data-message will approach an approximate "real time" value. The normalized banker's acceptance rate is set as the calculated baseline banker's acceptance rate and subsequently sent by the central server 62 over the network 66 to the plurality of banking servers 54 and the plurality of client machines 58 in the rate data-message. The normalization procedure is not particularly limited and that several different calculation operations are contemplated. For example, the normalization procedure can include calculating a simple average of all interest rates received from each response data- message sent from a banking server 54 to a client machine 58 that indicates the approval of a request for a banker's acceptance. Alternatively, the normalization procedure can include calculating a mean, weighted average, excluding values that exceed pre-determined boundary conditions or other statistical amount.

[0068] In general terms, the system 50 is configured to generate calculated baseline banker's acceptance rates to be used within the system to facilitate the negotiation of financial transactions. However, it is to be re-emphasized that the structure shown in Figure 1 is a schematic, non-limiting representation. For example, although four banking servers are shown in Figure 1 , it is to be understood that the system 50 can be modified to include any number of banking servers greater or less than four. Furthermore, it is also to be understood, that the number of banking servers can be changed or varied during operation of the system 50. Similarly, although four client machines are shown in Figure 1 , it is to be understood that the system 50 can be modified to include any number of client machines greater or less than four. Furthermore, it is also to be understood, that the number of client machines can be changed or varied as new clients are added to the system 50 or removed from the system.

[0069] Referring now to Figure 2, a method for generating and updating calculated baseline banker's acceptance rates is represented in the form of a flow-chart and indicated generally at 500. In order to assist in the explanation of the method 500, it will be assumed that method 500 is performed using system 50, though expressed from the operating perspective of one of the banking servers 54. Furthermore, the following discussion of method 500 will lead to further understanding of system 50 and its various components. However, it is to be understood that system 50 and/or method 500 can be varied, and need not work exactly as discussed herein in conjunction with each other, and that such variations are within the scope of the present invention. Furthermore, it is to be emphasized, that method 500 need not be performed in the exact sequence as shown and that various blocks can be performed in parallel rather than in sequence; hence the elements of the method 500 are referred to herein as "blocks" rather than "steps".

[0070] Prior to commencing block 510, it is presumed that client machines 58 and servers 54 have all received an initial calculated baseline banker's acceptance rate from central server 62.

[0071] Block 510 comprises receiving a request for a banker's acceptance. Referring to Figure 3, a schematic representation of a non-limiting example performance of block 510 being carried out using system 50 is shown. A request data-message 100 is generated by the client machine 58-1 and sent to the banking server 54-1 via the network 66. In the present embodiment, the request data-message 100 includes a data field 104 representing a request for a quantity of funds, a data field 108 representing a repayment date, and a data field 112 representing an interest rate. The values in the data field 104, data field 108 and data field 112 are not particularly limited and can be selected based on the type of banker's acceptance desired by an account holder operating the client machine 58-1. For example, if the client machine 58-1 is used to generate a data-message comprising a request for a banker's acceptance of $100,000 that need not be repaid for three months, the data field 104 is populated with the value $100,000 and the data field 108 is populated with a value representing a date three months from the date of the request. In the present embodiment, the interest rate populated in the data field 112 is based on the calculated baseline banker's acceptance rate previously received from the central server 62. In other embodiments, the baseline banker's acceptance rate used by the client machine 58-1 can be the LIBOR, the CDOR, or some other rate based on other overnight lending rates, or combinations thereof. In further embodiments, the value populated in the data field 112 can be generated by the client machine 58-1 based on other criteria or a combination of various criteria.

[0072] Block 520 comprises determining whether to approve the request for a banker's acceptance from the client machine 58-1 as received at block 510. In system 50, block 520 is effected by the banking server 54-1 which is configured to use the values represented by the data fields 104, 108, and 112 to determine whether to approve or deny the request at block 510. In general, if the values represented by the data fields 104, 108, and 112 are acceptable, the method 500 advances to block 530. In general, if the values represented by the data fields 104, 108, and 112 are unacceptable, the method 500 advances to block 540. In the present embodiment, the banking server 54-1 analyzes the values represented by the data fields 104, 108, and 112 and, optionally, in combination with other data available to the banking server 54- 1. For example, the other data can include a credit score associated with an account associated with the client machine 58-1 that sent the request received at block 510, or a limit on the size or repayment date associated with that account. In addition, the banking server 54-1 can be configured to analyze the value represented by the data field 112 to determine if it is acceptable based on a threshold variance from on the calculated baseline banker's acceptance rate as previously received from the central server 62. In other embodiments, the threshold amount can be based on the LIBOR and/or the CDOR. In further embodiments, the threshold amount can be generated by the banking server 54-1 based on other criteria.

[0073] It is to be re-emphasized that the schematic shown in Figure 3 is a non-limiting example. For example, although the present embodiment shows the client machine 58-1 sending the request data-message 100 to the banking server 54-1 via the network 66, other embodiments can involve modifying the system 50 such that the client machine 58-1 sends the request data-message 100 to more than one banking server 54. Therefore, it is to be appreciated that the request data-message 100 can be directed to specific banking server such as 54-1 and 54-2. Alternatively, the request data-message 100 can also be sent to all of the banking servers 54. In embodiments where the request data-message 100 is sent to more than one banking server, it is to be appreciated that each banking server that receives the request data-message carries out block 520. It will now be appreciated that in this embodiment an electronically implemented market place for overnight lending is created as the first banking server 54 indicating an approval of a banker's acceptance would be used to actually effect the overnight lending transaction.

[0074] Block 530 comprises approving the request for a banker's acceptance as outlined in the request data-message 100. Referring to Figure 4, a schematic representation of an example performance of block 530 in conjunction with block 550 (described below) being carried out by system 50 is shown. A response data-message 120 is generated by the banking server 54-1 and sent to the client machine 58-1 via the network 66. The response data- message 120 includes a data field 124 representing a response to the request for a banker's acceptance under the terms provided in the request data-message 100. In the present embodiment, the data field 124 is a Boolean data field having a binary value indicating that the request for a banker's acceptance has been approved.

[0075] In contrast to block 530, block 540 comprises denying the request for a banker's acceptance as outlined in the request data-message 100. While no example of a denial is shown in the figures, according to block 540, a response data-message 120 is generated by the banking server 54-1 and sent to the client machine 58-1 via the network 66. The response data-message 120 includes a data field 124 representing a response to the request for a banker's acceptance under the terms provided in the request data-message 100. In the present embodiment, the data field 124 is a Boolean data field having a binary value indicating that the request for a banker's acceptance has been denied. After block 540 is completed, the method 500 advances to block 560 without sending the response data-message 120 to the central server 62.

[0076] Returning again to the approval branch, block 550 follows block 530 and comprises sending response data-message 120 to the central server 62 as well. Referring again to Figure 4, a response data-message 120 is generated by the banking server 54-1 and sent over the network 66 to the central server 62. The response data-message 120 includes a data field 128 representing an interest rate for an approved banker's acceptance. In the present embodiment, the data field 128 is populated with a value equal to the value of data field 112 of the request data-message 100 since the banking server 54-1 does not alter the interest rate. The central server 62 stores the interest rate in the data record 70.

[0077] In other embodiments, the banking server 54-1 can alter the interest rate such that a different interest rate from the interest rate is populated in the data field 112 from the interest rate populated in the data field 128. It is to be appreciated, with the benefit of this specification, that in this embodiment where the interest rates populated in the data field 112 and the data field 128 are different, the banking server 54-1 is generating a data-message that includes a counter offer for the terms of the request data-message 100 from block 510. In turn, the client machine 58-1 is configured to generate a further data-message indicating an approval or denial of the counter offer data-message. Furthermore, in other embodiments, the client machine 58-1 can generate a further data-message with another response to the counter offer and the process can be repeated until an approval or final denial is reached. Although communication between the banking server 54-1 and the client machine 58-1 is discussed in this variation, it is to be understood that the system 50 can be modified to include messages between any banking server 54 and any client machine 58 and that the counter offers can be sent to a different client machine, such as the client machine 54-2, or a plurality of client machines.

[0078] In the present embodiment, all the response data-messages 120 with a data field 124 representing an approved banker's acceptance are sent to the central server 62. It is to be appreciated that in other embodiments, some of the response data-messages 120 with a data field 124 representing an approved banker's acceptance are not forwarded to the central server 62 and that the central server 62. By not sending every response data-message 120 with a data field 124 representing an approved banker's acceptance, fewer network resources will be used. Therefore, in systems where a significantly large number of banker's acceptances are approved, sending a portion of the response data-messages 120 with a data field 124 representing an approved banker's acceptance can still provide an accurate baseline banker's acceptance rate. For example, a portion of response data-messages can be randomly selected to provide a statistical sample.

[0079] Furthermore, it is contemplated that similar or substantially identical response data- messages 120 can be sent over the network 66 and received by the central server 62 and the client machine 58-1. Therefore, the response data-message 120 is simultaneously sent to both the central server 62 and the client machine 58-1 from the banking server 54-1. By using the same type of data-message, the resources used by the banking server 54-1 are reduced since fewer messages of different types are generated. However, it is to be appreciated that the reduction in resources used by the banking server 54-1 is balanced against the technical resource consumptions, such as the size of the response data-message 120. For example, the client machine 58-1 does not require the information populated in the data field 128. Similarly, it is to be understood, with the benefit of this description, that the central server 62 does not require the information populated in the data field 124 in the present embodiment since only response data-messages 120 with the value indicating the approved banker's acceptance actually result in the response data-message 120 being sent to central server 62.

[0080] Block 560 comprises determining whether a period of time has expired for the interest rates sent over that period of time. In the present embodiment, the period of time is about 24 hours; however other embodiments can include periods of time greater or less than about 24 hours. The determination is made by the central server 62 using an internal countdown clock (not shown) that is reset for each period. The procedure for determining whether the period of time has expired is not particularly limited to the procedure described in this embodiment and several variations are contemplated. For example, the period can be synchronized to the time of a clock (not shown), or manually defined for each period. In general, if a determination is made that the period of time has not expired, the method 500 returns to block 510. However, if a determination is made that the period of time has expired, the method 500 advances to block 570.

[0081] Block 570 comprises normalizing all the interest rates stored on the data record 70 of the central server 62 to generate and update a baseline banker's acceptance rate. In the present embodiment, the calculation of the baseline banker's acceptance rate is not particularly limited and that several different operations are contemplated. For example, the calculation can include determining a simple average of all interest rates stored in the data record 70. The calculated baseline banker's acceptance rate is then stored in the data record 70. Alternatively, the calculation can include calculating a mean, weighted average, or other statistical amount. Other normalization calculations will now occur to the person skilled in the art.

[0082] For example, a 91 day banker's acceptance rate can be calculated based on a single source of clearing data. In the present example, the calculation can be based on market weighted value traded banker's acceptance yields for all instruments over 89, 90 and 91 day terms. It is to be appreciated, with the benefit of this specification, that using three separate days for valuing the trade is advantageous because it would capture late reporting of trades, which can commonly be up to two or three days late. Furthermore, it Is to be appreciated that the 91 day banker's acceptance rate described in this example cannot be skewed as it is based upon observable trades that have taken place. In the present embodiment, the vast majority of these trades are placements of newly issued banker's acceptances which further serves to eliminate opportunities for collusion. In contrast, Canadian Dealers can use open market trades on existing issues to determine rates submitted for CDOR which can lead to further collusion since open market trades on existing issues do not reflect the current market conditions for a banker's acceptance.

[0083] Although the present embodiment discloses a single source of clearing data across the entire marketplace, it is to be appreciated with the benefit of this description that this method can be applied to marketplaces with more than one source of clearing data. However, marketplaces with a single source would provide a more accurate baseline banker's acceptance rate when compared with marketplaces have multiple sources of clearing data since a better sample of banker's acceptances can be collected.

[0084] In the present embodiment, the calculated normalized banker's acceptance rate is set as a new calculated baseline banker's acceptance rate. The calculated baseline banker's acceptance rate is sent by the central server 62 over the network 66 to the plurality of banking servers 54 and the plurality of client machines 58 in a rate data-message. Referring to Figure 5, a schematic representation of a performance of block 570 being carried out by system 50 is shown. In the present embodiment, the rate data-message 140 is generated by the central server 62 and sent to the plurality of banking servers 54 and the plurality of client machines 58 via the network 66. The rate data-message 140 includes a baseline data field 144 representing the calculated baseline banker's acceptance rate. After the performance of block 570, the method 500 returns to block 510 where the calculated baseline banker's acceptance rate populated in the data field 144 can be used by the plurality of banking servers 54 and the plurality of client machines 58 for subsequent requests for banker's acceptances.

[0085] Again, it is to be re-emphasized that the method 500 described above is a non- limiting representation. For example, although the present embodiment shows the client machine 58-1 sending the request data-message 100 to the banking server 54-1 via the network 66, it is to be appreciated that the request data-message 100 can also originate from any one of the other client machines 58-2, 58-3, of 58-4. Furthermore, the request data- message 100 can also be sent to any one of the other banking servers 54-2, 54-3, and 54-4. Referring to Figure 6, another variation can involve modifying the system 50 such that the client machine 58-1 sends the request data-message 100 to more than one banking server. In particular, identical request data-messages 100 can be simultaneously sent from the client machine 58-1 to all of the banking servers 54. Furthermore, it is also to be understood that the client machine 58-1 is merely used in this exemplary embodiment, and the steps described above by the client machine 58-1 can be carried out instead by any one of the other client machines 58-2, 58-3, or 58-4.

[0086] Referring now to Figure 7, a method in accordance with another embodiment generating calculated baseline banker's acceptance rates is represented in the form of a flowchart and indicated generally at 600. In order to assist in the explanation of the method 600, it will be assumed that method 600 is performed using system 50. Furthermore, the following discussion of method 600 will lead to further understanding of system 50 and its various components as well as various methods that can be carried out on the system 50. It is to be emphasized, that method 600 need not be performed in the exact sequence as shown and that various blocks can be performed in parallel rather than in sequence; hence the elements of the method 600 are referred to herein as "blocks" rather than "steps".

[0087] Block 610 comprises receiving a request for a banker's acceptance. Referring to Figure 8, a schematic representation of a performance of block 610 being carried out by system 50 is shown. In the present embodiment, a request data-message 100 is generated by the client machine 58-1 and sent to the central server 62 via the network 66 and subsequently to the banking server 54-1. The request data-message 100 includes a data field 104 representing a request for a quantity of funds, a data field 108 representing a repayment date, and a data field 112 representing an interest rate. The values populated in the data field 108 are not particularly limited and can be selected based on the type of banker's acceptance desired by the client machine 58-1. In the present embodiment, the interest rate populated in the data field 112 is based on a baseline banker's acceptance rate previously calculated by the central server 62. Furthermore, it is to be appreciated that by sending the request data-message 100 to the central server 62 from the client machine 58-1 instead of directly to the banking server 54-1 , the central server 62 can keep a log all requests made.

[0088] Block 620 comprises the banking server 54-1 receiving the request data-message 100 and using the values populated in the data fields 104, 108, and 112 to determine if the request for a banker's acceptance from the client machine 58-1 is acceptable. The manner in which the determination is made is not particularly limited and includes methods similar to those of block 520.

[0089] It is to be emphasized that the schematic shown in Figure 8 is a non-limiting representation. For example, although the present embodiment shows the client machine 58-1 sending the request data-message 100 to the banking server 54-1 via the central server 62 through the network 66, other embodiments can involve modifying the method 600 such that the central server 62 subsequently sends the request data-message 100 to more than one banking server 54. In embodiments where the request data-message 100 is sent to more than one banking server 54, it is to be appreciated that each banking server 54 that receives the request data-message carries out block 620.

[0090] Block 630 comprises approving the request for a banker's acceptance as outlined in the request data-message 100. Referring to Figure 9, a schematic representation of a performance of block 630 carried out by system 50 is shown. A response data-message 120 is generated by the banking server 54-1 and sent to the central server 62 via the network 66 and subsequently to the client machine 58-1. The response data-message 120 includes a data field 124 representing a response to the request for a banker's acceptance under the terms provided in the request data-message 100. In the present embodiment, the data field 124 is a Boolean data field having a binary value indicating that the request for a banker's acceptance has been approved.

[0091] Block 640 comprises denying the request for a banker's acceptance as outlined in the request data-message 100. A response data-message 120 is generated by the banking server 54-1 and sent to the central server 62 via the network 66 and subsequently to the client machine 58-1. The response data-message 120 includes a data field 124 representing a response to the request for a banker's acceptance under the terms provided in the request data- message 100. In the present embodiment, the data field 124 is a Boolean data field having a binary value indicating that the request for a banker's acceptance has been denied. It is to be appreciated that by sending the response data-message 120 to the central server 62 from the bank server 54-1 instead of directly to the client machine 58-1 , the central server 62 can keep a log all responses.

[0092] Block 650 comprises storing the rate of the response data-message 120 to the central server 62 if the data field 124 represents that the request for a banker's acceptance has been approved. The response data-message 120 includes a data field 128 representing an interest rate for a banker's acceptance. In the present embodiment, the data field 128 is populated with a value equal to the value of data field 112 of the request data-message 100 since the banking server 54-1 does not alter the interest rate. However, in embodiments where the banking server 54-1 can alter the interest rate, a different interest rate can be populated in the data field 128. The central server 62 stores the interest rate in the data record 70. In this present embodiment, the central server 62 stores the value populated in the data field 112 if the data field 124 represents that the request has been approved. In other embodiments, the central server can be modified to store all values of every request data-message 100 and response data-message 120.

[0093] Block 660 comprises determining whether a period of time has expired for the calculation of a normalization of all interest rates sent over the period of time. The determination is not particularly limited and includes the methods similar to those of block 560.

[0094] Block 670 comprises determining normalizing all the interest rates stored on the data record 70 of the central server 62. The determination is not particularly limited and includes the methods similar to those of block 570.

[0095] Variations are contemplated. For example, although the embodiment shown in Figure 8 depicts a single request data-message 100 generated by the client machine 58-1 and ultimately sent to the banking server 54-1 , it is to be understood that the embodiment is purely exemplary and it will be apparent to those skilled in the art that a variety of different methods of sending request data-messages 100 are contemplated. For example, as shown in Figure 10, a first request data-message 100 can be generated by the client machine 58-1 and sent to the central server 62 while a second request data-message 102 can be generated at approximately the same time by the client machine 58-2 and sent to the central server 62. The central server can subsequently send both the first request data-message 100 and the second request data- message 102 to each of the plurality of banking servers 54. It is to be appreciated that this effectively creates a lending exchange where each banking server 54 can view several requests for a banker's acceptance. Although two request data-messages 100 and 102 are shown in Figure 10, it is to be appreciated that the number of request data-messages received by the central server is not limited.

[0096] Referring to Figure 11 , an application of a plurality of systems 50-1 , 50-2, 50-3, and 50-4 for networking to update a baseline banker's acceptance rate is shown generally at 700. Each system 50-1 , 50-2, 50-3, and 50-4 of the plurality of systems is connected to a master server 710 and configured to send a baseline banker's acceptance rate to the master server 710. The master server 710 is generally configured to receive a baseline banker's acceptance rate from each system 50-1 , 50-2, 50-3, and 50-4. Therefore, it is to be appreciated, with the benefit of the above disclosure, that the master server 710 can be used to select the optimal system 50 for a banking server or client machine to make a banker's acceptance in embodiments where each banking server and client machine has access to multiple systems 50. In addition, the master server 710 can collect baseline banker's acceptance rates from the systems 50-1 , 50-2, 50-3, and 50-4 to generate a master baseline banker's acceptance rate based on data from more than one system. [0097] Although four systems 50-1 , 50-2, 50-3, and 50-4 are shown in Figure 11 , it is to be understood that variations are contemplated. For example, the plurality of systems 50-1 , 50-2, 50-3, and 50-4 can be modified to include any number of systems greater or less than four. Furthermore, it is also to be understood, that the number of systems can be changed or varied during operation.

[0098] In a variation, if no banker's acceptances have traded on a given day then other data can be used to determine a banker's acceptance rate. For example, in the case of CDOR, then the Bankers Acceptance level can be determined by taking the spread of the respective term (30, 60, 90, 180, 1 Year) for the calculated level yesterday (last business day) over the respective (30, 60, 90, 180, 1 Year) Traded Canada Treasury Bill (T-Bill) rate yesterday and applying that spread to the Traded Canada Treasury Bill for today, i.e. if there are no Bankers Acceptances at the given term traded today then the Traded Bankers Acceptance level for today is taken by calculating the spread (90 Day DEX Traded Bankers Acceptance minus the 91 Day Traded Canada T-bill) say 16bps and applying that spread (16bps) to the 91 Day Traded Canada T-bill rate for today. This figure can be calculated, tracked and utilized when the Traded Bankers Acceptance level cannot be determined due to the lack of traded Bankers Acceptances on the day in question. The person of skill in the art will now recognize that similar alternatives can be used for LIBOR and other overnight rates.

[0099] Various advantages arise from the present specification. At least one advantageous technical effect for certain embodiments includes the fact that the data-messages relating to banker's acceptances are processed in a substantially closed loop fashion, thereby normalizing and standardizing the processing resources of the various client machines and banking servers. A further technical effect is that there is greater technical accuracy in the reporting of the daily banker's acceptance rate. A further incidental advantage is greater financial transparency. These advantages are illustrated in part in Schedule "1", which is a representative sample of such positive effects. Schedule "1" shows a table, listed by date (Column "A") juxtaposing the prior art (Column "B", showing actual published CDOR data for that date) with normalized rates that would have been determined by central server 62 (column "C") if the present specification had been employed on those dates. The difference (shown in column "D") which illustrates differences between Column "A" and Column "B". Positive differences in Column "D" reflects errors that results in unnecessary extra financial costs borne by operators of client machines 58.

[00100] While specific embodiments have been described and illustrated, such embodiments should be considered illustrative only and should not serve to limit the accompanying claims.

Claims

What is claimed is:

1. A banking server for processing data-messages, the banking server comprising a network interface in communication with a network; and a processor in communication with the network interface, the processor configured to receive a request data-message from a plurality of client machines via the network, to send a response data-message via the network, wherein the request data-message comprises a request for a banker's

acceptance, and wherein the response data-message is configured for updating a baseline banker's acceptance rate at a central server.

2. The banking server of claim 1 , wherein the processor is further configured to send the response data-message to a client machine of the plurality of client machines from which the request data-message was received.

3. The banking server of claim 1 , wherein the response data-message comprises response data field representing a response to the request for a banker's acceptance.

4. The banking server of claim 3, wherein the processor is further configured to indicate whether the request is approved using a Boolean value stored in the response data field.

5. The banking server of claim 1 , wherein the processor is further configured to represent a quantity of funds requested by the request data-message using a quantity data field.

6. The banking server of claim 1 , wherein the processor is further configured to represent a repayment deadline requested by the request data-messages using a deadline data field.

7. The banking server of claim 1 , wherein the processor is further configured to represent an interest rate based on the baseline banker's acceptance rate requested by the request data-messages using a rate data field representing.

8. The banking server of claim 1 , wherein the request data-message is directed at the banking server.

9. The banking server of claim 1 , wherein the processor is further configured to receive a rate data-message via the network, the rate data-message comprising the baseline banker's acceptance rate.

10. The banking server of claim 9, wherein the response data-message is configured to update a data record on the central server.

1 1.A networked system for processing data-messages, the networked system

comprising: plurality of banking servers connected to a network, each of the banking servers configured to receive request data-messages from the network and to generate response data-messages for delivery over the network; a plurality of client machines connected to the network, each of the client machines configured to generate the request data-messages for delivery over the network to at least one of the banking servers, the request data- messages comprising requests for a banker's acceptance; and a central server connected to the network and configured to maintain a data record storing a baseline banker's acceptance rate, the central server configured to update the baseline banker's acceptance rate based on the response data-messages.

12. The networked system of claim 1 1 , wherein the plurality of banking servers is configured to deliver one of the response data-messages to a client machine of the plurality of client machines from which an associated request data-message was received.

13. The networked system of claim 11 , wherein each of the response data-messages comprises a response data field representing a response to the request for a banker's acceptance.

14. The networked system of claim 13, wherein the response data field comprises a Boolean value for indicating whether the request is approved by a banking server of the plurality of banking servers.

15. The networked system of claim 1 1 , wherein each of the request data-messages comprises a quantity data field representing a quantity of funds requested.

16. The networked system of claim 1 , wherein each of the request data-messages comprises a deadline data field representing a repayment deadline.

17. The networked system of claim 11 , wherein each of the request data-messages comprises a rate data field representing an interest rate based on the baseline banker's acceptance rate.

18. The networked system of claim 1 1 , wherein each of the request data-messages is sent to one banking server of the plurality of banking servers.

19. The networked system of claim 1 1 , wherein each of the request data-messages is sent to each banking server of the plurality of banking servers.

20. The networked system of claim 1 , wherein the central server is further configured to generate a rate data-message for delivery over the network to the plurality of banking servers and to the plurality of client machines, the rate data- message comprising the baseline banker's acceptance rate.

21 . The networked system of claim 1 , wherein the central server is configured to update the baseline banker's acceptance rate by extracting interest rates from at least two of the response data-messages, and by calculating a normalization of the interest rates.

22. The networked system of claim 21 , wherein the central server is configured to update the baseline banker's acceptance rate by writing a result of the

normalization to the data record.

23. The networked system of claim 11 , wherein the central server is configured to update the baseline banker's acceptance rate periodically.

24. A method for processing data-messages, the method comprising: receiving, at a plurality of banking servers, request data-messages from a plurality of client machines via a network, the request data-messages comprising requests for a banker's acceptance; sending, from the plurality of banking server, response data-messages via the network to a central server; maintaining, at the central server, a data record storing a baseline banker's acceptance rate; updating, at a central server, the baseline banker's acceptance rate based on the response data-messages.

25. The method of claim 24, wherein sending comprises sending one of the response data-messages to a client machine of the plurality of client machines from which an associated request data-message was received.

26. The method of claim 24, wherein each of the response data-messages

comprises a response data field representing a response to the request for a banker's acceptance.

27. The method of claim 26, further comprising indicating whether the request is approved by a banking server of the plurality of banking servers using a Boolean value stored in the response data field.

28. The method of claim 24, further comprising representing a quantity of funds

requested by each of the request data-messages using a quantity data field.

29. The method of claim 24, further comprising representing a repayment deadline requested by each of the request data-messages using a deadline data field.

30. The method of claim 24, further comprising representing an interest rate based on the baseline banker's acceptance rate requested by each of the request data- messages using a rate data field representing.

31. The method of claim 24, wherein receiving comprises receiving a directed

request data-message at one banking server of the plurality of banking servers.

32. The method of claim 24, further comprising sending, from a client machine of the plurality of client machines, identical request data-messages to each banking server of the plurality of banking servers.

33. The method of claim 24, further comprising generating a rate data-message for delivery over the network to the plurality of banking servers and to the plurality of client machines, the rate data-message comprising the baseline banker's acceptance rate.

34. The method of claim 24, wherein updating comprises extracting interest rates from at least two of the response data-messages, and calculating a normalization of the interest rates.

35. The method of claim 34, wherein updating comprises writing a result of the

normalization to the data record.

36. The method of claim 24, wherein updating comprises updating the baseline

banker's acceptance rate periodically.