Trading Systems Department Document BM&FBOVESPA Self Trade Prevention Functionality

Transcription

1 Self Trade Prevention Functionality Version October 19 th 2011

2 Table of Contents TABLE INDEX... 3 DOCUMENT OVERVIEW BUSINESS CONTEXT DISAMBIGUATION BUSINESS REQUIREMENTS SELF TRADE PREVENTION VERIFICATION AT CUSTOMER LEVEL IS MANDATORY FOR MESSAGES CONTAINING THE UNIQUE CUSTOMER IDENTIFIER THE UNIQUE CUSTOMER IDENTIFIER IS OPTIONAL SELF TRADE PREVENTION AT CUSTOMER LEVEL - REQUIRED PARAMETERS Unique Customer Identifier SELF TRADE ACTION FUNCTIONALITY RULES FOR SELF TRADE VERIFICATION AT CUSTOMER LEVEL Continuous trading In a condition that can trigger an auction During an auction SELF TRADE PREVENTION SELF TRADE PREVENTION SCENARIOS Self Trade prevention on Aggressing Order Self Trade prevention on Order Modification Self Trade prevention and Partial Fills Self Trade prevention on Stop Orders EXAMPLES SELF TRADE SCENARIOS FOR LIMIT ORDERS Scenario Steps Result Scenario Steps Result Scenario Steps Result Scenario Steps Result SELF TRADE SCENARIOS FOR FILL AND KILL ORDERS (FAK) Scenario Steps Result SELF TRADE SCENARIOS FOR ORDERS WITH MINIMUM QUANTITY Scenario Steps Result Scenario Steps Result

3 4.4 SELF TRADE SCENARIOS FOR FILL OR KILL ORDERS (FOK) Scenario Steps Result SELF TRADE SCENARIOS FOR PRICE AND QUANTITY CONTROL Scenario Steps Result Scenario Steps Result SELF TRADE PREVENTION GENERAL SCENARIOS Scenario 1: Incoming Orders from the Same Customer, but No Potential Match Steps Result Scenario 2: Potential match with two orders of the same customer Steps Result: Scenario 3: Incoming Market-to-Limit Bid matches multiple orders, but one order belongs to the same customer Bid elimination Steps Result Scenario 4: Simultaneous Self Trade at Customer Level and Broker / Firm Level Pre-Conditions Steps Result Scenario 5: Attempt to Submit Orders during an Auction Pre-Conditions Steps Result Brief explanation Scenario 9: Stop order: elimination when elected Steps Result THE UNIQUE CUSTOMER IDENTIFIER Table Index Table 1 - Scenario 1 for limit orders Table 2 - Scenario 2 for limit orders Table 3 - Scenario 2 resulting book Table 4 - Scenario 3 for limit orders Table 5 - Scenario 3 resulting book Table 6 - Scenario 4 for limit orders Table 7 - Scenario 4 resulting book Table 8 - Scenario 1 for FAK order Table 9 - Scenario 1 for FAK resulting book Table 10 - Scenario 1 for minimum quantity order Table 11 - Scenario 2 for minimum quantity order Table 12 - Scenario 2 for minimum quantity order: resulting book Table 13 - Scenario 1 for FOK order Table 14 - Scenario 1 for quantity control Table 15 - Scenario 3 for price control Table 16 - Scenario 3 for price control: resulting crossed book

4 Table 17 - Initial book Table 18 - Scenario 1: two orders of the same customer resting in the book Table 19 - Scenario 2: match with same customer Table 20 Scenario 3: Market-to-Limit Bid matching with more than one order Table 21 Scenario 4: Self Trade at customer and Broker / Firm level Table 22 Scenario 5: initial crossed book Table 23 - Initial book Table 24 Scenario 9: Stop order

5 Document Overview This document provides the detailed level specifications for Self Trade prevention at customer level. This document contains the following sections: Business Context Provide a brief explanation of Self Trade prevention from a business perspective. Use Cases Provide specific step-by-step business use scenarios for the Self Trade prevention feature. 5

