MMF Trading Portals in the Joined-Up Generation: The End of an Era
by Justin Meadows, Founder and Chief Executive, MyTreasury
When MMF trading portals were first implemented in the early 2000s they were typically single product, stand-alone systems delivering basic market discovery, trading and reporting capabilities. Since then the vision of electronic trading has developed into one of multi-asset class portals providing access to a broad range of instruments across different markets. The need for this is now widely accepted and MyTreasury is already offering a significant range of products in addition to MMFs and actively working to bring more on board. So it’s no longer a question of whether the end for dedicated MMF platforms is in sight, it’s simply a question of how quickly they disappear altogether from the treasury trading landscape.
The continuous revolution is now spreading more widely than just adding extra asset classes, and the focus is shifting onto the implementation of a fully integrated and automated treasury trading infrastructure. When this has been implemented a single click is all that’s required to optimise, execute, book, settle and report all treasury trading activities within the framework of local and global treasury policies. Whilst there has been an emerging understanding of just how powerful an integrated electronic trading set-up might be, this has not yet been reflected in its widespread implementation. But the continuing pressures on treasurers to deliver greater operational efficiency and effectiveness with reduced budgets is leading inevitably to the broader adoption of technology solutions and increased efforts to join these up into a fully integrated treasury trading infrastructure.
As with most large-scale technology implementations it is usually better to build the required infrastructure in stages rather than to attempt a ‘big bang’ approach with all its associated risks. The structuring and sequencing of this will of course vary from one organisation to another but it’s possible to identify five basic stages that will be required to achieve a comprehensive integration.
Stage 1 – The trading platform
The core of an integrated trading infrastructure is of course the trading platform itself and this is where most organisations start. To the casual observer the main trading platforms may appear to be very similar with only marginal, cosmetic differences between them. However, the reality is that there are fundamental differences in most cases, not only in terms of their underlying business models and risk metrics but also in their suitability to form the core of an integrated trading infrastructure. Not only must the platform be technically capable of being integrated with the other key elements of the infrastructure but it must also be capable of providing the required information to these other elements as well as being able to receive and use the information provided by them.
Interoperability is the key word here – both technically and in terms of business processes and workflow. It’s important to know whether the portal captures and can export all the information needed to deliver an effective treasury function as well as its ability to receive and use the required information from other systems to ensure simple and secure trading in line with treasury policies. An integrated infrastructure should also be able to contribute to enhanced risk management and governance and so it’s important to choose one that can maximise the benefits from this. True straight-through processing and straight-through reconciliation are simply not possible without comprehensive automation, so be wary of platforms that involve manual intervention at any point. It’s worth putting in some serious effort on comparative portal evaluation to make sure you have a platform fit for the future, not the past, because integration will deliver little or no benefit if you don’t.
Stage 2 – TMS integration
Typically the next stage is to link the trading platform with the treasury management system (TMS) or whatever is used to provide key TMS functionality if a dedicated system hasn’t been implemented. Corporates are sometimes reluctant to take even this fairly elementary first step towards integration because their previous experience of dealing with TMS suppliers has led them to believe that this is likely to be a long, painful and expensive process. But this should never be the case. If a portal is properly set up to handle TMS integration then there should be no need at all for the TMS provider to become involved. For locally implemented TMSs, such as most of the Wallstreet and SunGard systems, a trading platform should be able to deliver the required data points in the required format with the required timing through the preferred transfer protocol whether this be xls, csv, xml, TMS proprietary file format, web services, SWIFT or any other transfer mechanism. It shouldn’t take any longer than a couple of weeks’ elapsed time to get this in place including QA and user testing. The situation is slightly different with those TMSs delivered on a software-as-a-service (SaaS) basis, such as Kyriba and Reval, as this requires a single, direct integration between the platform and the web-based TMS to have already been put in place at a central rather than local level. If you select a platform that has already done this then integration will be available right from the start without any additional work.
Normally the first step in this integration is to export trade and associated market data from the platform into the TMS to avoid the need to manually re-enter trades or relevant market information such as fund sizes and yields and quoted and traded deposit rates. In some cases integration is extended further to include importing data from the TMS such as eligible counterparty lists, counterparty exposure limits and consolidated counterparty exposures, including instruments not traded on the platform. Many platforms these days offer quite sophisticated risk management capabilities but they need to be provided with up-to-date and accurate information if they are to perform effectively.
Stage 3 – Order management system integration
Once effective integration with the TMS is in place the next step is to incorporate the order management system (OMS) into the trading infrastructure. The definition of an OMS can range from a fully-fledged OMS such as Charles River or thinkFolio through Enterprise Resource Planning (ERP) systems such as SAP or JD Edwards to simple spreadsheets. In other words it’s whatever an organisation uses to plan its trades. For small organisations with relatively few trades integration is not a key requirement but for larger organisations often trading high volume instruments such as FX it’s important to remove the need to input trades manually into a trading platform. Keying in large numbers of trades every day does not represent a productivity improvement.