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

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 DI-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 DI-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) BELL Rules of Engagement Page 5

6 Document Owner Figure Index BELL FIX Protocol Rules Of Engagement DI-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 February 5th Updated section for Market Closing phase (625=U) Order cancelation now allowed during this phase JLRM January 5th For the Derivatives/FX section: Added value 103 (Self-Trading Prevention) to tag 103 EP 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 new values to tag 762 TAT - Added item 2.5 (Throttle)Added business rejection reason 99 = Throttle Limit Exceeded 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 [email protected] and JML BELL Rules of Engagement Page 7

8 August 7th July 3rd Jun 6th Added note on sequence number reset in the Logon session. For the Derivatives/FX section: - 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 - 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 ) 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 JML JML JML BELL Rules of Engagement Page 8

9 Mar 11th 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 , 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 JML BELL Rules of Engagement Page 9

10 Feb 18th Dec 4th 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 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 JML JML BELL Rules of Engagement Page 10

11 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department capabilities ( ) - Updated the description of fields TradingSessionID and TradingSessionSubID in sections and Added field CFICode to the SecurityListRequest message (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 Information Technology Department Document Owner 1.1 Introduction BELL FIX Protocol Rules Of Engagement DI-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) [email protected] 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 [email protected], or the BM&FBOVESPA customer service center at [email protected]. 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 DI-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. BELL Rules of Engagement Page 19

20 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 20

21 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 21

22 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 22