6 1 Business Context 1.1 Disambiguation To avoid misunderstandings, there are two types of Self Trade Self Trade Prevention at the Broker / Firm Level The main goal of this feature is to restrict matching between buying and selling orders from the same Broker / Firm. This is configured at group level by BVMF Self Trade Prevention at the Customer Level This functionality resembles the Self Trade prevention at the Broker / Firm Level; however the main goal of Self Trade prevention at customer level is to restrict matching between buying and selling orders from the same customer, regardless of Broker / Firm. The customer is identified by a unique customer identifier, included within the FIX message. It is up to the customer to include the unique customer identifier within the order message, i.e., it is optional. This document solely details Self Trade at Customer Level. 6

7 2 Business Requirements 2.1 Self Trade prevention verification at Customer Level is Mandatory for Messages Containing the Unique Customer Identifier The trading platform must perform Self Trade validations at customer level against all orders which contain the unique customer identifier. Messages that do not contain the unique customer identifier are not validated for self trade prevention. 2.2 The unique customer identifier is optional Self Trade prevention at the customer level must be explicitly required by the customer by providing a unique Customer Identifier in the FIX order message. However this identifier is not mandatory. 2.3 Self Trade Prevention at Customer Level - Required Parameters To enable the trading platform to handle Self Trade situations, the customer must provide the unique Customer Identifier in the order message: Unique Customer Identifier The unique Customer Identifier is optionally used in customer orders as a key to identify the customer. o This unique customer identifier is a unique number and by no means related to any Broker / Firm number. The unique customer Identifier can be optionally used by the customer regardless of Broker / Firm. o There is a TAG in the message entry and order modification to include the unique customer identifier. The unique Customer Identifier must be provided by the customer for the validation to be executed. o The system does not run Self Trade validations at customer level against orders not tagged with the unique customer identifier. 2.4 Self Trade Action Functionality Self Trade is a condition when both aggressor and aggressed order are tagged with the same unique Customer Identifier. The incoming (aggressing) order is eliminated in case of Self Trade at customer level. A modification can lead to order elimination in case of Self Trade at customer level. Self Trade prevention at customer level applies to both liquid and illiquid groups. Self Trade prevention at customer level functionality is active for all instruments of a specific instrument group, as decided by BM&FBOVESPA Market Operations. Changes (inclusions of exclusions) of the list of groups with this functionality enabled will be communicated in advance to all customers. 2.5 Rules for Self Trade Verification at Customer Level Two orders on opposite market sides with the same unique Customer Identifier can rest in the book simultaneously, as long as there is no potential match between them. 7

8 When a Stop order is elected, the resulting actual order is subjected to the same rules as any other incoming order Continuous trading During continuous trading, Self Trade validation at customer level is triggered by incoming (aggressing) orders tagged with a unique customer identifier. During continuous trading, Self Trade validation at customer level is also triggered by modification of orders tagged with a unique customer identifier. Self Trade prevention at customer level works only if both aggressor (incoming) and aggressed (resting) orders are tagged with the same unique Customer Identifier. In such situation, the aggressing order must be eliminated When a resting order tagged with a unique customer identifier is modified, and this modification leads to a potential match with another order tagged with the same identifier, this modified order must be eliminated. For incoming Minimum quantity orders or FOK orders, the Match Engine needs to analyze the book to assure the minimum required quantities can be achieved without self-trade. Otherwise the incoming (aggressing) order must be eliminated upon entry In a condition that can trigger an auction No Self Trade prevention validation is performed during conditions that can trigger an auction During an auction No Self Trade prevention validation is performed during an auction. Self Trade Prevention functionality is available only for Derivatives traded using the PUMA platform, and not for MegaBolsa. 8

