IBSI Announces Subscription Flexibility !

IBS Journal now starts at £9 per issue, and custom Reports at 40% off
READ MORE

In parallel with its core banking system project, National Australia Bank (NAB) is implementing Murex’s MX.3 on a global basis to support its FX operations. What has been achieved to date and what is still to be done?

National Australia Bank HQ, Melbourne

National Australia Bank HQ, Melbourne

NAB has been busy on the systems front over the last few years. Much of this is a work in progress, but it has implemented Oracle’s new core banking system, Oracle Banking Platform (OBP), for its UBank offshoot and plans to roll out this within the rest of the bank (IBS, September 2012, Oracle officially unveils its new core banking offering). As if that isn’t enough, it has also been undertaking a major overhaul of its trading operations, centred on Murex’s MX.3. As with the core system, not everything has gone smoothly but there have been a number of breakthroughs of late.

It has been a long project but NAB is now live on MX.3 for much of its FX trading and processing in Melbourne and is rolling out to its international operations on a phased basis. By so doing, it will end up with a much more standardised and centralised infrastructure. All operations will connect to Melbourne through a single pipe and all processing will be here, with a single end-of-day and, ideally, using a single legal entity, NAB Melbourne, although there will be the flexibility to use other legal entities if appropriate.

NAB has been replacing a mix of old, customised packages and in-house solutions for its trading operations. Deep at the heart of the mix was a customised version of the old Infinity system, which now resides with Sungard. The systems were not multi-product which meant issues around balancing, reconciliations and consolidated reporting.

The search for a new platform started around six years ago. NAB had a clearly stated preference for a package rather than an in-house development. The first couple of years involved due diligence of suppliers and systems. As a minimum, the bank was seeking a system that supported FX, interest rate products and commodities, says Tom Pragastis, NAB’s global head of FX and commodities and financial institutional sales. However, it proved to be reasonably difficult to find a multi-asset class system. ‘A lot of vendor systems, when you looked behind, did not have the breadth or depth of product coverage needed, particularly for FX options,’ he feels. The bank took in all of the standard solutions during its selection. ‘A lot of the usual suspects, once you went beyond spot and forwards, we thought were much narrower than we needed.’

NAB looked, unsurprisingly, at the likes of Calypso, Misys with Summit and Wall Street Systems. The selection was primarily run by the business, albeit with ‘intense advice from our specialist IT team’ and he describes it as a ‘shared decision with a shared vision’. There was no third party involvement. Murex was considered to be a long-standing vendor with well-recognised capabilities, says Pragastis. The supplier had users in Australia, albeit on earlier versions of its system, with NAB claiming to be the first taker for MX.3 here (there was some blurring of the edges of what was, and was not, an MX.3 deal or an Mxg 2000 deal around the time of the transition).

Importantly, Murex had a presence in the country, including a team of experts and consultants. Pragastis says: ‘One set of criteria was around who is here locally, because there are a lot of carpet-baggers, they fly in, say “yes, we can do it”, and fly out again. That model doesn’t work. For something this complex, on this sort of scale, there is a need for people to live with and eye-ball each other daily. We have our fair share of video screens and remote set-ups, but there is nothing that beats everyone in the same room, pounding keyboards, sketching diagrams, talking to users in the hallways and so on.’

MX.3 was considered by NAB to be a major step forward from the previous version of Murex’s long-standing flagship, Mxg 2000. It was a partial rewrite and had what was felt to be a significantly enhanced architecture. It was considered to have good front-to-back support for FX cash and, while there were gaps, these were intended to be filled by Murex during the project. Remi Lagane, general manager for Murex in Australia, says early in the process, before the contracts were signed, there was a list of gaps for FX cash and it was a partnership from day one to identify and deliver these. The process of plugging other holes was a bit of an evolving one, says Pragastis. Where there was thought to be a gap, NAB would highlight this with Murex and, if there was sufficient demand from the supplier’s client base as a whole, it would be prioritised and built.

The first focus was FX options. ‘FX options was a small but complex enough book to give the system a good shaking,’ says Pragastis. It was a manageable size, he says, but by virtue of touching all parts of the infrastructure, also meant that everything would be tested. ‘If we had gone for the spot or forward books, that would have been a problem, even though they are a lot simpler, they are a lot riskier.’ This first phase allowed NAB’s own developers to learn about the system and it only moved on to higher volume areas once the first phase was refined and the bank was happy. One of the main lessons, he says, was that you need to give developers time to learn the system. ‘We tend to overlook that from a scheduling point of view. I think because we never baked that in our original plan, that contributed quite a bit to the over-run. Whether you schedule it or not, people need time to learn.’

FX options went live in October 2010. Attention then turned to cash products, with these implemented in a couple of stages, in February 2012 and July 2012. NAB started with the front office and trades were still being settled in the old system before the back office part of MX.3 went live. ‘It was very staged, to minimise risk,’ says Pragastis. One of NAB’s counterparts, described by Pragastis as ‘supposedly the leader in bank IT implementations’, was experiencing a disastrous project at this time, with this still unresolved, he feels. ‘We think we were sensible taking a bit more time although we did spend a lot of money doing it. If you consider the costs of what our competitor bank is going through, we believe it was worth the extra spend.’

