A major overhaul of option symbology is in development at the Options Clearing Corp. (OCC) and it looks like July 2009 could be a partial replay of "Y2K" if market participants don't get their acts together. Just as organizations clamored to update, patch and fix their myopically built systems that couldn't cope with four digits in the year field in preparation for the new millennium, we can expect the same frenzy to take place once the new option symbology, proposed by the OCC, takes effect. While some firms have already spent serious time and effort preparing for the upcoming changes, many firms have not yet grasped the potential impact of this initiative-but they will soon.
Listed options are currently named using up to three alpha characters to represent the root symbol and two characters to identify the expiration month, call/put indicator, and strike price. This naming convention worked well for nearly three decades, but with ever expanding option volumes and an increasing palette of options-based products, the system just cannot cope.
Here's why: First, the root indicator, now three alpha characters long, is not compatible with over-the-counter (OTC) securities. Second, these cryptically named options are not very transparent to their underlying security. And third, call/put codes assume single-day expiration and are not compatible with new Long-term Equity Anticipation (Leap) options that can expire in the next calendar year, or Flexible Exchange (Flex) options, which can expire up to four times in a single month. Similarly, the Options Price Reporting Authority (Opra) configuration does not play well with short-dated option contracts that contain expiration dates that don't fit the standard expiration calendars found in The Wall Street Journal, for example.
In the upcoming year or so, options will change in many ways, but most notably:
There will be a single option symbology for all standard option contracts.
A new series key for naming standard contract options will be released.
New naming guidelines for pre- and post-corporation action events with regard to Flex options will be released.
Multipliers to represent listed index options in whole dollar strike intervals will be retired.
When implemented, these changes are expected to reduce front-, middle-, and back-office processes and errors, reduce corporate action conversions, reduce the coordination needed between exchanges for symbol elections, and eliminate wrap symbols and the Leap rollover process. Moreover, the initiative will provide coverage for 95 percent of all listed options and make handling options much easier than it was, but not without some aches and pains.
The look of option symbology, compared to today's look, will change drastically. Options will adopt a single, more transparent symbol, consisting of a minimum of 21 characters, versus the current Opra naming configuration. The new fields, listed in order, are:
Symbol-Six characters
Year-Two characters
Month-Two characters
Day-Two characters
Call/put indicator-One character
Strike dollar-Five characters
Strike decimal-Three characters
According to OCC data, option trade volume is expected to explode exponentially well into the future. Coupled with the proposed, not-so-opportune symbology changes, broker-dealers will have to deal with this increased volume as well. The chart below shows the rapid explosion of listed equity-based option volume over the past three decades.
Since 2001, option trade volume increased by more than 250 percent, with the trend line steepening more every year. The influx of more trades is reason for alarm. Systems, through which option trades flow, will bear the brunt of the increased volume. Moreover, the competitive fervor of exchanges creating new and novel option products, such as listed options on foreign exchange as well as listed options on fixed-income instruments, promises to add volume dramatically as the marketplace adopts them. Algorithmic trading of options has just begun to generate increased appeal. With greater adoption volume, growth may far exceed historically experienced rates of change-only exacerbating the impact on the technological front.
How to prepare
The pervasiveness of the changes proposed by the Option Symbology Initiative (OSI) will require firms to drastically change their current infrastructure to conform to the new option guidelines. Brokers and vendors supporting the new guidelines must, at a minimum, examine security master databases, market data databases, options analytics systems, order management and execution systems, trade processing and clearing systems, and compliance systems.
The security or product master databases-the central databases for most trading organizations-will suffer the greatest impact. Affected brokers must strategically plan for the conversion process and define strict backup and conversion testing procedures-if they maintain their own data-so as to ensure a smooth transition. If firms rely on vendors, those vendors must follow similar procedures.
It will soon be time to bring out that old vendor compliance sheet from Y2K-the one broker-dealers had vendors sign, indicating they were compliant. If you are unsure your vendors will live up to the compliance deadline, you should start thinking about how you can ensure that they will.
Encompassing three main phases-record layout development, symbol conversion process definition, and testing-firms can expect to see the OCC's detailed conversion strategy refined over the course of 2008 and officially communicated in early December of this year. New data elements, pushed into existing outbound feeds, will first appear this June, followed by scripted industry testing in January 2009. July 2009 marks the mandatory compliance and cutover date.
While the committee will establish universal testing guidelines and schedule industry-wide testing timetables, it will be critical that those in charge of IT at broker-dealers not only test in accordance with the committee's general guidelines, but also derive a more critical subset of testing procedures from those high-level guidelines due from the committee prior to Jan. 1, 2009.
It is practically impossible for the OCC to know the intricate details of every member's systems, so participants will need to define their own testing guidelines, procedures and metrics, and pay particular attention to the structure of their databases and the application program interfaces (APIs) of any proprietary software involved. They will be forced to work closely with vendors to ensure that necessary product updates are applied to their non-proprietary or third-party software applications. Any miscue in testing or patching could cause disaster for profit realization, as the potential impact grows in concert with the burgeoning volume.
It will be crucial for brokers and their vendors to perform complete end-to-end testing on all systems to ensure continuity. In addition to investigating potential impacts on primary systems and databases, the interfaces between each system and database will need investigating. Just like the Y2K date limitation problem, proprietary databases may need similar updating to accommodate for the larger option configuration. All exchange and market data interfaces will require analysis and, most likely, some modification. The diagram below depicts the systems involved.
The FIX protocol will be compatible with the new symbology but still warrants similar interface testing. Options exchanges are likely to follow in supporting both Opra and OCC configurations past the mandatory cutover date; however, firms should engage FIX protocol experts to ensure continuity between systems and exchanges.
Structured products, on the other hand, which can consist of a number of bundled derivatives, will require investigation, as the underlying option contract will need to follow the new configuration guidelines. Lastly, firms will need to consider how option-related analytics, including algorithms, will function using historical option data-for example, option data that was recorded using the old configuration.
How will the OSI affect your organization? A project management office (PMO) can help with structuring the transition effort, as well as coordinate with other internal initiatives that may be impacted by these changes. While critical initial work is needed for conducting an impact assessment, designing a conversion process, or planning for the implementation and necessary internal and industry testing, a PMO is essential to a project of this scale and scope. In times of frenzy, firms often clamber to apply Band-Aids to issues as they arise-while meticulous planning becomes an afterthought. This standard approach is bound for disaster. In preparation for major changes, careful planning is critical to ensure all systems are properly examined, patched, and tested. Without a detailed checklist in hand it will be difficult for already overburdened technology teams to investigate and test all potential problem areas within their respective organizations before the mandatory cutover date in July 2009.
James T. Leman is principal and head of capital markets, and Connor McGogney is senior consultant at technology advisory firm Westwater Corp.
No Related Articles