Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

FIBV Data Vending Workshop Presentation

by Zorro29 on Jul 05, 2010

147 views

More…

Less

Statistics

Favorites: 0
Downloads: 1
Comments: 0
Embed Views: 0
Views on SlideShare: 147
Total Views: 147

I’m very grateful for the invitation to be part of this workshop and would like to extend my thanks to Peter Clifford and Tom Krantz as well as to our hosts from the Taiwan Stock Exchange for including us on the agenda
I hope you’ll bear with me for just two slides as I set up our organization and set some of the context for our views on market data. FISD is a division of the Software and Information Industry Association located in Washington DC. SIIA is a trade association representing both content and software publishers. We have over 1100 members globally. FISD is somewhat unique within SIIA and within associations in general in that we don’t represent anyone. We are in fact a neutral business forum for all segments of the market data industry -- information providers, information vendors and information users. Members use FISD to build business relationships and address industry-wide issues associated with the worldwide flow of financial data. The key point about FISD is that the participants are responsible for their own strategic and commercial self-interests. Our role is to act as a neutral facilitator for the discussion and manager of the consensus agenda that emerges as a result. In many ways our role is to act as the global marriage counselor for the market data industry Our agenda is organized around two broad area. 1) Market data business management issues related to market data contracts, billing, administration, and market data business policies -- things like redistribution, data usage, unit of count, and business process automation. 2) Market data quality issues including data format standards, security identification standards, price type definitions and straight through processing. We also act as a spokesperson for the market data industry and act as a resource to the US regulators.
FISD is governed by an Executive Committee of 27 entities. We have an equal number of exchanges, vendors and users on the Executive Committee. This is the group that sets the FISD agenda and is the group that I report to. I’ve handed out a one page document outlining our major project areas and would be more than happy to answer any questions you have about FISD. I have to admit that I’m particularly pleased that this meeting is in Taiwan because almost without exception our members believe the voice of the Asian exchanges are not well enough represented in our forum. And everyone believes that the Asian markets are way too important not to be included in these discussions.
For this session I’m going to give you a general overview of what’s going on. Alan Ku from Reuters is going to give you a strategic perspective on XML and I’m going to give you an update on MDDL -- which is our XML standard for market data. So what’s going on? What we are seeing is no less that the creation of a new business landscape being driven by globalization and technology on the one hand and regulation and the requirements of transparency on the other. Over the past year we’ve seen a number of exchanges including the likes of DBAG, LIFFE, Nasdaq and the LSE transform themselves from traditional exchanges run on behalf of their members to profit-driven organizations subject to the requirements of their shareholders. I believe further integration is likely. The underlying question is what’s behind these trends. And I believe the answer is globalization, transparency and efficiency. In fact, I think we can be bold enough to conclude that we are in the midst of a new age -- one that I’ll term the age of efficiency. And the age of efficiency will be driven by standards. Standards are the infrastructure for the next generation of the financial information industry. Standards are the underpinnings of straight through processing, the key to business process automation and the building blocks of data distribution. It's no secret that all parts of the financial information industry are moving toward automation. The goals are cost mitigation, economies of scale and the use of technology for better risk management. Today's financial markets are challenged by the necessity to streamline the trade processing, execution and settlement cycles. T+1, cross-border trading and inter-market linkages are a reality. Market data departments are looking for every opportunity to simplify administration and rationalize data usage. In a nutshell, the whole industry is grappling with the full spectrum of business process changes required for thriving in the age of efficiency -- and standards are one of the critical keys.
So let’s take a look at some of these critical trends from a market data perspective. The first is STP which can be defined as the continuous flow of a transaction from trade inception to settlement without re-entry into transaction processing systems. Without exception, firms are in the midst of technology planning cycles for STP. The principal drivers are the growth in cross-border trading volumes, the regulatory requirements for T+1 and the need to lower costs. These changing market conditions now require a fast, efficient and automated way to process transactions. And from a market data perspective, the ability to accurately and precisely identify global securities -- meaning symbology in automated environments -- has now become essential. Much of the symbology problem boils down to the simple reality that financial instruments can be issued, priced, traded and settled in many ways. Combine that with the fact that different types of identifiers are relevant at various levels. And multiply it by the introduction of new exchanges, ATS/ECN and you have a situation where a single security can be registered and traded in more than one place with linkages occurring in many locations. That means the industry has to deal with pricing, valuation and currency variations for a single instrument trading multiple locations. From our perspective, the goal is to help the industry meet its objectives of automation, cost-mitigation and reduction of failed trades. From the exchange perspective I believe it is essential for you to recognize that you are the source of a lot of this information and to begin to think about the creation of linkages between instruments and corporate action information, the logic of symbol construction and the creation of standards for how it gets communicated and processed in global trading environments. Perhaps FIBV could play a role in getting the exchanges to agree on a uniform exchange symbology. All of these steps would help the industry meet the new requirements of automated cross-border processing. I’m going to talk a bit more about symbology and unique security identification tomorrow.
The second critical area relates to the data itself. I lump it all under the label of data quality, but its really relates to five things The first is the format of the data and the desire of the industry to re-deploy scarce resources from issues relating to managing multiple formats and toward issues relating to data applications. In my opinion, that what XML is about in general and what MDDL is about in specific. More about that in a moment. The second is about data volumes and capacity. This is a big issue for vendors and user firms -- particularly in the US options market. Both are investing heavily in upgrading communications lines, increasing distribution bandwidth and upgrading internal processing capabilities to make sure they can meet global projections. The key point is that there is a lot of “less than useful” data being disseminated which carries a big cost in terms of data collection, processing and distribution. The keys to addressing the capacity issue is threefold. 1) Communicate with your vendors on capacity projections. 2) Implement more aggressive quote mitigation strategies. 3) Prioritize your data dissemination. Vendors will process everything the exchange throws at them. That’s their job. But perhaps it’s not necessary to throw it at them all at once The third area relates to your feeds. Consistency and accuracy of the data flags will go a long way toward helping ensure the accurate processing of the data. The problem is that not all feeds identify important trading information the same way. Information about cancellations, corrections, trading halts and other status flags are critical and need to be accurate and understandable to vendors. Fourth is about price type transparency. This is what Herbie Skeete will refer to tomorrow as data taxonomy. A concept that I believe is very important for everyone in the MD industry in our new age of automation and fully one half of the function of MDDL. We’re talking about the development of a global MD glossary to provide both the common links among data and to promote complete data content transparency. I will talk more about this tomorrow. Finally, and perhaps most obviously, is to ensure that networks are upgraded and reliable. Get rid of legacy systems. Upgrade to IP multicast protocols. More data is coming down the pipes and the pipes must be able to handle it.
Market data administration is a costly and inefficient problem for everyone in the industry. In recent months there has been an aggressive and sustained discussion within FISD on the concept of business process automation or -- to put it another way -- the straight through processing of administration. It’s a big and important concept covering billing, reporting, invoice reconciliation, inventory management, permissioning and entitlements -- across multiple systems and among multiple segments of the industry.. This is nothing less than a global call for efficiency through electronic commerce designed to reduce the costs of market data administration. The good news is that this is the classic win/win for everyone in the business because there are lots of systemic inefficiencies that can be improved There are over 85 fee-liable exchanges and dozens of third party services that make up the market data inventories of vendors and user firms. And there are lots of policies and variations on policies that need to be understood and applied by organizations in the MD redistribution business. Lets face it, administration is part of the job -- and a confusing job it is. Not only do you have to comply with multiple policies from hundreds of sources, but you have to apply old contractual requirements to new real-world circumstances -- and do so for situations that were neither know or anticipated when the market data policies were created. Tomorrow I’m going to talk about four things. 1) Bringing contracts up to date. 2) Creating market data business policies that are clear, business friendly and consistent with technological reality. 3) Simplification of administrative processes. 4) And the creation of product, customer and billing data element standards that are required for administrative automation. Again, in the age of efficiency, the mantra is simplify, standardize and automate business processes.
I’m going to divide this discussion into two parts. Today I’ll give you the strategic overview of Market Data Definition Language (MDDL) -- otherwise known as MIDDLE if we do it right or MUDDLE if we screw it up. MDDL is on the fast track within FISD. It started as a request by the big banks. It was supported by the vendors (as evidenced by Alan’s presentation). And it has implications to every entity in the industry including exchanges. To give you some illustration of the pace of this activity, I’d never even heard about XML until last year and now we’ve just released Version 1.0 of XML for market data.
OK. So what is MDDL? In a nutshell, it’s a generic XML-based interchange format as well as a common data dictionary to describe everything distributed in market data feeds. Of course, the first challenge we had to overcome was to answer the question of what is market data. And we had to look at that question in the context of all the other XML initiatives taking place within the financial industry After much debate, MDDL is designed to define financial instruments (including those not traded on exchanges), corporate events affecting value and tradability and market related, economic and industrial indicators. It’s mission is twofold. The first is to promote data interoperability and to allow the industry to shift its focus from low value-added and costly functions of normalizing multiple data formats to higher value-added functions of data applications. The second is to develop a standard data glossary including agreed terminology and transparent definitions so that the people working with data delivered by multiple sources could understand what they are working with and use it as is appropriate for their specific applications. So please remember, we’re not talking about standardizing the business practices of exchanges, rather we’re only talking about standardizing formats and definitions. The initial application of MDDL is for end-of-day and snapshot applications (because XML is a data hog) but it has been designed to be simple and extensible into both streaming applications and for proprietary data applications
As I stated, MDDL was initiated on request of the banks and brokerage firms. And it was clear why a common format standard would be beneficial to users. However, FISD is a neutral business forum and I was concerned about the acceptability of a data standard to vendors. Let’s be honest. Market data vendors have spent decades building their businesses around proprietary data formats. And in the past there was quite a bit of resistance to industry efforts to standardize symbology. So what’s different now? Not be overly simplistic, I believe there are three core reasons why vendors are supporting XML and MDDL First is that the users are demanding open formats. The era of automation and efficiency is firmly rooted in the strategies of the firms. And vendors pay attention to user requirements. So the first reason is that vendors would rather be in front of the XML train, rather than get run over by it as it travels to their competitors Second is to enhance the functionality of their products. XML is a very useful technology and a big leap over HTML in that it allows for the definition of the content to be tagged and communicated. As you can see from the approach of Reuters, XML allows vendors to link data across various parts of their organization and outside organizations to deliver a centric view of the world to meet the specialized needs of their customers. And finally, XML is the message format for STP. And since the world is rapidly moving toward automated trade execution, it makes sense that vendors would adopt standards that make this easier. But let’s not oversimplify this issue. XML is the technology du jour but not firmly established. Standardization is a double-edged sword. You’re in trouble if you miss the standards boat, while at the same time standardization is a direct challenge to long-standing concepts of competitive advantage. To be honest, it’s too early to tell at this stage what the future is for XML.
Let’s take a closer look at the demand drivers for MDDL. From the user firm perspective, the principle goal is to make it easier and more cost effective to be able to integrate and normalize data delivered from multiple sources -- vendor, third parties, direct from exchanges -- and make it easier for the development of web-based display applications. User spend a lot of time and money mapping data to internal applications. So for users, it’s really about cost savings and reduction in the need for specialized programming to “work with” the data. Here’s an example of the double edge. On the one hand MDDL will make it easier for users to shift between vendors. On the other it will significantly reduce the cost of adding new data sources. One of the net impacts is that market data delivery becomes more of a commodity. From the vendor and data provider perspective, MDDL promotes data linkages by allowing for the creation of relationships between internal and external data. MDDL also allows for data transparency at a very granular level. It allows providers and vendors to describe the data and allows the users to select the specific data they need for their particular application. As such, it’s a powerful technology for product enhancement and a useful tool for mass customization of data. This is what people refer to as the “meta data” component of XML. Compared to other mark-up languages, MDDL allows for “content” tagging as well as “format” tagging. So another of the net impacts is to promote data transparency and to provide a tool for added value. XML is also the messaging standard for STP. Vendors and user firms that publish in XML and adopt the other industry standards including ISO 15022 data dictionary, business entity identifiers and ISIN will find it easier to work in GSTP trading environments.
To prepare for this meeting I went back through our MDDL working documents to identify the functional business requirements of the banks for MDDL. In summary form this is the business rationale and the minimum specification for development of the standard. In order to be useful, MDDL must Support multiple vendors (that’s fairly obvious) It must be able to provide a common interface among vendors It needs to allow for a common request format using any number of identification requirements -- ISIN, proprietary symbology, ticker symbol and instrument type MDDL needs to be extensible and accommodate vendor and exchange specific fields MDDL needs to be able to support entitlement and permissioning requirements. It needs to standardize data field names and normalize field names across multiple data sources It needs to provide a mechanism for validation and data quality It needs to support the automation requirements of STP And it needs to provide a common request/response interface for retrieving the data Tomorrow I’ll get a bit more into the structure of MDDL and give you a sense of where we are with the development of the taxonomy structure for market data.
For the past year, I have had the distinct honor and pleasure of being a participant on the U.S. Securities and Exchange Commission’s Market Data Advisory Committee. In addition to being great drama, this debate is serious and important. It’s about some fundamental issues -- not the least of which is the definition of transparency, the concepts of data ownership, the notion of the exchanges role in information competition and even some of the basic structural elements of the U.S. financial information industry. I’m going to give you an update on what’s happening in the States. I’m not entirely clear how much of what happens in our market is relevant to the rest of the world -- and I would be grateful for your thoughts as we work our way through this issue.
So what is going on? Here’s the background in a nutshell. In many ways this whole situation grew out of the rise of Internet trading and the gap between exchange policies for professional users and the requests by Internet brokers for adjustments to business policy. For many years Schwab (the largest Internet broker) and others including Fidelity and e-Trade lobbied the US equity exchanges to adjust their data usage rules and payment policies. And that created tension between the exchanges and the Internet brokers. Finally, Schwab wrote a request for ruling to the SEC accusing the exchange of discrimination and violating the terms of the 1975 Exchange Act amendments. The SEC had to respond. They spent a year creating a concept release on the issue. That release was sent to the industry for comment. There were lots of comments from all sides. The result was the creation of the SEC Advisory Committee which included 25 members from all sides of the industry -- exchange, broker/dealers, vendors and others. FISD was one of the others. At the same time, the US Congress was engaging into a debate on database protection. In essence this debate was the result of a Supreme Court decision known as the Feist case -- where Feist publishing copied the phone company white pages and was sued by the phone company. The Court ruled that the White pages were only a collection of facts and even if difficult to collect -- not subject to copyright protection. So facts are not subject to copyright and “sweat of the brow” protection is eliminated. This created a huge stir among the database industry in that many databases are simply a collection of facts. Is it now free reign to steal database compilations? The database industry -- including the exchanges -- are strongly lobbying Congress for database protection legislation to give them protection. This is quite a story in itself, but we’ll leave that for another time. However, it is an active question and the subject of many government inquiries -- including one by the powerful House Financial Services Subcommittee. Combine this with the other things that were going on including -- the request by the NYSE to withdraw from the CTA, the rise of for-profit exchanges, the continued growth of online trading and the capacity issues associated with decimalization in the US. The capacity question is about its impact on the value of the NBBO. The game has been joined.
Let me spend just a minute on the US market structure because it’s important in order to fully understand the issues at stake in the debate. The US has a central market system that was created in 1975 when Congress enacted the Securities Act Amendments of 1975. That Act directed the SEC to create a NMS to maintain stable and orderly markets and to centralize buying/selling interests for best execution Section 11A of that Act created the NMS in place today. There are three rules contained within that Section that are the subject of the debate. The first is the Transactions reporting rule that required the exchanges to file a transactions reporting plan for securities traded on its market. That rule required the consolidation of feeds and established SIAC and UTP as securities information processors. It also set up the requirement for best execution and was needed to ensure that retail investors got the same price as institutional investors. So this was created because broker/dealers were bad The second is the quote rule requiring the exchanges to make bids, offers and quote sizes available to vendors. Before 1975, exchanges determined who would or could not get access to market data. So this was created because exchanges were bad. The third is the display rule requiring vendors and broker/dealers to provide consolidated display of information (either the NBBO or a quote montage). Before that vendors decided which information to include in their displays. So this was created because vendors were bad. These are the regulatory subject of the debate. Here are the other factors at work.
Alright with that as background let me jump right in to the issues under debate. The first core issue is the definition of transparency. What is a transparent market? how is it achieved in the market? Is the current level of transparency sufficient? What information is required to ensure transparency? The second is about the importance of providing a consolidated data feed. It was created in a different technological environment. Is it still necessary? If so, is the current structure of a single consolidator still valid or should you open it up to competition? Then there is the issue of the cost of market data. Is the current fee setting structure appropriate? Are current fee levels discriminatory? Is the revenue sharing structure of the Plans appropriate? The issue of data access is really about two things. What data is made available. Just the NBBO or more enhanced data? Do the exchanges have a right to make money on “non-core” data? And just what is the definition of non-core? The other question is about exchange market data policies and the business models of the exchanges? Are they fair? And just who should set the business policies -- the exchanges or the SEC? Underlying all this discussion is the core issue of data ownership. Who really owns this data anyway? The brokers who generate orders? The public? Are the exchanges the creator or just the collector of market data? And finally, the capacity issue. This is important on two fronts. Has decimalization and growing quote traffic reduced the value of the NBBO. And what about the options industry. They generate 80% of traffic and are clogging up the pipes for everyone
The question of transparency and the market data required for transparent markets is -- in my opinion -- the most important question being debated. Price transparency is a cornerstone of the US NMS and facilitates best execution of orders, promotes investor protection and mitigates fragmentation of buying and selling interests among different market centers. In the US, the NBBO (best quotation and last sale with volume and market identification) is the most basic form. For the US markets this is fundamental and at the end of the data everyone supports the concept of a fully transparent market. But, does the existing system achieve the appropriate levels of transparency? Particularly since decimalization has increased the number of price increments and reduced the depth of trading at each price level. Because of that most believe the NBBO is less meaningful and they want the SEC to mandate the full depth of book. They also want to see quote competition, so that markets have incentive to generate useful data. In the states this is about consolidated market data and the display rule. Most believe that having a consolidated quote is important. Much to the dismay of some, the AC is recommending that the display rule -- which mandates that data from all markets needs to be included in market data displays -- be retained. This is good for the exchanges (particularly those that are not the primary market) in that it guarantees revenue. It’s not so good for vendors who want flexibility to package data to meet the various needs of their customers or for users who have to pay for “less than useful” data. The AC is also going to recommend that exchanges be allowed to sell their data independently and that they be allowed to distribute additional market data. Another victory for the exchanges and another revenue stream on non-core data (full depth of book, aggregation of orders at various size benchmarks other data elements). There is still an open question on whether this non-core data will be mandatory or optional
The issue of consolidation is about the means of consolidation (who does it) rather than should we have a consolidated quote. Just to set the stage, the concept of a central processor was developed in the 70’s as the most practical and reliable way(at the time) to generate a consolidated stream of data. The question before us now is -- does the model continue to make sense. We spent a lot of time on this issue. My interpretaion of the discussion was that most support the idea of competing consolidators IF the SEC eliminates the display rule and allows for free market information competition. We don’t support competing consolidators if we retain the display rule. In essence the current system works well and is very cost-effective. It’s only worth changing if we are adjusting the information requirements. However, the final report will say that we should retain the display rule and move to competing consolidators. Go figure. The net result (if this is implemented) is that the price of market data will rise because now you have to pay for multiple competing consolidators and we open ourselves up to price differences and problems with sequencing, validation, formats. To be fair, the thought is that market forces will mitigate most of the risks and that competition will push the system toward efficiency. The subject of market data business policy and administration was the subject of a lot of passionate debate. The net conclusion was -- market data business management issues are complicated and the existing administrative infrastructure is inefficient. The final report encourages the SEC to mandate transparency of fees, contractual terms, and business requirements. In fact there is even talk of making the FISD market data policy database an official repository in the US. Outside of that, the conclusion is that business process automation is a good thing. Simplicity and uniformity are a good thing. Business friendly business policies are a good thing. And get on with it! And if the industry can’t work cooperatively to address these issues, the government will have to step in. On the market data business policy front, I think it’s fair to say that the US markets are -- under scrutiny and -- on notice.
It’s very interesting that the one of the critical drivers behind this entire discussion was fees. Users say they are too high. Exchanges say they are not. The AC spent a lot of time talking about how fees are set and the role of the SEC in fee review. There was discussion about whether the distinctions between professional and non-professional subscribers were appropriate. At the end of the day -- the report will recommend (much to the relief of the exchanges) no change to either the statutory standard -- which is “fair, reasonable and not unreasonably discriminatory” -- or the role of the SEC in fee oversight. The big debate however is on revenue sharing among the exchanges. The NYSE wants to withdraw from CTA. The reason is that they don’t want to share market data revenues with other exchanges that (in their words) don’t add value to price transparency. And they make a good case. It’s unclear whether the SEC will allow NYSE to withdraw. There are two likely impacts if they do. First is the fact that all the exchanges would set their own fees, manage their own contracts and manage their own administration. It would increase the burden on redistributors, but would enable market forces to work by rewarding more efficient markets. This is clearly good for the primary markets. The second impact could be to force the regional exchanges out of business. In many ways they aren’t adding much value to the price transparency process. And they generate a lot of useless auto-quotes in order to get a bigger share of market data revenues. The other big question is about capacity and the impact of decimalization on quote traffic. The US options markets are the big problem. They generate over 80% of the quotes and they distribute a lot of quotes that are of no interest to anyone. The outcome of the debate will be to recommend that an official NBBO be calculated by OPRA with size and market identification. In addition, there are a number of quote mitigation strategies under consideration
The issue of data ownership is -- in many ways -- at the core of this debate. Of course, I’ve been involved in market data for 15 years and the question of data ownership has been at the center of the market data debate since I started -- and I’m not sure if it will advance much as a result of this debate. Competition, display rule and regulatory structure that inhibits competition -- (insert info from House testimonies) And it was not part of the discussion at the AC. What did emerge out of the AC was to reaffirm that the exchanges have the right to charge for market data. And since the display rule is in place -- in effect mandating that data from all market centers in included in the NBBO -- I’m not sure I fully understand the outcome of the debate over data ownership. And besides market data is governed by contracts anyway. Redistributors have to sign the contract to get the data. And if you sign the contract, you are obliged to comply with its terms and conditions. Nevertheless. The issue of data ownership continues to be a hot subject. As I mentioned earlier, it’s be waged under the guise of database protection legislation. Just to refresh your understanding. We are having a global database protection discussion to provide data owners with some degree of protection for data NOT covered by copyright. And in the US the Supreme Court set the standard with its decision in the Feist case -- that facts aren’t subject to copyright and -- effort in producing content (the so-called “sweat of the brow” doctrine) is not sufficient to protect intellectual property. So from a market data perspective, this is a debate about whether prices are “facts” and whether the exchange is the creator or just the collector of market data I would suggest however that this debate is just getting started. These are just the opening rounds of what will likely be a long battle.
I feel somewhat like the John the Baptist -- ushering in the age of efficiency and preaching the coming of standards. However, from my vantage point, the time looks right and the momentum seems to be building within the industry. Beyond that, during this presentation I will talk about (and I have to admit that I stole this concept from Herbie) the data taxonomy component of MDDL. I’m also going to talk about the information requirements for Straight Through Processing Then, if you’ll bear with me I’ll shift gears and talk about market data business policy and one of my new favorite subjects -- billing automation.
Let me summarize the points I made yesterday by saying that the new mantra for the global market data industry in the age of efficiency is simplify, standardize, automate. And standards are good for business. STP standards will help reduce the cost of trade processing, help manage risk (because nothing good can happen between trade and settlement -- only bad things can happen), help reduce trade failures and lower the costs of transactions. Data distribution standards make it easier and cheaper to integrate data into applications. Mapping data is expensive and not very valuable in a competitive sense. Billing and reporting standards as well as standardization (to the degree possible) in terms of market data policies -- will reduce the costs of administration and lead to better data management. I think this a fairly compelling case. The only question is whether we have the vision and collective will to work cooperatively to develop and implement these standards. In the short run, there will be some competitive obstacles and some business casualties. So will the industry seize the opportunity? I’d be interested in your thoughts.
As I said yesterday, every firm is in the midst of getting their technological infrastructure, internal processes and data sources in place for STP. STP is a big concept and will not happen overnight. However, STP is being driven by four core factors. The regulatory stipulations of T+1 in the US and elsewhere, growth in cross-border trading volumes, increasingly complex investment strategies, and of course, the need to lower costs through productivity gains. The market data message behind all four has consistently been the same. Changing market conditions require a fast, efficient and automated way to process transactions from point-of-trade to point-of-settlement
From a market data perspective, accurate and timely security identification is one the the critical keys to STP. In other words, the ability to precisely identify global securities in automated environments has now become essential. STP emphasizes the security identification problem because the front-office identifies securities by symbol while the back office identifies securities by number (ISIN or NSIN such as CUSIP). Part of the problem is that primary identifiers are not always available when trades are consummated and international secondary market identifiers are sometimes difficult to obtain. Incompatible databases and the lack of data standards are a primary cause of high error rates, product valuation errors, costly/manual exception-based processing, trades of the wrong security and the high rate of expensive trade failures. Our discussions indicate that well over 45% of information manager’s time is spent on quality assurance and database reconciliation. Everything from legacy systems to data silos, and from dealing with multiple vendors to significant latency gaps. All of which are exacerbated by the lack of a universal identifier and the maintenance issues associated with corporate action processing. SWIFT estimates that 59% of instructions need repair and manual intervention -- at a cost of $6/repair. There is a 10% mismatch between confirms and statements at a cost of $16 per mismatch. And that 15% fail to settle on time at a cost of $50 to resolve the settlement failure. And that on average, the cost of a manual repair of transactions is over $15. And don’t forget, this is before T+1 and STP. Automation requires procession
FISD’s role in STP has focused on security and business entity identification. Because no matter how you slice it, unique security identification is at the heart of STP automation. The first part of this discussion is about ISIN numbers -- as the basis of security identification. And there are a lot of problems with ISIN -- that can roughly be organized into two buckets. The first is the data issues of assignment, uniqueness and maintenance to make the number as functional as possible. The second is the commercial issues associated with access and usability. If you’ve been tracking the developments in this area, you might be aware of the creation of the ANNA Service Bureau and the efforts to improve the accuracy and maintenance issues associated with ISIN. This is good news and positive things are happening with the creation of the ASB. Unfortunately, ISIN is not an ideal solution for STP. It doesn’t include all the descriptive data needed to clear and settle, it doesn’t identify market or currency. It doesn’t cover all instruments including options, derivatives and fixed income. ISINs change based on corporate action. It’s not widely implemented in the SU. It’s an issue identifier, not an instrument identifier which creates problems for multiple listings and there are latency gaps in the links between various identifiers. That’s a lot of problems and the question of whether ISIN survives STP is a real one. On request of our members, FISD did some research on the requirements for unique identification. And to make a long and complicated story short -- ISIN alone is not sufficient for identification. It can be shared among separate issuances of a single security in multiple locations. What is needed is the ISIN and the place of official listing -- needed to differentiate the security in the case of multiple listings. Other identifiers are also required including a register level identifier for security routing and place of trade for due diligence, market compliance and trade execution problems. This is an ongoing debate and the outcome is still unclear. We’ve been in constant dialogue with ANNA and we’re scheduled to meet again next week on this issue of unique security identification. In some cases, the stock exchanges, not the numbering agencies, are the sources of the data that’s required. Back office processing has not traditionally been the business of the exchange -- however with STP and with the integration between exchanges and clearing, I suspect this issue will become a very important part of your coming agenda
I’m not going to spend a lot of time on the technical structure of MDDL other than to give you a sense of what’s going on. And while it’s too early to predict the end of proprietary data formats, the direction of the discussion does seem to point us in that direction. The bottom line is that these standards are useful, perhaps too useful to ignore. Standard data formats make it easier to move data between applications. Standard data definitions make it possible to create data linkages and enhance product functionality. So whether XML is the technology du jour or whether it is the next big thing for the financial industry is still an open question. I will point out that there are a lot of XML related initiatives underway in the financial industry -- including those for news, business research, trade processing as well as market data.
That being said, let me give you a sense of what MDDL does. On the vocabulary side -- we’re creating a common data glossary -- or taxonomy (as Herbie calls it) -- for market data. We have organized financial instruments into five broad categories -- equities, collective investment vehicles (including funds, annuities and trusts), debt instruments (including bonds, notes, CDs, commercial paper, and the like), contacts (including futures, options, rights, swaps, warrants) and units (meaning two or more instruments from any specific domain) Indicators includes things like indexes, financial indicators, exchange statistics, ratings and economic indicators) And corporate actions including notifications, descriptive data and fundamental information) These are collectively known as the MDDL domains.
Within each of those domains, MDDL has something called descriptors or the things that you need to know about each of the instruments types. We’ve organized the world into 14 descriptor categories including Instrument identification (including ticker symbols and numbering systems); Valuations (including price types, quantities, amounts and fiscal data); Measures (including rates, yields and volatility measures); Dates and Times (organized into defined, functional, and periods); Currency; Locations (such as market and country; holdings; Loads: Asset Classes, source; Status (for both markets and instruments), Indicators; and Features of the security. Taken together, the domains and descriptors make up the taxonomy of market data. This taxonomy is now ready for global review and adjustment. It’s important for all segments of the industry to be involved in this review and we encourage the exchanges to be represented in these discussions. In many ways, it’s your data that’s being standardized. It’s your feeds that are being normalized. And if exchanges are also becoming vendors and clearing entities, it will be your content that gets mapped to these applications. The MDDL vocabulary is posted on the FISD web site for those of you who want to get up to speed on the status of this discussion.
Just a short word on the technical structure of MDDL. We’re designing the standard to be extensible for both proprietary content and for streaming applications MDDL is flexible with only a minimal amount of defined structure The standard supports both XML schema and DTD We’ve taken an element approach to developing the architecture We are working with other standards bodies and other XML initiatives by using the concept of reference lists and namespace And finally MDDL uses an inheritance concept to make it as streamlined as possible. The key elements of the MDDL technical architecture has been crafted into a design paper that’s also posted on our site for your developers to use as reference
So where are we? Version 1.0 dealing with global equities, mutual funds and indices is now available in beta. We are planning on releasing the final version of 1.0 at the FISD World Financial Information Conference in London at the beginning of November. So we have between now and then for global review For those who want more information, please check out the MDDL web site at this address. If you want to be added to the MDDL distribution list, please give me your card or send me an e-mail and we’ll make sure you’re plugged in.
I’d like to spend the remainder of my time talking about the business management side of market data -- market data policies, contracts, billing/reporting requirements and administration. Over the past decade, the MD distribution environment has changed dramatically. In my opinion, we’re experienced at least three distribution revolutions -- stand-alone terminals, data feed delivery and Internet/Intranet distribution. Wireless communication will add a whole new dimension to the business challenges of market data management. Part of the problem with market data management is that business policies have not always kept pace with the changes in technology. It’s FISD’s opinion that MD management is a global business issue and needs to be managed as such. There are over 85 fee-liable exchanges around the world and dozens of other data sources (news, commentary analytics and corporate events). The industry’s ability to manage MD is compounded by both the complexities of administration and the lack of consistency among the exchanges and information providers. In this regard, all of FISD members are in agreement. The objective is to reduce paper, standardize and simplify contract administration, adopt new technologies into administrative systems and reduce the barriers to product innovation.
The market data contract is the principal document governing what vendors, redistributors and subscribers can and can’t do with the data. Everything starts with the contract and once it’s signed, parties are obligated to comply with the terms. FISD members have developed, published and continue to evolve an Exchange Contract Guide to help support the contract development and negotiation process among exchanges, vendors and client firms. This is a free resource posted on the FISD web site and maintained by our members. We’ve also agreed to a number of best practice recommendations including ones on lead time notification cycles, system descriptions, units of count, and audit procedures We’ve organized our contractual issues into twelve categories including -- determination of what’s covered by the contract, the technical specifications, the types of agreements that are required and who’s responsible for executing the agreement, rights and restrictions on data usage, system descriptions, fees and unit of counts, billing and reporting requirements, audits and other policies an restrictions such as policies on Internet redistribution
As I’m sure all of you know, contracts are often somewhat vague and subject to interpretation. Understanding and translating the complex policies of multiple exchanges is not a simple process. In particular Contracts are legal documents and don’t spell out how the rules are to be implemented or how to address the variety of real life situations encountered by vendors and client firms Contract are complex documents and have multi-year life spans and don’t always address evolving technologies or creative new application environments Compliance with policies often involves many organizations and many people -- entitlements, billing, reporting, IT/development and sales -- who all need to understand the practical side of market data rules. And of course there is global variations among all the various players Understanding the myriad of rules and their application -- particularly as it relates to redistribution and data usage is an extremely difficult thing to do. And that’s why we developed the …
Our market data policy database. Another free resource posted on our web site. The goal of the database is to define, clarify and publish all the obligations and requirements covered by exchange contracts. The objective is to ensure that all vendors, redistributors and end-users understand and have consistent interpretations of the policy and contractual requirements on a global basis. The database is also a useful reference tool for exchanges looking to develop new policies, update their contracts and for users looking to evaluate the business considerations they need to understand for specific applications The database contains policy statements from about 40 exchanges. It also contains fee schedules for about 75 exchanges. Our goal is to get the policies of all exchanges into the database and we encourage you to work with us to make sure your policies are included.
I pulled out seven business management issues that I thought were particularly important for exchange consideration -- all of which are covered in the ECG and MDPP In a broad sense there are two types of business models being used by exchanges. Vendor discretion gives a license to the vendor to redistribute data without pre-approval but subject to the terms of the exchange contract. The second starts with the premise that no one is allowed to to anything with the data until it is approved by the exchange. Most of the world uses the first model. Most of the US equity exchanges use the second. I’m not in the business of telling exchanges how to do their business, but I will note that the first model is much easier to administer and allows for more flexibility to respond to changing conditions Associated with that is user classification used to determine the rights to use market data and the fees. This is where distinctions are made between professional and non-professional subscribers. There are also important distinctions between vendors, sub-vendors and subscribers as well as distinctions between internal and external redistribution Unit of count refers to how market data is counted and priced as well as how the unit is to be applied in contracts. There is an ongoing debate in the industry on who and what gets counted. Units can be device-based, user-based, location based or identification based. There are unit of count policies for single users, common areas, shared terminals and users with multiple terminals. One of the problems with global administration is that the unit of count is not consistent within the industry. Inconsistent units of count complicate billing reconciliation
Billing and reporting means different things to different groups within the industry. For users it’s about invoice reconciliation and managing their market data inventory. For exchanges it’s about getting compensated for their data. Vendors are in the middle acting as the billing agent for the exchange and reconciliation agent for the user firm. Billing is an area crying out for standardization and automation and a classic win/win for everyone Subscriber agreements are the method used to control the use of data and determine responsibility for compliance with exchange requirements. The debate is about the need for these agreements as well as with their form and content. Another area for uniformity. Finally, are usage policies for derived and delayed data. As we heard earlier it is important to have policies that clarify the extent to which vendors and users are licensed to create or derive their own intellectual property from exchange market data for indices, graphs or historical analyses -- and on the extent to which derived data is subject to market data fees and reporting requirements.
Let me close with business process automation -- an appealing concept that should probably be described as the straight through processing of market data administration. The good news is that this concept has broad support among all segments of the industry all over the FISD membership. I believe there are three core goals of this activity The first is the importance of standards on what’s required to be captured on invoices and in inventory systems for billing and reconciliation. These standards are the basic infrastructure for billing automation and the first place to start. The second relates to process simplification and includes things such as flexible reporting dates, uniform approaches to pro-ration, simplification of reporting requirements and moving from transaction-based reporting to snap-shot reporting The third is about data consistency and the problems that occur because the users inventory doesn’t match the vendors inventory that doesn’t match the exchanges inventory. There is no common data set between the parties involved in billing and reconciliation But let’s be candid. The challenges of billing, reporting and reconciliation have been on the market data agenda for over 20 years. So while the path to fixing this problem is not completely clear -- there is one over ridding point -- in the age of e-commerce, automation and efficiency -- we can do better. The goal is to automate, simplify and standardize. BPA is a concept that is long overdue. I thank you for the invitation and for your attention.

FIBV Data Vending Workshop Presentation — Presentation Transcript

FIBV Data Vending Workshop Michael Atkin, FISD Taipei 13-14 September 2001
FISD: A Global Market Data Business Forum
- Neutral trade association for organizations in the market data industry
- 140 organizational members around the world
- Members are responsible for their own strategic and commercial interests within FISD
- Staff acts as a neutral facilitator of the discussion and manager of the consensus agenda that emerges as a result
FISD Executive Committee
- Exchanges (Chicago Board of Trade, Chicago Mercantile Exchange, Deutsche Boerse AG, Euronext, London Stock Exchange, Nasdaq Stock Market, New York Mercantile Exchange, New York Stock Exchange, Toronto Stock Exchange)
- Vendors (Bloomberg Financial, Bridge Information, Financial Times, FININFO SA, Primark Corp., Reuters, S&P Comstock, Telekurs Financial, Thomson Financial)
- User Firms (Charles Schwab, Credit Suisse First Boston, Fidelity Investments, JP Morgan Chase, Lehman Brothers Inc., Merrill Lynch, Morgan Stanley & Co., UK Information Provider User Group, Wellington Management Co., LLP)
Tomorrow’s Data Environment
- The new “age of efficiency and automation” is upon us
- Standards: what you don’t know can hurt you
- Four Core Areas
Straight Through Processing
- The automated processing of securities transactions from trade inception to settlement
- The back office moves forward
- Security identification in automated environments (symbology)
Data Quality
- MDDL (XML for market data)
- Data Volumes
- Data Flags
- Transparency of price types
- Network reliability
Market Data Administration
- Bring contracts up to date
- Transparent, consistent and rational market data business policies
- Business models that promote e-commerce
- Business process automation
Market Data Definition Language
What is MDDL?
- XML-based interchange format on the fields needed to describe
- Mission of MDDL
Core MDDL Question
- Why would vendors who have built a core business around proprietary data formats want to shift to an open format standard?
Why Do We Need MDDL?
- Application efficiency (user demand)
- Product functionality (data relationships)
- Straight through processing
MDDL Requirements
- Support multiple vendors
- Common vendor interface
- Common request format (ISIN, ticker, instrument type)
- Accommodate vendor and exchange specific fields
- Support entitlement and permissioning requirements
- Standardize data field names
- Provide a mechanism for validation and data quality
- Facilitate security identification for STP
- Common request/response interface
Transparency, Disclosure and Exchange Obligations Overview of Developments in the United States
Market Data Regulation
- What’s going on?
- Environmental Factors
U.S. Market Structure
- SEC Objectives
- Exchange Act and 1975 Amendments
Issues Being Addressed
- The definition of transparency
- Consolidated data stream
- Cost of market data and revenue sharing
- Access to data (terms and conditions)
- Data ownership
- Capacity and quote mitigation
Advisory Committee Recommendations
- Transparency
- Does existing systems provide sufficient transparency?
Recommendations
- Consolidation
- Plan Administration
Recommendations
- Fees and Revenues
- Capacity
Recommendations
- Data Ownership
- Focus of Congressional inquiry
Tomorrow’s Standards Today MDDL, Market Data Business Policy, Symbology and Business Process Automation
Simplify, Automate, Standardize
- New mantra for the global market data industry
- Standardization is good business
- Will the global financial industry work cooperatively to implement standards?
STP Standards
- Firms are in the midst of technology planning cycles for STP
- Changing market conditions require a fast, efficient way to process transactions from point-of-trade to point-of-settlement
Unique Security Identification
- Accurate and timely security identification is one of the keys to STP
- Incompatible databases and the lack of data standards mean high error rates, valuation errors, exception-based processing, trades of the wrong security and trade failures
Will ISIN Survive STP?
- ISIN is an issue identifier standard
- Place of official listing is essential for pricing and settlement of multiple listings (NOTE: source of the data is the stock exchanges, not the numbering agencies)
- Register is important for security routing
- Place of trade is important for due diligence and market compliance
Data Distribution and MDDL
- The end of the era of proprietary formats?
- Standard data formats are useful for moving data between applications
- Standard data definitions (taxonomy) are useful for creating data relationships and promoting content transparency
- Market data (MDDL) is a component of many other XML initiatives (news, business research, STP, clearing/settlement)
Vocabulary Development
- Common taxonomy for market data
- MDDL Domains
MDDL Descriptors/Glossary
- Identifiers
- Valuations (prices)
- Measures
- Statistics
- Dates and times
- Currencies
- Locations
- Holdings
- Loads and fees
- Industry classification
- Asset class
- Source
- Indicators
- Features
Technical Development
- Extensibility is the key
- Minimal structure defined
- XML schema and DTD supported
- Element based approach
- Concept of reference lists
- Property concept that inherits through hierarchy
MDDL Status
- Version 1.0 beta is now available
- Common equities, mutual funds and indices only
- 1.0 final at FISD’s World Financial Information Conference (London)
- http://www.mddl.org http:www.fisd.net/mddl
Market Data Business Management
- Everything starts with the contract
- Market data business policies
- Business process automation
Contractual Issues
- Principal document governing what vendors, redistributors and subscribers can/can’t do with the data
- (1) definition of market data (7) exchange fees
- (2) content and supply (8) unit of count
- (3) agreements (9) billing and payment
- (4) rights to use (vendor) (10) reporting requirements
- (5) rights to use (subscriber) (11) audit requirements
- (6) system descriptions (12) other market data policies
Problems with Contracts
Market Data Policy Project
- Comprehensive database covering all obligations and requirements covered by exchange contracts
Exchange Business Practices
- Prior Approval versus Vendor Discretion (business model for redistribution of data)
- User Classification (used to determine the rights to use data and fee levels)
- Unit of Count (how market data usage is counted, priced and applied in contracts)
Exchange Business Practices
- Billing and Reporting Requirements
- Subscriber Agreements (used to determine liability and to recognize rights and restrictions on data usage)
- Non-Real Time Data (policies governing the use of delayed data)
- Derived Data (extent to which vendors/subscribers can create their own intellectual property from exchange market data and under what terms)
Business Process Automation
- Simplification and automation of business processes is important to everyone and one of our most important administrative objectives
- Three core goals
- In the age of e-commerce -- we can do better
Now for the Sales Pitch
- Join FISD and get involved in this debate
- Attend the 5th World Financial Information Conference October 30 - November 2 in London
- Michael Atkin (direct) 202.789.4450 matkin@siia.net (web) www.fisd.net

FIBV Data Vending Workshop Presentation

by Zorro29 on Jul 05, 2010

Accessibility

Tags

Upload Details

Usage Rights

Statistics

FIBV Data Vending Workshop Presentation — Presentation Transcript