23 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 Comment type [ 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 23

24 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 Comment type [ 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 24

25 Document Owner Tag Tag name Req d Data type 58 Text N String BELL FIX Protocol Rules Of Engagement DI-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 25

26 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 26

27 Document Owner Trading Phase and Security Status BELL FIX Protocol Rules Of Engagement DI-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 Allowed N Y Cancellation of all day orders. BELL Rules of Engagement Page 27

28 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 28

29 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 29

30 Document Owner BELL FIX Protocol Rules Of Engagement DI-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 30

31 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment securities modified/added since the timestamp indicated (in UTC format). 559 SecurityListRequestType Y Int Values accepted by BM&FBOVESPA: 1: According to CFICode/SecurityType 2: According to product 4: All securities 5: According to asset 167 SecurityType C String(32) Conditionally required if SecurityListRequestType = 1 and the client wants to subscriber for a SecurityType. Values accepted by BM&FBOVESPA: - FUT = futures - SPOT = spot market - SOPT = spot options - FOPT = futures options - DTERM = forward 460 Product C Int Conditionally required if tag 559=2 (subscription by product). Values accepted by BM&FBOVESPA: 2 Commodity 4 Currency 7 Index 12 Other 13 Financing 461 CFICode C String(6) Classification of Financial Instruments (CFI Code) values. Indicates the type of security using ISO standard, Conditionally required if SecurityListRequestType = 1. If both this tag and SecurityType are specified, CFICode has precedence and SecurityType is ignored Asset C String(10) Conditionally required if tag 559=5 (subscription by asset). Asset associated with the security, such as DOL, BGI, OZ1, WDL, CNI, etc. [ Standard message trailer ] Security List (MsgType = y) The Security List message is used to return a list of securities that matches the criteria specified in a Security List Request. If the list of securities returned is so large it requires message fragmentation (i.e. more than one message to return all the securities), tag TotNoRelatedSym will be set, containing the total number of securities to be returned in the stream of messages, as opposed to the value of NoRelatedSym, which indicates the number of securities returned in that specific message. The last message in the stream will have tag LastFragment set to Y. Absence of tag LastFragment should be interpreted as LastFragment = N. If the list of securities that is requested is an empty set (i.e. there are no instruments that match the entered criteria in the Security List Request message), a Security List message is returned to the BELL Rules of Engagement Page 31

32 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department requesting counterparty with the LastFragment field set to Y and the totnorelatedsym field set to 0 (zero). Tag Tag name Req d Data type Comment [ Standard message header ] 320 SecurityReqID Y String(32) Echoed back from the Security List Request message that caused this message to be sent. 322 SecurityResponseID Y String(32) Unique ID of this message, generated by BM&FBOVESPA. 560 SecurityRequestResult Y Int The results returned to the Security List Request message. Values issued by BM&FBOVESPA: 0 = Valid request 1 = Invalid or unsupported request 6 = Duplicate SecurityReqID 7 = Request Queued 393 TotNoRelatedSym N Int Used to indicate the total number of securities being returned for this request. Used in the event that message fragmentation is required. 893 LastFragment N Boolean Indicates whether this message is the last in the sequence of messages. Valid values: Y = Last message N = Not last message 146 NoRelatedSym N NumInGroup Specifies the number of repeating instruments specified. [ Instrument identification block ] See Section Instrument Identification Block for tag values 454 NoSecurityAltID N NumInGroup Number of alternate security identifiers. 455 SecurityAltID N String(50) Security Alternate identifier for this security (e.g. ISIN). First member of repeating group - must be specified if NoSecurityAltID > 0. Requires SecurityAltIDSource. 456 SecurityAltIDSource N String(1) Identifies class or source of the SecurityAltID (455) value. Required if SecurityAltID is specified. Values issued by BM&FBOVESPA: 4 = ISIN number H = Clearing house/organization 711 NoUnderlyings N NumInGroup Number of underlying BELL Rules of Engagement Page 32

33 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment instruments. Conditionally required if NoUnderlyings > UnderlyingSymbol C String(50) Underlying instrument s ticker symbol. Conditionally required if NoUnderlyings > UnderlyingSecurityID C String(50) Underlying instrument s security identifier. Conditionally required if NoUnderlyings > UnderlyingSecurityIDSource C String(1) Qualifier for underlying instrument s security ID. Value issued by BM&FBOVESPA: 8 = Exchange Symbol (BM&FBOVESPA security identification). Conditionally required if NoUnderlyings > UnderlyingSecurityExchange C String(3) Underlying instrument s exchange. Value issued by BM&FBOVESPA: XBMF = BM&FBOVESPA Conditionally required if NoUnderlyings > NoLegs N NumInGroup Number of instrument legs. 600 LegSymbol C String(50) Leg symbol. Conditionally required if NoLegs > LegSecurityID C String(50) Unique identifier for the instrument leg, as per tag LegSecurityIDSource. Conditionally required if NoLegs > LegSecurityIDSource C String(1) Qualifier for tag LegSecurityID. Value issued by BM&FBOVESPA: 8 = Exchange Symbol (BM&FBOVESPA security identification) Conditionally required if NoLegs > LegSecurityExchange C String(3) Exchange code the leg security belongs to. Value issued by BM&FBOVESPA: XBMF = BM&FBOVESPA Conditionally required if NoLegs > RoundLot N Qty The trading lot size of the security. 562 MinTradeVol N Qty The minimum trading volume for the security. 969 MinPriceIncrement N Price Number of minimum tick increments. Number of decimals used for 5151 TickSizeDenominator N Int pricing this instrument, e.g. price = 0,001, decimals = 3. BELL Rules of Engagement Page 33

34 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment 9749 MinOrderQty N Qty Minimum quantity of an order for the security MaxOrderQty N Qty Maximum quantity of an order for the security InstrumentId N Int Unique number identifying the instrument. 15 Currency N Currency Currency used for the price. 167 SecurityType N String(32) Values accepted by BM&FBOVESPA: - FUT (futures) - SPOT (spot market) - SOPT (spot options) - FOPT (future options) - DTERM (forward markets, or termo ) 762 SecuritySubType N String(32) The sub type of the instrument. Values issued by BM&FBOVESPA: 4 FX spot10 - Gold 20 - Index 30 - Interest rate 40 - FX rate 50 - Foreign debt 60 - Agricultural 70 Energy 80 - Indices 90 - Strategy Futures-style option Carbon credits 460 Product N Int Product associated with this instrument. Values issues by BM&FBOVESPA: 2 Commodity 4 Currency 7 Index 12 Other 13 Financing 14 Carbon Credit 6937 Asset N String(10) Asset associated with the security, such as DOL, BGI, OZ1, WDL, CNI, etc. 107 SecurityDesc N String(1000) Descriptive string of the security (e.g. dollar futures or gold futures ). 541 MaturityDate N LocalMktDate Date of instrument maturity. 200 MaturityMonthYear N MonthYear Month and year of the maturity (for futures and options). 202 StrikePrice N Price Strike price of option. 947 StrikeCurrency N Currency Currency of option s strike price. BELL Rules of Engagement Page 34

35 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment 231 ContractMultiplier N Double Specifies the ratio or multiply factor to convert from nominal units (e.g. contracts) to total units (e.g. shares) (e.g. 1.0, 100, 1000, etc). 667 ContractSettlMonth N MonthYear Specifies when the contract will settle. 461 CFICode N String(6) Classification of Financial Instruments (CFI code) values, which indicate the type of security using the ISO standard. 470 CountryOfIssue N Country ISO country code of instrument issue. 225 IssueDate N LocalMktDate The date on which the security is issued/activated. 873 DatedDate N LocalMktDate The date of the security activation, if different from the IssueDate. 916 StartDate N LocalMktDate Start date of a financing deal, i.e. the date the buyer pays the seller cash and takes control of the collateral 917 EndDate N LocalMktDate End date of a financing deal, i.e. the date the seller reimburses the buyer and takes back control of the collateral. 64 SettlDate N LocalMktDate Specific date of trade settlement (SettlementDate) in YYYYMMDD format. 63 SettlType N Char Indicates order settlement period. If present, SettlDate (64) overrides this field. If both SettlType (63) and SettDate (64) are omitted, the default for SettlType (63) is 0 (Regular). 423 PriceType N Int Code that represents the price type of the instrument. Valid values: 12 Product ticks in full ticks 13 Product ticks in halfs 14 Product ticks in fourths 15 Product ticks in eights 16 Product ticks in sixteenths 17 Product ticks in thirtyseconds 18 Product ticks in sixtyfourths 20 Product ticks in half thirtyseconds 21 Product ticks in quarter BELL Rules of Engagement Page 35

36 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment thirty-seconds 22 Product ticks in half sixtyfourths 6938 SecurityValidityTimestamp N UTCTimestamp 9918 SecurityGroup N String(15) [ Standard message trailer ] Absence of this field denotes that the instrument trades in decimals. Indicates the UTC timestamp when trading for this security expires, i.e. when it is not eligible to trade anymore. Different from MaturityDate. Indicates the group this instrument belongs to Order Management This section describes messages exchanged that are relevant to order management, i.e. the sending of orders, cancellations, modifications and reporting of state changes. The following diagram illustrates the lifecycle of an order in BM&FBOVESPA s trading system. It represents the possible states indicated in the OrdStatus field. BELL Rules of Engagement Page 36

37 Replaced Reject on entry Rejected Receive valid replace request Full execution Partial execution Receive valid order New Full execution Filled Partial execution Receive valid replace request Full execution Receive valid cancel request End of day Cancelled due to trading rules (e.g. FOK or IOC without counterparty) Receive valid cancel request Cancelled Receive valid cancel request Partially Filled End of day Partial execution Expired End of day New Order Single (MsgType = D) Figure 6 - Order lifecycle state diagram The New Order Single message is used by institutions to electronically submit orders for execution to BM&FBOVESPA. Orders should have a unique identifier (see tag ClOrdID <11>) assigned by the institution for a trading day. Orders with duplicate identifiers will be rejected by BM&FBOVESPA. The acknowledgment of receipt of a New Order Single message is issued by BM&FBOVESPA in the form of an Execution Report message. Other relevant sections to order modification are: Section 9.7: Trading on Behalf Section 9.8: Trade Give-ups Section 9.9: Program Trading, Foreign Investors and DMA Clients Tag Tag name Req d Data type Comment [ Standard message header ] Unique identifier of the order as assigned 11 ClOrdID Y String(38) by institution. [ Instrument identification block ] See Section Instrument Identification Block for tag values BELL Rules of Engagement Page 37

38 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment 54 Side Y Char Side of order. Valid values: 1 = Buy 2 = Sell 38 OrderQty Y Qty Number of shares or contracts ordered. 110 MinQty N Qty Minimum quantity of an order to be executed. 111 MaxFloor N Qty Maximum number of shares or contracts within an order to be shown on the match engine at any given time. Order type. Values accepted by 40 OrdType Y Char BM&FBOVESPA: 2 = Limit 4 = Stop Limit K = Market with leftover as Limit 44 Price C Price Price per share or contract. Conditionally required if the order type requires a price (not market). 99 StopPx C Price The stop price of a stop limit order (Conditionally required if OrdType = 4). Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. Values accepted by 59 TimeInForce N Char BM&FBOVESPA: 0 = Day (or session) 3 = Immediate or Cancel (IOC) 4 = Fill or Kill (FOK) 78 NoAllocs N NumInGroup Number of repeating groups for pre-trade allocation. If present, should be always 1, since allocation can be done only for a single client. 79 AllocAccount N String(9) Sub-account mnemonic. Required if NoAllocs > 0. Must be first field in repeating group. 661 AllocAcctIDSource N Int Identifies source of AllocAccount. Value accepted by BM&FBOVESPA: 99 Other (custom or proprietary code) 453 NoPartyID Y NumInGroup Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole. 448 PartyID Y String(50) Used to identify source of PartyID. 447 PartyIDSource Y Char Identifies class or source of the PartyID (448) value. Value accepted by BM&FBOVESPA: D = Proprietary/Custom code 452 PartyRole Y Int Identifies the type or role of the PartyID (448) specified. Values accepted by BM&FBOVESPA: 4 Clearing Firm 7 Entering Firm 12 Executing Trader 36 Entering Trader BELL Rules of Engagement Page 38

39 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment 40 Transfer to Firm 54 Sender Location ID 60 TransactTime Y UTCTimestamp Time of execution/order creation; expressed in UTC format. 529 OrderRestrictions N MultipleValueString Restrictions associated with an order. If more than one restriction is applicable to an order, this field can contain multiple instructions separated by space. Values accepted by BM&FBOVESPA: 1 - Program Trade 7 - Foreign Entity (of foreign government or regulatory jurisdiction) 8 - External Market Participant 77 PositionEffect N Char Indicates whether the resulting position after a trade should be a closing position. Value accepted by BM&FBOVESPA: C = Closed 826 TradeAllocIndicator N Int Identifies how the trade is to be allocated Valid value: 1 = Allocation required (give up trade) allocation information not provided (incomplete) Absence of this field indicates that allocation is not required, or allocation is provided with the trade. [ Standard message trailer ] New Order Cross (MsgType = s) Used to submit a cross order into a market. The cross order contains two order sides (buy and sell), each one containing information about that side, including the buyer, the seller and ClOrdID field. Each of these sides is called a leg of the cross order. The cross order is identified by the CrossID (548) tag. BM&FBOVESPA will not validate for the uniqueness of this tag, but strongly suggests it to be unique. Other relevant sections to order modification are: Section 9.10: New Order Cross Execution Rules at BM&FBOVESPA. Tag Tag name Req d Data type Comment [ Standard message header ] 548 CrossID Y String(50) Identifier for a cross order. Must be unique during a given trading day. 549 CrossType Y Int Type of cross being submitted to a market. Values accepted by BM&FBOVESPA: 1 = Cross Trade which is executed completely or not. Both sides are treated in the same manner. This is equivalent to an All or None. BELL Rules of Engagement Page 39

40 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment Indicates if one side or the other of a cross 550 CrossPriorization Y Int order should be prioritized. Value accepted by BM&FBOVESPA: 0 = None Order type. Value accepted by 40 OrdType Y Char BM&FBOVESPA for trade registration: 2 = Limit [ Instrument identification block ] See Section Instrument Identification Block for tag values 44 Price Y Price Price per share or contract. 60 TransactTime Y UTCTimestamp Time of execution/order creation; expressed in UTC (Universal Time Coordinated, also known as "GMT"). 552 NoSides Y NumInGroup Number of Side (54) repeating group instances. Must be always 2 (both sides) 54 Side Y Char Side of order. Valid values: 1 = Buy 2 = Sell 11 ClOrdID Y String(38) Unique identifier of the order as assigned by the client. 38 OrderQty Y Qty Number of shares or contracts ordered. 77 PositionEffect N Char Indicates whether the resulting position after a trade should be a closing position. Value accepted by BM&FBOVESPA: C = Closed 78 NoAllocs N NumInGroup Number of repeating groups for pre-trade allocation. If present, should be always 1, since allocation can be done only for a single client. 79 AllocAccount N String(9) Sub-account mnemonic. Required if NoAllocs > 0. Must be first field in repeating group. 661 AllocAcctIDSource N Int Identifies source of AllocAccount. Value accepted by BM&FBOVESPA: 99 Other (custom or proprietary code) 453 NoPartyID Y NumInGroup Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole. 448 PartyID Y String(50) Used to identify source of PartyID. 447 PartyIDSource Y Char Identifies class or source of the PartyID (448) value. Value accepted by BM&FBOVESPA: D = Proprietary/Custom code 452 PartyRole Y Int Identifies the type or role of the PartyID (448) specified. Values accepted by BM&FBOVESPA: 7 Entering Firm 12 Executing Trader 36 Entering Trader 40 Transfer to Firm 54 Sender Location ID Identifies how the trade is to be allocated TradeAllocIndicator N Int 826 Valid value: BELL Rules of Engagement Page 40

41 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment 1 = Allocation required (give up trade) allocation information not provided (incomplete) Absence of this field indicates that allocation is not required, or allocation is provided with the trade. [ Standard message trailer ] Order Cancel Request ( MsgType = F ) The Order Cancel Request message requests the cancellation of all of the remaining quantity of an existing order. The request will only be accepted if the order can successfully be pulled back from the match engine without executing. An order may be cancelled by either the client order ID (unique order ID assigned by the client and sent in the ClOrdID tag in the New Order message), the BM&FBOVESPA order ID (unique order ID for an instrument assigned by BM&FBOVESPA when the order is accepted and present in the OrderID tag in the Execution Report) or the secondary order ID (BM&FBOVESPA-generated ID that changes when an order is modified or a disclosed quantity is replaced). In the Order Cancel Request message, the client order ID should be in the OrigClOrdID tag, and the BM&FBOVESPA order ID in the OrderID tag. The precedence for order identification is OrderID -> SecondaryOrderID -> OrigClOrderID. A cancel request is assigned a ClOrdID and is treated as a separate entity. If rejected, the ClOrdID of the Cancel Request will be sent in the Cancel Reject message, as well as the ClOrdID of the actual order in the OrigClOrdID field. The ClOrdID assigned to the cancel request must be unique amongst the ClOrdID assigned to regular orders and replacement orders. Note that the entering trader specified in the PartyID repeating group must be the same as the entering trader in the original order. A successful Order Cancel Request is replied to with an Execution Report message. Tag Tag name Req d Data type Comment [ Standard message header ] 41 OrigClOrdID Y String(38) ClOrdID of the order that the client is trying to cancel. 37 OrderID N String(32) BM&FBOVESPA-assigned OrderID of the order the client is trying to cancel. If this tag is present, the value in tag OrigClOrdID is ignored. [ Instrument identification block ] See Section Instrument Identification Block for tag values 11 ClOrdID Y String(38) Unique ID of cancel request as assigned by the institution. 198 SecondaryOrderID N String(50) Exchange-generated order identifier that changes for each order modification event, or quantity replenishment in disclosed orders. 54 Side Y Int Side of order to be cancelled. Valid values: BELL Rules of Engagement Page 41

42 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment 1 = Buy 2 = Sell 453 NoPartyID Y NumInGroup Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole. 448 PartyID Y String(50) Used to identify source of PartyID. 447 PartyIDSource Y Char Identifies class or source of the PartyID (448) value. Value accepted by BM&FBOVESPA: D = Proprietary/Custom code 452 PartyRole Y Int Identifies the type or role of the PartyID (448) specified. Values accepted by BM&FBOVESPA: 7 Entering Firm 12 Executing Trader 36 Entering Trader 54 Sender Location ID 60 TransactTime Y UTCTimestamp Time this order request was initiated/released by the trader or trading system, in UTC format. 529 OrderRestrictions N MultipleValueString Restrictions associated with an order. If more than one restriction is applicable to an order, this field can contain multiple instructions separated by space. Values accepted by BM&FBOVESPA: 1 - Program Trade 7 - Foreign Entity (of foreign government or regulatory jurisdiction) 8 - External Market Participant [ Standard message trailer ] Order Cancel Reject ( MsgType = 9 ) The Order Cancel Reject message is issued by BM&FBOVESPA upon receipt of a Cancel Request or Order Cancel Replace Request (modification) message which cannot be honored. Filled orders cannot be cancelled or modified. When rejecting an Order Cancel Request, the Order Cancel Reject message will provide the ClOrdID and OrigClOrdID values which were specified on the original Cancel/Replace Request message for identification. Tag Tag name Req d Data type Comment [ Standard message header ] BELL Rules of Engagement Page 42

43 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department 37 OrderID Y String(32) If CxlRejReason= Unknown order, value is: - NONE if cancel is done via OrigClOrdID - Value of the OrderID of the original cancel or modification request. Otherwise, unique identifier for Order as assigned by BM&FBOVESPA. Uniqueness is guaranteed within a single trading day/instrument. 11 ClOrdID Y String(38) Unique order id assigned by institution to the cancel request. 41 OrigClOrdID Y String(38) ClOrdID which could not be canceled/replaced. 39 OrdStatus Y Char OrdStatus value after this cancel reject is applied. If CxlRejReason = Unknown Order, this field s value is Rejected. 54 Side N Char Side of the original order. Values issued by BM&FBOVESPA: 1 = Buy 2 = Sell [ Instrument identification block ] See Section Instrument Identification Block for tag values 1 Account N String Account mnemonic. 434 CxlRejResponseTo Y Char 102 CxlRejReason N Int 58 Text C String(50) 453 NoPartyID N NumInGroup 448 PartyID C String(50) 447 PartyIDSource C Char Identifies the type of request that this Cancel Reject is in response to. Values issued by BM&FBOVESPA: 1 - Order Cancel Request 2 - Order Cancel/Replace Request Code to identify reason for cancel rejection. Valid values: 0 = Too late to cancel 1 = Unknown order 99 = Other Description of error in case CxlRejReason = 99 (Other), or in other cases, may contain extra information on stated CxlRejReason. Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole. Used to identify source of PartyID. Conditionally required if NoPartyID>0. Identifies class or source of the PartyID (448) value. Conditionally required if NoPartyID>0. Value issued by BM&FBOVESPA: D = Proprietary/Custom code BELL Rules of Engagement Page 43

44 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department 452 PartyRole C Int Identifies the type or role of the PartyID (448) specified. Conditionally required if NoPartyID>0. Values issued by BM&FBOVESPA: 4 Clearing Firm 7 Entering Firm 12 Executing Trader 36 Entering Trader 40 Transfer to Firm 54 Sender Location ID [ Standard message trailer ] Order Cancel Replace Request (MsgType = G) The Order Cancel Replace Request message is used to change the parameters of a previously entered order. The Cancel/Replace request will only be accepted if the order can successfully be pulled back from the match engine without executing. Requests which cannot be processed will be rejected using the Order Cancel Reject message, containing the ClOrdID of the cancel/replace request and the OrigClOrdID of the order the client is trying to cancel. The client may optionally cancel the order by its OrderID or SecondaryOrderID. In this case, the OrigClOrdID tag will be ignored. The precedence for order identification is OrderID SecondaryOrderID OrigClOrdID. Only the fields that are being changed need to be sent in the replacement. Fields that are not sent are considered to be the same as the cancelled order. Only the following fields may change: Quantities (OrderQty, MaxFloor); Prices (Price); The modification of stop orders before they are triggered is not allowed, and will be rejected. Attempts to change another field will be rejected with an Order Cancel Reject, with tag CxlRejReason (102) = 2 (Exchange/Broker option) and a description in tag Text (58). An order that is replaced will keep its OrderID. Other relevant sections to order modification are: Section 9.7: Trading on Behalf Section 9.8: Trade Give-ups Section 9.9: Program Trading, Foreign Investors and DMA Clients Section 9.11: In-flight Modification and Interpretation of the OrderQty Field. Tag Tag name Req d Data type Comment [ Standard message header ] 41 OrigClOrdID Y String(38) ClOrdID of the order that the client is trying to cancel. 37 OrderID N String(32) BM&FBOVESPA-assigned OrderID of the order the client is trying to cancel. If this tag is present, the value in tag OrigClOrdID is ignored. BELL Rules of Engagement Page 44

45 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment [ Instrument identification block ] See Section Instrument Identification Block for tag values Unique ID of cancel replace 11 ClOrdID Y String(38) request as assigned by the institution. 198 SecondaryOrderID N String(50) Exchange-generated order identifier that changes for each order modification event, or quantity replenishment in disclosed orders OrigSecondaryOrderID N String(50) Original SecondaryOrderID value for a modified order. 54 Side Y Char Side of order. Valid values: 1 = Buy 2 = Sell 38 OrderQty Y Qty Number of shares or contracts ordered. 111 MaxFloor N Qty Maximum number of shares or contracts within an order to be shown on the match engine at any given time. 40 OrdType Y Char Order type. Values accepted by BM&FBOVESPA: 2 = Limit 4 = Stop Limit K = Market with leftover as Limit 44 Price C Price Price per share or contract. Conditionally required if the order type requires a price (not market orders). 78 NoAllocs Y NumInGroup Number of repeating groups for pre-trade allocation. Should be always 1, since allocation can be done only for a single client. 79 AllocAccount Y String(9) Sub-account mnemonic. Must be first field in repeating group. Note that BM&FBOVESPA does not allow account modification for an order entered by a DMA customer. Hence, this tag s value must be the same as the original order. 661 AllocAcctIDSource Y Int Identifies source of AllocAccount. Value accepted by BM&FBOVESPA: 99 Other (custom or proprietary code) 453 NoPartyID Y NumInGroup Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole. BELL Rules of Engagement Page 45

46 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment 448 PartyID Y String(50) Used to identify source of PartyID. 447 PartyIDSource Y Char Identifies class or source of the PartyID (448) value. Value accepted by BM&FBOVESPA: D = Proprietary/Custom code 452 PartyRole Y Int Identifies the type or role of the PartyID (448) specified. Values accepted by BM&FBOVESPA: 4 Clearing Firm 12 Executing Trader 36 Entering Trader 40 Transfer to Firm 54 Sender Location ID 60 TransactTime Y UTCTimestamp Time this order cancel replace request was initiated/released by the trader or trading system, in UTC format ( GMT ) 529 OrderRestrictions N MultipleValueString Restrictions associated with an order. If more than one restriction is applicable to an order, this field can contain multiple instructions separated by space. Values accepted by BM&FBOVESPA: 1 - Program Trade 7 - Foreign Entity (of foreign government or regulatory jurisdiction) 8 - External Market Participant [ Standard message trailer ] Execution Report ( MsgType = 8 ) The Execution Report message is used in the following scenarios: Confirm the receipt of an order; Confirm changes to an existing order (i.e. accept order cancel requests); Relay order status information; Relay fill information on working orders (trades); Reject orders. Each execution report contains two fields which are used to communicate both the current state of the order as understood by the broker and the purpose of the message: OrdStatus (used to convey the current status of an order) and ExecType (used to identify the purpose of the Execution Report message). The field ExecTransType is kept as required for backwards compatibility with FIX 4.2 only. Its value should always be 0 = New. End of Day Considerations At the market closing trading phase, all unexecuted orders are cancelled from the order book, causing the generation of Execution Report messages with OrdStatus=Cancelled and ExecType=Expired to the order owners. BELL Rules of Engagement Page 46

47 Tag Tag name Req d Data type Comment [ Standard message header ] 37 OrderID Y String(32) Unique identifier for Order as assigned by the exchange. Uniqueness is guaranteed within a single trading day/instrument. 11 ClOrdID Y String(38) ID of electronically submitted order by the institution. 41 OrigClOrdID C String(38) Contains the ClOrdID of the replacement order. Conditionally required when ExecType = 5 (Replace). 198 SecondaryOrderID C String(50) Specifies the secondary order ID assigned by the exchange to this order, which will identify this order in the market data feed for orderdepth book updates, whereas the OrderID is immutable and is not sent in the market data feed. If an order is received with MaxFloor (disclosure quantity) > 0, every time the quantity is replenished by the disclosure quantity amount (e.g. due to an execution), a new SecondaryOrderID is assigned to the order. This identifier may also be used for order cancellation and modification. 548 CrossID C String(50) ID of electronically submitted cross order by the institution (if in response to a cross order). 17 ExecID Y String(32) Unique identifier of execution message as assigned by the exchange unique per instrument. 19 ExecRefID N String(32) Optionally sent when reporting a trade bust. Contains the identifier of the busted trade. [ Instrument identification block ] See Section Instrument Identification Block for tag values BELL Rules of Engagement Page 47

48 150 ExecType Y Char 39 OrdStatus Y Char 40 OrdType C Char BTSFinalTxOrdStatus 3 C Char Describes the action that triggered this specific Execution Report - see the OrdStatus (39) tag for the current order status (e.g, Partially Filled). Values issued by BM&FBOVESPA: 0 New 4 Canceled 5 Replaced 8 Rejected F Trade H Trade Cancel C Expired D Restated Valid values: 0 New 1 Partially Filled 2 Filled 4 Canceled 5 Replaced (Removed/Replaced) 8 Rejected Conditionally required when ExecType!= 8 (Reject) or ExecType!= H (Trade bust). Values issued by BM&FBOVESPA: 2 = Limit 4 = Stop Limit K = Market with leftover as Limit Used in book sweep scenarios (when the order sweeps the book executing against several other orders), indicating the end state of the order. Values issued by BM&FBOVESPA: 0 New 1 Partially Filled 2 Filled 4 Canceled 5 Replaced 8 Rejected 3 This field is sent in the message in case an order enters the order book and executes immediately against more than one order on the opposite side, generating more than one Execution Report message to relay the fill information. Each Execution Report will contain the end state of the client s order in this field. Therefore, if an order partially executes 3 times until it is filled, each Execution Report will contain the following pairs: Exec Rpt #1 (OrdStatus = Partially Filled, BTSFinalTxOrdStatus = Filled); Exec Rpt #2 (OrdStatus = Partially Filled, BTSFinalTxOrdStatus = Filled); and Exec Rpt #3 (OrdStatus = Filled, BTSFinalTxOrdStatus = Filled). BELL Rules of Engagement Page 48

49 Document Owner 378 ExecRestatementReason N Int BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department 636 WorkingIndicator N Boolean 103 OrdRejReason C Int 54 Side Y Int 38 OrderQty Y Qty 44 Price C Price 99 StopPx C Price 6 AvgPx Y Price Always 0 (zero). 32 LastQty C Qty Indicates reason of restatement, if available. Value issued by BM&FBOVESPA: 4 Broker option 103 Self-Trading Prevention Indicates if the stop order has been triggered and is available for trading. Possible values: Y = Order is available for trading; N = Order is not available for trading. Code to identify reason for order rejection. For optional use with ExecType = 8 (Rejected). Valid values: 1 = Unknown symbol 2 = Exchange closed 3 = Order exceeds limit 4 = Too late to enter 5 = Unknown Order 6 = Duplicate Order (e.g. dupe ClOrdID) 11 = Unsupported order characteristic 13 = Incorrect Quantity 15 = Unknown Account 99 = Other (generic error, see tag Text for further information) Side of order. Valid values: 1 = Buy 2 = Sell Number of shares or contracts ordered. Price per share or contract. Required if specified on the order. The stop price of a stop limit order (Conditionally required if OrdType = 4). Quantity of shares bought/sold on this (last) fill. Conditionally required when ExecType = F (Trade). 31 LastPx C Price Price of this (last) fill. 110 MinQty C Qty 111 MaxFloor C Qty Minimum quantity of an order to be executed. Echo from original order s MinQty. Maximum number of shares or contracts within an order to be shown on the match engine at any given time. Echo from original order s MaxFloor. BELL Rules of Engagement Page 49

50 Document Owner 151 LeavesQty Y Qty 14 CumQty Y Qty 9757 OrigOrdQty N Qty BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department 59 TimeInForce N Char 75 TradeDate N LocalMktDate 6032 UniqueTradeId C String(32) Amount of shares open for further execution, or unexecuted. LeavesQty = OrderQty - CumQty. Total number of shares or contracts filled. Original quantity of the order before it was modified. Present in the message only if ExecType=5 (Replaced). Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. Values accepted by BM&FBOVESPA: 0 = Day (or session) 3 = Immediate or Cancel (IOC) 4 = Fill or Kill (FOK) Indicates date of trade referenced in this message in YYYYMMDD format (expressed in local time at place of trade). Absence of this field indicates current day (expressed in local time at place of trade). Contains the unique identifier for this trade, per instrument + trading date, as assigned by the exchange. Conditionally required if ExecType = F (Trade). 1 Account N String Account mnemonic. 453 NoPartyID Y NumInGroup Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole. 448 PartyID Y String(50) Used to identify source of PartyID. 447 PartyIDSource Y Char Identifies class or source of the PartyID (448) value. Value accepted by BM&FBOVESPA: D = Proprietary/Custom code 452 PartyRole Y Int Identifies the type or role of the PartyID (448) specified. Values issued by BM&FBOVESPA: 4 Clearing Firm 7 Entering Firm 12 Executing Trader 36 Entering Trader 40 Transfer to Firm 54 Sender Location ID 382 NoContraBrokers C NumInGroup Number of contra brokers in an execution. Currently, this field will be always set to 1. Conditionally required when reporting trades. 375 ContraBroker N String(50) Identifies contra broker. BELL Rules of Engagement Page 50

51 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department 337 ContraTrader N String(50) Identifies the trader of the ContraBroker. 60 TransactTime Y UTCTimestamp Time of execution/order creation; expressed in UTC (Universal Time Coordinated, also known as "GMT") 58 Text N String(50) Free format text string. 826 TradeAllocIndicator N Int Identifies how the trade is to be allocated. Valid value: 1 = Allocation required (give up trade) allocation information not provided (incomplete) Absence of this field indicates that allocation is not required, or allocation is provided with the trade. [ Standard message trailer ] Market Data The Market Data feed provided by BM&FBOVESPA is based on the regular FIX subscription model. There are different market data entry types for each security, and the client institution may subscribe individually to each entry type, not necessarily in the same message. Note that subscription can be made on a per-security basis, market segment ( Futures or Options ), product code or CFI code (all available in the Security List message). The following market data entry types are currently supported by BM&FBOVESPA: Market Data Entry Type 0 Bid 1 Offer e f Description Aggregate bid Aggregate offer Comment The full book on the buy side for the security. The book is order-depth based, i.e. each individual order will appear as a separate book entry, even if it contains the same price as other orders. The full book on the sell side for the security. The book is order-depth based, i.e. each individual order will appear as a separate book entry, even if it contains the same price as other orders. The price-depth book on the buy side for the security. Each book entry corresponds to a price, and may contain more than one order. It displays the total quantity (sum of all order quantities) at that price. The price-depth book on the sell side for the security. Each book entry corresponds to a price, and may contain more than one order. It displays the total quantity (sum of all order quantities) at that price. 2 Trade The completed trades for the security. 4 Opening price The opening price of the security (first trade). 5 Closing price The closing price of the security (previous day s last trade). 7 Trading session high price The highest price traded for the security in the trading BELL Rules of Engagement Page 51

52 Market Data Entry Type Description Comment session. 8 Trading session low price The lowest price traded for the security in the trading session. Volume-Weighted Average Price, the ratio of the value traded to total volume traded over the trading session. Calculated using the formula: 9 B X Z a b Trading session VWAP price Trade volume Top of book offer Top of book bid Referential prices Trading phase P VW AP c Instrument state The status of the security. j Q j j Q P j j Where: P VWAP = Volume Weighted Average Price P j = price of trade j Q j = quantity of trade j j = each individual trade that takes place over the defined period of time (excluding cross trades). The total volume traded for that security in the trading session. The top of book on the sell side for the security. The top of book for the market data entry type is price-depth, i.e. in case more than one order is on the top of the book with the same price, the quantities will be aggregated. The top of book on the buy side for the security. The top of book for the market data entry type is price-depth, i.e. in case more than one order is on the top of the book with the same price, the quantities will be aggregated. The referential prices for the security, such as price tunnels and settlement prices. The trading phase for the security, such as trading or surveillance intervention. Upon request subscription (via the Market Data Request message), the institution will be verified for authorization to that specific security and entry type, as contracted from BM&FBOVESPA. In case of failed authorization, the subscription request will be rejected with a Market Data Request Reject message or a session level reject message (tag 35=3). Upon successful subscription, the client will receive a full snapshot of the information requested (with the Market Data Full Snapshot message), and from that point on will receive incremental messages (Market Data Incremental Refresh), whose content will update specific entries of the full snapshot sent immediately after the subscription. In case of communications failure, such as a FIX connection drop, the client institution needs to resubscribe to the market data entries of interest in that FIX connection. For more details on message flows of FIX market data, please refer to the scenarios in the appendix, or to the FIX 4.4 specification Volume 4. BELL Rules of Engagement Page 52

53 Document Owner Book depths available BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department BM&FBOVESPA supports two types of book depth: order depth and price depth. The client which is subscribing to market data will choose, in the subscription message, which type of book depth it wishes to receive. Both types may be received using the same subscription message, although this procedure is discouraged due to bandwidth consumption Order depth book Order depth book contains order by order information, where each entry represents an individual order. For example, this is how an order-depth book looks like: Bid Qty Price Offer Qty One entry per order: same price on more than one entry. BM&FBOVESPA will always send the full depth of the book for order-depth book, i.e. the client will always receive updates for all the orders that are in the order book, even if it is the last one (worst price). For books that are shallow this may not represent a problem, but for deeper books, updates to the bottom of the book are not always relevant, although they will consume bandwidth. Below, is an example of the typical subscription message for an order-depth book (see section for more details on the message): Tag Value Comment MDReqID [unique identifier] Unique value; may be a GUID. SubscriptionRequestType 1 Snapshot + updates MarketDepth 0 Full book MDUpdateType 1 Incremental refreshes only NoMDEntryTypes 2 2 market data entries being requested. MDEntryType 0 Bid MDEntryType 1 Offer NoRelatedSym 1 1 Symbol DOLV08 Instrument Price depth book Price-depth book contains price by price information, where each entry represents the aggregation of all order quantities at that price. The following table illustrates the price-depth book of the same book described above: Bid Offer Number of Orders Qty Price Qty Number of Orders One entry per price: more than one order per entry. BELL Rules of Engagement Page 53

54 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department In addition to the quantity and the price, the price-depth book also makes the number of orders that compose a specific price available. BM&FBOVESPA presets the depth of the book that will be made available per instruments, usually defaulting to 5. This means that the client will only receive the best 5 price points in the book. Notice that, whereas order depth book offers more detailed information on the orders, price-depth book is more bandwidth efficient, since the snapshot is much smaller and tends to have fewer updates - since updates below the market depth are not sent to the client. Below, is an example of the typical subscription message for a price-depth book (see section for more details on the message). Tag Value Comment MDReqID [unique identifier] Unique value; may be a GUID. SubscriptionRequestType 1 Snapshot + updates MarketDepth 0 Full book (depth is preset by BM&FBOVESPA) MDUpdateType 1 Incremental refreshes only NoMDEntryTypes 2 2 market data entries being requested. MDEntryType e Aggregate bid MDEntryType f Aggregate offer NoRelatedSym 1 1 Symbol DOLV08 Instrument Market Data Request (MsgType = V) A Market Data Request is a general request for market data on a specific security. A successful Market Data Request returns one Market Data Full Snapshot message containing one or more Market Data Entries for each instrument that matches the request. It is then followed by incremental updates (Market Data Incremental Refresh messages). The customer may subscribe for a set of instruments in a single message: for that, it may use the fields Product, CFICode or SecurityType, which will subscribe to all instruments that match the stated criteria. The order of precedence in the message is Product CFICode SecurityType SecurityID. The following examples illustrate how a customer may subscribe using different subscription criteria, for an order-depth book: Example 1: Subscription for instrument DOLV08: Tag Value Comment MDReqID [unique identifier] Unique value; may be a GUID. SubscriptionRequestType 1 Snapshot + updates MarketDepth 0 Full book MDUpdateType 1 Incremental refreshes only NoMDEntryTypes 2 2 market data entries being requested. MDEntryType 0 Bid MDEntryType 1 Offer NoRelatedSym 1 1 Symbol DOLV08 Instrument SecurityID BMFBR SecurityID of DOLV08 SecurityIDSource 8 Qualifier of the SecurityID BELL Rules of Engagement Page 54

55 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Example 2: Subscription for CFICode FCAPSX: Tag Value Comment MDReqID [unique identifier] Unique value; may be a GUID. SubscriptionRequestType 1 Snapshot + updates MarketDepth 0 Full book MDUpdateType 1 Incremental refreshes only NoMDEntryTypes 2 2 market data entries being requested. MDEntryType 0 Bid MDEntryType 1 Offer NoRelatedSym 1 1 Symbol [N/A] No instrument CFICode FCAPSX CFICode value Example 3: Subscription for only FUTURES instruments: Tag Value Comment MDReqID [unique identifier] Unique value; may be a GUID. SubscriptionRequestType 1 Snapshot + updates MarketDepth 0 Full book MDUpdateType 1 Incremental refreshes only NoMDEntryTypes 2 2 market data entries being requested. MDEntryType 0 Bid MDEntryType 1 Offer NoRelatedSym 1 1 Symbol [N/A] No instrument SecurityType FUT Futures instruments Expected Market Data Request Responses If the customer issues a Market Data Request message subscribing for a group of instruments, the response issued by BM&FBOVESPA is individual for each instrument that composes that group. Therefore, if the customer subscribes for all futures instruments, it will receive a Market Data Snapshot or a Market Data Request Reject for each individual futures instrument. All response messages will contain the same MDReqID tag value as the original request. Message Specification Tag Tag Name Req d Data Type Comment [ Standard message header ] Must be unique, or the ID of previous Market Data Request to disable if 262 MDReqID Y String(32) SubscriptionRequestType = Disable previous Snapshot + Updates Request (2). 263 SubscriptionRequestType Y Char Indicates what type of response is expected. Valid values: 1 = Snapshot + Updates (Subscribe) 2 = Disable previous Snapshot + Update Request (Unsubscribe) 264 MarketDepth Y Int Depth of market for Book Snapshot. Values accepted by BM&FBOVESPA: BELL Rules of Engagement Page 55

56 Tag Tag Name Req d Data Type Comment 0 = Full Book Regardless of whether the book is orderdepth or price-depth, this tag s value will always be zero. For price-depth book, the available depth is set in the match engine, not being up to the customer to define the depth it will receive. 265 MDUpdateType C Int Required if SubscriptionRequestType (263) = Snapshot + Updates (1). Specifies the type of Market Data update. Valid values: 1 = Incremental Refresh (value 0 = Full Refresh is not supported by BM&FBOVESPA). 267 NoMDEntryTypes Y NumInGroup Number of MDEntryType fields requested. 269 MDEntryType Y Char Types of Market Data Entries that the firm requesting the Market Data is interested in receiving. Values accepted by BM&FBOVESPA: 0 = Bid 1 = Offer e = Aggregate bid f = Aggregate offer 2 = Trade 4 = Opening Price 5 = Closing Price 7 = Trading Session High Price 8 = Trading Session Low Price 9 = Trading Session VWAP Price B = Trade Volume X = Top of book offer Z = Top of book bid a = Referential prices b = Instrument trading phase c = Instrument state 146 NoRelatedSym Y NumInGroup Number of instruments requested. Currently, BM&FBOVESPA only supports one instrument or instrument set per market data request; hence this tag s value must always be Symbol Y String(50) Symbol of the instrument, required for being the first field in the repeating group. If subscribing to only one instrument, set value to the instrument s symbol. If subscribing for a set of symbols, set to [N/A] (without the quotes). 48 SecurityID C String(50) SecurityID of the instrument, conditionally required if subscribing for only one instrument (tag 55!= [N/A]). The value in this tag must match the symbol stated in BELL Rules of Engagement Page 56

57 Tag Tag Name Req d Data Type Comment tag SecurityIDSource C String(1) SecurityIDSource qualifying the SecurityID, conditionally required if field SecurityID is set. 461 CFICode N String(6) CFICode of the instruments being subscribed, according to rule For list of available CFICodes, please refer to the Security List message issued by BM&FBOVESPA. 460 Product N Int Product of the instrument set being subscribed. For list of available product codes, please refer to the Security List message issued by BM&FBOVESPA. 167 SecurityType N String(32) Market segment of the instrument set being subscribed. For list of available security type codes, please refer to the Security List message issued by BM&FBOVESPA. [ Standard message trailer ] Market Data Request Reject (MsgType = Y) The Market Data Request Reject will be issued by BM&FBOVESPA when it cannot honor the Market Data Request, due to business or technical reasons. Tag Tag Name Req d Data Type Comment [ Standard message header ] 262 MDReqID Y String(32) Echoes back the ID of Market Data Request message that triggered this rejection. 281 MDReqRejReason Y Char Reason for the rejection of a Market Data request. Valid values: 0 = Unknown symbol 1 = Duplicate MDReqID 2 = Insufficient Bandwidth 3 = Insufficient Permissions 4 = Unsupported SubscriptionRequestType 5 = Unsupported MarketDepth 6 = Unsupported MDUpdateType 7 = Unsupported AggregatedBook 8 = Unsupported MDEntryType 9 = Unsupported TradingSessionID A = Unsupported Scope B = Unsupported OpenCloseSettleFlag C = Unsupported MDImplicitDelete Y = MDReqID not found (attempt to cancel an unknown subscription request) Z = Invalid request BELL Rules of Engagement Page 57

58 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag Name Req d Data Type Comment 58 Text N String(50) Descriptive text of reason for rejection [ Standard message trailer ] Market Data Snapshot/Full Refresh (MsgType = W) The Market Data Snapshot/Full Refresh messages are sent as the response to a Market Data Request message. The message refers to only one Market Data Request. It will contain the appropriate MDReqID tag value to correlate the request with the response. Tag Tag Name Req d Data Type Comment [ Standard message header ] 262 MDReqID Y String(32) Echo back from the Market Data Request message. 75 TradeDate N LocalMktDate Used to specify the trading date for which a set of market data applies, in YYYYMMDD format. Absence of this field indicates current day (expressed in local time at place of trade). 451 NetChgPrevDay N PriceOffset Net change from previous trading day s closing price vs. last traded price. 264 MarketDepth N Int Indicates the depth of the aggregate book (order depth book is always full depth), if applicable. [ Instrument identification block ] See Section Instrument Identification Block for tag values 268 NoMDEntries Y NumInGroup Number of entries following. 269 MDEntryType Y Char Type Market Data entry. Valid values: 0 = Bid 1 = Offer e = Aggregate bid f = Aggregate offer 2 = Trade 4 = Opening Price 5 = Closing Price 7 = Trading Session High Price 8 = Trading Session Low Price 9 = Trading Session VWAP Price B = Trade Volume X = Top of book offer Z = Top of book bid a = Referential prices BELL Rules of Engagement Page 58

59 Tag Tag Name Req d Data Type Comment b = Instrument trading phase c = Instrument state 270 MDEntryPx C Price Price of the Market Data Entry. Conditionally required when this market data entry involves a price. Represents the financial value for trade volume (B). Other entry types that do not involve price - such as trading phase (b) or instrument state (c) do not require this tag. 271 MDEntrySize C Qty Quantity or volume represented by the Market Data Entry. Conditionally required when MDEntryType = Bid (0), Offer (1), Aggregate bid (e), Aggregate offer (f), Trade (2), Top of Book Offer (X), Top of Book Bid (Z), Trade Volume (B) or Opening Price (4). 346 NumberOfOrders C Int Conditionally required if this is a price-depth book entry. Contains the number of orders that make up the aggregate quantity at the price point. 272 MDEntryDate Y UTCDateOnly Date of Market Data Entry. 273 MDEntryTime Y UTCTimeOnly Time of Market Data Entry. 286 OpenCloseSettlFlag N MultipleValueString Identifies if the opening price in field MDEntryPx represents a theoretical opening price. Value issued by BM&FBOVESPA: 5 Theoretical price. 336 TradingSessionID N String(32) Identifier for Trading Session. The counterparty may ignore this value. 625 TradingSessionSubID C String(2) Identifier for the trading phase. Conditionally required when MDEntryType= b. For possible values, see section TradSesOpenTime C UTCTimestamp Indicates the time the auction is scheduled to end. Conditionally required when MDEntryType= c and SecurityTradingStatus=102 (Auction) without random ending. 326 SecurityTradingStatus C Int Identifier for the security BELL Rules of Engagement Page 59

60 Tag Tag Name Req d Data Type Comment 37 OrderID C String(50) 274 TickDirection C Char trading status. Conditionally required when MDEntryType= c. Values sent by BM&FBOVESPA: 100: Not started 101: Trading 102: Auction 103: Forbidden 104: Finished Auction 105: Suspended 106: Pre Auction 107: Post Auction 108: Revoked 109: Canceled 110: Matching 111: No bidder 112: Minimum bid not reached 113: Adjudicated 114: Accepted 115: Impugned 116: Forbidden (reserved) 117: Subject to interference 118: Frozen 119: Extended auction 120: Expired 121: Random closing 122: Halted 123: Forbidden suspended 124: Forbidden trading 125: Forbidden frozen Unique identifier for Order as assigned by the exchange, maps to the SecondaryOrderID field in the Execution Report message for the derivatives market (for the FX market, it is the actual OrderID). It is unique per broker firm, per instrument, per trading date. Conditionally required when this Bid or Offer represents an order. Direction of the tick. Conditionally required if reporting a Trade. Valid values: 0 = Plus Tick 1 = Zero-Plus Tick 2 = Minus Tick 3 = Zero-Minus Tick BELL Rules of Engagement Page 60

61 Tag Tag Name Req d Data Type Comment 289 MDEntrySeller N String(50) 288 MDEntryBuyer N String(50) 290 MDEntryPositionNo N Int 6032 UniqueTradeID C String(32) 6932 NoReferentialPrices C NumInGroup 6934 ReferentialPriceType N Int 6933 ReferentialPx N Price For optional use in reporting trades (selling party) or indicating a new offer entry. Note: not sent in FX messages (blind screen). For optional use in reporting trades (buying party) or indicating a new bid entry. Note: not sent in FX messages (blind screen). Display position of a bid or offer, numbered from most competitive to least competitive, per market side, beginning with 1. Conditionally required when MDEntryType=0,1, e or f (Bid, Offer, Aggregate bid or Aggregate offer). Contains the unique identifier for this trade per instrument+trading date, as assigned by the exchange. Conditionally required if reporting a Trade. Indicates the number of referential prices in this message. Conditionally required if reporting referential prices. The type of the referential price. Values sent by BM&FBOVESPA: 0: Settlement price 1: Reference price 2: Operational tunnel upper limit 3: Operational tunnel lower limit 4: No referential price available 5: Previous day settlement price Larger than : ignore value Value of the reference price. If the value of this tag is , then the recipient should consider the price type indicated in tag 6934 as not BELL Rules of Engagement Page 61

62 Tag Tag Name Req d Data Type Comment 6290 *** Ignore *** N Char *** Ignore *** N Integer 60 TransactTime N UTCTimestamp [ Standard message trailer ] calculated yet. *** This tag will be deprecated, please ignore *** *** This tag will be deprecated, please ignore *** Timestamp the referential price was generated Market Data Incremental Refresh (MsgType = X) After a subscription for Market Data messages succeeded and the Market Data Snapshot/Full Refresh has been issued, further updates will be communicated to the subscriber via the Market Data Incremental Refresh message. These messages will be sent until the client institution cancels the subscription with a Market Data Request with SubscriptionRequestType= Book Management Considerations For bid or offer book entries (order and price depth book), the deletion is based on the entry s position (field MDEntryPositionNo). For example, assume ten bids for a security. Adding a bid with MDEntryPositionNo = 4 requires the receiver to shift down other Market Data Entries, i.e. the Market Data Entry in the 4 th display position will shift to the 5 th, the 5 th shifts to the 6 th, etc. until the 10 th shifts to the 11 th. BM&FBOVESPA will not send a modification of all MDEntries in the 4 th through 10 th positions just to update the MDEntryPositionNo field; the counterparty must infer the change. Similarly, deleting a Market Data Entry in the 7 th position causes the 8 th Market Data Entry to move into the 7 th position, the 9 th to shift into the 8 th position, etc. BM&FBOVESPA will not issue a change action to modify the position of an entry in the book. Change updates are only sent when a value applicable to a specific MDEntryPositionNo such as total quantity or number of orders changes Price-depth Bottom Row Handling For price-depth book only, the recipient of the market data must know how many price levels are being supplied by BM&FBOVESPA. The recipient must delete the bottom price row when the number of price rows is exceeded BM&FBOVESPA will not send a delete of the bottom row when the number is exceeded. BM&FBOVESPA will send the bottom row again when a higher level row is deleted. The following example illustrates this behavior: Buy-side book Number of Orders Qty Price Top row of the book (best bid). Bottom row of the book. New buy order is received (BUY 10.60), updating the top of the book (bid): Market Data Incremental Refresh MDEntryPositionNo 1 MDUpdateAction New BELL Rules of Engagement Page 62

63 MDEntrySize 1000 MDEntryPx NumberOfOrders 1 Implicit deletion of the previous bottom row. Buy-side book Number of Orders Qty Price New bottom row of the book. The order with price is deleted (CANCEL BUY 10.57): Market Data Incremental Refresh MDEntryPositionNo 3 MDUpdateAction Delete MDEntryPositionNo 5 MDUpdateAction New MDEntrySize 8000 MDEntryPx NumberOfOrders 3 New bottom row will be sent by BM&F. Buy-side book Number of Orders Qty Price New bottom row of the book Message Specification Tag Tag Name Req d Data Type Comment [ Standard message header ] 75 TradeDate N LocalMktDate Used to specify the trading date for which a set of market data applies, in YYYYMMDD format. Absence of this field indicates current day (expressed in local time at place of trade) *** Ignore *** N String *** Please ignore this tag *** 268 NoMDEntries Y NumInGroup Number of entries following. 279 MDUpdateAction Y Char Type of Market Data update action. Valid values: 0 = New 1 = Change 2 = Delete 269 MDEntryType Y Char Type Market Data entry. Valid values: 0 = Bid BELL Rules of Engagement Page 63

64 Tag Tag Name Req d Data Type Comment 1 = Offer e = Aggregate bid f = Aggregate offer 2 = Trade 4 = Opening Price 5 = Closing Price 7 = Trading Session High Price 8 = Trading Session Low Price 9 = Trading Session VWAP Price B = Trade Volume X = Top of book offer Z = Top of book bid a = Referential prices b = Instrument trading phase c = Instrument state 278 MDEntryID Y String(32) Market Data Entry identifier. May be ignored. [ Instrument identification block ] See Section Instrument Identification Block for tag values 270 MDEntryPx C Price Price of the Market Data Entry. Conditionally required when this market data entry involves a price. Represents the financial value for trade volume (B). Other entry types that do not involve price - such as trading phase (b) or instrument state (c) do not require this tag. 271 MDEntrySize C Qty Quantity or volume represented by the Market Data Entry. Conditionally required when MDUpdateAction = New (0) and MDEntryType = Bid (0), Offer (1), Aggregate bid (e), Aggregate offer (f), Trade (2), Top of Book Offer (X), Top of Book Bid (Z), Trade Volume (B) or Opening Price (4). 346 NumberOfOrders C Int Contains the number of orders that make up the aggregate quantity at the price point. Conditionally required if this is a price-depth book entry. 272 MDEntryDate Y UTCDateOnly Date of Market Data Entry. 273 MDEntryTime Y UTCTimeOnly Time of Market Data Entry. 286 OpenCloseSettlFlag N MultipleValueString Identifies if the opening price in field MDEntryPx represents a theoretical opening price. Value issued by BM&FBOVESPA: BELL Rules of Engagement Page 64

65 Tag Tag Name Req d Data Type Comment 336 TradingSessionID N String(32) 625 TradingSessionSubID C String(2) 342 TradSesOpenTime C UTCTimestamp 326 SecurityTradingStatus C Integer 37 OrderID N String(50) 5 Theoretical price. Identifier for Trading Session. The counterparty may ignore this value. Identifier for the trading phase. For possible values, see section Conditionally required when MDEntryType= b. Indicates the time the auction is scheduled to end. Conditionally required when MDEntryType= c and SecurityTradingStatus=102 (Auction) without random ending. Identifier for the security trading status. Conditionally required when MDEntryType= c. Values sent by BM&FBOVESPA: 100: Not started 101: Trading 102: Auction 103: Forbidden 104: Finished Auction 105: Suspended 106: Pre Auction 107: Post Auction 108: Revoked 109: Canceled 110: Matching 111: No bidder 112: Minimum bid not reached 113: Adjudicated 114: Accepted 115: Impugned 116: Forbidden (reserved) 117: Subject to interference 118: Frozen 119: Extended auction 120: Expired 121: Random closing 122: Halted 123: Forbidden suspended 124: Forbidden trading 125: Forbidden frozen For optional use when this Bid or Offer represents an order. Unique identifier for Order as assigned by the exchange, maps to the SecondaryOrderID field in the Execution Report BELL Rules of Engagement Page 65

66 Tag Tag Name Req d Data Type Comment 274 TickDirection N Char 451 NetChgPrevDay N PriceOffset 289 MDEntrySeller N String(50) 288 MDEntryBuyer N String(50) 290 MDEntryPositionNo C Int 6032 UniqueTradeID C String(32) 285 DeleteReason C Char 6932 NoReferentialPrices C NumInGroup 6934 ReferentialPriceType C Int message for the derivatives market (for the FX market, it is the actual OrderID). It is unique per broker firm, per instrument, per trading date. Direction of the tick. Valid values: 0 = Plus Tick 1 = Zero-Plus Tick 2 = Minus Tick 3 = Zero-Minus Tick Net change from previous trading day s closing price vs. last traded price. For optional use in reporting Trades. Selling party in a trade. For optional use in reporting Trades. Buying party in a trade. Display position of a bid or offer, numbered from most competitive to least competitive, per market side, beginning with 1. Conditionally required when MDEntryType=0,1, e or f (Bid, Offer, Aggregate bid or Aggregate offer). Contains the unique identifier for this trade per instrument + trading date, as assigned by the exchange. Conditionally required if reporting a Trade. Reason for trade bust. Values issues by BM&FBOVESPA: 0 trade bust 1 error (reserved for future use) Indicates the number of referential prices in this message. Conditionally required if reporting referential prices. The type of the referential price. Values sent by BM&FBOVESPA: 0: Settlement price 1: Reference price 2: Operational tunnel upper limit 3: Operational tunnel lower limit 4: No referential price available BELL Rules of Engagement Page 66

67 Tag Tag Name Req d Data Type Comment 5: Previous day settlement price 6933 ReferentialPx C Price 6290 *** Ignore *** N Char *** Ignore *** N Integer 60 TransactTime N UTCTimestamp [ Standard message trailer ] Larger than : ignore value Value of the reference price. If the value of this tag is , then the recipient should consider the price type indicated in tag 6934 as not calculated yet. *** This tag will be deprecated, please ignore *** *** This tag will be deprecated, please ignore *** Timestamp the referential price was generated Security Status (MsgType = f) 4 The Security Status message relays trading phase changes of a specific instrument group. The customer knows by usage of the Security List message which instruments belong to a group. The new trading phase is specified in the TradingSessionSubID field. In the long term this message will deprecate MDEntryType = b (trading phase) i.e. BM&FBOVESPA will stop broadcasting security status information as an MDEntryType, and use this message. Currently, the customer may receive the same information on a per instrument basis by subscribing to this MDEntryType. For individual instrument status, subscription to MDEntryType = c should still be used. Please contact BM&FBOVESPA for availability of this message. This functionality is not available to all products. Tag Tag Name Req d Data Type Comment [ Standard message header ] 9918 SecurityGroup N String(15) The instrument group that is changing trading phase. [ Instrument identification block ] See Section Instrument Identification Block for tag values 625 TradingSessionSubID Y String(2) Identifier for the trading phase. For possible values, see section SecurityTradingStatus N Integer Values sent by BM&FBOVESPA: 100: Not started 101: Trading 102: Auction 103: Forbidden 4 Contact BM&F for availability. This functionality is not available to all products. BELL Rules of Engagement Page 67

68 Tag Tag Name Req d Data Type Comment 104: Finished Auction 105: Suspended 106: Pre Auction 107: Post Auction 108: Revoked 109: Canceled 110: Matching 111: No bidder 112: Minimum bid not reached 113: Adjudicated 114: Accepted 115: Impugned 116: Forbidden (reserved) 117: Subject to interference 118: Frozen 119: Extended auction 120: Expired 121: Random closing 122: Halted 123: Forbidden suspended 124: Forbidden trading 125: Forbidden frozen [ Standard message trailer ] Event Communication News (MsgType = B) The News message is utilized to publish news information from BM&FBOVESPA to the connected community. News published by BM&FBOVESPA may be: Security-specific news (such as beginning of auction or settlement price information); BM&FBOVESPA official notices; Generic news. News messages are disseminated to all FIX connections on a request basis. When requesting a FIX connection to BM&FBOVESPA, please indicate if that session should receive News messages or not. BM&FBOVESPA does not support retransmission of News messages on the application level, only as FIX session level retransmissions. Tag Tag Name Req d Data Type Comment [ Standard message header ] Time of message origination (always expressed in 42 OrigTime N UTCTimestamp UTC - Universal Time Coordinated, also known as GMT ) 6940 NewsSource Y String(50) Indicates the source of the news. Values issued by BM&FBOVESPA: BELL Rules of Engagement Page 68

69 Tag Tag Name Req d Data Type Comment DCM BBMNet MarketSurveillance Internet DPR-VE 6936 Language Y String(10) Indicates the language the news is in. Represented by the two-letter ISO standard identification. Absence of this field defaults to pt Portuguese. 148 Headline N String(100) The headline of a News message. 146 NoRelatedSym N NumInGroup Specifies the number of repeating symbols (instruments) specified. [ Instrument identification block ] See Section Instrument Identification Block for tag values 33 NoLinesOfText Y NumInGroup Identifies number of lines of text body. 58 Text Y String Repeating field, number of instances defined in NoLinesOfText. 149 URLLink N String A URL (Uniform Resource Locator) link to additional information (e.g. ) 215 NoRoutingIDs Y NumInGroup Indicates the number of destinations of this message. 216 RoutingType Y Int Indicates the type of RoutingID (217) specified. Values issued by BM&FBOVESPA: 2 = Target List. 217 RoutingID Y String(1) Assigned value used to identify a specific routing destination. Values issued by BM&FBOVESPA: 1 = Vendors 2 = Traders 3 = BM&FBOVESPA RSS feed 4 = BBMNet 5 = GLOBEX [ Standard message trailer ] General Business Message Reject ( MsgType = j ) The Business Message Reject message can reject an application-level message which fulfills session level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject message will be issued. Tag Tag name Req d Data type Comment [ Standard message header ] 45 RefSeqNum N Int MsgSeqNum of rejected message. 372 RefMsgType Y String The MsgType of the FIX message being referenced. 379 BusinessRejectRefID C String(50) The value of the business-level ID field on the message being referenced. Required unless the BELL Rules of Engagement Page 69

70 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Tag Tag name Req d Data type Comment corresponding ID field was not specified. Code to identify the reason of the rejection. Valid values: 0 = Other 1 = Unknown ID = Unknown Security BusinessRejectReason Y Int 3 = Unsupported Message Type 4 = Application not available 5 = Conditionally Required Field Missing 6 = Not authorized 99 = Throttle Limit Exceeded 58 Text N String(50) Message to explain reason for rejection, if available. [ Standard message trailer ] BELL Rules of Engagement Page 70

71 Document Owner Post Trading BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Position Maintenance Request (MsgType = AL) The Position Maintenance Request message is used to perform option exercise. It is followed by a Position Maintenance Report message, which contains the operation outcome (e.g. accepted, rejected, rejected with warnings). Tag Tag Name Req d Data Type Comment [ Standard message header ] 1 Account N String Account mnemonic as agreed between buy and sell sides [ Instrument identification block ] See Section Instrument Identification Block for tag values Time of execution/order creation 60 TransactTime Y UTCTimestamp (expressed in UTC (Universal Time Coordinated, also known as "GMT") 453 NoPartyID Y NumInGroup Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole. 448 PartyID Y String(50) Used to identify source of PartyID. 447 PartyIDSource Y Char Identifies class or source of the PartyID (448) value. Value accepted by BM&FBOVESPA: D = Proprietary/Custom code 452 PartyRole Y Int Identifies the type or role of the PartyID (448) specified. Values issued by BM&FBOVESPA: 4 Clearing Firm 7 Entering Firm 36 Entering Trader Type of account associated with an order. 581 AccountType N Int Valid values: 3 = House Trader 660 AcctIDSource N Int Used to identify the source of the Account (1) code. Valid values: 99 = Other 702 NoPositions Y NumInGroup Number of position entries. 703 PosType Used to identify the type of quantity that is Y String being returned. Valid values: EX = Option Exercise Qty 705 ShortQty Y Qty Short Quantity 976 QuantityDate Date associated to the quantity that is Y LocalMktDate being reported for the position. PosTransType Identifies the type of position transaction. 709 Y Int Valid values: 1 = Exercise BELL Rules of Engagement Page 71

72 PosReqID PosMaintAction ClearingBusinessDate Y Y Y Unique identifier for the position String maintenance request as assigned by the submitter. Maintenance Action to be performed. Valid values: Int 1 = New: used to increment the overall transaction quantity The "Clearing Business Date" referred to LocalMktDate by this maintenance request. [ Standard message trailer ] Position Maintenance Report (MsgType = AM) The Position Maintenance Report messages is sent as the reply of a Position Maintenace Request message. Tag Tag Name Req d Data Type Comment [ Standard message header ] 1 Account N String Account mnemonic as agreed between buy and sell sides [ Instrument identification block ] See Section Instrument Identification Block for tag values 58 Text N String Error description, if applicable 60 TransactTime Y UTCTimestamp Time of execution/order creation (expressed in UTC (Universal Time Coordinated, also known as "GMT") 453 NoPartyID Y NumInGroup Repeating group below should contain unique combinations of PartyID, PartyIDSource, and PartyRole. 448 PartyID Y String(50) Used to identify source of PartyID. 447 PartyIDSource Y Char Identifies class or source of the PartyID (448) value. Value accepted by BM&FBOVESPA: D = Proprietary/Custom code 452 PartyRole Y Int Identifies the type or role of the PartyID (448) specified. Values issued by BM&FBOVESPA: 4 Clearing Firm 7 Entering Firm 36 Entering Trader Type of account associated with an order. 581 AccountType N Int Valid values: 3 = House Trader 702 NoPositions Y NumInGroup Number of position entries. 703 PosType Used to identify the type of quantity that is Y String being returned. Valid values: EX = Option Exercise Qty 705 ShortQty Y Qty Short Quantity BELL Rules of Engagement Page 72

73 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department 976 QuantityDate Date associated to the quantity that is Y LocalMktDate being reported for the position. 753 NoPosAmt Y NumInGroup Number of Position Amount entries 707 PosAmtType Type of Position amount. Valid values: Y String CASH = Cash Amount (Corporate Event) 708 PosAmt Y Amount Position amount PosTransType 709 Y Int 1 = Exercise PosReqID 710 Y String submitter. PosMaintAction OrigPosReqRefID Y Y Int String Identifies the type of position transaction. Valid values: Unique identifier for the position maintenance request as assigned by the Maintenance Action to be performed. Valid values: 1 = New: used to increment the overall transaction quantity Reference to the PosReqID (710) of a previous maintenance request that is being replaced or canceled. ClearingBusinessDate The "Clearing Business Date" referred to 715 Y LocalMktDate by this maintenance request. 721 PosMaintRptID Y String Unique identifier for this position report PosMaintStatus PosMaintResult ThresholdAmount Y N N Int Int PriceOffset [ Standard message trailer ] Status of Position Maintenance Request. Valid values: 2 = Rejected 3 = Completed 4 = Completed with Warnings Result of Position Maintenance Request. Valid values: 0 = Successful Completion - no warnings or errors 1 = Rejected 99 = Other Amount that a position has to be in the money before it is exercised. BELL Rules of Engagement Page 73

74 9.5 Order Types Supported The following order types are supported by BM&FBOVESPA: Limit Stop Limit Market with Leftover as Limit Limit Orders Limit orders specify the worst price at which the order may execute, i.e. an order to buy a security at or below a stated price (defined in tag 44 Price), or to sell a security at or above a stated price. If the order does not execute, it will remain in the order book. Validation rules: Minimum quantity is allowed; Minimum quantity is not allowed if instrument is in the auction state; Disclosed quantity is allowed; Disclosed quantity must be less than the total order quantity; Disclosed quantity must be at least 10 times the size of the instrument round lot; Disclosed quantity is invalid with time in force IOC or FOK; Disclosed quantity and minimum quantity cannot be set for the same order; Stop Limit Orders Stop limit orders are associated with a trigger price or stop price at which it becomes a limit order. The order will be inserted into the order book as soon as the first trade occurs at the specified stop price (tag 99 StopPx). From this point on, it will behave as a regular limit order, with the price defined in tag 44 Price. Validation rules: Minimum quantity is not allowed Disclosed quantity is not allowed The limit price for a buy stop limit must be >= the trigger price The limit price for a sell stop limit must be <= the trigger price Time in force can be either Day or IOC The trigger price must be >= last traded price for that instrument Market with Leftover as Limit Market with leftover as limit orders will behave like a regular market order, and any unexecuted quantity will become a limit order in the order book, with its limit price set at the last executed price. Validation rules: Disclosed quantity is allowed Minimum quantity is allowed BELL Rules of Engagement Page 74

75 9.6 Order Validity Types (Time in Force) Supported The following order validities are supported in BELL: Day IOC (FAK) FOK Day Orders Day orders are available in the order book until they execute or are cancelled (either by the customer who submitted it or BM&FBOVESPA market operations). At the end of the day all orders are cancelled by the match engine during the cancel orders trading phase, and the customers who submitted them will receive the Execution Reports expiring the orders (tag 150= C ). Msg sent Msg received ClOrdId OrderId Price Qty D ABC Exec Type Ord Status 8 ABC New New Last Qty Last Price Comment Instrument is in continuous trading mode. Execution Report confirming receipt is sent back to customer. Order is partially filled for Partially 8 ABC Trade Filled Instrument goes into cancel orders trading phase. 8 ABC Expired Canceled Order is expired IOC (FAK) Orders IOC (Immediate or Cancel) or FAK (Fill And Kill) orders are orders that require immediate execution, and the unexecuted quantity is automatically expired. If there is no counterparty to execute against, the order is rejected. Msg sent Msg received ClOrdId OrderId Price Qty Exec Type Ord Status Last Qty Last Price Comment D ABC Instrument is in continuous trading mode. Execution Report 8 ABC New New confirming receipt is sent back to customer. 8 ABC Trade Partially Order is partially filled Filled for ABC Expired Canceled Order is expired FOK Orders FOK (Fill Or Kill) orders require that the full amount stated in the order is executed upon entering the order book. If there is not enough quantity on the opposite side to fill the order, the order is rejected. Msg Msg Exec Ord Last Last ClOrdId OrderId Price Qty sent received Type Status Qty Price Comment D ABC Instrument is in continuous trading mode. Execution Report 8 ABC Reject Rejected rejecting the order, since there s no opposite side. BELL Rules of Engagement Page 75

76 9.7 Trading on Behalf An order may be entered into the trading system on behalf of another firm or another trader. There are two terms to specify the parties on an order: the entering trader (or firm) and the executing trader (or firm). The entering trader is the trader who owns the order, i.e. the trader whose limits will be applied to, or the one against whose account the settlement will occur. The executing trader is the trader that actually inserts the order into the trading system. Most of the time, the entering trader is the executing trader; therefore there is no need to specify the executing trader. However, when a trader inserts an order into the system on behalf of another trader (i.e. is trading on behalf of another trader), this trader is the executing trader. To correctly specify to BM&FBOVESPA the order parties, the NoPartyID repeating group must be correctly filled. The following combinations are allowed: Scenario 1: Trader entering order for him/herself Trader ABC enters order. Msg Msg Exec ClOrdId OrderId Price Qty sent received Type Ord Status NoPartyID repeating group NoPartyID = 1 PartyID PartyIDSource PartyRole D ABC ABC D (Entering trader) Execution report is sent back to entering trader NoPartyID = 1 PartyID PartyIDSource PartyRole 8 ABC New New 36 ABC D (Entering trader) Scenario 2: Trader entering order on behalf of another trade Trader ABC enters order on behalf of trader DEF. Notice that a copy of the Execution Report for that order will be sent to entering trader (the order owner ) as well. Further updates to that order s state will also be copied to the entering trader. Msg sent Msg received ClOrdId OrderId Price Qty D ABC Exec Type Ord Status NoPartyID repeating group NoPartyID = 2 PartyID PartyIDSource PartyRole ABC D 12 (Executing trader) DEF D 36 (Entering trader) Execution report is sent back to executing trader (ABC) NoPartyID = 2 PartyID PartyIDSource PartyRole ABC D 12 8 ABC New New (Executing trader) DEF D 36 (Entering trader) Execution report is sent back to entering trader (DEF) 8 ABC New New NoPartyID = 2 PartyID PartyIDSource PartyRole BELL Rules of Engagement Page 76

77 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department ABC D 12 (Executing trader) DEF D 36 (Entering trader) BELL Rules of Engagement Page 77

78 9.8 Trade Give-ups A trade may be given up to another firm, i.e. the firm that carries the position is a firm other than the executing firm (the firm that put the order in the market). Give-ups may be done post-trade (via the BM&FBOVESPA Serviços website) or pre-trade, indicating the give up in the order message. The giveup is uniquely identified by what is called in BM&FBOVESPA a give-up link number. The give-up indication is done in the order message by setting the transfer to firm PartyRole (tag 452) in the Parties repeating group with the bipartite link number. Once the trade is made, the take up firm (the firm the trade was given up to) will receive notification and will accept or reject the trade. If the take up firm rejects the trade, the position is carried by the executing firm. The following example illustrates a pre-trade give-up indication: Consider that customer 1234 was assigned a give-up link number, with executing firm = GHI and giveup firm is DEF. The give-up link number is Trader ABC is the trader that puts the order in the market. Msg sent Msg received ClOrdId Price Qty NoPartyID repeating group D ABC NoPartyID = 3 PartyID PartyIDSource PartyRole ABC D 36 (Entering trader) GHI D 7 (Entering firm) 9898 D 40 (Transfer to firm) BELL Rules of Engagement Page 78

79 9.9 Program Trading, Foreign Investors and DMA Clients BM&FBOVESPA requires that all order-related messages (new order, modification, cancellation) originating from: Program trading (algo boxes); or Order routing solutions through a DMA provider or another exchange for a foreign end customer account. To be marked as such. For this purpose, the executing party of the order (the executing firm, DMA provider or exchange) must fill in tag 529 (OrderRestrictions). This field is of type MultipleValueString, i.e. a set of values may apply separated by blank spaces. Hence: If the order is originating from program trading, set field 529 to 1 - Program Trade; If the order is originating from an international DMA provider, or another exchange, set field 529 to 8 External Market Participant If the order is allocated to a foreign end-customer account, set field 529 to 7 Foreign entity. For example: Example Order originates from an international DMA provider, for a foreign end-customer Order is originated from another exchange for a foreign end-customer Foreign hedge fund originates the order, trading on its own account, via program trading Tag 529 value Please note that tag 529 should be set to 7 in case the end-customer account is registered pursuant to the provisions of Resolutions 2689 and 2687 issued by the Central Bank of Brazil DMA Identification BM&FBOVESPA requires that all order messages (New Order Single, Order Cancel Request and Order Cancel Replace Request) generated by DMA clients (either by DMA provider or direct connection to BM&FBOVESPA) contain the information of origin, broker firm associated with the order (entering firm) and the trader which entered the order (entering trader). This information must be in the Parties component block of each of the messages, as follows: PartyRole=54 (Sender Location): The value that is supposed to be put in the PartyID tag (448) for PartyRole=54 will be provided by BM&FBOVESPA to the connecting client as of the certification process. This value will be the same for all order/modification/cancel requests coming from that connection. This value is limited to 5 bytes; PartyRole=7 (Entering Firm): The value that is supposed to be put in the PartyID tag (448) for PartyRole=7 must be the BM&FBOVESPA broker firm code associated with the firm that is providing access to the BM&FBOVESPA market. May be different for each order/modification/cancel request coming to a single BELL FIX connection. For more details on the code, please see below; PartyRole=36 (Entering Trader): The value that is supposed to be put in the PartyID tag (448) for PartyRole=36 must be the identification of the operator that has entered the order at the DMA provider or DMA client. The entering trader for DMA clients is not registered at BM&FBOVESPA, but is required due to Brazilian regulatory requirements and will be stored for post-trade. This value is limited to 25 bytes. BELL Rules of Engagement Page 79

80 IMPORTANT Failure to send any of the 3 PartyRoles listed, will cause a rejection of the order/modification/cancel request. For a list of available BM&FBOVESPA broker firm codes, please see the BM&FBOVESPA website at: And click on: About BM&FBOVESPA Participants Participants; Select Brokerage House in the Categories group, and click Search. The following table illustrates an example of a DMA provider (e.g. XYZ ) sending a New Order Single to BM&FBOVESPA, entered by trader ABC : Msg sent Msg received ClOrdId Price Qty NoPartyID repeating group D ABC NoPartyID = 3 PartyID PartyIDSource PartyRole XYZ D 54 (Sender Location) ZZZ D 7 (Entering Firm) ABC D 36 (Entering trader) It is important to take in consideration that the entering firm code must be exactly as listed at the BM&FBOVESPA website since this field is a string, is different than 188. To verify if the connecting client is considered a DMA client or not, and to get a list of BM&FBOVESPA broker firm codes, please contact BM&FBOVESPA at [email protected] or [email protected] Account Allocation Restrictions for DMA Customers DMA customers that connect to BELL FIX are required to either: Allocate their orders pre-trade, i.e. stating the account in tag 79 (AllocAccount, in the NoAllocs repeating group) in the New Order Single and Order Cancel Replace Request messages, or Indicate the give-up code in PartyRole 40 (transfer to firm) in the Parties component block. IMPORTANT Orders originated by DMA customers without account allocation or giveup code information will be rejected by BELL. In addition, orders that are already available in the order book may not have their allocation account or give-up code modified. For changing these order characteristics pre-trade, the DMA customer will first need to cancel the order, and then issue a new order with the desired account. BELL Rules of Engagement Page 80

81 9.10 New Order Cross Execution Rules at BM&FBOVESPA Crossed orders sent into BM&FBOVESPA may have a different behavior than just plain trade registration. Each instrument may be configured by market surveillance to process a crossed order differently. This configuration causes the order to: Break each leg of the crossed order into a child limit order that execute immediately against each other (normal crossed order behavior); or Break each leg of the crossed order into a child limit order that execute against orders existing in the order book; or Break each leg of the crossed order into a child order and initiate an auction at the price of the crossed order, for both the buy and sell sides; or Reject the crossed order entirely (crossed order not allowed for that instrument in that particular order book instance, as defined in BM&FBOVESPA Regulation for cross orders). BM&FBOVESPA recommends the reading of BM&FBOVESPA regulation in conjunction with this BM&FBOVESPA FIX Specification for better understanding of cross orders Immediate Execution of Crossed Order In this configuration, a crossed order is immediately executed upon arriving at the order book, and Execution Report messages (one for each leg) indicating the execution are sent to the crossed order originator. Subsequently, a new trade is sent in the Market Data feed. Each Execution Report references the cross order by the CrossID field and the legs are referenced by the ClOrdID field, sent in the original cross order message. The order originator (e.g. the trader) may not take individual action on the legs of the crossed order. Example Consider a crossed order for that is sent to BM&FBOVESPA and executes immediately. The following table illustrates the messages at a high-level (with the most relevant fields) that are exchanged in this scenario. Msg sent Msg received CrossID Price Qty s ABC Ord Status Exec Type Cum Qty Leaves Qty Last Px Last Qty ClOrdId ORD_1 (Buy) ORD_2 (Sell) 8 ABC New New ORD_1 8 ABC New New ORD_2 Buy child order (ORD_1) executes against sell child order 10.58) 8 ABC Filled Trade ORD_2 8 ABC Filled Trade ORD_1 Comment New Order Cross from trader. Buy leg is ack ed. Sell leg is ack ed. Sell leg is filled. Buy leg is filled. BELL Rules of Engagement Page 81

82 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department Crossed Order Legs that Execute Against Existing Orders In this configuration, a crossed order is broken into two child limit orders, with the crossed order price and quantity, for each side (buy and sell). Each child order is identified by the ClOrdID field sent in the original crossed order message, and the orders may execute against existing orders in the order book. Example: Consider the following order book: Bid Qty Price Offer Qty A crossed order is received for this instrument, with quantity 7000 and price 10.58; this instrument is configured to convert a crossed order into two child limit orders. This will cause the following chain of events: The cross order will be broken into two child orders: buy and sell 10.58; The sell child order will execute against the existing order (buy 10.58), with a leaves quantity of 2000; The remaining 2000 quantity of the sell child order will be executed against the buy child order 10.58). The buy child order will have a remaining quantity of Hence the resulting order book will be: Bid Qty Price Offer Qty The following table illustrates the messages at a high-level (with the most relevant fields) that are exchanged in this scenario. Msg sent Msg received CrossID Price Qty s ABC Ord Status Exec Type Cum Qty Leaves Qty Last Px Last Qty ClOrdId ORD_1 (Buy) ORD_2 (Sell) 8 ABC New New ORD_1 8 ABC New New ORD_2 Sell child order (ORD_2) executes against existing order buy ABC Partially Filled Trade ORD_2 Remaining buy child order (ORD_2) quantity executes against sell child order (ORD_1) Comment New Order Cross from trader. Buy leg is ack ed. Sell leg is ack ed. Sell leg is executed for BELL Rules of Engagement Page 82

83 8 ABC Filled Trade ORD_2 8 ABC Partially Filled Trade ORD_1 Sell leg is filled. Buy leg is partially filled Auction Triggered by Crossed Order In this configuration, a crossed order is broken into two child orders, with the crossed order price and quantity, for each side (buy and sell). Each child order is identified by the ClOrdID field sent in the original crossed order message. This triggers an auction for the instrument, and each child order may be executed separately. While the auction is in effect, the order originator may not take individual action on both child orders; rather, he/she will be able to act on the cross order itself. After the auction ends, the unexecuted leg of the crossed order may remain in the order book, or may be cancelled by market surveillance. From this point on, it behaves as a normal order and may be acted upon by the order originator. Example: Consider the following order book: Bid Qty Price Offer Qty A crossed order is received for this instrument, with quantity 7000 and price 11.00; this instrument is configured to trigger an auction upon receiving such cross order. Hence it will then be: Bid Qty Price Offer Qty Msg sent Msg received CrossID Price Qty OrdStatus s ABC Exec Type CumQty Leaves Qty ClOrdId ORD_1 (Buy) ORD_2 (Sell) 8 ABC New New ORD_1 8 ABC New New ORD_2 Comment New Order Cross from trader. Buy leg is ack ed. Sell leg is ack ed. Notice that the crossed order is not immediately executed, and the instrument will remain in auction status for a period of time configured by market surveillance. A market data incremental refresh is sent indicating BELL Rules of Engagement Page 83

84 Document Owner BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department the new orders price points and the instrument status change to auction. Consider that the buy leg of the order is executed, and sell leg remains unexecuted in the order book. The order book will be then be: Bid Qty Price Offer Qty Msg received Cross ID Price Qty Ord Status Exec Type Cum Qty Leaves Qty Last Px Last Qty Cl OrdId Comment 8 ABC Filled Trade ORD_1 Buy leg is executed. Subsequently, a market data incremental refresh is sent, deleting the buy leg s entry and notifying the trade. BELL Rules of Engagement Page 84

85 9.11 In-flight Modification and Interpretation of the OrderQty Field The OrderQty field is interpreted by BM&FBOVESPA as the total investor quantity, i.e. the total size of the order. That stands true for order modification requests as well. Hence, the connecting counterparty must take this into consideration when implementing cancel/replacement logic, especially regarding in-flight modification scenarios (where the order is executed at the exchange at the same time the counterparty issues a modification request for that same order). The following scenarios represent a high-level overview of the messages exchanged (with the most relevant fields only) for different situations that represent the interpretation of OrderQty. In a nutshell, BM&FBOVESPA always uses in flight modification. Scenario 1: Plain modification of previously sent order In this scenario, an order is sent (BUY 12), and has its quantity increased to 1400 due to a modification request. Msg sent Msg received ClOrdID OrderID OrigCl OrdID Price Qty D ABC Ord Status Exec Type Cum Qty Leaves Qty 8 ABC1 ORD_ New New Trader issues a modification request to increase quantity to G MOD1 ORD_1 ABC ABC1 ORD_ New Replace Comment New Order from trader. Order is ack ed by exchange. Order qty is increased to 1400 by trader. Modificaion is ack ed by exchange. Scenario 2: In-flight modification of previously sent order In this scenario, an order is sent (BUY 12), which partially executes for 200. Concurrently (i.e., before receiving the Execution Report notifying the partial fill of 200), the counterparty issues a modification request to increase its quantity to Msg sent Msg received ClOrd ID Order ID Price Qty Ord Status Exec Type Cum Qty Leaves Qty Last Qty Last Price Comment D ABC New Order from trader. Order is 8 ABC1 ORD_ New New ack ed by exchange. The order executes for The partial fill notification does not reach the trader yet. Trader issues a modification request for the same order, increasing quantity to Order qty is G MOD1 ORD_ increased to 1300 by trader. Trader receives the Execution Report for the partial fill 12.00) 8 ABC1 ORD_ Partially Filled Trade Partial fill is received by trader. Here, the order is modified in the match engine, with its total investor quantity increased to 1300, even though 200 were already executed. BELL Rules of Engagement Page 85

86 8 ABC1 ORD_ Partially filled Replace Modificaion is ack ed by exchange. Scenario 3: Rejected in-flight modification of previously sent order In this scenario, an order is sent (BUY 12.00), which partially executes for 800 (remaining quantity = 200). Concurrently, the counterparty issues a modification request trying to decrease the order quantity from the original 1000 to 700. Msg sent Msg received ClOrd ID Order ID Price Qty Ord Status Exec Type Cum Qty Leaves Qty Last Qty Last Price Comment D ABC New Order from trader. 8 ABC1 ORD_ New New Order is ack ed by exchange. The order executes for The partial fill notification does not reach the trader yet. Trader issues a modification request for the same order, decreasing quantity to 700. Order qty is G MOD1 ORD_ decreased to 700 by trader. Trader receives the Execution Report for the partial fill 12.00) 8 ABC1 ORD_ Partially Partial fill is Trade Filled received by trader. Here, the order is expired, and modification is rejected by the match engine, since its new total investor quantity (700) is less than the order's cumulative quantity (800). Order is expired 8 ABC1 ORD_ Canceled Expired by the match engine. 9 MOD1 Modification is rejected by exchange, with CxlRejReason=99, and error message in field 58 (Text). BELL Rules of Engagement Page 86

