When you buy financial data, the stock/commodity/whatever exchanges that are selling the price information want to make sure that you are controlling that data, so that they can get as much money as they possibly can. Therefore, there are all kinds of tight controls on what you can do with it once you get your hands on it, so that the stock exchanges can know exactly how much to charge you for realtime price data. The Reuters/RMDS form of that is called DACS (Data Access Control System), which allows you to locally administer who in your organization is supposed to have access to what types of data, and then every month you run a report and send it to Reuters and they tell you how much you have to pay based on who was permissioned to see what types of data during the course of that month.
In contrast, the last time I worked with Bloomberg data, to change anything like that you had to go through your Bloomberg Representative, which took longer. So the fact that DACS is a local system is actually not a bad part of their design, because it means you don't have to talk to your sales guy for every small change. I mean, in theory you could hack your local database and screw those nasty exchanges, but it doesn't really seem worth it, so the exchanges trust the reports.
Now let's say you're doing a server-side transformation like calculating implied volatilities from listed equity option prices. In general, many transformations like that you want to share amongst multiple end users, because they can be expensive to perform, but you need to make sure that the user who wants the implied volatility has the rights to the underlying instruments. (In non-financial terms, if you have a server-side process calculating a function F(A, B, C), then in order to be able to get the results of F applied to A, B, and C, you need to have the rights to see A, B, and C in their raw form). This is because the end users aren't actually seeing A, B, or C, they're seeing F(A,B,C), so a server is going to listen to A, B, and C on behalf of all users, and then compute F. But this isn't a use case that exchanges are comfortable with, so you have to prove to them that you really are checking your permissions all the way through: you have to prove to them that you're checking against DACS.
DACS works in terms of Permissionable Entities (PEs for short) and Items. An Item is an individual market instrument that you want to get data on. Cisco is an Item. AT&T is an Item. An individual option on Cisco or AT&T is also an Item. There are lots and lots of items. But most of them are paid for in the same bundle (you never call up the London Stock Exchange and say "hey, I'm only interested in real time updates on Vodafone and BT, so just sell me those"). Those bundles are Permissionable Entities, and Reuters sells packages of Permissionable Entities to you.
Yes, that's all just background.
Here's the juicy fail.
OpenDACS allows you to ask "what are the PEs that user X has rights to?"
OpenDACS also allows you to ask "does user X have access to Item Y?"
(stop me if you know where this is going).
Apparently nobody at Reuters thought to hook up the two. That's right, there's no documented way to either:
- Get the PE applicable for a particular Item; or
- Get all the Items that a PE covers.
Even better, after contacting Reuters, there's no officially supported way to do this at all, documented or undocumented. Nobody ever thought that you might want to do this.
This means that what should be an M+N problem (one call per user to get his PE list; one call per Item to get the PE) has turned into an M*N problem. Given that these are remote calls, that's not great, and traders aren't going to be happy starting up in the morning to wait 15 minutes while all the items that they need are checked against the database. Which will actually happen for all users at once. What joy!
Because apparently I'm the only person in the history of the world to ever actually use any Reuters API and realize that it fundamentally Fails at its most obvious use case.
Posts