9 3 Self Trade Prevention Self Trade prevention at customer level is a functionality that aims to restrict matching between buying and selling orders from the same customer, regardless of Broker/Firm. For this purpose, the customer must be identified with a unique Investor ID, included within the order message. The use of this unique identifier is optional and it is up to the customer to provide this information within the Parties block in the FIX message. Note that Investor ID value is not the same as the customer s Account (1) field nor is there necessarily a one-to-one mapping between Account and Investor ID. As presented below, PartyID (448) field must be used to convey the unique customer identifier used by Self Trade prevention and PartyRole (452) must be assigned with value 5 Investor ID. Tag Tag Name Data Type Value 453 NoPartyIDs NumInGroup 448 PartyID String 447 PartyIDSource Char D 452 PartyRole Int 5 Investors must provide here their unique customer identifier in order to enable Self Trade prevention. It s important to note that Self Trade prevention at customer level works only if both aggressor (incoming) and aggressed (resting) orders are assigned to the same unique Investor ID. However, two orders on opposite market sides with the same unique customer identifier can rest in the book simultaneously, as long as there is no potential match between them. Self Trade prevention rules at the customer level do not apply for auction, match events that trigger an auction, orders entered on-behalf by CCB and UDS legs. In order to guarantee the oneness on Investor IDs, BVMF adopted the following convention to define the customer identifier for each participant: Brazilian residents and corporate investors must use the 8 leftmost digits of their CNPJ; A Brazilian resident and individual investor uses the whole CPF as a unique customer identifier; Non-resident investors must use a six-digit code extracted from their individual investor ID. The whole code is formatted as AAAAA.BBBBBB.CCCCCC.X-Y, where only the CCCCCC part is used. The table below presents some examples of Investor IDs: Investor Document Type Document Number Unique Customer Identifier Corporate resident CNPJ / Individual resident CPF Non-resident investor Investor ID Note: All Investor ID values above should be provided in tag PartyID (448) as numeric only (i.e. exclude alphanumeric characters such as dashes and dots). 9

10 3.1 Self Trade prevention scenarios This section presents scenarios where the Self Trade prevention at the customer level causes the cancellation of orders entered by customers. In all cases, the system sends an ExecutionReport and provides the reason for the order elimination in tag ExecRestatementReason (378) Self Trade prevention on Aggressing Order In this scenario, the customer already has an order in the book tagged with their unique Investor ID and the new order that is being sent can potentially match with the one in the book. In this case, the new order is accepted and then canceled upon entry. Tag OrderStatus (39) in the ExecutionReport sent to the participant indicates that the order has been canceled (39 = 4 Canceled) and tag ExecRestatementReason (378) provides a self explanatory reason for the elimination (378 = 103 Self Trade prevention). Note that the system does not run Self Trade validations at customer level for orders not tagged with Party Role (452) = 5 Investor ID. Order Entry Gateway {An order for buying 100 shares at $ of customer already rests in the order book when the same customer sends the following sell order to the system.} BM&FBovespa NewOrderSingle (35=D, 54=2, 38=100, 44=70.77, 448= , 447=D, 452=5) ExecutionReport (35=8, 39=0, 150=0) - Accepted ExecutionReport (35=8, 39=4, 150=D, 378=103 (SELF TRADING TRADE PREVENTION)) {Aggressing order is eliminated} Figure 1 - Self Trade prevention on aggressing order The following table shows the sequence of messages received and sent by the Exchange and some sample values are assigned to key fields in order to demonstrate their usage: Message Message Received Sent (452=5) Comment 1 NewOrderSingle D ExecutionReport New 3 ExecutionReport D 103 Restated / Canceled 10