Why did it go over budget? ‘Like all these things, whether it is naivety or vendor exuberance, there is probably a level of optimism,’ says Pragastis. It is something a lot of organisations grapple with, he feels. The initial plan was very aggressive and there is also the complexity of the product sets to consider, such as the events and triggers around FX options, plus the number of connections and amount of integration.

Tom Pragastis, NAB

Tom Pragastis, NAB

Nevertheless, Pragastis gives the implementation a mark of ‘eight and a half or nine out of ten’. He adds: ‘We know how much certain peers of ours have spent on systems that probably do a lot less than we have achieved.’ He describes Murex as ‘a good partner that stayed the course’. When there were issues, Murex responded well, he says. ‘They really understood what went wrong and worked to sort it out.’ At times, it would have been very easy for NAB to have given up, he says, ‘but our alternative view was, look, we’ll spend a substantial amount of money, which no one will give us again, so let’s make sure it works and we leave a decent legacy for the next generation’.

Ownership of all of the ‘high-value’ parts of the project resided with NAB. Of the total spend, Pragastis’ estimate is that five per cent was to third parties. ‘It was our preference for anything that could be boxed up to be put out to a third party,’ he says. This happened with formatting of confirmations and reporting, for instance. However, there was limited scope for this and there had to be a clear specification if so. ‘We wanted the learning to stay within the bank so that drove more to be done internally.’

There were some issues during the implementation of FX options but these were ironed out. There were some tweaks needed to performance, including optimisation of the end-of-day batch run. However, since July, when FX cash went fully live, the system has been ‘pretty robust’. The aim is now to improve the performance further, from around six trades per second to 15 per second. There are around 100 direct users, in the trading, middle and back office areas, and 300 to 400 across the broader sales-force. By the time the system has been rolled out to all offices, this number is likely to have doubled. At present, the legacy FX options and FX cash systems have been turned off in Australia; the international operations will be migrated on a phased basis in the next year or so.

The system runs on Sun Unix boxes with Oracle. There are more than 30 interfaces, including for market data, static data and trade capture, to a variety of tools particularly around FX cash, to multi-bank and NAB’s own portals and to internal systems, including the general ledger and payment systems. Murex’s Lagane says: ‘Especially for FX cash, which is a volume, factory-based business with simple products, there needs to be automation, so integration is absolutely key.’

There was a degree of reengineering during the project and this is ongoing. ‘To gain the full benefits meant that the way we processed transactions before had to change,’ says Pragastis. ‘We never started with the intention of putting in a new system but burdening it with old processes.’ He describes the reengineering as ’80 per cent of the way there’ for NAB Melbourne and half the way there for the international roll-out. FX processes have been standardised and the bank is moving towards reducing the number of legal names to a minimum and having a single pipe into the back-end from anywhere in the world. Every trade will flow into NAB Melbourne, with all trading using this legal name.

The regional offices are moving to the standard processes, so that the entire operation will do things one way. ‘You have to be a low cost producer, no ifs or buts about it.’ That stretches as far as accounting and product control processes, he adds. ‘For us, that is a quite significant reengineering of our processes.’

There will be a single end-of-day batch run, including for P&L accounting. This will run after New York closes and will be complete by the time Sydney’s product controllers arrive. As it is a small window, the system needs to be robust and needs to perform well, says Pragastis, so that the batch run is completed on time and does not impact the rest of the business. The system remains available during the batch run and the bank can mark-to-market on an intraday basis. One aim has been to reduce the duplication of effort across the globe. For instance, the bank now has one set of product controllers in Sydney handling the accounts for all operations, rather than three sets spread around the regions.

NAB is satisfied with the system now that it is in. ‘As a baseline for us going forward, I think it is very strong,’ says Pragastis. He believes the bank is already seeing benefits and could see full payback as it completes its roll-out within the next three years. Much of the benefit comes from the vision. For instance, it would have been possible to have implemented Murex but still had multiple separate end-of-days around the globe, he says. There will be a lot of efficiencies by the time the project is complete, he feels, including the standard processes, single end-of-day and single trading name.

Pragastis believes the bank can now scale and that this will be a major benefit. ‘We can go hard on volume because the marginal cost per transaction is nothing.’ It will also mean improved transparency and risk management. The streamlining of the book structures, with most trades and risk centralised, means from a market risk oversight perspective there will be access in real-time, from anywhere around the world, he says. The only aspect that will not be real-time, due to the different level of complexity, will be Value at Risk (VaR), he adds.

As indicated, NAB is not the only Australian bank to have been implementing MX.3, with projects as well at ANZ and CBA. For a while, there were plenty of rumblings in the market about these and how long and costly they had become. NAB appears to be the first to have had major breakthroughs but a local source feels that the other projects are now relatively on-track, perhaps influenced by seeing what has been achieved at NAB. Nevertheless, Pragastis believes that in terms of the global streamlining of systems and processes, the competition is not heading this way, so he feels that NAB has gained a long-term leap forward.

By Martin Whybrow.

 

by Darshana Adanwale
imp-loader
preloader