Reuters Yields Real-Time Updates To Telerate; SOP Feed For Rich’s Triarch Used As Lever

THIS WEEK'S LEAD STORIES

After long and bitter negotiations, Telerate Systems, Inc. has begun to install simultaneous update devices--"binco boxes"--at consenting Reuters data contribution sites world-wide.

In a move which could significantly alterthe balance of powerbetween the rivalfinancial information supliers, Reuters Holdings PLC bargained away simultaneous electronic access to its contributor network in exchange for permission to handle Telrete’s SOP (standard output protocol) feed through Rich Inc.'s Triarch.

Tensions between the two companies led to a nasty squabble as Telerate said Reuters was guilty of "degradation" of Telerate data, while Reuters accused Telerate of "blatant discrimination" and "obstructive behavior."

Although an agreement in principle was reached in March, rollout of the bincos is just underway. The effect will be most dramatic in Europe, where Telerate will gain access to new contributors, as well as improve the timeliness of data currently provided in the form of sequential, rather than simultaneous, updates.

What's In A Binco?

A binco -- short for "bank in-house computer" -- sits between the contributor's input keyboard and the Reuter 600CGP contributor interface. It eavesdrops on the line and captures data insertions from Reuters contributors.

Then, using keystroke equivalence formulas, it interprets and reformats data for transmission to the Telerate network. Software development for the binco box was done by Troy Systems Ltd. of London.

Simultaneous updating is convenient for contributors because it eliminates the necessity of inputting the same information more than once. Many rejected dual updating in the past because of this inconvenience.

Reuters had long resisted Telerate's installation of dual update interfaces, claiming they pose technical difficulties for Reuters network management.

What It All Means

The deal removes one of the last barriers to direct competition between Telerate and Reuters, and Telerate's recent pre-announcement with AT&T of a foreign exchange dealing service foreshadows the toe-to-toe action likely to ensue.

The other piece of the puzzle, which has yet to fall into place, is the long-awaited General Accounting Office report. If the GAO report supports wider access to government securities prices, Reuters can then be expected to move to directly compete with Telerate for the supply of interdealer broker prices.

While many analysts have long considered Reuters and Telerate to be directly competitive, the two firms have been unable, until very recently, to address each other's primary business centers from a position of information parity.

Reuters continues to hold the high ground in foreign exchange -- especially in Europe -- and Telerate has had a wrap on the U.S. Treasury markets. If the GAO report goes Reuters's way, and ultimately translates into legislative action, the egg and yolk will be truly scrambled.

Ironically, Reuters and Telerate may have poisoned their own well, since competition on the basis of price and service rather than proprietary information franchises may eventually reduce profit margins at both firms. Of course, mutual clients will welcome such competition.

Ancient History

Both Reuters and Telerate built their empires on exclusive information franchises. Insulated from commoditization of market data by proprietary sources, the companies were slow to enter the "value added" fray.

Nonetheless, a niche emerged for the value-added handling of Telerate and Reuters data. Reuters saw the handwriting on the wall, and, saddled with a rapidly obsolescing Monitor network, scored a coup by acquiring Rich.

Telerate was slower out of the box, and by September 1986 faced the embarrassment of seeing Reuters reap profits from the value-added delivery of SOP via Triarch.

A Tough Business to Be In

For six long months last winter, Telerate made up for lost time. Even the most grizzled veterans of the financial data wars will be shocked at the acrimony and abandon with which this round was fought.

TST

has gained access to letters and memos that document the bargaining process.

At stake for Reuters/Rich were several pending Triarch installations on either side of the Atlantic screaming for access to SOP. For Telerate, controlling conditions of proprietary data distribution was the conspicuous issue. But Telerate's ulterior motive was to gain access to simultaneous updating from Reuters's network of data contributors.

Triarch: 'Frankly Diabolical'

