Self-Regulatory Organizations; Chicago Board Options Exchange, Incorporated; Notice of Filing and Immediate Effectiveness of a Proposed Rule Change Relating to the Technical Disconnect Functionality, 46395-46399 [2013-18347]

Download as PDF Federal Register / Vol. 78, No. 147 / Wednesday, July 31, 2013 / Notices the ability to adjust the thresholds of Trade Collar Protection to react to market conditions. In addition, the Exchange believes that preventing executions of incoming marketable orders at prices that are not [sic] more than one Trading Collar outside of the NBBO and rejecting incoming limit orders that are priced specified parameters away from the NBBO also assures that executions will not occur at erroneous prices, thereby promoting a fair and orderly market. Similarly, the Exchange believes that rejecting limit orders priced a specified percentage away from the NBBO removes impediments to and perfects the mechanism of a free and open market by reducing the potential for executions at erroneous prices. B. Self-Regulatory Organization’s Statement on Burden on Competition The Exchange does not believe that the proposed rule change will impose any burden on competition not necessary or appropriate in furtherance of the purposes of the Act. The Exchange believes the proposal will provide market participants with additional protection from anomalous executions. Thus, the Exchange does not believe the proposal creates any significant impact on competition. mstockstill on DSK4VPTVN1PROD with NOTICES C. Self-Regulatory Organization’s Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others No written comments were solicited or received with respect to the proposed rule change. III. Date of Effectiveness of the Proposed Rule Change and Timing for Commission Action The Exchange has filed the proposed rule change pursuant to Section 19(b)(3)(A)(iii) of the Act 16 and Rule 19b–4(f)(6) thereunder.17 Because the proposed rule change does not: (i) Significantly affect the protection of investors or the public interest; (ii) impose any significant burden on competition; and (iii) become operative prior to 30 days from the date on which it was filed, or such shorter time as the Commission may designate, if consistent with the protection of investors and the public interest, the proposed rule change has become effective pursuant to Section 19(b)(3)(A) of the Act and Rule 19b–4(f)(6)(iii) thereunder. At any time within 60 days of the filing of such proposed rule change, the 16 15 17 17 Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings under Section 19(b)(2)(B) 18 of the Act to determine whether the proposed rule change should be approved or disapproved. IV. Solicitation of Comments Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods: Electronic Comments • Use the Commission’s Internet comment form (https://www.sec.gov/ rules/sro.shtml); or • Send an email to rulecomments@sec.gov. Please include File Number SR–NYSEArca–2013–72 on the subject line. Paper Comments • Send paper comments in triplicate to Elizabeth M. Murphy, Secretary, Securities and Exchange Commission, 100 F Street NE., Washington, DC 20549–1090. All submissions should refer to File Number SR–NYSEArca–2013–72. This file number should be included on the subject line if email is used. To help the Commission process and review your comments more efficiently, please use only one method. The Commission will post all comments on the Commission’s Internet Web site (https://www.sec.gov/ rules/sro.shtml). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for Web site viewing and printing in the Commission’s Public Reference Section, 100 F Street NE., Washington, DC 20549–1090. Copies of the filing will also be available for inspection and copying at the NYSE’s principal office and on its Internet Web site at www.nyse.com. All comments U.S.C. 78s(b)(3)(A)(iii). CFR 240.19b–4(f)(6). VerDate Mar<15>2010 16:14 Jul 30, 2013 18 15 Jkt 229001 PO 00000 U.S.C. 78s(b)(2)(B). Frm 00084 Fmt 4703 Sfmt 4703 46395 received will be posted without change; the Commission does not edit personal identifying information from submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR– NYSEArca–2013–72 and should be submitted on or before August 21, 2013. For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.19 Kevin M. O’Neill, Deputy Secretary. [FR Doc. 2013–18346 Filed 7–30–13; 8:45 am] BILLING CODE 8011–01–P SECURITIES AND EXCHANGE COMMISSION [Release No. 34–70039; File No. SR–CBOE– 2013–071] Self-Regulatory Organizations; Chicago Board Options Exchange, Incorporated; Notice of Filing and Immediate Effectiveness of a Proposed Rule Change Relating to the Technical Disconnect Functionality July 25, 2013. Pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 (the ‘‘Act’’),1 and Rule 19b–4 thereunder,2 notice is hereby given that, on July 12, 2013, Chicago Board Options Exchange, Incorporated (the ‘‘Exchange’’ or ‘‘CBOE’’) filed with the Securities and Exchange Commission (the ‘‘Commission’’) the proposed rule change as described in Items I, II, and III below, which Items have been prepared by the Exchange. The Commission is publishing this notice to solicit comments on the proposed rule change from interested persons. I. Self-Regulatory Organization’s Statement of the Terms of Substance of the Proposed Rule Change The Exchange is proposing to amend its rules to codify the Technical Disconnect Mechanism. The text of the proposed rule change is also available on the Exchange’s Web site (https:// www.cboe.com/AboutCBOE/ CBOELegalRegulatoryHome.aspx), at the Exchange’s Office of the Secretary, and at the Commission’s Public Reference Room. 19 17 CFR 200.30–3(a)(12). U.S.C. 78s(b)(1). 2 17 CFR 240.19b–4. The Commission notes that the Exchange filed the proposed rule change pursuant to Section 19(b)(3)(A)(ii) of the Act (15 U.S.C. 78s(b)(3)(A)(ii)) and Rule 19b–4(f)(5) thereunder (17 CFR 240.19b–4(f)(5)), which renders the proposal effective upon filing with the Commission. 1 15 E:\FR\FM\31JYN1.SGM 31JYN1 46396 Federal Register / Vol. 78, No. 147 / Wednesday, July 31, 2013 / Notices II. Self-Regulatory Organization’s Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change In its filing with the Commission, the Exchange included statements concerning the purpose of and basis for the proposed rule change and discussed any comments it received on the proposed rule change. The text of these statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant aspects of such statements. mstockstill on DSK4VPTVN1PROD with NOTICES A. Self-Regulatory Organization’s Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change 1. Purpose The Exchange is proposing to amend CBOE Rules to codify a Technical Disconnect functionality which is designed to assist CBOE Trading Permit Holders (‘‘TPHs’’) in the event that they lose communication with a CBOE Application Server (‘‘CAS’’) due to a loss of connectivity between their designated CBOE Client Application and a CAS. By way of background, CBOE TPHs currently enter quotes and orders into a CAS via Client Applications. For purposes of this discussion, a ‘‘Client Application’’ is the system component, such as a CBOE-supported workstation or a TPH’s custom trading application, through which a TPH communicates its quotes and/or orders to a CAS,3 which sits between the Client Application and the trading platform for the CBOE Hybrid Trading System. Messages are passed between a Client Application and a CAS. The quotes a Market-Maker enters on the Exchange may be sent by a Market-Maker from one or more Client Applications. Similarly, the orders a TPH enters on the Exchange may be sent by the TPH from one or more Client Applications. When a CAS loses communication with a Client Application such that the CAS does not receive an appropriate response to a Heartbeat Request within ‘‘x’’ period of time (‘‘Heartbeat Response Time’’), the Technical Disconnect Mechanism will automatically logoff the TPH’s affected Client Application and, if applicable, will automatically cancel any Market-Maker quotes posted through the affected Client Application. For purposes of this rule, a ‘‘Heartbeat Request’’ refers to a message from a CAS 3 CBOE currently has numerous CASs serving TPHs. VerDate Mar<15>2010 16:14 Jul 30, 2013 Jkt 229001 to a Client Application to check connectivity and which requires a response from the Client Application in order to avoid logoff. The Heartbeat Request acts as a virtual pulse between a CAS and a Client Application and allows a CAS to continually monitor its connection with a Client Application. Failure to receive a response to a Heartbeat Request within the Heartbeat Response Time is indicative of a technical or system issue. This function of automatically logging off a Client Application, and if applicable automatically cancelling Market-Maker quotes posted through the affected Client Application, when there is no response to a Heartbeat Request within the Heartbeat Response Time is intended to help to mitigate the potential risks associated with a loss of communication with a Client Application (e.g., erroneous or unintended executions due to stale quotes that remained in the CBOE Book). This serves to assist a TPH when such a technical or system issue occurs, and also assist the Exchange in maintaining a fair and orderly market generally. A CAS will generate a Heartbeat Request to a Client Application after a specified interval (‘‘Heartbeat Interval’’ or ‘‘ ‘n’ period of time’’). Additionally as noted above, a CAS will disconnect a Client Application, and if applicable cancel any Market-Maker quotes posted through the affect Client Application, after a specified period of time if it does not receive a appropriate response to a Heartbeat Request (Heartbeat Response Time or ‘‘ ‘x’ period of time’’). The Exchange notes that the Heartbeat Interval and the Heartbeat Response Time depend upon the Application Programming Interface (‘‘API’’) a TPH is using.4 Currently, the Exchange offers two APIs: CBOE Market Interface (‘‘CMi’’) API and Financial Information eXchange (‘‘FIX’’) Protocol. CMi currently has two versions available: CMi and CMi 2. A TPH may determine which of the available APIs, and if applicable, which version, it would like to use. First, a CAS on the CMi API will generate a Heartbeat Request to a Client Application after every ‘‘n’’ period of time. The Value of ‘‘n’’ is currently set by the Exchange at two (2) seconds. Depending upon the interface version of CMi a TPH is using, the value of ‘‘x’’ is either set at twenty (20) seconds by the Exchange or the TPH may determine the 4 An API is a computer interface that allows market participants with authorized access to interface electronically with the Exchange. Multiple versions of each API may exist and other APIs may be supported from time-to-time. PO 00000 Frm 00085 Fmt 4703 Sfmt 4703 value of ‘‘x’’ at logon, so long as it is not less than three (3) seconds and does not exceed twenty (20) seconds. A CAS on the CMi 2 API will generate a Heartbeat Request to a Client Application (i) after the CAS does not receive any messages from a particular Client Application for ‘‘n’’ period of time or (ii) after every ‘‘n’’ period of time. A TPH using CMi 2 will determine whether Heartbeat Requests are generated every ‘‘n’’ period of time or only if no messages are received for ‘‘n’’ period of time. A TPH using the CMi 2 API will also determine the value of ‘‘n’’ at logon. In no event shall ‘‘n’’ be less than three (3) seconds or exceed twenty (20) seconds. If a CAS generates a Heartbeat Request only after it does not receive any messages from a particular Client Application for ‘‘n’’ period of time, the value of ‘‘x’’ (Heartbeat Response Time) will be set at a half (.5) second. If a CAS generates a Heartbeat Request every ‘‘n’’ period of time, the value of ‘‘x’’ shall be equal to the value of ‘‘n.’’ For example, if a TPH using CMi 2 chooses to receive a Heartbeat Request every ‘‘n’’ period of time and sets the value of ‘‘n’’ to 6 seconds, then the TPH’s Client Application must respond to a Heartbeat Request within 6 seconds or the Client Application will be disconnected. A CAS on the FIX API will generate a Heartbeat Message to a Client Application after the CAS does not receive any messages from a particular Client Application for ‘‘n’’ period of time. If the CAS does not receive a response to the ‘‘Heartbeat Message’’ from the Client Application for ‘‘n’’ period of time, the CAS shall generate a Heartbeat Request to the Client Application. For purposes of this rule, a ‘‘Heartbeat Message’’ refers to a message from a CAS to a Client Application to check connectivity. Failure to respond to a Heartbeat Message within ‘‘n’’ period of time will trigger the generation of a Heartbeat Request. A TPH using the FIX API will determine the value of ‘‘n’’ at logon. In no event shall ‘‘n’’ be less than five (5) seconds. The value of ‘‘x’’ (Heartbeat Response Time) will be set equal to the value of ‘‘n.’’ For example, if a TPH using FIX sets the value of ‘‘n’’ to 6 seconds, then the TPH’s Client Application must respond to a Heartbeat Request within 6 seconds or the Client Application will be disconnected. The following example illustrates the manner in which the Technical Disconnect Mechanism functions on CMi. For purposes of this example only, the TPH will be a Market-Maker and ‘‘n’’ will be set at 2 seconds and ‘‘x’’ is set at 20 seconds: E:\FR\FM\31JYN1.SGM 31JYN1 mstockstill on DSK4VPTVN1PROD with NOTICES Federal Register / Vol. 78, No. 147 / Wednesday, July 31, 2013 / Notices (1) 10:00:000—Heartbeat Request sent to Client Application after logon 10:00:020—CAS generates Heartbeat Request to Client Application 10:00:030—CAS receives message from Client Application 10:00:040—CAS generates Heartbeat Request 10:00:040–10:00:240—No messages received from Client Application 10:00:240—No messages received from Client Application within 20 seconds — Client Application automatically logged off and pending MarketMaker quotes previously entered from the Client Application automatically canceled The following example illustrates the manner in which the Technical Disconnect Mechanism functions on CMi2 when a TPH chooses to have the CAS generate a Heartbeat Request every ‘‘n’’ period of time. For purposes of this example only, the TPH will be a nonMarket-Maker and ‘‘n’’ will be set by the TPH at 5 seconds: (1) 10:00:000—Heartbeat Request sent to Client Application after logon 10:00:020—CAS receives a message from Client Application 10:00:050—Heartbeat Request sent to Client Application 10:00:100 –No response to Heartbeat Request received by CAS within 5 seconds —Client Application automatically logged off and pending orders previously entered from the Client Application remain in the Hybrid Trading System The following examples illustrate the manner in which the Technical Disconnect Mechanism functions on CMi 2 when a TPH chooses to have the CAS generate a Heartbeat Request only when the CAS does not receive any messages from the Client Application for ‘‘n’’ period of time. For purposes of these examples only, the TPH will be a Market-Maker and ‘‘n’’ will be set by the TPH at 5 seconds: (1) 10:00:000—Heartbeat Request sent to Client Application after logon 10:00:020—CAS receives a message from Client Application —Counter re-starts 10:00:070—No messages received from Client Application within 5 seconds —CAS generates Heartbeat Request 10:00:073—CAS receives a message from Client Application —Counter restarts (2) 10:00:000—Heartbeat Request sent to Client Application within login 10:00:020—CAS receives a message from Client Application VerDate Mar<15>2010 16:14 Jul 30, 2013 Jkt 229001 —Counter re-starts 10:00:070—No messages received from Client Application within 5 seconds —CAS generates Heartbeat Request 10:00:075—No messages received from Client Application within .5 seconds —Client Application automatically logged off and pending MarketMaker quotes previously entered from the Client Application automatically canceled Lastly, the following example illustrates the manner in which the Technical Disconnect Mechanism functions on FIX. For purposes of this example only, the TPH will be a MarketMaker and ‘‘n’’ will be set by the TPH at 5 seconds: (1) 10:00:000—Heartbeat Request sent to Client Application after logon 10:00:020—CAS receives a message from Client Application —Counter restarts 10:00:070—No messages received from Client Application within 5 seconds —CAS generates Heartbeat Message 10:00:120—No messages received from Client Application within 5 seconds —CAS generates Heartbeat Request 10:00:170—No messages received from Client Application within 5 seconds —Client Application automatically logged off and pending MarketMaker quotes previously entered from the Client Application automatically canceled As demonstrated above, a Heartbeat Request may be generated (i) every ‘‘n’’ period of time or (ii) when the CAS does not receive any messages from a Client Application for a specified period of time (‘‘n’’ period of time) depending upon the API being used. Regardless of the API being used however, if an appropriate response message to a Heartbeat Request is not received by the CAS from the Client Application within a specified period of time (‘‘x’’ period of time or Heartbeat Response Time), the Technical Disconnect Mechanism is triggered and the Client Application is automatically logged off and, if applicable, a Market-Maker’s quotes through that Client Application are automatically canceled. The Exchange notes that any nonconnectivity is event- and Client Application-specific. Therefore, the cancellation of a Market-Maker’s quotes entered into a CAS via a particular Client Application will neither impact nor determine the treatment of the quotes of the same or other Market- PO 00000 Frm 00086 Fmt 4703 Sfmt 4703 46397 Makers entered into a CAS via a separate and distinct Client Application. The Technical Disconnect Mechanism will not impact or determine the treatment of orders previously entered into a CAS. As discussed above, the function of automatically cancelling a Market-Maker’s quotes posted through an affected Client Application is intended to help to mitigate the potential risks associated with a loss of communication with a Client Application. For example, in today’s market, Market-Makers’ quotes are rapidly changing and can have a lifespan of only milliseconds. Additionally, under the Hybrid Trading System, trades are automatically effected against the Market-Maker’s then current quote. Therefore, if a TPH’s Client Application is disconnected for any period of time, it is very possible that any quotes posted through that Client Application would be stale by the time the TPH reestablished connectivity. Consequently, any resulting execution of such quotes is more likely to be erroneous or unintended. Conversely, the Exchange notes that orders tend to be static in nature and often rest in the book. Indeed, certain order types, such as Market-on-Close orders, are intended to rest in the book for a period of time. As such, there is a lower risk of erroneous or unintended executions resulting from orders that remained in the Hybrid Trading System during and after an affected Client Application was logged off. The Exchange next notes that the CAS will send a logout message to an affected Client Application that confirms that the Client Application connection has been terminated. Once connectivity to the Client Application is reestablished, a Market-Maker affected by the mechanism is able to send messages to the CAS to reestablish the Market-Maker’s quotes. Any MarketMaker affected by the Technical Disconnect Mechanism is not relieved of its obligation to provide continuous electronic quotes under the Exchange rules.5 The Exchange finally notes that 5 With respect to a Market-Maker who is obligated to provide continuous electronic quotes on the Hybrid Trading System (‘‘Hybrid Market-Maker’’), CBOE Rule 1.1(ccc) Continuous Electronic Quotes provides that the Exchange may consider other exceptions to the Hybrid Market-Maker’s continuous electronic quote obligation based on demonstrated legal or regulatory requirements or other mitigating circumstances. As provided in SR–CBOE–2005–93, Amendment 1 (See Securities Exchange Act Release No. 54250 (July 31, 2006), 71 FR 44729 (August 7, 2006)), mitigating circumstances that may be considered by the Exchange may include, but is not limited to, instances where a technical failure or limitation in E:\FR\FM\31JYN1.SGM Continued 31JYN1 46398 Federal Register / Vol. 78, No. 147 / Wednesday, July 31, 2013 / Notices the Technical Disconnect Mechanism is enabled for all TPHs and may not be disabled by TPHs. The Exchange believes that while information relating to connectivity and the Technical Disconnect Mechanism are already available to TPHs via technical specifications, codifying this information within the rule text will provide additional transparency and further reduce potential confusion. mstockstill on DSK4VPTVN1PROD with NOTICES 2. Statutory Basis The Exchange believes the proposed rule change is consistent with the Securities Exchange Act of 1934 (the ‘‘Act’’) and the rules and regulations thereunder applicable to the Exchange and, in particular, the requirements of Section 6(b) of the Act.6 Specifically, the Exchange believes the proposed rule change is consistent with the Section 6(b)(5) 7 requirements that the rules of an exchange be designed to prevent fraudulent and manipulative acts and practices, to promote just and equitable principles of trade, to foster cooperation and coordination with persons engaged in regulating, clearing, settling, processing information with respect to, and facilitating transactions in securities, to remove impediments to and perfect the mechanism of a free and open market and a national market system, and, in general, to protect investors and the public interest. In particular, the Exchange believes that codifying in the rules how the Technical Disconnect Mechanism works provides additional transparency in the rules and provides an additional avenue to easily understand CBOE’s system and processes. The Exchange believes this will also reduce any potential confusion, thereby removing a potential impediment to and perfecting the mechanism for a free and open market and a national market system, and, in general, protecting investors and the public interest. Additionally, the Technical Disconnect Mechanism is a valuable tool that is designed to help maintain a fair and orderly market. The Exchange believe that the Technical Disconnect Mechanism assists with the maintenance of fair and orderly markets by helping to mitigate the potential risks a Hybrid Market-Maker’s system prevents the Hybrid Market-Maker from maintaining, or communicating to the Exchange, timely and accurate electronic quotes. However, a pattern or practice of technical failures or limitations, or the excessive frequency of technical failures or limitations, may also be considered by the Exchange in determining whether to except the period of time from the continuous electronic quoting requirements. 6 15 U.S.C. 78f(b). 7 15 U.S.C. 78f(b)(5). VerDate Mar<15>2010 16:14 Jul 30, 2013 Jkt 229001 associated with a loss in communication with a Client Application, especially risk associated with a loss in communication with a Client Application of a Market-Maker that is providing quotes across a multitude of series and classes. The Exchange also believes that the proposed rule change is designed to not permit unfair discrimination among market participants. The Exchange notes that the Technical Disconnect Mechanism automatic logoff function is applicable to all TPHs and may not be disabled by any TPH. The Exchange believes that the Technical Disconnect Mechanism benefits the marketplace because it designed to help alert a TPH to a potential technical or system issue and automatically logoff a TPH’s Client Application within certain prescribed parameters. With respect to the Technical Disconnect Mechanism’s automatic cancellation of Market-Maker quotes, the Exchange also believes it is not unfair to cancel only Market-Maker quotes and not orders. Particularly, the automatic cancellation of Market-Maker quotes benefits the marketplace because it is designed to help reduce the risk of stale quotes remaining on the CBOE Book in the event that a CAS loses connectivity with a Client Application (e.g., potentially resulting in erroneous or unintended executions). Furthermore, the functionality provides for the protection of Market-Makers, who must bear the burden of market risk for stale quotes, as well as for the protection of investors and the efficiency and fairness of the markets as a whole. Conversely, because orders tend to be static in nature and often rest in the book, the Exchange believes there is a lower risk of erroneous or unintended executions resulting from orders that remain in the Hybrid Trading System during and after an affected Client Application is logged off. The Exchange believes this functionality enhances the overall market quality for options traded on CBOE. B. Self-Regulatory Organization’s Statement on Burden on Competition CBOE does not believe that the proposed rule change will impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. Specifically, the Exchange does not believe the proposed rule change will cause any burden on intramarket competition because it applies to all TPHs. Even though the functionality treats MarketMakers’ quotes differently than orders, the Exchange notes again that it believes that the Technical Disconnect Mechanism benefits all market PO 00000 Frm 00087 Fmt 4703 Sfmt 4703 participants because it reduces the risk of stale quotes on the CBOE Book, which can result in erroneous or unintended trades. Further, the Exchange does not believe that such change will impose any burden on intermarket competition that is not necessary or appropriate in furtherance of the purposes of the Act. The Exchange notes that, should the proposed changes make CBOE more attractive for trading, market participants trading on other exchanges are welcome to become TPHs and trade at CBOE if they determine that this proposed rule change has made CBOE more attractive or favorable. C. Self-Regulatory Organization’s Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others The Exchange neither solicited nor received comments on the proposed rule change. III. Date of Effectiveness of the Proposed Rule Change and Timing for Commission Action The foregoing rule change has become effective pursuant to Section 19(b)(3)(A) of the Act 8 and paragraph (f) of Rule 19b–4 9 thereunder. At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission will institute proceedings to determine whether the proposed rule change should be approved or disapproved. IV. Solicitation of Comments Interested persons are invited to submit written data, views and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods: Electronic Comments • Use the Commission’s Internet comment form (https://www.sec.gov/ rules/sro.shtml); or • Send an email to rulecomments@sec.gov. Please include File Number SR–CBOE–2013–071 on the subject line. 8 15 9 17 E:\FR\FM\31JYN1.SGM U.S.C. 78s(b)(3)(A). CFR 240.19b–4(f). 31JYN1 Federal Register / Vol. 78, No. 147 / Wednesday, July 31, 2013 / Notices Paper Comments • Send paper comments in triplicate to Elizabeth M. Murphy, Secretary, Securities and Exchange Commission, 100 F Street NE., Washington, DC 20549–1090. All submissions should refer to File Number SR–CBOE–2013–071. This file number should be included on the subject line if email is used. To help the Commission process and review your comments more efficiently, please use only one method. The Commission will post all comments on the Commission’s Internet Web site (https://www.sec.gov/ rules/sro.shtml). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for Web site viewing and printing in the Commission’s Public Reference Room, 100 F Street NE., Washington, DC 20549, on official business days between the hours of 10:00 a.m. and 3:00 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. All comments received will be posted without change; the Commission does not edit personal identifying information from submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR–CBOE– 2013–071 and should be submitted on or before August 21, 2013. For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.10 Kevin M. O’Neill, Deputy Secretary. [FR Doc. 2013–18347 Filed 7–30–13; 8:45 am] mstockstill on DSK4VPTVN1PROD with NOTICES BILLING CODE 8011–01–P SECURITIES AND EXCHANGE COMMISSION [Release No. 34–70037; File No. SR– NYSEMKT–2013–62] Self-Regulatory Organizations; NYSE MKT LLC; Notice of Filing and Immediate Effectiveness of Proposed Rule Change Adding a New Rule To Codify Existing Price Protection Mechanisms July 25, 2013. Pursuant to Section 19(b)(1) 1 of the Securities Exchange Act of 1934 (the ‘‘Act’’) 2 and Rule 19b–4 thereunder,3 notice is hereby given that on July 17, 2013, NYSE MKT LLC (the ‘‘Exchange’’ or ‘‘NYSE MKT’’) filed with the Securities and Exchange Commission (the ‘‘Commission’’) the proposed rule change as described in Items I and II below, which Items have been prepared by the self-regulatory organization. The Commission is publishing this notice to solicit comments on the proposed rule change from interested persons. I. Self-Regulatory Organization’s Statement of the Terms of Substance of the Proposed Rule Change The Exchange proposes to add a new rule to codify existing price protection mechanisms. The text of the proposed rule change is available on the Exchange’s Web site at www.nyse.com, at the principal office of the Exchange, and at the Commission’s Public Reference Room. II. Self-Regulatory Organization’s Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change In its filing with the Commission, the self-regulatory organization included statements concerning the purpose of, and basis for, the proposed rule change and discussed any comments it received on the proposed rule change. The text of those statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant parts of such statements. A. Self-Regulatory Organization’s Statement of the Purpose of, and the Statutory Basis for, the Proposed Rule Change 1. Purpose The Exchange is proposing to add Rule 967NY to codify and clarify price protection mechanisms already in use 1 15 U.S.C.78s(b)(1). U.S.C. 78a. 3 17 CFR 240.19b–4. 2 15 10 17 CFR 200.30–3(a)(12). VerDate Mar<15>2010 16:14 Jul 30, 2013 Jkt 229001 PO 00000 Frm 00088 Fmt 4703 Sfmt 4703 46399 on the Exchange. The Exchange has in place various price check parameter features that are designed to help maintain a fair and orderly market by preventing incoming options orders from automatically executing at potentially erroneous prices. The Exchange believes that the features assist with the maintenance of fair and orderly markets by helping to mitigate the potential risks associated with orders sweeping through multiple price points, thereby resulting in executions at prices that are away from the last sale price or best bid or offer and that are potentially erroneous. The Exchange is proposing to add a new rule to codify existing price check protection and order handling features to provide clarity on the operation of the functionality. Trading Collars The Exchange applies a ‘‘Trade Collar Protection’’ mechanism that prevents the immediate execution of incoming market orders or marketable limit orders (‘‘marketable orders’’) outside of a specified parameter (referred to as a ‘‘Trading Collar’’). Pursuant to proposed Rule 967NY(a)(3), the Trade Collar Protection mechanism is not available for quotes 4 or for orders with execution conditions IOC, AON, FOK and NOW.5 Trading Collars are determined by the Exchange on a class-by-class basis and, unless announced otherwise via Trader Update, are the same value as the bidask differential guidelines established pursuant to Rule 925NY(b)(4), as set forth in proposed Rule 967NY(a)(2). For example, Rule 925NY(b)(4) sets the bidask differential for an option priced less than $2.00 at $0.25. For any option that 4 Market Makers have obligations to provide liquidity through the quoting obligations set forth in Rule 925.1NY. The Exchange does not believe it is necessary to provide Trade Collar Protection to quotes, as they may be priced to address dislocation in the market. The Exchange provides Market Makers with a dedicated trade protection mechanism set forth in Rule 928NY. 5 IOC, AON, FOK or NOW are time in force indicators added to orders that notify the Exchange that the order is not eligible for Trade Collar Protection. When Trade Collar Protection does not apply, marketable orders will receive an immediate execution. The Exchange does not believe that Trade Collar Protection is necessary for orders with IOC, FOK, or NOW instructions because by definition, those orders are intended to access all availability liquidity without delay and cancel if they do not execute. Because Trade Collar Protection may hold a market or marketable limit order for execution, the Exchange believes that it would contradict the explicit instruction of a customer using IOC, FOK, or NOW instructions (immediately execute or cancel). The Exchange further believes that the Trade Collar Protection is not necessary for AON orders because by definition, an AON order must meet sufficient size before executing, and so partial executions at multiple price points would contradict the explicit instruction of a customer using an AON instruction. E:\FR\FM\31JYN1.SGM 31JYN1

Agencies

[Federal Register Volume 78, Number 147 (Wednesday, July 31, 2013)]
[Notices]
[Pages 46395-46399]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2013-18347]


