1. Now we build a server from our executable Server-side: –Executable –Heavyweight process that stays up –Add a message set (will be driven by our GUI requirements) –State management for optimization –Re-use our mid-term executable as a regression test harness –Recovery State re-construction Connection management (we will use TCP sockets) Why build a server? –Scaling –Parallel processing –Separate by process boundary so client can be written in a different language/dev environment –Support client evolution (more rapid than server side - mfc, java,.net, etc.,) Socket code fragments supplied on class page Heavyweight process vs. thread –Shared memory –Contention management –Ease of debug –Complexity compromise –Parallel processing model Clustering Individual machine may have multiple CPU’s, OS may be fine grained

2. “Middleware” See Socket.tar

3. Putting it all together Teams can build server and client in parallel via stubs Functionality we will have to add to our server: –Bucketed Risk –Scenario capability –VaR –Position change intra-day (“new business” or trading activity intra-day) There will be a grading phase on the server using our new client GUI –Our executable will now become our test driver –GUI environment choice is up to the teams - language/tools are your choice –GUI code will not be graded - it just has to work with your server –The full app will be demo’d during last class by each team. Both team members must present. –We will start drilling into GUI requirements Now that we can price and calculate risk it’s time to put a nice front end on it! New functionality will be added to server as we go...

4. Measuring trading book change We can now calculate risk at a point in time for a given book –Credit : Loss Given Default –Market : Interest rate sensitivity However, the risk changes daily given trading activity and changing market environment… –What is market environment (yield curve or spread change)? –What is the new position (trading activity or “new business”) –What is the new risk given above? –Sensitivities change as valuations change given non-linearity of p/y function We need an itemized bill: –“Risk Attribution” (what were the biggest contributors to my risk profile)? –“PnL Attribution” (How did I make/lose money?) If VaR changed materially where did it come from? Big position move or a risk move? –Was it due to Interest Rate movement of Spread movement?

5. Calculate LGD for the book Calculate LGD given a ratings downgrade scenario: –AA to A (for example) –BBB to BB (Investment grade crosses over to junk) –This is when we’ll need to use the unique ID (SBB_ID) Calculate change in position given trading activity intra-day –We’ll have a starting book “opening” and end-of-day “closing” book You should be able to: –Load two position files and price by either spread or yield –Calculate Market Value of the trading book per bond: MarketValue = Position * Price/100 –Calculate scenarios by shifting the yield curve –Show how risk has changed given trading activity –Show risk bucketed by maturity band –Calculate hedge amount of the 2 year treasury to flatten out risk in each band –Each team will have to use graphics to meet some aspect of the requirements –Tabular and graphical display –Accept user input for running pre-determined as well as ad-hoc scenarios –Calculate VaR for trading book (covered in future lecture) Requirements for Final Submission

6. Requirements for Front End Static reports: Position change (see spreadsheet story-board) Total Notional Amount, Risk and LGD by: “Quality” “Issuer” User input driven: Risk and Market Value by maturity band: Maturity buckets defined as: 0-2yr, 2-5yr, 5-10yr, 10-30yr (If > 30 year put in this bucket) Display Notional Amount of 2 year treasuries (T2 in file) to hedge each bucket bucket risk = dv01_2yr * Amount_2yr bucket risk = sum of individual risks of each position in the bucket User should be able to re-run maturity band report with shifted inputs: Yield curve parallel up and down by 50% (of starting yield curve yields) User entered spreads at each point (to support ad-hoc shifts) It is required is to display data in tabular form (see spreadsheet spec) It is required to display in graphical form as well (use your imagination). e.g, pie, bar, stacked bar, line, scatter… Solve for Amount

7. Deliverables –Server built with version 1 of message set defined –Stub client wiggling in your language of choice –Your regression harness inputs can now be tradingbook_results.txt Tradingbook_results.txt and results.txt are posted on class page before lecture after mid-term submission (after any late submissions) –Submission will be a server and a simple stub client –Deliverable is what you submitted for the mid term BUT called from the client –“run.sh” to start server –Timing info to be written to stdout by server process –Bracket message handler with START_TIMER() … END_TIMER() –Download new SBB_util.h/cc to get parameterized version of end_clock(…) so you can send the results back to the client –Return real, user and system time as a message to the client –“Output is as before (two files which the server writes out)

8. Early look at Requirements for Final 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/message set 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

9. Early look at Requirements for Final Presentation review GUIrequirements_V1.xlsx