From mailer@stamper.itconsult.co.uk Sun Apr 3 00:24:27 2005
Return-Path: <mailer@stamper.itconsult.co.uk>
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 <josh@mail.info-bazar.net>; 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 <mailer@stamper.itconsult.co.uk>
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-----