-----------------------------------------------------------------------

SECURITIES AND EXCHANGE COMMISSION

[Release No. 34-70039; File No. SR-CBOE-2013-071]


Self-Regulatory Organizations; Chicago Board Options Exchange, 
Incorporated; Notice of Filing and Immediate Effectiveness of a 
Proposed Rule Change Relating to the Technical Disconnect Functionality

July 25, 2013.
    Pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 
(the ``Act''),\1\ and Rule 19b-4 thereunder,\2\ notice is hereby given 
that, on July 12, 2013, Chicago Board Options Exchange, Incorporated 
(the ``Exchange'' or ``CBOE'') filed with the Securities and Exchange 
Commission (the ``Commission'') the proposed rule change as described 
in Items I, II, and III below, which Items have been prepared by the 
Exchange. The Commission is publishing this notice to solicit comments 
on the proposed rule change from interested persons.
---------------------------------------------------------------------------

    \1\ 15 U.S.C. 78s(b)(1).
    \2\ 17 CFR 240.19b-4. The Commission notes that the Exchange 
filed the proposed rule change pursuant to Section 19(b)(3)(A)(ii) 
of the Act (15 U.S.C. 78s(b)(3)(A)(ii)) and Rule 19b-4(f)(5) 
thereunder (17 CFR 240.19b-4(f)(5)), which renders the proposal 
effective upon filing with the Commission.
---------------------------------------------------------------------------

