BM&FBOVESPA Electronic Link (BELL) Financial Information exchange (FIX) Rules of Engagement. Derivatives FX

Transcription

1 BM&FBOVESPA S.A. Securities, Commodities and Futures Exchange BM&FBOVESPA Electronic Link (BELL) Financial Information exchange (FIX) Rules of Engagement Derivatives FX Version 3.0.9

2 Contacts To request copies of this document, please contact: Centro de Controle BM&FBOVESPA (BM&FBOVESPA Control Center) (São Paulo) Or BELL Rules of Engagement Page 2

3 Index FIGURE INDEX PREFACE Introduction Abbreviations Glossary NETWORK CONNECTIVITY TO BELL Physical/Link Layer Options RCCF Internet via VPN Direct Leased Line or Service Provider Network Setup for Distributors Network Setup for Brokerage Firms/Banks Data Encryption Throttle COUNTERPARTY IDENTIFICATION FIX Comp IDs FIX Session Assignment CERTIFICATION Certification Network Setup Certification Segments Market Data Certification Order Management BELL FAULT TOLERANCE Distributed Data Centers Clustered Services STANDARD HEADER/TRAILER Standard Header Standard Trailer MESSAGE SUMMARY Summary of Session Messages Summary of Application Messages SESSION MESSAGES Logon (MsgType = A) Heartbeat (MsgType = 0) Test Request (MsgType = 1) Resend Request (MsgType = 2) Reject (MsgType = 3) Sequence Reset (MsgType = 4) Logout (MsgType = 5) FX/DERIVATIVES TRADING Trading Hours/Sessions Connection Times Trading Sessions and Phases Trading Phase and Security Status Supported Trading Phases at BM&FBOVESPA FIX Version Message Flows Derivatives FX (Foreign Exchange) Application Level Messages Instrument Identification Block BELL Rules of Engagement Page 3

4 Document Owner BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department Security Definition Security List Request (MsgType = x) Security List (MsgType = y) Order Management New Order Single (MsgType = D) New Order Cross (MsgType = s) Order Cancel Request ( MsgType = F ) Order Cancel Reject ( MsgType = 9 ) Order Cancel Replace Request (MsgType = G) Execution Report ( MsgType = 8 ) Market Data Book depths available Market Data Request (MsgType = V) Market Data Request Reject (MsgType = Y) Market Data Snapshot/Full Refresh (MsgType = W) Market Data Incremental Refresh (MsgType = X) Security Status (MsgType = f) Event Communication News (MsgType = B) General Business Message Reject ( MsgType = j ) Post Trading Position Maintenance Request (MsgType = AL) Position Maintenance Report (MsgType = AM) Order Types Supported Limit Orders Stop Limit Orders Market with Leftover as Limit Order Validity Types (Time in Force) Supported Day Orders IOC (FAK) Orders FOK Orders Trading on Behalf Trade Give-ups Program Trading, Foreign Investors and DMA Clients DMA Identification Account Allocation Restrictions for DMA Customers New Order Cross Execution Rules at BM&FBOVESPA Immediate Execution of Crossed Order Crossed Order Legs that Execute Against Existing Orders Auction Triggered by Crossed Order In-flight Modification and Interpretation of the OrderQty Field Trade Cancellations (Trade Busts) Order Identification Order Execution Rules at BM&FBOVESPA Application Message Scenarios Security Definition Security List Request with One Message Returned Security List Request with Updates Security List Request without Updates Security List Request with Updates after Specified Timestamp Start of Day Security List Request with More than One Message Returned Order Management Order Entry, Partial Fill and Complete Fill Order Cancellation by ClOrdID Order Cancellation by OrderID Order Cancellation Attempt of Filled Order Order Modification BELL Rules of Engagement Page 4

5 Document Owner BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department Market Data Successful Subscription Request + Updates Successful Subscription plus Book Updates Failed Subscription Request (Invalid Security ID) Trade Cancellation (Trade Bust) APPENDIX Error Messages for Rejected Orders in Tag 58 (Text) Securities Clearing House (Fixed Income) Trade Type Dates of Brazilian Public Bonds BELL Rules of Engagement Page 5

6 Document Owner Figure Index BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department Figure 1 - BM&FBOVESPA-Distributors network setup Figure 2 - BM&FBOVESPA-brokerage firms/banks network setup Figure 3 - Trading day(trading session) and trading phases Figure 4 - Derivatives Clearinghouse message flow Figure 5 - FX Clearing House message flow Figure 6 - Order lifecycle state diagram Figure 7 - Security List Request responded with only one Security List message Figure 8 - Security List Request with updates Figure 9 - Security List Request without subscription to further updates Figure 10 - Security List Request for securities added/modified after specified timestamp Figure 11 - Security List Request responded with more than one Security List message Figure 12 - Order Entry with partial and total fill Figure 13 - Order cancellation using ClOrdID Figure 14 - Order cancellation by OrderID Figure 15 - Attempt to cancel a filled order Figure 16 - Order modification scenario - OrderID is kept for modified order Figure 17 - Market data subscription, full update and incremental refresh for partial execution and cancellation Figure 18 - Book snapshot plus updates with MDPositionNo changes Figure 19 - Market Data Reject due to invalid security ID Figure 20 - Trade cancellation BELL Rules of Engagement Page 6

