Computer method and apparatus for optimizing portfolios of multiple participants6393409Abstract Computer technology for substantially optimizing portfolios of multiple participants is disclosed. Preferably the portfolios of such multiple participants comprise fixed income instruments. The disclosed systems and methods include using at least one computer system for storing digital data representing portfolio holdings of multiple parties and, in particular, for each participant storing in the computer memory data representing constraints with respect to the desired portfolio. The method and system comprise optimizing using an optimization engine portfolio and constraint information of multiple participants so as to generate a set of trades that would substantially optimize participants portfolios with respect to a known objective. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
(Amounts in Millions)
old new net discounted
year bond bond cash flow cash flow
0 98.317 (97.411) 0.906 0.906
1 (4.388) 4.907 0.520 0.495
2 (4.388) 4.907 0.520 0.471
3 (104.388) 102.318 (2.069) (1.785)
PROFIT 0.087
The breakeven discount rate that makes the swap beneficial is 2.8%. The profitability of the swap increases with increasing maturity of the bonds, decreasing price of the underwater bonds, and increasing discount rate. Alternatively, one may swap for market-discount bonds, i.e., bonds currently trading at a discount. Normally, securities are taxed on an effective-yield basis; however, market-discount securities have different taxation. If the income from the bond exceeds the financing cost for the bond (which is assumed to be true in this example), the investor may elect to pay tax on cash flow rather than yield. For a discount bond, tax on cash flow is always lower than tax on yield. If the investor makes this election, there is an additional tax due on excess of sale or redemption proceeds over cost. This election may be made on a bond by bond basis. Swapping to a market-discount bond achieves greater economic benefit than swapping to a par bond, as illustrated in the example below. For simplicity, consider that the underwater bond, discussed in the previous example, is swapped with a bond of identical attributes (but different issuer to avoid a wash sale). The only modifications to the previous analysis are the cash flows of the new discount bonds. As a result of the swap, the new bonds are bought for $97.411MM, netting the tax refund. On three successive years, the investor receives, after taxes, a coupon equal to the coupon foregone. On the third year, the investor also receives the return principal of $100MM, however, we are required to pay tax on the accrual from the discount price. Thus, we receive $100MM plus $4.388MM minus 35% of ($100MM-$97.411MM)=$103.48MM. This analysis is summarized in Table 2 below, which illustrates that the resulting profit is greater than that of the previous scenario.
TABLE 2
(Amounts in Millions)
Swapping for Discount Bond
0 98.317 (97.411) 0.906 0.906
1 (4.388) 4.388 0.000 0.000
2 (4.388) 4.388 0.000 0.000
3 (104.388) 103.481 (0.906) (0.782)
PROFIT 0.124
Software Implementation In general, a multi-party book loss optimization problem of the exemplary application described above is well-suited to linear programming, a known optimization technique. Book loss is defined as the par sold multiplied by the difference in book price and market price for the securities available in the secondary market at the time of the transaction. Table 2 below defines variables used in the following discussion, where indexes i, j, k correspond to the set of all bonds, firms, and sectors, respectively.
TABLE 3
Basic Variable Definitions
symbol meaning
variables
BUY.sub.i,j par amount of bond i bought by firm j
SELL.sub.i,j par amount of bond i sold by firm j
constant inputs
CURPAR.sub.i,j original par amount of bond i held by firm j
PRICE.sub.i,j firm j's transaction price for bond i
BOOK.sub.i,j firm j's book price for bond i
ACCRUED.sub.i accrued interest for bond i
PV.sub.i,j PRICE.sub.i,j + ACCRUED.sub.i (firm j's transaction cost
for bond i)
DUR modified-present-value duration for bond i
CON.sub.i present-value convexity for bond i
IN.sub.i,j,k bond i belongs to firm j's k-th sector (0, 1)
In the following discussion it is assumed that PRICE.sub.i,j =PRICE.sub.i for all j, because fixing a single mid-market price for each security is a practical necessity in conducting the tax swap. However, the model presented herein is more general, allowing, in other embodiments, different firms to transact at different prices for a given security as will be understood by a person skilled in the art. The objective function representing total book loss, optimized by the system, is expressed as follows: ##EQU1## This function is optimized subject to the following constraints: Bond conservation: for a given bond, the par amounts bought and sold over all participating firms must net to zero, i.e., there is a closed universe of bonds. ##EQU2## Present value neutrality: for every firm, the total of all trades must be present-value neutral. ##EQU3## Duration neutrality: the total of all trades must leave the dollar-duration within a reasonable tolerance. This is a relaxed form of dollar-duration-neutral trading. The constraints are applied on a per party (j) basis. ##EQU4## These constraints bound the permissible change in dollar duration around a given target range ($DUR.sub.j.sup.min, $DUR.sub.j.sup.max). For example, bounds equivalent to .+-.1/2 (one-half) year modified duration would be typical. If only a portion of a participating firm's entire portfolio is employed in a swap, this constraint applies to that portion only, so that the change resulting from the swap would be diluted in the overall portfolio. Convexity neutrality: These constraints are similar to the above constraint, except that $DUR.sub.j is replaced by CON.sub.j. The total of all trades must leave the convexity within a reasonable tolerance. These constraints, bounding the permissible change in convexity, represent a relaxed form of convexity-neutral trading. For example, bounds of $CON.sup.min =$CON.sup.curr and $CON.sup.max =.infin. are typical. Since all trades are conducted at fair market prices, a decrease in convexity need not be a concern. The lower convexity would be reflected in lower security prices. Other market-value weighted attributes: Yield and rating are constrained in an identical manner as duration and convexity. In other embodiments, other portfolio characteristics can be defined in a manner similar to duration and convexity. Par-value weighted attributes: Maturity and coupon are constrained in a manner similar to duration and convexity; however, par-value rather than market-value is used for weighing. As noted, in other embodiments, other characteristics can be similarly defined. Proceeds bounding within sectors: The total of all trades must leave the present value (within every sector) between reasonable (predefined) bounds. These constraints can enforce present-value-neutral trading, possibly weakened to provide additional flexibility. Alternately, the use of these constraints may provide an opportunity to employ the transaction in order to reallocate the portfolio. These constraints, expressed below, are applied on a per party (j) basis. ##EQU5## These constraints bound the permissible change in proceeds within a sector around a given target range (SPV.sub.j.sup.min, SPV.sub.j.sup.max). For example, quality sectors used in these optimizations categorize bonds by Moody's and S&P ratings, as well as by a numerical scale. Name constraints are a special case of sector constraints, pinpointing an individual bond issuer. As understood by a person skilled in the art, it is sometimes useful to constrain buys and sells directly, as shown below, in addition to the net change constraint above. ##EQU6## The sectors include an industry sector type, such as Financials, Utilities, Industrials and Sovereign/Agencies, as well as other types of sectors including rating, broad maturity, fine maturity, duration, convexity, EJV sector, EJV subsector, EJV subsubsector, holdings, issuer, SIC code, and other sectors customized to specific firms. Another category of sectors is a specification of bonds that cannot be sold to a given firm. Non-negativity and boundedness: the amount bought and sold must be non-negative, and the amount sold must not be greater than the original par amount owned. Additionally, the amount bought must not exceed the total amount owned by all other firms. ##EQU7## If the right-hand-side of the buy equation is zero, then no variable BUY.sub.i,j is required in the model, thereby reducing its complexity. Furthermore, the potential for churning with respect to this security would be eliminated. In the model defined by the above objective function and constraints, churning and wash sales may occur when more than one party owns the same bond. Churning refers to buying and selling of the same security to generate spurious book loss. Churning involves swapping bonds with the same CUSIP (Committee on Uniform Security Identification Procedure) code. A wash sale involves bonds that satisfy the following three similarity conditions: 1)the same issuer, 2)maturities within five years of each other, and 3)coupons within 25 bp. To eliminate churning and wash sales, the results obtained by employing the above continuous model may then be modified by computing net sales of each bond for each firm. The net sales would then be presented as a resultant portfolio produced by the transaction. However, it is unlikely that the resultant allocation of bonds would be substantially optimal with respect to the goal of book loss maximization, and therefore this is not the preferred approach. For example, if each of two firms hold two bonds A and B, co-members of a given sector, the objective function may be maximized by a wash sale of bonds A and B: each sells the other both A and B. If only net sales are taken into account these sales would net zero for each bond, and, therefore, no trades and book losses would be produced. The optimal solution, however, is for one firm to sell A and the other to sell B, allowing each to achieve a book loss. The formulation of the objective function, provided above, maximizes achieved book loss. In an alternative embodiment, this function can be generalized as follows to include the economic value of tax deferral: ##EQU8## A person skilled in the art, based on this discussion, can also implement optimization with respect to this function. However, given that variables are defined as bought and sold amounts, churning and wash sales still remain an issue. However, if variables were to be defined as the net change in the amount bought and sold, the churning/wash sales problem would be avoided, but the objective function becomes problematic. This happens because there is a benefit only from a net sale, not from a net gain, ##EQU9## which is nonlinear. Alternatively, the churning and wash sales can be avoided by introducing non-linearities into the constraints rather than the objective function: ##EQU10## The implementation of the preferred embodiment for the exemplary application considered here, enhances the continuous model discussed above by employing mixed-integer techniques. The enhancement of the preferred embodiment effectively addresses the issue of churning and wash sales (including taking into account bonds owned by the subsidiaries of the same parent). In the preferred embodiment, SELL.sub.i,j and BUY.sub.i,j are set to be mutually exclusive for all bonds i owned by a firm j and at least one other firm. This formulation translates into a mixed-integer linear program. The CPLEX software used in the referred embodiment provided for solving mixed-integer linear programming as well as for specifying mutual exclusion. See CPLEX Optimization, Inc. Using the CPLEX Callable Library. Version 4.0 930 Tahoe Blvd., Bldg. 802, Incline Village, Nev. 89451. http://www.cplex.com, 1995 incorporated herein by reference. In alternative embodiments that employ optimization software without this mutual-exclusion facility, but which support zero-one variables, the previous described formulation is appended with the following expressions to achieve the desired result (See also D. G. Luenberger, Linear and Nonlinear Programming, Addison-Wesley, Reading, Mass., Second Edition, 1984, incorporated herein by reference): ##EQU11## where .theta. is the set of subsidiaries owned by the parent of firm j and M is a suitably large number. The Boolean variables .delta..sub.i,j select either buying (.delta..sub.i,j =0) or selling (.delta..sub.i,j =1) of bond i by firm j. As a result, inflated sales (fueled by churned buys) are disallowed. Note however that this alone will not prevent wash sales of similar, yet not identical, securities. Two or more affiliated parties (e.g., subsidiaries of the same parent firm) cannot trade with each other, yet may require different constraints in order to not be treated as a single entity. In the preferred embodiment this requirement is modeled in the following manner. If a bond i is originally held by at least one of the affiliated parties .theta., two cases are possible: (1) i is not held by any party outside of .theta.; or (2) at least one party outside of .theta. holds i. Accordingly, in the first case, the constraint BUY.sub.i,.theta. =0 is introduced and, in the second case, the constraint introduced is as follows: ##EQU12## The above constraints do not guarantee that no trades between affiliated parties would occur, but these constraints drastically reduce such trades. The system of the preferred embodiment automatically checks for trades slipping through these constraints for manual correction after optimization. Although mixed-integer programs such as presented before are difficult to solve optimally for large data sets, sufficiently satisfactory solutions can be obtained using the method of the preferred embodiment as described herein. Results that are not strictly optimal, but are sufficiently optimized to be acceptable, may also be referred to as optimal in this discussion. FIGS. 2 and 3 illustrate the processing performed by the preferred embodiment with respect to the illustrative tax swap application. Initially, workstation 100 accepts portfolio information from clients who wish to participate in a swap. Portfolio information includes specifications of bonds, uniquely identified with a CUSIP, par holdings and book prices. In addition, clients provide constraints defining their requirements for the resultant portfolio. The clients may submit their portfolio and constraint information in various formats, for example, in the form of a spread sheet such as provided by Microsoft Excel. As discussed previously, client portfolios may be provided to the system in various ways, e.g., by e-mail or on a magnetic medium or simply entered by the operator. The encoding of information received from the clients is not limited to a specific format. The front end 30 of the preferred embodiment is a large Microsoft Excel workbook written in Visual Basic. At step 200 the front end 30 accepts the client information that has been translated manually into a formal specification using a syntax discussed below. In general, the front end stores portfolio and constraint information. User and System constraints can be specified and stored in the front end 30. The user constraints allow participants of the tax swap to specify customized constraints to ensure that their individual requirements are met. For example, firm i may require that it would not buy bonds rated lower than AA. The system constraints are specified by the entity running the intermediary tax swap system itself so as to guarantee certain invariants, such as the constraints discussed above. Constraints on sectors specify (1) which sectors are constrained; (2) over what statistic the constraint is defined; and (3) the bounds of the constraint. The sectors within a constraint are defined either as an individual identifier or any number of identifiers connected with logical operators. The following grammar for name expressions is used to specify sectors. letter: one of a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z digit: one of 0 1 2 3 4 5 6 7 8 9 number: digit digit number char: letter digit op: .vertline. & identifier: char identifier char unary: identifier .about.identifier sector: unary (unary) unary op binary (unary op binary) An identifier is either a full CUSIP, a name (a six character CUSIP), or an alpha-numeric string previously defined as a sector of a certain bond. For example ".about.(AAA/AA)" specifies all bonds rated lower than AA. The ".vertline." operator is logical OR; "&" is logical AND; and ".about." means NOT. Parenthesis are used in a conventional manner. A full CUSIP specifies an exact bond issue, whereas a name specifies an issuer. For example "912827T6 & 312911" specifies a single Treasury bond and a group of mortgages. A client firm, for example, may specify names it refuses to buy, e.g., ".about.369856". The following grammar is used for constraint specification: applies-to: one of or-applies and-applies or-applies: one of number number.vertline.or-applies and-applies: one of number number & and-applies value: one of #PV #LOSS #DUR #CONV #MAT #COUPON #RATING variable: one of #ALL #SECTOR #FINAL #BUY #SELL #NET #CURR #AVG numerator-value: value value numerator-value numerator-variable: variable variable numerator-variable numerator: numerator-value numerator-variable denominator-value: value value denominator-value denominator-variable: variable variable denominator-variable denominator: denominator-value denominator-variable fraction: numerator numerator-denominator method: one of #REL #ABS #PROP constraint: applies-to print-name sector fraction method bounds In the above grammar, "print-name" is an optional string that provides textual representation of the constraint for summary purposes. The "Or-applies" expressions specify a group of firms in which a given constraint applies individually to each firm. The "And-applies" expressions specify a group of firms to which the constraint applies collectively. In general, a constraint is of the form: ##EQU13## A pair of numbers (L, U) represents the lower and upper bounds placed on the constraint. The numerators and (optional) denominators define the statistic. The numerator represents the base statistic, and the denominator can be used to normalize the base statistic. The base statistic is defined by both variable and value specifications. For example, if a firm is interested in constraining the market-value-weighted dollar duration of all bonds it buys, the numerator is set to #PV#DUR#BUY. The variable #BUY specifies that the set of bonds bought should be considered. The values #PV#DUR specify that the desired statistic is present value times duration times par amount. Other variables that can be used are #SELL (bonds sold), #NET (buys minus sells), #SECTOR (pay attention to the sectors specified in the constraint), #ALL (ignore sectors), #FINAL (original plus buys minus sells), and #AVG (buys plus sells divided by two). These variables can also be combined as in the example above. The values include #CONV (convexity), #MAT (maturity), #COUPON (coupon), #RATING (rating) and #LOSS (book price minus price), as well as other values defined by the user, as will be understood by one skilled in the art. As mentioned, the denominator is used to optionally normalize the base statistic. For example the previous numerator #PV#DUR#BUY needs to be normalized by the denominator #PV to compute a valid duration. All the variables specified above can be used in the denominator. In addition the variables used in the denominator include #CURR (current portfolio) and #NONE (denominator equals one). Commonly used constraints may also be specified as macros. Constraints can be bound with respect to #ABS (absolute value of bounds), #REL (a value relative to a base value, i.e., base value.+-.percentage points), and #PROP (proportional values, i.e., base value multiplied by percentages; the base value is always computed from the incoming portfolios). For example, suppose firms 3 and 4 both wish to individually constrain that the convexity of their resulting portfolios be greater than the convexity of their initial portfolios. Such a constraint is specified as follows:
firm numerator denominator method lower upper
3.vertline.4 #PV#CONV#ALL #PV #REL 0 1000
Here the zero lower bound guarantees that the original convexity cannot be lower than the resulting convexity. The large upper bound indicates that convexity is allowed to increase up to 1000% of the original value (essentially unlimited). At step 210 the portfolio attributes collected from the clients are supplemented with additional information in order to specify the full set of attributes for optimization. As discussed above, such additional data is obtained from remote databases, such as EJV, Capital Access, Fact Set, and Bloomberg. As discussed above, the EJV data is electronically accessed and translated for entry into the front end. Some attributes may need to be entered by an operator, for example, data from Bloomberg concerning uncommon bond. Next at 220 an optimization interface module 40 is invoked to translate the portfolio and constraint data, stored in the specified form in the front end 30, into a linear program format that can be processed by the optimization engine 190. The optimization interface can, for example, be implemented as a program written in C++. The optimization interface is described in further detail in connection with FIG. 4. The optimization engine at step 230 solves the linear programming matrix provided to it by the optimization interface. Although as indicated previously, the optimization engine is CPLEX, a commercial program from CPLEX Optimization Inc., an alternative optimization program capable of handling mixed integer linear programming can be used. (See description of CPLEX above and CPLEX Optimization, Inc. Using the CPLEX Callable Library. Version 4.0 930 Tahoe Blvd., Bldg. 802, Incline Village, Nev. 89451. http://www.cplex.com, 1995, incorporated herein by reference). As noted, in the preferred embodiment, CPLEX is installed on server 120. In this way, multiple front-end programs can access the remote optimizer over the network. After the optimizer has completed its processing, a transaction proposal is generated at step 240. After the clients review the transaction proposals, the system receives client feedback at step 250. If any client wants to modify the portfolio or constraint information, the processing goes back to step 200 and the steps described above are repeated. If all clients agree on the proposed transactions, as illustrated in FIG. 3, the system accepts at step 310 actual trading prices of the bonds from the corresponding traders. Specifically, a benchmark pricing module is invoked which automatically summarizes a tax swap transaction solution into forms appropriate for trader input. (In FIG. 1 the benchmark pricing module is illustrated as running on workstation 160). The bonds traded in the swap are automatically split among the appropriate traders and an appropriate benchmark Treasury is automatically computed for them. Since the tax swap requires a set of fair (mid-market) prices provided by the intermediary entity and agreed upon by all the parties, the benchmark pricing software module generates the mid-market prices at which all the bonds in the tax swap are traded. These prices are based on mid-market quotes from corporate traders of the intermediary entity, who is not part of the transaction. Rather than gathering up-to-date price quotes for each optimization during a given transaction, corporate bonds are quoted as a spread to the yield of a benchmark security (typically, a US Treasury (UST)). The bonds may also be quoted as a spread to the interpolated yield of two benchmarks or they may be quoted as simple prices. First the yields of currently traded US Treasuries are determined as known in the art. Instead of using all US Treasury prices, only the on-the-run prices are used. First, the closing prices of every UST and the market prices of all the on-the-runs are collected. Second, a butterfly portfolio for each UST is constructed using the two on-the-runs with the closest durations as barbells. Third, the change in the current present value of each UST is determined by that of the two ends of the barbell, taking into account the butterfly weights. Subsequently, the prices of the bonds used in a transaction are easily computed based on the spreads quoted by the traders. The yield of a bond is the yield of the benchmark plus the spread. The spread quoted may be based on yield to maturity, yield to call, yield to put, or yield to average life. The date corresponding to settlement of the final transaction has to be used when converting the bond yield to the final bond price. Upon receiving the actual trading prices from the traders, the optimization is repeated at step 320 and then the results are provided to the clients for a final approval. After all the clients approve the transaction, the tax swap transaction is executed (330). Alternatively in another preferred embodiment, the actual prices provided by traders may be entered into the system before the complete agreement of the parties on the final transaction has been reached. Specifically, in such an embodiment, the actual prices are introduced when the parties are in substantial but not complete agreement with respect to the proposed swap, so that several final iterations involving optimization are performed with the actual prices obtained from the traders. This embodiment modifies flowcharts of FIGS. 2 and 3 in the following manner. The decision 250 also includes a test of whether such a substantial agreement has been reached. If so, at this point, the actual prices are generated in accordance with the process discussed in connection with step 310 (benchmark pricing). Thereafter, the iterative process proceeds based on actual prices and not using the prices from external databases. When, at 250, the complete agreement has been reached, the transaction is executed. The Optimization interface module 40 is now described in further detail in connection with FIG. 4. The formulation of a linear programming problem for input to the optimization engine is specified in terms of an MPS file, which is an industry standard. Input to a linear programming optimizer can be expressed as essentially a system of equations, each of the form: a.sub.1 x.sub.1 +a.sub.2 x.sub.2 +a.sub.3 x.sub.3 + . . . +a.sub.n x.sub.n.ltoreq.b or a.sub.1 x.sub.1 +a.sub.2 x.sub.2 +a.sub.3 x.sub.3 + . . . +a.sub.n x.sub.n =b where a.sub.i are constant coefficients, x.sub.i are variables, b is a constant and n is the number of variables in the system. As known in the art, such expressions are represented in a matrix, which is the exemplary application can be very large, for example, with n of 16,000 and 10,000 equations. Although the matrix is large, most of the coefficients are usually zero. The MPS file format allows the use of a sparse matrix notation, specifying only the non-zero coefficients. A definition of the MPS format is provided in the CPLEX manual, http://www.cplex.com, using the CPLEX Callable Library, Version 4.0, from CPLEX Optimization Inc., 930 Tahoe Blvd., Bldg. 802, Incline Village, Nev. 89451, incorporated herein by reference. The MPS file of the preferred embodiment includes user constraints and system constraints. At step 410 the optimization interface 40 processes the data stored in the front end 30 so as to convert the formal representation of the constraints into a tree data structure stored in memory. Tree data structures are known in the art and form a portion of computer's memory. The tree data structure produced by the optimization interface comprises nodes representing logical operators and leafs representing sector names (or other constraint information). Such a tree data structure is traversed, as known in the art, in order to convert the formal description of the constraints into data formatted for processing by the optimization engine. The tree data structure is built by parsing the formal description of the constraints in the front end as textual strings using known techniques. Namely, the parenthesis are sorted first and then substrings are parsed left to right. At step 420, the interface 40 generates the part of the MPS file specifying the linear programming matrix for user constraints. Specified for every bond is a sector membership set (e.g., "FINL,AA"). Also, specified for every constraint is a logical sector specification (e.g., ".about.(AAA.vertline.AA)"). To generate a given constraint, the program loops through every bond (in all portfolios of all participants) and determines the following: (1) does this constraint apply to this bond? and (2) if so, what coefficients should this bond's linear programming variables receive? Two MPS inequalities are generated for each user constraint specified in the front end of the preferred embodiment, because both upper and lower bounds each require an inequality constraint. If the numerator variable is #ALL then the program does not check for sector inclusion: this bond will have non-zero coefficients. If the numerator variable is #SECTOR then the interface program 40 compares each component of the bond's sector membership set to the logical sector specification of the constraint. For example, if the bond is "FINL,AA" and the constraint is ".about.(AAA.vertline.AA)", then this bond is not bounded by the constraint and its coefficient is zero. To perform a logical comparison, the interface traverses the tree data structure discussed in connection with step 410. If the bond is constrained, the program determines the proper coefficient a.sub.i for each linear programming variable associated with the bond. A bond has BUY and SELL linear programming variables. Integer linear programming variables are also employed, for example, to prevent churning, wash sales, and ensure group exclusion. The numerator's value specification is used to compute a.sub.i, for example, #PV#DUR indicates that the coefficient a.sub.i is computed as the bond's present value times duration. The par amount is contributed by the value of the linear programming variable x.sub.i. The program also accounts for an optional denominator. To save MPS file preparation time, the program generates the denominator only once for both the upper and lower bounds. This is done by generating a new linear programming variable and creating an equality constraint for the denominator. ##EQU14## The equality coefficients are generated in a manner similar to the inequality coefficients previously discussed. The new linear programming variable is then appended to the end of upper and lower bounds inequalities. The coefficient of the new linear programming variable is the negative upper or lower bound, respectively, as illustrated below.
Lx .ltoreq. numerator .ltoreq. Ux
numerator .gtoreq. Lx
numerator .ltoreq. Ux
numerator - Lx .gtoreq. 0
numerator - Ux .ltoreq. 0
Next, at step 430, the program generates system constraints which include bound conservation constraints as well as other constraints discussed above in connection with the linear programming model. Group exclusion constraints to prevent churning, wash sales, and buying and selling among subsidiaries as discussed above are processed at step 440. These constraints are generated by the system without input from the clients. The programming of generating these constraints is apparent to a person skilled in the art from the previous discussion of these constraints. As noted at step 430, the optimization interface module 30 generates the part of the MPS file specifying the linear programming matrix for bond conservation and other linear programming constraints is generated. Similarly, at step 430, the optimization interface module generates the part of the MPS file specifying the integer linear programming matrix, namely the churning constraints, the wash sale constraints, and the group exclusion constraints are generated. The previously described preferred embodiment is neutral with respect to multiple firms, i.e., no firm is given an advantage over another. However, the resultant trades may distribute gains among the firms not completely evenly. Although, completely fair distribution of gains is difficult, the fairness of the distribution can be improved by utilizing one of the techniques discussed below, or other techniques known in the art. Although the solution which does not attempt to achieve a fair distribution is sufficient for the implementation of the preferred embodiment, alternative embodiments may include additional processing that addresses fairness as discussed below. One such approach to achieving fairness that may be used in an alternative embodiment is to employ a method developed by Shapley for constructing a "fair" solution to the classic coalition problem in game theory. See H. Raiffa, The Art and Science of Negotiation, Harvard University Press, Cambridge, 1982, incorporated herein by reference. The general problem considered by Shapley involves n players, each subgroup of which has a given, fixed utility. Usually the largest subgroup, i.e., the entire group, generates greater utility than any other partitioning of the players. The problem addressed by Shapley is to divide the gains among the players so that they all cooperate in a single large coalition rather than splitting apart into cliques. Shapley values give such a division based on fundamental principles, e.g., linear composition of solutions and no payments to players who contribute nothing. In formulating a tax swap as a coalition problem, the majority of a subgroup's utility is attributed by its tax loss, which can be evaluated with the optimizer for each subgroup. Two additional factors contributing to utility include: 1) a consideration that discount securities (priced below par), purchased in the swap, have a smaller future tax burden than par or premium securities, so that all players wish to swap in discount securities; and 2) by swapping among themselves, the firms have less total transaction costs than the market would charge, especially considering premiums due to the inelasticity of supply of discount bonds. Once these considerations are factored into the subgroup utilities, Shapley values can be computed, to determine a fair division of proceeds. In some alternative embodiments, it may also be desirable to tilt the objective function. Since the objective function thus far is to maximize total loss, it may be achieved through one firm receiving a disproportionate share of the tax loss relative to other firms. One method of rectifying the immediate book-loss and concomitant tax advantage bias is with the following objective function: ##EQU15## where a.sub.j >0 is a constant assigned to firm j in order to control the relative value of its book losses to the overall optimization. To negotiate an actual deal it is important for the entity acting as an intermediary to standardize security prices in the resulting trades in accordance to the market prices of the corresponding investments. As discussed above, the benchmark pricing module manages such a pricing. The standardized pricing gives the multiple parties to the swap confidence in the impartiality of the intermediary entity. Payment for the services of the intermediary may for example, come from a fixed percentage of realized tax deduction, or using another compensation scheme. Individual parties must be prevented or at worst dissuaded from "cherry picking" prices or securities, i.e., viewing the optimized trades and selectively committing to only certain trades. For example, a party which avoids an assigned buy trade that is perceived as too expensive is hoping to engage in a form of arbitrage. That party wants to buy at no worse than fair value, but of course does not identify the bonds it is selling above fair value. The intermediary entity must tightly control the timing of the swap, not allowing individual parties to stretch the target trade date. With time slippage comes the risk that the market will rally. If the market rallies, there will be fewer underwater securities in the pool and less losses embedded in each security. One technique of controlling timing is to limit participation and plan a series of swaps. The present invention is not to be limited in scope by the specific embodiments described herein. Indeed, modifications of the invention in addition to those described herein will become apparent to those skilled in the art from the foregoing description and accompanying figures. Doubtless, numerous other embodiments can be conceived that would not depart from the teaching of the present invention, which scope is defined by the following claims.
|
Same subclass Same class Consider this |
||||||||||