87 9.12 Trade Cancellations (Trade Busts) BM&FBOVESPA Market Surveillance may cancel trades according to BM&FBOVESPA market rules. Once a trade is cancelled (busted), the following events occur: A Market Data Incremental Refresh message will be sent to the market, with the update action = Delete and containing the trade identification in field UniqueTradeID and; An Execution Report message with ExecType= H (Trade Cancelled) will be sent to all the parties participated in that trade. 5 A trade that is cancelled does not roll back the state of the order that participated in the trade, i.e. the order is not reinstated in the order book. Tags LastQty and LastPrice will contain the quantity and price of the trade busted, respectively. The following scenario illustrates the messaging behaviour during a trade cancel: Msg sent Msg received ClOrd ID Symbol Price Qty D ABC Ord Status Exec Type Cum Qty Unique TradeID 8 ABC1 WDLH New New 0 1 Last Qty Last Price Comment New Order from trader. Order is ack ed by exchange. The order is filled for Fill is received by 8 ABC1 WDLH Filled Trade trader. BM&FBOVESPA Market Surveillance cancels the trade. Market Data Incremental Refresh is sent over the market data feed: MDUpdateAction=2, Symbol=WDLH08 and 8 ABC1 WDLH Filled UniqueTradeId=1 Trade Cancelled Trade cancel is received. The status of the order does not change with the trade bust, and the client should rely on the information in the ExecType field to convey the cancellation. The UniqueTradeID field (tag 6032) is unique per instrument, per trading session. The following scenario illustrates a new order, partial execution, trade cancellation and a complete fill: Msg Msg ClOrd Ord Exec Cum Unique Last Last Symbol Price Qty Comment sent received ID Status Type Qty TradeID Qty Price New Order from D ABC trader. Order is ack ed 8 ABC1 WDLH New New 0 1 by exchange. 8 ABC1 WDLH The order is partially filled for Partially filled Trade Partial fill is received by trader. BM&FBOVESPA Market Surveillance cancels the trade. Market Data Incremental Refresh is sent over the market data feed: MDUpdateAction=2, Symbol=WDLH08 and UniqueTradeId=1 Partially Trade Trade cancel is 8 ABC1 WDLH filled Cancelled received. The order is filled for ABC1 WDLH Filled Trade Order is filled. 5 Contact BM&F for availability BELL Rules of Engagement Page 87

