Finance Computing Projects - Dec 7

1. Finance Computing Projects - Dec 7 • Second and final Quiz on MMM • Requirements questions answered • Final instructor evaluation • Class feedback: • How could this course be improved? • Questions/help with project

2. Comparing Market and Credit Risk • Market - “How does the value of my book change as prevailing rates change?” • Interest rate sensitivity - our first order measure DV01 • Scenario shifts - more extreme than instantaneous measure • Notional (Amount) • Others: VaR • Credit - “What happens if the counterparty/issuer with my money doesn’t pay it back?” • Loss Given Default: • Expected Loss = Probability of Default * Loss Given Default • This data is published from ratings agencies or it is derived internally • Ratings downgrades • Scenarios - a common one is “JTD” (jump to default) • Notional (Amount) - also known as “Current Exposure” for unsettled trades • Others: Potential exposure - future worst case

3. Requirements for Front End V2 • Static reports (won’t need to be re-run with a new user-supplied yield curve) • Day-over-day change (see spreadsheet story-board) • Total Notional Amount (aka “notional”), Risk and LGD aggregated by: • “Quality” - only show for codes that exist in the portfolio (not a sparse array) • “Issuer” - use ticker to identify issuer • Two separate data.txt files will be provided (“day_1.txt” and “day_2.txt”). In the meantime, to test you can create your own (just make a copy and change the amounts). • Your executable will now take a second book-file parameter. • When not doing the day-over-day analysis, you may want to parameterize your main to unnecessarily loading the second data file (count argc). • Or, you may want to have two different special purpose instances of your executable • Finally, two things can change between day 1 and day 2: Amount and Rating!

4. Requirements for Front End V2 (cont) • This “maturity band” report can be re-run with a new user-specified yield curve • Risk (e.g., dv01) and Market Value by maturity band: • Maturity buckets defined as: 0-2yr, 2-5yr, 5-10yr, 10-30yr inclusive • Grouping by “remaining term” of the bond (years between settle and maturity) is more extensible • Can also sort on number of periods (since we always assume even periods) • First calculate the total dv01 for each of the 4 buckets making up the total book as we have before • Second, calculate the dv01 of the 2 year (ticker “T2”) • Solve for and display the Amount of 2 year treasuries (T2 in file) to hedge the risk in each mat bucket • bucket dv01 * bucket amount = T2 dv01 * T2 Amount • One way group by maturity is to assign a benchmark treasury to every bond in the portfolio (whether it is spread or yield priced) and group by ticker (T2, T5, T10, T30). User input : • User should be able to re-run maturity band report (not the day over day change report) with shifted inputs: • Yield curve parallel up and down by 50% (of starting yield curve yields) • User entered spreads (in basis points) at each point (to support ad-hoc, non-parallel shifts) • It is required is to display data in tabular form however: • It is desirable to also display in graphical form where possible. • e.g, pie, bar, clustered column chart… Solve for Amount:

5. Requirements for Front End V2 (Assumptions) • SimplifyingAssumptions: • Given we are assuming all periods are equal: • No partial periods, thus no day count conventions apply • Settlement date (and maturity) always fall on a coupon anniversary • The “day 2” data file will have the same settlement date as the “day 1” data file in order to keep the remaining term constant. • In reality as soon as a bond is issued it starts to age and settlement data marches forward daily, shortening the remaining term of the bond • Another place where this applies is with the yield curve: • For us yield curve has “constant maturity” yields • New positions can not be added on day 2 (only existing positions from day 1 can change) • Filenames for data and yield curve info will not change (they can be hard-coded in DLLs)

6. Deliverables for Final • Install package: • .tar (as before) - including makefile, README, etc. • Your main is now your also test driver (to simulate calls from the client side) • Include unit or regression test code along with your main • Parameterize your main to handle the cases required to support the GUI as well as any unit or regression testing • Include the client side code (or excel file) in the UNIX .tar • I will not grade the user handling part of the client side code but may need to refer to it • I will examine your main to see how you unit/regression tested your server-side (should map closely to what your GUI needs). • Presentation/demo • I will provide new data files (day1_data.txt, day2_data.txt and yieldcurve.txt) to be used during the presentation before the weekend. • The only changes I will make during the demo is to the yield curve inputs! • You should already be testing your code with data files of your own…

7. Requirements for Presentation • Architecture: • Description of: • Server-side capabilities • Client-side capabilities • How is logic partitioned between server and client side? • GUI technology choice rationale • “Middleware” protocol • Challenges faced during implementation • How was the work partitioned within the team? • Demonstrate the front end • What questions does the app help the user answer? • Clear description of how to install it, build it and use it • Walk through test-driver of the server side (a requirement!) • I will drive after the presentation is given and ask questions interactively