Telerate was stung by the pre-announcement of Rich's proposed Triarch Ticker Generator -- marketed as a tool for real-time manipulation of Telerate data. Telerate's reaction to this affront was to withhold permission from Rich for use of the SOP feed in pending Triarch installations.

The occasion for this action was a certification process which required Telerate SOP users to comply with a vaguely worded technical specification entitled "Acceptable Standards For A Telerate Digital Server." During the negotiation, this document underwent periodic revisions, growing from four paragraphs in September, to twelve less than a year later.

Following a September 25th certification demo at Reuters in London, David Wilson, then Telerate product development and marketing manager, wrote to Heinrich Wenzel, Reuters client service manager, Europe, prohibiting connection of SOP to Rich's digital server.

This was followed by an internal Telerate memo dated September 29th in which Wilson says: "The core of the situation is that we currently will not interface to the Rich SOP digital server. The Rich product is frankly diabolical and we have no intention, here in Europe, of interfacing to it until they achieve a standard that is acceptable to us at Telerate."

Quid Pro Quo

Meanwhile, Telerate was seeking simultaneous updates of Eurobond price pages from Guy Butler Ltd., a London-based bond dealer. Reuters argued against installation of the binco device, claiming it couldn't adequately emulate Reuters keyboard facilities.

Instead, Reuters proposed that the Reuter network deliver updates to Telerate. This entailed a slight delay in delivery of the prices. Not surprisingly, although Butler endorsed Reuters's suggestion, it didn't sit well with Telerate.

Wilson informed then-U.K. managing director John Jessop of Butler's decision in a December 11th memo, and mentioned a pending certification test (December 19th) for Triarch's handling of SOP:

"It is my recommendation that following the trial we inform Reuters that we cannot interface our digital feed to Rich.

"There is no doubt that Reuters will put their full weight behind reversing our decision."

Wilson's recommendation that Rich fail the test fell on sympathetic ears. At the same time, someone at Telerate came up with the bright idea of a quid pro quo -- a linkage between simultaneous updating and Triarch access to SOP.

As recommended, Triarch failed the December 19th certification test due to a variety of "concerns" expressed in a December 23d letter from Wilson to Wenzel. These included the fact that the news window had only five lines instead of six, the unacceptability of flashing updates, and the absence of vertical bars.

None too pleased, Wenzel returned fire, pointing out that none of the inadequacies cited in Triarch's handling of SOP were specifically required by the technical guidelines supplied by Telerate.

Summit

This dialogue led to a Telerate-Rich-Reuters summit meeting on January 7th. Proposals and accusations flew thick and fast. Reuters agreed to remove all references to the ticker generator from Triarch marketing materials. Telerate agreed to review the SOP implementation guidelines for completeness. Reuters proposed that Telerate certify the Triarch server's handling of SOP in exchange for a written guarantee of compliance with all explicit technical specifications.

Telerate rejected this proposal and countered with the suggestion that a third-party server -- from Troy Systems Ltd. -- be used until the Triarch upgrade was complete. Reuters in turn rejected this proposal, citing the lead time required for integration of the Troy server.

Reuters approved in principle Telerate's restrictions on reprocessing SOP data, but pointed out that European systems such as FOXI and Valuta already use Telerate data for calculations.

Reuters accused Telerate of discriminating against them on the server specification issue, whereupon Telerate introduced the question of Reuters policy on simultaneous update devices. Reuters resisted Telerate's implicit linkage of simultaneous updates with Triarch's handling of the SOP feed, but the seed had been planted.

One Man’s Degradation Is Another’s Value-Added

After the January 7th summit, Rich vice president Tony Stankus requested that Telerate schedule another certification test for Triarch, citing inconvenience to mutual clients. Richard Snape, Telerate's then-product marketing vice president, replied "con brio" in a January 28th letter,

"Thank you for your letter of January 22. However, the sense of urgency that you communicate is puzzling. I would like to put this situation into perspective:

"Reuters/Rich developed the Triarch system and promised the market a number of capabilities. One of the advertised capabilities was handling Telerate's SOP. Unfortunately, Reuters/Rich failed to coordinate the development of this Triarch capability with Telerate. This failure now appears to be ill-advised.

"Not only did Reuters/Rich promise that Triarch would handle SOP effectively, but they proceeded to sell Triarch as a SOP distribution mechanism without notifying Telerate. This also appears to be an unfortunate action.

"When it came to Telerate's attention that not only was Triarch being sold as a SOP distribution mechanism, but also that Triarch degraded Telerate information, Telerate postponed SOP installations until Triarch could meet Telerate's acceptable standards. Telerate's principal concern is the welfare of its subscribers; degradation of SOP is not in our clients' best interest....

"Perhaps Reuters/Rich should consider more seriously Telerate's suggested interim solutions so that our mutual customer needs are met immediately and the development of the Triarch system can be completed in a more rational, businesslike manner."

Snape gets as good as he gives in a February 10, 1987 response from Reuters's Wenzel, who says, among other things:

"...I find your attitude to this matter, as evidenced by your letter, most unhelpful. Our companies have mutual clients and our objective should be to co-operate with each other to ensure that the requirements of those customers are met as quickly and efficiently as possible. However, rather than co-operating with Reuters and its clients, Telerate's attitude has been consistently obstructive....

"... It is totally unreasonable for Telerate to refuse to connect the SOP feed to Triarch on the ground that Triarch does not meet Telerate's 'acceptable standards' if you are not prepared to supply us with a comprehensive and definitive statement of the features you wish to be available on Triarch in sufficient detail to enable us to identify the adaptations that need to be made.

"We are aware that the Telerate SOP feed has been made available to a number of customers in the United Kingdom who are accessing Telerate through systems which do not provide the features that you are requiring of Triarch. This is blatant discrimination against Triarch. I require a clear explanation from you as to why Triarch is being treated less favorably than other system vendors...

"If, as you profess, Telerate's concern is the welfare of its subscribers, I find it hard to understand your continuing refusal to connect the SOP feed to Triarch or even carry out further tests on Triarch since your refusal is having a direct detrimental effect on your customers and potential customers.

"...I see no reason to involve our customers either in buying unnecessary additional equipment or in receiving the Telerate service in video form when there is no technical or other reason (apart from Telerate's obstructive behavior) why they should not receive the digital SOP direct on Triarch.

"Telerate's continual procrastination on this issue cannot be tolerated by Reuters or its customers."

Let's Make A Deal

This was precisely the response Telerate was looking for. By making life intolerable for Rich, Telerate created the opening it needed with Reuters for linkage of SOP/Triarch to the simultaneous update issue. In a candid internal memo dated February 17th, Snape briefs Jessop on the status of the negotiations, saying:

"We can rather easily provide R/R with the rest of the specs to provide adequate SOP distribution and display. We have up to now withheld some of this information as a lever to reach accommodation with Reuters regarding simultaneous updating."

In a letter dated February 17th, Jessop responds to Wenzel, spelling out the terms of the deal:

"I want to make it clear from the outset that Telerate wishes to cooperate with Rich Reuters fully in providing to mutual clients with a proper level of service....

"Telerate will not knowingly discriminate against Rich/Reuters or anyone else. You ask for a 'clear explanation' of an alleged discrimination. It may not have occurred to you -- but obviously has to us -- that Rich is alone among many vendors of switching systems the only one owned by a direct competitor of Telerate's. If this has made us wary in what we concede in the way of protocols, it is understandable and will be, I'm sure, to our mutual clients....

"You reject interim solutions, such as a video-based SOP or Troy front end and insist on unrestricted access to our digital feed. You don't pause for one moment, of course, to consider the implications of this to Telerate. Reuters would have complete access to our data feed. You could perform traffic analyses of inestimable marketing value to you, perform or allow to be performed various calculations on Telerate data over which we would have no control and sell applications programmes on Telerate data in competition with our products. Reuters will not, of course give Telerate access to Reuters Digital Feed. Why ask us to do what you will not?

