About Us

PnL Explained Professionals FAQ

Site Map



Contact Us


Main Page by Topic

A. PnL Explained

B. CTRM Software

C. Statistics



CTRM System Design Philosophy


This page has considerations for the industry at large for a proposed and even recommended design philosophy for CTRM systems.  Hope it helps.  Enjoy.  Because having fun should also be a part of CTRM system design.



1) “Simple Things Should Be Simple”

2) ‘Hooks’ Everywhere

3) Show Your Work

4) Design Is Not Done Until You Have Included Reports

5) Separate GUI Versus Raw Functionality, API For Everything.



1) Simple Things Should Be Simple

‘Simple things should be simple’ is short for the design philosophy ‘simple things should be simple and complex things should be hard’.  Or that might be changed to ‘hard things should be hard’, which sounds better.


This is a general philosophy, most often used/applied for the GUI or how the user interacts with the system. 


The user will want to do things that they think are simple and should be easy to do, and some designs make it hard (which is not good). 


On the other hand, if the user has something hard or complex to do, then that is OK that is hard to do in the system.  By that I mean… it is a good design, or can be, if it takes more steps (‘clicks’) to do something complicated.  It may not be a good design if it takes the same clicks/effort to do something easy as to do something complicated.


An example to illustrate:

Systems will have a way to model/store forward prices, e.g., futures prices for Crude oil.  That concept may be called a term like; ‘curve’, ‘index’, ‘projection index’, ‘price curve’, ‘price index’, ‘forward price curve’, ‘forward curve’, ‘forward price index’ or some other similar name.   We’ll call this concept a ‘forward curve’ in this blog or just ‘curve’.


A full system may have 100s of forward curves. The forward curves could be for things like:

1.1) Crude Oil

1.2) Unleaded Gas

1.3) Power

1.4) Natural Gas

1.5) Gold

1.6) Silver

1.7) Cocoa



For the below example, let’s assume that the system has just 10 forward curves and that the user wants to ‘shock’ (meaning change) the prices on all 10 of them.


The user may want to ‘shock’ all prices up 10%.  So if Crude Oil is trading $50, then the ‘shocked’ price would go be $55.


When we say ‘all prices’, we don’t just mean one value per forward curve (which would be 10 prices in total). 


Instead, each forward curve may contain dozens of prices, which might be one price, a projected ‘forward’ price per month, e.g., going out 5 years.  That is 60 prices, which is 12 months * 5 years, per curve, so 600 prices.  i.e., With the possibility that no two prices are the same.  E.g., January Crude Oil might be $50 and the projected price for February might be $50.73, March might be 50.42 and so on.


Example of Design that is consistent with our Design Philosophy:

Since we want to shock all curves up 10%, we would want to add a row on a screen, where we can pick which ‘Curves’ we want to shock.  In the curve pick-list, we might have a special value of ‘All’.  So we would just add one row, pick between ‘absolute’ shocks (e.g., up or down a specific dollar amount like $4 or -$6) or ‘relative’ shocks (e.g., up or down a particular percent like +10% or -5%) and enter the shock value, i.e., one single value (‘up 10%’) which the system would be smart enough to apply to all 600 forward curves/months.


Example of a Design that is *not*consistent with our Design Philosophy:

If a user has to go to a screen and add one curve at a time (manually).  i.e., so 10 times.  And then, for each curve, having to shock each month, meaning enter in a value per curve per month.  So instead of one ‘+10%’ as in the case above, you wind up with 600 ‘+10%’, plus the extra hassle of having to manually select each curve you want.


Now onto another example.  Let’s make this a little ‘harder’, i.e., more ‘complex’.

Instead of just one ‘shock’ values for all curves, let’s say we want to shock each curve by a separate amount, for example:

1.1) Crude Oil +5%

1.2) Unleaded Gas +4%

1.3) Power +2%


For this, we would want a screen where you can add 10 rows, one per curve, and set the shock values per curve.  i.e., set 10 things instead of just one, and that is OK (a good design), because ‘harder things should be harder to do’.


Shocking all of the months on a forward curve by the same value is called a ‘Parallel Shock’.  (The parallel term coming from how things would look if you plotted/graphed them out.).  That has been what we have been doing in the example so far.


Now let’s make the example even more complicated.  Suppose we instead wanted to shock each month on each curve by a different amount, for example:

1.1.1) Crude Oil Jan +5%

1.1.2) Crude Oil Feb +4.8%

1.1.3) Crude Oil Mar +4.3%


1.2.1) Unleaded Gas Jan +4%

1.2.2) Unleaded Gas Jan +3.6%



