[Federal Register Volume 78, Number 154 (Friday, August 9, 2013)]
[Notices]
[Pages 48738-48741]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2013-19258]


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

SECURITIES AND EXCHANGE COMMISSION

[Release No. 34-70112; File No. SR-C2-2013-029]


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

August 5, 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 29, 2013, C2 Options Exchange, Incorporated (the 
``Exchange'' or ``C2'') 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 
available on the Exchange's Web site (http://www.c2exchange.com/Legal/
), at the Exchange's Office of the Secretary, 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 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.

[[Page 48739]]

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 C2 Rules to codify a Technical 
Disconnect functionality which is designed to assist C2 Permit Holders 
(``Permit Holders'') in the event that they lose communication with a 
CBOE Application Server (``CAS'') due to a loss of connectivity between 
their designated C2 Client Application and a CAS.
    By way of background, C2 Permit Holders 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 
Permit Holder's custom trading application, through which a Permit 
Holder communicates its quotes and/or orders to a CAS,\3\ which sits 
between the Client Application and CBOE Command. 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 Permit Holder enters on 
the Exchange may be sent by the Permit Holders 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 Permit Holder'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 C2 Book). This 
serves to assist a Permit Holder when such a technical or system issue 
occurs, and also assist the Exchange in maintaining a fair and orderly 
market generally.
---------------------------------------------------------------------------

    \3\ C2 currently has numerous CASs serving Permit Holders.
---------------------------------------------------------------------------

    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 an 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 Permit 
Holder is using.\4\ Currently, the Exchange offers two APIs: CBOE 
Market Interface (``CMi'') API and Financial Information eXchange 
(``FIX'') Protocol. CMi currently has only one version available: CMi 
2. A Permit Holder 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 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 Permit Holder 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 
Permit Holder 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 Permit Holder 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 Permit Holder'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 Permit Holder 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 Permit Holder using FIX sets 
the value of ``n'' to 6 seconds, then the Permit Holder'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 2 when a Permit Holder chooses to 
have the CAS generate a Heartbeat Request every ``n'' period of time. 
For purposes of this example only, the Permit Holder will be a non-
Market-Maker and ``n'' will be set by the Permit Holder 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 System
    The following examples illustrate the manner in which the Technical 
Disconnect Mechanism functions on CMi 2 when a Permit Holder 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 Permit Holder will be a 
Market-Maker

[[Page 48740]]

and ``n'' will be set by the Permit Holder 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 a .5 
second
    --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 Permit Holder will be a Market-Maker and ``n'' will 
be set by the Permit Holder 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 System, trades 
are automatically affected against the Market-Maker's then current 
quote. Therefore, if a Permit Holder'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 Permit Holder 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 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 in accordance with the Exchange rules.\5\ 
The Exchange finally notes that the Technical Disconnect Mechanism is 
enabled for all Permit Holders and may not be disabled by Permit 
Holders.
---------------------------------------------------------------------------

    \5\ See C2 Rule 8.5, C2 Rule 8.13 and C2 Rule 8.17.
---------------------------------------------------------------------------

    The Exchange believes that while information relating to 
connectivity and the Technical Disconnect Mechanism are already 
available to Permit Holders 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. Additionally, 
the Exchange believes the proposed rule change is consistent with the 
Section 6(b)(5) \8\ requirement that the rules of an exchange not be 
designed to permit unfair discrimination between customers, issuers, 
brokers, or dealers. 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 C2'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 believes that 
the Technical Disconnect

[[Page 48741]]

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 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 Permit Holders and may not be disabled by any 
Permit Holder. The Exchange believes that the Technical Disconnect 
Mechanism benefits the marketplace because it is designed to help alert 
a Permit Holder to a potential technical or system issue and 
automatically logoff a Permit Holder'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 C2 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 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 and unintended executions resulting from orders that remain 
in the 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 C2.
---------------------------------------------------------------------------

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

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

    C2 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 Permit Holders. 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 C2 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 C2 more 
attractive for trading, market participants trading on other exchanges 
are welcome to become Permit Holders and trade at C2 if they determine 
that this proposed rule change has made C2 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 \9\ and paragraph (f) of Rule 19b-4 \10\ 
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.
---------------------------------------------------------------------------

    \9\ 15 U.S.C. 78s(b)(3)(A).
    \10\ 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 (http://www.sec.gov/rules/sro.shtml); or
     Send an email to [email protected]. Please include 
File Number SR-C2-2013-029 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-C2-2013-029. 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 (http://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-C2-2013-029 and should be 
submitted on or before August 30, 2013.

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

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

Kevin M. O'Neill,
Deputy Secretary.
[FR Doc. 2013-19258 Filed 8-8-13; 8:45 am]
BILLING CODE 8011-01-P