Sound byte -- if we have 2 unrelated stochastic processes for 2 points on the YC, the 2 calculated prices can induce arbitrage.

Jargon: whenever you see "process", always think of "distro" under some "measure".

Jargon: whenever you see "price", it almost always means a fair "quote" on some contract whose terminal value is yet to be revealed. This price comes directly from the distro by discounting the expected payoff

Jargon: bond prices basically mean loan rates, possibly forward-start. Libor is a loan. FRA is a loan. ED-future represents a loan. A single-period IR swap consists of 2 loans. OIS is based on overnight loans. I notice that from any term structure model, we always want to back out the PROCESS of various bond prices. I guess that's because the actual contracts are invariably written in terms of loans.

Preliminary: IMO, a simple IR option is a call/put on one point of the YC. Example is a call on the 3M Libor. Libor rate changes every day, so we can model it as a stochastic PROCESS. We can also model the evolution of the entire YC with 20 "points" or infinite points.

Earlier formula used to price IR options (including bond options, caps, swaptions) is not from an IR model at all. Black's formula was proposed for options on commodity futures. When adapted to interest rates, Black's formula was kind of OK to price options on one point on the (evolving) yield curve, but problematic when applied to multiple points on the YC.

As a consequence, such a model can

- give a distribution of an (yet unrevealed) discount factor of maturity M1, after calibrating the model params with one set of market data

- give a distribution of an (yet unrevealed) discount factor of maturity M2, after calibrating the model params with another, unrelated set of market data

As a result, the 2 distributions are like the speculations by 2 competing analysts -- can be contracting. If a bank uses such a model, and gives quotes based on these 2 distros, the quotes can be self-contradicting, i.e. inducing arbitrage. I would imagine the longer-maturity yield (converted from the discount factor) could turn out to be much lower than short-maturity, or the yield curve could have camel humps.

Following Black's formula, First generation of IR models describe the short rate evolution as a stochastic process, but short rate can't "reproduce" a family photo. In other words, we can't back out the discount factor of every arbitrary maturity.

More precisely, given a target date "t" [1] the model gives the distribution of the (unrevealed) short rate on that target date, but the zero-curve on that target date has infinite points, each being a discount factor from some distant future (like 30Y) to the target date. The short rate distribution is not enough to reproduce the entire YC i.e. the family photo.

The only way I know to give consistent [2] predictions on all points of the YC is a model describing the entire YC's evolution. We have to model the (stochastic) process followed by any arbitrary point on the YC, i.e. any member on the family photo. The model params thus calibrated would be self-consistent.

[1] that's later than the last "revelation" date or valuation date, i.e. any IR rate on the target date is unknown and should have some probability distribution.

[2] arb-free, not self-contradicting

Sound byte -- disconnected, unrelated Processes for 2 bonds (eg 29Y vs 30Y) could induce arbitrage. These 2 securities are unlike Toyota vs Facebook stocks. I think the longer maturity bond can be used to arbitrage the shorter maturity. I think it's safe to assume non-negative interest rate. Suppose both have face value $1. Suppose I could buy the long bond at a dirt cheap $0.01 and short-sell the short bond at a high $0.98 and put away the realized profit.....

## Saturday, June 6, 2015

### arbitrate-free term structure models

Labels: z_IR_misc

## my favorite topics (labels)

_fuxi
(302)
_misLabel
(13)
_orig?
(3)
_rm
(2)
_vague
(2)
clarified
(58)
cpp
(39)
cpp_const
(22)
cpp_real
(76)
cpp/java/c#
(101)
cppBig4
(54)
cppSmartPtr
(35)
cppSTL
(33)
cppSTL_itr
(27)
cppSTL_real
(26)
cppTemplate
(28)
creditMkt
(14)
db
(65)
db_sybase
(43)
deepUnder
(31)
dotnet
(20)
ECN
(27)
econ/bank`
(36)
fin/sys_misc
(43)
finGreek
(34)
finReal
(45)
finRisk
(30)
finTechDesign
(46)
finTechMisc
(32)
finVol
(66)
FixedIncom
(28)
fMath
(7)
fMathOption
(33)
fMathStoch
(67)
forex
(39)
gr8IV_Q
(46)
GTD_skill
(15)
GUI_event
(30)
inMemDB
(42)
intuit_math
(41)
intuitFinance
(57)
javaMisc
(68)
javaServerSide
(13)
lambda/delegate
(22)
marketData
(28)
math
(10)
mathStat
(55)
memIssue
(8)
memMgmt
(66)
metaProgram`
(6)
OO_Design
(84)
original_content
(749)
polymorphic/vptr
(40)
productive
(21)
ptr/ref
(48)
py
(28)
reflect
(8)
script`/unix
(82)
socket/stream
(39)
subquery/join
(30)
subvert
(13)
swing/wpf
(9)
sysProgram`
(16)
thread
(164)
thread_CAS
(15)
thread_cpp
(28)
Thread*
(22)
timeSaver
(80)
transactional
(23)
tune
(24)
tuneDB
(40)
tuneLatency
(30)
z_ajax
(9)
z_algoDataStruct
(41)
z_arch
(26)
z_arch_job
(27)
z_automateTest
(17)
z_autoTrad`
(19)
z_bestPractice
(39)
z_bold
(83)
z_bondMath
(35)
z_book
(18)
z_boost
(19)
z_byRef^Val
(32)
z_c#GUI
(43)
z_c#misc
(80)
z_cast/convert
(28)
z_container
(67)
z_cStr/arr
(39)
z_Favorite*
(8)
z_FIX
(15)
z_forex
(48)
z_fwd_Deal
(18)
z_gz=job
(33)
z_gzBig20
(13)
z_gzMgr
(13)
z_gzPain
(20)
z_gzThreat
(19)
z_hib
(19)
z_IDE
(52)
z_ikm
(5)
z_IR_misc
(36)
z_IRS
(26)
z_javaWeb
(28)
z_jdbc
(10)
z_jobFinTech
(46)
z_jobHunt
(20)
z_jobRealXp
(10)
z_jobStrength
(15)
z_jobUS^asia
(27)
z_letter
(42)
z_linq
(10)
z_memberHid`
(11)
z_MOM
(54)
z_nestedClass
(5)
z_oq
(24)
z_PCP
(12)
z_pearl
(1)
z_php
(20)
z_prodSupport
(7)
z_py
(31)
z_quant
(14)
z_regex
(8)
z_rv
(38)
z_skillist
(48)
z_slic`Problem
(6)
z_SOA
(14)
z_spring
(25)
z_src_code
(8)
z_swingMisc
(50)
z_swingTable
(26)
z_unpublish
(2)
z_VBA/Excel
(8)
z_windoz
(17)
z_wpfCommand
(9)

## About Me

- familyman
- New York (Time Square), NY, United States
- http://www.linkedin.com/in/tanbin

## No comments:

Post a Comment