Awareness of the fact that missing or inaccurate standing settlement instructions (SSIs) are a major inhibitor to true straight-through processing (STP) is as long-standing as the industry’s focus on STP itself. Problems with SSIs are still the biggest single cause of reference data-related trade fails, which themselves are the second biggest cause of fails behind short stock. Periodically the SSI problem rises to the surface of the industry’s consciousness and an initiative is born to try to address it, but as things stand today the challenge of maintaining accurate SSI data – which is anything but “static” – remains as acute as it has ever been.
Admittedly, there could be hope on the horizon, as bank-owned co-operative Swift prepares to round once again on the SSI arena, as part of its broader initiative to create a reference data repository hosted on Swiftnet. Swift freely admits that its last foray into SSIs – which involved encouraging participants to populate a central repository with data using FIN messaging – was far from successful. But it is hoping that with its new generation of messaging solutions and its new Swiftnet hosted repository it can be more successful this time out. The area is ripe for a centralised solution, Swift reasons, on the basis that everyone would prefer to only have to worry about the accuracy of their own data, and to be responsible only for that.
Swift is also hopeful of securing a partnership with Omgeo, provider of the dominant commercial SSI database in the marketplace, Alert, thus bringing together its own community, strongly dominated by custodian banks, and Omgeo’s user base among the investment management and investment banking sectors of the marketplace, and neatly facilitating an end-to-end, industry-wide SSI solution. While it seems certain Swift is planning an announcement on SSIs at its forthcoming Sibos conference in Boston in October, whether the Omgeo tie-up will come off is less certain; the relationship between the two entities has had its ups and downs in the past, and Omgeo is understandably reluctant to see a revenue stream cannibalised by a utility-based service.
If this latest SSI initiative were to be less than a resounding success it would come as no surprise to industry observers, who have seen other attempts to streamline SSI processing come to little or nothing during recent years. The much vaunted SSIFresh initiative – centring on appending SSIs to FIX messages to better “electronify” their communication – did seem to have a good degree of momentum behind it during the early years of this century, sponsored as it was by industry best practices champion ISITC Europe and some of the leading FIX proponents. SSIFresh even spawned a commercial ASP initiative, Centralise, which sought to put the new model into practice, as well as accommodating the transmission of SSI information in other formats. But the investment management community in particular seemed to pull away from SSIFresh on the grounds that it didn’t really alter the electronic trade confirmation (ETC) model enough to make a real difference to them – and Centralise never made it off the starting blocks.
Similarly, some of the other commercial SSI businesses that have sprung up in the past few years and looked to have the potential to compete with Omgeo Alert have not yet made the impact that might have been hoped for. SSISearch, for example, which has established itself as the de facto SSI service for settlement instructions related to CLS on the FX payments side, had made noises about extending its franchise into the securities world, but there is little evidence of it having done so. AccountNet, the SSI component of Thomson TradeWeb’s STP services (supporting its fixed income electronic trading capability), also looked a likely contender to be the new generation of Alert (since Omgeo is a joint venture of Thomson Financial and DTCC, it shares a parent with TradeWeb), but although Omgeo has done some work to migrate legacy DTCC SSI technology into the Alert environment, AccountNet has not yet begun to play the role that might have been expected of it.
As a result of the fact that much of this industry and service provider level SSI activity has yielded little or no change in the status quo, market participants are left with a similar set of challenges when it comes to maintaining ever-changing SSI data to those they have always had. And the issues faced by one sector of the marketplace – the broker/dealers – have perhaps been even more overlooked. As Ben Marsh, managing director at iMeta Technologies, points out, even if the SSIFresh model were to take off – and there is still some appetite for it, he says – it would likely divert already electronic communication away from Omgeo Alert on to FIX; fund managers already trading electronically with their brokers might well shift to appending SSIs to FIX messages, rather than using Alert, but the advent of such a solution would be unlikely to make much of a dint in the plethora of non-electronic sources of SSI information with which broker/dealers have to cope.
Brokers have to manage “a very large number of disparate sources”, Marsh says. “Alert covers 70 per cent of the volume of changes, and that’s if you’re doing institutional equities in Europe and North America. If you are doing Asia FX there is very little chance of getting that data on Alert.” As well as the other electronic sources mentioned above, which have taken off to varying degrees, brokers must handle a range of other types of sources – “emails, faxes, word documents, CDs of files and even books in the post” – and typically the process of dealing with these is “pretty manual”, he reckons. A solution from Swift could potentially go some way to reducing reliance on non-standardised and non-electronic sources, he says – perhaps particularly if Swift were to focus outside the core Alert domain of equities and fixed income and look more at foreign exchange and derivatives. But currently, the average broker is being bombarded with a bewildering array of SSI information coming into its shop in numerous different ways.
And for the brokers, the SSI management challenge is compounded by high volumes, Marsh continues. “Certainly within the larger investment banks, the problems around managing data are due to a large extent to volume, especially for organisations that are cross-asset and cross-geography. And when changes do come, they can impact a large number of people at once: one change in one geography can impact many SSIs, and people using them to clear trades.” Controlling the changing SSI data is another major headache, he adds. “Quite often this is coming into many different places in the organisation at once. All the bigger banks have centralised reference data teams that are responsible for keying data into systems. But SSI data comes in all over the bank – in the client services area, in the front office, where new accounts are opened, in the settlement area where there has been a break… Once it’s in there, because of the way in which these organisations have grown up, they are often keying it into multiple systems. This is a day in, day out activity. Larger organisations will have 50 to 100 people doing this, and a lot are trying to employ bodies in offshore locations such as India and Singapore to make the process more cost-effective.” That this is a costly activity for investment banks is beyond doubt, Marsh says. “I’ve never met a bank that can tell me how much this costs them, but they do think it’s substantial.”
Given the industry’s recent focus on centralising management of reference data – not just instrument data but other types of counterparty data, driven by regulatory and customer service demands and the desire to improve cross-selling – and launching enterprise data management (EDM) programmes based on centralised data stores and streamlined workflow processes, one might expect that investment banks would have tried to bring SSI data into the EDM fold. This is not typically so, however, Marsh reckons – because SSI data has tended to be managed operationally and within operational and regional silos. “This is viewed as operational data. While the banks have made a considerable effort to centralise some other types of counterparty data in order to meet compliance obligations, and may have used third party databases such as those from GoldenSource or Asset Control, the vast majority of brokers we talk to who have consolidated SSIs into one database have used inhouse built systems.” So SSI data is typically falling outside the remit of centralised reference data management programmes, meaning it has not benefited from efforts to standardise practices and processes in order to increase efficiency.
So, the general belief that improving STP is A Good Thing, and potential industry level solutions from the likes of Swift aside, are there other strong drivers for broker/dealers to improve their SSI management? Increasingly so, Marsh believes. One is that great current driver of improvements of all kinds, MiFID. “The whole settlement piece impacts on best execution under MiFID,” he says. “It is no good if you get a great price, but then settlement breaks make that great price meaningless.” SSIs cause settlement breaks and fails, which cost money to repair, diminishing the gains achieved by attaining best execution in the first place, ergo brokers have a strong motive to improve SSI management and prevent breaks. “If the buy sides are looking at operational effectiveness across the board, and incorporating it into their pricing models for best execution, then doing this becomes much more important for the brokers,” Marsh continues.
Another strong motive is the increasing practice among investment managers of monitoring their brokers’ operational performance and apportioning their business accordingly, penalising poor performers with fines and even trading embargoes. Now that operational performance is definitely forming one of the criteria for the “broker vote” – meaning that good STP can certainly win business for brokers and poor STP lose it – SSI management as a key element of operational efficiency gains in importance, Marsh says. Indeed, the most recent ZYen survey into the operational performance of brokers in the European securities market – based on responses from their investment manager clients – shows that in 2006 clients reported a six per cent improvement in their brokers’ handling of static data over 2005, which appears to contribute to an overall improvement in settlement last year over the previous year.
“All the big brokers have service level agreements (SLAs) for confirmation timeliness with the big institutions they look after, and SSI management impacts their ability to meet these SLAs,” Marsh continues. “The investment managers are increasingly demanding homogenous service levels across asset and across region,” he adds. “The way banks are typically set up to manage SSIs precludes that, because SSIs have been regionally and operationally managed historically. Such a set-up makes it very hard to offer the same level of service across asset class and region.”
In all probability, even if new SSI utilities such as that envisaged by Swift do get off the ground, they will likely build up strength in particular asset classes and particular regions in the first instance at least. The prospect of broker/dealers being able to get all their SSI data from one standardised electronic source is a remote one for the foreseeable future. And the imperatives for broker/dealers to improve SSI management seem to be too powerful for this to be put on a back-burner to “wait and see” what the industry comes up with.
Another option is to implement a third party solution capable of taking in SSIs from a range of sources in an automated fashion, and populating downstream systems with the updated information, helping to ensure data is properly maintained and removing the expensive, risk-prone and inefficient manual component of the task.
Subscribe to our newsletter
