Published: August 18, 2014
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.
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.
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.
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.[[[PAGE]]]
More sophisticated OMSs will typically offer rules-based portfolio optimisation tools as a key component of the system, suggesting an optimum trade or set of trades in line with an organisation’s treasury policies and preferences, which can then be imported into the trading platform. However, where these types of OMS are not implemented it will be possible to use the optimisation tools embedded within some trading platforms, providing the required data to make the optimisation rules operational can be imported into the platform. So depending on where automated portfolio optimisation takes place, if at all, integration will need to allow the importing either of optimal trade sets into the trading platform or the data required for the platform to use its own portfolio optimisation capabilities.
By this stage of integration planned trades can be automatically uploaded to the trading platform from the OMS and optimal trades executed without the need for any manual intervention, except the approval of trades prior to submission if required. Executed trades will then be automatically booked into the TMS together with any associated market data required for audit and reporting purposes. The next step in the process is to automate the settlement of investments made through the platform. Where settlement is made through the TMS this requirement will normally be taken care of at the TMS integration stage by ensuring that all the required data to enable automated settlement is exported from the platform into the TMS. However, where this isn’t the case it’s important to identify whether the platform can provide any support to the automation of settlement and whether there are any integration requirements to achieve this. MyTreasury for example has developed an auto-settlement capability that allows investors to generate and send SWIFT MT101 Request for Settlement instructions to their own banks for the direct transfer of monies to the fund or bank where the investment has been made, avoiding the need for the cash to pass through any third parties. This does not require integration with any other treasury systems as it uses MyTreasury’s own SWIFT infrastructure, but other platforms may have some kind of auto-settlement capability that does have integration implications.
The final stage of integration is the one required to maximise the value of all the information collected for and generated by the trading process. An electronic trading platform is a repository of a lot of valuable information and a gateway through to significant information held in integrated systems. The emergence of portfolio analytics is a good example of how platforms have begun to provide consolidated reporting drawing information from across a range of systems to add significant value to what have previously been standalone databases. As the range of instruments traded increases the scope of consolidated reporting will also need to be extended, quite possibly beyond those traded on the platform, to include trading and market data from the TMS and other systems. And rather than just being a standalone process at the end of the trading continuum it will actually become an integral part of the workflow. For example, providing appropriate integration has been achieved key reports in areas such as portfolio analysis and consolidated exposure reporting will be fed back into trade planning and risk management processes to ensure dynamic optimisation of investment and compliance with treasury policies.
Click image to enlarge
The fully developed infrastructure will look something like the one presented in Figure 1. Not all of the components will be relevant for all organisations and things may be done in a different order from that set out in this article but the message is clear. The fate of single-product standalone trading platforms is already sealed. The future is multi-instrument, automated and integrated trading platforms delivering substantial added value to corporates in their ever more demanding search for more cost effective solutions. At some stage this may well lead to a blurring of the boundaries between the different types of system supplier, but this is unlikely to be in the immediate future as the existing boundaries between them are still quite sharply defined. But it will still be an interesting area to track as the one absolute certainty is that things won’t remain the same for long.
How Thought Leadership Can Reduce the Cost of Sales by Patrik Havander, Havander & Partners A focused attention on the costs incurred by the global sales and marketing processes is becoming increasingly important for corporate banks and their transaction banking departments. While the client/bank relationship remains vital, research has shown that in fact relationship selling […]
