Self Trade Prevention Functionality Version 1.0.0 October 19 th 2011
Table of Contents TABLE INDEX... 3 DOCUMENT OVERVIEW... 5 1 BUSINESS CONTEXT... 6 1.1 DISAMBIGUATION... 6 2 BUSINESS REQUIREMENTS... 7 2.1 SELF TRADE PREVENTION VERIFICATION AT CUSTOMER LEVEL IS MANDATORY FOR MESSAGES CONTAINING THE UNIQUE CUSTOMER IDENTIFIER... 7 2.2 THE UNIQUE CUSTOMER IDENTIFIER IS OPTIONAL... 7 2.3 SELF TRADE PREVENTION AT CUSTOMER LEVEL - REQUIRED PARAMETERS... 7 2.3.1 Unique Customer Identifier... 7 2.4 SELF TRADE ACTION FUNCTIONALITY... 7 2.5 RULES FOR SELF TRADE VERIFICATION AT CUSTOMER LEVEL... 7 2.5.1 Continuous trading... 8 2.5.2 In a condition that can trigger an auction... 8 2.5.3 During an auction... 8 3 SELF TRADE PREVENTION... 9 3.1 SELF TRADE PREVENTION SCENARIOS... 10 3.1.1 Self Trade prevention on Aggressing Order... 10 3.1.2 Self Trade prevention on Order Modification... 11 3.1.3 Self Trade prevention and Partial Fills... 11 3.1.4 Self Trade prevention on Stop Orders... 13 4 EXAMPLES... 14 4.1 SELF TRADE SCENARIOS FOR LIMIT ORDERS... 14 4.1.1 Scenario 1... 14 4.1.1.1 Steps... 14 4.1.1.2 Result... 14 4.1.2 Scenario 2... 14 4.1.2.1 Steps... 14 4.1.2.2 Result... 14 4.1.3 Scenario 3... 15 4.1.3.1 Steps... 15 4.1.3.2 Result... 15 4.1.4 Scenario 4... 15 4.1.4.1 Steps... 15 4.1.4.2 Result... 16 4.2 SELF TRADE SCENARIOS FOR FILL AND KILL ORDERS (FAK)... 16 4.2.1 Scenario 1... 16 4.2.1.1 Steps... 16 4.2.1.2 Result... 16 4.3 SELF TRADE SCENARIOS FOR ORDERS WITH MINIMUM QUANTITY... 17 4.3.1 Scenario 1... 17 4.3.1.1 Steps... 17 4.3.1.2 Result... 17 4.3.2 Scenario 2... 17 4.3.2.1 Steps... 17 4.3.2.2 Result... 18 2
4.4 SELF TRADE SCENARIOS FOR FILL OR KILL ORDERS (FOK)... 18 4.4.1 Scenario 1... 18 4.4.1.1 Steps... 18 4.4.1.2 Result... 18 4.5 SELF TRADE SCENARIOS FOR PRICE AND QUANTITY CONTROL... 18 4.5.1 Scenario 1... 18 4.5.1.1 Steps... 18 4.5.1.2 Result... 19 4.5.2 Scenario 3... 19 4.5.2.1 Steps... 19 4.5.2.2 Result... 19 4.6 SELF TRADE PREVENTION GENERAL SCENARIOS... 20 4.6.1 Scenario 1: Incoming Orders from the Same Customer, but No Potential Match... 20 4.6.1.1 Steps... 20 4.6.1.2 Result... 20 4.6.2 Scenario 2: Potential match with two orders of the same customer... 20 4.6.2.1 Steps... 20 4.6.2.2 Result:... 21 4.6.3 Scenario 3: Incoming Market-to-Limit Bid matches multiple orders, but one order belongs to the same customer Bid elimination... 21 4.6.3.1 Steps... 21 4.6.3.2 Result... 21 4.6.4 Scenario 4: Simultaneous Self Trade at Customer Level and Broker / Firm Level... 21 4.6.4.1 Pre-Conditions... 21 4.6.4.2 Steps... 22 4.6.4.3 Result... 22 4.6.5 Scenario 5: Attempt to Submit Orders during an Auction... 22 4.6.5.1 Pre-Conditions... 22 4.6.5.2 Steps... 23 4.6.5.3 Result... 23 4.6.5.4 Brief explanation... 23 4.6.6 Scenario 9: Stop order: elimination when elected... 23 4.6.6.1 Steps... 23 4.6.6.2 Result... 23 5 THE UNIQUE CUSTOMER IDENTIFIER... 25 Table Index Table 1 - Scenario 1 for limit orders... 14 Table 2 - Scenario 2 for limit orders... 14 Table 3 - Scenario 2 resulting book... 14 Table 4 - Scenario 3 for limit orders... 15 Table 5 - Scenario 3 resulting book... 15 Table 6 - Scenario 4 for limit orders... 15 Table 7 - Scenario 4 resulting book... 16 Table 8 - Scenario 1 for FAK order... 16 Table 9 - Scenario 1 for FAK resulting book... 17 Table 10 - Scenario 1 for minimum quantity order... 17 Table 11 - Scenario 2 for minimum quantity order... 17 Table 12 - Scenario 2 for minimum quantity order: resulting book... 18 Table 13 - Scenario 1 for FOK order... 18 Table 14 - Scenario 1 for quantity control... 19 Table 15 - Scenario 3 for price control... 19 Table 16 - Scenario 3 for price control: resulting crossed book... 19 3
Table 17 - Initial book... 20 Table 18 - Scenario 1: two orders of the same customer resting in the book... 20 Table 19 - Scenario 2: match with same customer... 21 Table 20 Scenario 3: Market-to-Limit Bid matching with more than one order... 21 Table 21 Scenario 4: Self Trade at customer and Broker / Firm level... 22 Table 22 Scenario 5: initial crossed book... 22 Table 23 - Initial book... 23 Table 24 Scenario 9: Stop order... 24 4
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
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
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: 2.3.1 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
When a Stop order is elected, the resulting actual order is subjected to the same rules as any other incoming order. 2.5.1 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. 2.5.2 In a condition that can trigger an auction No Self Trade prevention validation is performed during conditions that can trigger an auction. 2.5.3 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
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 99.999.999/9999-99 99999999 Individual resident CPF 999.999.999-99 99999999999 Non-resident investor Investor ID 9999.999999.999999.9-9 999999 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
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). 3.1.1 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 $ 70.77 of customer 02058930 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=02058930, 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 448 35 40 Received Sent (452=5) 38 44 39 150 378 Comment 1 NewOrderSingle D 2 02058930 100 70.77 -- -- -- 2 ExecutionReport 8 2 02058930 100 70.77 0 0 -- New 3 ExecutionReport 8 2 02058930 100 70.77 4 D 103 Restated / Canceled 10
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 8 3.1.3 Self Trade prevention and Partial Fills 35 11 40 AB C AB C DE F DE F DE F 448 (452=5) 38 44 39 150 378 Comment 2 02058930 100 72.77 -- -- -- 2 02058930 100 72.77 0 0 -- New 2 02058930 100 70.77 -- -- -- 2 02058930 100 70.77 5 5 -- Replaced 2 02058930 100 70.77 4 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
Order Entry Gateway BM&FBovespa NewOrderSingle (35=D, 11=ABC, 38=100, 448=02058930, 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 448 35 11 Received Sent (452=5) 38 32 151 14 39 150 378 Comment 1 NewOrderSingle D ABC 02058930 1000 -- -- -- -- -- -- 2 ExecutionReport 8 ABC 02058930 1000 -- 1000 -- 0 0 -- New 3 ExecutionReport 8 ABC 02058930 1000 100 900 100 1 F -- Partial Fill 4 ExecutionReport 8 ABC 02058930 1000 100 800 200 1 F -- Partial Fill 5 ExecutionReport 8 ABC 02058930 1000 -- 800 200 4 D 103 Restated / Canceled 12
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=02058930, 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 3 11 40 448 38 39 150 378 636 Comment Received Sent 5 (452=5) 1 NewOrderSingle D ABC 4 02058930 100 -- -- -- -- 2 ExecutionReport 8 ABC 4 02058930 100 0 0 -- N New 3 ExecutionReport 8 ABC 2 02058930 100 0 0 -- Y New 4 ExecutionReport 8 ABC 2 02058930 100 4 D 103 -- Restated / Canceled 13
4 Examples All examples and brokers are fictional. 4.1 Self Trade Scenarios for Limit Orders 4.1.1 Scenario 1 4.1.1.1 Steps BROKER / FIRM 82 is buying 100 shares at R $ 70.77 for customer 02058930 and submits a sell order of 100 at R $ 70.77 to customer 02058930. Table 1 - Scenario 1 for limit orders 82 4/7/2011 15:42:31 100 70,77 70,97 300 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 500 70,76 70,97 100 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 300 70,75 70,98 500 4/7/2011 15:42:40 150 147 4/7/2011 15:42:15 500 70,75 70,99 500 4/7/2011 15:39:07 227 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 4.1.1.2 Result The aggressing (incoming) order should be eliminated because the aggressed one has the same unique Customer Identifier. 4.1.2 Scenario 2 4.1.2.1 Steps BROKER / FIRM 82 is buying 500 shares at R $ 70.76 for customer 00003491 and BROKER / FIRM 22 submits a sell order of 1,000 at R $ 70.75 for customer 00003491. Table 2 - Scenario 2 for limit orders Firm ID 82 4/7/2011 15:42:31 100 70,77 70,97 300 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 500 70,76 70,97 100 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 300 70,75 70,98 500 4/7/2011 15:42:40 150 147 4/7/2011 15:42:15 500 70,75 70,99 500 4/7/2011 15:39:07 227 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 4.1.2.2 Result The order is partially executed in 100 shares at R$ 70.77 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/2011 15:31:49 500 70,76 70,97 300 4/7/2011 15:42:26 54 16 4/7/2011 15:28:00 300 70,75 70,97 100 4/7/2011 15:42:40 3 147 4/7/2011 15:42:15 500 70,75 70,98 500 4/7/2011 15:42:40 150 122 4/7/2011 14:42:48 600 70,72 70,99 500 4/7/2011 15:39:07 227 71 2000 4/7/2011 15:37:57 27 14
4.1.3 Scenario 3 4.1.3.1 Steps BROKER / FIRM 147 is buying 500 shares at R$ 70.75 for customer 00219426 and submits a sell order of 10,000 at R$ 70.00 for customer 00219426. Table 4 - Scenario 3 for limit orders Broker / Firm ID Timestamp Quantity Price Price Quantity Timestamp Broker / 82 4/7/2011 15:42:31 100 70,77 70,97 300 4/7/2011 54 15:42:26 82 4/7/2011 15:31:49 500 70,76 70,97 100 4/7/2011 3 15:42:40 16 4/7/2011 15:28:00 300 70,75 70,98 500 4/7/2011 150 15:42:40 147 4/7/2011 15:42:15 500 70,75 70,99 500 4/7/2011 227 15:39:07 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 4.1.3.2 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. Table 5 - Scenario 3 resulting book Broker / Firm ID Timestamp Quantity Price Price Quantity Timestamp Broker / 147 4/7/2011 15:42:15 500 70,75 70,97 300 4/7/2011 54 15:42:26 122 4/7/2011 14:42:48 600 70,72 70,97 100 4/7/2011 3 15:42:40 70,98 500 4/7/2011 150 15:42:40 70,99 500 4/7/2011 227 15:39:07 71 2000 4/7/2011 15:37:57 27 4.1.4 Scenario 4 4.1.4.1 Steps BROKER / FIRM 21 is buying 100 shares at R $ 67.90 for customer 00054860 and submits a sell order of 10,000 at R$ 67.90 for customer 00054860. Table 6 - Scenario 4 for limit orders 82 4/7/2011 100 70,00 70,97 300 4/7/2011 15:42:26 54 15:42:31 82 4/7/2011 500 70,00 70,97 100 4/7/2011 15:42:40 3 15:31:49 16 4/7/2011 15:28:00 300 69,50 70,98 500 4/7/2011 15:42:40 150 15
147 4/7/2011 15:42:15 122 4/7/2011 14:42:48 2 4/7/2011 15:30:18 8 4/7/2011 14:33:09 21 4/7/2011 14:50:30 500 69,00 70,99 500 4/7/2011 15:39:07 227 600 68,00 71 2000 4/7/2011 15:37:57 27 100 67,95 71,1 100 4/7/2011 15:29:37 147 1000 67,90 71,2 500 4/7/2011 15:05:55 27 100 67,90 71,2 500 4/7/2011 15:21:17 227 4.1.4.2 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$ 67.90 and the remaining amount of 6900 at R$ 67.90 is eliminated. Table 7 - Scenario 4 resulting book 21 4/7/2011 100 67,90 70,97 300 4/7/2011 15:42:26 54 14:50:30 70,97 100 4/7/2011 15:42:40 3 70,98 500 4/7/2011 15:42:40 150 70,99 500 4/7/2011 15:39:07 227 71 2000 4/7/2011 15:37:57 27 71,1 100 4/7/2011 15:29:37 147 71,2 500 4/7/2011 15:05:55 27 71,2 500 4/7/2011 15:21:17 227 4.2 Self Trade Scenarios for Fill and Kill Orders (FAK) 4.2.1 Scenario 1 4.2.1.1 Steps BROKER / FIRM 147 is buying 500 shares at R $ 70.75, and customer 00219426 sends a sell order of 10,000 at R $ 70.00 for customer 00219426 with FAK qualifier. Table 8 - Scenario 1 for FAK order 82 4/7/2011 15:42:31 100 70,77 70,97 300 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 500 70,76 70,97 100 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 300 70,75 70,98 500 4/7/2011 15:42:40 150 147 4/7/2011 15:42:15 500 70,75 70,99 500 4/7/2011 15:39:07 227 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 4.2.1.2 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
Table 9 - Scenario 1 for FAK resulting book 147 4/7/2011 15:42:15 500 70,75 70,97 300 4/7/2011 15:42:26 54 122 4/7/2011 14:42:48 600 70,72 70,97 100 4/7/2011 15:42:40 3 70,98 500 4/7/2011 15:42:40 150 70,99 500 4/7/2011 15:39:07 227 71 2000 4/7/2011 15:37:57 27 4.3 Self Trade Scenarios for Orders with Minimum Quantity 4.3.1 Scenario 1 4.3.1.1 Steps BROKER / FIRM 147 is buying 500 shares at R $ 70.75 for customer 00219426 and sends a sell order of 10,000 at R$ 70.00 with minimum quantity equals to 1000 for customer 00219426. Table 10 - Scenario 1 for minimum quantity order Firm ID 82 4/7/2011 15:42:31 100 70,77 70,97 300 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 500 70,76 70,97 100 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 300 70,75 70,98 500 4/7/2011 15:42:40 150 147 4/7/2011 500 70,75 70,99 500 4/7/2011 15:39:07 227 15:42:15 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 4.3.1.2 Result The order is eliminated because it couldn t achieve the minimum quantity before reaching the Bid tagged with the same unique customer identifier. 4.3.2 Scenario 2 4.3.2.1 Steps BROKER / FIRM 147 is buying 500 shares at R$ 70.75 for customer 00219426 and BROKER / FIRM 22 submits a sell order for 1,000 at R$ 70.00 for customer 00219426 with a minimum quantity equals to 500. Table 11 - Scenario 2 for minimum quantity order 82 4/7/2011 15:42:31 100 70,77 70,97 300 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 500 70,76 70,97 100 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 300 70,75 70,98 500 4/7/2011 15:42:40 150 147 4/7/2011 500 70,75 70,99 500 4/7/2011 15:39:07 227 15:42:15 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 17
4.3.2.2 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/2011 500 70,75 70,97 300 4/7/2011 15:42:26 54 15:42:15 122 4/7/2011 14:42:48 600 70,72 70,97 100 4/7/2011 15:42:40 3 70,98 500 4/7/2011 15:42:40 150 70,99 500 4/7/2011 15:39:07 227 71 2000 4/7/2011 15:37:57 27 4.4 Self Trade Scenarios for Fill or Kill Orders (FOK) 4.4.1 Scenario 1 4.4.1.1 Steps BROKER / FIRM 82 is buying 500 shares at R$ 70.76 for customer 00219426 and sends a sell order with qualifier FOK of 1,000 at R$ 70.00 for customer 00219426. Table 13 - Scenario 1 for FOK order 82 4/7/2011 100 70,77 70,97 300 4/7/2011 15:42:26 54 15:42:31 82 4/7/2011 500 70,76 70,97 100 4/7/2011 15:42:40 3 15:31:49 16 4/7/2011 300 70,75 70,98 500 4/7/2011 15:42:40 150 15:28:00 147 4/7/2011 500 70,75 70,99 500 4/7/2011 15:39:07 227 15:42:15 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 4.4.1.2 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 4.5.1 Scenario 1 4.5.1.1 Steps BROKER / FIRM 82 is buying 1000 shares at R$ 70.77 for customer 00219426 and BROKER / FIRM 22 sends a sell order of 1,500 at R$ 70.00 for customer 00219426. The quantity band is triggered with a quantity equals to or higher than 900. 18
Table 14 - Scenario 1 for quantity control 82 4/7/2011 1000 70,77 70,97 300 4/7/2011 15:42:26 54 15:42:31 82 4/7/2011 15:31:49 500 70,76 70,97 100 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 300 70,75 70,98 500 4/7/2011 15:42:40 150 147 4/7/2011 15:42:15 500 70,75 70,99 500 4/7/2011 15:39:07 227 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 4.5.1.2 Result The incoming Ask triggers an auction despite of being tagged with the same unique customer identifier of the resting 1000Lots@70.77 Bid. 4.5.2 Scenario 3 4.5.2.1 Steps BROKER / FIRM 16 is buying 300 shares at R$ 70.75 for customer 00219426 and sends a sell order of 1,000 at R $ 70.00 for customer 00219426. The auction price band is triggered with a price equals to or less than R$ 70.75. Table 15 - Scenario 3 for price control 82 4/7/2011 100 70,77 70,97 300 4/7/2011 15:42:26 54 15:42:31 82 4/7/2011 500 70,76 70,97 100 4/7/2011 15:42:40 3 15:31:49 147 4/7/2011 500 70,75 70,98 500 4/7/2011 15:42:40 150 15:28:00 16 4/7/2011 300 70,75 70,99 500 4/7/2011 15:39:07 227 15:42:15 122 4/7/2011 14:42:48 600 70,72 71 2000 4/7/2011 15:37:57 27 4.5.2.2 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$ 70.75. Table 16 - Scenario 3 for price control: resulting crossed book 147 4/7/2011 500 70,75 70,75 400 4/7/2011 16 15:28:00 16:01:00 16 4/7/2011 300 70,75 70,97 300 4/7/2011 15:42:26 54 15:42:15 122 4/7/2011 600 70,72 70,97 100 4/7/2011 15:42:40 3 14:42:48 70,98 500 4/7/2011 15:42:40 150 70,99 500 4/7/2011 15:39:07 227 71 2000 4/7/2011 15:37:57 27 19
4.6 Self Trade Prevention General Scenarios For the remaining scenarios, the following initial order book applies: Reference price = $1499.00 Auction bands: $1494.00 x 1503.00 Quantity band = 700Lots Protection points = $2.00 Table 17 - Initial book 82 4/7/2011 15:42:31 100 $1499.00 $1501.00 100 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 150 $1498.50 $1502.00 200 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 150 $1498.00 $1502.50 100 4/7/2011 15:42:40 150 147 4/7/2011 15:42:15 100 $1495.00 $1504.00 50 4/7/2011 15:39:07 227 4.6.1 Scenario 1: Incoming Orders from the Same Customer, but No Potential Match 4.6.1.1 Steps Broker / Firm 22 sends new bid of 100Lots@$1495.00. It is tagged with a unique Customer Identifier. An incoming ask of 100Lots@$1501.00 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/2011 15:42:31 100 $1499.00 $1501.00 100 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 150 $1498.50 $1501.00 100 4/7/2011 16:01:33 29 16 4/7/2011 15:28:00 150 $1498.00 $1502.00 200 4/7/2011 15:42:40 3 147 4/7/2011 15:42:15 100 $1495.00 $1502.50 100 4/7/2011 15:42:40 150 22 4/7/2011 16:01:31 100 $1495.00 $1504.00 50 4/7/2011 15:39:07 227 4.6.1.2 Result This scenario does not trigger any Self Trade action because there is no potential match. Both orders will rest in the order book. 4.6.2 Scenario 2: Potential match with two orders of the same customer 4.6.2.1 Steps Broker / Firm 22 submitted a bid of 100Lots@$1500.00 NOT tagged with unique Customer Identifier. Broker / Firm 29 is submitting a limit ask of 100Lots@$1500.00 tagged with a unique Customer Identifier. 20
Table 19 - Scenario 2: match with same customer 22 4/7/2011 100 $1500.00 $1501.00 100 4/7/2011 15:42:26 54 16:01:31 82 4/7/2011 15:42:31 100 $1499.00 $1502.00 200 4/7/2011 15:42:40 3 82 4/7/2011 15:31:49 150 $1498.50 $1502.50 100 4/7/2011 15:42:40 150 16 4/7/2011 15:28:00 150 $1498.00 $1504.00 50 4/7/2011 15:39:07 227 147 4/7/2011 15:42:15 100 $1495.00 4.6.2.2 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@$1500.00 4.6.3 Scenario 3: Incoming Market-to-Limit Bid matches multiple orders, but one order belongs to the same customer Bid elimination 4.6.3.1 Steps A limit Ask, from Broker / Firm 29, is resting in the book. It is 100Lots@$1501.00 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/2011 15:42:31 100 $1499.00 $1501.00 100 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 150 $1498.50 $1501.00 100 4/7/2011 29 16:01:33 16 4/7/2011 15:28:00 150 $1498.00 $1502.00 200 4/7/2011 15:42:40 3 147 4/7/2011 15:42:15 100 $1495.00 $1502.50 100 4/7/2011 15:42:40 150 $1504.00 50 4/7/2011 15:39:07 227 4.6.3.2 Result First trade is 100Lots@$1501.00. Remaining bid quantity is $200Lots. When trying to match with 100Lots@$1501.00 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. 4.6.4 Scenario 4: Simultaneous Self Trade at Customer Level and Broker / Firm Level 4.6.4.1 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
Both orders are submitted by the same customer (same unique Customer Identifier) and through the same Broker / Firm. 4.6.4.2 Steps Broker / Firm 22 submitted an Ask of 100Lots@$1500.00 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/2011 15:42:31 100 $1499.00 $1500.00 100 7/7/2011 16:01:31 22 82 4/7/2011 15:31:49 150 $1498.50 $1501.00 100 4/7/2011 15:42:26 54 16 4/7/2011 15:28:00 150 $1498.00 $1502.00 200 4/7/2011 15:42:40 3 147 4/7/2011 15:42:15 100 $1495.00 $1502.50 100 4/7/2011 15:42:40 150 $1504.00 50 4/7/2011 15:39:07 227 Broker / Firm 22 submits an incoming limit bid of 100Lots@$1500.00, tagged with the same unique Customer Identifier. 4.6.4.3 Result The incoming Bid triggers an auction due to Self Trade at Broker / Firm level. 4.6.5 Scenario 5: Attempt to Submit Orders during an Auction 4.6.5.1 Pre-Conditions Current parameters: Reference price = $1499.00 Auction bands: $1494.00 x 1503.00 Quantity band = 700Lots Protection points = $2.00 Broker / Firm 82 submitted a Bid of 400Lots@$1500.00 tagged with a unique Customer Identifier. Broker / Firm 54 submitted an Ask of 700Lots@$1500.50 with the same unique Customer Identifier. Broker / Firm 82 submitted a Bid of 800Lots@$1501.00 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 = $1501.00 / TOQ = 800 82 4/7/2011 15:42:31 800 $1501.00 $1500.50 700 4/7/2011 54 15:42:26 82 4/7/2011 400 $1500.00 $1501.00 100 4/7/2011 15:42:40 3 15:31:49 16 4/7/2011 15:28:00 100 $1499.00 $1502.00 200 4/7/2011 15:42:40 150 147 4/7/2011 15:42:15 150 $1499.00 $1502.00 100 4/7/2011 15:39:07 227 22
4.6.5.2 Steps Broker / Firm 82 submitted a Bid of 200Lots@$1502.00, tagged with the same unique Customer Identifier as the highlighted orders in the book (400@$1500.00 Bid and 700@$1500.50 Ask). 4.6.5.3 Result The incoming bid 200Lots@$1502.00 is accepted. 4.6.5.4 Brief explanation There is no Self Trade validation at customer level during an auction. 4.6.6 Scenario 9: Stop order: elimination when elected Similar to previous examples from section 4.6, the initial book condition is: Reference price = $1499.00 Auction bands: $1494.00 x 1503.00 Quantity band = 700Lots Protection points = $2.00 A Stop Bid, from Broker / Firm 22, is resting in the stop order book. It triggers at $1500.00 and becomes a limit bid of 100Lots@$1501.00. This order is tagged with the same unique customer identifier as the Ask 100Lots@$1501.00 from broker 29. Table 23 - Initial book 82 4/7/2011 15:42:31 100 $1499.00 $1501.00 100 4/7/2011 15:42:26 54 82 4/7/2011 15:31:49 150 $1498.50 $1502.00 200 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 150 $1498.00 $1502.50 100 4/7/2011 15:42:40 150 147 4/7/2011 15:42:15 100 $1495.00 $1504.00 50 4/7/2011 15:39:07 227 4.6.6.1 Steps A limit Ask, from Broker / Firm 29, is entered. It is 100Lots@$1501.00 tagged with a unique Customer Identifier. Ask 100Lots@1501.00 from Broker / Firm 54 is cancelled There is an incoming limit Bid of 100Lots@$1500.00 from Broker / Firm 99 There is an incoming limit Ask of 100Lots@$1500.00 from Broker / Firm 98 4.6.6.2 Result There is trade of 100Lots@$1500.00. Now the LTP (last trade price) = $1500.00 and the resulting book is: 23
Table 24 Scenario 9: Stop order 82 4/7/2011 15:42:31 100 $1499.00 $1501.00 100 4/7/2011 29 16:01:33 82 4/7/2011 15:31:49 150 $1498.50 $1502.00 200 4/7/2011 15:42:40 3 16 4/7/2011 15:28:00 150 $1498.00 $1502.50 100 4/7/2011 15:42:40 150 147 4/7/2011 15:42:15 100 $1495.00 $1504.00 50 4/7/2011 15:39:07 227 Because now LTP = $1500.00, Stop order would become a limit Bid of 100Lots@$1501.00. But as such condition would lead to self-trade with 100Lots@$1501.00 Ask, the Bid is eliminated. The book remains as above. 24
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 99.999.999/9999-99. Unique Customer Identifier will be: 99999999 Investor 2: individual and resident in Brazil CPF is 999.999.999-99. Unique Customer Identifier will be: 99999999999 Investor 3: non-resident investor ID is 9999.999999.999999.9.9. Unique Customer Identifier will be: 999999 25