|
|
|
|
Main
Page by Topic |
||
|
C. Statistics |
||
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.
Outline
2) Focus on Strategic Approach: Long-term Parallel
3) Notes
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.
2) Focus on Strategic
Approach: Long-term Parallel
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:
2.1.1.1) ‘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.
2.1.1.2) 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:
2.1.2.1) Something simple like a ‘Trades Done Today’ report.
2.1.2.2) 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.
2.1.2.3) Tie
outs/reconciliations with exchange for futures contracts
2.1.2.4) 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) Notes
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