From OASYS Global to CTM

In January, 17 firms, including fund managers, broker dealers and custodian banks, signed on as "Early Adopters" of Omgeo's Central Trade Manager (CTM) global straight-through processing platform.  Bill Hodash was in Hong Kong recently talking to clients and exchange representatives about the initial phase of the product, which aims to replace and greatly improve on the old Thomson OASYS Global system, and he took time out to talk to FinanceAsia.

FinanceAsia: You're involved with the Securities Institute of America (SIA) T+1 committees. I noticed that in October the proposed date for change in settlement procedure to trade day plus one (T+1), was put back a year to June 2005. Did this have any effect on Omgeo's business plans?

Hodash: There are two committees I'm involved with, one is the overall T+1 steering committee, which is looking at all the building blocks needed for achieving T+1 in US securities. But then there's a separate committee for one of those eight building blocks - institutional, or transactional, processing. That's the one I'm heavily involved with.

Pushing things back a year didn't have a major effect on Omgeo. We have Gant charts at the SIA when you go to these conferences that have us being held accountable for meeting certain dates for the market to move to T+1 and our dates have not shifted despite this change.

They are really looking for us to implement CTM first globally, and that's where we have put our priority with the initial release and production targeted at global markets and then the US customisation to meet the detailed requirements of their code of practice will begin to be implemented in the first quarter of next year.

Can you talk about the migration strategy for the global customers who were using solutions from Thomson, before the creation of Omgeo with the Depositary Trust and Clearing Corp (DTCC)?

At this stage there are several main releases planned for CTM. First this one global platform, sort of like GSTPA, where you have a matching system that meets global needs and is very flexible and is not too pinned down to a given domestic market.

The first of these will be a migration-focused release. Currently we have a bridge from CTM to OASYS Global so asset managers who move to CTM can still match trades with brokers who are still using OASYS and haven't migrated up to the new system yet.

That's critical for us because otherwise our clients are going to have hesitancy to move if they don't know that all their counterparties are accessible from one entry point. This is critical for fund managers, we believe, for them to have a single gateway in.

So that bridge is in, but later this year we'll be adding bridges back to other Thomson and DTCC services and all the back-end processing which creates trade confirmations tied to DTCC settlement systems.

After building these bridges will you also be looking at drilling down into addressing the details and idiosyncrasies in the various global markets?

Absolutely. We have started that on this trip, talking to infrastructure people about their plans and local market needs. Now that we have a core commercial release it's time to turn our attention to domestic markets, not just in the US. In places like the UK, Hong Kong, Singapore and Australia we really want to do that.

For us it's not a one-time initial implementation with a maintenance budget, it's an implementation and development plan over the next couple of years to meet domestic needs and we've built CTM to feature that. It's profile driven from a market/security point of view where we can have slightly different workflows for different types of products settling in different markets. That's a big differentiator from what GSTPA are talking about. They're much more focused on cross-border and having something that meets all needs as a lowest common denominator.

We see that that is necessary as an initial implementation, but we've built CTM with domestic markets in mind. That comes from all the years of experience Thomson has with its offices worldwide. We know that one size does not fit all.

What kinds of reaction are you seeing in Asian markets to your new product and future plans?

There is a lot of interest now in Australia and Japan. The industry infrastructure people I talk to are in various degrees of planning for an institutional matching service. It's less about T+1 and more about STP for efficiency and expected volume growth.

They do have OASYS Global in all of these markets, and it has bought enormous efficiency to them, but to make the next step markets are looking at matching. Different Asian markets move at different speeds and it is unlike the US, which has a deadline and is very T+1 driven.

As far as migration strategy goes, we are going to move the current OASYS Global trade flows onto CTM, so that we are not supporting in the end, in various markets, the platform and operating system of OASYS Global. So we'll be able to cut our own costs and boost efficiency as a company while still supporting the exact same business flows, and make that transparent for the client. We're going to do that because we know Asian markets will get to this point at vastly different times.

It also means we don't have any internal vested interest to try to get markets to move faster than they are ready to. We will continue to offer our ETC-like solution, but in a more efficient environment using the latest technology.

There are going to be some markets that don't move to central matching and we are not going to abandon those markets just because they are not migrating to our new solution.

The Global Straight-through Processing Association (GSTPA) and Omgeo are competing ventures looking to automate the communication of institutional-trade information between broker/dealers, investment managers and global custodians. I know that talks are still continuing to achieve interoperability between the two systems, how are these progressing?

They started in April last year and those meeting are three-way. Representing the industry are some people from the SIA, then the team from GSTPA and then our people.

These meetings are held about every month and we have various sub-committees. We are taking it pretty seriously, but we all have an agreement whereby we won't talk about the specifics of our positions on the various issues that need to be addressed until we have a final answer. The SIA will ultimately be the one that makes that announcement.

You can draw some conclusions, that if we've been meeting so frequently since April then this is a difficult matter, but we are still talking. The focus is on the business issues and a lot of them are discussed in the initial SIA release that approved Omgeo - things like who does what match, pricing, liability and access to our legacy services.

Discussions are more about his kind of thing than standard forms for messaging. We have decided to deal with the technology once the business issues are finalised because we know the technology is there for us to be interoperable.

I notice that one major difference in the two ventures, besides different architectures and focuses on cross-border trade, is the role of custodians.

It is a bit of a different workflow. I was involved with GSTPA when it started in 1997 in my role working for a subsidiary of DTCC. There was a joint whitepaper that really looked at a distributed model of standard settlement instructions, and I think that survived into the GSTPA model we see today, whereas our model at Omgeo features a standard settlement instruction database.

What some people don't understand is that our model does feature direct involvement from the custodian very early on. When is the earliest time a custodian can know a customer is doing a trade? I think it is the time that the fund manager allocates the trade, that is after all when the broker finds out for the very first time.

Our system has a feature that does simultaneous notification of the custodian and the broker, but it also features a direct feed to the alert database of custodian settlement instructions, looking at how they settle trades in various instrument types and in various markets. They can use that link to feed from their database to synchronise, but also they can customise and validate the fund manager information pointing at them.

It's a different approach, but on both sides there are very early involvement of custodians, with them fully responsible for the settlement instructions as opposed to the investment manager.
There's a paper on this - the Just-in-Time code of practice that was issued by the ISITC-IOA group (Industry Standardization for Institutional Trade Communications - International Operations Association) and we have presented with them and with GSTPA on this issue.

I guess it's just a question of which approach custodians are comfortable with?

We have plenty of custodian instructions on our database as we speak. I like to think this is because they are comfortable with the approach we have. We're improving those services to give them much better automation and better connection to it.

I understand the principles behind the distributed approach, but I've never seen it work. It has never been tried and needs to be proven. You can see in the SIA paper that they acknowledge it is a possibility, but they don't know if it works.

They know our central database works in the United States though. The one we used traditionally for US settlement is SID, standing instruction database, that was part of the DTCC's TradeSuite product. And that enriches 30% of all US trade confirmations today. It's not a theory and it's not a prototype.