11 3.1.2 Self Trade prevention on Order Modification When an order modification leads to a potential match with another order, tagged with the same Investor ID, the modification will be accepted but it will be followed by an immediate elimination of the order. Tag OrderStatus (39) in the ExecutionReport sent to the participant indicates that the order has been canceled (39 = 4 Canceled) and tag ExecRestatementReason (378) provides a self explanatory reason for the elimination (378 = 103 Self Trade prevention). Figure 2 - Self Trade prevention on order modification The following table shows the sequence of messages received and sent by the Exchange and some sample values are assigned to key fields in order to demonstrate their usage: Message Received Message Sent 1 NewOrderSingle D 2 ExecutionReport 8 3 OrderCancelReplaceRequest G 4 ExecutionReport 8 5 ExecutionReport Self Trade prevention and Partial Fills AB C AB C DE F DE F DE F 448 (452=5) Comment New Replaced D 103 Restated / Canceled This scenario presents a situation in which the order is partially executed in 200 shares and the remaining amount of 800 is eliminated because the next aggressed order has the same unique Investor ID. Tag OrderStatus (39) in the ExecutionReport sent to the participant indicates that the order has been canceled (39 = 4 Canceled) and tag ExecRestatementReason (378) provides a self explanatory reason for the elimination (378 = 103 Self Trade prevention). 11

12 Order Entry Gateway BM&FBovespa NewOrderSingle (35=D, 11=ABC, 38=100, 448= , 447=D, 452=5) ExecutionReport (35=8, 11=ABC, 39=0, 150=0) - Accept {Order matches partially with other counter parties before it is eliminated} ExecutionReport (35=8, 11=ABC, 39=1, 150=F) - Partial Fill ExecutionReport (35=8, 11=ABC, 39=1, 150=F) - Partial Fill ExecutionReport (35=8, 11=ABC, 39=4, 150=D, 378=103 (SELF TRADING TRADE PREVENTION)) {Order is eliminated} Figure 3 - Self Trade prevention and partial fills For incoming Minimum quantity orders or FOK orders, the Match Engine analyzes the book to assure the minimum required quantities can be achieved without self-trade. Otherwise the incoming (aggressing) order must be eliminated upon entry. The following table shows the sequence of messages received and sent by the Exchange and some sample values are assigned to key fields in order to demonstrate their usage: Message Message Received Sent (452=5) Comment 1 NewOrderSingle D ABC ExecutionReport 8 ABC New 3 ExecutionReport 8 ABC F -- Partial Fill 4 ExecutionReport 8 ABC F -- Partial Fill 5 ExecutionReport 8 ABC D 103 Restated / Canceled 12

13 3.1.4 Self Trade prevention on Stop Orders In the following scenario, a Stop order becomes a Limit order and it is tagged with the same Investor ID as another order in the book. If such condition leads to a self-trade, the triggered order will be immediately eliminated. Tag WorkingIndicator (636) points when the order becomes active and available for trading. Upon activation, the OrderType (40) changes from Stop Limit (40 = 4) to Limit (40 = 2) and the order is eliminated by the Self Trade prevention functionality. Order Entry Gateway {A Stop Order is accepted and rests in the stop order book.} BM&FBovespa NewOrderSingle (35=D, 11=ABC, 40=4, 38=100, 448= , 447=D, 452=5) ExecutionReport (35=8, 11=ABC, 39=0, 40=4, 150=0, 636=N) - Accept {Stop Order triggers} ExecutionReport (35=8, 39=0, 40=2, 636=Y) - Accept ExecutionReport (35=8, 11=ABC, 39=4, 150=D, 378=103 (SELF TRADING TRADE PREVENTION)) {Order is eliminated} Figure 4 - Self Trade prevention on Stop orders Message Message Comment Received Sent 5 (452=5) 1 NewOrderSingle D ABC ExecutionReport 8 ABC N New 3 ExecutionReport 8 ABC Y New 4 ExecutionReport 8 ABC D Restated / Canceled 13

