Serving the Quantitative Finance Community

 
User avatar
daveangel
Topic Author
Posts: 5
Joined: October 20th, 2003, 4:05 pm

design issues and problems

May 28th, 2010, 5:18 pm

i was hoping to pick some smart persons brain here. I am working (purely privately and off my own curiosity) on a risk management system for derivatives. the issue I have is with yield curves and how the system can be used. now a yield curve defined today is straightforward - you can have cash, futures, swaps etc. and you build the curve from market rates and prices. However, let us say you are using the system in real life - the user wants to load yesterdays yield curve. would you define new instruments for each day (or instance of the curve) ? This is particularly an issue with things like depos and swaps that are quoted on rate basis and have a par value. for futures, it is not an issue because they are quoted on a price basis and you can store the prices. but would you store the rates for each day and have a generic on the run swap/depo or the swap/depo for each day ?
knowledge comes, wisdom lingers
 
User avatar
wsirhc
Posts: 0
Joined: July 9th, 2007, 3:39 pm

design issues and problems

May 28th, 2010, 6:15 pm

I'd certainly recommend defining instruments independently of the curve, before you define the curve. There are a certain number of attributes of the instrument that you definitely need to define (e.g. currency, daycount convention, length of fixed periods, etc.). There are also a number of instrument attributes that you may or may not care about such as: reset periods on floating legs, indexes used on floating legs, fixing/payment calendars, etc. . The number of such attributes is sufficiently high that you really don't want to create a fresh copy every day.Every time a curve is defined (e.g. each day) you may decide to: a) pick the instruments to be included in that curve and b) specify the market rates for those instruments.Alternately, you may want to define one or more curve structures (e.g. a set of instruments to be used to construct the curve). In this case, every time a curve is defined a curve structure needs to be referenced and the market rates for the instruments in the curve structure specified.One other design aspect you may want to think about is the best way to store the fixings for the first floating period of swaps.
 
User avatar
daveangel
Topic Author
Posts: 5
Joined: October 20th, 2003, 4:05 pm

design issues and problems

May 28th, 2010, 8:27 pm

yes definitely define instruments and then create curves from them. but lets take say a 5yr swap - would have n 5year swaps (one for each day) or just one ? this has been driving me nuts ! currently my swap instrument has a start date and end date as two parameters. so on this basis i would have swap for each instance of a curve.
knowledge comes, wisdom lingers
 
User avatar
wsirhc
Posts: 0
Joined: July 9th, 2007, 3:39 pm

design issues and problems

May 28th, 2010, 8:58 pm

I'd have lots of 5yr swaps, but the difference between them would be things like the currency, daycount convention, length of fixed periods, index, reset frequency, etc.. For these I would not define a Start Date and End Date when I defined the instrument, just the maturity (i.e. 5 years).Then when I started to generate the curve I would know T and could calculate the Start Date (e.g. T + 2 for EUR) and End Date (e.g. T + 2 days + maturity). One could store the calculated Start and End Dates but only as part of the generated curve. The next time I generated the curve (even if for the same T) I'd recalculate the Start Date and End Date again.Doing this would also allow one to calculate the actual Time Decay of a trade (or portfolio). On a given day, say 24th May, one would calculate the PV using that day's curve. The next day one could take the curve defined on 24th, but generate it for T=25th and then value the trade (or portfolio) again. The difference between the two PVs would be soley down to the change in date, not changes in market data.
 
User avatar
Kamtsa
Posts: 0
Joined: June 4th, 2006, 11:01 am

design issues and problems

May 30th, 2010, 9:03 am

We are also using the 'standard' method wsirhc describes: defining quote instruments independently of curve, and the curve has then a list - possibly different for each day - of quote instruments from which it is build. Storing only the the daily quotes for the instruments.Daveangel, about storing the begin/end as relative dates (spot period, life time period), or in absolute terms (start date, end date), wouldn't you be needing both, depending on the instruments? I was thinking of building an asset-specific discount curve. One time you'd be using cds spreads, quoted as rolling instruments, protection starting from say 2 spot days from today, rolling around the next quarter, running different periods like 6M,1Y,3Y,5Y... Alternatively you could build the asset discount curve - say for a specific bond - out of a list of quotes for a suitable, liquid bond. These quoted bonds come with their own fixed start/end date depending on the specific bond (term sheet). In any case the curve would be independent from the quote instrument specification, though.I've been thinking a bit a as well about daveangels design issues and best and most logical way of storing these objects, but I'm still unsure about a good/ideal way to do this. Anybody like to give their opinion or their experiences it'd be much appreciated.
 
