Main Page by Topic
Strategies for Switching CTRM Systems
This page shares with you, gentle reader, thoughts and considerations on the different strategies for switching CTRM systems, including the ‘big bang’ weekend cutover approach and the phased and/or parallel run approach.
1.1) Approach #1) ‘Weekend cutover’.
For a traditional approach, the most common may be the weekend cutover. A typical playbook for this approach is to run end-of-day processing in the legacy system on Friday, including feeds ‘downstream’, i.e., to accounting system(s), credit system(s), firm-wide risk systems, etc. So on the Friday, the legacy system would still be the system of record.
Then, typically on Saturday, the trade and all data would be migrated all at once to the new system.
One variation is to have the new system have its effective system date be on the Friday, i.e., even though the real world date would be Saturday, over the weekend. And then for the new system to rerun the End-of-Day as of the Friday date. This would include any calculations and reports. However, this would not go downstream.
This variation has these benefits:
1.1.1) Use the Friday EOD (End-of-Day) data from both systems for a reconciliation, a.k.a., a ‘tie out’.
1.1.2) One more test, with the latest data.
1.1.3) This will initialize the MTM (valuation) data as of the Friday, such that when the first real/official EOD runs on Monday, then the PnL (profit/loss) will be correct. PnL requires two data of MTM data to be accurate.
1.2) Parallel Run
With this approach both systems run for multiple dates, which could be a week or two. The legacy system would continue to be the system of record during the parallel. Trades and prices would be fed or manually entered into both systems. The new system would generate EOD calculations, reports and feeds.
During this time, the new system would not be feeding any live systems. It may receive live data, such as futures trades from an exchange. In other words, things like price feed and trade feeds from external sources will be live in both systems during a parallel run, intraday and EOD activities would happen in both, but only the legacy system would feed data to downstream systems.
There would be expected that there would be daily reconciliations/tie-outs between the new and legacy system.
When it comes time to ‘turn off’ the legacy system, it would be, ideally just a matter of making the new system feeds ‘live’ to feed downstream and to stop sending the feeds from the legacy system, i.e., to ‘flip the switch’.
1.3) Long-term Parallel
For this approach, the idea would be a longer term parallel, e.g., 6 months to a year. This would make sense in the case where a new system is being built out. Such as when a firm builds out their own CTRM system from scratch or in the early years of firms using BlueCTRM, the open source CTRM.
The reason why this needs to be long term is that it is assumed that in the course of the parallel, new functionality, i.e., enhancements, will either be identified or you might expect to have the case where you know you have some gaps and you still start the parallel anyway, so as to test the areas that do work.
Whereas for strategy 1.2, the simple Parallel Run, the expectation is that the new system is fully working, which you already confirmed via QA (quality assurance) and UAT (user acceptance testing), and you are just being extra cautious/prudent.
Here is a possible scenario/plans for a firm rolling out BlueCTRM, using what we are calling here a long term parallel.
2.1) Phase #1: ‘Trades’
In this phase, trades are still mastered in the legacy system. There would be a minimum of a once a day copy from the legacy system to BlueCTRM with the expectation of also having intra-day updates.
For the case where trades are fed into a firm from an external source, like an exchange, the exchange feed would be configured to automatically feed into the new CTRM System. It is expected that the only trades that would need to be exported from the legacy system and imported into the new CTRM System would be trades that are manually being entered into the legacy system.
2.1.1) Variations on the daily and/or intraday trade load are:
22.214.171.124) ‘flush and fill’. Each day, the trades in the new CTRM System are deleted and replaced with new/fresh versions. As a variation, this would not happen for all trades, but just the ones that have changed since the prior day.
The advantage of this approach is that it increases the likelihood the trades are perfectly in sync between the two systems.
126.96.36.199) For the second variation, the trade feed will first look to find a match in the new CTRM System based on the trade number from the legacy system and, if it finds it, amend it with the details from the legacy system, assuming that the trade changed.
The advantage of this approach is that the trade number in the new CTRM System will not change from day to day, relative to a trade based out of the legacy system.
In either case, the trade number from the legacy system would be stamped onto the trade in the new CTRM System. This is needed to line up (align) trades for reconciliation.
2.1.2) As part of Phase #1 ‘Trades’, you would either use or build reports that feed out of the new CTRM System. Since there is just trades, you would be limited to just reports that contain only trade data.
That could be:
188.8.131.52) Something simple like a ‘Trades Done Today’ report.
184.108.40.206) Regulatory reports, e.g., for Dodd Frank. Per Dodd Frank rules, you must report, for applicable derivative trades (swaps and options), trade ‘Life Cycle Events’, such as a novation (counterparty change). Most of these reports could be run out of BlueCTRM. Anything that doesn’t require prices/MTM data.
220.127.116.11) Tie outs/reconciliations with exchange for futures contracts
18.104.22.168) Tie outs/reconciliations with ICE eConfirm for reportable derivatives.
Remember that in this phase, things are still just running in parallel. Any reporting out of BlueCTRM would be just considered for comparison with a similar report from the legacy system.
On the other hand, for some reports, e.g., a reconciliation between the trade data in the new CTRM System and ICE eConfirm, if a discrepancy is found, it might be worth checking on the trade as it is mastered in the legacy system to confirm that there is really an issue and to fix/resolve the issue as appropriate.
2.2) Phase #2: Trades and New Reports
In this phase, we assume that you have your legacy system as live and that means trades are ‘mastered’ in it and that the new CTRM System has been running for a while as a perfect copy of just the trades.
Now you can think about writing new reports directly from the new CTRM System, so long as they just use trade data.
Effectively at this point, the new CTRM System is running ‘live’ with regard to trades, having been in sync for some number of months. And so newly created reports from the new CTRM System are live.
Depending on the frequency of updates and plans, existing reports, the ones assumed to have been running in the legacy system and the new CTRM System for a number of months, could also be considered live/valid out of the new CTRM System, with potentially turning them off from the legacy system.
The plan is, after all, to eventually turn off the legacy system. In fact, this brings up a good point about the long-term parallel. Which is that there would be a phased approach to shutting down the legacy system, or if not shutting it down, then to take certain areas of the new CTRM System and consider them ‘live’, while possibly generating and then ignoring/not using the equivalent reports in the legacy system.
Even at this phase, with just the trade data, you can have the new system, the new CTRM System, generate ‘Confirms’, i.e., confirmation documents. Meaning that just the trade details are all you need from an information point of view to start creating confirmations documents (for the parallel).
2.3) Phase #3: Trades, Reports and Settlement Data.
Let’s now imagine that we add one more key piece of functionality, which is to have settlement prices fed into the new CTRM System and have those prices used to calculate payments on deals.
We use the term ‘settlement prices’ instead of ‘closing prices’ to be slightly more accurate in our terminology. For example, in the gold markets, there might be an ‘AM’ price (morning) and a ‘PM’ price (afternoon) each day, where you have the case where deals could require prices on either one or other combinations such as the average of AM and PM prices.
Just by adding this extra functionality, you can also start producing invoices. i.e., the documents you would send your trading counterparties with the amounts they own you for your profits on the derivatives trades you did with them, or to send them an invoice for them to pay for the value of the physical commodity that you delivered, etc.
For this physical example, we would assume that ‘actuals’, i.e., actual quantities/volumes delivered would also be fed into the new CTRM System.
2.4) Phase #4: Adding MTM (valuations)
Up until now, we have assumed that the new system running in parallel has just trades and settlement prices. In order to calculate MTM values, you also need to add forward prices (a.k.a., projected prices). And volatilities and possibly correlations for valuing options.
Once you start running MTM valuations in the new system, you can create these types of reports:
2.4.1) MTM (valuation) reports. A version of these are required for regulatory reporting.
2.4.2) PnL (Profit/Loss) reports, showing daily changes to MTM values
2.4.3) Potentially PnL Explained (a.k.a., PnL Attribution)
2.5) Phase #5: Adding Market Risk as ‘greeks’
This phase add the ability to calculate the ‘greeks’ and use them in reports. ‘Greeks’ like ‘Delta’, which shows how the MTM would change due to small changes in the prices (i.e., sensitivity to market price moves), ‘Vega’, which is like ‘Delta’ except for volatilities/options, ‘Theta’, which shows how the MTM will change from the current date to the next business date.
This allows for an ever wider set of reports/reporting.
2.5) Phase #6: Risk Management, VaR and Stress
This phase adds VaR (value at risk) and ‘Stress’ short for ‘Stress Test Reporting’ where market prices are ‘shocked’ in a simulate move up or down to see how the MTM would change in value.
3.1) We expect firms to offer ‘risk as a service’ type offerings, i.e., they may be available now or, if not now, then soon. So it may be the case that just by reaching one of the early phases of deployment, i.e., getting all of the trades in the new CTRM System, then you can interface it to a Web Service for MTM valuations and Risk reporting. We feel this is going to be a compelling deployment option for firms in the future.
3.2) The above example of phases didn’t cover important parts of a CTRM solution, notably scheduling (a.k.a., logistics), so be sure to take that into account as well.
Introduction to CTRM
Click on this link for a great introduction to CTRM software: Introduction to CTRM Software