A blog describing the implementation of a CTRM in the metals trading business.

1. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125
b5e03f18f5d8blog-metalstradingsystemimplementation-
190703210215.docx
Page 1 of 7
Metals Trading System Implementation
Introduction
We recently implemented the Eka CTRM (commodities trade risk management) system.
The accounting system that the client was using was SAP.
The project was a rescue project for us. The client had already started the project and had
run into difficulties. As such, it is a good case study to highlight the importance of project
planning and the monitoring and clarifying the progress of the project during project
management.
The project ran for longer that the client had expected and so illustrates the importance of
having realistic expectations and of the time and effort required to get a new system off he
ground.
Although this blog concentrates on the issues above with a view to learn from the
experience, this is not a criticism. At all times, all staff remained commendably positive and
professional and all the issues were worked through successfully.
Staff levels and cost savings when having a system.
The benefits of having a CTRM are the following.
 Transparency
 Methodical business process
 Scale-ability
 Meeting Financial Control Objectives
We can give you information on what each of these means and how an ETRM delivers them
separately, if you wish.
Reducing costs is not on this list for a reason…although, if business volume increases, there
will be cost savings.

2. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125
b5e03f18f5d8blog-metalstradingsystemimplementation-
190703210215.docx
Page 2 of 7
We created two extra roles, in fact.
 A risk/ performance analyst
 An extra hand for putting in trades to the system.
The risk analyst was a role required to run the reports, check them, manage any corrections
required and present them to management. Especially important as the client was keen to
ensure managers only saw profit reports for their area.
A junior role was created in the ops department who would put in many of the required
trades, working from the operators existing and various spreadsheets. There was no option
in this system to upload trades.
Cost
Business Volume
There is an initial cost with introducing a CTRM, but as business volume increases, costs increase slowly.
With no CTRM, risk measured on spreadsheets etc, costs increase proportionally to business volume.
Notice also, that with increased volume and no CTRM, transparency decreases, represented by the
colour of the line.
Cost increasing
proportionately
withscale
Cost
increasing
slowlywith
scale
Witha
CTRM
Withouta
CTRM
Initial
cost

3. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125
b5e03f18f5d8blog-metalstradingsystemimplementation-
190703210215.docx
Page 3 of 7
Selection
We were not involved in the CTRM selection process and we saw much evidence that, as
we always say, it is worth getting consultants involved with this
process. It is in the nature of people selling a system to emphasise
what it does well and give it the best spin. Equally salespeople will
not draw your attention to what will not work, or what can be
done…but not very elegantly.
It was clear that the client had been left with an over-inflated view of
what the system would be like to use and what it could do. This
does not mean that we think the client necessarily made the wrong
decision on the system. The metals commodity training business is
notorious for not having a single system satisfactory in every way.
Selection is also about getting the right people to do the job. The
client started the project by putting in a relatively junior member of
staff in charge of delivery. His was a mistake and very unfair on the
poor person. Without the experience and without a clear plan of
delivery, he was never going to be able to mange to do this. The
inevitable happened, and he crashed and burned.
To make matters worse, when he was taken off the project, no one
in the company was really sure what had been achieved to that
point. Milestones that had been reported as being delivered, had in
fact not been successful. This all made it more difficult for us,
coming in at a later stage, to make a proper assessment of the
amount of work required to rescue the project and get it to a
point where the system was up and running.
Definition
Scope
Selection
Design
Build
Deliver
All projects go through six stages as above.
Design and build are the most expensive. Getting
the first three right saves costs lateron.

4. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125
b5e03f18f5d8blog-metalstradingsystemimplementation-
190703210215.docx
Page 4 of 7
Cut-over
Cut-over is the process of putting the initial transaction data onto the new system.
When you are cutting over from a replaced system, you have to make sure that all
profits a reported in one system or the other and not both. For the CTRM on this
project, since we were not replacing an existing daily reporting system, we
did not have to make sure of this. Our cut-over rule was simple: All
business where title was delivered to a customer after the cut-over date, 1
October in our case, was put into the Live system. That meant that all the
purchases made in October onwards as well as the purchases for the
stock that existed on 1 October would go into the system. All secondary
costs from 1 November went into the system.
This meant that although the system had live data for October, profit
reports would not be meaningful until November.
It also meant that the ops, because ops entered the trades, were putting in
a lot of extra data in…simultaneously into Eka, as part of ‘lift off’,
and into their spreadsheets, as part of their ongoing work. The
extra resource that we had in the Ops team to do this was,
therefore, invaluable.
Paper Trading
Eka handles paper trading pretty well. We worked together with Eka to build the reports for
the paper traders in the way that they needed them.
The have a good process for transferring the unrealised profit to realised profit once the
derivatives are no longer traded. In fact, you cannot do an EOD until this is done. The
process is pretty easy and we got the accounts team doing this with 15 minutes training.
Reporting
Some CTRMs have what they call real time reporting. This is often not real time in the
sense that the M2Ms are being calculated from the real time values on the market screen,
but that the profit on trades can be interrogated on the system screen. They do not require
that an end of day (EOD) process has been run.
Eka cannot report in this way. It requires the EOD process to be run first, and then PnL
reports can be accessed which shows the profit on any of the days that EOD has been run.
This can be frustrating during the implementation period as you can’t run EOD unless quite a
lot of information has been put in and all the required details on trades entered are complete.
So, we were well into the process before we could run reports. The error in deal entry only
then became apparent and resulted in us rolling back EODs, correctly trades and then rolling
forward again. I think that this is something to be aware of in the future in order to deal with
the client’s expectations.

5. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125
b5e03f18f5d8blog-metalstradingsystemimplementation-
190703210215.docx
Page 5 of 7
When we did manage to start running
PnL reports, we found that there were
arithmetic errors in the reports. The
explanation for this was that the repors
didn’t work well for metals trading as
they had not been used before, Eka
not having many metal clients. The
reports have now been fixed and it
should be no problem, or less of a
problem, in future metal
implementations of Eka.
A benefit of the way Eka reports PnL is that ordinary employees using the system can’t see
the profits made. This fits in well with the client’s culture where the profit numbers are
regarded as being private.
Eka has plenty of queries to use – by which I mean that you can run lists in the system. The
operators use these as operational reports to process business.
One shortcoming of Eka is that they cannot tie in the derivative trades with the physical
liftings that they are hedging – the ‘strategy’ label is held at the (‘term’) trade level not the
lifting level. This makes some of the reporting that we would like to do for our client
impossible. Eka are looking at doing some development work in this area.
Interface
The scope of the project only included interfacing the invoices, product and secondary cost,
from Eka to SAP, and the new counterparty details. We consider his to be the minimum
piece of work and the one that offers the most benefit. The system was capable of
producing stock and accrual reports, and full paper profit reports (realised profit, commission
and open equity) that were sufficient information for the accounts team to calculate and
generate month end journals. Eka can be configured to generate these journals too. A
project to do that configuration and implementation is something that can be done as a later
phase.
The interface function in Eka is well developed. It has a fully functioning process that
manages the posting of journals that ensures that they are not posted twice, they are
reversed before being cancelled etc. They also, helpfully, allow this process to be
overridden during the implementation of the system. They have a tool that allows users to
define the account codes that invoices will be posted to. It also manages the passing of the
XML generated to the receiving system, and handling error messages.

6. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125
b5e03f18f5d8blog-metalstradingsystemimplementation-
190703210215.docx
Page 6 of 7
This meant that it was
straightforward,
although time
consuming, for a user to
set up the accounting
rules without having
technical knowledge of
script writing, for
instance.
One thing that was
missing was the
functionality of dealing
with VAT from more
than one country. We
got Eka to fix this behind
the scenes using special
script.
The journal is generated in an XML form and sent as a message to the receiving system. If
the receiving system sends back a message to say that the journal has succeeded, then Eka
makes sure that the journal cannot be sent again. Otherwise it indicates that there is an
error which must be investigated.
The system is not run in the background, it needs a human to kick it off, but it works pretty
well, doesn’t take a lot of time to operate and is generally satisfactory for small or medium
businesses.
Handling the interface from the SAP side proved to take more effort to set up.
The model that we built was to have SAP run as a simple ledger. Daily reporting, including
inventory reporting, will be done on Eka. SAP would be required to produce monthly
accounts only. There was no need to post stock entries to SAP, for instance. Instead the
monthly closing entries would ensure that the inventory in SAP agreed to Eka.
When the XML was received by SAP, it ran a script on the XML to generate a journal in that
system. As this was handled by a separate contractor, we couldn’t say why it took as long
as it did to set up in the correct way. The accounts team were not confident to switch on the
interface before copying the live SAP database and having Eka post to the copy for a month
in a genuine parallel run.
In the end it took 10 weeks from starting to work on the interface before it was switched on.
EKA
New
Counterparty
details
SAP
Reference data New trades Ops data
Trade finance
data
Daily
journals
(i) invoices
Monthly journals
(i) paper closed in month
(ii) brokers fees
(iii) accruals for paper trades
(iv) accruals for trades and costs not invoiced
(v) missing trades
(vi) stock adjustments
Reference data
(i) New customers
(ii) other reference data
Interim report
Trade finance
reports
Daily profit
reports
Daily Exposure
& VAR reports
Monthly
accounts/
Annual
accounts
Sundry
accounting
reports
Sundry
volumetric
reports
Credit reports
Bank
movement
details

7. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125
b5e03f18f5d8blog-metalstradingsystemimplementation-
190703210215.docx
Page 7 of 7
Project Management
We managed the project using modern project software, Monday.com. This was web based
which meant that stakeholders in different locations could all access the same data on the
project. Each project task was held on a ‘pulse’, which is a line on the main table. But each
pulse was capable of holding all of the communications about that task in a social media
type format (similar to Facebook) that felt very familiar to everyone using it.
Monday.com allows you to build custom tables, with each project task represented bya line or ‘pulse’. Attached to each pulse
is all of the correspondence,files, documents that were relevant to tackling the task.
Once the system was up and running, we withdrew from the project. There were still just a
few outstanding tasks on the project that the client could work with Eka to complete. This
saves the client money on our fees. Using Monday.com meant that when we, as
implementors and project manages, withdrew from the project, we could leave the client with
this tool to monitor and follow up on those remaining tasks.

8. Z:tempwindows20190703210215_56fb739c2682e721618f0cb85125
b5e03f18f5d8blog-metalstradingsystemimplementation-
190703210215.docx
Page 8 of 8
Things to learn from this project.
Even on a project in a small company, it is worth formally going through all the stages
of a project, eg Definition, Scope and Selection, and making sure that they are
complete. And in the case of selection, it is well worth getting a consultant, like
ourselves, involved so as to be sure to understand what a vendor can really deliver,
and what is just sales talk.
It should be recognised that running costs will be higher with a CTRM. The extra
junior resource that we had in the ops team really helped. It would have also been
helpful to have recruited the risk analyst earlier so that they could have helped in
setting up the project and, for instance, entered pricing data and ran EOD procedures
for us during the implementation instead of us having to do this ourselves.
Leaving a project to internal staff and expecting them to deliver a system in addition
to their existing tasks is a recipe for disaster. It increases the risk that the project will
fail; and it increase the risk that those people will make errors in their existing work.
The cost in the goodwill of other members of staff who will also be asked to help in a
project that doesn’t get off the ground, also hurts the company.
Having project management software that you can leave with the client is really
helpful in making a good, professional handover to them at the point when it is more
cost effective for the client to take the project back in house.
If you are taking over a project that has already been started in house, don’t assume
that what the client tells you has already been achieved, really has been achieved.
Conclusion of project
The project was a success and the client has a
system that is running, is interfacing to their
accounting system and is reporting profit to
them every day.
There are certainly areas where the system
and process can be improved. This is always
the case, and we would be happy to go back to
the client to help with this if they think this
would be helpful.
In the meantime, they will bed in the process,
get used to it and get value from it.