Calculting Strike from Delta on an FX Risk Reversal Component
Calculting Strike from Delta on an FX Risk Reversal Component
Loading saved threads...
Attack68 · External communityPost link
External question — Quantitative Finance Stack Exchange
Author: Attack68
Original post: https://quant.stackexchange.com/questions/77783
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
As part of a trade confirmation I have the following information:
FXCall
On: 20mm EUR versus 22.02mm USD
Trade Date: 16 March 23
Spot: 1.0615
Swap points: 60.1 # implied forward 1.06751
Volatility: 8.9%
Expiry: 16 Jun 23
Delivery: 20 Jun 23
Strike: 1.101
Option Price: 70.25 USD points per EUR
Premium: USD 140,500
Premium payment: 20 Jun 2023
For refence the 3m SOFR rate on 16 Mar 23 was around 4.78%, and the 3M ESTR rate 2.93%.
This was part of a 25% delta risk-reversal, which means the broker derived the strike from the given delta (25%) and the volatility as stated.
I cannot derive exactly the strike value 1.101, which leads to the question:
Do interbank FX options transactions calculate strikes versus spot delta, as standard, and not forward delta?
(I get closer using a spot delta and not a forward delta)
Do interbank FX options transactions use anything other than black scholes derivative to derive the delta sensitivity and reverse imply the strike?
The formulae effectively applied are stated neatly in:
https://www.researchgate.net/publication/275905055_A_Guide_to_FX_Options_Quoting_Conventions
but even with this the numbers in the trade confirmation are either more egregiously rounded than I expected or I am missing something trivial.
Quote
Report
Attack68 · External communityPost link
External answer — Quantitative Finance Stack Exchange
Author: Attack68
Original post: https://quant.stackexchange.com/a/77788
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
So the closest I could get was using the formulae from the attached reference:
$$
v = \frac{\text{discount factor at delivery}}{\text{discount factor at spot}} \\
K = f e^{\left ( -\Phi^{-1}(\frac{25\%}{v}) \sigma \sqrt{t} + \frac{1}{2}\sigma^2t \right )}
$$
So with all the given info, and where 2.55% is the EUR interest rate from parity:
$$
v = \frac{1}{1+\frac{92}{360}2.55\%} = 0.9935255253266214 \\
\Phi^{-1}\left (\frac{0.25}{v} \right ) = -0.66937165293466 \\
K = 1.06751 * exp \left (-0.66937 * 0.089 * \sqrt{\frac{92}{365}} + \frac{1}{2} 0.089^2 \frac{92}{365} \right ) \\
K = 1.1010192011340847
$$
Within 0.00001 to the broker calculated value and rounded to 3d.p. seems to be sufficient.
Will leave this question posted as an example of application.
This used
spot delta
and did not make any premium adjustment.
Quote
Report
AKdemy · External communityPost link
External answer — Quantitative Finance Stack Exchange
Author: AKdemy
Original post: https://quant.stackexchange.com/a/77802
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
I think your answer is actually misleading. Using standard Black Scholes (Garman Kohlhagen) will not give you the values for either premium or delta, using the inputs and trade parameters you provided.
Since FX is all OTC,yzou can never be sure about the details unless you ask your broker. Generally though, in order to maintain liquidity there are a number of standardized conventions. Unfortunately, these conventions vary between currency pairs. Usually, vanilla EURUSD options are not premium adjusted. If you have access to Bloomberg, you can check on
OVDV
- 92)Settings->Conventions.
Wystup and Reiswich, 2009
also have an overview of the most commonly used conventions.
See the following screenshot from Bloomberg's
OVML
, where the 3rd screenshot has 25D as an input and solves for strike (the exact decimals are shown in white - when you hover over the value in the OVML screen).
The values are quick to replicate:
For CCY1CCY 2, you have Notional in CCY1 (20MM) and Premium in CCY2 (USD)
You have a deferred (forward) premium, therefore I use two dates (see
here
for an explanation)
all other inputs are given
The model is just standard Garman Kohlhagen
all inputs are provided in the question
In Julia, this looks as follows:
#load packages
using Distributions, Dates, DataFrames, PrettyTables
#define helper functions
ppf(x) = quantile(Normal(0.0, 1.0),x)
N(x) = cdf(Normal(0,1),x)
#define GK
function GK(F,K, days_to_expiry, days_to_delivery ,ccy1, ccy2,σ)
d1 = ( log(F/K) + 0.5*σ^2*days_to_expiry/365 ) / (σ*sqrt(days_to_expiry/365))
d2 = d1 - σ*sqrt(days_to_expiry/365)
c = exp(-ccy2*days_to_delivery/365)*(F*N(d1) - K*N(d2))
δ_spot = exp(-ccy1*days_to_expiry/365) * N(d1)
δ_fwd = N(d1)
return c, δ_fwd, δ_spot
end
The inputs are all given, but the days to expiry and delivery are computed. I allow for hours to expiry but that is irrelevant here (the computed price is below the quoted, and delta would increase with increasing time).
# inputs
s = 1.0615
pts = 60.1
fwd_scale = 10^4
f = s + pts / fwd_scale
println("Forward = $f")
k = 1.101
σ = 0.089
ccy1 = 0.0255008 #0.0255 # EUR
ccy2 = 0.0478 # USD
price_dt = Date(2023,3,16)
premium_dt = Date(2023,6,20)
expiry_dt = Date(2023,6,16)
delivery_dt = Date(2023,6,20)
hours = 0 #0.7115 allows to get more accurate pricing but more hours to expiry would be needed (increases delta)
days_to_expiry = (expiry_dt - price_dt).value + hours/24
days_to_delivery = (delivery_dt - premium_dt).value + hours/24
r1_cont = log(1+ccy1*days_to_expiry/360)/(days_to_expiry/365)
r2_cont = log(1+ccy2*days_to_expiry/360)/(days_to_expiry/365)
I am omitting PrettyTables formatting. Essentially, I compute strike for 25D according to
Wystup and Reiswich, 2009
(omitting the call/put flag φ because we only care about calls here):
$$ K = fe^{-N^{-1}(e^{rf\tau} * \delta_{s})*\sigma* \sqrt{t} + \frac{1}{2}*\sigma^{2}*\tau }$$
or for forward delta:
$$ K = fe^{-N^{-1}(\delta_{f})*\sigma* \sqrt{t} + \frac{1}{2}*\sigma^{2}*\tau }$$
δ = 0.25
# compute strike from delta
k_25D = f*exp((1/2)*σ^2*days_to_expiry/365 - ppf(δ*exp(r1_cont *days_to_expiry/365))*σ*sqrt(days_to_expiry/365))
# get option value for computed strike and quoted strike
opt = [GK(f, strike, days_to_expiry, days_to_delivery, r1_cont, r2_cont, σ) for strike in (k, k_25D)]
# get spot premium
premium_dt_spot = Date(2023,3,20)
days_to_delivery_spot = (delivery_dt - premium_dt_spot).value + hours/24
opt2 = [GK(f, strike, days_to_expiry, days_to_delivery_spot, r1_cont, r2_cont, σ) for strike in (k, k_25D)];
Notional = 20_000_000
df = DataFrame("Strike" => [k, k_25D],
"Fwd Premium USD" => [opt[1][1]*Notional, opt[2][1]*Notional ],
"Spot Premium USD" => [opt2[1][1]*Notional ,opt2[2][1]*Notional ],
"Fwd Delta" => [opt[1][2]*100 , opt[2][2]*100 ], "Spot Delta" => [opt[1][3]*100, opt[2][3]*100] )
The output matches Bloomberg exactly:
Using the computed spot delta of 25.0124 returns the strike (1.101) of your broker:
DataFrame("Delta" => [δ, opt[1][3]], "Strike Solved" => [k_25D, f*exp((1/2)*σ^2*days_to_expiry/365 - ppf(opt[1][3]*exp(r1_cont *days_to_expiry/365))*σ*sqrt(days_to_expiry/365))])
Personally, I suspect that there are two things happening here:
Using
Sticky Delta
is quite common in FX
You just paid a slight "mark-up" to the fair price, given the inputs (for instance, rounded to nearest 100)
What is Sticky Delta?
Sticky Strike is really just Black Scholes Delta computed with
Finite Difference
.
Sticky Delta refers to adjusting IV when you bump up and down (because IV is stuck to delta /moneyness).
Therefore, there are 3 possible outcomes relative to Black Scholes Delta:
a downward sloping IV -> Sticky Delta will be lower
a flat IV -> Sticky Delta will be identical
an upward sloping IV -> Sticky Delta will be higher
Now, Bloomberg conveniently displays Sticky Delta as well. As you can see, sticky delta does in fact show 25D.
P.S.
If it were premium included, you would not be able to use a closed form solution and would need to solve for strike numerically - for example, using Brent's root-finding method as suggested by Wystup and Reiswich.
Quote
Report
Post Reply
Checking account access…