88 9.13 Order Identification When a client submits an order and the order is accepted by the match engine, the acknowledgement is sent to the client in an Execution Report message (tag 35=8). This message contains the following order identifiers: ClOrdId field (tag 11) echoing back the original ClOrdId value sent in the order submission message (tag 35=D); and OrderID field (tag 37), which is exchange generated, and is unique per instrument, per trading session. This value is immutable throughout the order s lifecycle; and SecondaryOrderID field (tag 198), which is exchange generated, and changes on every modification or replenishment event for disclosed orders. The following scenario illustrates how these values change throughout different order events, from the client s perspective: Scenario 1: Order is received, partially filled and completely filled (no change to SecondaryOrderID). Msg Msg ClOrd Secondary Ord Exec Symbol OrderID sent received ID OrderID Status Type Comment D ABC1 New Order from trader. Order is 8 ABC1 WDLH New New ack ed by exchange. 8 ABC1 WDLH Partially filled Trade Partial fill is received by trader. 8 ABC1 WDLH Filled Trade Order is filled. Scenario 2: Disclosed order is received, partially filled and completely filled (SecondaryOrderID changes upon replenishment). Msg Msg ClOrd Secondary Ord Exec Symbol OrderID sent received ID OrderID Status Type Comment D ABC1 New Order from trader. Order is 8 ABC1 WDLH New New ack ed by exchange. 8 ABC1 WDLH Partially filled Trade Partial fill is received by trader. Order is partially filled, and quantity is replenished. 8 ABC1 WDLH Partially filled Trade Order is partially filled, and quantity is replenished again. 8 ABC1 WDLH Filled Trade Partial fill is received by trader. Order is filled. Scenario 3: Order is received, and then modified (SecondaryOrderID changes upon modification). Msg Msg ClOrd Secondary Ord Exec Symbol OrderID Comment sent received ID OrderID Status Type New Order D ABC1 from trader. BELL Rules of Engagement Page 88