I. Self-Regulatory Organization's Statement of the Terms of Substance 
of the Proposed Rule Change

    The Exchange is proposing to amend its rules to codify the 
Technical Disconnect Mechanism. The text of the proposed rule change is 
also available on the Exchange's Web site (https://www.cboe.com/AboutCBOE/CBOELegalRegulatoryHome.aspx), at the Exchange's Office of 
the Secretary, and at the Commission's Public Reference Room.

[[Page 46396]]

II. Self-Regulatory Organization's Statement of the Purpose of, and 
Statutory Basis for, the Proposed Rule Change

    In its filing with the Commission, the Exchange included statements 
concerning the purpose of and basis for the proposed rule change and 
discussed any comments it received on the proposed rule change. The 
text of these statements may be examined at the places specified in 
Item IV below. The Exchange has prepared summaries, set forth in 
sections A, B, and C below, of the most significant aspects of such 
statements.

A. Self-Regulatory Organization's Statement of the Purpose of, and 
Statutory Basis for, the Proposed Rule Change

1. Purpose
    The Exchange is proposing to amend CBOE Rules to codify a Technical 
Disconnect functionality which is designed to assist CBOE Trading 
Permit Holders (``TPHs'') in the event that they lose communication 
with a CBOE Application Server (``CAS'') due to a loss of connectivity 
between their designated CBOE Client Application and a CAS.
    By way of background, CBOE TPHs currently enter quotes and orders 
