Vous êtes sur la page 1sur 40
GPU-Accelerated Stochastic Volatility Modeling Gerald A. Hanweck, Jr., PhD CEO, Hanweck Associates, LLC Eurex
GPU-Accelerated Stochastic
Volatility Modeling
Gerald A. Hanweck, Jr., PhD
CEO, Hanweck Associates, LLC
Eurex Quantitative Seminars
Chicago
May 17, 2011
Toronto
May 18, 2011
New York
May 19, 2011
Hanweck Associates, LLC
30 Broad St., 42nd Fl.
New York, NY 10004
www.hanweckassoc.com
Tel: +1 646-414-7274
1 © Hanweck Associates, LLC
May 17-19, 2011
Agenda Introduction Stochastic Volatility Review • Why Use Stochastic Volatility? • The Heston (1993) Stochastic
Agenda
Introduction
Stochastic Volatility Review
• Why Use Stochastic Volatility?
• The Heston (1993) Stochastic Volatility Model
A Primer on Graphics-Processing Unit (GPU) Computing
Using GPUs to Solve the Heston Model
Application: Fitting Eurex Euro-Bund Options
Questions
2 © Hanweck Associates, LLC
May 17-19, 2011
Stochastic Volatility Review 3 © Hanweck Associates, LLC May 17-19, 2011
Stochastic Volatility Review
3 © Hanweck Associates, LLC
May 17-19, 2011
Why Use Stochastic Volatility? Realized volatility is not constant over time Implied volatility is not
Why Use Stochastic Volatility?
Realized volatility is not constant over time
Implied volatility is not constant over time
Constant-volatility models (e.g., Black-Scholes) exhibit:
• volatility smiles
• volatility skews
Better modeling of volatility leads to:
• better hedging
• better risk management
4 © Hanweck Associates, LLC
May 17-19, 2011
Volatility Is Not Constant Bund Realized 3M vs Rolling Quarterly ATM Implied Volatility [Insert charts
Volatility Is Not Constant
Bund Realized 3M vs Rolling Quarterly ATM Implied Volatility
[Insert charts of bund implied and realized volatility since 2006]
12.00%
10.00%
8.00%
Realized Vol
6.00%
ATM Implied Vol
4.00%
2.00%
0.00%
5/28/05
10/10/06
2/22/08
7/6/09
11/18/10
4/1/12
Date
*Implied vol was calculated using the at the money front month quarterly options
rolled 3 weeks to expiration.
5 © Hanweck Associates, LLC
May 17-19, 2011
Vol
Volatility Smiles Implied Volatility of Expected Premium Example: 11.00% 10.80% • Options expire in 3
Volatility Smiles
Implied Volatility of Expected Premium
Example:
11.00%
10.80%
• Options expire in 3 months
10.60%
• Futures = 100
10.40%
10.20%
• Volatility to expiry can take, with
equal probability, one of three
levels: 5%, 10% or 15%.
10.00%
9.80%
95
96
97
98
99
100
101
102
103
104
105
Strike
Probability
1/3
1/3
1/3
Volatility
Expected
Implied
Strike
5%
10%
15%
Premium
Volatility
95
5.02
5.39
6.07
5.49
10.88%
100
1.00
1.99
2.99
1.99
10.00%
105
0.02
0.45
1.19
0.55
10.82%
call option premia
What’s going on?
As one moves away from the money, option premium becomes more convex in volatility, and
Jensen’s Inequality tells us that the expected premium will be greater than the premium at the expected volatility.
6 © Hanweck Associates, LLC
May 17-19, 2011
Volatility Smiles (cont’d) Example: Euro-Bund March 2009 Implied Volatility on January 5, 2009 Implied Volatility
Volatility Smiles (cont’d)
Example: Euro-Bund March 2009 Implied Volatility on January 5, 2009
Implied Volatility
10.80%
Futures = 124.65
10.60%
10.40%
10.20%
10.00%
9.80%
9.60%
9.40%
9.20%
9.00%
114
116
118
120
122
124
126
128
130
132
134
136
Strike
7 © Hanweck Associates, LLC
May 17-19, 2011
Volatility Skews • Volatility skews typically arise from correlation between volatility and underlying price
Volatility Skews
• Volatility skews typically arise from correlation between volatility and
underlying price (“directional volatility”).
• Correlation drivers include macroeconomic events, central-bank activity,
leverage and risk premia.
Euro-Bund December 2008 Implied Volatility on October 1, 2008
Implied Volatility
10.00%
Futures =
115.37
9.50%
9.00%
8.50%
8.00%
7.50%
During the throes of
the financial crisis,
just after Lehman
declared
bankruptcy, the
Euro-Bund volatility
skew steepened to
the call side (i.e.,
higher volatility at
lower yields)
7.00%
108
109 110 111
112 113 114
115 116
117
118 119
120
121 122
123 124 125
126
Strike Price
8 © Hanweck Associates, LLC
May 17-19, 2011
The Heston Model Let S represent the underlying asset price, and v represent its variance.
The Heston Model
Let S represent the underlying asset price, and v represent its
variance. Heston* represents their evolution through time as:
where z 1 and z 2 are Weiner processes correlated as ρ.
Convenient properties of the Heston model:
• stochastic volatility ⇒ volatility smiles
• correlation between underlying and volatility ⇒ volatility skews
• mean-reverting volatility
• extends Black-Scholes
• extensible to stochastic jumps (e.g., Bates, 1996)
• quasi closed-form solution for European call and put options!
* Heston, Steven L., “A Closed-Form Solution for Options with Stochastic Volatility with Applications to Bond and Currency Options,” The
Review of Financial Studies, 6(2), 1993, pp. 327-343.
9 © Hanweck Associates, LLC
May 17-19, 2011
The Heston Model: Quasi Closed-Form Solution Heston formula for pricing a European call option on
The Heston Model:
Quasi Closed-Form Solution
Heston formula for pricing a European call option on S with strike K, time
to expiration T, constant interest rate r, and market price of volatility risk λ:
10 © Hanweck Associates, LLC
May 17-19, 2011
Quasi-Closed-Form Solution (cont’d) f(x) Using Heston to price a European call or put option involves
Quasi-Closed-Form Solution (cont’d)
f(x)
Using Heston to price a European call or put
option involves numerically integrating two
complicated complex-valued functions.
Fitting the model to market data can require
hundreds of thousands of option pricing
evaluations.
Illustration of
numerical
integration
using the
Real-time applications require fast
calculations.
trapezoid rule
Unfortunately, numerical integration is
computationally intensive
embarrassingly parallel.
but it is also
EnterEnter thethe GPU!GPU!
x
11 © Hanweck Associates, LLC
May 17-19, 2011
Graphics-Processing Unit Computing 12 © Hanweck Associates, LLC May 17-19, 2011
Graphics-Processing Unit
Computing
12 © Hanweck Associates, LLC
May 17-19, 2011
Quantitative Finance: The Computation Conundrum As financial products and processes have grown in complexity •
Quantitative Finance:
The Computation Conundrum
As financial products and processes have grown in complexity
• Credit Default Swaps (CDS)
• Algorithmic Trading
• Collateralized Debt Obligations (CDOs)
• High-Frequency Trading
• Asset/Mortgage-Backed Securities
(ABS/MBS)
• Program Trading
• Risk Management
• Structured Finance
• Asset Valuation
their
computational needs have become more demanding
• Monte Carlo simulations
• Numerical optimization
• Binomial / trinomial trees & lattices
• Finite-difference / finite-element methods
• Numerical integration
• Digital signal processing (FFT)
• Matrix algebra
• Real-time data processing
and
compute-related resources are at a premium:
• Shrinking IT budgets
• Productivity growth
• Limited server rack space and power
• Increased regulatory demands
• Higher energy costs for servers and
cooling
• “Green” pressure
13 © Hanweck Associates, LLC
May 17-19, 2011
High-Performance Computing: Who Needs It? “In the ongoing arms race on Wall Street, high-performance computing
High-Performance Computing:
Who Needs It?
“In the ongoing arms race on Wall Street, high-performance computing (HPC),
also referred to as supercomputing, provides a huge competitive advantage that
no firm can afford to miss out on.”
– Wall Street & Technology, March 19, 2007.
Every firm in quantitative finance today needs more computing power!
Financial Institutions
Institutional Applications
• Investment Banks
• Risk Management
• Hedge Funds
• Financial Modeling &
Engineering
• Asset Managers
• Quantitative Analysis
• Insurance
Companies
• Portfolio Management
• Pension Plans
• Sales & Trading
• Mortgage Servicers
• Research
14 © Hanweck Associates, LLC
May 17-19, 2011
HPC in Finance Today Several hardware / software acceleration platforms exist today: • Conventional multi-core
HPC in Finance Today
Several hardware / software acceleration platforms exist today:
• Conventional multi-core CPU-based grids / clusters (MPI, OpenMP)
• GPUs and GPU-based clusters (NVIDIA Tesla/CUDA, AMD/ATI, OpenCL)
• FPGA accelerators (Celoxica, Exegy, Tervela, ACTIV)
• Specialized MPUs (IBM Cell, Tilera)
They are not mutually exclusive!
• CPUs excel at MIMD problems (multiple instruction, multiple data)
• GPUs are designed for SIMD problems (single instruction, multiple data)
• FPGAs handle SIMD and asynchronous real-time data processing well
• They can all be combined into optimized systems / clusters
15 © Hanweck Associates, LLC
May 17-19, 2011
Overview of Tesla C2050/C2070 GPU NVIDIA Tesla C2050 Specifications Processor clock 1.15 GHz # of
Overview of Tesla C2050/C2070 GPU
NVIDIA Tesla C2050 Specifications
Processor clock
1.15
GHz
# of CUDA cores
448
Peak floating-point perf
1.03
Tflops (SP)
Memory clock
1.5 GHz
Memory bus width
384 bit
Memory size
3 GB / 6 GB
Source: NVIDIA
16 © Hanweck Associates, LLC
May 17-19, 2011
GPUs = Higher Flops and Memory Bandwidth 1200 Peak Double Precision FP GFlops/sec 250 Peak
GPUs = Higher Flops and Memory
Bandwidth
1200
Peak Double Precision FP
GFlops/sec
250
Peak Memory Bandwidth
GBytes/sec
Kepler
Kepler
1000
200
Fermi+
M20xx
800
Fermi
Fermi+
M2070
150
M20xx
Fermi
600
M1060
M2070
100
400
8‐core
Sandy Bridge
8 ‐core Sandy
Bridge
3 GHz
3 GHz
Westmere
Nehalem
Westmere
M1060
50
200
3 GHz
3 GHz
Nehalem
3 GHz
3 GHz
0
0
2007 2008
2009 2010
2011 2012
2007
2008 2009
2010 2011
2012
Double Precision: NVIDIA GPU
Double Precision: x86 CPU
NVIDIA GPU (ECC off)
x86 CPU
17 © Hanweck Associates, LLC
May 17-19, 2011
Source: NVIDIA
DRAM I/F I/F DRAM I/FDRAM I/F DRAM DRAM I/F I/F DRAM DRAM I/F I/F DRAM
DRAM I/F I/F
DRAM I/FDRAM I/F
DRAM
DRAM I/F I/F
DRAM
DRAM I/F I/F
DRAM
GPU Architecture:
Two Main Components
Global memory
Analogous to RAM in a CPU server
Accessible by both GPU and CPU
Currently up to 6 GB
Bandwidth currently up to 150 GB/s
for Quadro and Tesla products
ECC on/off option for Quadro and
Tesla products
Streaming
Multiprocessors
(SMs)
L2L2
Streaming Multiprocessors (SMs)
Streaming
Multiprocessors
Perform the actual computations
Each SM has its own control units,
registers, execution pipelines,
caches
(SMs)
Source: NVIDIA
18
© Hanweck Associates, LLC
May 17-19, 2011
DRAM I/FDRAM I/FDRAM
I/F I/F
Giga Thread
HOST
HOST I/F I/F
DRAM
I/FDRAM I/F I/FDRAM DRAM I/FDRAM NVIDIA GPU Architecture Instruction Cache Scheduler Scheduler Dispatch Dispatch
I/FDRAM
I/F
I/FDRAM
DRAM I/FDRAM
NVIDIA GPU Architecture
Instruction Cache
Scheduler
Scheduler
Dispatch
Dispatch
Register File
32
CUDA cores per streaming
Core
Core
Core
Core
multiprocessor (512 total)
Streaming
Core
Core
Core
Core
Multiprocessors
8x peak double precision
floating point performance
(SMs)
Core
Core
Core
Core
Core
Core
Core
Core
(50% of peak single precision)
L2L2
Core
Core
Core
Core
Dual Thread Scheduler
Core
Core
Core
Core
Streaming
64
KB of RAM for shared
memory and L1 cache
(configurable)
Multiprocessors
Core
Core
Core
Core
(SMs)
Core
Core
Core
Core
Load/Store Units x 16
Special Func Units x 4
Source: NVIDIA
Interconnect Network
64K Configurable
Cache/Shared Mem
Uniform Cache
19
© Hanweck Associates, LLC
May 17-19, 2011
I/FDRAM
I/F
Giga Thread
DRAM I/FHOST
Kernel Execution CUDA thread CUDA core • Each thread is executed by a core CUDA
Kernel Execution
CUDA thread
CUDA core
• Each thread is executed
by a core
CUDA Streaming
Multiprocessor
• Each block is executed by
one SM and does not
migrate
CUDA thread block
• Several concurrent blocks
can reside on one SM
depending on the blocks’
memory requirements and
the SM’s memory
resources
CUDA‐ enabled GPU
• Each kernel is executed
CUDA kernel grid
on one device
• Multiple kernels can
execute on a device at one
time
20 © Hanweck Associates, LLC
May 17-19, 2011
Source: NVIDIA
CUDA Overview Execution CPU code passes control to GPU functions called kernels Data is transferred
CUDA Overview
Execution
CPU code passes control to GPU functions called kernels
Data is transferred between CPU to GPU memory via DMA copies
Threading
A kernel operates on a grid of thread blocks (up to 65,535 x 65,535
x 65,535)
Each thread block runs multiple threads (up to 1,024 per thread
block)
Threads are grouped into SIMD-like warps (32 threads)
Memory
GPU DRAM, or global memory, or device memory (multiple
gigabytes) with L2 cache; generally slow (hundreds of clocks)
Per SM shared memory / L1 cache (64KB) arranged in 32 banks;
generally fast (2 clocks)
Registers; very fast, but limited resource
Constant memory (64KB shared by all SMs, read only by kernel
code)
Texture memory (spatially cached global memory with rudimentary
interpolation, up to 65,536 x 65,535 elements, read-only by kernel
code)
Source: NVIDIA
21 © Hanweck Associates, LLC
May 17-19, 2011
Anatomy of a CUDA C/C++ Application CUDACUDA C/C++C/C++ ApplicationApplication Host = CPU SerialSerial codecode
Anatomy of a CUDA C/C++ Application
CUDACUDA C/C++C/C++
ApplicationApplication
Host = CPU
SerialSerial codecode
Serial code executes in
a Host (CPU) thread
Device = GPU
ParallelParallel codecode
Parallel code executes
in many Device (GPU)
thread across multiple
processing elements
Host = CPU
SerialSerial codecode
Device = GPU
ParallelParallel codecode
Source: NVIDIA
22 © Hanweck Associates, LLC
May 17-19, 2011
CUDA C : C with a few keywords Kernel: function called by the host that
CUDA C : C with a few keywords
Kernel: function called by the host that executes on the GPU
Can only access GPU memory
No variable number of arguments
No static variables
Functions must be declared with a qualifier:
global
device
host
: GPU kernel function launched by CPU, must return void
: can be called from GPU functions
: can be called from CPU functions (default)
host
and
device
qualifiers can be combined
23 © Hanweck Associates, LLC
May 17-19, 2011
CUDA C : C with a few keywords void saxpy_serial(int n, float a, float *x,
CUDA C : C with a few keywords
void saxpy_serial(int n, float a, float *x, float *y)
{
Standard C Code
for (int i = 0; i < n; ++i)
y[i] = a*x[i] + y[i];
}
// Invoke serial SAXPY kernel
saxpy_serial(n, 2.0, x, y);
global
void saxpy_parallel(int n, float a, float
*x, float *y)
{
int i = blockIdx.x*blockDim.x + threadIdx.x;
Parallel C Code
if (i < n)
y[i] = a*x[i] + y[i];
}
// Invoke parallel SAXPY kernel with 256 threads/block
int nblocks = (n + 255) / 256;
saxpy_parallel<<<nblocks, 256>>>(n, 2.0, x, y);
24 © Hanweck Associates, LLC
May 17-19, 2011
CUDA Overview Performance Tips Coalesce Global Memory Accesses Global memory is read/written as 32-, 64-
CUDA Overview
Performance Tips
Coalesce Global Memory Accesses
Global memory is read/written as 32-, 64- or 128-byte transactions (naturally aligned)
A warp can access a naturally aligned contiguous group of 32, 64 or 128 bytes in a single
coalesced memory transaction
Uncoalesced memory accesses require multiple transactions, reducing performance
While L1 and L2 caches can mitigate some of the performance hit, try to coalesce memory
accesses as much as possible (e.g., organize data contiguously, use padding)
Avoid Bank Conflicts
Shared memory is organized into 32 banks
A bank conflict occurs if two or more threads in a warp access different 32-bit words in the same
bank
A warp can access all 32 banks in one transaction as long as there are no bank conflicts
A bank conflict requires the shared-memory access to be broken up into multiple transactions,
reducing performance (sometimes severely)
Try to avoid bank conflicts if at all possible by organizing data in shared memory appropriately
25 © Hanweck Associates, LLC
May 17-19, 2011
CUDA Overview Performance Tips (cont’d) Avoid Divergent Branches All threads in a warp run in
CUDA Overview
Performance Tips (cont’d)
Avoid Divergent Branches
All threads in a warp run in SIMD fashion
If threads take divergent branches (e.g., in an if-else clause or a loop), the different paths are
serialized, which can severely reduce performance
Try to avoid divergent branches if possible (e.g., use arithmetic operations, group similar threads
together)
Use Constant Memory
Useful for static model parameters, covariance matrices, cashflow schedules, call schedules, etc.
Limited to 64KB, read-only by the kernel
Fast, particularly when all threads in a warp should read the same location
Use Texture Memory
Useful for static model parameters, covariance matrices, cashflow schedules, call schedules, etc.
Can be very large, read-only by the kernel
2-D arrays in texture memory benefit from spatial caching
Best performance is achieved when reads are clustered together in the 2-D array
26 © Hanweck Associates, LLC
May 17-19, 2011
CUDA Programming Resources CUDA Toolkit Compiler, libraries, and documentation Free download for Windows, Linux, and
CUDA Programming Resources
CUDA Toolkit
Compiler, libraries, and documentation
Free download for Windows, Linux, and MacOS
GPU Computing SDK
Code samples
Whitepapers
GPU Tools
Profiler – GUI or Command-line tool used to inspect memory
access and kernel execution patterns
Debugger
• Linux: cuda-gdb
• Windows: Parallel Nsight
27 © Hanweck Associates, LLC
May 17-19, 2011
Using GPUs to Solve the Heston Model 28 © Hanweck Associates, LLC May 17-19, 2011
Using GPUs to Solve the Heston
Model
28 © Hanweck Associates, LLC
May 17-19, 2011
Numerical Integration f(x ) • Each thread evaluates one piece of the integral and saves
Numerical Integration
f(x )
• Each thread evaluates one piece of the
integral and saves the result to shared
memory
• Each thread block then performs a sum
reduction on all points evaluated within
the thread block
• One value from each thread block is
saved to global memory and copied
back to host memory
x
• These results are then summed on the
CPU to compute the value of the
integral. If many thread blocks are
needed in the first kernel call, then
another sum reduction kernel can be
executed to compute this sum
29 © Hanweck Associates, LLC
May 17-19, 2011
Sum Reduction 3 1 7 0 4 1 6 3 3 1 7 0 4
Sum Reduction
3
1
7
0
4
1
6
3
3
1
7
0
4
1
6
3
3
1
7
0
4
1
6
3
3
1
7
0
4
1
6
3
3
1
7
0
4
1
6
3
3
1
7
0
4
1
6
3
3
1
7
0
4
1
6
3
3
1
7
0
4
1
6
3
4
7
5
9
4
7
5
9
4
7
5
9
4
7
5
9
4
7
5
9
4
7
5
9
4
7
5
9
4
7
5
9
11
14
11
14
11
14
11
14
11
14
11
14
11
14
11
14
25
25
25
25
25
25
25
25
Level 0:
8 blocks
3
1
7
0
4
1
6
3
Level 1:
4
7
5
9
11
14
1 block
25
• A sum reduction technique is used to sum the value of the Heston
integral
• As shown above, multiple kernel call can be used to perform the sum if
many points need to be evaluated
30 © Hanweck Associates, LLC
May 17-19, 2011
Application: Fitting Eurex Euro-Bund Options 31 © Hanweck Associates, LLC May 17-19, 2011
Application:
Fitting Eurex Euro-Bund Options
31 © Hanweck Associates, LLC
May 17-19, 2011
Data and Methodology Data • Eurex Euro-Bund futures and options end-of-day settlement prices • Jan
Data and Methodology
Data
• Eurex Euro-Bund futures and options end-of-day settlement prices
• Jan 2006 – April 2011
Fitting Methodology
• Out-of-the-money options with premium greater than 0.01
• Minimize least-squares difference between market and model option
premium (equivalent to vega weighting implied volatility differences, but
more robust)
• Euro-Bund options are American style, but futures-style margining
makes early-exercise suboptimal, so European Heston model applies
(see Wu & Vischer, 2009)
• Can fit to individual expiry or surface; for one day or many; allow all
parameters to vary or fix some (fitting is an art!)
32 © Hanweck Associates, LLC
May 17-19, 2011
Benchmarks NVIDIA Tesla C2070 GPU vs. Intel Xeon E5640 @2.67 GHz (singe core) Time to
Benchmarks
NVIDIA Tesla C2070 GPU vs. Intel Xeon E5640 @2.67 GHz (singe core)
Time to price 10,000 options
• CPU: 348.2 seconds
• GPU: 5.1 seconds
Option pricings per second
• CPU ~ 30 /s
• GPU ~ 2000/s
GPU gives about 70x performance gain!
33 © Hanweck Associates, LLC
May 17-19, 2011
Euro-Bund Options Expiring September 2011 Fitted Premiums 1.8 Fit performed on 04/12/2011 settlement prices for
Euro-Bund Options Expiring
September 2011
Fitted Premiums
1.8
Fit performed on 04/12/2011
settlement prices for out of the
money options expiring 09/2011
1.6
Fitted Puts
Fitted Calls
1.4
Market Puts
1.2
Market Calls
1
0.8
0.6
Fitted Heston Parameters
0.4
0.2
V
0.0033334
0
0
V
0
110
115
120
125
130
135
Strike (€)
inf
Heston Fitted Vols
κ
0
6.80%
6.60%
σ
0.0769625
6.40%
ρ
0.0290827
6.20%
λ
0
6.00%
5.80%
*κ and λ forced to 0
5.60%
Heston Implied Vols
Market Implied Vols
5.40%
105
110
115
120
125
130
135
Strike (€)
34
© Hanweck Associates, LLC
May 17-19, 2011
Vol
Premium (€)
September 2011 Euro-Bund Surface Heston Fitted Vols for 07/2011 Options 7.90% Fit performed on 04/12/2011
September 2011 Euro-Bund Surface
Heston Fitted Vols for 07/2011 Options
7.90%
Fit performed on 04/12/2011
settlement prices for out of the
money options expiring 07/2011
and 09/2011
Heston Implied Vol
Market Implied Vol
7.40%
6.90%
6.40%
5.90%
Fitted Heston Parameters
5.40%
V
0.00315456
0
105
110
115
120
125
130
135
Strike (€)
V
0.02133107
inf
Heston Fitted Vols for 09/2011 Options
6.80%
κ
0.05127899
6.60%
σ
0.07871576
6.40%
6.20%
ρ
0.03037642
6.00%
λ
0
5.80%
Heston
Implied Vols
5.60%
Market
Implied Vols
*λ forced to 0
5.40%
105
110
115
120
125
130
135
Strike (€)
35 © Hanweck Associates, LLC
May 17-19, 2011
Vol
Vol
Stability Of Parameters – September 2011 Euro-Bund Options √V0 0.08 V 0 and κ parameters
Stability Of Parameters –
September 2011 Euro-Bund Options
√V0
0.08
V 0 and κ parameters show stability over
time for a fitted option chain
0.07
0.06
0.05
0.04
0.03
0.02
0.01
0
2/26/11
3/8/11
3/18/11
3/28/11
4/7/11
4/17/11
Date
Sigma
Rho
0.25
0.14
0.2
0.12
0.15
0.1
0.1
0.05
0.08
0
-0.05
0.06
-0.1
0.04
-0.15
-0.2
0.02
-0.25
0
-0.3
2/26/11
3/8/11
3/18/11
3/28/11
4/7/11
4/17/11
2/26/11
3/8/11
3/18/11
3/28/11
4/7/11
4/17/11
Date
Date
36
© Hanweck Associates, LLC
May 17-19, 2011
Rho
Sigma
√V0
Concluding Remarks 37 © Hanweck Associates, LLC May 17-19, 2011
Concluding Remarks
37 © Hanweck Associates, LLC
May 17-19, 2011
Concluding Remarks The Heston model applied to Euro-Bund options provides a reasonable model for individual
Concluding Remarks
The Heston model applied to Euro-Bund options provides a
reasonable model for individual volatility skews; less reasonable for
entire surfaces (particularly very short-dated options)
Some parameters (mean reversion, market price of risk) might need
to be fixed / removed due to limited degrees of freedom
Some parameters (rho) might benefit from fitting over time
GPU-based acceleration reduces Heston model valuation time by
orders of magnitude, making real-time pricing and fitting feasible
GPU-based acceleration is applicable to other models that require
numerical integration, lattices or Monte-Carlo techniques
38 © Hanweck Associates, LLC
May 17-19, 2011
References Bates, David S., “Jumps and Stochastic Volatility: Exchange Rate Processes Implicit in Deutsche Mark
References
Bates, David S., “Jumps and Stochastic Volatility: Exchange Rate Processes Implicit in
Deutsche Mark Options,” The Review of Financial Studies, 9(1), 1996, pp. 69-107.
Heston, Steven L., “A Closed-Form Solution for Options with Stochastic Volatility with
Applications to Bond and Currency Options,” The Review of Financial Studies, 6(2),
1993, pp. 327-343.
West, Graeme, “Calibration of the SABR Model in Illiquid Markets,” Applied
Mathematical Finance, 12(4), 2005, pp. 371-385.
Wu, Shengxiong, and Axel Vischer, “Similarities and Differences of the Volatility Smiles
of Euro-Bund and 10-Year T-Note Futures and Options,” Eurex working paper,
November 2009.
39 © Hanweck Associates, LLC
May 17-19, 2011
This presentation has been prepared for the exclusive use of the direct recipient. No part
This presentation has been prepared for the exclusive use of the direct recipient. No part of this presentation
may be copied or redistributed without the express written consent of the author. Opinions and estimates
constitute the author’s judgment as of the date of this material and are subject to change without notice.
Information has been obtained from sources believed to be reliable, but the author does not warrant its
completeness or accuracy. Past performance is not indicative of future results. Securities, financial instruments
or strategies mentioned herein may not be suitable for all investors. The recipient of this report must make its
own independent decisions regarding any strategies, securities or financial instruments discussed. This material
is not intended as an offer or solicitation for the purchase or sale of any financial instrument.
Copyright © 2011 Hanweck Associates, LLC.
All rights reserved.
Additional information is available upon request.
40 © Hanweck Associates, LLC
May 17-19, 2011