Then it is OK for a user to have to do more work, e.g., go to a second ‘detail level’ screen. 


Side note:  There should also be a way to easily feed in shock values, especially if there are 600 of them, i.e., one per curve per month, as in the second example, meaning to automate the process.


Another example:

A system where you need to go to 10 screens to setup one new portfolio (a.k.a., trade book), e.g., e.g. one for the new name, one screen to assign to users, another screen for adding to the end-of-day batch calculations, etc.  Versus having one screen where you can consolidate the steps.  This also helps ensure that no steps are missed.


2) Hooks Everywhere

The idea is that for everything a user can do in the GUI, there should be some ‘hook’ where system integrators can customize the behavior.  This could be with configuration or coding (a.k.a. ‘scripting’).  So, every button click, every text entry, every time a pick-list is selected, when a screen starts/closes, when a row is added or deleted.  Basically every keyboard or mouse interaction.


This design philosophy also applies to behind the scenes activities.  E.g., when a trade is booked via a feed (e.g., from an exchange or internal system), market prices loaded, etc.


Actions you should be able to configure or code include:

2.1) Stop the action

2.2) Modify the action.  E.g., for trade booking, might automatically populate a custom field.

2.3) Modify what gets returned by the action

2.4) Start some unrelated action.  E.g., an e-mail gets sent when a trade is booked (e.g., of a certain kind).

Key to these ‘hooks’ is that that they are separate from the core code of the system.  i.e., so you don’t need to modify the core code. 


As an end user, the new behavior should be seamless as if it were native functionality.


For each ‘hook’, it needs to be easy to:

a) Turn on or off as needed, for changing behavior and/or debugging.

b) See that they are being invoked.  As someone trying to debug the system, if the default behavior was changed by a ‘hook’, you need to be able to easily identify that.  (i.e., opposite from what an end user would experience, where they want things to be seamless).


3) Show Your Work

In math class, just providing the right answer may not be enough to earn full credit.  Some math teachers may require you to ‘show your work’ to get full credit.


As this applies here, to the extent that there are intermediate steps in a calculation, the user and/or someone debugging things needs to be able to see the intermediate steps.


Example 1:  Summary Versus Detail Level Reporting/calculations

Sometimes I see reports that only produce a summarized version.  E.g., if you have 100 similar trades, the report might show one number for volume, a consolidate/summed value of ‘12300 units’.  If you ever have a discrepancy, it is really hard to figure out why with just a summary level report.  So every summary level report should also have a detail (e.g., trade level) report available, even if users don’t run it on a typical day.


Example 2: Complicated calculations that have multiple (intermediate) steps:

3.1) ‘VaR’ (value at risk)

3.2) ‘Netback’

For a system that produced these numbers (i.e., the final numbers), there should be a way (screens or reports) to see the numerous intermediate steps along the way so as to be able to identify the root cause of any issue.


4) Design Is Not Done Until You Have Included Reports

A respected mentor once told me, ‘if I knew what reports people wanted to see, I would have designed the system differently’.


So often when creating reports, either the raw data needed isn’t there, or it is not very convenient to get.


Make sure when designing a system that you include in the design the reports that will be needed.  You could almost start with the reports and work back and say, ‘what sort of system would we need to design so as to be able to get to this report’?


This has even deeper meaning if you include in ‘reports’ other things that may not technically be ‘reports’, but that work in a similar way (meaning get data and output it, potentially with formatting).  That includes:

4.1) Any and all extracts.  E.g., CSV file extract with trade and valuation data to go to a downstream system.   This is like a ‘report’ with no formatting.

4.2) Client invoices / monthly statements.  If the client (getting the invoice) wants to see day-by-day data, and the system only stores data at the monthly level, that is a problem.


5) Separate GUI Versus Raw Functionality, API For Everything.

Systems should have a clean separation from the GUI side of things versus the way the system works, with an API (software function call) for everything. 



5.1) A system where you could ‘split’ a trade into two on the screen (in the GUI), e.g., to set two different settlement instructions.  Where there was no API, so could not automate it.

5.2) A system that has a certain kind of report that is has code tied to the GUI.  E.g., push a button on the GUI and create a certain report.  The system should have an API for that.  In this example, the ‘report’ was assumed to be something based on a per-user configuration, e.g., the user selected which columns to pivot.  And we assumed that there was no API that could call into that (which is bad).  i.e., ideally, the user would want that report auto-run every day, but instead that person might need to run it manually from the GUI (in this hypothetical example). A better design would allow for an API to automatically run the same report, even including the user’s custom configuration.



Introduction to CTRM

Click on this link for a great introduction to CTRM software: Introduction to CTRM Software




Site Map

Contact Us