Patent Application
20200186609
While costs associated with computers and memory storage products have been falling, with technological improvements, available computing resources of organizations remain at a premium. For example, as businesses increasing move towards electronic communications, electronic processing of business processes, and electronically monitoring these communications and business processes, memory usage and computing processing power needs increase accordingly. In many cases, computing centers tasked with implementing and maintaining the discussed electronic communications and business processes are constrained by existing or aging hardware and software resources, budgetary concerns regarding the purchase, upgrade, or repair of the hardware and software infrastructure components. This may be true for large or small business organizations. In an illustrative example, a large organization may have many clients engaging in large numbers of electronic transactions, the details of which may be stored in memory. In many cases, these electronic transactions may occur continually and/or concurrently with electronic transactions with multiple other clients. As such, memory storage requirements may increase to a predefined limit, such that computing resources may be depleted, before additional resources may be added to the system. Additionally, the data stored may be communicated between computing systems for processing. These communication requirements may result in slowed communications capability, as communication bandwidth on an organizations network may be finite, regardless of how much data must be communicated. As such, a need has been recognized for improved data management capabilities, in storage capacity and transmission bandwidth management, while maintaining desired parameters of the underlying data.
Systems and methods are described for reducing memory storage and communication bandwidth requirements by compressing data based on the underlying stored information. A memory management computing device may be programmed to monitor a size of a plurality of data structures stored in a data repository. The computing device may compare the size of each of a plurality of data structures to a predetermined threshold. When a size of an uncompressed data structure meets the threshold, the memory management computing device may calculates a value of a first compression parameter based on a value of a first parameter and a value of a second parameter of each data element of the uncompressed data structure, calculate a value of a second compression parameter based the value of the first parameter of each data element of the uncompressed data structure, and generate a compressed data structure based on the value of the first compression parameter and the second compression parameter. The memory management computing device may replace, in the data repository, the uncompressed data structure with the compressed data structure.
In an illustrative example, a data repository associated with a financial institution may store thousands of data structures, each having up to ten thousand data elements, where each data structure stores electronic information associated with a different portfolio and each line item of a particular data structure may correspond to an electronic transaction associated with the portfolio. In some cases, the financial institution may be required to store a record of each electronic transaction to meet one or more regulatory requirements. As such, as the number of electronic transactions increases, particularly for institutional trading firms, may exceed an allowable memory allocation size in a relatively short time. In some cases, the electronic data structures corresponding to electronic portfolios may be synchronized over a network between two or more computing systems one or more times a day. In some cases, synchronization may be performed on a real-time (or near real-time) basis. In such cases, synchronizing thousands of portfolios, each including thousands of transactions, may cause communication traffic to slow, particularly during periods of high communication traffic. By actively monitoring a size of each portfolio data structure, memory usage may be proactively managed to minimize memory usage requirements and limit manpower and equipment costs in installing, testing, and activating additional storage devices. Similarly, communications delays may be minimized through actively managing the size of the data structures communicated and/or synchronized between different computing systems. Through active management of data structure size, communication times and/or delays may be minimized proportionally.
The details of these and other embodiments of the present disclosure are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will be apparent from the description and drawings.
The present invention may take physical form in certain parts and steps, embodiments of which will be described in detail in the following description and illustrated in the accompanying drawings that form a part hereof, wherein:
Illustrative Operating Environment
Aspects of at least some embodiments can be implemented with computer systems and computer networks that allow users to communicate trading information. An exemplary trading network environment for implementing trading systems and methods according to at least some embodiments is shown in
Computer system 100 can be operated by a financial product exchange and configured to perform operations of the exchange for, e.g., trading and otherwise processing various financial products. Financial products of the exchange may include, without limitation, futures contracts, options on futures contracts (“futures contract options”), and other types of derivative contracts. Financial products traded or otherwise processed by the exchange may also include over-the-counter (OTC) products such as OTC forwards, OTC options, etc.
Computer system 100 receives orders for financial products, matches orders to execute trades, transmits market data related to orders and trades to users, and performs other operations associated with a financial product exchange. Exchange computer system 100 may be implemented with one or more mainframe, desktop or other computers. In one embodiment, a computer device uses one or more 64-bit processors. A user database 102 includes information identifying traders and other users of exchange computer system 100. Data may include user names and passwords. An account data module 104 may process account information that may be used during trades. A match engine module 106 is included to match prices and other parameters of bid and offer orders. Match engine module 106 may be implemented with software that executes one or more algorithms for matching bids and offers.
A trade database 108 may be included to store information identifying trades and descriptions of trades. In particular, a trade database may store information identifying the time that a trade took place and the contract price. An order book module 110 may be included to store prices and other data for bid and offer orders, and/or to compute (or otherwise determine) current bid and offer prices. A market data module 112 may be included to collect market data, e.g., data regarding current bids and offers for futures contracts, futures contract options and other derivative products. Module 112 may also prepare the collected market data for transmission to users. A risk management module 134 may be included to compute and determine a user's risk utilization in relation to the user's defined risk thresholds. An order processor module 136 may be included to decompose delta based and bulk order types for further processing by order book module 110 and match engine module 106.
A clearinghouse module 140 may be included as part of exchange computer system 100 and configured to carry out clearinghouse operations. Module 140 may receive data from and/or transmit data to trade database 108 and/or other modules of computer system 100 regarding trades of futures contracts, futures contracts options, OTC options and contracts, and other financial products. Clearinghouse module 140 may facilitate the financial product exchange acting as one of the parties to every traded contract or other product. For example, computer system 100 may match an offer by party A to sell a financial product with a bid by party B to purchase a like financial product. Module 140 may then create a financial product between party A and the exchange and an offsetting second financial product between the exchange and party B. As another example, module 140 may maintain margin data with regard to clearing members and/or trading customers. As part of such margin-related operations, module 140 may store and maintain data regarding the values of various contracts and other instruments, determine mark-to-market and final settlement amounts, confirm receipt and/or payment of amounts due from margin accounts, confirm satisfaction of final settlement obligations (physical or cash), etc. As discussed in further detail below, module 140 may determine values for performance bonds associated with trading in products based on various types of currency pairs.
Each of modules 102 through 140 could be separate software components executing within a single computer, separate hardware components (e.g., dedicated hardware devices) in a single computer, separate computers in a networked computer system, or any combination thereof (e.g., different computers in a networked system may execute software modules corresponding more than one of modules 102-140).
Computer device 114 is shown directly connected to exchange computer system 100. Exchange computer system 100 and computer device 114 may be connected via a Ti line, a common local area network (LAN) or other mechanism for connecting computer devices. Computer device 114 is shown connected to a radio 132. The user of radio 132 may be a trader or exchange employee. The radio user may transmit orders or other information to a user of computer device 114. The user of computer device 114 may then transmit the trade or other information to exchange computer system 100.
Computer devices 116 and 118 are coupled to a LAN 124. LAN 124 may implement one or more of the well-known LAN topologies and may use a variety of different protocols, such as Ethernet. Computers 116 and 118 may communicate with each other and other computers and devices connected to LAN 124. Computers and other devices may be connected to LAN 124 via twisted pair wires, coaxial cable, fiber optics, radio links or other media.
A wireless personal digital assistant device (PDA) 122 may communicate with LAN 124 or the Internet 126 via radio waves. PDA 122 may also communicate with exchange computer system 100 via a conventional wireless hub 128. As used herein, a PDA includes mobile telephones and other wireless devices that communicate with a network via radio waves.
One or more market makers 130 may maintain a market by providing constant bid and offer prices for a derivative or security to exchange computer system 100. Exchange computer system 100 may also include trade engine 138. Trade engine 138 may, e.g., receive incoming communications from various channel partners and route those communications to one or more other modules of exchange computer system 100.
One skilled in the art will appreciate that numerous additional computers and systems may be coupled to exchange computer system 100. Such computers and systems may include, without limitation, additional clearing systems (e.g., computer systems of clearing member firms), regulatory systems and fee systems.
The operations of computer devices and systems shown in
Of course, numerous additional servers, computers, handheld devices, personal digital assistants, telephones and other devices may also be connected to exchange computer system 100. Moreover, one skilled in the art will appreciate that the topology shown in
In some cases, the remote computer system 240 may include one or more of a data repository 242, a computer device 244 and/or a user interface 246. The remote computer system 240 may be communicatively coupled to at least one additional computer system via the network 505. In some cases, the remote computer system 240 may be configured to obtain information about one or more of the data structures 222, process the information to compress a plurality of data elements 232 of the data structures 222, 230 and communicate information about the compressed data structures (e.g., data structure 235 to remote computing systems to reduce memory requirements associated with storing the data structures 222, 230, and 235 while additionally reducing communication times and/or communications delays associated with communicating such information In some cases, the data repository computing device 220 and/or the remote computer system 240 may be communicatively coupled to one or more additional computing systems (not shown). In some cases, the one or more additional computing systems may communicate (e.g., synchronize) data structure information to and/or from the data repository computing device 220, the remote computer system 240 or both.
In some cases, the remote computing system 240 may monitor a size of each of the plurality of data structures 222 and 230, where the size of the data structure may correspond to the number of data elements of each data structure (e.g., the number of data elements 232 of data structure 230). In some cases, the remote computing system may compare the size of each data structure 222 and 230 to a pre-defined threshold. In some cases, the size of each data structure may be compared to a same threshold or each data structure may be assigned a different threshold based on characteristics of a user, business organization, or data stored in the data structure. For example, the threshold may be 100 data elements, 1,000 data elements, 10,000 data elements or the like. In many cases, the remote computing system may be used to manage memory requirements for a large number of data structures stored on one or more different computing devices.
In some cases, the remote computing system 240 may process a rule set to perform a data compression algorithm based on information stored in the data structure to be compressed. For example, one or more parameters of each data elements 232 may be used in a data compression algorithm such that a plurality of data elements may be compressed to fewer data elements (e.g., 0, 1, 2, etc.). In first step of an illustrative compression algorithm, a value of a first parameter may be used to calculate a first weighting parameter for each data element, where the weighting parameter may be used to compute a weighted value of a second parameter for each data element in a second step. In a third step, a weighted compression parameter may be computed, such as a sum of the weighted value of the second parameter for each of the plurality of data elements of the data structure. In a fourth step, a second compression parameter may be calculated, such as a sum of the unweighted second parameter. In a fifth step, a first data element of a compressed data structure (e.g., 235) may be generated based on information of the original data elements 232 of the uncompressed data structure (e.g., data structure 232). For example, values of each third parameter for each of the data elements 232 may be compared to determine the maximum value and the minimum value. This value may be assigned to the associated parameter of the first data element of the compressed data structure 235 and a second parameter may be calculated as a function of the first compression parameter and the second parameter. In a sixth step, a second compressed data element may be generated using the lowest parameter and a difference between the second compression value and the first compression value. Once generated, the compressed data element 235 may be stored in the data repository 220 to replace the uncompressed data structure 230 and the uncompressed data structure 230 may be deleted.
In some cases, the clearinghouse module 140 may be configured to monitor and/or otherwise manage a capital obligation associated with a plurality of swaps, such as a swap portfolio such as by using the process discussed above with respect to
A data repository associated with a financial institution may store thousands of data structures, each having up to ten thousand data elements, each data element corresponding to a financial transaction (e.g., an interest rate swap, an interest rate swap in a foreign currency, and the like). Memory requirements for the financial institution may be reduced by reducing notional amount and/or clearing line items associated with portfolios of swaps that are on an organization's books. In some embodiments, a computer system may access data corresponding to a portfolio that comprises m interest rate swaps, wherein m is an integer greater than one. A financial institution managing the portfolio may have a first data storage capacity large enough to store information associated with the portfolio comprising m interest rate swaps. The accessed data may comprise multiple data components for each of the interest rate swaps, such as a notional value and a fixed rate value. Each of the interest rate swaps may correspond to a common tenor. The computer system may calculate parameters for a compressed swap having a risk value equivalent to a sum of risk values of the interest rate swaps. The parameters may include a compressed swap notional value, a compressed swap fixed rate value, and a compressed swap floating rate spread value. The computer system may optionally determine, based at least on part on the compressed swap parameters, a performance bond requirement attributable to the interest rate swaps. The computer system may compare a determined performance bond requirement to account data associated with a holder of the portfolio and may perform one or more additional actions based on the comparing.
A financial institution associated with the portfolio may have one or more computing systems (e.g., servers, data repositories, processors, etc.) that may be used, at least in part, to store or otherwise manage portfolios of the financial institution's clients. These financial institution computing systems may be sized to manage a specified amount of data associated with aspects of the financial institution's business. This may include managing and/or processing information associated with the portfolios. As portfolios become larger for one or more of the financial institution's clients, the data storage capacity and/or processing power necessary to process and/or store this information may approach a storage capacity and/or processing power limit of the currently installed hardware. As such, the financial institution may be required to install more computing devices and/or upgrade existing computing components to handle the additional information storage and/or processing requirements. By monitoring, or otherwise managing the size of one or more portfolios, the financial institution may proactively manage the computing requirements and the associated costs. For example, the financial institution may monitor a size of a client's portfolio. If the portfolio size approaches a threshold, the financial institution computing system may automatically initiate a portfolio compression process. In other cases, the financial institution computing system may provide an indication to an individual, such as a network manager, that the computing system is approaching the limits to allow manual initiation of a portfolio compression process.
In some cases, a method for reducing a notional amount and/or clearing line items associated with a portfolio of swaps may include determining at least a first fixed rate for use in blending a plurality of swaps. Each of the swaps may have matching economics and a different associated fixed rate. In some cases, the swaps may include non-matched data, such as different rates associated with different data elements. The method may further include determining, by one or more computing devices, a first remnant swap using the first fixed rate and determining a second remnant swap using a second fixed rate, wherein the second fixed rate is different from the first fixed rate.
In some cases, a non-transitory computer-readable medium may contain computer-executable instructions, that when executed by a processor, cause one or more computing devices to determine a first blend rate for use in blending a plurality of swaps. Each of the plurality of swaps may have matching economics and a different associated fixed rate. The instructions may further cause the one or more computing devices to determine a first remnant swap using the first blend rate and to determine a second remnant swap using the second blend rate to blend the plurality of swaps.
In some cases, a system for reducing notional amount and/or clearing line items associated with swaps that are on an organization's books may include a network and one or more computing devices. The computing devices may include a processor and one or more non-transitory memory devices storing instructions that, when executed by the processor, cause the one or more computing devices to determine a first blend rate and a second blend rate for use in blending a plurality of swaps. Each of the plurality of swaps may have matching economics and a different associated fixed rate. The instructions may further cause the one or more computing devices to determine a first remnant swap using the first blend rate and determine a second remnant swap using the second blend rate to blend the plurality of swaps together with first remnant swap. The one or more computing devices may then communicate, via the network, information corresponding to the first remnant swap and the second remnant swap to an institution associated with the plurality of swaps.
In some cases, a method for compressing a portfolio of swaps may be implemented by a computer device and include determining a fixed rate for use in blending a plurality of swaps, where each of the plurality of swaps may have matching economics and a different associated fixed rate. A computing device may further determine a blended swap for blending the plurality of swaps using the fixed rate, wherein a gross notional of the blended swap could be less than the gross notional amount for the plurality of swaps and/or reducing the number of clearing line items.
In some cases, stored data may include information corresponding to trading of one or more financial products. For example, over-the-counter (OTC) products include financial instruments that are bought, sold, traded, exchanged, and/or swapped between counterparties. Many OTC derivatives exist to fill a wide range of needs for counterparties, including limiting or mitigating exposure to risks and/or maximizing cash flow. After an exchange of an OTC product, counterparties may expend resources managing the product for the duration of its life. Management may be complicated based on the number of exchanges and/or the specific terms of the contract.
An interest rate swap (IRS) is an example of a type of OTC product where the parties agree to exchange streams of future interest payments based on a specified principal or notional amount. Each stream may be referred to as a leg. Swaps are often used to hedge certain risks, for instance, interest rate risk. They can also be used for speculative purposes.
An example of a swap includes a plain fixed-to-floating, or “vanilla,” interest rate swap. The vanilla swap includes an exchange of interest streams where one stream is based on a floating rate and the other interest stream is based on a fixed rate. In a vanilla swap, one party makes periodic interest payments to the other based on a fixed interest rate. In return for the stream of payments based on the fixed rate, the party may receive periodic interest payments based on a variable rate. The payments are calculated over the notional amount.
The variable rate may be linked to a periodically known or agreed upon rate for the term of the swap such as the London Interbank Offered Rate (LIBOR). This rate is called variable, because it is reset at the beginning of each interest calculation period to the then current reference rate, such as LIBOR published rate. The parties to an IRS swap generally utilize these exchanges to limit, or manage, exposure to fluctuations in interest rates, or to obtain lower interest rates than would otherwise be unobtainable.
Usually, at least one of the legs to a swap has a variable rate. The variable rate may be based on any agreed upon factors such as a reference rate, the total return of a swap, an economic statistic, etc. Other examples of swaps include total return swaps, and Equity Swaps.
The expiration or maturity of the future streams of payments may occur well into the future. Each party may have a book of existing and new IRSs having a variety of maturity dates. The parties may expend substantial resources tracking and managing their book of IRSs and other OTC products. In addition, for each IRS, the party maintains an element of risk that one of its counterparties will default on a payment.
Currently, financial institutions such as banks trade interest rate payments and/or interest rate swaps over the counter. Steams of future payments must be valued to determine a current market price. The market value of a swap is the sum of the difference between the present value of the future fixed cash flows and the floating rate and the price of the swap is determined based on the fixed rate. Because the fixed rate of a particular swap is determined based on the available fixed rate at the time the price is struck, the fixed rates associated with two different swaps will rarely be the same. As such, each swap that is struck causes a separate line item to be booked until an opposite swap with the same fixed rate is struck. As such, it would be desirable to provide a way to blend coupons for reducing notional amounts and/or line items (e.g., swaps) on a financial organization's books.
In some cases, clients may desire to enter into one or more swaps (e.g., interest rate swaps) for hedging a position in a market. For example, an organization may have multiple positions in fixed rate mortgages, while having less exposure to products associated with a floating rate. At such times, the organization may desire to enter into one or more swaps with another party to hedge risks that may be associated with having a majority of fixed rate products. For example, when interest rates fall, the organization may make money by having a majority of fixed rate products in a portfolio. However, when the market goes up (e.g., interest rates rise), the organization may lose the opportunity to profit from the higher interest rates. By hedging these risks, the parties to the interest rate swaps may have a goal to allow their assets and/or liabilities to at least remain near the starting levels and/or minimize any losses. Generally, an available fixed rate dictates the price of a swap, where the fixed rate available at the market changes over time. For example, a dealer may quote a swap at a first rate at a time 0. A short time later (e.g., about 10 minutes, about 30 minutes, etc.), the same dealer may provide a quote for a similar swap, but having a second rate that is different from the first rate. Once the swaps are entered, the fixed rate will remain fixed for the lifetime of the swap. Over time, a swap purchaser (e.g., an individual, an organization, a business, etc.) may develop a portfolio of swaps, including the swaps of at least one payer swap (e.g., providing the fixed rate leg of the swap) and/or at least one receiver swap (e.g., providing the floating rate leg of the swap). Few, if any, swaps may have the same interest rate resulting in a large number of swaps to remain open on the organization's books.
An organization or an individual may enter into multiple swaps during a given period (e.g., a day, a week, a month, etc.) and, as a result, may have multiple line items in their books in relation to these swaps. For example, a customer may have a first swap for paying a set amount (e.g., $100 million) and a second swap for receiving the same set amount (e.g., $100 million). Although these swaps are associated with the same notional amount, the interest rates are likely to be different. As such, these swaps will not net out. Rather, the $200 million remains open on the organization's books. These swaps may further be subject to regulatory requirements, such as governmental requirements, international banking requirements (e.g., BASEL 3 requirements), and/or the like. These regulatory requirements may subject the organization to capital charges (e.g., a specified cash reserve) to ensure that a financial organization has enough cash to cover their liabilities regarding their swap portfolio.
In an illustrative example, a financial institution may have a house account having a number of swaps open in the account. Under the regulatory requirements, the financial institution is required to set aside capital (e.g., a margin account) to cover the open swaps. This cash requirement may be dependent upon, at least in part, on the gross notional amount and/or the total clearing line items associated with the swap portfolio. As such, the financial organization can reduce its capital requirements by reducing the number of line items on their books, and/or by reducing the gross notional of the swap portfolio.
In some cases, multiple line items having the same interest rate may be collapsed together (e.g., canceled). For example, a pay swap having an associated first notional amount of may be offset by a second notional amount associated with a receive swap when the pay and receive swaps have the same interest rate. However, this is rare. For example, a swap participant may use an investment strategy for achieving the same fixed rate for two or more different swaps. In such cases, the customer may specify a desired rate for a swap when contacting a dealer. While the dealer may be able to find a counter-party willing enter into a swap at that rate, the swap may incur a fee to equalize the economics of the swap. For example, at the desired fixed rate, the economics of the swap may favor the paying party or the receiving party. By equalizing these differences, the swap may then be structured to allow the total value of the fixed rate leg to be equal to the floating rate leg of the swap. In general, when the interest rates are determined for the swaps, the precision may be specified by one or more parties to the swap. In some cases, the precision of the rates may be limited to a defined precision common to the market, such as about 2 decimal places, about 5 decimal places, up to 7 decimal places. In other cases, the rate precision may be specified to be a precision greater than 7 decimal places, such as 11 decimal places, up to 16 decimal places, etc.)
In some cases, a clearinghouse may monitor a portfolio of swaps to determine whether any of the total notional value of the swap portfolio may be canceled or otherwise offset. For example, the clearing house may, on a periodic (e.g., daily) basis, process an algorithm to determine a net value of a client's swap portfolio and send a message to the client to terminate a line item, or offset at least a portion of the gross notional value when two or more line items may be collapsed.
In the past, the over-the-counter swap market was largely a bespoke market, where a customer desiring to enter into a swap would contact, such as by telephone, one or more dealers to determine which dealer would offer the best price to enter into the deal. In such cases, the swap may be entered on a common platform, but the trade execution was completed by phone. Because swaps may not be fully transparent, governmental regulations have required that swaps be executed via a Swap Execution Facility (SEF). A SEF is a regulated platform for swap trading that provides pre-trade information, such as bids, offers, and the like, and/or an execution mechanism to facilitate execution of swap transactions among eligible participants. Over time more and more types of swaps may be executed via a SEF, such as interest rate swaps. Because the SEF may operate using a more automated swap market mechanism, the likelihood that a customer may enter into different swaps, where each share a same interest rate will become increasingly rare. A SEF may execute many swaps with multiple coupons at a centralized location. In some cases, different swaps may share the same, or similar, economics to another swap. However, the coupons are likely to differ due to the swaps executing at different times. As such, a client may quickly build a book (e.g., swap portfolio) with many swap line items, which, in turn, would require the client to incur a large capital obligation corresponding to the gross notional and/or the total clearing line items of the book of swaps.
Currently, the unilateral “risk-free” compression of stored data, such as those comprising Brazilian Real (BRL) CDI interest rate swaps (BRL swaps) is limited to standard netting, where the fixed rate on trades within a compression group must match. This problem will limit the line item and gross notional reduction that is possible, therefore not allowing for maximum compression of the stored data. The current disclosure discusses this problem, allowing the stored data to be adaptively compressed such as by compressing BRL swaps with differing fixed rates, increasing an amount of stored data (e.g. data corresponding to electronic trades) eligible for compression and, therefore, maximizing the reduction of consumed memory usage and/or allowing for more efficient use of bandwidth in communicating information about the stored data.
While some memory compression algorithms may utilize information stored in the data structures to be compressed, additional parameters and/or other requirements may be required. For example, other BRL swap compression solutions may either a) require the fixed rate to match on eligible trades and/or b) are multilateral solutions requiring the portfolios of 2+ trading participants to achieve reduction in line items or gross notional.
For stored data such as a portfolio of BRL Swaps, adaptive data compression algorithms, such as coupon blending, can be achieved by following the steps outlined below. The original stored data (e.g., the portfolio 222) will be reduced to a smaller stored data structure comprising two remnant trades, where the gross notional will also be reduced.
Step 1: Calculate the EXP Rate for each trade within the portfolio.
EXP Rate=(1+r){circumflex over ( )}n/252−1
Where:
EXP Rate=exponential weighting
r=fixed rate
n=Brazil business days in the accrual period
Step 2: Calculate the Weighted Notional (WN) for each trade within the portfolio based on a present value (PV) notional.
WN=PV Notional*EXP Rate
Where:
PV Notional (PVN)=Present Value Notional
Step 3: Calculate the Net Weighted Notional (NWN) of the portfolio
NWN=Σ(WN)
Step 4: Calculate the Net PV Notional (NPN)
NPN=Σ(PVN)
Step 5: Create BRL Swap Remnant 1 by assigning it the highest fixed rate of the original portfolio and calculating the PV Notional of Remnant 1 (PVR1).
PVR1=(NWN−NPN*e_min)/(e_max−e_min)
Where:
e_min=EXP rate of lowest fixed rate
e_max=EXP rate of highest fixed rate
Step 6: Create BRL Swap Remnant 2 by assigning it the lowest fixed rate of the original portfolio and calculating the PV Notional of Remnant 2 (PVR2).
PVR2=NPN−PVR1
BRL Swap coupon blending reduces operational risk and process times by decreasing the number of line items (trades) that a system must process, maintain and report without changing the cash flows of the original portfolio. The illustrative process may be used to compress the data structures to minimize memory usage associated with a plurality of stored portfolios. The described algorithm may also reduce the gross notional outstanding of eligible trades resulting in a decrease of capital that a Clearing Member Firm must hold against their cleared swap portfolio.
In some cases, the clearinghouse computer system 540 may include one or more of a data repository 542, a computer device 544 and/or a user interface 546. The clearinghouse computer system 540 may be communicatively coupled to at least one financial institution computer system, such as the financial institution computing system 510 via the network 505. In some cases, the clearinghouse computer system 540 may be configured to obtain information about one or more of the swap portfolios 522, process the information to blend coupons associated with the different swaps of the swap portfolios 522 and communicate information about the blended swaps to the financial institution computing system 510 to reduce one or more line items associated with the swap portfolios 522 and/or to reduce a gross notional value associated with the swap portfolios 522 to reduce memory requirements while additionally reducing a total capital charge incurred by the financial institution in relation to the swap portfolios 522.
The present invention has been described herein with reference to specific exemplary embodiments thereof. It will be apparent to those skilled in the art that a person understanding this invention may conceive of changes or other embodiments or variations, which utilize the principles of this invention without departing from the broader spirit and scope of the invention as set forth in the appended claims.
This application is a continuation under 37 C.F.R. § 1.53(b) of U.S. patent application Ser. No. 15/832,244 filed Dec. 5, 2017 (Attorney Docket No. 004672-17548Z-US)) now U.S. Pat. No. ______, which claims the benefit of the filing date under 35 U.S.C. § 119(e) U.S. Provisional Patent Application Ser. No. 62/491,040, filed Apr. 27, 2017, the entire disclosures of which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62491040 | Apr 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15832244 | Dec 2017 | US |
| Child | 16792973 | US |
