SIIA ● Financial Information Services Division
VRXML Working Meeting Report
May 18, 2004
Present
Michael Atkin (FISD), Sara Banerjee (Telekurs), Milton Davidson (Telerate), James Hartley (FISD), Jarod Hillman (London Stock Exchange), Paul Howarth (Goldman Sachs), Ron Jordan (NYSE), Rob Leitner (The Roberts Group), David Luftig (Gemini), Glen Madeja (CME), Jeannie Merritt (Nasdaq), Richard Mundell (The Roberts Group), Joan Nickson (Comstock), Bryan Palmer (Gemini), Deidre Quinn (NYSE), Tania Sekuluska (Thomson Financial), Niel Siekerka (Merrill Lynch), Alicia VanDeVeer (Hyperfeed), Trish Wisell (Telerate)
Minutes
Interest in the concepts behind building a standards-based infrastructure (VRXML) for billing and reporting remains high. Adoption (and outright implementation) remains slow for two primary reasons:
1. At the moment, participants make little distinction between mapping/programming to send/receive valid VRXML documents versus meeting the business rule requirements of sending VRXML files to exchanges. The VRXML Working Group agreed on the importance of separating VRXML programming from meeting business rule requirements. The VRXML Working Group recognizes the magnitude of internal efforts needed to clean and process data (product codes, mapping, complexity of reports). As such, FISD will be looking into ways of helping members program to deliver valid VRXML documents – outside of the data integrity requirements needed before vendors can reconcile total inventory with NYSE or meet the various business rules of other exchanges (i.e. enable members to test VRXML without requiring the submission of “perfect data”)
Firms can validate their XML programming approach using off-the-shelf tools such as XML Spy. NYSE indicates they recently implemented a test process to allow firms to validate VRXML only. Other firms (such as the Roberts Group) can also help firms validate VRXML. [Note: The Roberts Group has already validated their VRXML solution and integrated it into their inventory system – eliminating the need for XML programming by TRG clients] The third step in the process is to fix the data and get the reporting requirements right
2. Reporting is a complex (unfortunately) task while knowledge of reporting is small (again unfortunate). Not only that, but as we all know it is still not the top priority among vendors. NYSE is helping a bit by “raising the bar” associated with compliance. Other exchanges are moving in a similar direction. FISD is planning on three activities to address this challenge.
a. First we are creating a FAQ section on the VRXML web site to help raise the overall level of knowledge about VRXML.
b. Second, FISD has compiled a list of the top 15 firms that are considered as “good candidates” for VRXML. That list is being reviewed by exchanges for addition/modification. FISD will meet with each of the candidate firms to find out where they stand on VRXML as well as what we can do to support their activities.
c. Finally, we are working to bridge the “discussion gap” between users, vendors and exchanges on the potential of VRXML throughout the information chain. For example, user firms are keen on getting a standard for electronic invoices/inventory reports. Exchanges are keen on a standard for reporting. In concept, VRXML can/should be used for both (i.e. VRXML as input from users to vendors/exchanges and from vendors to exchanges as well as VRXML as output in the form of an electronic invoice from exchanges to vendors/users and from vendors to their customers).
Other results from the May 19 meeting include:
· The value of separating generic business rules from exchange specific business rules on the VRXML web site. Discussion is underway on how to accomplish and maintain this activity
· Identification of the “role of the entity” (i.e. subscriber, vendor, receiver) in reporting and how to identify that role in VRXML reports. Discussions are underway on the use of correct “labels” for the various roles as well as how to indicate the role in the report. Rob Leitner (The Roberts Group) agreed to spearhead this activity.
· Agreement to extend the specification to be able to identify who the report is “from” and who the report is directed “to.” James Hartley agreed to implement the extension for consideration by the Working Group. Discussion is still underway on whether the “from/to” field should be optional or mandatory.
· Agreement that the industry should use ISO 10383 Market Identification Code (MIC) to identify exchanges, ECNs and other market centers. This will be published as a best practice on VRXML.org. Standard identification of vendors and users as well as the creation of a unique identification repository) are still open issues.
· Identification of “date of relevance” associated with VRXML reports. Working Group participants agree that VRXML will eventually need to define the reporting period in the specification. More discussion is required to determine whether the “effective date” within the record is sufficient for current uses of VRXML.
· Agreement that vendor and exchange product codes need to be transparent and mapped to appear on an invoice report and facilitate reconciliation. This issue still needs further refinement. Hard examples are needed.
· Implementation of a change log on the VRXML web site. The entire group agrees that changes should be kept to a minimum and made no more frequently than quarterly.