The Gateway to Algorithmic and Automated Trading

Case Study: Nordic Models - Auto FX at DnB NOR

Published in Automated Trader Magazine Issue 03 October 2006

DnB NOR is Norway's largest financial services group with total assets of more than NOK1400bn. The group has an established history of proprietary trading that was expanded in mid 2005 with the addition of an API trading program for FX. AT talks to Jan Stromme, the programís architect, and Paul Nerby, its head trader, about the programís technology, techniques and markets.

Jan Stromme and Paul Nerby Auto FX at DnB NOR
Jan Stromme and Paul Nerby

What were the factors that prompted DnB NOR to consider automated FX trading?

Jan Stromme: DnB NOR has a history of active proprietary trading relative to its size. The initial objective was to automate this approach and also to try and expand into previously unexplored areas.


How did you both become involved? Did you already have previous experience in this field?

Paul Nerby: I had been working as a proprietary trader at DnB NOR for about seven years. I was interested in possibly porting some of the techniques I had been using when trading manually to an automated environmen

JS: I had formerly worked at EBS, which had recently made API trading available on its platform for qualified users. I had gained insight into the architecture and modelling required for API trading from my involvement in that.


How long has the project been running?

JS: The project began in earnest in September 2005 when we started putting together the infrastructure and tools. There were three of us; Paul, myself and a dedicated programmer working on the project and we had completed the first phase by November 2005 when we started testing and evaluating models. Live trading began in early May of this year. A mixture of the summer vacation season and some minor networking issues that we needed to resolve have meant that recently we temporarily suspended live trading, but this will resume shortly.

PN: The temporary lull has also allowed us to examine the performance during the live period and look at possible refinements and additions that we might make during the next live trading period. Apart from the models themselves, we have also been looking at ways in which we might make the code leaner and meaner in programming terms.


Were there any significant obstacles that you needed to overcome in terms of technology or internal controls/risk management before going live?

JS: No, not really. We undertook an extensive planning exercise and made sure that we involved the right people from inception to go live. For example, we were in regular contact with IT and risk management, which helped minimise any potential internal technology and risk issues. It also meant that we made the most efficient use of the available resources, as any reworking was kept to the minimum. Another factor that was hugely beneficial was that the bank's management is very knowledgeable about model trading and comfortable with the technological concepts involved. They were therefore willing to allocate the right resources from the outset and allow the API trading team to be autonomous with regards to decision-making. (quote here)

PN: I would agree. In general, it was very plain sailing - particularly internally. We did have some minor issues with API version compatibility and some marketprovided test environments being not totally representative of live market conditions


How many people do you have on the team responsible for your automated FX trading? Has it been a particularly resource-intensive process?

JS: There are typically five or six people involved at most. In terms of API trading of FX, DnB NOR is one of the smaller trading banks and was also one of the earlier entrants to this market. As to resources, we set out with the objectives of going live within a fairly tight timeframe but with a relatively modest budget, whilst also minimising any internal ripple across the departments involved.


How are the participants split in terms of duties - e.g. how many traders, quants, tech support etc?

JS: There are two core project participants; a prop trader (Paul) and a solutions architect (me). There is also a specialist programmer, as well as a few additional risk management and IT personnel involved on a more occasional basis.

Which trading platforms are you connected to and which pairs do you trade?

JS: At present we are API trading on Reuters and EBS. As of now, we focus on the pair where historically the lion's share of our trading has been done, namely EURUSD. However, we also deal in other majors, and we are monitoring other currencies closely for future potential. While we aren't trading a huge range of pairs at present, applying our trading models to them is just a case of plugging them in and turning them on.


So is there an inter market arbitrage element to your trading? And would you describe your models as ultra high frequency?

PN: Inter market arbitrage was originally one of our primary intentions, but in practice it has actually been a relatively small element in our trading. As to frequency, we are not particularly hyper-frequency, though by the same token we certainly aren't position trading - we don't hold trades overnight.


Is your automated FX trading proprietary or hedging in nature, or a mixture of both?

JS: Our trading engine is designed from a proprietary perspective. There are possibilities for hedging, but the interaction with our booking/risk-management systems is at present one-way only, so there is no automated hedging initiated by the engine and generated from the exposure management system. Any hedging trades would therefore have to be undertaken manually by a human trader.


Are you using one primary trading model or a portfolio of them?

PN: A portfolio of models - as a basis, we are replicating some of the methods I was using as a manual trader, but then improving on them. Apart from "systemising" these we have also added some additional models in order to improve diversification and achieve a smoother equity curve. As part of this, we have started to examine some longer term ideas. As I said, we are not especially hyper-frequency in our approach, but this combination of models is resulting in a higher trade count than when I was trading manually on or off manually. So we might start the day with all the models firing on all markets, but we might turn some of them off if they don't perform as expected during the day. We sometimes also turn off models or markets in the run up to a major economic report.


Has this higher trade count made slippage much of a problem for you?

PN: To some extent, yes. We have obviously encountered some slippage, and in some of our models slippage can have quite a detrimental effect, but this certainly hasn't been a huge problem in most cases. By sticking to the most liquid pairs, such as EURUSD, we haven't suffered much frictional performance degradation.DnB_NOR_London_building.JPG


How does the design process work?

JS: Either Paul or I will come up with the underlying concepts for new trading models. We will discuss these and any that seem promising will be passed to our programmer for coding. We will then back test these and if satisfactory will run them in simulation mode. If the results are still satisfactory, the model may be included in the portfolio.


Would you describe your trading as completely automated, or is there still some human input in real time?

JS: It is not totally black box - more what you might call grey box. While order execution is automatic we are also monitoring the trading process very closely. We have a dashboard that allows us to monitor the triggers of the various models and markets which we can turn on or off manually. So we might start the day with all the models firing on all markets, but we might turn some of them off if they don't perform as expected during the day. We sometimes also turn off models or markets in the run up to a major economic report.


Would you describe your models as completely selfadaptive?

PN: Up to a point, but we think there may be practical limitations to this. For example, we have occasionally observed some potential for altering/skewing models on certain days when market behaviour seems to differ between US and UK time zones. Therefore one possibility would be to have separately calibrated models for the two time zones for these occasions, though each group of models would be self-adaptive as regards its particular zone.

"...we have occasionally observed some potential for altering/skewing models on certain days when market behaviour seems to differ between US and UK time zones".


Are you pleased with the results of your automated FX trading to date? Is it in line with your expectations?

So far so good. It is early days still, but consistent positive returns certainly appear achievable based on our experience with live trading so far. At the outset, we felt that API FX trading could add value to the prop desk and that impression has certainly been confirmed.

So, do you think you might expand your API trading into other non-FX markets? At present we are sticking to foreign exchange, but we could move beyond that if things continue to go well. We're keeping an eye out for other markets though not actively researching them. Our main focus remains EURUSD, though we also trade a certain amount of cable. As I mentioned earlier we aren't API trading any Scandinavian currencies as yet because the liquidity is rather erratic. However, since we are obviously well acquainted with these currencies we may well branch out into them in the future as opportunity and liquidity permit.