89 8 ABC1 WDLH New New Trader modifies order quantity. 8 ABC1 WDLH Replaced Replace Order is filled 8 ABC1 WDLH Filled Trade Order is ack ed by exchange. Order was modified. Order is filled. BM&FBOVESPA provides the ability for a client to verify the position of its order in the order book by the usage of the OrderID field (tag 37), which is issued in market data snapshot messages (tag 35=W) and market data incremental refresh messages (tag 35=V). This tag does not contain the actual OrderID that is issued in the Execution Report message, but the SecondaryOrderID instead, which is unique per broker firm, per instrument, per trading date. This way, the client may verify where the order is located in the order book. As an example, consider the following order book: OrderID Buyer Bid Qty Price Offer Qty Seller OrderID And the client submits an order (Sell 11.03). The messages and the order book will look as follows: OrderID Buyer Bid Qty Price Offer Qty Seller OrderID Msg sent D Msg received ClOrd ID ABC1 Symbol OrderID Secondary OrderID Ord Status Exec Type 8 ABC1 WDLH New New Comment New Order from trader. Order is ack ed by exchange. BELL Rules of Engagement Page 89

90 9.14 Order Execution Rules at BM&FBOVESPA BM&FBOVESPA matches orders by price/time priority. Lower offer prices take precedence over higher offers prices, and higher bid prices take precedence over lower bid prices. If there is more than one bid or offer at the same price level, earlier bids and offers take precedence over later bids and offers, respectively. Under price/time priority of orders, a bid (offer) is filled at the best price by the earliest entered offer (bid) at that price. If additional contract units are needed to fill the bid (offer) then the next oldest offer (bid) at that price is matched until all of the liquidity at that price has been exhausted. Then matches would commence at the next best price until the order is completely filled. BELL Rules of Engagement Page 90

