Now we build a server from our executable

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. Requirements for Final Submission • 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)

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