14 4 Examples All examples and brokers are fictional. 4.1 Self Trade Scenarios for Limit Orders Scenario Steps BROKER / FIRM 82 is buying 100 shares at R $ for customer and submits a sell order of 100 at R $ to customer Table 1 - Scenario 1 for limit orders 82 4/7/ :42: ,77 70, /7/ :42: /7/ :31: ,76 70, /7/ :42: /7/ :28: ,75 70, /7/ :42: /7/ :42: ,75 70, /7/ :39: /7/ :42: , /7/ :37: Result The aggressing (incoming) order should be eliminated because the aggressed one has the same unique Customer Identifier Scenario Steps BROKER / FIRM 82 is buying 500 shares at R $ for customer and BROKER / FIRM 22 submits a sell order of 1,000 at R $ for customer Table 2 - Scenario 2 for limit orders Firm ID 82 4/7/ :42: ,77 70, /7/ :42: /7/ :31: ,76 70, /7/ :42: /7/ :28: ,75 70, /7/ :42: /7/ :42: ,75 70, /7/ :39: /7/ :42: , /7/ :37: Result The order is partially executed in 100 shares at R$ and the remaining amount is eliminated because the aggressed one has the same unique Customer Identifier. Table 3 - Scenario 2 resulting book Firm ID 82 4/7/ :31: ,76 70, /7/ :42: /7/ :28: ,75 70, /7/ :42: /7/ :42: ,75 70, /7/ :42: /7/ :42: ,72 70, /7/ :39: /7/ :37:

15 4.1.3 Scenario Steps BROKER / FIRM 147 is buying 500 shares at R$ for customer and submits a sell order of 10,000 at R$ for customer Table 4 - Scenario 3 for limit orders Broker / Firm ID Timestamp Quantity Price Price Quantity Timestamp Broker / 82 4/7/ :42: ,77 70, /7/ :42: /7/ :31: ,76 70, /7/ :42: /7/ :28: ,75 70, /7/ :42: /7/ :42: ,75 70, /7/ :39: /7/ :42: , /7/ :37: Result The order is partially executed in 900 shares: 100 at R$ 70.77, 500 at R$ and 300 at R$ and the remaining amount of 9100 is eliminated because the aggressed one has the same unique Customer Identifier. Table 5 - Scenario 3 resulting book Broker / Firm ID Timestamp Quantity Price Price Quantity Timestamp Broker / 147 4/7/ :42: ,75 70, /7/ :42: /7/ :42: ,72 70, /7/ :42:40 70, /7/ :42:40 70, /7/ :39: /7/ :37: Scenario Steps BROKER / FIRM 21 is buying 100 shares at R $ for customer and submits a sell order of 10,000 at R$ for customer Table 6 - Scenario 4 for limit orders 82 4/7/ ,00 70, /7/ :42: :42: /7/ ,00 70, /7/ :42: :31: /7/ :28: ,50 70, /7/ :42:

16 147 4/7/ :42: /7/ :42:48 2 4/7/ :30:18 8 4/7/ :33: /7/ :50: ,00 70, /7/ :39: , /7/ :37: ,95 71, /7/ :29: ,90 71, /7/ :05: ,90 71, /7/ :21: Result The order is partially executed in 3100 shares: 100 and 500 at R$ 70.00, 300 at R$ 69.50, 500 at R$ 69.00, 600 at R$ 68.00, 100 at R$ 67, 95, and 1000 at R$ and the remaining amount of 6900 at R$ is eliminated. Table 7 - Scenario 4 resulting book 21 4/7/ ,90 70, /7/ :42: :50:30 70, /7/ :42: , /7/ :42: , /7/ :39: /7/ :37: , /7/ :29: , /7/ :05: , /7/ :21: Self Trade Scenarios for Fill and Kill Orders (FAK) Scenario Steps BROKER / FIRM 147 is buying 500 shares at R $ 70.75, and customer sends a sell order of 10,000 at R $ for customer with FAK qualifier. Table 8 - Scenario 1 for FAK order 82 4/7/ :42: ,77 70, /7/ :42: /7/ :31: ,76 70, /7/ :42: /7/ :28: ,75 70, /7/ :42: /7/ :42: ,75 70, /7/ :39: /7/ :42: , /7/ :37: Result The order is partially executed in 900 shares: 100 at R$ 70.77, 500 at R$ 70.76, and 300 at R$ 70.75, and the remaining amount of 9100 is eliminated because the aggressed one has the same unique Customer Identifier. 16