91 Document Owner 9.15 Application Message Scenarios BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department The following sections provide examples of the most common application message scenarios. In all scenarios, if a message is malformed or fails specific business level conditions, it will be rejected with either a Session Reject (invalid tag for message, invalid body length, etc) or Business Message Reject message (e.g., conditionally required field missing). BELL Rules of Engagement Page 91

92 Security Definition The following diagrams illustrate the security definition scenarios (start of day, intraday updates, etc) Security List Request with One Message Returned In this example, the connecting counterparty requests a list of all securities traded by BM&FBOVESPA. BM&FBOVESPA responds with the list of securities available, contained in a single message. Client institution BM&F SecurityReqID=ABCD SecurityListRequestType=4 Security List Request (MsgType=x) Security List (MsgType=y) SecurityReqID=ABCD NoRelatedSym=4 -- SecurityID = BMF SecurityID = BMF SecurityID = BMF SecurityID = BMF003 All security definitions are sent in one message only (tag TotNoRelatedSym is not set). Figure 7 - Security List Request responded with only one Security List message. BELL Rules of Engagement Page 92

93 Security List Request with Updates In this example, the connecting counterparty requests a list of securities traded by BM&FBOVESPA and subscribes for further updates as they occur. Client institution BM&F SecurityReqID=ABCD SecurityListRequestType=4 SubscriptionRequestType=1 Security List Request (MsgType=x) Security List (MsgType=y) SecurityReqID=ABCD NoRelatedSym=4 -- SecurityID = BMF SecurityID = BMF SecurityID = BMF SecurityID = BMF003 All security definitions are sent in one message only (tag TotNoRelatedSym is not set). Another security is added (BMF004). Security List (MsgType=y) SecurityReqID=ABCD NoRelatedSym=1 -- SecurityID = BMF004 Figure 8 - Security List Request with updates. BELL Rules of Engagement Page 93

