A credit default swap (CDS) is a financial product that may be used to hedge risk and/or for other purposes. A CDS can take several forms. As the name implies, a “single name” CDS names a single corporation or other credit entity. A buyer of a single name CDS agrees to make one or more payments to the seller of that CDS. The amount of those payments may be negotiated between the buyer and the seller and is akin to the CDS purchase price. In return for the agreed-upon payments, the CDS seller agrees to make a designated payout if the credit entity named by the CDS goes into default during the tenor of that CDS. Default events may be defined by the CDS and may include, e.g., bankruptcy, failure to pay debts, etc.
An index CDS names multiple credit entities, with that collection of entities sometimes known as a “basket.” For example, some types of index CDS may name a basket of 100 or more different corporations. As with a single name CDS, an index CDS buyer agrees to make one or more payments to the seller. In return for those payments, the seller agrees to make a designated payment for each of the named entities (or “names”) of the CDS that goes into default during the CDS tenor.
At any given time during its tenor, an executed CDS (i.e., a CDS that has been entered into by a buyer and a seller) has a market value. For example, assume that a buyer of a single name CDS relating to XYZ Co. agrees to pay $100 to the seller. Further assume that, at some time after the buyer and the seller execute that CDS, the credit-worthiness of XYZ Co. deteriorates. Because of that deterioration, the market price of a CDS to obtain similar protection against XYZ Co. default is now $110. For the buyer who paid $100 for the executed single name CDS naming XYZ Co., the buyer's position in that executed CDS has gained value. Conversely, the seller's position in that executed CDS has lost value. If XYZ Co. were to default, the value of the buyer's position in the executed CDS would jump to the amount of the agreed payout, less the original purchase price. The value of the seller's position would vary in the opposite direction upon XYZ Co. default.
Values of buyer and seller positions in a CDS can also vary in other ways. For instance, assume that the credit worthiness of XYZ Co. improves after execution of the CDS from the previous example. Because of that improvement, the new market price for similar CDS naming XYZ Co. may have dropped to $90. This would represent a decrease in the value of the buyer's position in the executed CDS and an increase in the value of the seller's position.
The value of a position in an executed index CDS can vary in ways similar to those described above. However, the effect of any one name on the value of an index CDS position is much less than in the case of a single name CDS position.
A CDS may be cleared so as to protect against a default by the buyer or seller of that CDS. After execution of a CDS by a buyer and seller, for example, a clearinghouse may perform a novation and a become party to multiple credit default swaps (CDSs) with the buyer and seller. In particular, the CDS between the buyer and seller is replaced with a first CDS between the buyer and the clearinghouse as seller, and an identical second CDS between the seller and the clearinghouse as buyer. In practice, a clearinghouse may deal with firms known as clearing members (or “members”). Each member may act for itself and/or on behalf of multiple other parties. As a result, each member may have a large portfolio of CDSs that are cleared through a clearinghouse. In any given portfolio, a member may have positions in multiple different types of CDSs. Some positions may be as a buyer, and some positions may be as a seller.
To help ensure that a member fulfills its obligations under CDSs in its portfolio, a clearinghouse may require the member to provide a margin payment. This margin payment represents a security or performance bond. This is distinguishable from the use of the term “margin” in connection with securities trading, where margin refers to a partial payment of a purchase price. As used herein, the term “margin” refers to a security or performance bond associated with CDS clearing.
A CDS may be denominated in any of multiple currencies. For example, CDX is a name for a family of index CDS products with baskets of North American credit entities, and for which the buyer and seller payments are in U.S. dollars (USD). As another example, iTraxx® is a brand name for a family of index CDS products having baskets of credit entities from other regions, and for which buyer and seller payments are in Euros (EUR). A clearinghouse member may have a portfolio that includes CDS products denominated in more than one currency. Determining an appropriate margin for such a portfolio presents problems not addressed by known systems
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 a method according to some embodiments, a computer system may access data describing positions of a multi-currency CDS portfolio PF. The portfolio PF may include a portfolio portion PF1 comprising positions in CDS products denominated in a first currency and a portfolio portion PF2 comprising positions in CDS products denominated in a second currency. The computer system may calculate, based on the accessed data and on an exchange rate FX21_UP for converting the second currency to the first currency, a first margin component in the first currency. The computer system may also calculate, based on the accessed data and on an exchange rate FX21_DN for converting the second currency to the first currency, a second margin component in the first currency, wherein FX21_UP is greater than FX21_DN. The computer system may additionally calculate a margin component MC1 as a maximum of a set of values that includes the first margin component and the second margin component. The computer system may further calculate, based on the accessed data, a margin component MC21 in the first currency, a margin component MC22 in the second currency, a first currency margin requirement MR1 as a sum of the margin component MC21 and a portion of the margin component MC1 corresponding to the portfolio portion PF1, and a second currency margin requirement MR2 as a sum of the margin component MC22 and a portion of the margin component MC1 corresponding to the portfolio portion PF2. The computer system may transmit data representing the first currency margin requirement MR1 and the second currency margin requirement MR2.
Embodiments include, without limitation, methods for calculating and otherwise processing data related to margin requirements for multi-currency CDS portfolios, 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 stored by one or more non-transitory computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage 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 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 information. An exemplary trading network environment for implementing 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, other types of options, and other types of derivative contracts. Financial products traded, cleared, and/or otherwise processed by the exchange may also include CDSs. Financial products traded through the exchange may also or alternatively include other types of financial products, including without limitation stocks, bonds and or other securities (e.g., exchange traded funds), foreign currencies, spot market trading of commodities, and over-the-counter (OTC) products such as OTC forwards, OTC options, OTC interest rate swaps, 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 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 associated with 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 of CDSs 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 CDS or other product. Module 140 may also be configured to perform other clearinghouse operations. As a further example, module 140 may maintain margin data with regard to clearing members. As part of such margin-related operations, module 140 may store and maintain data regarding the values of various CDSs and other interests, 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, etc. CDS margin calculation module 142 may also generate, store, and process data regarding margins for multi-currency CDS portfolios. 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. Also shown in
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 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, 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 in connection with margins for multi-currency CDS portfolios. In some embodiments, some or all of these operations may be performed by CDS margin calculation module 142. In other embodiments, one or more other modules of computer system 100 may perform some or all of these operations. In still other embodiments, one or more of these operations could be performed by a computer system that is separate from computer system 100.
In step 201, module 142 accesses data describing positions in a multi-currency CDS portfolio PF. Portfolio PF includes positions in multiple types of CDS products. A “position” refers rights as a buyer or as a seller in a corresponding executed CDS product having defined parameters such as named credit entity(ies), default definitions, payout amounts, tenor, etc., and also having an agreed-upon price. A portion PFUSD of portfolio PF includes positions in CDS products denominated in USD. A portion PFEUR of portfolio PF includes positions in CDS products denominated in EUR. For convenience, “credit entity[ies] named in a position,” or the like, is used below as a shorthand reference to describe credit entity[ies] named in a CDS corresponding to a position.
In step 203, module 142 calculates FXEURUSD_UP and FXEURUSD_DN, where each of FXEURUSD_UP and FXEURUSD_DN is an exchange rate for converting EUR to USD, with FXEURUSD_UP being greater than FXEURUSD_DN. To calculate FXEURUSD_UP and FXEURUSD_DN, module 142 first calculates a value ΔFXEURUSD by taking the 99% quantile of 5-day log changes of the spot EUR-to-USD exchange rate standardized by exponentially weighted moving average volatility. Module 142 then calculates FXEURUSD_UP and FXEURUSD_DN by applying ΔFXEURUSD to the current EUR-to-USD spot rate (FXEURUSD_Spot).
In step 205, module 142 calculates a margin component MC1UP using a first set of one or more algorithms and based on the positions in portfolio PF (PF positions). Margin component MC1UP is calculated in USD.
In step 301, module 142 performs an algorithm to calculate a value for a spread risk component SRUP for the PF positions. Spread risk component SRUP represents a 99th percentile estimate of an amount that the value of portfolio PF might change over a predetermined period (e.g., 5 days) as a result of changes in the value of CDSs corresponding to PF positions, but without considering possible default events, and assuming an exchange rate of FXEURUSD_UP. In some embodiments, the algorithm of step 301 generates N scenarios using a Monte Carlo simulation calibrated to historical data, with N=10,000 scenarios n=1 through n=10,000. In each scenario, a 5-day change in the value of each PF position is estimated. In other embodiments, there may be more or fewer scenarios and/or a different simulation model may be used. For each nth scenario, a value of SRUP(n) is calculated in USD according to SRUP(n)=SRUSD(n)+FXEURUSD_UP*SREUR(n), where SRUSD(n) is an estimate of a 5-day value change (in USD) for the positions in portion PFUSD of portfolio PF according to scenario n, and wherein where SREUR(n) is an estimate of a 5-day value change (in EUR) for the positions in portion PFEUR of portfolio PF according to scenario n. SRUP is then set to equal the 99th percentile value from the 10,000 values of SRUP(n) calculated for n=1 through n=10,000.
In step 303, module 142 performs an algorithm to calculate a value for a jump-to-default component JTDUP for the PF positions. The jump-to-default component JTDUP represents an estimate of the largest possible loss that might result from a default by a single credit entity named by one or more of the PF positions, and assuming an exchange rate of FXEURUSD_UP. In some cases, a given credit entity may be named in multiple PF positions. Some of those positions may correspond to single name CDSs, and some may correspond to index CDSs. Those positions may also include buyer positions and seller positions. As can be appreciated, the default of a single credit entity may increase the value of some positions and may decrease the value of other positions.
In some embodiments, JTDUP is calculated in USD and may estimate losses, apart from spread risk losses, that may result from a default of a single one of the entities represented in portfolio PF. In some such embodiments, and for each of j credit entities named in one or more of the PF positions, the algorithm of step 303 first calculates a value JTDUP(j). The value for JTDUP(j) represents an exposure of portfolio PF if there is a default of the jth credit entity and payouts are made based on that default. In some embodiments, JTDUP(j) value may equal the sum of (1) the mark-to-market (MTM) values, as of default, for all PF positions corresponding to a single name CDS naming the jth credit entity, and (2) the MTM values, as of default, for all PF positions corresponding to an index CDS position including the jth credit entity as a constituent, but with each of those index CDS positions assumed to have a notional equal to 1/R of the index CDS position actual notional (as of the time of JTDUP(j) calculation), with R being the number of names in the corresponding index CDS. If the jth entity is denominated in USD, then (1) and (2) are initially calculated in USD. If the jth entity is denominated in EUR, then (1) and (2) may be initially calculated in EUR and converted to USD using FXEURUSD_UP. Depending on the nature of each PF position naming the naming the jth credit entity, the value of JTDUPp(j) could be positive or negative.
The algorithm of step 303 then computes a value L* representing the largest loss at 99% confidence level in any scenario involving a default of a single credit entity named in one or more of the PF positions. This calculation may be performed according to Equation 1.
In Equation 1, “SRUP(j)” is a value for spread risk calculated using the same N scenarios used in connection with step 301, but for a portfolio PFno_j that is similar to portfolio PF, but with all single name positions naming the jth entity excluded and with notionals of all index positions having a basket that includes the jth entity adjusted to exclude the jth entity. SRUP(j) is set to equal the 99th percentile value from the 10,000 values of SRUP(j,n)=SRUSD(j,n)+FXEURUSD_UP*SREUR(j,n) calculated for n=1 through n=10,000, where SRUP(j,n) is a value for spread risk of portfolio PFno_j under scenario n, SRUSD(j,n) is a value for spread risk of the USD-denominated portion of portfolio PFno_j under scenario n, and SREUR(j,n) is a value for spread risk of the EUR-denominated portion of portfolio PFno_j under scenario n. The value of jump-to-default component JTDUP may then calculated according to Equation 2, where SRUP is the value from step 301.
JTD
UP=max((L*−SRUP), 0) Equation 2
In step 305, module 142 performs an algorithm to calculate a value for a jump-to-health component JTHUP for the PF positions. The jump-to-health component JTHUP is used to account for a large, idiosyncratic move in any single name spread, and assuming an exchange rate of FXEURUSD_UP. JTHUP may be calculated in USD. In some embodiments, and for each of j credit entities named in one or more PF positions corresponding to a single name CDS, the algorithm of step 305 calculates a net value JTHUP(j) of all PF positions corresponding to a single name CDS naming the jth credit entity. These net values are calculated by assuming the spreads for the single name CDSs corresponding to those positions take values given by their 0.5% quantiles. If the jth entity is denominated in USD, then JTHUP(j) may initially be calculated in USD. If the jth entity is denominated in EUR, then then JTHUP(j) may be initially calculated in EUR and converted to USD using FXEURUSD_UP.
The algorithm of step 305 then computes a value L**, representing the largest loss at 99% confidence level in any scenario with a JTH event. This value may be calculated according to Equation 3.
In Equation 3, “SR′UP(j)” is a value for a spread risk calculated using the same N scenarios used in connection with step 301, but for a portfolio PF′no_j that is similar to portfolio PF, but with all single name positions naming the jth entity excluded. SR′UP(j) is set to equal the 99th percentile value from the 10,000 values of SR′UP(j,n)=SR′USD(j,n)+FXEURUSD_UP*SR′EUR(j,n) calculated for n=1 through n=10,000, where SR′UP(j,n) is a value for spread risk of portfolio PF′no_j under scenario n, SR′USD(j,n) is a value for spread risk of the USD-denominated portion of portfolio PF′no_j under scenario n, and SR′EUR(j,n) is a value for spread risk of the EUR-denominated portion of portfolio PF′no_j under scenario n. The value of jump-to-default component JTHUP may then be calculated according to Equation 4, where SRUP is the value from step 301.
JTH
UP=max((L**−SRUP, 0) Equation 4:
In step 307, module 142 calculates a value for MC1 UP=SRUP+JTDUP+JTHUP.
Returning to
Returning to
In step 211, module 142 performs a third set of one or more algorithms and calculates a value for a margin component MC2USD. Module 142 calculates a value for MC2USD in USD based on the PFUSD positions.
In step 401, module 142 performs an algorithm to calculate a value for an interest rate charge component IRUSD for portfolio portion PFUSD. Interest rate charge IRUSD accounts for possible losses associate with changes in an applicable discount curve structure over a designated period (e.g., 5 days). In some embodiments, the ISDA (International Swaps and Derivatives Association) discount curve for USD is used, an upward shift of the curve is assumed, and a resulting change in value of portfolio portion PFUSD (Δup) is calculated. Next, a downward shift of the curve is assumed, and a resulting change in value of portfolio portion PFUSD (Δdn) is calculated. Whichever of Δup and Δdn represents a greater loss is then used as the value of IRUSD. The magnitudes of the upward and downward shifts are taken to be the 99% quantile of the 5-day log returns for the 5-year point on the ISDA curve, with the quantiles estimated using empirical quantiles based on a 5 year look back period from the date of calculating IRUSD.
In step 403, module 142 performs an algorithm to calculate a value for a liquidity charge component LCUSD for portfolio portion PFUSD. The liquidity charge accounts for extra cost that may be incurred to liquidate portfolio portion PFUSD if position sizes are large relative to market depth of corresponding products. In some embodiments, the algorithm of step 403 first breaks up positions in portfolio portion PFUSD into additional subportfolios based on the types of corresponding CDS products. For example, one subportfolio may include positions in IG (investment grade) index CDS products, another subportfolio may include positions in HY (high yield) index CDS products, etc. For each subportfolio, a corresponding total exposure is calculated and a corresponding liquid product is identified. With regard to index CDS products for example, the most recent (or “on-the-run”) product tends to be very liquid, while older (or “off-the-run”) products tend have less liquidity. In some embodiments, the on-the-run 5-year CDS product corresponding to the subportfolio is chosen as the liquid product for that subportfolio.
For each subportfolio, the algorithm of step 403 then determines the amount of the corresponding liquid product that would be needed to hedge the corresponding total exposure. The algorithm of step 403 then compares that amount to recent trading volume of the corresponding liquid product and calculates a liquidity cost for that subportfolio based on the comparison. If the needed amount of the corresponding liquid product is small relative to the current trading volume, then the liquidity cost may be very small. If the needed amount of the corresponding liquid product is large relative to the current trading volume, then the liquidity cost may be larger. In some embodiments, the relationship between needed amount and recent trading volume may be implemented as a look-up table that assigns a liquidity charge to different ranges of H/V, where H is the amount of liquid product needed to hedge and V is the trading volume of that liquid product.
After calculating a liquidity charge for each subportfolio, the liquidity charges are then summed. The step 403 algorithm then designates that sum as the value of LCUSD. In step 405, module 142 calculates MC2USD as the sum of IRUSD and LCUSD.
Returning to
Returning to
In Equation 5, “MC1Spot” is a value calculated in the same manner as MC1UP and MC1DN, but by using FXEURUSD_Spot instead of FXEURUSD_UP or FXEURUSD_DN. Module 142 calculates a EUR margin requirement MREUR for portfolio PF in step 217. In some embodiments, module 142 calculates a value for MREUR according to one of Equation 6a or Equation 6b. Equation 6a is used if FXEURUSD_UP was used to calculate MC1 (i.e., if MC1=MC1UP), and Equation 6b is used if FXEURUSD_DN was used to calculate MC1 (i.e., if MC1=MC1DN).
In step 219, module 142 transmits the values for MRUSD and MREUR to one or more other components of computer system 100. In step 221, those one or more other components may confirm that a member account corresponding to portfolio PF contains sufficient funds in USD and EUR to satisfy the values of MRUSD and MREUR, or that the member has otherwise deposited collateral determined to be equivalent to the combined requirements of MRUSD and MREUR. In some embodiments, for example, computer system 100 may be configured to accept alternative collateral (e.g., other currencies, US Treasury securities, etc.) in lieu of some or all of MRUSD and/or MREUR according to a predefined “haircut” schedule.
In some embodiments, a computer system may perform operations similar to those described above in connection with
As indicated above,
Operations such as those described herein can be extended to multi-currency CDS portfolios that include interests in CDSs denominated in more than two currencies. For example, assume portfolio PF also has a portion PFJPY that includes positions in CDSs denominated in Japanese Yen (JPY). Step 203 could be modified so as to also calculate exchange rates FXJPYUSD_UP and FXJPYUSD_DN in manner similar to that used to calculate FXEURUSD_UP and FXEURUSD_DN. Steps 205 and 207 could be replaced with (i) steps to calculate values for MC1 UP/UP using operations similar to those in steps 301-307 of
A set of steps similar to those of
Embodiments such as those described herein may provide several advantages. Effects of potential FX rate fluctuation are included as a risk component in overall margin requirement calculation. By separating a margin requirement into portions denominated in separate currencies, a portfolio holder may have the option of providing security in multiple currencies, thereby potentially obtaining a discount representing overall margin requirement attributable to conversion of one currency into another. For holders of portfolios that only involve a single currency, the above described methodology results in a margin requirement only denominated in that single currency.
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.