17 Table 9 - Scenario 1 for FAK resulting book 147 4/7/ :42: ,75 70, /7/ :42: /7/ :42: ,72 70, /7/ :42: , /7/ :42: , /7/ :39: /7/ :37: Self Trade Scenarios for Orders with Minimum Quantity Scenario Steps BROKER / FIRM 147 is buying 500 shares at R $ for customer and sends a sell order of 10,000 at R$ with minimum quantity equals to 1000 for customer Table 10 - Scenario 1 for minimum quantity order Firm ID 82 4/7/ :42: ,77 70, /7/ :42: /7/ :31: ,76 70, /7/ :42: /7/ :28: ,75 70, /7/ :42: /7/ ,75 70, /7/ :39: :42: /7/ :42: , /7/ :37: Result The order is eliminated because it couldn t achieve the minimum quantity before reaching the Bid tagged with the same unique customer identifier Scenario Steps BROKER / FIRM 147 is buying 500 shares at R$ for customer and BROKER / FIRM 22 submits a sell order for 1,000 at R$ for customer with a minimum quantity equals to 500. Table 11 - Scenario 2 for minimum quantity order 82 4/7/ :42: ,77 70, /7/ :42: /7/ :31: ,76 70, /7/ :42: /7/ :28: ,75 70, /7/ :42: /7/ ,75 70, /7/ :39: :42: /7/ :42: , /7/ :37:

18 Result The order is partially executed in 900 shares: 100 at R$ 70.77, 500 at R$ 70.76, and 300 at R$ 70.75, and the remaining amount of 100 is eliminated because the next aggressed order has the same unique Customer Identifier. Table 12 - Scenario 2 for minimum quantity order: resulting book 147 4/7/ ,75 70, /7/ :42: :42: /7/ :42: ,72 70, /7/ :42: , /7/ :42: , /7/ :39: /7/ :37: Self Trade Scenarios for Fill or Kill Orders (FOK) Scenario Steps BROKER / FIRM 82 is buying 500 shares at R$ for customer and sends a sell order with qualifier FOK of 1,000 at R$ for customer Table 13 - Scenario 1 for FOK order 82 4/7/ ,77 70, /7/ :42: :42: /7/ ,76 70, /7/ :42: :31: /7/ ,75 70, /7/ :42: :28: /7/ ,75 70, /7/ :39: :42: /7/ :42: , /7/ :37: Result The order is eliminated because the minimum condition to match would include an order tagged with the same unique customer identifier. 4.5 Self Trade Scenarios for Price and Quantity Control Scenario Steps BROKER / FIRM 82 is buying 1000 shares at R$ for customer and BROKER / FIRM 22 sends a sell order of 1,500 at R$ for customer The quantity band is triggered with a quantity equals to or higher than

19 Table 14 - Scenario 1 for quantity control 82 4/7/ ,77 70, /7/ :42: :42: /7/ :31: ,76 70, /7/ :42: /7/ :28: ,75 70, /7/ :42: /7/ :42: ,75 70, /7/ :39: /7/ :42: , /7/ :37: Result The incoming Ask triggers an auction despite of being tagged with the same unique customer identifier of the resting 1000Lots@70.77 Bid Scenario Steps BROKER / FIRM 16 is buying 300 shares at R$ for customer and sends a sell order of 1,000 at R $ for customer The auction price band is triggered with a price equals to or less than R$ Table 15 - Scenario 3 for price control 82 4/7/ ,77 70, /7/ :42: :42: /7/ ,76 70, /7/ :42: :31: /7/ ,75 70, /7/ :42: :28: /7/ ,75 70, /7/ :39: :42: /7/ :42: , /7/ :37: Result The order is partially executed in 600 shares: 100 at R$ 70.77, 500 at $ 70.76, and the remaining amount of 400 triggers the auction at R$ Table 16 - Scenario 3 for price control: resulting crossed book 147 4/7/ ,75 70, /7/ :28:00 16:01: /7/ ,75 70, /7/ :42: :42: /7/ ,72 70, /7/ :42: :42:48 70, /7/ :42: , /7/ :39: /7/ :37:

20 4.6 Self Trade Prevention General Scenarios For the remaining scenarios, the following initial order book applies: Reference price = $ Auction bands: $ x Quantity band = 700Lots Protection points = $2.00 Table 17 - Initial book 82 4/7/ :42: $ $ /7/ :42: /7/ :31: $ $ /7/ :42: /7/ :28: $ $ /7/ :42: /7/ :42: $ $ /7/ :39: Scenario 1: Incoming Orders from the Same Customer, but No Potential Match Steps Broker / Firm 22 sends new bid of 100Lots@$ It is tagged with a unique Customer Identifier. An incoming ask of 100Lots@$ submitted by Broker / Firm 29, with the same unique Customer Identifier. Table 18 - Scenario 1: two orders of the same customer resting in the book 82 4/7/ :42: $ $ /7/ :42: /7/ :31: $ $ /7/ :01: /7/ :28: $ $ /7/ :42: /7/ :42: $ $ /7/ :42: /7/ :01: $ $ /7/ :39: Result This scenario does not trigger any Self Trade action because there is no potential match. Both orders will rest in the order book Scenario 2: Potential match with two orders of the same customer Steps Broker / Firm 22 submitted a bid of 100Lots@$ NOT tagged with unique Customer Identifier. Broker / Firm 29 is submitting a limit ask of 100Lots@$ tagged with a unique Customer Identifier. 20

21 Table 19 - Scenario 2: match with same customer 22 4/7/ $ $ /7/ :42: :01: /7/ :42: $ $ /7/ :42: /7/ :31: $ $ /7/ :42: /7/ :28: $ $ /7/ :39: /7/ :42: $ Result: This scenario does not trigger any Self Trade prevention at customer level action because the Match Engine cannot identify that both orders belongs to the same customer (one of them is not tagged) Resulting trade of 100Lots@$ Scenario 3: Incoming Market-to-Limit Bid matches multiple orders, but one order belongs to the same customer Bid elimination Steps A limit Ask, from Broker / Firm 29, is resting in the book. It is 100Lots@$ tagged with a unique Customer Identifier. There is an incoming Market-to-Limit bid of 300Lots tagged with the same unique Customer Identifier, from Broker / Firm 22 Book is: Table 20 Scenario 3: Market-to-Limit Bid matching with more than one order 82 4/7/ :42: $ $ /7/ :42: /7/ :31: $ $ /7/ :01: /7/ :28: $ $ /7/ :42: /7/ :42: $ $ /7/ :42: $ /7/ :39: Result First trade is 100Lots@$ Remaining bid quantity is $200Lots. When trying to match with 100Lots@$ Ask, tagged with the same unique customer identifier, the system will eliminate the remaining bid quantity due to Self Trade at the same customer. The first trade remains valid Scenario 4: Simultaneous Self Trade at Customer Level and Broker / Firm Level Pre-Conditions In addition to the Self Trade Prevention General Scenarios described in section 4.6, the following preconditions also apply for this scenario: Group is configured to trigger an auction on Self Trade at the Broker / Firm level. 21