into a CAS via Client Applications. For purposes of this discussion, a 
``Client Application'' is the system component, such as a CBOE-
supported workstation or a TPH's custom trading application, through 
which a TPH communicates its quotes and/or orders to a CAS,\3\ which 
sits between the Client Application and the trading platform for the 
CBOE Hybrid Trading System. Messages are passed between a Client 
Application and a CAS. The quotes a Market-Maker enters on the Exchange 
may be sent by a Market-Maker from one or more Client Applications. 
Similarly, the orders a TPH enters on the Exchange may be sent by the 
TPH from one or more Client Applications.
---------------------------------------------------------------------------

    \3\ CBOE currently has numerous CASs serving TPHs.
---------------------------------------------------------------------------

    When a CAS loses communication with a Client Application such that 
the CAS does not receive an appropriate response to a Heartbeat Request 
within ``x'' period of time (``Heartbeat Response Time''), the 
Technical Disconnect Mechanism will automatically logoff the TPH's 
affected Client Application and, if applicable, will automatically 
cancel any Market-Maker quotes posted through the affected Client 
Application. For purposes of this rule, a ``Heartbeat Request'' refers 
to a message from a CAS to a Client Application to check connectivity 
and which requires a response from the Client Application in order to 
avoid logoff. The Heartbeat Request acts as a virtual pulse between a 
CAS and a Client Application and allows a CAS to continually monitor 
its connection with a Client Application. Failure to receive a response 
to a Heartbeat Request within the Heartbeat Response Time is indicative 
of a technical or system issue. This function of automatically logging 
off a Client Application, and if applicable automatically cancelling 
Market-Maker quotes posted through the affected Client Application, 
when there is no response to a Heartbeat Request within the Heartbeat 
Response Time is intended to help to mitigate the potential risks 
associated with a loss of communication with a Client Application 
(e.g., erroneous or unintended executions due to stale quotes that 
remained in the CBOE Book). This serves to assist a TPH when such a 
technical or system issue occurs, and also assist the Exchange in 
maintaining a fair and orderly market generally.
    A CAS will generate a Heartbeat Request to a Client Application 