"An additional unresolved aspect of this whole matter -- and I do regard the situation as a series of interlocking features -- is the question of dual updating.

"Just as you claim to be frustrated by our failure to provide you with needed specifications of SOP protocols, Reuters has continually stalled on providing Telerate with the ability to receive simultaneous updates from clients who wish to contribute to both systems. This ability has been developed in the MCI 807 (Binco) box. We consider this facility to be an integral part of any co-operative process between Reuters and Telerate.

"Your correspondence constantly refers to the supreme objective of meeting the requirements of our clients. We aim to please our customers too. Co-operation between Reuters and Telerate to that end cannot be a one-way street; you cannot hector us to keep making concessions while making none yourselves. We don't intend to make unreciprocated concessions and, if necessary, will tell our mutual subscribers why. We,like you, have a business to run and protect."

At this point, higher powers intervened. A February 19th meeting ensued between Telerate president Neil Hirsch, Rich president Jerome Rich, and Snape.

Jessop delivered a formal proposal to Reuters's John Lowe calling for approval of the binco box on a worldwide basis. In return, Telerate offered interim approval of Triarch/SOP installations. The deal was struck two weeks later. In a March 10th memo, Telerate's Snape says:

"Consequent to the positive response Reuters made to JJ's [John Jessop's] letter of February 19, I have approved conditional installation of SOP's at six North American Triarch sites and London has approved 5-6....

"More SOP/Triarch installations will be approved on a case-by-case basis if (1) Reuters continues to co-operate regarding simultaneous updating, and (2) Reuters/Rich satisfies SOP acceptable standards."

Who Blinked First?

In an extended game of chicken it came down to who was more willing and better positioned to endure the confusion and dissatisfaction of mutual clients waiting for their Telerate. The record shows that Telerate was more willing to make that sacrifice to achieve strategic business development goals.

Both sides have the safety hatch of "acceptable technical standards" should they choose to bail out of the deal, but at present, each has a lot to lose from breaking the truce.

Telerate comes out a winner of this round, but not smelling like a rose. Telerate released its SOP without a mature strategy for controlling and exploiting the feed. Reuters took advantage of that mistake. Reuters has introduced a data feed, but so far only public domain data is included.

Telerate has been forced to cover it's strategic retreat from the data feed business with arguments of network control and proprietary "look and feel." Why shouldn't users be free to put Telerate data into whatever applications they choose? After all, they've paid for it.

The binco bargain includes a proviso that Telerate is free to install a proprietary server between its feed and any hybrid system receiving the SOP feed. Look for Telerate to exercise this option soon.

Only users who have a paid subscription or are part of a corporate subscription are able to print or copy content.

To access these options, along with all other subscription benefits, please contact info@waterstechnology.com or view our subscription options here: http://subscriptions.waterstechnology.com/subscribe

You are currently unable to copy this content. Please contact info@waterstechnology.com to find out more.

‘Feature, not a bug’: Bloomberg makes the case for Figi

Bloomberg created the Figi identifier, but ceded all its rights to the Object Management Group 10 years ago. Here, Bloomberg’s Richard Robinson and Steve Meizanis write to dispel what they believe to be misconceptions about Figi and the FDTA.

Where have all the exchange platform providers gone?

The IMD Wrap: Running an exchange is a profitable business. The margins on market data sales alone can be staggering. And since every exchange needs a reliable and efficient exchange technology stack, Max asks why more vendors aren’t diving into this space.

Most read articles loading...

You need to sign in to use this feature. If you don’t have a WatersTechnology account, please register for a trial.

Sign in
You are currently on corporate access.

To use this feature you will need an individual account. If you have one already please sign in.

Sign in.

Alternatively you can request an individual account here