7 Change log Date Version Description Author For the Derivatives/FX section: - Included Account field in the Order Cancel Reject message - NewOrderCross: corrected the TradeAllocIndicator position (now Inside the NoSides repeating group) - Updated data type of tag AllocAccount July 29th Added security sub type domains (field SecuritySubType) TAT - Added item 2.5 (Throttle) - Added business rejection reason 99 to tag 380 on Business Message Reject (type j) For the Fixed Income Tradin section: - Removed session For the Derivatives/FX section: - Corrected tag 6940 (NewsSource) type and domain - Added Post Trading messages section (9.4.7) December - Added Position Maintenace Request ( ) and Position th 2008 Maintenance Report ( ) messages AG - NewOrderCross: corrected the TradeAllocIndicator position (now Inside the NoSides repeating group) - Corrected OrderRestriction field type November 14th For the Derivatives/FX section: - Corrected tag 762 description - Corrected IOC(FAK) order behavior description - Corrected tag 423 description - Corrected order of tags in the ReferentialPrices repeating group - Corrected tag 560 description - Corrected tag 40 description for the Execution Report message - Added new criteria in the Security List Request message (tag 559) - Added tag 19 (ExecRefId) information to the Execution Report message - Added tag 925 (NewPassword) to the Logon message, and explanation on how to change the password - Added description to the Market Data Request mechanism, indicating that a subscription by a group of instruments may receive individual instrument rejections (section Expected Market Data Request Responses ) - Changed connection times description to avoid confusion (9.1.1) - Removed tag 797 from the Execution Report message - Added product 14 Carbon Credits to tag Updated contact information to centrodecontrole@bmf.com.br and servicos@bmfbovespa.com.br. - Added note on sequence number reset in the Logon session. August 7th For the Derivatives/FX section: JML JML BELL Rules of Engagement Page 7

8 Removed the MDEntryID references in the market data section to avoid confusion on book management - Added account information (NoAccount repeating group) to the modification message, and made note about account reallocation restriction (section ) - Explained the subscription by CFICode, SecurityType and Product using the Market Data Request message (section ), with examples - Removal of Order Mass Cancel Request/Response and Order Mass Status Request sections, and their related tags in the Execution Report - Corrected the OrderID field description in the Market Data Snapshot and Incremental messages (for FX) - Added section on DMA account allocation restrictions (9.9.2) - Added value D (restated) to the ExecType field (tag 150) and added field ExecRestatementReason (tag 378) to the Execution Report message ( ) - Added section on supported order validities (9.6) - Updated in-flight modification scenario, to reflect order expiration when order quantity < filled quantity (section 9.11) - Added description of tags LastQty and LastPrice for the trade bust Execution Report in section 9.12 For the Derivatives/FX section: - Inserted reference to list of BM&FBOVESPA broker firm codes in section 9.9, made DMA requirements more explicit - Removed tag QuoteCondition from Market Data messages - Removed the Order Status Request message section (not supported) - Removed information on the bipartite link number for giveups in section 9.8, and substituted it by give-up link number, as well as correction to the example - Few cosmetic changes throughout the document July 3rd Changed the PositionEffect and TradeAllocIndicator fields description - Changed the Symbol tag description - Added new audience and source for the News message (section ) - Added more information on order type validation rules (section 9.5) - Removed tags MinQty and StopPx from the Order Cancel Replace Request message (section ) JML Jun 6th For the Derivatives/FX section: - Added MarketDepth field to the Market Data Snapshot message, indicating the depth of the aggregate book (section ) - Added support to instrument group code and product in the Security List message (section ) - Added new PartyRole: 54 (Sender Location ID), needed for DMA and order routing solutions, for New Order Single, Order Cancel Request, Order Cancel Replace Request and Execution Report messages - Added Mini-batch trading phase description to section JML BELL Rules of Engagement Page 8

9 Mar 11th , expanding the domain of tag TradingSessionSubID. - Added tag DeleteReason (285) to the Market Data Incremental Refresh message (section ) - Added the Parties component block to the Order Cancel Reject message (section ) - Removed the Market, Market If Touched and Stop orders from the specification (section and other various sections) - Removed the GTC time in force - Added section on order execution rules (section 9.14) - Changed description on how News messages are sent (section ) - Changed GTS site to - Changed description of tag OrderID in section Various cosmetic changes - Fixed OrderRestrictions field domain for foreign entities (section 9.9) - Added DMA identification sub-section (9.9.1) - Added Side and Instrument block information to the Order Cancel Reject message (section ) - Corrected the LeavesQty field description in Execution Report messages - Fixed the description of the Order Cancel Replace Message removed the modification of MinQty and stop orders (section ) - Added fields to the referential price market data description (in sections and ) to let customers know these fields are sent but need to be ignored. For the Derivatives/FX section: - Created section to explain trade cancellations - Created section to explain supported order types - Added section on Order Identification and Order book crossreferencing - Added underlying instrument information, instrument legs and price type (tag PriceType) to the Security List message - Included OrigSecondaryOrderID field in the Order Cancel Replace Request message - Included OrigOrdQty field in the Execution Report message - Included field CopyMsgIndicator field in the Execution Report message - Fixed the order lifecycle diagram on section 9.4.3, to remove the transition from New to Rejected - Fixed referential prices domain (field ReferentialPxType) - Corrected cross order scenario table on section Changed the MDEntryType values for aggregate bid and aggregate offer to e and f, respectively - Added Entering Firm PartyRole - Fixed description of field MaturityDate and MaturityMonthYear, and added field SecurityValidityTimestamp to the SecurityList message to indicate the last eligible trade timestamp - Added length limitations on specific string fields - Added End of Consultation trading phase to section JML BELL Rules of Engagement Page 9