22 Both orders are submitted by the same customer (same unique Customer Identifier) and through the same Broker / Firm Steps Broker / Firm 22 submitted an Ask of 100Lots@$ tagged with a unique Customer Identifier. It rests in the book. Table 21 Scenario 4: Self Trade at customer and Broker / Firm level 82 4/7/ :42: $ $ /7/ :01: /7/ :31: $ $ /7/ :42: /7/ :28: $ $ /7/ :42: /7/ :42: $ $ /7/ :42: $ /7/ :39: Broker / Firm 22 submits an incoming limit bid of 100Lots@$ , tagged with the same unique Customer Identifier Result The incoming Bid triggers an auction due to Self Trade at Broker / Firm level Scenario 5: Attempt to Submit Orders during an Auction Pre-Conditions Current parameters: Reference price = $ Auction bands: $ x Quantity band = 700Lots Protection points = $2.00 Broker / Firm 82 submitted a Bid of 400Lots@$ tagged with a unique Customer Identifier. Broker / Firm 54 submitted an Ask of 700Lots@$ with the same unique Customer Identifier. Broker / Firm 82 submitted a Bid of 800Lots@$ from a different customer, which triggers an auction by breaching the quantity band. The resulting book is: Table 22 Scenario 5: initial crossed book TOP = $ / TOQ = /7/ :42: $ $ /7/ :42: /7/ $ $ /7/ :42: :31: /7/ :28: $ $ /7/ :42: /7/ :42: $ $ /7/ :39:

23 Steps Broker / Firm 82 submitted a Bid of 200Lots@$ , tagged with the same unique Customer Identifier as the highlighted orders in the book (400@$ Bid and 700@$ Ask) Result The incoming bid 200Lots@$ is accepted Brief explanation There is no Self Trade validation at customer level during an auction Scenario 9: Stop order: elimination when elected Similar to previous examples from section 4.6, the initial book condition is: Reference price = $ Auction bands: $ x Quantity band = 700Lots Protection points = $2.00 A Stop Bid, from Broker / Firm 22, is resting in the stop order book. It triggers at $ and becomes a limit bid of 100Lots@$ This order is tagged with the same unique customer identifier as the Ask 100Lots@$ from broker 29. Table 23 - Initial book 82 4/7/ :42: $ $ /7/ :42: /7/ :31: $ $ /7/ :42: /7/ :28: $ $ /7/ :42: /7/ :42: $ $ /7/ :39: Steps A limit Ask, from Broker / Firm 29, is entered. It is 100Lots@$ tagged with a unique Customer Identifier. Ask 100Lots@ from Broker / Firm 54 is cancelled There is an incoming limit Bid of 100Lots@$ from Broker / Firm 99 There is an incoming limit Ask of 100Lots@$ from Broker / Firm Result There is trade of 100Lots@$ Now the LTP (last trade price) = $ and the resulting book is: 23

24 Table 24 Scenario 9: Stop order 82 4/7/ :42: $ $ /7/ :01: /7/ :31: $ $ /7/ :42: /7/ :28: $ $ /7/ :42: /7/ :42: $ $ /7/ :39: Because now LTP = $ , Stop order would become a limit Bid of 100Lots@$ But as such condition would lead to self-trade with 100Lots@$ Ask, the Bid is eliminated. The book remains as above. 24

25 5 The unique customer identifier BVMF will request the final investor to use their CPF/CNPJ as unique Customer Identifier. This document is issued by Brazilian Revenue Service (Receita Federal) for both individual and corporate investors. Non-resident investors will use their individual investor ID. The rule is: A Brazilian resident and corporate investor uses the 8 leftmost digits of its CNPJ as a unique customer identifier; A Brazilian resident and individual investor uses the whole CPF as a unique customer identifier; A non-resident uses the individual investor ID, a six-digit code part of a broader code, used by the exchange as a non-resident identifier. The whole code is formatted as aaaaa.bbbbbb.cccccc.x-y, where just the cccccc part will be used. Example Investor 1: corporate and resident in Brazil CNPJ is / Unique Customer Identifier will be: Investor 2: individual and resident in Brazil CPF is Unique Customer Identifier will be: Investor 3: non-resident investor ID is Unique Customer Identifier will be: