WO2014019051A1

WO2014019051A1 - Server and method for processing data records

Info

Publication number: WO2014019051A1
Application number: PCT/CA2012/000725
Authority: WO
Inventors: John George Bruce Mclean
Original assignee: Ftse Tmx Global Debt Capital Markets Inc.
Priority date: 2012-07-31
Filing date: 2012-07-31
Publication date: 2014-02-06

Abstract

A server and method for processing data records are provided. The method involves managing a plurality of data records, creating at least one new data record at a predetermined time, and sorting the plurality of data records at the predetermined time. Each data record includes a rate data field, a principal data field, and a date data field representing a maturity date. The rate data field of at least one data record represents a floating interest rate. The server includes a network interface, a memory storage unit and a processor for carrying out the method.

Description

SERVER AND METHOD FOR PROCESSING DATA RECORDS

FIELD

[0001] The present specification relates generally to servers and methods carried out by servers, and more particularly to processing data records.

BACKGROUND

[0002] Electronic financial transactions are offered in many different contexts and constantly evolving. 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 improved efficiency (e.g. reduced processing resources on a central processing unit, reduced electronic memory consumption), accuracy (e.g. the actual transactions are executed in the proper order with predictability) and the like.

[0003] In a particular application of electronic financial transactions, exchange-traded funds ("ETFs") are becoming more prevalent. ETF's are investment funds that trade on stock exchanges much like equities are traded on stock exchanges. Most ETFs are designed to hold assets to track an index or a particular investment strategy. For example, an ETF can hold a variety of financial instruments such as stocks and bonds in predetermined ratios. For example, bond-based ETFs can be designed to hold fixed-rate bonds with a range of maturities to track a yield curve as part of a bond ladder investment strategy where bonds are grouped into rungs with the bonds in each rung having similar maturity dates. One rung can hold bonds having maturity dates between 1 and 2 years, the next rung having bonds with maturity dates between 2 and 3 years, etc.

[0004] In order to manage the electronic financial transactions associated with ETFs, various data records and data structures are used to execute the transactions. Transactions often involve manipulating the data records in the data structures with each transaction. In general, different types of financial instruments can be characterized by different data records maintained in specific data structures. In the example relating to bond-based ETFs, data records can represent a financial instrument such as a bond for use in the bond ladder investment strategy. The data structures can be configured to store data records in various rungs or subsets of the entire set of data records.

[0005] Depending upon the goals of the electronic systems managing the ETF, the total market value represented by fields in the data records can be allocated between the data structures representing the rungs of the ladder according to a variety of schemes. The allocation can involve storing the data records in the various rung data structures. Each of the rung data structures is generally configured to have approximately the same value of financial instruments in each of the rung data structures to spread the risk and benefit of the yield curve. In other words, the bond ladder attempts to manage risks associated with bonds and/or to manage cash flow. In particular, the data structures representing the bond ladder manages the reinvestment risk by organizing the maturities of the bonds in the ladder such that a selected proportion of the data records represent bonds can mature in any given year. The capital from the maturing bonds can be reinvested into similar data records representing new bonds of a selected maturity date range to create new data records representing a new ladder rung data structure. Therefore, the reinvestment risk is managed since a portion of the data records will have associated interest rates at the time of the reinvestment. These data structures can also manage the flow of cash by selecting data records representing bonds having different coupon dates in each data structure so that coupon payments can be periodically provided as a payout (eg. a dividend paid by the ETF) or added to the capital.

[0006] Electronic systems managing bond-based ETFs having data records representing bonds are generally popular but suffer from a disadvantage in that, to date, such systems are generally configured to manage data records in accordance with a bond ladder investment strategy that use data records representing fixed-rate bonds. Such fixed-rate instruments do well when interest rates decrease but do not perform well when interest rates increase. Thus, in a market where interest rates are expected to rise, systems managing the bond-based ETFs will experience higher number of electronic financial transactions as investors rush to reduce their positions in bond-based ETFs. This can lead to increased burden on the technical resources maintaining the data records as an account associated with the ETF acts to reduce their investment in the ETF by reducing the number of data records associated with the account during periods of underperformance. SUMMARY

[0007] In accordance with an aspect of the specification, there is provided a method for processing data records on a server. The method involves managing a plurality of data records. Each data record includes a rate data field, a principal data field, and a date data field representing a maturity date. The rate data field of at least one data record represents a floating interest rate. The method further involves creating, at a predetermined time, at least one new data record. Creating the at least one new data record involves subtracting an amount represented by the principal data field of the at least one new data record from a balance record in a memory storage unit. The method also involves sorting the plurality of data records at the predetermined time.

[0008] Managing can involve storing each data record in the memory storage unit of the server. Managing can further involve maintaining the balance record in the memory storage unit. Managing can also involve deleting each data record at the maturity date. In addition, managing can involve adding the amount represented by the principal data field to the balance record at the maturity date of each data record.

[0009] Sorting can involve selecting a first subset of data records. The maturity date of each data record in the first subset can be within a predefined first range of dates. Sorting can also involve selecting a second subset of data records. The maturity date of each data record in the second subset can be within a predefined second range of dates. The second range can be adjacent to the first range.

[0010] The method can further involve selecting a third subset of data records. The maturity date of each data record in the second subset can be within a predefined third range of dates, the third range adjacent to the second range.

[0011] The predetermined time can be set to be on a specific date each calendar year.

[0012] The method can further involve calculating a payout amount associated with the plurality of data records.

[0013] The method can further involve transmitting the payout amount to a client machine.

[0014] The method can further involve adding the payout amount to a client machine.

[0015] In accordance with another aspect of the specification, there is provided a server for processing data records. The server includes a network interface. In addition, the server includes a memory storage unit for storing a plurality of data records and a balance record. Each data record includes a rate data field, a principal data field, and a date data field representing a maturity date. The rate data field of at least one data record represents a floating interest rate. The server also includes a processor in communication with the memory storage unit and the network interface. The processor is configured to create, at a predetermined time, at least one new data record. In addition, the processor is further configured to sort the plurality of data records at the predetermined time.

[0016] The processor can be further configured to delete each data record at the maturity date. Furthermore, the processor can be further configured to add the amount represented by the principal data field to the balance record at the maturity date of each data record.

[0017] The processor can be further configured to select a first subset of data records. The maturity date of each data record in the first subset can be within a predefined first range of dates. The processor can be further configured to select a second subset of data records. The maturity date of each data record in the second subset is within a predefined second range of dates. The second range can be adjacent to the first range.

[0018] The processor can be further configured to select a third subset of data records, wherein the maturity date of each data record in the second subset is within a predefined third range of dates. The third range can be adjacent to the second range.

[0019] The predetermined time can be set to be on a specific date each calendar year.

[0020] The processor can be further configured to calculate a payout amount associated with the plurality of data records.

[0021] The processor can be further configured to transmit the payout amount to a client machine.

[0022] The processor can be further configured to add the payout amount to a client machine.

[0023] In accordance with another aspect of the specification, there is provided a non- transitory computer readable medium encoded with codes. The codes are for directing a processor to manage a plurality of data records. Each data record includes a rate data field, a principal data field, and a date data field representing a maturity date. The rate data field of at least one data record represents a floating interest rate. Furthermore, the codes are for directing the processor to create, at a predetermined time, at least one new data record. Creating the at least one new data record comprises subtracting an amount represented by the principal data field of the at least one new data record from a balance record in a memory storage unit. In addition, the codes are for directing the processor to sort the plurality of data records at the predetermined time.

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0025] Figure 1 is a block diagram of the components of a server in accordance with an embodiment;

[0026] Figure 2 is a schematic representation of a data record in accordance with an embodiment;

[0027] Figure 3 is a flow chart of a method in accordance with an embodiment; and