94 Security List Request without Updates In this example, the connecting counterparty requests a snapshot of the list of securities traded by BM&FBOVESPA without subscribing for further updates. Client institution BM&F SecurityReqID=ABCD SecurityListRequestType=4 SubscriptionRequestType=0 Security List Request (MsgType=x) Security List (MsgType=y) SecurityReqID=ABCD NoRelatedSym=4 -- SecurityID = BMF SecurityID = BMF SecurityID = BMF SecurityID = BMF003 All security definitions are sent in one message only (tag TotNoRelatedSym is not set). Another security is added (BMF004). New security is not sent because SubscriptionRequestType = 0 (snapshot only). Figure 9 - Security List Request without subscription to further updates. BELL Rules of Engagement Page 94

95 Security List Request with Updates after Specified Timestamp In this example, the connecting counterparty requests a list of securities traded by BM&FBOVESPA that have been modified/added after a specific timestamp. It will receive updates if any afterwards. Client institution BM&F SecurityReqID=ABCD SecurityListRequestType=4 SubscriptionRequestType=1 Security List Request (MsgType=x) Request made on 26 Apr 2007, at 14:40:00 Security List (MsgType=y) Connection drop SecurityReqID=ABCD NoRelatedSym=4 -- SecurityID = BMF SecurityID = BMF SecurityID = BMF SecurityID = BMF003 All security definitions are sent in one message only (tag TotNoRelatedSym is not set). Another security is added (BMF004) while connection is down. SecurityReqID=TEST SecurityListRequestType=4 SubscriptionRequestType=1 SecurityUpdatesSince= :40:00 Security List Request (MsgType=x) Security List (MsgType=y) SecurityReqID=TEST NoRelatedSym=1 -- SecurityID = BMF004 Figure 10 - Security List Request for securities added/modified after specified timestamp. BELL Rules of Engagement Page 95