after a specified interval (``Heartbeat Interval'' or `` `n' period of 
time''). Additionally as noted above, a CAS will disconnect a Client 
Application, and if applicable cancel any Market-Maker quotes posted 
through the affect Client Application, after a specified period of time 
if it does not receive a appropriate response to a Heartbeat Request 
(Heartbeat Response Time or `` `x' period of time''). The Exchange 
notes that the Heartbeat Interval and the Heartbeat Response Time 
depend upon the Application Programming Interface (``API'') a TPH is 
using.\4\ Currently, the Exchange offers two APIs: CBOE Market 
Interface (``CMi'') API and Financial Information eXchange (``FIX'') 
Protocol. CMi currently has two versions available: CMi and CMi 2. A 
TPH may determine which of the available APIs, and if applicable, which 
version, it would like to use.
---------------------------------------------------------------------------

    \4\ An API is a computer interface that allows market 
participants with authorized access to interface electronically with 
the Exchange. Multiple versions of each API may exist and other APIs 
may be supported from time-to-time.
---------------------------------------------------------------------------

    First, a CAS on the CMi API will generate a Heartbeat Request to a 
Client Application after every ``n'' period of time. The Value of ``n'' 
is currently set by the Exchange at two (2) seconds. Depending upon the 
interface version of CMi a TPH is using, the value of ``x'' is either 
set at twenty (20) seconds by the Exchange or the TPH may determine the 
value of ``x'' at logon, so long as it is not less than three (3) 
seconds and does not exceed twenty (20) seconds.
    A CAS on the CMi 2 API will generate a Heartbeat Request to a 
Client Application (i) after the CAS does not receive any messages from 
a particular Client Application for ``n'' period of time or (ii) after 
every ``n'' period of time. A TPH using CMi 2 will determine whether 
Heartbeat Requests are generated every ``n'' period of time or only if 
no messages are received for ``n'' period of time. A TPH using the CMi 
2 API will also determine the value of ``n'' at logon. In no event 
shall ``n'' be less than three (3) seconds or exceed twenty (20) 
seconds. If a CAS generates a Heartbeat Request only after it does not 
receive any messages from a particular Client Application for ``n'' 
period of time, the value of ``x'' (Heartbeat Response Time) will be 
set at a half (.5) second. If a CAS generates a Heartbeat Request every 
``n'' period of time, the value of ``x'' shall be equal to the value of 
``n.'' For example, if a TPH using CMi 2 chooses to receive a Heartbeat 
Request every ``n'' period of time and sets the value of ``n'' to 6 
seconds, then the TPH's Client Application must respond to a Heartbeat 
Request within 6 seconds or the Client Application will be 
disconnected.
    A CAS on the FIX API will generate a Heartbeat Message to a Client 
Application after the CAS does not receive any messages from a 
particular Client Application for ``n'' period of time. If the CAS does 
not receive a response to the ``Heartbeat Message'' from the Client 
Application for ``n'' period of time, the CAS shall generate a 
Heartbeat Request to the Client Application. For purposes of this rule, 
a ``Heartbeat Message'' refers to a message from a CAS to a Client 
Application to check connectivity. Failure to respond to a Heartbeat 
Message within ``n'' period of time will trigger the generation of a 
Heartbeat Request. A TPH using the FIX API will determine the value of 
``n'' at logon. In no event shall ``n'' be less than five (5) seconds. 
The value of ``x'' (Heartbeat Response Time) will be set equal to the 
value of ``n.'' For example, if a TPH using FIX sets the value of ``n'' 
to 6 seconds, then the TPH's Client Application must respond to a 
Heartbeat Request within 6 seconds or the Client Application will be 
disconnected.
    The following example illustrates the manner in which the Technical 
Disconnect Mechanism functions on CMi. For purposes of this example 
only, the TPH will be a Market-Maker and ``n'' will be set at 2 seconds 
and ``x'' is set at 20 seconds:


[[Page 46397]]


(1) 10:00:000--Heartbeat Request sent to Client Application after logon
    10:00:020--CAS generates Heartbeat Request to Client Application
    10:00:030--CAS receives message from Client Application
    10:00:040--CAS generates Heartbeat Request
    10:00:040-10:00:240--No messages received from Client Application
    10:00:240--No messages received from Client Application within 20 
seconds
    -- Client Application automatically logged off and pending Market-
Maker quotes previously entered from the Client Application 
automatically canceled

    The following example illustrates the manner in which the Technical 
Disconnect Mechanism functions on CMi2 when a TPH chooses to have the 
CAS generate a Heartbeat Request every ``n'' period of time. For 
purposes of this example only, the TPH will be a non-Market-Maker and 
``n'' will be set by the TPH at 5 seconds:

(1) 10:00:000--Heartbeat Request sent to Client Application after logon
    10:00:020--CAS receives a message from Client Application
    10:00:050--Heartbeat Request sent to Client Application
    10:00:100 -No response to Heartbeat Request received by CAS within 
5 seconds
    --Client Application automatically logged off and pending orders 
previously entered from the Client Application remain in the Hybrid 
Trading System

    The following examples illustrate the manner in which the Technical 
Disconnect Mechanism functions on CMi 2 when a TPH chooses to have the 
CAS generate a Heartbeat Request only when the CAS does not receive any 
messages from the Client Application for ``n'' period of time. For 
purposes of these examples only, the TPH will be a Market-Maker and 
``n'' will be set by the TPH at 5 seconds:

(1) 10:00:000--Heartbeat Request sent to Client Application after logon
    10:00:020--CAS receives a message from Client Application
    --Counter re-starts
    10:00:070--No messages received from Client Application within 5 
seconds
    --CAS generates Heartbeat Request
    10:00:073--CAS receives a message from Client Application
    --Counter restarts
(2) 10:00:000--Heartbeat Request sent to Client Application within 
login
    10:00:020--CAS receives a message from Client Application
    --Counter re-starts
    10:00:070--No messages received from Client Application within 5 
seconds
    --CAS generates Heartbeat Request
    10:00:075--No messages received from Client Application within .5 
seconds
    --Client Application automatically logged off and pending Market-
Maker quotes previously entered from the Client Application 
automatically canceled

    Lastly, the following example illustrates the manner in which the 
Technical Disconnect Mechanism functions on FIX. For purposes of this 
example only, the TPH will be a Market-Maker and ``n'' will be set by 
the TPH at 5 seconds:

(1) 10:00:000--Heartbeat Request sent to Client Application after logon
    10:00:020--CAS receives a message from Client Application
    --Counter restarts
    10:00:070--No messages received from Client Application within 5 
seconds
    --CAS generates Heartbeat Message
    10:00:120--No messages received from Client Application within 5 
seconds
    --CAS generates Heartbeat Request
    10:00:170--No messages received from Client Application within 5 
seconds
    --Client Application automatically logged off and pending Market-
Maker quotes previously entered from the Client Application 
automatically canceled

    As demonstrated above, a Heartbeat Request may be generated (i) 
every ``n'' period of time or (ii) when the CAS does not receive any 
messages from a Client Application for a specified period of time 
(``n'' period of time) depending upon the API being used. Regardless of 
the API being used however, if an appropriate response message to a 
Heartbeat Request is not received by the CAS from the Client 
Application within a specified period of time (``x'' period of time or 
Heartbeat Response Time), the Technical Disconnect Mechanism is 
triggered and the Client Application is automatically logged off and, 
if applicable, a Market-Maker's quotes through that Client Application 
are automatically canceled.
    The Exchange notes that any non-connectivity is event- and Client 
Application-specific. Therefore, the cancellation of a Market-Maker's 
quotes entered into a CAS via a particular Client Application will 
neither impact nor determine the treatment of the quotes of the same or 
other Market-Makers entered into a CAS via a separate and distinct 
Client Application. The Technical Disconnect Mechanism will not impact 
or determine the treatment of orders previously entered into a CAS. As 
discussed above, the function of automatically cancelling a Market-
Maker's quotes posted through an affected Client Application is 
intended to help to mitigate the potential risks associated with a loss 
of communication with a Client Application. For example, in today's 
market, Market-Makers' quotes are rapidly changing and can have a 
lifespan of only milliseconds. Additionally, under the Hybrid Trading 
System, trades are automatically effected against the Market-Maker's 
then current quote. Therefore, if a TPH's Client Application is 
disconnected for any period of time, it is very possible that any 
quotes posted through that Client Application would be stale by the 
time the TPH reestablished connectivity. Consequently, any resulting 
execution of such quotes is more likely to be erroneous or unintended. 
Conversely, the Exchange notes that orders tend to be static in nature 
and often rest in the book. Indeed, certain order types, such as 
Market-on-Close orders, are intended to rest in the book for a period 
of time. As such, there is a lower risk of erroneous or unintended 
executions resulting from orders that remained in the Hybrid Trading 
System during and after an affected Client Application was logged off.
    The Exchange next notes that the CAS will send a logout message to 
an affected Client Application that confirms that the Client 
Application connection has been terminated. Once connectivity to the 
Client Application is reestablished, a Market-Maker affected by the 
mechanism is able to send messages to the CAS to reestablish the 
Market-Maker's quotes. Any Market-Maker affected by the Technical 
Disconnect Mechanism is not relieved of its obligation to provide 
continuous electronic quotes under the Exchange rules.\5\ The Exchange 
finally notes that

[[Page 46398]]

the Technical Disconnect Mechanism is enabled for all TPHs and may not 
be disabled by TPHs.
---------------------------------------------------------------------------

    \5\ With respect to a Market-Maker who is obligated to provide 
continuous electronic quotes on the Hybrid Trading System (``Hybrid 
Market-Maker''), CBOE Rule 1.1(ccc) Continuous Electronic Quotes 
provides that the Exchange may consider other exceptions to the 
Hybrid Market-Maker's continuous electronic quote obligation based 
on demonstrated legal or regulatory requirements or other mitigating 
circumstances. As provided in SR-CBOE-2005-93, Amendment 1 (See 
Securities Exchange Act Release No. 54250 (July 31, 2006), 71 FR 
44729 (August 7, 2006)), mitigating circumstances that may be 
considered by the Exchange may include, but is not limited to, 
instances where a technical failure or limitation in a Hybrid 
Market-Maker's system prevents the Hybrid Market-Maker from 
maintaining, or communicating to the Exchange, timely and accurate 
electronic quotes. However, a pattern or practice of technical 
failures or limitations, or the excessive frequency of technical 
failures or limitations, may also be considered by the Exchange in 
determining whether to except the period of time from the continuous 
electronic quoting requirements.
---------------------------------------------------------------------------

    The Exchange believes that while information relating to 
connectivity and the Technical Disconnect Mechanism are already 
available to TPHs via technical specifications, codifying this 
information within the rule text will provide additional transparency 
and further reduce potential confusion.
2. Statutory Basis
    The Exchange believes the proposed rule change is consistent with 
the Securities Exchange Act of 1934 (the ``Act'') and the rules and 
regulations thereunder applicable to the Exchange and, in particular, 
the requirements of Section 6(b) of the Act.\6\ Specifically, the 
Exchange believes the proposed rule change is consistent with the 
Section 6(b)(5) \7\ requirements that the rules of an exchange be 
designed to prevent fraudulent and manipulative acts and practices, to 
promote just and equitable principles of trade, to foster cooperation 
and coordination with persons engaged in regulating, clearing, 
settling, processing information with respect to, and facilitating 
transactions in securities, to remove impediments to and perfect the 
mechanism of a free and open market and a national market system, and, 
in general, to protect investors and the public interest.
---------------------------------------------------------------------------

    \6\ 15 U.S.C. 78f(b).
    \7\ 15 U.S.C. 78f(b)(5).
---------------------------------------------------------------------------

    In particular, the Exchange believes that codifying in the rules 
how the Technical Disconnect Mechanism works provides additional 
transparency in the rules and provides an additional avenue to easily 
understand CBOE's system and processes. The Exchange believes this will 
also reduce any potential confusion, thereby removing a potential 
impediment to and perfecting the mechanism for a free and open market 
and a national market system, and, in general, protecting investors and 
the public interest.
    Additionally, the Technical Disconnect Mechanism is a valuable tool 
that is designed to help maintain a fair and orderly market. The 
Exchange believe that the Technical Disconnect Mechanism assists with 
the maintenance of fair and orderly markets by helping to mitigate the 
potential risks associated with a loss in communication with a Client 
Application, especially risk associated with a loss in communication 
with a Client Application of a Market-Maker that is providing quotes 
across a multitude of series and classes.
    The Exchange also believes that the proposed rule change is 
designed to not permit unfair discrimination among market participants. 
The Exchange notes that the Technical Disconnect Mechanism automatic 
logoff function is applicable to all TPHs and may not be disabled by 
any TPH. The Exchange believes that the Technical Disconnect Mechanism 
benefits the marketplace because it designed to help alert a TPH to a 
potential technical or system issue and automatically logoff a TPH's 
Client Application within certain prescribed parameters. With respect 
to the Technical Disconnect Mechanism's automatic cancellation of 
Market-Maker quotes, the Exchange also believes it is not unfair to 
cancel only Market-Maker quotes and not orders. Particularly, the 
automatic cancellation of Market-Maker quotes benefits the marketplace 
because it is designed to help reduce the risk of stale quotes 
remaining on the CBOE Book in the event that a CAS loses connectivity 
with a Client Application (e.g., potentially resulting in erroneous or 
unintended executions). Furthermore, the functionality provides for the 
protection of Market-Makers, who must bear the burden of market risk 
for stale quotes, as well as for the protection of investors and the 
efficiency and fairness of the markets as a whole. Conversely, because 
orders tend to be static in nature and often rest in the book, the 
Exchange believes there is a lower risk of erroneous or unintended 
executions resulting from orders that remain in the Hybrid Trading 
System during and after an affected Client Application is logged off. 
The Exchange believes this functionality enhances the overall market 
quality for options traded on CBOE.

B. Self-Regulatory Organization's Statement on Burden on Competition

    CBOE does not believe that the proposed rule change will impose any 
burden on competition that is not necessary or appropriate in 
furtherance of the purposes of the Act. Specifically, the Exchange does 
not believe the proposed rule change will cause any burden on 
intramarket competition because it applies to all TPHs. Even though the 
functionality treats Market-Makers' quotes differently than orders, the 
Exchange notes again that it believes that the Technical Disconnect 
Mechanism benefits all market participants because it reduces the risk 
of stale quotes on the CBOE Book, which can result in erroneous or 
unintended trades. Further, the Exchange does not believe that such 
change will impose any burden on intermarket competition that is not 
necessary or appropriate in furtherance of the purposes of the Act. The 
Exchange notes that, should the proposed changes make CBOE more 
attractive for trading, market participants trading on other exchanges 
are welcome to become TPHs and trade at CBOE if they determine that 
this proposed rule change has made CBOE more attractive or favorable.

C. Self-Regulatory Organization's Statement on Comments on the Proposed 
Rule Change Received From Members, Participants, or Others

    The Exchange neither solicited nor received comments on the 
proposed rule change.

III. Date of Effectiveness of the Proposed Rule Change and Timing for 
Commission Action

    The foregoing rule change has become effective pursuant to Section 
19(b)(3)(A) of the Act \8\ and paragraph (f) of Rule 19b-4 \9\ 
thereunder. At any time within 60 days of the filing of the proposed 
rule change, the Commission summarily may temporarily suspend such rule 
change if it appears to the Commission that such action is necessary or 
appropriate in the public interest, for the protection of investors, or 
otherwise in furtherance of the purposes of the Act. If the Commission 
takes such action, the Commission will institute proceedings to 
determine whether the proposed rule change should be approved or 
disapproved.
---------------------------------------------------------------------------

    \8\ 15 U.S.C. 78s(b)(3)(A).
    \9\ 17 CFR 240.19b-4(f).
---------------------------------------------------------------------------

 IV. Solicitation of Comments

    Interested persons are invited to submit written data, views and 
arguments concerning the foregoing, including whether the proposed rule 
change is consistent with the Act. Comments may be submitted by any of 
the following methods:

Electronic Comments

     Use the Commission's Internet comment form (https://www.sec.gov/rules/sro.shtml); or
     Send an email to rule-comments@sec.gov. Please include 
File Number SR-CBOE-2013-071 on the subject line.

[[Page 46399]]

Paper Comments

     Send paper comments in triplicate to Elizabeth M. Murphy, 
Secretary, Securities and Exchange Commission, 100 F Street NE., 
Washington, DC 20549-1090.

All submissions should refer to File Number SR-CBOE-2013-071. This file 
number should be included on the subject line if email is used. To help 
the Commission process and review your comments more efficiently, 
please use only one method. The Commission will post all comments on 
the Commission's Internet Web site (https://www.sec.gov/rules/sro.shtml). Copies of the submission, all subsequent amendments, all 
written statements with respect to the proposed rule change that are 
filed with the Commission, and all written communications relating to 
the proposed rule change between the Commission and any person, other 
than those that may be withheld from the public in accordance with the 
provisions of 5 U.S.C. 552, will be available for Web site viewing and 
printing in the Commission's Public Reference Room, 100 F Street NE., 
Washington, DC 20549, on official business days between the hours of 
10:00 a.m. and 3:00 p.m. Copies of the filing also will be available 
for inspection and copying at the principal office of the Exchange. All 
comments received will be posted without change; the Commission does 
not edit personal identifying information from submissions. You should 
submit only information that you wish to make available publicly. All 
submissions should refer to File Number SR-CBOE-2013-071 and should be 
submitted on or before August 21, 2013.

    For the Commission, by the Division of Trading and Markets, 
pursuant to delegated authority.\10\
---------------------------------------------------------------------------

    \10\ 17 CFR 200.30-3(a)(12).
---------------------------------------------------------------------------

Kevin M. O'Neill,
Deputy Secretary.
[FR Doc. 2013-18347 Filed 7-30-13; 8:45 am]
BILLING CODE 8011-01-P
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.