From mailer@stamper.itconsult.co.uk Sun Apr 3 00:24:27 2005 Return-Path: Received: from m13.itconsult.net (m13.itconsult.net [193.201.42.13]) by mail.info-bazar.net (8.13.3/8.13.3) with ESMTP id j32GONKN006168 for ; Sun, 3 Apr 2005 00:24:25 +0800 Received: from stamper.itconsult.co.uk (stamper.itconsult.co.uk [193.201.42.31]) by m13.stamper.itconsult.co.uk (GMS 10.03.3304/NT8923.00.5408c509) with SMTP id ecggghaa for josh@mail.info-bazar.net; Sat, 2 Apr 2005 17:23:39 +0100 From: Stamper To: josh@mail.info-bazar.net Subject: Clear Stamped 0269751:no subject (file transmission) Message-Id: <0269751.a@stamper.itconsult.co.uk> Date: Sat, 2 Apr 2005 17:23:39 +0100 Status: RO Stamper is a service provided free of charge to Internet users. You are very welcome to use Stamper, but you may only do so if you have first read our Terms of use, which exclude liability on our part and which provide for you to indemnify us against any potential liability arising from your use of Stamper. By using Stamper you warrant that you have read and accept the Terms. The Terms of use are available by sending email to info@stamper.itconsult.co.uk or from the web page http://www.itconsult.co.uk/stamper.htm. -----BEGIN PGP SIGNED MESSAGE----- ######################################################## # # The text of this message was stamped by # stamper.itconsult.co.uk with reference 0269751 # at 16:23 (GMT) on Saturday 02 April 2005 # # For information about the Stamper service see # http://www.itconsult.co.uk/stamper.htm # ######################################################## - -----BEGIN PGP SIGNED MESSAGE----- = Computation Financial Engineering Approach = == Abstract == In this article, I present a general way to attack financial engineering problems such as finding the hedge plan and the valuation thereby. I don't attack these problems from the probability or martingale theory approach because in my humble opinion those approaches are somewhat academic fun only and lose focus on essential issues. The approach works well with programming both with simulation and tree, therefore is more practical in real application. == Index == 0 State: the coordinate in rational mind 0 Tree: live forward and think backward 0 Risk neutral: why 0 Simulation: without probability 0 Example == State: the coordinate in rational mind == The dynamic hedge differs from static hedge in that the dynamic hedge is a hedge plan based on the state while the static hedge has no concept of state. To be afraid of the death in a travel we buy travel insurance in the airport, this is a static hedge, since all the hedge action is done at the start and no other action is required later. To be afraid of missing the elevators, we monitor the floor indicator of each elevator and walk back and forth to the front of the elevator which we think is most likely the one we will take, this is a dynamic hedge, since at the start we didn't know which hedge action we would take. The state in the elevator story is all the floor indicators of the elevators. We may extend the state concept further, say, we notice one cargo boy who will stop on the 15th floor while we are going to 20th floor. Since he will take much longer time to move the cargo, we may choose not to take the same elevator with him. Now the state is extended with one additional dimension: "is the cargo boy around?". Dynamic hedge is simply a _hedge plan_ about what to do in what _state_. Sometimes, the current situation may map onto multiple states, if so, multiple hedges are executed simultaneously. Back to financial engineering. For European style option, usually the state means the current market factors. For an Asian style option, usually the state means the history of the market factors. Very often, the dimension of the state is too high for us to handle, so, we will sometimes artificially shrink the dimension of the state. For example, for the Asian style option we just mention, we may rather choose the sum of the history market factor and the current market factor as the state. For structured notes, the state may include many market factors. With a snowball feature, state may become a high dimensional monster. That is why the structured note is the realm where lacks the footprints of the financial engineers. == Tree: live forward and think backward == As long as the dimension of the state is high, many beautiful methodologies including dynamic programming (i.e. tree) lose the stage to dance. The beauty of the tree is that, it is really compact. With some risk-neutral probability, all we have to do is calculate the expectation value backward and compare that value with an exercise action; tree may be the first tool all the financial engineers learn about. The hazard of the tree is that it can not handle history-dependent style product and the high dimension of state causes the number of the nodes on the tree grows exponentially. The expectation present value is vivid in the implementation of the tree model; we need to calculate it at each node by discounting its ascending nodes. == Risk neutral: why == We are now to mention about one essential issue that many financial engineers forget about: why we need to calculate the expectation. Suppose we have a product A which has a contingent payoff, and we now want to value this product. Suppose we can have a hedge deal H such that the total payoff becomes a fixed number /*fixed*/ ; by the arbitrage principle, the future value of A must be the number /*fixed*/. In math: for every scenario s, A+H=fixed Therefore, we can take the expectation under *_any_* probability measure and get: fixed=E[A+H]=E[A]+E[H] Now, if we impose a special measure on the stochastic process such that the expectation of H is zero, then we come to the conclusion that we can calculate out the future value of the trade A by simply taking the expectation of the trade A under the so-called /risk-neutral/ or /martingale/ measure: fixed=E[A] Note that the number /fixed/ appears in the above argument simply by arbitrage, nothing to do with the probability. However, financial engineers tend to forget this and tend to build some martingale models such that the expectation can be formulated more easily, the so-called _closed form_. An infamous story is, lately, I talked with a trader about how to hedge the FX risk in the quanto swap which has a closed form answer in the Libor rate model, she said that the correlation risk can not be hedged. This is really weird for me since I don't think one can know the value of the financial product unless one knows the hedge plan. In my opinion, it is much better if we know the dynamic hedge plan even in a limited ration, say, shrunken state; financial engineering shall not be a black art. == Simulation: without probability == The simulation approach may be the first tool for human to take to handle with uncertainty. This approach is justified once the stochastic process is risk-neutral, then by the Chebyshev inequality, the average of the simulation will tend to the expectation and the expectation is the answer to the valuation question. Simulation comes to rescue our life because it can handle complex product and high dimension state. This tool for European product is wonderful, however, we would have the trouble when we need to know some action plan for American or Bermudan style product since the hedge action is figured out backward in a Tree style and the traditional simulation is a never-backward mechanism. Many approach for the tough situation were proposed, many among them are good attempt, but they still fall into the expectation jail, i.e., a martingale stochastic process about market factors must be set up in advance. In this context. the hazard of financial engineers is that they tend to forget about real world and build some probability-happy process and compromise the applicability with the model risk. To use simulation approach, we have to face the trouble to build probability-happy model which is not quite easy, but do we need to face this trouble? After all, by the argument above, we don't need it at the first place, the probability came into the show accidentally and ironically became the major role of the show, and this is really weird. My approach is as follow. The first step is to decide what state is. After that, we define a grid over the state. Since we don't have to build a probability-happy process for the market factors, we can model market factors in realistic way like an empirical scientist; one example is in the Example section where we model interest rate as well as equity like a real scientist. The following goal is to find the hedge plan on the value of a future date on which all the contingencies vanish so it is naturally the _maturity date_. When the above is decided, we run a program doing the simulation; for each scenario, as time starts from now into the future, we reach some states and the correspondent hedge action is triggered, including the exercise decision or the purchase of the hedge deals. So far, we can not assure the Boolean (for exercise decision) or size (for ordinary hedge deal) of the hedge action so we just calculate the hedge actions' _one_ unit contribution of the value on the maturity date in this scenario. Apparently, we now have a _linear formula_ for the value on maturity date in this scenario: the coefficient is the one unit contribution of the value on the maturity date, the variable is the hedges' Boolean or size. After running over all the scenarios, we are now facing a _linear programming_ (LP) problem. The goal is to maximize the minimum value among entire scenarios. Why this goal? This is kind of philosophy I learn from game theory (financial engineer is always playing game with the market, isn't it?) Thinking the perfect hedge situation where all the value is the same, by the nature of LP, it is impossible that we have a variables setting such that the maximum is 100 and the minimum is 80 while with another variables setting such that the maximum and the minimum is both 70. With this goal, we will tend to find the perfect dynamic hedge. When the LP is done, the maximum and the minimum value among entire scenarios may be the same or not, i.e., perfect hedge or not. In perfect hedge situation, we discount that future value to now by the current yield curve to get the present value (i.e. the valuation, the price). In imperfect situation, we take the proper one as the valuation result by our position side and may average out these values for reporting purpose and face the truth that given the available hedging tools we didn't come to a perfect hedge plan but we had done our best to stable the future values among entire scenarios. Further, now we have the variables setting, i.e., the hedge Boolean/size at each state, in short, we come to a hedge plan in hand; this is much better than traditional probability approach where we know nothing about the hedge even we come to a valuation price. The availability of perfect hedge plan is closely related to the rank of the matrix in the LP. Usually the simulation number is larger than the number of hedge action, in this situation, it is impossible to get a perfect hedge plan by linear algebra theory. As all the traders know, the more hedge tools can be used and the more state in trader's mind (i.e. the size of the hedge plan), the better the hedge performance (i.e. the interval between the maximum and the minimum value) is. Under my approach, financial engineering problem becomes a computational problem, we use computer to extend our brain to handle the state and to find the hedge plan. Currently, the state grid is defined by human, someday not quite a future, maybe we can have a computational algorithm to help on the finding of the best states' definition required in my approach. == Example == This example is a concept-proof of my approach. The product in question is an American equity option in a floating interest rate context. The valuation is handled by simulation. Note that my approach works in a Tree context as well. In fact, in this example, I use a tree to store the simulation data structure. For a serious simulation, it is impossible to store these data this way; a simulation shall be implemented in iterated style. From point of view of software design, the _scenario_ and the _approach_ and the _product_ specification shall be separated and this is left as an exercise if you are really serious about this article (i.e. good reader). I use perl and a well-known GNU LP library to accomplish the code. #!/usr/bin/perl use Math::LP qw(:types); use Math::LP::Constraint qw(:types); use strict; # market factor scenarios my $mf=[ [[15,2],[20,1],[30,1],[32,1.2]], [[15,2],[20,1],[30,1],[25,1.5]], [[15,2],[20,1],[15,1.5],[18,1.5]], [[15,2],[20,1],[15,1.5],[12,2]], [[15,2],[10,3],[15,2.5],[16,2.3]], [[15,2],[10,3],[15,2.5],[11,2.6]], [[15,2],[10,3],[8,4],[10,2.5]], [[15,2],[10,3],[8,4],[5,4.2]] ]; my $pathnum=8; my $horizon=3; # state grid setting my @diameter; $diameter[0]=1; $diameter[1]=0.5; $diameter[2]=0.05; my @st; $st[0]=0; $st[1]=1.3; $st[2]=0.81; # hedge plan my %h; my $lp= new Math::LP; my $y= new Math::LP::Variable(name=>"low", lower_bound=>-10000); $lp->maximize_for( make Math::LP::LinearCombination($y, 1.0) ); my @constraint; for my $i (0..$pathnum-1) { my @e; my @e1; for my $t (0..$horizon-1) { # current market factor my $s=$mf->[$i]->[$t]->[0]; my $r=$mf->[$i]->[$t]->[1]; if (my $state_id=reached_state($t, $s, $r)) { my $hedge_id; # if ($t==$horizon-1) { # European # for 1st hedge, the decision to exercise $hedge_id=$state_id; unless (defined($h{$hedge_id})) { $h{$hedge_id} = new Math::LP::Variable(name=>"h$hedge_id", is_int =>1); } push @e, $h{$hedge_id}, $mf->[$i]->[$horizon]->[0]- deposite($i, $t, 15); push @e1, $h{$hedge_id}, 1; # } # for 2nd hedge, the underlying stock hedge $hedge_id=$state_id . 's'; unless (defined($h{$hedge_id})) { $h{$hedge_id} = new Math::LP::Variable(name=>"h$hedge_id", lower_bound =>-10000); } push @e, $h{$hedge_id}, $mf->[$i]->[$horizon]->[0] - deposite($i, $t, $s); } } push @e, $y, -1; for (0..(($#e-1)/2)) { print $e[2*$_]->[1], '*', $e[2*$_+1], ' + '; } print "\n"; my $constraint = new Math::LP::Constraint( lhs => make Math::LP::LinearCombination(@e), rhs => 0, type => $GE, ); $lp->add_constraint( $constraint ); push @constraint, $constraint; for (0..(($#e1-1)/2)) { print $e1[2*$_]->[1], '*', $e1[2*$_+1], ' + '; } print "\n"; $lp->add_constraint(new Math::LP::Constraint( lhs => make Math::LP::LinearCombination(@e1), rhs => 1, type => $LE, ) ); } $lp->solve; my $fv=$lp->optimum; print "== future value ==\n$fv\n"; print "== hedgeID : hedge Boolean/size ==\n"; for (keys %h) { print ' ', $h{$_}[1], ' : ', $h{$_}[2], "\n"; } my @dis = map {$_->{'slack'} + $fv } @constraint; @dis = sort {$a <=> $b} @dis; print "== value among scenarios (assending order) ==\n" . join(', ', @dis) ."\n"; ## the states reached; return the stateID sub reached_state { my @a=@_; my @i; for (0..$#a) { $i[$_] = int(($a[$_]-$st[$_])/$diameter[$_]+0.5); } return join('_', @i); } ## future value of floating deposit sub deposite { my $scenario=shift; my $t=shift; my $m=shift; for ($t..$horizon-1) { $m *= 1 + $mf->[$scenario]->[$_]->[1] /100; } return $m; } - -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQB1AwUBQk7G21Y6lNZmmS4NAQHaHwMAq7JwiehJNWDXHLAQInggWAStAOxMbqxe 0+S6fIPZVNQhOCJK7426F+kK8OS4n79CML4Al87TaZbpJpCauB3XQaG7LCUxGRy3 MjVbxlX+OO59OmR52QT69Fj9eIkzFDK1 =9niZ - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Stamper Reference Id: 0269751 iQEVAgUBQk7HB4GVnbVwth+BAQHbpQf+IqGq2wH2yYzFAJ8fvPVvd+udpFIJpzhR t0sZxhAysdNhuMKo4kEtiKZ3KSgZehdZV6PJef953eqTa+H54zC5MdpqY+Ykcwo9 c4e/7s3AbMFIrVGMEQV6QrOkCInp4iYrOrZD330XHYsbnnzXOGp5Mhdw10whSmlJ ipFPjqNZk4TPza6Mp5HPg1faA5YXja9dbUS6KjZfZdB1IzUXH1Sze/Gxjg54+4be RqdnMe+hr5i6RZ0fTOV1gT8HjS6G9MlRstkCQlk0C74Z9OHEMYVqqoe5nKi3vUR8 PX/kbV67QqCcZb4l3hfKSRnnEaYnxoM+cGItXXYmAtXnsQ9GD+zWhA== =m2cE -----END PGP SIGNATURE-----