Case study: pricing and structuring

General Requirements

• Use existing pricing/model library in order to price new contracts.
• Explain pricer setup and results.
• Add new components or modules to pricing/model library.
• Calibrate the models or back out model parameters from historical data.
• Document the new components or modules.
• Monitor the model usage.

Industry practice: Huge Excel spreadheets and email communication

1. Set up the pricing (e.g., of a new contract) in an Excel spreadsheet. The point is not just to get a number, but to prove that the pricing is correct. Thus you have to include quite a few tests and scenarios, ending up with a very complicated spreadsheet. This is usually a very tedious, error-prone task. We already mentioned a few drawbacks in the Use cases: Excel/GUI vs scripting.
2. Email spreadsheet to stakeholders (traders, marketers, risk managers, etc). Include long explanation in body of email. Spend time on the phone or at desk walking stakeholder through spreadsheet. You may end up explaining things several times to different stakeholders.
3. In case of follow up questions, retrieve the original email. This can quickly get very confusing as email threads tend to grow very fast.

Problems with this approach:

• You spend a great deal of time performing manual tasks that are either not necessary or should be automated.
• No transparency. You cannot track changes to your document or spreadsheets in a version control system.
• If you hand over the project to someneone else, you will have to sit down and go over a lot of irrelevant details.
• More often than not, your spreadsheet will stop working at some point. Fixing a broken spreadsheet requires a lot of effort, much more than fixing a script that performs the same calculations.

Streamlined approach

1. Set up the pricing in a Python script: retrieve data from a wide variety of sources and formats, easily run your and third-party libraries side-by-side.
2. Write the documentation - by automatically running the Python scripts and automaticaly inserting the results in the document.
3. Publish the documentation to internal website.
4. Place the documentation source code (including relevant scripts) under source control.
5. Should any stakeholders need clarification (that require an answer longer than a few lines), enhance the documentation as needed, then point them to the web site.
6. In general, document all your work. Add any relevant tests/experiments/studies to the web site. If you have to reference work that sits in a folder, add it to the web site. Place the work under source control.

What you gain:

• Very significant productivity improvement.
• Complete transparency.
• The reader (with the same environment as you) can very easily replicate selected results. It is a live document.
• Zero time hand-over. Any developer (with the same environment as you) can regenerate the entire document from source by simply entering “build html” at the command line.
• Never forget anything. No work ever decays or gets lost.