An equity total return swap (TRS) is a type of over the counter (OTC) financial product in which one party agrees to make periodic interest payments based on a floating reference interest rate that may change from time to time (e.g., the 3 month London Interbank Offered Rate, or “LIBOR”). The other party to the TRS agrees to make periodic payments, based on the performance of one or more stocks, that includes returns based on price movement of those stocks and dividends paid by issuers of those stocks. In many cases, the TRS is periodically “reset.” During such TRS resets, the floating rate used for calculating interest rate payments may be updated (e.g., to the current LIBOR). The notional value of the swap may also be updated based on the current value of the reference equity securities. In some TRSs, the parties may exchange payments at a reset.
Although useful for various economic goals, a TRS may have numerous drawbacks. Periodic processing of payments between the parties can be administratively burdensome. Moreover, negotiating the terms of a TRS can also be burdensome. For example, parties to a TRS may have a standardized set of terms governing all such swaps, e.g., an ISDA Master Agreement. Negotiating the terms of such an agreement can be time-consuming. For these and other reasons, there remains a need for other types of products that can mimic the economic character of a TRS.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the invention.
In at least some embodiments, a value for a carry-adjusted version of an economic index may be calculated. The calculation may include adjusting an equity component by a carrying cost component. The equity component may be based on a value of the economic index corresponding to the current time. The carrying cost component may be based on a carrying cost rate and a time period from the current time to a previous time. The calculation may be periodically reset to, e.g., reflect a new carrying cost rate. The carry-adjusted version of an economic index may be the underlying of a futures contract or other type of product. Any of numerous types of economic indices may provide a value on which an equity component is based. Examples of such indices include, without limitation, stock and other equity market indices, bond market indices, commodity market indices, etc. Similarly, a carrying cost rate could represent any of numerous types of carrying costs. Examples of such costs include, without limitation, interest rates indicative of funding costs, commodity storage costs, etc.
Embodiments include, without limitation, herein-described methods for processing data associated with carry-adjusted indices and/or futures contracts based on such indices, computer systems configured to perform such methods, and non-transitory computer-readable media storing instructions executable by a computer system to perform such methods.
Some embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.
In the following description of various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which various embodiments are shown by way of illustration. It is to be understood that there are other embodiments and that structural and functional modifications may be made. Embodiments of the present invention may take physical form in certain parts and steps, examples of which will be described in detail in the following description and illustrated in the accompanying drawings that form a part hereof.
Various embodiments may comprise a method, a computer system, and/or a computer program product. Accordingly, one or more aspects of one or more of such embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment, and/or an embodiment combining software and hardware aspects. Furthermore, such aspects may take the form of a computer program product embodied as one or more non-transitory computer-readable storage media having computer-readable program code, or instructions, stored in or on that media. The term “computer-readable medium” or “computer-readable storage medium” as used herein includes not only a single medium or single type of medium, but also a combination of one or more media and/or types of media. Such a non-transitory computer-readable medium may store computer-readable instructions (e.g., software) and/or computer-readable data (i.e., information that may or may not be executable). Any suitable computer readable media may be utilized, including various types of non-transitory computer readable storage media such as hard disks, CD-ROMs, optical storage devices, magnetic storage devices, FLASH memory, and/or any combination thereof. The term “computer-readable medium” or “computer-readable storage medium” could also include an integrated circuit or other device having hard-coded instructions (e.g., logic gates) that configure the device to perform one or more operations.
Aspects of method steps described in connection with one or more embodiments may be executed by one or more processors associated with a computer system (such as but not limited to exchange computer system 100 described below). As used herein, a “computer system” could be a single computer or could comprise multiple computers. When a computer system comprising multiple computers performs a method, various steps could be performed by different ones of those multiple computers. Processors of a computer system may execute computer-executable instructions stored on non-transitory computer-readable media. Embodiments may also be practiced in a computer system forming a distributed computing environment, with tasks performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Aspects of at least some embodiments can be implemented with computer systems and computer networks that allow users to communicate trading and other information. An exemplary trading network environment for implementing systems and methods according to 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 data relating to various financial products. In addition to carry-adjusted index futures contracts such as are described herein, financial products of the exchange may include, without limitation, futures contracts, options on futures contracts, other types of 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, OTC swaps, etc. Financial products traded through the exchange may also or alternatively include other types of financial interests, including without limitation stocks, bonds and/or other securities (e.g., exchange traded funds), foreign currencies, and spot market trading of commodities.
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 a 64-bit processor. 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 operations of a clearinghouse of the exchange that operates computer system 100. Module 140 may receive data from and/or transmit data to trade database 108 and/or other modules of computer system 100 regarding trades involving futures contracts and other financial products traded through the exchange that operates system 100. Clearinghouse module 140 may facilitate the financial product exchange (or a clearinghouse of the 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 futures contract, an option, a carry-adjusted index futures contract, or another exchange-traded financial product with a bid by party B to purchase a like exchange-traded financial product. Module 140 may then create an exchange-traded financial product between party A and the exchange clearinghouse and a second exchange-traded financial product between the exchange clearinghouse and party B. Module 140 may similarly create offsetting contracts when creating contracts as a result of an option exercise and/or may select option grantors to fulfill obligations of exercising option holders. Module 140 may also be configured to perform other clearinghouse operations. As a further example, module 140 may maintain performance bond data with regard to clearing members and/or trading customers. As part of such operations, module 140 may store and maintain data regarding the values of various futures contracts and other interests, determine mark-to-market and final settlement amounts, confirm receipt and/or payment of amounts associated with performance bond accounts, confirm satisfaction of delivery and other final settlement obligations, etc.
Exchange computer system 100 may include a CAI/CAIFC module 142. Module 142 may generate, store, and process data associated with one or more types of carry-adjusted index (CAI) and/or with one or more types of carry-adjusted index futures contract (CAIFC). Various operations performed by module 142 in at least some embodiments are further described below.
Each of modules 102 through 142 could be implemented as 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-142). When one or more of modules 102 through 142 are implemented as separate computers in a networked environment, those computers may be part of a local area network, a wide area network, and/or multiple interconnected local and/or wide area networks.
Exchange computer system 100 may also communicate in a variety of ways with devices that may be logically distinct from computer system 100. For example, 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 T1 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 and may communicate with exchange computer system 100 via 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 continual bid and offer prices for a derivative, security, or other type of product 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, 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 at least some embodiments, exchange computer system 100 (or “computer system 100”) receives, stores, generates, and/or otherwise processes data associated with a CAIFC. As explained in further detail below, a CAI may be based on another economic index and a carrying cost that varies over time.
A CAI may be based on a “total return” index that is itself based on components such as stocks, bonds or other types of interests that may have a capital value (e.g., a price at which the instrument might be bought or sold) and that may also represent a source of income (e.g., dividends, interest). A total return index reflects both the changes in capital value for the index components and the accrued income of those index components. Well-known examples of an economic index and a total return version of that index include the Standard & Poor's 500 Index and the Standard & Poor's 500 Index Total Return Index. The Standard & Poor's 500 Index is quoted under, and will henceforth be referenced by, the ticker symbol SPX. The Standard & Poor's 500 Index Total Return Index is quoted under the ticker symbols SPTR and SPXTR and will henceforth be referenced as SPTR. The SPX is calculated based on prices of the component stocks in that index, but does not incorporate or otherwise account for dividends paid out on those stocks. The SPTR is calculated based on the prices of those component stocks, but by also assuming that dividends are reinvested into those stocks. Although various examples will be described by reference to the SPTR, embodiments include carry-adjusted indices based on other indices.
As used herein, a carrying cost represents a cost that would be associated with holding components of total return index. The carrying cost may be, for example, interest that might be paid for funds used to acquire a portfolio of stocks that mirrors components of the SPTR. As another example, a carrying cost might be charges that would be paid to store a precious metal, a commodity, or some other type of good. Total carrying cost will in general increase over time, although the rate at which the carrying cost increases may vary. Although various examples will be described by reference to the 3 month U.S. Dollar London Interbank Offered Rate (3 month USD LIBOR) as the rate at which a carrying cost may increase, embodiments include carry-adjusted indices based on other interest rates as carrying costs, as well as carry-adjusted indices in which a carrying cost is derived from a rate other than (or in addition to) an interest rate.
“Futures contract” is a generic term for certain types of standardized derivative contracts that are traded through an exchange. For each type of futures contract, definitional parameters may define terms that apply to all future contracts of that type. Those terms may include, for example, an expiration date applicable to all contracts of that type, the manner in which contracts of that type are quoted and priced, times during which contracts of that type may be traded, and the manner in which contracts of that type may be settled, i.e., the manner in which obligations under a contract of that type may be satisfied. In many cases, definitional parameters for a type of futures contract define all terms of contracts of that type except for a price term. Parties wishing to enter into a futures contract may then submit orders that contain offer or bid values for that price term, with the orders then matched based on offer and bid values. Computer system 100 may then create, or “execute,” corresponding contracts based on the matched orders.
Definitional parameters for a type of futures contract also specify a particular subject matter, or “underlying,” for all contracts of that type. As but one example, an underlying for a type of futures contract may be an agricultural or other commodity. In such a case, definitional parameters may further specify that each futures contract of that type requires delivery of a predefined amount of that commodity on or about a predefined future date. As yet another example, an underlying may be a currency, a market index, an interest rate or other economic subject matter. In such a case, definitional parameters may specify payment on a predefined date of an amount computed from the value of the underlying on some future date. As a more specific example, a futures contract may specify that one party will pay a contract price in return for receiving, at contract maturity, an amount of money equal to the value of a stock index multiplied by a contractually specified factor (e.g., the value of the SPX at maturity×$50).
There are two counterparties to a futures contract. A long counterparty (or “long”) usually refers to a futures contract party holding a long position, with that party also known as the buyer of the futures contract. For index-based futures contracts, a long may agree to pay a contract price in return for an amount based on the index value at some future time. A short counterparty (or “short”) usually refers to a futures contract party holding a short position, with that party also known as a seller of the futures contract. For index-based futures contracts, a short may agree to receive a contract price in return for paying the amount based on the future index value.
In some embodiments, computer system 100 may generate and store data that includes definitional parameters for a type of CAIFC. In at least some embodiments, CAIFCs may be traded through computer system 100 in a manner similar to other exchange-traded products. Parties wishing to acquire long CAIFC positions may submit data that indicate bids for CAIFCs and prices at which those parties are willing to enter into long CAIFC positions. Parties wishing to acquire short CAIFC positions may submit data that indicate offers for CAIFCs and prices at which those parties are willing to enter into short CAIFC positions. Computer system 100 may match bids and offers based on price and create CAIFCs at those matched prices.
For convenience, subsequent discussions may describe a CAIFC in terms of actions and obligations of the counterparties to a particular CAIFC. In some embodiments, however, and similar to other types of exchange-traded contracts, one of the counterparties to every CAIFC may be a clearinghouse (e.g., a clearinghouse of the exchange operating computer system 100). For each matched bid-offer pair, computer system 100 may thus create a first CAIFC between the matched bidder as a long and a clearinghouse as a short, as well as an identical second CAIFC between the matched offeror as a short and the clearinghouse as a long.
In at least some embodiments, definitional parameters may specify that a long to a particular type of CAIFC will receive, at contract maturity, an amount corresponding to the value of a specific CAI as of a future date (e.g., at or near contract maturity) in return for payment of the contract price. A short to such a CAIFC may have converse obligations, e.g., to pay the amount corresponding to the value of that CAI as of the future date in return for being paid the contract price. Exchange computer system 100 may calculate the value of the CAI, and/or it may receive values of the CAI from an external source.
The definitional parameters may further specify a manner in which that CAI is calculated. In some embodiments, the calculation of a CAI “I” is periodically “reset” in a manner discussed below. For convenience, a period between two adjacent resets will be referred to as an “inter-reset” period. In some embodiments, values for index I during a current inter-reset period may be calculated using Equation 1.
In Equation 1, IT is the value of the index I at a time T. T may be, e.g., close of business on a particular calendar date. I0 is a closing value of the index I on the last day of the immediately preceding inter-reset period. ST is a value of a total value index S at time T. S0 is a closing value of that same index S on the last day of the immediately preceding inter-reset period. In some embodiments, index S is the SPTR. R0 is a value for an interest rate applicable to the current inter-reset period. In some embodiments, R0 is a value of the 3 month USD LIBOR on the first day of the current inter-reset period.
D0S-TS is the number of calendar days from a settlement date associated with the last day of the last inter-reset period to a settlement date associated with time T. In some embodiments, for example, and so as to reflect market conventions associated with equity markets, it is assumed that a settlement date associated with a date X is the third business day following X. Although subsequent discussion will elaborate on details of embodiments in which that settlement date convention (i.e., third business day following X) applies, such discussion merely provides an example to help illustrate various features. In other embodiments, a different settlement date convention may apply.
In some embodiments, the I calculation is reset every three months. In this manner, the I calculation further mimics schedules associated with a TRS. In some embodiments, for example, and so as to align with “roll” tendencies of holders of positions in futures products based on other indices which may be used for hedging purposes or for the purpose of facilitating trading in a CAIFC, the I calculation is reset at the end of the Tuesday preceding the third Friday in each of March, June, September, and December. In particular, S&P 500 Futures Contracts and E-mini S&P 500 Futures Contracts are traded through CME Group Inc. of Chicago, Ill., US under ticker symbols SP and ES, respectively. SP and ES contracts expire on the third Friday in each of March, June, September, and December. By Tuesdays immediately preceding the third Fridays in those months, approximately 50% of positions in SP and ES contracts that are about to expire have rolled to positions in later maturing SP or ES contracts. Although subsequent discussion will elaborate on details of embodiments in which the I calculation is reset every three months, such discussion merely provides an example to help illustrate various features. In other embodiments, an I calculation may reset at different time intervals and/or at different schedules. Such different schedules may include, e.g., resets that occur with different timings relative to expirations of one or more types of futures contracts or other financial products.
Each column of
In the next row, the 0.272 value for R0 on September 16 and 17 is a value of the 3 month USD LIBOR on the first day of inter-reset period N−1 (Jun. 19, 2013). The 0.252 value of R0 for September 18, 19, 20, and 23 is a value of the 3 month USD LIBOR on the first day of the inter-reset period N (Sep. 18, 2013). The row labeled “R” provides values of the 3 month USD LIBOR on each of the days T represented in the table of
The row labeled “Last reset,” provides the date of the last day of the inter-reset period immediately preceding the inter-reset period within which a particular date T is contained. For September 16 and 17, which are in period N−1, the “Last reset” date is Jun. 18, 2013, the last day of period N−2. For September 18, 19, 20 and 23, which are in period N, the “Last reset” date is Sep. 17, 2013, the last day of period N−1. As indicated in the next row (“Last reset settle”), the settlement date associated with Jun. 18, 2013, is Jun. 21, 2013, and the settlement date associated with Sep. 17, 2013 is Sep. 20, 2013. The row labeled “D0S-TS” contains, for each of dates T represented in the table of
In the next row, the 1328.656 value of I0 for September 16 and 17 represents the closing I value on Jun. 18, 2013, the last day of inter-reset period N−2 (not shown in the table). The 1377.602 value of I0 for September 18, 19, 20, and 23 represents the closing I value on Sep. 17, 2013, the last day of inter-reset period N−1. The next row, labeled “IT,” provides the closing SPTR values on each of the days T represented in the table of
At the reset between periods N−1 and N, and as respectively indicated in
Contingency procedures may also be established to address circumstances that might affect resets. For example, a reset might be scheduled to occur between dates X and Y. On one or both of those dates, markets might not open because of a holiday or because of a significant emergency. Contingency procedures could address such a circumstance by prescribing how values of S0, I0, and R0 are to be obtained if markets do not open on a day with which one of those values is associated. As but one further example, markets might be unexpectedly closed on date X. Contingency procedures may then require that the reset occur as planned at the end of date X, with R0 for the post reset period updated to a value of the 3 month USD LIBOR on date Y, but with S0 and I0 for the post reset period updated to the closing values of S and I from the last business day before date X. If markets are open on date X but are unexpectedly closed on date Y, contingency procedures may then require that the reset occur as planned at the end of date X, with S0 and I0 for the next period being the closing values of S and I on date X, but with R0 post reset being a value of the 3 month UDS LIBOR on the first business day following date Y. These contingency procedures could be combined if markets are unexpectedly closed on dates X and Y. In some embodiments, in the event of unexpected market closure on date X or date Y, observations for the index calculation may be taken on the next opened business day after X or Y.
The example of
In step 301, the computer system calculates an initial value of the CAI. In some embodiments, the initial CAI value may be calculated in a manner such as that described above. In step 302, the computer system determines if it is time to calculate a new CAI value. In some embodiments, for example, the computer system may determine in step 302 whether it is the end of a business day T. If not, the computer system repeats step 302 (“no” branch). If so (“yes” branch), the computer system proceeds to step 303.
In step 303, the computer system determines if a reset has occurred since the last calculation of the CAI closing value. In embodiments such as that described in connection with
If a reset has not occurred, the computer system proceeds to step 304. In step 304, the computer system accesses stored data that includes a value EIT that is a current value (e.g., at the close of day T) for a separate economic index. That separate economic index may be a total return index such as the SPTR. Examples of other total return indices that might be used include, without limitation, various indices available from other providers. The accessed data may also a value EI0c of that separate economic index at a time T0a corresponding to the last reset, a value CAI0b of the CAI at a time T0b corresponding to the last reset, and a value R0c of a carrying cost rate at a time T0c corresponding to the last reset. In embodiments in which a carrying cost rate is a cost of funds (e.g., an interest rate), that rate may be, e.g., a LIBOR, a U.S. Treasury funds rate, or some other interest rate subject to periodic revision.
In some embodiments, EI0a and CAI0b are closing values from the last day of the last inter-reset period and R0c is a value from the first day of the current reset period. In embodiments such as that described in connection with
In step 305, the computer system calculates a value D0-T representing an amount of time over which a carrying cost will be calculated. In some embodiments, D0-T represents a span of time between a date related to the end of the previous inter-reset period and a date related to a current date T. In some embodiments such as those described in connection with
In step 306, the computer system calculates CAIT, a current value for the CAI. In some embodiments, this calculation includes calculating an equity component and a carrying cost component, with the equity component being based on the value EIT, and with the carrying cost component based on R0c and D0-T, and then adjusting the equity component by the carrying cost component. Stated generally, the calculation may be represented as shown in Equation 2a.
CAI
T
=f(EIT)−f(R0c,D0-T) Equation 2a:
In Equation 2a, the equity component is f(EIT), where f(EIT) generally represents an output of a function that includes EIT as an input, and the carrying cost component is f(R0c, D0-T), where f(R0c, D0-T) generally represents an output of a function that includes R0c and D0T as inputs. In some embodiments, the equity component is also a function of the value EI0a, resulting in Equation 2b, a more specific form of Equation 2a.
CAI
T
=f(EIT,EI0a)−f2(R0c,D0-T) Equation 2b:
In some embodiments, the equity and carrying cost components are also functions of the value CAI0b, resulting in Equation 2c, an even more specific form of Equation 2c.
CAI
T
=f(EIT,EI0a,CAI0b)−f2(R0c,D0-T,CAI0b) Equation 2c:
In some embodiments, the calculation of step 306 is represented by Equation 2d.
AF in Equation 2d is an optional annualization factor. Exemplary values for AF, which may depend, e.g., on the convention used for R0c, include 1, 360 and 365. Equation 1 is a more specific form of Equation 2d, and in embodiments such as those described in connection with
In step 307, the computer system transmits the calculated value of CAIT for use in connection with further processing operations. From step 307, the computer system returns to step 302.
Returning to step 303, if the computer system determines that it is time for a rest, the computer system proceeds to step 308. In step 308, the stored value for EI0a to be accessed during performance of step 304 is updated with a new value of the separate economic index at a new time T0a corresponding to the reset that has just occurred. In a similar manner, the stored value for CAI0b to be accessed during performance of step 304 is updated with a new value of the CAI at a new time T0b corresponding to the reset that has just occurred. Finally, the stored value for R0c to be accessed during performance of step 304 is updated with a new value of the carrying cost rate at a new time T0c corresponding to the reset that has just occurred. In embodiments such as those described in connection with
The data represented by the first row of Table 1 (“Underlying”) indicates that the underlying subject matter of a CAIFC1 is a product of the value of the CAI and a notional multiplier. The notional multiplier, which would be the same for all CAIFC1s, may be, e.g., $50. The “Obligations” row includes data that specifies the obligations of short and long counterparties to a CAIFC1. The long obligations require a long to pay the contract price at contract expiration in return for receipt of a sum equal to the value of the underlying at expiration (e.g., the value of the CAI at expiration multiplied by the notional multiplier). The short obligations require the short to pay the value of the underlying at contract expiration in return for receiving the contract price. In effect, one of the parties is required to pay the other the difference between the contract price and the value of the underlying at expiration.
The “Quote” row includes data that specifies how offers to buy or sell CAIFC1s are to be quoted. In some embodiments such as that described in connection with
The “Last trade” row includes data that indicates the date and time by which trades in CAIFC1s must end (e.g., 4:15 p.m. Chicago time on the day prior to contract expiration). The “Settlement” row includes data that defines procedures for daily settlements and for final settlement. The daily settlement procedures may specify how the contract will be valued, prior to close of CAIFC1 trading, for purposes of marking to market. Those daily settlement procedures, for example, may indicate that the daily settlement valuation is based on closing trade price for other CAIFC1s if there were trades on that day, may indicate that the daily settlement valuation is based on a midpoint of offers and bids for CAIFC1s if there were no trades, and may provide methodology for determining that midpoint. The final settlement procedures may specify how a CAIFC1 underlying is valued at contract expiration. In some embodiments, the final value of a CAIFC1 is the value of the CAI at expiration. In other embodiments, and as described below, a slightly modified CAI calculation may be used to obtain a “special opening quote” (SOQ) for the CAI that is used to determine the final underlying value. The “CAI” row includes data that describes the methodology for calculating the CAI and/or a source of data that will provide CAI calculations and/or data for elements in the CAI calculation. In some embodiments, for example, the data in the CAI row may include (either explicitly or as a pointer to other data) information setting forth the calculation procedure described in connection with
The “Fee” row may include data that defines how the exchange will charge fees for executing CAIFC1s. In some embodiments, fees for CAIFC1s are structured so as reduce undesirable opportunities for arbitrage relative to other types of index-based futures contracts. Under one such structure, fees for various types of CAIFCs are laddered so that a front month CAIFC fee is comparable to a fee for a front month contract in another index-based futures contract product (e.g., an ES contract), while longer-dated CAIFCs are priced successively higher. For example, an exchange fee for executing a CAIFC that is the nth expiring contract relative to the front month may be set to 2n−1 times the front month contract fee. To illustrate this concept, assume that there are 8 types of CAIFC contracts that can be traded in January 2015: CAIFC1 expiring in March 2015, CAIFC2 expiring in June 2015, CAIFC3 expiring in September 2015, CAIFC4 expiring in December 2015, CAIFC5 expiring in March 2016, CAIFC6 expiring in June 2016, CAIFC7 expiring in September 2016, and CAIFC8 expiring in December 2016. In January 2015, a CAIFC1 is the front month contract (n=1), a CAIFC2 is the first deferred contract (n=2), etc. If the fee for executing a CAIFC1 in January 2015 is F, then the fee for executing a CAIFC2 in January 2015 is 3F ((2*2−1)*F), the fee for executing a CAIFC3 in January 2015 is 5F ((2*3−1)*F), etc. After expiration of CAIFC1s, the “n” rankings of CAIFC2 through CAIFC7 respectively decrease by one, and a new type of contract (CAIFC9 expiring in March 2017) becomes available as n=8. In April 2015, because CAIFC2 is now the front month (n=1), a fee for executing a CAIFC2 in April 2015 is now F, the fee for executing a CAIFC3 (now N=2) in April 2015 is now 3F, etc. This would continue following each expiration.
In step 403, order book module 110 of exchange computer system 100 begins receiving order data from parties desiring to enter into CAIFC1s. Computer system 100 may continue to receive such order data until the operations of
In step 406, match engine module 106 of computer system 100 determines if any of the received buy orders can be matched with any of the received sell orders. Match engine module 106 may perform this determination based on the bid and offer prices in those orders. This matching may be performed on a first-in first-out (FIFO) basis or on some other basis and using conventional order matching algorithms used in connection with orders for existing types of futures contracts and other products. If no matches are possible, and as shown by the “no” branch from step 406, computer system 100 determines in step 409 whether a “stop” flag has been set. Such a flag may be set, for example, if the close of trading time and date for CAIFC1s has been reached. If the flag is not set, and as shown by the “no” branch from step 409, step 406 is repeated. If the stop flag has been set, and as shown by the “yes” branch from step 409, the operations of
If computer system 100 determines in step 406 that a match is possible, and as shown by the yes branch from step 406, the match is performed in step 412. As part of step 412, computer system 100 stores data for executed CAIFC1s corresponding to the matched buy and sell orders. For each CAIFC1 buy order matched to an CAIFC1 sell order, at least two CAIFC1s are created. A first of those CAIFC1s is between the matched buyer and a clearinghouse of the exchange. The buyer is the long counterparty to that CAIFC1 and the clearinghouse is the short counterparty to that CAIFC1. A second of those CAIFC1s is between the matched seller and the clearinghouse. The seller is the short counterparty to that CAIFC1 and the clearinghouse is the long counterparty to that CAIFC1. The prices for those two CAIFC1s, which are based on the matched orders, are the same. The matched buyer and seller may not know each other's identities. As part of step 412, clearinghouse module 140 of computer system 100 stores the contract price for each of the executed CAIFC1s.
In step 415, computer system 100 again determines if the stop flag has been set. If not, and as indicated by the “no” branch from step 415, computer system 100 returns to step 406. If the stop flag has been set, and as indicated by the “yes” branch from step 415, the operations of
In step 501 of
If computer system 100 determines in step 501 that it is time to perform a final settlement calculation, and as indicated by the “final” branch from step 501, computer system proceeds to step 509. In step 509, computer system 100 determines a final settlement value for the executed CAIFC1 based on the final settlement procedures set forth in the CAIFC1 parameter data. This final settlement value is equal to the notional multiplier times a CAI value as of the contract expiration.
In some embodiments, and as described above, a modified CAI calculation may be used when calculating a final settlement value. Because some governmental regulations require that a final settlement price be based on an opening index price, the CAI calculation may be modified to produce an SOQ CAI on the expiration date. In particular, the CAI calculation methodology discussed in connection with
The CAI calculation for final settlement may also or alternatively be modified to account for carrying cost rate mismatches during the time between the reset immediately prior to CAIFC1 expiration and the date on which a CAIFC1 is finally settled. For some types of CAIFCs, traders may hedge their positions by entering into other types of index-based futures positions. At the time a CAIFC and a hedge position are entered, a carrying cost rate used in the CAI calculation and a carrying cost rate implicit in the hedge position contract may be the same. Moreover, the hedge position contract and the CAIFC may expire at the same time. If a reset occurs between the time of entry into the CAIFC and hedge contract and the time those contracts expire together, however, there will be a mismatch in the carrying cost rates associated with the CAIFC and the hedge contract.
To further illustrate this, assume a CAIFC1 is based on index I as described in connection with
Because party A executes the CAIFC1 and the ES contract at the same time in February 2015, both are based on interest rates as of the time those contracts are executed. Although the CAI may be calculated during February 2015 based on a 3 month USD LIBOR from December 2014, party A would have based its decision to enter a CAIFC1, and would have based the price at which it was willing to enter that CAIFC1, on current funding rates. When the CAI calculation is reset in March 2015, however, the 3 month USD LIBOR used in the CAI calculation may change. As a result, there will be a mismatch between the funding rates relied upon for the CAIFC1 and the ES contracts. Although this rate mismatch may be small and may only apply for a short time (e.g., the 5 days between the reset and the settlement of the CAIFC1 and the ES contracts on the Monday following the third Friday in March 2015), it can cause significant effects for large portfolios.
Equation 3 is an example of a modified CAI calculation to obtain an SOQ value of a CAI for final settlement in embodiments such as those described in connection with
In Equation 3, ISOQ is the SOQ value of the index used for final settlement of the CAIFC1. I0, S0, and D0S-TS have the same meanings as in Equation 1. SSOQ is an opening value of the SPTR on the day that the CAIFC1 expires. An opening value of an SPTR for a particular day is calculated in a manner similar to a closing value for that same day, but instead uses opening prices for the SPTR component stocks on that day instead of closing prices for those stocks. R0-1 is the value for the 3 month USD LIBOR that was used in calculation of index I prior to the most recent reset. If ISOQ is being calculated on Sep. 20, 2013, for example, R0-1 has a value of 0.272 (see
In at least some embodiments, an SOQ value of a CAI would only be used in connection with valuation of expiring futures contracts based on that CAI, and the unmodified CAI value would be calculated on that expiry date and used for other purposes. In some embodiments, an SOQ value of a CAI may be calculated in another manner. In some embodiments, an SOQ value of a CAI may be calculated by, and computer system 100 may receive those SOQ values of the CAI from, a computer system of a third party.
In additional embodiments, an SOQ value of a CAI is not used at all. Instead, the CAI used to determine final value of a CAIFC could be calculated in the same manner by which values for the CAI are obtained at other times. Stated differently, values for a CAI may be calculated continuously and in the same manner (e.g., as described in connection with
After calculating the final settlement value in step 509, computer system 100 proceeds to step 512. In step 512, computer system 100 may store data to update an account of the CAIFC1 holder to reflect the final value. As with final settlement performed in connection with other types of futures contracts, this update may represent an account decrease that requires the holder to deposit additional funds or may represent an account increase that the holder can withdraw.
Although the preceding description of
Additional embodiments include numerous variations on the exemplary features described thus far.
The foregoing description of embodiments has been presented for purposes of illustration and description. The foregoing description is not intended to be exhaustive or to limit embodiments to the precise form explicitly described or mentioned herein. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. The embodiments discussed herein were chosen and described in order to explain the principles and the nature of various embodiments and their practical application to enable one skilled in the art to make and use these and other embodiments with various modifications as are suited to the particular use contemplated. Any and all permutations of features from above-described embodiments are the within the scope of the invention.
This application claim priority to U.S. provisional patent application No. 62/019,020, filed Jun. 30, 2014, and titled “Carry-Adjusted Index Futures.” Application No. 62/019,020, in its entirety, is incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
62019020 | Jun 2014 | US |