10 Feb 18th Dec 4th For the Derivatives/FX section: - Inserted text explaining the return of an empty set to the Security List Request message (section ) - Updated the contact list for Comp ID assignment (section 3.2) - Added the term Correspondent Broker to the glossary - Added PartyRole Correspondent Broker, Clearing Firm and Customer Account to New Order Single, Modification and Cancel Request messages - Added the section of Order Entry Certification process (section 4.2.2) - Added section on fault tolerance (section 5) - Added tags and information on the price-depth book (formerly only order-depth book was available) section Corrected the Book Management Considerations section in regards to MDUpdateAction = Change (section ) - Corrected the Contacts section - Remove the expire date and minimum quantity information from bid/offer market data entries (sections and ) - Corrected the definition of field MDEntryPx (sections and ) for trade volume (notional) - Corrected the definition of field UniqueTradeID (unique per instrument per trading date) - Removed description of unsupported time in force values: at the opening, at the close, GTX, GTD (sections and ) - Updated the description of tag ExecID (unique per instrument) - Corrected the data type of tag SecurityTradingStatus to Int (formerly String) in sections and Added section 9.8, on give up specification in order messages. - Added field OrderRestrictions (tag # 529) to indicate order origin information (program trading, foreign investor, etc) - sections , and Added field QuoteCondition to the market data incremental and snapshot messages (sections and ) to provide support for implied prices. - Reshuffled a few chapters (Trading On Behalf, In-flight Modification, New Order Cross Rules at BM&FBOVESPA) - Removed TradingSessionID from Execution Report message (section ) - Performed various corrections/additions to the SecurityList message (section ). - First version of consolidated specification (Derivatives , FX and Fixed Income 1.0.7) - Included section on supported trading phases their capabilities ( ) - Updated the description of fields TradingSessionID and TradingSessionSubID in sections and Added field CFICode to the SecurityListRequest message JML JML BELL Rules of Engagement Page 10

11 Document Owner BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department (section ) - Added fields TickSizeDenominator and InstrumentId to the SecurityList message (section ) - Enhanced the text on the Certification section (4) - Added section FIX Comp ID assignment (3.2) - Updated description of fields SenderCompID and TargetCompID in section Standard Header (6.1) - Added more connectivity details to the Network Connectivity section (2) - Updated description of tag 58 (Text) in the Order Mass Cancel Report message - Added more values to tag BTSFinalTxOrdStatus in the Execution Report message ( ) - Added Transfer to Firm PartyID for giveup trades - Added giveup term to the glossary BELL Rules of Engagement Page 11

12 1 Preface Document Owner 1.1 Introduction BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department BM&FBOVESPA provides a trading interface based on the Financial Information exchange ("FIX") Protocol. This interface is nicknamed BELL (BM&FBOVESPA Electronic Link). FIX is a technical specification for electronic communication of trade-related messages. It is an open standard managed by members of FIX Protocol Limited ( This document outlines BM&FBOVESPA FIX implementation and is provided for third-parties which need trading connectivity through BELL. It is assumed that the reader of this document has knowledge of the basic functioning of the FIX protocol. 1.2 Abbreviations Abbreviation FIX IP SSL TCP BELL 1.3 Glossary Term BM&FBOVESPA Electronic Link BM&FBOVESPA Broker Brokerage Correspondent Broker Counterparty Derivatives DMA Entering Firm Entering Trader Description Financial Information Exchange Protocol Internet Protocol Secure Socket Layer Transport Control Protocol BM&FBOVESPA Electronic Link Definition BM&FBOVESPA s solution for accessing its electronic trading platform Securities, Commodities and Futures Exchange, based in São Paulo, Brazil. For more information, visit A broker is an individual or firm who acts as an intermediary between a buyer and seller, usually charging a commission. Used interchangeably with broker when referring to a firm rather than an individual. Also called brokerage house or brokerage firm. Identifies a correspondent broker (broker/firm which originates the order to BM&FBOVESPA from a DMA provider or order routing solution). Party to a trade. A financial security (such as option or future) whose characteristics and value are derived from the characteristics and the value of another asset. Direct Market Access functionality that allows end-customers, such as hedge funds or investment banks, to directly access the exchange electronically without the need to go over physical broker firm infrastructure. Broker who has recorded or reported an execution. This term is particularly useful where the trade is entered into a trading system by a broker who is not a party to the trade, as it allows any inquiries or problem resolution to be directed to the appropriate source. Individual usually identified by a trading badge number or initials that actually enters an order to a market (especially in open outcry markets). Usually the Entering Trader is the same as the Executing BELL Rules of Engagement Page 12

13 Term Executing Firm Executing Trader FIX Gateway Futures Give-up firm Instrument Issuer Market Data Matching Order Origination Firm Order Gateway Security SISBEX Vendor Definition Trader. However, under some circumstances the Entering Trader will have the trade executed by another trader who is then identified as the Executing Trader. Identifies executing / give-up broker. Trader or broker id associated with Executing Firm who actually executes the trade. Service that provides connectivity to third-party clients and brokerages using the FIX protocol. Contracts covering the sale of financial instruments or physical commodities for future delivery on a commodity exchange. Firm to which a trade is given up, i.e. firm which carries the trade. Financial capital in a readily tradable form. An entity that puts a financial asset in the marketplace. A collective term for quotes, last sales, volume statistics and other information used by the market to evaluate trading opportunities. The process by which two counter-parties that have engaged in a trade compare the settlement details of the trade provided by both. Matching is done to verify all aspects of a trade and ensure that all parties agree on the terms of the transaction. Firm which originates the order. The service provided by BM&FBOVESPA which relays FIX messages from a third-party client, usually a vendor, to the SISBEX system. A stock, bond or contract that has been authorized for trading on, and by, a registered exchange. Each exchange has different criteria to determine a security's eligibility for listing. The system used by BM&FBOVESPA to negotiate public bonds. Institution that sells services to its clients. In the context of this document, a vendor is an institution that sells access to market data feeds and order management interfaces to an Exchange. BELL Rules of Engagement Page 13

14 2 Network Connectivity to BELL BM&FBOVESPA offers network connectivity via: RCCF Internet via VPN Direct leased line or service provider These options are discussed in detail in the following sections. 2.1 Physical/Link Layer Options RCCF RCCF ( Rede de Comunicações da Comunidade Financeira, or Financial Community Communications Network) is an MPLS network that connects all brokerage firms to BM&FBOVESPA, as well as some distributors and other interested clients. This network allows for specific SLAs and contingency features. It is typically used to receive market data and transactional messages (order management) Internet via VPN Clients may also connect to BM&FBOVESPA via the Internet implementing a VPN tunnel, which reduces cost but does not provide contingency and SLA. BM&FBOVESPA supports VPN both via software and hardware. This type of connection may be used for the certification process of all trading features, including market data, order management and order routing, even though in the production environment connectivity will be via RCCF or direct leased line Direct Leased Line or Service Provider Clients may contract a direct leased line or utilize a service provider to connect to BM&FBOVESPA with a dedicated link. This option may include contingency features and SLA. Contact BM&FBOVESPA for details on setting up this type of connectivity. It may be used to receive market data as well as transferring of transactional messages. 2.2 Network Setup for Distributors Distributors (vendors, ISVs or service providers) may connect to BM&FBOVESPA to receive market data and to route orders to the BM&FBOVESPA broker community. This connection may be established upon previous business agreement with BM&FBOVESPA, and the SLA is dependent on the type of information to be transferred over the network. The following diagram illustrates the possible setups for the network: BELL Rules of Engagement Page 14

15 End client MPLS End client Distribution Network RCCF FIX Gateway End client Distributor site End client End client End client Distribution Network FIX Gateway Distributor site Internet VPN tunnel (Hardware or Software) FIX Gateway Market data/ order routing Order routing BM&F Trading Platform End client End client Distribution Network FIX Gateway Dedicated link (leased line or service provider) BM&F data center End client Distributor site Broker community Figure 1 - BM&FBOVESPA-Distributors network setup 2.3 Network Setup for Brokerage Firms/Banks Brokerage firms and banks with trading rights at BM&FBOVESPA may connect to receive market data and orders routed from clients (for brokerage firms only), as well as issue their own orders according to previous business agreement with BM&FBOVESPA. This connection may be established via RCCF or a direct leased line. The following figure illustrates this setup: BELL Rules of Engagement Page 15

16 Trader MPLS Trader Trader Trader Trader Firm LAN Firm LAN Hub Hub FIX Gateway FIX Gateway Firm site RCCF Dedicated link (leased line or service provider) FIX Gateway Market data/ order entry BM&F Trading Platform Algorithmic trading server Firm site BM&F data center 2.4 Data Encryption Figure 2 - BM&FBOVESPA-brokerage firms/banks network setup BM&FBOVESPA does not support built-in FIX encryption. Security of the connection is provided by the lower layers (MPLS in the case of RCCF, VPN in the case of Internet) and physical isolation for dedicated links. BM&FBOVESPA market surveillance also performs audits in case there is the suspicion of illegal connection procedures. 2.5 Throttle The throttling mechanism controls the flow of messages at the FIX session level and was implemented to regulate the number of messages sent to BM&FBOVESPA in order to optimize performance. The throttling parameter is specified in messages per second and different actions are taken should the throttle parameter be exceeded (queue or reject). So, two parameters must be set: the maximum amount of messages which defines the maximum number of messages that will be processed by the FIX Gateway per second; and the reject / non-reject exceeded messages defines if the exceeded messages must be rejected or queued. If a message exceeds the maximum rate set, it can be rejected or queued. In case of rejection, a "Business Message Reject" error message will be sent with BusinessRejectReason = Throttle limit exceeded. Client systems can cross-reference the business message reject message with the originating message that was throttled by verifying the content of tag 45 (RefSeqNum). This tag will containg the FIX session level sequence number (tag 34) of the message that was rejected. If non-reject is set, the throttle mechanism will withhold the messages exceeded until the end of the second, in this case, a higher latency would be observed in the response. Assuming a scenario in which the limit is set to 50 messages per second. The first period of time begins when the gateway receives the first message and if more than 50 messages are sent before the next second, they are throttled. Throttling parameters are configured by the CCB (BM&FBOVESPA Control Center) and are activated at the CCB s discretion, or upon customer request. BELL Rules of Engagement Page 16

17 3 Counterparty Identification 3.1 FIX Comp IDs FIX connections are established based on comp IDs fields that identify, on the session level, the counterparty in the connection. These IDs do not convey trader or firm information. They are used only on the FIX session level. As per the FIX specification: SenderCompID OnBehalfOfCompID TargetCompID DeliverToCompID A sends directly to B A B B sends directly to A B A BM&FBOVESPA may support under request order routing solutions, i.e. hub-to-hub topology. In this case, the BM&FBOVESPA identification code must be specified in the DeliverToCompID (128) field of all messages being sent to BM&FBOVESPA via the third party. BM&FBOVESPA identification code will be contained in the OnBehalfOfCompID (115) field of any message sent from BM&FBOVESPA to the connected counterparty. SenderCompID OnBehalfOfCompID TargetCompID DeliverToCompID Send from A to C via B A sends to B A B C B sends to C B A C C responds to A via B C sends to B C B A B sends to A B C A 3.2 FIX Session Assignment FIX comp IDs and IP addresses for connection are assigned by BM&FBOVESPA to connecting counterparties. The process is differentiated according to the counterparty category (banks, trading firms, DMA providers, vendors, other exchanges). For more details, please contact the BM&FBOVESPA CCB: BM&FBOVESPA Control Center (São Paulo) centrodecontrole@bmf.com.br BELL Rules of Engagement Page 17

18 4 Certification Before connecting to BM&FBOVESPA, the counterparty must undergo the certification process according to the activity it will perform. There are three certification segments at BM&FBOVESPA: Market data: for receiving BM&FBOVESPA s market data, typically vendors and firms; or Order management: for trading at BM&FBOVESPA through order entry and management (typically firms); or Each of these segments contains its own certification process which is described in detail in separate documents (see the following sections and the BM&FBOVESPA website at If you want to start a certification process with BM&FBOVESPA, please contact the BM&FBOVESPA Testing and Certification Center at ctc@bvmf.com.br, or the BM&FBOVESPA customer service center at bvmfsolution@bvmf.com.br. 4.1 Certification Network Setup The network setup is similar for all three segments, since connectivity will be provided via a Certification FIX Gateway. The physical link used for certification may vary from the one to be used in production, since it is the application that is being certified, and not the physical layer. Hence, a client application which will run using RCCF or a dedicated link in the production environment may be certified through an Internet VPN connection. 4.2 Certification Segments Market Data Certification Market data certification consists of receiving a mass of market data from BM&FBOVESPA simulating different book management scenarios, trade scenarios, start/end of day scenarios and trading session changes. A few scenarios that are specific to settlement prices and other special cases will also be tested. The Certification FIX Gateway provides: A test feed of BM&FBOVESPA s market data for specific instruments. This data is a replay of a production day for the purposes of testing by the counterparties. The recipient of these messages must not take any trading-related decisions based on the information that comes from this feed; At specified timeslots, the gateway will issue the messages that correspond to a certification test case. Once the counterparty feels comfortable to start the certification procedure, it should notify BM&FBOVESPA of its intent to start the process. A copy of the market data certification document, containing all the scenarios will be followed by an assigned tester at BM&FBOVESPA, and all logs must be kept as evidence of passing each test case Order Management The procedure for certifying order management (order entry) connections is the same as the one for market data. The counterpart will connect to a certification FIX gateway, and will follow the BELL Rules of Engagement Page 18

19 Document Owner BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department BM&FBOVESPA s certification document for order entry, which is provided upon request to BM&FBOVESPA. The counterpart will perform a series of tests that are pre-specified by BM&FBOVESPA, and its outcome will be used as evidence of passing certification. 5 BELL Fault Tolerance When connecting to the BM&FBOVESPA trading system, BM&FBOVESPA provides fault tolerance facilities to its customers in the form distributed data centers and clustered services. 5.1 Distributed Data Centers BM&FBOVESPA maintains two data centers that are geographically dispersed and provide fault tolerance in case of physical occurrences. These data centers are named CT1 and CT2. If a problem occurs on CT1 that prevents trading from happening, the appropriate applications will be failed over to CT Clustered Services All components of the BM&FBOVESPA trading system are allocated in clusters, which in case of hardware failure fail over to the backup device. These components are on a cluster group with an activepassive configuration the primary component is running, while the backup component is idle. In case of a failure, the backup component takes over. Failovers of backend components of BM&FBOVESPA s trading platform should be transparent to the connected customers. If the FIX gateway fails over, however, it will have an impact on the connected customer. In this case, the FIX gateways are running in a cluster group on CT1 and another on CT2 (totaling four instances), and when the primary fails, the backup FIX gateway takes over the connection. The FIX sequence numbers are shared among FIX gateways in the same cluster group. That being, if a failover occurs for two FIX gateways in the same BM&FBOVESPA data center, the customer should expect a Logout message from BM&FBOVESPA, immediately followed by a Logon message. Since the sequence numbers are still the same as from the previous connection, the resynchronization of the sequence numbers should be kept to a minimum. In case of a more serious failure, and a failover to CT2 is required, the expected inbound and outbound sequence numbers are maintained. If a warm startup of GTS is performed, there is no need for the customer to reset its sequence number or clear its OMS. BM&FBOVESPA market surveillance will cancel all orders upon its discretion and the Execution Reports will be sent through the appropriate FIX sessions. BELL Rules of Engagement Page 19

20 6 Standard Header/Trailer 6.1 Standard Header All messages, in both directions, must be initiated with the FIX standard header. Tag Tag name Req d Data type Comment 8 BeginString Y String FIX BodyLength Y Int (Always unencrypted, must be second field in message) 35 MsgType Y String (Always unencrypted, must be third field in message) 34 MsgSeqNum Y Int 43 PossDupFlag N Boolean 49 SenderCompID Y String 56 TargetCompID Y String 115 OnBehalfOfCompID N String 128 DeliverToCompID N String 52 SendingTime Y UTCTimestamp 97 PossResend N Boolean 6.2 Standard Trailer All messages, in both directions, must end with the FIX standard trailer. Please contact BM&FBOVESPA for appropriate CompID assignment (see section 3.2). Please contact BM&FBOVESPA for appropriate CompID assignment (see section 3.2). For messages sent by BM&FBOVESPA = Client s Brokerage firm ID (if any); For messages received by BM&FBOVESPA = Client s Trading partner ID (if any). For messages sent by BM&FBOVESPA = Client s trading partner ID (if any); For messages received by BM&FBOVESPA = Client s Brokerage firm ID (if any). Expressed in UTC (Universal Time Coordinated), also known as GMT. Tag Tag name Req d Data type Comment 10 CheckSum Y Int (Always unencrypted, always last field in message) BELL Rules of Engagement Page 20

21 7 Message Summary 7.1 Summary of Session Messages The following table summarizes the session messages supported by BM&FBOVESPA:. Derivatives/FX Trading Message FIX MsgType Sent by BM&FBOVESPA Received by BM&FBOVESPA Logon A X X Heartbeat 0 X X Test Request 1 X X Resend Request 2 X X Reject 3 X X Sequence Reset 4 X X Logout 5 X X 7.2 Summary of Application Messages The follow table summarizes the application messages supported by BM&FBOVESPA. Derivatives/FX Trading Message FIX MsgType Sent by BM&FBOVESPA Received by BM&FBOVESPA Execution Report 8 X Order Cancel Reject 9 X New Order Single D X New Order Cross s X News B X Order Cancel Request F X Order Cancel Replace G X Request Business Message Reject j X X Security List Request x X Security List y X Market Data Request V X Market Data Request Y X Reject Market Data Snapshot W X Full Refresh Market Data Incremental X X Refresh Position Maintenace AL X Request Position Maintenace Report AM X Any unsupported messages that are received by BM&FBOVESPA will be rejected with a Business Message Reject message, with tag BusinessRejectReason (380) = 3 (unsupported message type). BELL Rules of Engagement Page 21

22 8 Session Messages This section details the session management messages used by BM&FBOVESPA. 8.1 Logon (MsgType = A) The FIX Logon message (A) authenticates a user establishing a connection to a remote system. The Logon (A) message must be the first message sent by the application requesting to initiate a FIX session. Note: if the client wishes to change its password (sent in tag 95), it may do so by sending tag 925 with the new password. Tag Tag name Req d Data type Comment [ Standard message header ] 98 EncryptedMethod Y Int Must be HeartBtInt Y Int Recommended: ResetSeqNumFlag N Boolean 789 NextExpectedMsgSeqNum N Int 464 TestMessageIndicator N Boolean Sent only by BM&FBOVESPA 95 RawDataLength N Length Required when this message contains authentication data. For more details on authentication data in Logon messages, please contact BM&FBOVESPA. 96 RawData N Data Required when this message contains authentication data. For more details on authentication data in Logon messages, please contact BM&FBOVESPA. 925 NewPassword N String Only sent from the client to BM&FBOVESPA. Allows the client to change its password. [ Standard message trailer ] BM&FBOVESPA strongly advises counterparties to not reset their IMPORTANT sequence numbers on logon (tag 141=Y) in FIX sessions where transactional messages (order entry) are sent. In case of a disconnection, if the customer resets its sequence number on logon, it will probably lose messages that convey order state information (Execution Reports), risking having them in a stale state. For market data sessions, resetting the sequence numbers on logon is desirable. 8.2 Heartbeat (MsgType = 0) The Heartbeat (0) monitors the status of the communication link and identifies when the last of a string of messages was not received. Tag Tag name Req d Data type 112 TestReqID N String Comment [ Standard message header ] Required when the heartbeat is the result of a Test Request message. BELL Rules of Engagement Page 22

23 Tag Tag name Req d Data type [ Standard message trailer ] Comment 8.3 Test Request (MsgType = 1) The FIX Test Request (1) message requests a heartbeat from the counterparty. The Test Request message checks sequence numbers or verifies the communication line status. The opposite application responds to the Test Request with a Heartbeat (MsgType = 0) message, echoing the TestReqID (112) tag contained in the request. Tag Tag name Req d Data type 112 TestReqID Y String 8.4 Resend Request (MsgType = 2) Comment [ Standard message header ] Identifier included in Test Request message to be returned in resulting Heartbeat [ Standard message trailer ] The resend request is sent by the receiving application to initiate message retransmission. This function is used if a gap in sequence numbers is detected, if the receiving application lost a message, or as a part of the initialization process. Tag Tag name Req d Data type Comment [ Standard message header ] 7 BeginSeqNo Y Int Message sequence number of first message in range to be resent 16 EndSeqNo Y Int Message sequence number of last message in range to be resent. If request is for a single message BeginSeqNo = EndSeqNo. If request is for all messages subsequent to a particular message, EndSeqNo = "0" (representing infinity). [ Standard message trailer ] 8.5 Reject (MsgType = 3) The FIX Reject (3) message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. Tag Tag name Req d Data type Comment [ Standard message header ] 45 RefSeqNum Y Int MsgSeqNum of rejected message 371 RefTagID N Int The tag number of the FIX field being referenced. 372 RefMsgType N String The MsgType of the FIX message being referenced. 373 SessionRejectReason Y Int Code to identify reason for a session-level Reject message. Values issued by BM&FBOVESPA: 0 = Invalid tag number 1 = Required tag missing 2 = Tag not defined for this message type 3 = Undefined Tag 4 = Tag specified without a value 5 = Value is incorrect (out of range) for this tag BELL Rules of Engagement Page 23

24 Document Owner Tag Tag name Req d Data type 58 Text N String BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department Comment 6 = Incorrect data format for value 9 = CompID problem 10 = SendingTime accuracy problem 11 = Invalid MsgType 13 = Tag appears more than once 14 = Tag specified out of required order 15 = Repeating group fields out of order 16 = Incorrect NumInGroup count for repeating group 17 = Non "data" value includes field delimiter (SOH character) 99 = Other Where possible, message to explain reason for rejection. [ Standard message trailer ] 8.6 Sequence Reset (MsgType = 4) The Sequence Reset (4) message has two modes: Gap Fill mode and Reset mode. Gap Fill mode is used in response to a FIX Resend Request (2) when one or more messages must be skipped. Reset mode involves specifying an arbitrarily higher new sequence number to be expected by the receiver of the FIX Sequence Reset (4) message, and is used to reestablish a FIX session after an unrecoverable application failure. Tag Tag name Req d Data type 123 GapFillFlag N Boolean 36 NewSeqNo Y Int New sequence number. [ Standard message trailer ] 8.7 Logout (MsgType = 5) Comment [ Standard message header ] Indicates that the Sequence Reset message is replacing administrative or application messages which will not be resent. Valid values: Y = Gap Fill message, MsgSeqNum field valid N = Sequence Reset, ignore MsgSeqNum The FIX Logout (5) message initiates or confirms the termination of a FIX session. Disconnection without the exchange of Logout messages should be interpreted as an abnormal condition. Tag Tag name Req d Data type Comment [ Standard message header ] 58 Text N String Explanation for Logout reason (if any). [ Standard message trailer ] BELL Rules of Engagement Page 24

25 9 FX/Derivatives Trading 9.1 Trading Hours/Sessions Connection Times BM&FBOVESPA may establish specific FIX connection times for each client, exchange or DMA provider. Please contact BM&FBOVESPA CCB at for more details Trading Sessions and Phases A trading day is the basis for defining a division of time for trading a security at BM&FBOVESPA. At BM&FBOVESPA, a trading session is the same as a trading day. During a single trading day, time is divided in trading phases. Each phase has a start time and special characteristics that identify the behaviour of the market for the security (or list of securities) that is in that phase. The start of one trading phase marks the end of the previous one. A single trading phase acts as a time label for a slice of the trading day. In other words, a set of business trading rules (if an order can be entered, modified or deleted, the limits for trading the security, etc) may be set to a specific trading phase. Examples of trading phases include: Pre-opening (Auction) No-cancel order Opening (Auction Matching) Continuous Trading Surveillance Intervention Market Closing There may be one or more calendar days during the same trading day (or trading session). The following picture illustrates this division: Trading day Calendar day Calendar day Start of Day Consultation Intervention Before Opening (...) Mini-batch Start of Day Consultation No-cancel (...) Trading phase Figure 3 - Trading day(trading session) and trading phases. Trading phase definitions and timetable will be sent to connected counterparties via FIX messaging in later releases. Currently, this information is available from the BM&FBOVESPA website. BELL Rules of Engagement Page 25

26 Document Owner Trading Phase and Security Status BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department Both trading phase and security might have different status during a trading day: for instance, in a given trading day, the trading phase could be in continuous trading mode when an order is received by the match engine. At this moment the match engine determines that the order exceeds the high limit price threshold. The engine starts an auction for this security: the security status changes to on auction but the trading phase remains the continuous trading mode with no status change (not halted or paused). The security status has precedence over the trading phase of that security. Therefore, if a security is in auction status (no auto-match will occurs) when its trading phase is continuous trading (when automatch occurs), auto-match will not take place for that security. Trading Phase Change Notification When a trading phase changes or when a security status changes, this information is sent in a Market Data Delivery fashion. This is very important for traders to know that a security is being auctioned, or to be notified that the actual trading phase does not allows them to cancel orders sent to BM&FBOVESPA (no business rules are sent to the traders, but the label of the trading phase recalls to them which rules are implied in that phase, as is the case of intervention before opening phase) Supported Trading Phases at BM&FBOVESPA The following table illustrates the supported trading phases at BM&FBOVESPA, with information on trading capabilities for each of these phases: Trading phase information Name Start of day consultation Intervention before opening Code C Market data Allowed New order entry Not allowed Order cancellation/ modification Available in market Not allowed N Y E Allowed Allowed Not allowed N Y FX Der. Corporate action Pre-opening auction to establish theoretical opening price. Continuous trading S Allowed Allowed Allowed Y Y End of consultation F Not allowed Not allowed Not allowed N Y Pause state at the end of the trading session. Surveillance intervention N Allowed Not allowed Allowed N Y Market closing U Not allowed Not allowed Not allowed N Y Cancellation of all day orders. BELL Rules of Engagement Page 26

27 Mini-batch M Not allowed Not allowed Not allowed N Y Indicates change to after-hours (change of trading date). Undefined I Not allowed Not allowed Not allowed Y Y Instrument in undefined phase. No trading allowed. 9.2 FIX Version The BM&FBOVESPA FIX engine is FIX 4.4-based. FIX 4.2 may be supported upon request to BM&FBOVESPA. 9.3 Message Flows This section illustrates the message flows for the Derivatives and FX Clearing Houses Derivatives Execution Trader Trader Trader Market data (trades, book, referential data) and order state reports Order entry, cancellation and modification GTS (BM&F Trading System) Trades (registration and cancellation) Derivatives Clearing House Figure 4 - Derivatives Clearinghouse message flow. BELL Rules of Engagement Page 27

28 FX (Foreign Exchange) Execution Market data (trades, book, referential data) and order state reports Trader Trader Bank Order entry, cancellation and modification GTS (BM&F Trading System) Trade registration/ cancellation Trade confirmation request/response FX Clearing House Trade registration SISBACEN Figure 5 - FX Clearing House message flow. Note: for FX market data, the participating party is not specified in the message (blind screen), i.e. the book information will not contain bank/broker information. 9.4 Application Level Messages This section details the application level messages used when connecting to BM&FBOVESPA Instrument Identification Block Instruments are uniquely identified using the block of tags below. Tag Tag name Req d Data type Comment 55 Symbol Y String BM&FBOVESPA requires that this field is properly set. It contains the human readable form of the SecurityID tag, available in the Security List message. 48 SecurityID Y String Security ID as defined by BM&FBOVESPA. For the SecurityID list, see the message Security List. 22 SecurityIDSource Y String Conditionally required if the SecurityID field is set. 1 Please check with BM&F for FIX connectivity availability for FX trading. BELL Rules of Engagement Page 28

29 Document Owner BELL FIX Protocol Rules Of Engagement DO-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment Valid value: 8 = Exchange Symbol (BM&FBOVESPA Security Identification) 207 SecurityExchange N String Market to which security ID (tag 48) belongs. Valid value: XBMF = BM&FBOVESPA This tag is optional, and its absence defaults the Market Center to XBMF (BM&FBOVESPA) Security Definition 2 FIX messages are utilized so that the connecting parties are able to determine which instruments are traded at BM&FBOVESPA. Instrument definition messaging is based on a subscription model, in which the client institutions subscribe to receive instrument definitions according to specific criteria, and optionally receive updates afterwards. The subscription may be cancelled at any time Security List Request (MsgType = x) The Security List Request message is used by institutions that connect to BM&FBOVESPA to retrieve a list of all securities that are available for trading in that connection according to specified criteria, and to receive further updates that match those criteria. Its response is a Security List message, which contains information about the instruments traded such as Security IDs and relevant trading information (trade lot, minimum quantity, tick increment, etc). In case the request fails, its response will be the Security List message with the SecurityRequestResult field indicating the reason of the rejection. Cancellation of the subscription may be done setting the field SubscriptionRequestType to 2 (unsubscribe). Tag Tag name Req d Data type Comment [ Standard message header ] Unique ID of the Security List Request. BM&FBOVESPA strongly advises this value to be unique throughout the trading 320 SecurityReqID Y String day, since it will be used to cross reference the request with the response. However, BM&FBOVESPA will not validate it for its uniqueness. 263 SubscriptionRequestType Y Char Subscribe or unsubscribe for security changes specified in the request. Values accepted by BM&FBOVESPA: 0 = Snapshot 1 = Snapshot + Updates (Subscribe) 2 = Disable previous Snapshot + Update Request (Unsubscribe) 6935 SecurityUpdatesSince N UTCTimestamp Optional field that indicates the response to this request should be only the list of 2 Please check with BM&F for availability. BELL Rules of Engagement Page 29