The Value of Knowing Your Traded World.

Ian Moore, March 2007

The issues facing any organisation for post execution transaction processing are well understood. At a high level, a transaction enters the system and, on the said settlement date, will complete the main stage of its lifecycle.

However the transaction will need to pass many milestones within this life cycle and these milestones also have their own constraints and deadlines. With the creation of improved message formats, the quality of financial messaging and interbank communications has risen. Many problems that were traditionally seen as prone to error have in recent years seen massive improvement. But only now is it realised that there are still other operational areas that could be improved.

As companies grow, more and more systems have been bought on board to solve the problems but have themselves introduced issues when attempting to track a transaction from start to finish. Likewise, acquisitions can also introduce short term increases in system-counts, or even long term if the cost and difficulty of migration far outweigh any benefits. These problems mostly materialise in the middle to back office of operations centres.

The back office operation in many organisations is seen as a cost centre adding little value to the business. At present this role is seen as a burden on profitability but, as better reporting on costing is required, the true financial cost is more exposed to clients than ever before. Indeed it is often the case that the actual cost of an individual transaction, both from messaging costs through to its share of staff costs, to ensure its successful completion of its life cycle, are rarely known.

So where can improvements be made? Whereas traditionally most of the focus has been on counterparty performance, often because it is the most visible and easy to monitor, now even peformance of internal systems needs to be scrutinised.

Management reporting and SLA agreements are often in place to perform the basics of cost trends, but where is the true picture of what leads to these costs? Though often assumed there is little that can be done in this area, if one system were to know the complete history of a transaction and users had only one place to look, could there be improvements in these areas?

Careful analysis of exceptions and accurate alerting can reduce the burden put upon users whose job it is to resolve processing issues. Indeed the analysis itself could highlight "what if" scenarios whereby simple changes to internal procedures could produce better quality processing at a lower cost.

By collecting information in one place, more and better analysis can be achieved. By correlating the data, patterns will emerge of different scenarios and it may often be the case that small improvement in one area could lead to long term cost reduction. By allowing the collection of different data or through business managers being capable of changing the scope of their enquiries, do patterns emerge?

There are many examples of how this analysis could help. If static data is missing could that be reported in almost real time to the department concerned? When there are exceptions, can these be instantly prioritised, automatically focusing the users on the transactions that could result in the most failures. If these crucial exceptions are caught, these too can form part of the analysis and highlight scenarios faster. By knowing how long it takes to solve an issue, can this be equated to staffing costs? It may be the case that even a small number of transactions of a particular type, even though only perceived as a minute percentage of the overall volume, could, if fixed, result in a disproportionate cost saving to the business.

Regular failures by one of the parties involved may result in higher costs - even if the time taken to fix these is small, and solved well within deadlines, additional message costs may be incurred but rarely realised. Improved quality or checking could prevent these costs.
Where possible can repairs be centralised whereby the main monitoring tool is used to automate requests to other systems to perform the repair. In this scenario the user can take actions that will in turn generate requests to other systems to perform the action, thus reducing the overhead of the number of systems the user has to access simultaneously.

Staffing levels often need to be kept to cope with peak demand. Are there times when this demand could be reduced? If certain operations took place internally at slightly different times could this even out those peaks?

We have spoken of the milestones that a transaction must itself pass though in order to complete. The settlement date is the ideal. But the reality is that the sooner any transaction can be processed, the more time to deal with any potential issues. Again allowing more time could result in lower staffing costs. Accurate, easily customisable analysis can assist in solving any of these issues.

About Tradeshape
Tradeshape is an innovative provider of cash and liquidity management solutions that empower financial institutions with the ability to better manage their capital once a trade has been executed and thus to ‘know their traded world’. The solutions are targeted at fund managers, wealth managers and hedge funds. Tradeshape was founded by executives with over 60 years of experience in financial messaging, cash management and automated transaction processing with the aim of delivering increased liquidity control and better financial transaction processing and analysis. Tradeshape is located in Cork, Ireland, and London, United Kingdom. For more information see www.tradeshape.com.

Press Contact:
Jenny Swift
Rivercalm
Tel: 0044 207 665 1636
swift@rivercalm.com