[0028] Figure 4 is a flow chart of a method which is part of the method shown in Figure 3.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0029] Referring now to Figure 1 , a schematic block diagram of components of a server for processing data records is generally shown at 50. It is to be understood that server 50 is purely exemplary and it will be apparent to those skilled in the art that a variety of servers are contemplated. In the present embodiment, server 50 can be any type of computing device configured for processing data records. For example, server 50 can include high performance server systems such as HP Blade servers having a plurality of ProLiant server blades. Another example of a server is 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 non-volatile storage device such as a hard disc drive. Alternatively, server 50 can include a desktop personal computer configured to carry out similar functions for systems not requiring a server with significant processing power, such as when a relatively small number of data records are to be processed. In other embodiments, the server 50 can also be implemented as one or more virtual servers, or a rented server session in the cloud accessed through a network. [0030] As shown in Figure 1 , the server 50 includes a processor 54, a network interface 58, and a memory storage unit 62. The network interface 58 and the memory storage unit 62 are each in electrical communication with the processor 54.

[0031] The network interface 58 is not particularly limited and can include various network interface devices such as a network interface controller (NIC). In particular, the network interface 58 is generally configured to connect a network 66. For example, the network interface 58 can connect to the network 66 using a data link layer standard such as Ethernet, Wi-Fi, mobile network (such as, but not limited to, fourth generation (4G), third generation (3G), code division multiple access (CDMA), Groupe Special Mobile (GSM) or Long Term Evolution (LTE) standards, or Token Ring.

[0032] The memory storage unit 62 can be of any type such as non-volatile memory (e.g. Electrically Erasable Programmable Read Only Memory (EEPROM), Flash Memory, hard disk, floppy disk, optical disk, solid state drive, or tape drive) or volatile memory (e.g. random access memory (RAM)). Although the memory storage unit 62 is generally a type of non-volatile memory because of the robust nature of non-volatile memory, some embodiments can use volatile memory in situations where high access speed is desired. In the present embodiment, the memory storage unit 62 is a non-volatile memory unit storing a plurality of data records 100-1 , 100-2, and 100-3. (Generically, data record 100, and collectively data records 100. This nomenclature is used elsewhere herein). The data records 100 are configured to represent information associated with a financial instrument.

[0033] The memory storage unit 62 also stores a balance record 105. The balance record 105 is configured to represent an amount of available funds for applying to a principal when creating data records 100 representing financial instruments. In the present embodiment, when a data record 100 is created, the value stored in the balance record 105 can decrease by an amount associated with the price of a financial instrument represented by the data record created. Therefore, it is to be appreciated by a person of skill in the art, with the benefit of this description, that the creation of a data record 100 can represent a purchase of a financial instrument. Similarly, when data records 100 are deleted, the value stored in the balance record 105 can increase by an amount associated with the price of a financial instrument represented by the data record 100 deleted. Therefore, it is to be appreciated by a person of skill in the art, with the benefit of this description, that the deletion of a data record 100 can represent a sale or redemption of a financial instrument.

[0034] Referring to Figure 2, a schematic representation of a non-limiting example of a data record 100 is generally shown. In the present embodiment, the data record 100 includes information representing financial instrument providing income such as a fixed-rate bond or a floating rate note. The data record 100 includes a rate data field 101 an interest rate associated with the financial instrument. For example, if the data record 100 represents a fixed-rate bond, the rate data field 101 includes a value representing a fixed interest rate of the fixed-rate bond. In another example, if the data record 100 represents a floating rate note, the rate data field can include a value representing the interest rate of the floating rate note at a particular time. It is to be appreciated that if the data record 100 represents a floating rate note, the value of the rate data field 101 can be updated periodically when the interest rate associated with the floating rate note is adjusted.

[0035] In other embodiments of a data record 00 representing a floating rate note, the rate data field 101 can be populated with a fixed value to add or subtract to a reference interest rate stored in an additional data field (not shown). For example, the reference interest rate can be set as any one of the London Interbank Offered Rate (LIBOR), the Euro Interbank Offered Rate (Euribor), the Tokyo Interbank Offered Rate (TIBOR), the London Interbank Bid Rate (LIBID), the Mumbai Inter-Bank Offer Rate (MIBOR), the Johannesburg Interbank Agreed Rate (JIBAR), the Sterling OverNight Index Average (SONIA) or the Canadian Dealer Offered Rate (CDOR). In these embodiments, the rate data field 101 does not need to be constantly updated and the interest rate can be determined periodically according to a desired time interval in combination with the reference interest rate. Alternatively, the reference interest rate can instead be stored on the memory storage unit 62 of the server 50. Furthermore, it is to be appreciated by a person of skill in the art, with the benefit of this description, that the data field 101 can represent a marginal spread which is the credit spread attributed to the issuer over the reference interest rate.

[0036] In addition, data records 100 representing floating rate notes can include further data fields for storing information. For example, the data record 100 can include a data field representing the frequency of coupon payouts such an indication of monthly, quarterly, semiannual or annual payouts. As another example, the data record 100 can further include a data field identifying the issuer of the floating rate note for applications where the identity of the issuer is desirable. As another example, the data record 100 can also include a data field providing information related to the payout policies such as when the issuer provides a payout (e.g. a payout date, pay cycle details) and when the issuer provides the payout in the event of a holiday or weekend. [0037] In the present embodiment, the data record 100 represents either a fixed-rate bond or a floating rate note. It is to be appreciated that under certain conditions, a data record 100 representing a fixed rate bond can be selected over a floating rate note for achieving higher returns on investment. For example, if the interest rate for bonds is expected to drop, a bond having a fixed-rate set prior to a rate drop generally performs better than a floating rate note. Alternatively, if the interest rate for bonds is expected to increase, a floating rate note capable of increasing its interest rate generally performs better than a fixed rate note.

[0038] The data record 100 also includes a principal data field 102 representing the principal amount of a financial instrument. In the present embodiment, the principal amount is fixed and cannot be varied. It is to be appreciated now, with the benefit of this description, that the processor 54 can use the value in the principal data field 102 along with the value in the rate data field 101 to calculate a payout amount associated with the data record 100 at predetermined intervals. The payout amount can then be transmitted through the network 66 to client machines (not shown) to represent an electronic payment of funds. In other embodiments, the payout amount can be added to the balance record 105. It is to be appreciated that in this latter embodiment, the interest accrued from the financial instrument can be considered to be automatically re-invested.

[0039] In the present embodiment, the data record 100 also can include a date data field 103 representing a maturity date associated with the financial instrument. The maturity date represents the date when the data record 100 expires and can be deleted or otherwise removed from the memory storage unit 62 such the data record 100 is no longer maintained by the processor 54. Therefore, the date data field 103 represents the date on which the financial instrument is redeemed and that the principal amount is added back to the balance record 105. In other embodiments, the date data field 103 can be modified to be a counter variable which is incrementally decreased until the maturity date. For example, if the maturity date of the data record 100 is exactly one year away from a present time, the counter variable can have a value of three-hundred-and-sixty-five (in a non-leap year) which decreases with each passing day.

[0040] The values in the rate data field 101 , principal data field 102 and date data field 103 are not particularly limited and are populated based on the characteristics of the financial instrument represented by the data record 00. For example, if the data record 100 represents a fixed rate bond with a principal of $100,000 with an interest rate of 5% and a maturity date of January 1 , 2017, the rate data field 101 is populated with the value 5%, the principal data field 102 is populated with a value of $100,000, and the date data field 103 is populated with the value January 1 , 2017.

[0041] Referring back to Figure 1 , the processor 54 is generally configured to execute programming instructions 110 to process data records 100 and to send and receive data over the network 66 via the network interface 58. In the present embodiment, the programming instructions 110 configure the processor 54 to manage a plurality of data records 100, create a new data record, or sort the plurality of data records 100, as discussed in greater detail below. The programming instructions 110 are shown to be stored in a cache within the processor 54. It is to be appreciated that the storage of the programming instructions 110 is not limited and the programming instructions can be store in any computer readable medium. For example, the system 50 can be modified to store the programming instructions 110 in the memory storage unit 62. As another example, the programming instructions can also be stored in a separate memory storage unit (not shown).

[0042] In general terms, the server 50 is generally configured process data records representing financial instruments to the client device. However, it is to be re-emphasized that the structure shown in Figure 1 is a schematic, non-limiting representation. For example, although the present embodiment shown in Figure 1 includes the memory storage unit 62 for storing three data records 100-1 , 100-2, and 100-3, it is to be understood that the memory storage unit 62 can be modified to store more or less data records 100. In addition, it is also to be understood that the balance record 105 can be stored on an additional memory storage unit (not shown) such that it is separated from the data records 100. Furthermore, it is to be understood, with the benefit of this description, that several different types of financial instruments can be represented by the plurality of data records 100. Therefore each individual data record 100 can represent a different type of financial instrument such as a fixed-rate bond, a floating rate note, or asset backed securities.

[0043] Referring now to Figure 3, a method for processing data records on a server is represented in the form of a flow-chart and indicated generally at 200. In order to assist in the explanation of the method 200, it will be assumed that the programming instructions 110 configure the processor 54 of the server 50 to carry out method 200. Furthermore, the following discussion of the method 200 will lead to further understanding of the server 50 and its various components. However, it is to be understood that the server 50 and/or the method 200 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 200 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 200 are referred to herein as "blocks" rather than "steps".

[0044] Prior to commencing block 220, it is presumed that server 50 includes an initial plurality of data records 100 in the memory storage unit 62. The source of the initial plurality of data records 100 is not particularly limited. For example, the initial plurality of data records 100 can be predetermined by the programming instructions 110. In other embodiments, the programming instructions 110 can configure the processor 54 to create the initial plurality of data records 100 based on input received from the network interface 58. In other embodiments still, the server 50 can include an input device (not shown) for receiving input to create the initial plurality of data records 100.

[0045] Block 220 comprises managing a plurality of data records 100. The management of the plurality of data records 100 is not particularly limited and can include various functions associated with the plurality of data records 100. For example, the processor 54 can be configured to create new data records 100 representing the purchase of new financial instruments. Alternatively, managing the plurality of data records 100 can also involve deleting data records 00 that have matured.

[0046] Referring now to Figure 4, a non-limiting example of the execution of block 220 is shown. It is to be emphasized, the example shown in Figure 4 is a non-limiting example and that variations are contemplated. Furthermore, the blocks shown in Figure 4 not be performed in the exact sequence as shown and that various blocks can be performed in parallel or another order rather than in sequence.

[0047] Block 222 comprises storing a data record 100 in the memory storage unit 62. The manner in which data record 100 is stored is not particularly limited. The storing of the data record can involve using conventional writing techniques associated with the memory storage unit 62. In the present embodiment, the memory storage unit 62 is a non-volatile memory storage unit. Therefore, it is to be appreciated that storing the data record 100 is a passive process. In other embodiment, the memory storage unit can be modified to be a volatile memory storage unit. Therefore, when the memory storage unit is volatile, storing the data record 100 can involve taking steps to ensure the volatile memory does not lose power.

[0048] Block 224 comprises maintaining a balance record 105 in the memory storage unit 62 upon creating each data record. The manner in which the balance record 105 is maintained is not particularly limited and includes methods similar to those of block 222. In addition to storing the value represented by the balance record 105, the value of the balance record 105 can be added to or subtracted from. For example, when the data record is used to trigger generations of an electronic payout instruction amount as discussed above, the payout amount can be added to the balance record 105 in some embodiments.

[0049] Block 226 comprises deleting a data record 100 in the memory storage unit 62 at the maturity stored in the date data field 103. The manner in which data record 100 is deleted is not particularly limited. The deleting of the data record 100 can involve using conventional data handling techniques associated with the memory storage unit 62.

[0050] Block 228 comprises adding an amount stored in the principal data field 102 to the balance record 05 at the maturity date stored in the date data field 103. The manner in which the addition is carried out is not particularly limited and can involve standard computational techniques available on the processor 54.

[0051] In general terms, the execution of block 220 carries out the management of data record 100 from the creation to the deletion of the data record 100 in the memory storage unit 62. In the present embodiment, each data record 100 can be created if there balance record 105 represents a sufficient amount of available funds.

[0052] Again, it is to be re-emphasized that the execution of block 220 described above is a non-limiting representation. For example, it is to be appreciated, with the benefit of this description that blocks 222 and 224 can be carried out simultaneously. Similarly, blocks 226 and 228 can also be carried out simultaneously. Furthermore, it is to be understood that several executions of block 220 can occur simultaneously and in parallel for separate data records.

[0053] Returning to Figure 3, block 240 comprises creating at least one new data record 100 at a predetermined time. When the new data record 100 is created, an amount represented by the principal data field 102 of the data record 100 is subtracted from a balance record 105 in the memory storage unit 62.

[0054] The predetermined time is not particularly limited and can represent any time selected by the processor 54 based on local criteria. In the present embodiment, the predetermined time is set to be on a specific date each calendar year. Therefore, it is to be appreciated that new data records 100 are created once a year in this embodiment and that the period between each data record creation event is equal. In other embodiments, the predetermined time can lead to time periods greater or less than one calendar year. In other embodiments still, the predetermined time can lead to unequal time periods. [0055] As discussed above, each data record 100 of the present embodiment can be a fixed-rate bond or a floating rate note. In the present embodiment, the creation of new data records 100 results in at least one new data record. In instances where more than one data record 100 is created, then data records 100 created at the predetermined time are of the same type (e.g.. fixed-rate bond or floating rate note). Similarly, if the method 200 is repeated, the creation of new data records 100 at the subsequent predetermined time is also of the same type, although it can be of a different type from the previous predetermined time. Therefore, it is appreciated that the plurality of data records 100 can include both fixed-rate bonds and floating rate notes as each the new data records that are created can be of a different type from the existing data records which have not been deleted. Although the present embodiment contemplates the creation of multiple data records 100 to a single type, other embodiments can provide for the creation of multiple data records 100 that are divided between fixed-rate bonds and floating rate notes.

[0056] Block 260 comprises sorting the plurality of data records 100 at the predetermined time discussed above in connection with block 240. Therefore, it is to be appreciated that block 260 can be executed simultaneously with block 240 or shortly before or after the execution of block 240. The manner by which the plurality of data records 100 is sorted is not particularly limited and many variations are contemplated. In the present embodiment, a first subset of data records 100 are selected from the plurality of data records 100. The selection of the first subset involves examining the date data field 103 of each data record 100 to determine whether the maturity date of each data record 100 falls within a predefined range of dates. If a data record 100 meets this criteria, the data record is selected to be in the first subset of data records. Similarly, a second subset of data records 100 are selected from the plurality of data records 100. The selection of the second subset involves examining the date data field 103 of each remaining data record 100 not selected to be in the first subset to determine whether the maturity date of each data record 100 falls within a predefined range of dates for the second subset. If a data record 100 meets this criteria, the data record is selected to be in the second subset of data records. In the present embodiment, the range of dates associated with the first and second subsets of data records are adjacent to each other and each data record 100 of the plurality of data records fall within the first or second subset.

[0057] It is to be re-emphasized that the method 200 described above is a non-limiting representation. Furthermore, it is to be appreciated now with the benefit of this description that the method 200 can be continuously carried out by the server 50. For example, at the predetermined time, the server 50 can set another predetermined time after creating new data records 100 and sorting the data records. Therefore, the method 200 can loop indefinitely.

[0058] Variations are contemplated. For example, although the embodiment shown in Figure 3 depicts creating at least one new data record 100 at a predetermined time at block 240, it is to be understood that the embodiment is purely exemplary and it will be apparent to those skilled in the art the creation of data records is not limited to the predetermined time. For example, a new data record can be created immediately after the deletion of another record or when the balance record 105 reaches a threshold value. It is to be appreciated by a person of skill in the art, with the benefit of this description, that this example can represent an automatic re-investment of a financial instrument upon maturity.

[0059] As another example of a variation, although the embodiment shown in Figure 3 depicts sorting the plurality of data records into two subsets, it is to be understood that the embodiment is purely exemplary and it will be apparent to those skilled in the art that the number of subsets is not limited to two subsets. For example, other embodiment can include several subsets to simulate a ladder investment strategy involving various financial instruments in each rung of the ladder. Furthermore, it is to be appreciated that the predetermined range of dates used to establish each subset can vary. For, example, the range for each subset can be different or identical to the ranges for other subsets.

[0060] As yet another example of a variation, the server 50 can be modified to receive a market feed from the network 66 via the network interface 58. The market feed can include data configured to provide an indication in regard to an expected change in the interest rate. Therefore, the programming instructions 110 can be configured to further process the market feed data to automatically select whether to create data records 100 representing a fixed-rate bond or a floating rate note during the execution of block 240 using objective indicators.

[0061] Various advantages arise from the present specification. At least one advantageous technical effect for certain embodiments includes the fact that fewer manual manipulations of the data records are used to accommodate for changing market conditions and forecasts. Another advantage includes the ability to generate an index based on the payout amounts or interest rates of the financial instruments represented by the data records 100. The reduction in editing of the data records results in decreasing the demand for processing resources of the server. A further technical effect is that there is greater technical accuracy selection of data records based on using objective indicators. A further incidental advantage is greater financial transparency by using the objective indicators. [0062] 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 method for processing data records on a server, the method comprising: managing a plurality of data records, each data record having a rate data field, a principal data field, and a date data field representing a maturity date, wherein the rate data field of at least one data record represents a floating interest rate; creating, at a predetermined time, at least one new data record, wherein

creating the at least one new data record comprises subtracting an amount represented by the principal data field of the at least one new data record from a balance record in a memory storage unit; and sorting the plurality of data records at the predetermined time.

2. A method of claim 1 , wherein managing comprises: storing each data record in the memory storage unit of the server; maintaining the balance record in the memory storage unit; deleting each data record at the maturity date; and adding the amount represented by the principal data field to the balance

record at the maturity date of each data record.

3. A method of claim 2, wherein sorting comprises: selecting a first subset of data records, wherein the maturity date of each data record in the first subset is within a predefined first range of dates; and selecting a second subset of data records, wherein the maturity date of each data record in the second subset is within a predefined second range of dates, the second range adjacent to the first range.

4. The method of claim 3, wherein sorting further comprises selecting a third subset of data records, wherein the maturity date of each data record in the second subset is within a predefined third range of dates, the third range adjacent to the second range.

5. The method of claim , wherein the predetermined time is set to be on a specific date each calendar year.

6. The method of claim 1 , further comprising calculating a payout amount

associated with the plurality of data records.

7. The method of claim 6, further comprising transmitting the payout amount to a client machine.

8. The method of claim 6, further comprising adding the payout amount to a client machine.

9. A server for processing data records, the server comprising: a network interface; a memory storage unit for storing a plurality of data records and a balance record, each data record having a rate data field, a principal data field, and a date data field representing a maturity date, wherein the rate data field of at least one data record represents a floating interest rate; and a processor in communication with the memory storage unit and the network interface, the processor configured to create, at a predetermined time, at least one new data record, the processor further configured to sort the plurality of data records at the predetermined time.

10. The server of claim 9, wherein the processor is further configured to: delete each data record at the maturity date; and add the amount represented by the principal data field to the balance record at the maturity date of each data record.

11.The server of claim 10, wherein the processor is further configured to: select a first subset of data records, wherein the maturity date of each data record in the first subset is within a predefined first range of dates; and select a second subset of data records, wherein the maturity date of each data record in the second subset is within a predefined second range of dates, the second range adjacent to the first range.

12. The server of claim 11 , wherein the processor is further configured to select a third subset of data records, wherein the maturity date of each data record in the second subset is within a predefined third range of dates, the third range adjacent to the second range.

13. The server of claim 9, wherein the predetermined time is set to be on a specific date each calendar year.

14. The method of claim 9, wherein the processor is further configured to calculate a payout amount associated with the plurality of data records.

15. The method of claim 14, wherein the processor is further configured to transmit the payout amount to a client machine.

16. The method of claim 14, wherein the processor is further configured to add the payout amount to a client machine.

17. A non-transitory computer readable medium encoded with codes, the codes for directing a processor to: manage a plurality of data records, each data record having a rate data field, a principal data field, and a date data field representing a maturity date, wherein the rate data field of at least one data record represents a floating interest rate; create, at a predetermined time, at least one new data record, wherein

creating the at least one new data record comprises subtracting an amount represented by the principal data field of the at least one new data record from a balance record in a memory storage unit; and sort the plurality of data records at the predetermined time.