The Data Gap Between Published SSIs (Standing Settlement Instructions) and Usable SSIs:
Where is the data gap?
My experience when working with a number of broker dealers on delivering iMeta’s Assassin SSI management system has highlighted a recurring problem. Broker dealer’s common problem is the data gap between the pure SSI, published by their investment manager client, and what actually needs to be set up in their settlement system(s). This data gap is usually caused by settlement system specific codes for products, settlement market, booking entities etc. which must be manually entered along with the main investment manager published SSI details.
This leaves the broker dealer with a resource intensive exercise, which may need to be repeated across multiple settlement systems for a single SSI. Each time an SSI gets manually keyed and enriched, for use by a specific settlement system, the scope for data entry errors and subsequent failed settlement increases. This issue applies to all the different SSI data sources a broker dealer may be managing. SSIs from Omgeo’s Alert system, or a pdf document published by the investment manager will both need system specific enrichment before they can be used.
Bridging the data gap:
In order to tackle the issues caused by this data gap, the broker dealer needs a solution which combines three stages.
The first stage is to break down the silos of SSI data which get built up around the different settlement systems. By creating a centralised golden copy SSI repository, the effort and risks of duplicated data entry are removed and the settlement system specific data requirements can be consolidated.
The next stage is to implement an SSI data model which is flexible enough to accommodate the consolidated system specific data in conjunction with the pure SSI details published by the broker dealer’s client. With all the consolidated data modelled in a single location the options for tackling the data gap start to open up.
The final stage builds on the first two stages – the automation of the SSI enrichment process for the specific settlement systems data. This can occur at a number of points within the SSI management process; be it automated field populating during data entry, or message enrichment at the point an SSI flows from the centralised SSI repository to one or more settlement systems.
Bringing all these stages together enables the straight-through processing of SSI data from a source like Omgeo Alert, even when the data needs to be distributed to multiple settlement systems. Achieving this will free up valuable resources to focus on the management of settlement exceptions and manually sourced data. This also removes the need for rekeying the data across multiple settlement systems, providing valuable efficiency savings.
by Adrian Haken