User avatar
daveangel
Topic Author
Posts: 5
Joined: October 20th, 2003, 4:05 pm

design issues and problems

May 30th, 2010, 10:15 am

a further but related issue is do I distinguish between the present value of an instrument and its market "price". for things like futures, equities,exchange rates the market price is a true price. for things like swaps the market price is a swap rate. so although the pv method for all instruments should work the same way and return the pv of a contract, do I also need a "price" method which returns the price of that instrument ?
knowledge comes, wisdom lingers
 
User avatar
zhouxing
Posts: 1
Joined: March 24th, 2006, 4:17 pm

design issues and problems

June 3rd, 2010, 8:07 pm

There are two questions I can see here.1. re. building instruments. Most curve building instruments, swap included, are just a series of cash flows. A cash flow is related to a set of dates. Therefore today's 5yr swap is different from yesterday's 5-yr swap because they are associate with a different set of dates. Today's 5-yr par rate is associated with a different cash flow from those of yesterday's. Therefore theoretically, yesterdays' curve needs to be built using yesterday's market data. The key here is that the market input you are using should match the correct cash flow (dates). Of course, sometimes (e.g. when calculating theta), we may assume the input rate stays the same. But this assumption may cause problem if we are using instruments such as US FedFund Futures as building instruments.2. price v.s. rateIt depends on your building methodology. If you are using things such as bootstrap which can price instrument exactly, using these two probably does not make lots of difference. But if you build curve by global fitting (e.g. spline), using pv and price/rate difference as solving target will have some difference. Personally I will prefer to solve the curve based on price/rate because in this way we are making our targeted price/rate evenly close to the original market inputs.
 
User avatar
daveangel
Topic Author
Posts: 5
Joined: October 20th, 2003, 4:05 pm

design issues and problems

June 4th, 2010, 5:32 am

good points 1. i agree - yesterdays 5 year swap is not the same as today's 5year swap. different dates, accrual periods, rates etc2. price versus rate - I actually am thinking more generally of difference between pv and price. for example, exchange traded futures have a "price" which is quoted in the market and a pv which will be different. a swap has "price" (which is the swap rate) and a pv which can be calculated. my thinking here is interaction between calculated values and market prices. I am using the idea that an instrument may be valued using different engines one of which is a mark to market engine. some instruments will only have one equities for example can (or should !) only be MTM whereas a futures contract may be MTM or priced theoretically depending on the application.
knowledge comes, wisdom lingers
 
User avatar
wsirhc
Posts: 0
Joined: July 9th, 2007, 3:39 pm

design issues and problems

June 6th, 2010, 6:27 pm

1) Yesterday's (say 5yr) swap v's today's (5yr) swapYes, cashflow dates and amounts for yesterday's (say 5yr) swap will be different from today's, however, (back to the original question) this does not mean that one must define the swap instruments afresh each day. If one defines the swap (or other) instruments in terms of things such as: spot days, period frequency, roll conventions, calendars, etc. then your program can calculate the cashflows for each instrument based upon that instrument's definition and the value of T chosen.2) Solving Target - Price/Rate or PVAn alternate solving target that can also be used is (PV / sensitivity), so that one can define that max tolerated error in terms of basis points.BTW: Using a curve to determine price/rate of instruments can be used to determine market risk, bucketed using a standard set of "market instruments" (rather than the actual liquid instruments that are most appropriate for a given currency). The idea is: a) generate the curve(s) using the actual instruments that are liquid for the currency concerned b) use the generated curve to price each of the standard "market instruments" one wants to use for bucketed market risk c) generate curves from these standard instruments (and the standard instuments with "bumps" applied). Of course a big objection to this is that these standard "market instruments" can be as theoretical as ZCBs (in some currencies), but if wanting to get an overview of market risk across multiple currencies this can be useful.