96 Start of Day Security List Request with More than One Message Returned In this example, the connecting counterparty requests a list of all securities traded by BM&FBOVESPA at the start of day. BM&FBOVESPA responds with the list of securities available, contained in more than one message. Client institution BM&F SecurityReqID=ABCD SecurityListRequestType=4 Security List Request (MsgType=x) Security List (MsgType=y) SecurityReqID=ABCD TotNoRelatedSym=10 NoRelatedSym=4 -- SecurityID = BMF SecurityID = BMF SecurityID = BMF SecurityID = BMF003 4 of 10 security definitions are sent in the first message. Security List (MsgType=y) SecurityReqID=ABCD TotNoRelatedSym=10 NoRelatedSym=4 -- SecurityID = BMF SecurityID = BMF SecurityID = BMF SecurityID = BMF007 Another 4 of 10 security definitions are sent in the second message. Security List (MsgType=y) SecurityReqID=ABCD TotNoRelatedSym=10 LastFragment=Y NoRelatedSym=2 -- SecurityID = BMF SecurityID = BMF009 Last Security List Report in stream contains tag LastFragment=Y. Figure 11 - Security List Request responded with more than one Security List message. BELL Rules of Engagement Page 96

97 Document Owner Order Management BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department The following diagrams illustrate the order management (entry, execution, cancellation, modification and status request) scenarios Order Entry, Partial Fill and Complete Fill In this example, an order is sent by the client institution. This order is partially filled and is completely filled afterwards. Client institution BM&F ClOrdID=ABCD OrderQty=1000 New Order Single (MsgType=D) Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=0 ExecType=0 LeavesQty=1000 Order is received by the book. Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=1 ExecType=F LeavesQty=400 CumQty=600 Order is partially executed for 600 contracts/ shares. Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=2 ExecType=F LeavesQty=0 CumQty=1000 Order is executed for 400 contracts/ shares. Figure 12 - Order Entry with partial and total fill BELL Rules of Engagement Page 97

98 Order Cancellation by ClOrdID In this example, the client institution issues an order, and cancels it afterwards referring to its ClOrdID. The ClOrdID was generated by the issuer of the order, and must be unique for that trading session. BM&FBOVESPA correlates the ClOrdID issued by the client with its own internal order ID per instrument, sent to the client in the tag OrderID in the Execution Report messages. Client institution BM&F ClOrdID=ABCD OrderQty=1000 New Order Single (MsgType=D) Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=0 ExecType=0 LeavesQty=1000 Order is received by the book. Order Cancel Request (MsgType=F) Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=4 ExecType=4 LeavesQty=1000 Order is fully cancelled. Figure 13 - Order cancellation using ClOrdID BELL Rules of Engagement Page 98

99 Order Cancellation by OrderID Once an order is accepted by BM&FBOVESPA, it is assigned a unique internal identifier by instrument, sent to the client in the tag OrderID in each Execution Report message. The client may take action on that order using the OrderID instead of the ClOrdID. Client institution BM&F ClOrdID=ABCD OrderQty=1000 New Order Single (MsgType=D) Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=0 ExecType=0 LeavesQty=1000 Order is received by the book. ClOrdID=CXLREQ001 OrigClOrdID=ignored OrderID=BMF001 Order Cancel Request (MsgType=F) Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=4 ExecType=4 LeavesQty=1000 Order is fully cancelled. Figure 14 - Order cancellation by OrderID BELL Rules of Engagement Page 99

100 Order Cancellation Attempt of Filled Order In this example, the client issues a new order, this order is filled, and the client attempts to cancel the filled order. The cancel request will be rejected. Client institution BM&F ClOrdID=ABCD OrderQty=1000 New Order Single (MsgType=D) Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=0 ExecType=0 LeavesQty=1000 Order is received by the book. Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=2 ExecType=F LeavesQty=0 CumQty=1000 Order is executed for 1000 contracts/ shares. ClOrdID=CXLREQ001 OrigClOrdID=ABCD Order Cancel Request (MsgType=F) Cancel Request Reject (MsgType=9) ClOrdID=CXLREQ001 OrderID=BMF0001 OrigClOrdID=ABCD CxlRejReason=1 Cancel Request is rejected (Unknown order). Figure 15 - Attempt to cancel a filled order BELL Rules of Engagement Page 100

101 Order Modification This example illustrates the modification of an order issued by the client. Notice that an order that is modified keeps the BM&FBOVESPA order ID (OrderID) of the cancelled order. Buy-side institution BM& ClOrdID=ABCD OrderQty=1000 New Order Single (MsgType=D) Execution Report (MsgType=8) ClOrdID=ABCD OrderID=BMF0001 OrdStatus=0 ExecType=0 LeavesQty=1000 Order is received by the book. Order Cancel Replace Request (MsgType=G) Order ABCD is cancelled and replaced with order REPLACE001. Execution Report (MsgType=8) ClOrdID=REPLACE001 OrderID=BMF0001 OrdStatus=0 ExecType=5 LeavesQty=5000 Note that the OrderID is the same. Figure 16 - Order modification scenario - OrderID is kept for modified order. BELL Rules of Engagement Page 101

102 Document Owner Market Data BELL FIX Protocol Rules Of Engagement DI-GIA Trading Interfaces Department The following examples illustrate common scenarios for Market Data related message flow Successful Subscription Request + Updates This example illustrates the client s subscription request for market data information, followed by a full snapshot and further updates. Note that not all market data information is illustrated in this example; it only contains the indication of tags deemed relevant for the purpose of explaining how the market data message flow works. Client institution BM&F MDReqID=ABCD SubscriptionRequestType=1 SecurityID=BMFCO Market Data Request (MsgType=V) Market Data Snapshot Full Refresh (MsgType=W) BID OFFER Qty Price Qty Price MDReqID=ABCD SecurityID=BMFCO NoMDEntries= MDEntryType=0, MDEntryPx=2600, MDEntrySize=100, MDPositionNo=1 - MDEntryType=0, MDEntryPx=2400, MDEntrySize=150, MDPositionNo=2 - MDEntryType=0, MDEntryPx=2100, MDEntrySize=100, MDPositionNo=3 - MDEntryType=1, MDEntryPx=2800, MDEntrySize=150, MDPositionNo=1 - MDEntryType=1, MDEntryPx=2900, MDEntrySize=200, MDPositionNo=2 - MDEntryType=1, MDEntryPx=3100, MDEntrySize=300, MDPositionNo=3 New Order is received BUY 2800 Partially executes against best offer SELL Market Data Incremental Refresh (MsgType=X) BID OFFER Qty Price Qty Price MDReqID=ABCD SecurityID=BMFCO NoMDEntries=4 (three book updates + 1 trade) - MDUpdateAction=0,MDEntryType=0,MDEntryPx=2800,MDEntrySize=100,MDPositionNo=1 - MDUpdateAction=1,MDEntryType=1,MDEntryPx=2800,MDEntrySize=50,MDPositionNo=1 - MDUpdateAction=2,MDEntryType=0,MDEntryPx=2800,MDEntrySize=100,MDPosition=1 - MDUpdateAction=0,MDEntryType=2,MDEntryPx=2800,MDEntrySize=100 Cancel Request is received. Cancel SELL Market Data Incremental Refresh (MsgType=X) BID OFFER Qty Price Qty Price MDReqID=ABCD SecurityID=BMFCO NoMDEntries=1 - MDUpdateAction=2,MDEntryType=1,MDPositionNo=3 Figure 17 - Market data subscription, full update and incremental refresh for partial execution and cancellation. BELL Rules of Engagement Page 102

103 Successful Subscription plus Book Updates In this example, the connecting counterparty requests for a book snapshot (bid and offer) plus updates. It illustrates the changes in the position of the book entries (MDPositionNo) according to new, delete and change events. Client institution BM&F MDReqID=ABCD SubscriptionRequestType=1 SecurityID=BMFCO Market Data Request (MsgType=V) Market Data Snapshot Full Refresh (MsgType=W) BID OFFER Qty Price Qty Price MDReqID=ABCD SecurityID=BMFCO NoMDEntries= MDEntryType=0, MDEntryPx=2600, MDEntrySize=100, MDPositionNo=1 - MDEntryType=0, MDEntryPx=2400, MDEntrySize=150, MDPositionNo=2 - MDEntryType=0, MDEntryPx=2100, MDEntrySize=100, MDPositionNo=3 - MDEntryType=1, MDEntryPx=2800, MDEntrySize=150, MDPositionNo=1 - MDEntryType=1, MDEntryPx=2900, MDEntrySize=200, MDPositionNo=2 - MDEntryType=1, MDEntryPx=3100, MDEntrySize=300, MDPositionNo=3 New Order is received BUY 2850 Market Data Incremental Refresh (MsgType=X) BID OFFER Qty Price Qty Price MDReqID=ABCD SecurityID=BMFCO NoMDEntries= MDUpdateAction=0,MDEntryType=0,MDEntryPx=2850,MDEntrySize=100,MDPositionNo=1 Cancel Request is received. Cancel BUY Market Data Incremental Refresh (MsgType=X) BID OFFER Qty Price Qty Price MDReqID=ABCD SecurityID=BMFCO NoMDEntries=1 - MDUpdateAction=2,MDEntryType=1,MDPositionNo=2 Replace Request is received. Modify BUY 2400 to BUY Market Data Incremental Refresh (MsgType=X) BID OFFER Qty Price Qty Price MDReqID=ABCD SecurityID=BMFCO NoMDEntries=1 - MDUpdateAction=1,MDEntryType=1,MDPositionNo=2, MDEntrySize=500 Figure 18 - Book snapshot plus updates with MDPositionNo changes. BELL Rules of Engagement Page 103

104 Failed Subscription Request (Invalid Security ID) This example illustrates a failed attempt by the client to subscribe to the market data feed for an instrument. In this specific case, the subscription fails because the Security ID in the market data subscription message is invalid. Client institution BM&F MDReqID=ABCD SubscriptionRequestType=1 SecurityID=XXXXXX Market Data Request (MsgType=V) Security ID XXXXXX is invalid. Market Data Request Reject (MsgType=Y) MDReqID=ABCD MDReqRejReason=0 (Unknown Symbol) Figure 19 - Market Data Reject due to invalid security ID. BELL Rules of Engagement Page 104

105 Trade Cancellation (Trade Bust) This scenario illustrates the cancellation of a previously reported trade. Client institution BM&F Note that in each Market Data Incremental Refresh message, the MD Entries that represent changes to the order book are not displayed for simplicity. Trade with UniqueTradeID=456 occurs for security BMFCO001, 13 Market Data Incremental Refresh (MsgType=X) SecurityID=BMFCO001 NoMDEntries=1 MDUpdateAction=0,MDEntryType=2, MDEntryPx=13, MDEntrySize=5000, UniqueTradeID=456 Trade with UniqueTradeID=456 is cancelled by BM&F Market Surveillance Market Data Incremental Refresh (MsgType=X) SecurityID=BMFCO001 NoMDEntries=1 MDUpdateAction=2,MDEntryType=2, MDEntryPx=13, MDEntrySize=5000, UniqueTradeID=456 Figure 20 - Trade cancellation. BELL Rules of Engagement Page 105