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 • Library (e.g, excel add-in) • Add a message set (will be driven by our GUI requirements) • State management for optimization • Retain our mid-term executable as a regression test driver • 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 will be 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. 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 well

3. 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?

4. 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 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)

5. 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

6. Deliverables • Server built with version 1 of message set defined • Stub client wiggling in your language of choice • Your regression harness is now your executable loading tradingbook.txt with answers • Tradingbook.txt and results.txt are posted on class page after mid term submission lecture • Submission will be a server and a python client • Python example is posted with socket code fragment • The client process will write 3 numbers to stdout: • Amount of 2 year treasuries needed to hedge risk in the 30 year maturity bucket • Total market value of portfolio given 100 basis point shift UP of all yields • Total market value of portfolio given 100 basis point shift DOWN of all yields • “run.sh” to start server • Timing info to be written to stdout by server process as before • Bracket message handler with START_TIMER() … END_TIMER() • Download new SBB_util.h/cc to get parameterized version of end_clock(…) • Return real, user and system time as a message to the client • “Client.py” to exec client which will write out results to stdout • Output format (all in 3 decimal places): • Hedge_amount mkt_value+100 mkt_value-100 real user system • I’ll measure client side real, user, sys time by: • $ time python client.py • The real time is our time elapsed end to end time • With the timer routine embedded in our C++ server we can see overhead of: • Python, GUI code, IPC

7. 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 • 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