MEFFGate Trading FIX INTERFACE SPECIFICATIONS

MEFFGate Trading FIX INTERFACE SPECIFICATIONS Version T1.2 30 July 2012

The information contained in this document is subject to modification without notice. Unless otherwise noted, the companies, names and data used in the examples are fictitious. No part of this document may be reproduced or transmitted in any form or by any means, be it electronical or mechanical, for any reason without written permission. 2008 MEFF. All rights reserved 2009 MEFF. All rights reserved 2010 MEFF. All rights reserved 2011 MEFF. All rights reserved 2012 MEFF. All rights reserved ii

Changes made in the latest revision Outlined below are the main changes made in the version T1.2: General The new version of the MEFFGate FIX protocol T1.2. As it is explained in section 2.7 Identification of the MEFFGate FIX protocol of this manual, if the client application wishes to use the new version T1.2 of the protocol, it must use the tag ProprietaryFixProtocolVersion [5680] in the Logon message. If no specific value is sending in this tag, MEFFGate will use the version indicated in the MEFFGate user configuration The maximum number of subscriptions of every type per connection is now documented: 40 subscriptions Management of cross trades has been reviewed, with new messages (Trade Capture Report, Trade Capture Report Ack, Trade Capture Report Request and Trade Capture Report Request Ack). Message New Order-Cross has been removed from this version (T1.2) and all the previous ones also It sets out how to identify a non-standard (flexible) contract in the cross trade functionality: SecurityID [48] + CFICode[461] + MaturityDate [541] + ContractMultiplier [231] + StrikePrice [202]. The messages related are: Trade Capture Report and Trade Capture Report Ack For trade cancellation the message Execution Report will be used, with ExecType = H New fields The NumberOfOrders [346] field has been added to the Market Data Snapshot Full Refresh message The EventDate [866] field has been added to the Security List message to inform the last trading day of the contract The block Stipulations has been added to the Security List message to indicate whether the security admits orders and/or cross trades The StrikeValue [968], RoundLot [561] and MinTradeVol [562] have been added to the Security List message The HaltReason [327] has been added to the Security Status message The TrdMatchID [880] field has been added to the Execution Report message. It contains the trade registration number (in the previous version this information was in the SecondaryExecID [527] field) The GrossTradeAmt [381] field has been added to the Execution Report message The SecondaryExecID [527] field has been added to the Quote Status Report message The OnBehalfOfCompID [115], OnBehalfOfSubID [116], DeliverToCompID [128] and DeliverToSubID [129] have been added to the Standard Message Header Changes to fields The SecondaryExecID [527] tag has changed its meaning. Now contains the order history number Two new values (9 y M) have been added to the tag MDEntryType [269] in the messages Marker Data Request y Market Data Snapshot Full Refresh. The OpenCloseSettleFlag [286] iii

field has been removed from the Market Data Snapshot Full Refresh message Now the fields OrderQty [38], BidSize [134], OfferSize [135], LastQty [32], LeavesQty [151] and CumQty [14] have a greater size The order reference has a new size of 15 characters long. This is related to the tag Text [58] in the New Order-Single, Order Modification Request and Execution Report messages Values for the field OrdRejReason [103] have been reviewed in the Execution Report and Quote Status Report messages As a consequence of the New Order Cross message removal, the field CrossType [549] has been erased from the Execution Report message Outlined below are the main changes from the documentation published on 1 December 2008: The NumberOfOrders [346] field has been removed from the Market Data Snapshot Full Refresh message Values for the field OrdRejReason [103] have been reviewed in the Execution Report and Quote Status Report messages A new message flow Modification request accepted by MEFFGate of an order executed in the moment it is requested has been added in 8.4.4 (Modify orders Message flow) to indicate that an Order Cancel Reject message is sent responding to an Order Modification Request The message flow Cancellation request accepted by MEFFGate of an order executed in the moment it is requested has been modify in 8.5.4 (Cancel orders Message flow) to indicate that an Order Cancel Reject message is sent responding to an Order Cancel Request The following message flow has been reviewed: 10.8 (Cross trades) The following messages have been reviewed: 10.10.4 (Trade Capture Report sent by MEFFGate) and 10.10.5 (Trade Capture Report Ack) Outlined below are the main changes from the documentation published on 11 March 2009: Energy Contract Group: Tag 200 (MaturityMonthYear) is YYYYMMwW for weekly expiration dates Values for the field AccountType [581] have been reviewed in the Trade Capture Report sent to MEFFGate, Trade Capture Report sent by MEFFGate and Trade Capture Report Ack messages Values for the field NoSides [552] have been reviewed in the Trade Capture Report sent to MEFFGate message Outlined below are the main changes from the documentation published on 24 September 2009: The following messages have been reviewed: 10.10.3 (Trade Capture Report sent to MEFFGate), 10.10.4 (Trade Capture Report sent by MEFFGate) and 10.10.5 (Trade Capture Report Ack). Also has been reviewed the related chapter 4.5.4 (General conventions in application messages - Instrument block - Contract code (Symbol field) or using the combination SecurityID + CFICode + MaturityDate + ContractMultiplier + StrikePrice) Corrected inaccurate situation of the block Stipulations in Security List message iv

Outlined below are the main changes from the documentation published on 16 March 2010: Request for Quote (new functionality): o o New messages: Quote Request and Quote Request Reject The members that are currently receiving the Indication of Interest message won t notice any change in their FIX interface o A detailed explanation has been included in chapter 7 - Request for Quote - Indication of Interest o New message flows have been added in chapter 7 o Chapter 1.2 has been updated Trading Session Status message: Value 0 (Unknown) has been removed from the tag TradSesStatus [340] Market Data Snapshot Full Refresh message: Description of the field PriceDelta [811] has been updated Outlined below are the main changes from the documentation published on 25 November 2011: The chapter 9.8.1 - Delta protection and Account configuration for quotes: Introduction has been modified to indicate the delta protection functionality is currently not available. As a consequence, all the parameters related to delta protection have to be configured with a zero value The format of the following tags: MsgSeqNum [34], NextExpectedMsgSeqNum [789] and RefSeqNum [45] have been corrected to SeqNum (according to the FIX standard) Outlined below are the main changes from the documentation published on 25 November 2011: Delta protection and Account configuration for quotes: o o From version 9.50 the delta protection functionality is available Chapters 9.8.1 - Introduction Delta protection and Account configuration for quotes and 9.8.2- Delta Protection: Description and Registration Instructions / Registration Instructions Response messages, have been modified to include the new reasons for cancellation due to delta protection. Three limits, which act independently, can be configured during an established time period: Total volume of traded contracts Delta: abs[volume of (Calls buy + Puts sell + Futures buy) (Calls sell + Puts buy Futures sell)] abs[total buy volume Total sell volume] o Tag CFICode [461]: Added value FMXXXX to allow time-spreads quoting v

Contents Changes made in the latest revision... iii Contents...vi Index of Messages... x 1. Introduction... 1 1.1 Scope of this manual... 1 1.2 Public and private information... 2 1.3 Structure of manual... 3 1.4 Format of the message definition tables... 4 1.5 Related documents... 4 2. Implementation decisions... 5 2.1 Description... 5 2.2 Fields ignored... 5 2.3 Unsupported fields... 5 2.4 Length of String type... 5 2.5 Maximum length of message... 5 2.6 Encryption... 5 2.7 Identification of the MEFFGate FIX protocol... 5 3. FIX Session... 6 3.1 Introduction... 6 3.2 FIX session and communication session... 6 3.3 Identification of the FIX session... 6 3.4 Client software and FIX sessions... 7 3.5 Message routing from different users through an unique FIX session (multilogon connection)... 7 3.6 Synchronisation of the FIX session... 7 3.7 Synchronisation at application level... 10 3.8 High availability... 10 3.9 PossResend field... 11 3.10 Reception of information for all traders of the member... 11 3.11 Reception of information on actions taken on behalf of the trader... 11 3.12 Administrative messages that the FIX client must manage... 11 3.13 List of messages... 11 3.14 Message flow... 12 3.15 Annotations and adaptations of FIX 4.4... 14 3.16 Definition of messages... 15 3.16.1 Standard Message Header... 15 3.16.2 Standard Message Trailer... 17 3.16.3 Logon (Msg Type = A)... 18 3.16.4 Logout (Msg Type = 5)... 19 3.16.5 Heartbeat (Msg Type = 0)... 20 3.16.6 Test Request (Msg Type = 1)... 21 3.16.7 Resend Request (Msg Type = 2)... 22 3.16.8 Sequence Reset (Msg Type = 4)... 23 3.16.9 Reject (Msg Type = 3)... 24 4. General conventions in application messages...25 4.1 Order identification... 25 4.1.1 ClOrdID... 25 4.1.2 OrderID... 25 4.1.3 SecondaryOrderID... 25 4.1.4 SecondaryExecID... 25 4.2 Trade identification... 26 4.2.1 ExecID... 26 4.2.2 TrdMatchID... 26 4.3 Parties block... 26 4.4 Symbol and SecurityID... 29 4.5 Instrument block... 30 4.5.1 CFICode... 30 4.5.2 Underlying asset (SecurityID field)... 30 4.5.3 Expiration (MaturityMonthYear field)... 31 vi

4.5.4 Contract code (Symbol field) or using the combination SecurityID + CFICode + MaturityDate + ContractMultiplier + StrikePrice... 31 4.5.5 Combination of selection criteria... 31 4.6 Error format (Text Field)... 31 4.7 Limitation on the maximum permitted number of subscriptions alive... 32 5. Common Application Messages...33 5.1 Introduction... 33 5.2 Network communication status... 33 5.3 Password change... 33 5.4 Rejection of application messages... 33 5.5 List of messages... 33 5.6 Message flow... 34 5.7 Annotations and adaptations of FIX 4.4... 34 5.8 Definition of messages... 35 5.8.1 Network Counterparty System Status Request (Msg Type = BC)... 35 5.8.2 Network Counterparty System Status Response (Msg Type = BD)... 36 5.8.3 User Request (Msg Type = BE)... 37 5.8.4 User Response (Msg Type = BF)... 38 5.8.5 Business Message Reject (MsgType = j)... 39 6. Market Information...40 6.1 Introduction... 40 6.2 Market information: Status of trading session... 41 6.2.1 Description... 41 6.2.2 List of messages... 41 6.2.3 Message flow... 41 6.2.4 Annotations and adaptations of FIX 4.4... 42 6.3 Market information: Contracts... 43 6.3.1 Description... 43 6.3.2 Request contract information... 43 6.3.3 Reception of contract definitions... 44 6.3.4 Reception of contract status... 44 6.3.5 Ending subscriptions... 44 6.3.6 List of messages... 44 6.3.7 Flow of messages... 45 6.3.8 Annotations and adaptations of FIX 4.4... 49 6.4 Market information: Prices... 50 6.4.1 Description... 50 6.4.2 Information request... 50 6.4.3 Receipt of information... 50 6.4.4 List of messages... 51 6.4.5 Message flow... 51 6.4.6 Annotations and adaptations of FIX 4.4... 52 6.5 Definition of messages... 53 6.5.1 Trading Session Status Request (Msg Type = g)... 53 6.5.2 Trading Session Status (Msg Type = h)... 54 6.5.3 Security List Request (Msg Type = x)... 55 6.5.4 Security List (Msg Type = y)... 56 6.5.5 Security Status Request (MsgType = e)... 59 6.5.6 Security Status (MsgType = f)... 60 6.5.7 Market Data Request (Msg Type = V)... 61 6.5.8 Market Data Request Reject (Msg Type = Y)... 62 6.5.9 Market Data Snapshot Full Refresh (Msg Type = W)... 63 7. Request for Quote - Indication of Interest...65 7.1 Introduction... 65 7.2 Description... 65 7.3 List of messages... 65 7.4 Message flow... 66 7.5 Annotations and adaptations of FIX 4.4... 67 7.6 Definition of messages... 68 7.6.1 Quote Request (Msg Type = R)... 68 7.6.2 Quote Request Reject (Msg Type = AG)... 69 7.6.3 Indication of Interest (Msg Type = 6)... 70 8. Order management and trades notification...71 8.1 Introduction... 71 vii

8.2 Order management on behalf of a trader... 71 8.3 Enter orders... 72 8.3.1 Description... 72 8.3.2 Order entry status... 72 8.3.3 Supported order types and validity of orders... 72 8.3.4 Order persistence... 72 8.3.5 Give-up instructions in the order entry... 73 8.3.6 List of messages... 73 8.3.7 Message flow... 73 8.3.8 Annotations and adaptations of FIX 4.4... 75 8.4 Modify orders... 76 8.4.1 Description... 76 8.4.2 Order modification request status... 76 8.4.3 List of messages... 77 8.4.4 Message flow... 77 8.4.5 Annotations and adaptations of FIX 4.4... 78 8.5 Cancel orders... 79 8.5.1 Description... 79 8.5.2 Status of order cancellation request... 79 8.5.3 List of messages... 79 8.5.4 Message flow... 80 8.5.5 Annotations and adaptations of FIX 4.4... 81 8.6 Mass cancellation of orders... 82 8.6.1 Description... 82 8.6.2 Selection criteria... 82 8.6.3 Status of mass cancellation request... 82 8.6.4 ClOrdID field... 82 8.6.5 List of messages... 83 8.6.6 Message flow... 83 8.6.7 Annotations and adaptations of FIX 4.4... 84 8.7 Notification of execution... 85 8.7.1 Description... 85 8.7.2 Trade cancellation... 85 8.7.3 List of messages... 85 8.7.4 Message flow... 85 8.7.5 Annotations and adaptations of FIX 4.4... 86 8.8 Order Status Request... 87 8.8.1 Description... 87 8.8.2 List of messages... 87 8.8.3 Message flow... 88 8.8.4 Annotations and adaptations of FIX 4.4... 88 8.9 Definition of messages... 89 8.9.1 New Order - Single (Msg Type = D)... 89 8.9.2 Order Cancel Request (Msg Type = F)... 91 8.9.3 Order Modification Request (Msg Type = G)... 92 8.9.4 Execution Report (Msg Type = 8)... 95 8.9.5 Order Cancel Reject (Msg Type = 9)... 99 8.9.6 Order Status Request (Msg Type = H)... 100 8.9.7 Order Mass Cancel Request (Msg Type = q)... 101 8.9.8 Order Mass Cancel Report (Msg Type = r)... 102 8.9.9 Order Mass Status Request (Msg Type = AF)... 103 9. Quote management...104 9.1 Introduction... 104 9.2 Enter quotes... 105 9.2.1 Description... 105 9.2.2 List of messages... 105 9.2.3 Message flow... 106 9.2.4 Annotations and adaptations of FIX 4.4... 109 9.3 Modify quotes... 110 9.3.1 Description... 110 9.3.2 List of messages... 110 9.3.3 Message flow... 110 9.3.4 Annotations and adaptations of FIX 4.4... 112 9.4 Cancel quotes... 113 9.4.1 Description... 113 9.4.2 Selection criteria... 113 viii

9.4.3 List of messages... 113 9.4.4 Message flow... 114 9.4.5 Annotations and adaptations of FIX 4.4... 115 9.5 Notification of quote execution... 116 9.5.1 Description... 116 9.5.2 List of messages... 116 9.5.3 Message flow... 116 9.5.4 Annotations and adaptations of FIX 4.4... 116 9.6 Quote Status Request... 117 9.6.1 Description... 117 9.6.2 List of messages... 117 9.6.3 Message flow... 117 9.6.4 Annotations and adaptations of FIX 4.4... 117 9.7 Definition of messages... 118 9.7.1 Quote (Msg Type = S)... 118 9.7.2 Quote Cancel (Msg Type = Z)... 119 9.7.3 Quote Status Request (Msg Type = a)... 120 9.7.4 Quote Status Report (Msg Type = AI)... 121 9.8 Delta protection and Account configuration for quotes... 123 9.8.1 Introduction... 123 9.8.2 Delta Protection: Description... 123 9.8.3 RegistID... 123 9.8.4 List of messages... 125 9.8.5 Message flow... 125 9.8.6 Annotations and adaptations of FIX 4.4... 126 9.8.7 Definition of messages... 127 9.9 Quote parameters report... 131 9.9.1 Description... 131 9.9.2 List of messages... 131 9.9.3 Message flow... 131 9.9.4 Annotations and adaptations of FIX 4.4... 132 9.9.5 Definition of messages... 133 10. Cross trades...135 10.1 Introduction... 135 10.2 Entry of cross trades between different members... 135 10.3 Acceptance of cross trades between different members... 136 10.4 Entry of cross trades within the member... 136 10.5 Price and Effective amount... 137 10.6 Cross trade groups and cash market cross trades... 137 10.7 List of messages... 137 10.8 Message flow... 138 10.9 Annotations and adaptations of FIX 4.4... 142 10.10 Definition of messages... 143 10.10.1 Trade Capture Report Request (Msg Type = AD)... 143 10.10.2 Trade Capture Report Request Ack (Msg Type = AQ)... 144 10.10.3 Trade Capture Report (Msg Type = AE) sent to MEFFGate... 145 10.10.4 Trade Capture Report (Msg Type = AE) sent by MEFFGate... 148 10.10.5 Trade Capture Report Ack (Msg Type = AR)... 151 11. Communication of Events...154 11.1 Introduction... 154 11.2 List of messages... 154 11.3 Message flow... 154 11.4 Annotations and adaptations of FIX 4.4... 154 11.5 Definition of messages... 155 11.5.1 News (Msg Type = B)... 155 Appendix A MEFF Order Types... A-1 Appendix B User Fields... B-1 ix

Index of Messages 3.16.1 Standard Message Header... 15 3.16.2 Standard Message Trailer... 17 3.16.3 Logon (Msg Type = A)... 18 3.16.4 Logout (Msg Type = 5)... 19 3.16.5 Heartbeat (Msg Type = 0)... 20 3.16.6 Test Request (Msg Type = 1)... 21 3.16.7 Resend Request (Msg Type = 2)... 22 3.16.8 Sequence Reset (Msg Type = 4)... 23 3.16.9 Reject (Msg Type = 3)... 24 5.8.1 Network Counterparty System Status Request (Msg Type = BC)... 35 5.8.2 Network Counterparty System Status Response (Msg Type = BD)... 36 5.8.3 User Request (Msg Type = BE)... 37 5.8.4 User Response (Msg Type = BF)... 38 5.8.5 Business Message Reject (MsgType = j)... 39 6.5.1 Trading Session Status Request (Msg Type = g)... 53 6.5.2 Trading Session Status (Msg Type = h)... 54 6.5.3 Security List Request (Msg Type = x)... 55 6.5.4 Security List (Msg Type = y)... 56 6.5.5 Security Status Request (MsgType = e)... 59 6.5.6 Security Status (MsgType = f)... 60 6.5.7 Market Data Request (Msg Type = V)... 61 6.5.8 Market Data Request Reject (Msg Type = Y)... 62 6.5.9 Market Data Snapshot Full Refresh (Msg Type = W)... 63 7.6.1 Quote Request (Msg Type = R)... 68 7.6.2 Quote Request Reject (Msg Type = AG)... 69 7.6.3 Indication of Interest (Msg Type = 6)... 70 8.9.1 New Order - Single (Msg Type = D)... 89 8.9.2 Order Cancel Request (Msg Type = F)... 91 8.9.3 Order Modification Request (Msg Type = G)... 92 8.9.4 Execution Report (Msg Type = 8)... 95 8.9.5 Order Cancel Reject (Msg Type = 9)... 99 8.9.6 Order Status Request (Msg Type = H)... 100 8.9.7 Order Mass Cancel Request (Msg Type = q)... 101 8.9.8 Order Mass Cancel Report (Msg Type = r)... 102 8.9.9 Order Mass Status Request (Msg Type = AF)... 103 9.7.1 Quote (Msg Type = S)... 118 9.7.2 Quote Cancel (Msg Type = Z)... 119 9.7.3 Quote Status Request (Msg Type = a)... 120 9.7.4 Quote Status Report (Msg Type = AI)... 121 10.10.1 Trade Capture Report Request (Msg Type = AD)... 143 10.10.2 Trade Capture Report Request Ack (Msg Type = AQ)... 144 10.10.3 Trade Capture Report (Msg Type = AE) sent to MEFFGate... 145 10.10.4 Trade Capture Report (Msg Type = AE) sent by MEFFGate... 148 10.10.5 Trade Capture Report Ack (Msg Type = AR)... 151 11.5.1 News (Msg Type = B)... 155 x

1. Introduction 1. Introduction 1.1 Scope of this manual This document contains the definition of the interface provided by MEFF for developing applications related with the trading scope. The interface is based on version 4.4 of the FIX Protocol standard (Financial Information exchange). More detailed information about the standard can be found in reference document 1 (see 1.5) or on the website www.fixprotocol.org. The interface follows the FIX 4.4 specifications, as far as possible. In the majority of cases the structure and semantics of the messages are identical to the standard. In some cases, the protocol has been extended to cover functions not considered by the standard. These extensions are clearly detailed in the document. In other cases, the standard is ambiguous or indicates that the details should be mutually defined by the parties. In these cases the manual provides a detailed description to avoid any possible ambiguity. All annotations and adaptations of the standard have been done in accordance with the recommendations in the standard. To avoid possible duplication in the sources of information, this document does not include explanations of those matters that comply exactly with the standard. Therefore, the standard documentation should be considered as the main source of information for any matter that is not explicitly covered in this manual. This is a reference document for those Members and ISVs that wish to develop software that can communicate with the market using the MEFFGate server FIX interface. 30 July 2012 MEFF 2012 1

1. Introduction 1.2 Public and private information The functions covered by MEFFGate are grouped into public and private information. The following table displays the public functions and their related messages. Public function Obtain session status Obtain information on contracts Obtain information on prices Obtain information about indications of interest Related messages Trading Session Status Request Trading Session Status Security List Request Security List Security Status Request Security Status Market Data Request Market Data Request Reject Market Data Snapshot / Full Refresh Indication of Interest (Parties Block not informed) The following table displays the private functions and their related messages. Private function Order management Quote management Cross trades Send messages to market supervisor and Reception of administrator s messages Request for Quote Related messages New Order Single Order Cancel Request Order Modification Request Execution Report Order Cancel Reject Order Status Request Order Mass Cancel Request Order Mass Cancel Report Order Mass Status Request Quote Quote Status Report Execution Report Quote Cancel Quote Status Request Execution Report Trade Capture Report Request Trade Capture Report Request Ack Trade Capture Report Trade Capture Report Ack Execution Report News Quote Request Quote Request Reject Indication of Interest (Parties Block informed) 30 July 2012 MEFF 2012 2

1. Introduction 1.3 Structure of manual The manual is divided into two parts. The first part, containing the first four chapters, gives a description of generic features of this interface. This first chapter describes the scope of the document, its structure and introduces the related documents. Chapter 2 Implementation decisions presents those annotations or restrictions arising from the implementation of the protocol defined in this manual. Chapter 3 FIX Session describes those aspects related to the session level, including the detailed description of the corresponding messages. Chapter 4 General conventions in application messages describes in detail specific aspects that affect the majority of the messages described in this manual. Given the generic nature of the content, which affects all the messages, it is recommended to read chapters 2, 3 and 4 before considering other chapters. The second part of the manual, containing the remainder of the chapters, describes the different functions supported by MEFFGate. Each of these chapters deals with a specific function, describing specific matters of interest. Each of these chapters contains the following sections: Introduction. A brief description of the function covered in the chapter List of messages. List of the different messages implemented by the function Message flow. Description of the different scenarios for message exchange that may arise, with the corresponding message flow diagrams Annotations and adaptations of FIX 4.4. Details the annotations and adaptations that MEFF has made to the standard protocol to meet its needs Definition of messages. Contains a table for each message in the chapter, describing the message fields in detail Finally, various tables providing information referred to throughout the document are included as appendices. 30 July 2012 MEFF 2012 3

1. Introduction 1.4 Format of the message definition tables As explained in the previous section, a table for each message is included in those chapters where it is necessary, describing the component fields in detail. These tables contain one field per row and have the following columns: Column Tag Name Req Meaning Field number. The fields added to the message in this implementation have an asterisk ( * ) after the number Name of field according to the FIX standard Y indicates that the field is required; N means that the field is optional. Y* means that the field is required in this implementation, but it is optional in the FIX 4.4 standard Valid values Format Accepted values for the field in the context of the message. It may be a list of values, or a range of numeric values, e.g. >=3, <= 10. The default value for the field is also indicated in this column. To avoid confusions with the terms, the original FIX value description has been respected in the values associated with codes. Type of data in the field. It is one of the types defined by FIX, or one of these types with some additional restriction. String(n) is a String type with a maximum of n characters, or in some cases with exactly n characters. For more information on the String type, See 2.4 Description Description of the field in the context of the message 1.5 Related documents # Title Author Version 1 Financial Information Exchange Protocol (FIX) 4.4 with errata 20030618 FIX Committee 18 June 2003 2 Financial Information Exchange Protocol (FIX) 5.0 candidate release FIX Committee October 2006 3 HF MEFFGate FIX Interface Specifications T3.3 MEFF 30 July 2012 4 HF MEFFGate FIX Interface Specifications M3.3 MEFF 30 July 2012 5 HF MEFFGate FIX Interface Specifications M3.0 MEFF 27 September 2010 6 HF MEFFGate FIX Interface Specifications M2.0 MEFF 30 Julio 2010 7 MEFFGate Trading FIX Interface Specifications T1.1 MEFF 10 January 2012 8 MEFFGate Trading FIX Interface Specifications T1.0 MEFF 24 September 2009 9 MEFFGate Clearing FIX Interface Specifications C1.3 MEFF 27 September 2010 10 MEFFGate Clearing FIX Interface Specifications C1.2 MEFF 24 September 2009 11 MEFFGate Clearing FIX Interface Specifications C1.1 MEFF 24 September 2009 30 July 2012 MEFF 2012 4

2. Implementation decisions 2. Implementation decisions 2.1 Description This chapter presents the implementation decisions made by MEFF. Those aspects that the standard leaves open and have been defined in this implementation are detailed here. 2.2 Fields ignored In some cases, the content of certain fields of the entering messages may be ignored by MEFFGate. When this is the case, it is clearly stated in the field description. 2.3 Unsupported fields The unsupported fields of a message are not included in its description. Messages sent to MEFFGate should not contain unsupported fields. Messages sent by MEFFGate never contain unsupported fields. No required fields have been declared unsupported. 2.4 Length of String type The FIX standard does not place any restriction on the maximum length of the String type. In this implementation the maximum length is 255 characters. In some fields, a shorter maximum length has been established. In these cases, the type is presented as String(n), where n is the maximum number of characters of the field. In certain cases n indicates the exact length of the field, in which case it will be explicitly stated in the valid values column. 2.5 Maximum length of message The maximum length of the messages sent or received by MEFFGate is 4096 bytes. 2.6 Encryption MEFFGate does not use the encryption defined in the FIX standard (using the SecureData and SecureDataLen fields in the message header). The encryption is implemented through the use of SSL (Secure Socket Layer). 2.7 Identification of the MEFFGate FIX protocol MEFFGate implements an additional function that allows both parties to agree on the MEFFGate FIX version that they are going to use. It is important to distinguish between the version of the FIX protocol (in this case 4.4 ) and the version of the MEFFGate FIX protocol ( T1.2 in this edition). More than one version of the MEFFGate FIX protocol may exist for the same version of FIX. Similarly, one version of the MEFFGate FIX protocol may work with more than one version of the FIX protocol. The MEFFGate FIX protocol version used as default by MEFFGate is determined in the MEFFGate user configuration. The client program may also indicates which MEFFGate FIX protocol version it is going to use in the ProprietaryFixProtocolVersion of the Logon message. This field has been added by MEFF and has been implemented as an optional field. If the version requested by the client program is not available in the MEFFGate server in use, it will return a Logout Message with the corresponding explanatory message. 30 July 2012 MEFF 2012 5

3. FIX Session 3. FIX Session 3.1 Introduction The level of the FIX session guarantees the complete delivery of messages between both parties, without errors. MEFFGate implements the majority of the functions of the session level defined in the FIX 4.4 standard 3.2 FIX session and communication session As explained in the standard, there are two types of session: Communication session. This begins when a request to start a session (Logon message) is accepted. It ends when the communication is completed, preferably with the exchange of Logout messages FIX session. This is a combination of two-way messages identified by a sequence of consecutive numbers. A FIX session begins when the sequence numbers of both parties are restarted with the value 1. There is no explicit way of ending a FIX session; a session ends when a new one begins. A FIX session can encompass more than one communication session In addition to the two mentioned types of sessions, the Market session should also be considered. A Market session begins each day when the MEFFGate server loads the market data again and accepts connections for said session, following the procedure defined by MEFF. The client program must begin a new FIX session in the first connection of the Market session. Given that MEFFGate does not provide 24-hour support for the service, the ResetSeqNumFlag field is not required in the Logon message. 3.3 Identification of the FIX session Once a communication session has been established, MEFFGate identifies the associated FIX session using four fields in the Logon message sent by the initiator: SenderCompID SenderSubID TargetCompID TargetSubID SenderCompID identifies the member and SenderSubID identifies the trader. TargetCompID together with TargetSubID identify the market. No more than one FIX session can exist at a time with the same values for these four fields. The SenderCompID, SenderSubID, TargetCompID and TargetSubID fields are present in all the FIX messages. All the messages belonging to the same FIX session must have the same values in these fields. If a message is received with values that do not correspond with those of the session, it will be rejected with a Reject message. It should be noted that the values of these fields are inverted when the message is sent by MEFFGate, with respect to those sent by the client. Suppose that trader 001 of member A001 has a session established with the Financial Contract Group at MEFF. The messages will be those shown below: 30 July 2012 MEFF 2012 6

3. FIX Session Client message to MEFFGate: MEFFGate message to client: o SenderCompID = A001 o SenderCompID = MEFF o SenderSubID = 001 o SenderSubID = M3 o TargetCompID = MEFF o TargetCompID = A001 o TargetSubID = M3 * o TargetSubID = 001 3.4 Client software and FIX sessions A MEFFGate client is a software development that connects to MEFF through a MEFFGate server. As noted in 3.3, a FIX session is limited to one trader and one platform. A client will be able to establish various FIX sessions simultaneously to access more than one platform or trade in one market with various trader codes. A MEFFGate server can provide service to various sessions simultaneously, be they of the same client or various clients. When a FIX client tries to connect with a platform that is not available, his Logon message is answered with a Logout message with the appropriate explanation. 3.5 Message routing from different users through an unique FIX session (multilogon connection) MEFFGate allows to establish, through an unique FIX session, a message routing from different users who have the appropiate privileges. This is a multilogon connection. For this purpose, the following tags from the Standard Message Header are used in application messages: OnBehalfOfCompID [115], OnBehalfOfSubID [116], DeliverToCompID [128] and DeliverToSubID [129]. It should be noted that the tags OnBehalfOfCompID [115] and OnBehalfOfSubID [116] are used when the client application sends application messages to MEFFGate. Tags DeliverToCompID [128] and DeliverToSubID [129] are used when MEFFGate sends application messages to the client application. Application message to MEFFGate: Application message to client: o OnBehalfOfCompID = B001 o DeliverToCompID = B001 o OnBehalfOfSubID = 351 o DeliverToSubID = 351 3.6 Synchronisation of the FIX session On initiating a communication session (sending Logon message), the client can opt to initiate a new FIX session or continue with a previous session from the same market session. The procedure to follow in each case is described below. * See table 17 in document Codification Tables for a list of available markets 30 July 2012 MEFF 2012 7

3. FIX Session Start a new FIX session. To start a new FIX session the value to be used in the MsgSeqNum field of the Logon message must be 1. Continuation with previous FIX session. To continue a previous FIX session the value to be used in the MsgSeqNum field is the consecutive number to the one used in the last message of the session to be continued. Note that on starting a new FIX session, it will replace the previous session and therefore it cannot be continued later. A client application can only continue a FIX session if it connects to the same MEFFGate server with which the FIX session had been initiated. In the case that it has to connect to a different MEFFGate server a new FIX session will have to be started. When a Logon message has a MsgSeqNum other than 1, the number sent might not coincide with the number that MEFFGate was expecting for this session (MEFFGate expects the consecutive number after the number of the last message received for that session). The different situations that can arise with respect to the sequence number of the Logon message and the message expected by MEFFGate are shown below. MsgSeqNum is the same as the number expected by MEFFGate. There is no discrepancy and MEFFGate accepts the connection. MsgSeqNum lower than the number expected by MEFFGate. MEFFGate rejects the connection by sending a Logout message with the sequence number 1. In this case the connection cannot be accepted as the sequence number used in the Logon message was previously used by another message in the same session. MsgSeqNum higher than the number expected by MEFFGate. MEFFGate accepts the connection, and requests that the missing messages between the sequence number expected and the number used by the client be sent. The request to send these messages will be made using one of the following mechanisms: o o Logon message with NextExpectedMsgSeqNum. This method will be used whenever the client has used the NextExpectedMsgSeqNum field in his Logon message Resend Request message. In the event that the client has not used the NextExpectedMsgSeqNum field (Logon message), the server will not use it. In this case the server, after the Logon message reply, will notify the client of the sequence error using the Resend Request message When continuing with a FIX session it is advisable to use the NextExpectedMsgSeqNum field (Logon message), indicating the message number expected to facilitate the synchronisation between both parties. In this way, the server can detect if the client did not receive some of the messages, and proceed to resend them. When this value is not specified, the server continues sending messages from the last number in the sequence sent. MEFFGate uses the NextExpectedMsgSeqNum field in the reply to the Logon message if the client used it in his start message. MEFFGate only uses the Resend Request message as described above, that is, immediately after a Logon request. Any other time when there is a discrepancy between the expected sequence number and the number received, MEFFGate assumes that there is a serious problem and closes the connection with a Logout message. When MEFFGate requests a lower sequence number from the client than the one that the client proposes, the client can decide whether to repeat the same messages that he sent with the sequence numbers that are missing, send one or more GapFills, or simply give them a new use. In any case the client must take into account that the messages will be processed by MEFFGate in the moment that it is received like any other message. It is recommended to set up controls to prevent orders being sent that could have become obsolete whilst the disconnection lasted. 30 July 2012 MEFF 2012 8

3. FIX Session Like in MEFFGate, the client can only use the Resend Request message in case of detecting that the Logon message sent by the server is out of the sequence and does not contain the NextExpectedMsgSeqNum field. If MEFFGate receives a Resend Request message at any other moment it will be considered as an error and the connection will end. Independent of whether it was requested through the Resend Request message or using the NextExpectedMsgSeqNum field of the Logon message, the repetition of messages by the server is limited to messages belonging to the Market Session underway. The server repeats all the messages requested, except those providing public information and also those not corresponding to the current situation of each quote. Given the volume of public information and the quote history that may exist, it cannot be repeated and will be replaced by a Gapfill messages. The client must use query functionalities available to get up to date on this information. See section 3.6 for more information on this matter. A) The FIX session continues without request for repetition of messages 1 1 2 2 3 4 3 5 6 7 8 4 5 n m m + 1 m + 2 n + 1 m + 3 m + 4 n + 2 n + 3 m + 5 m + 6 m + 7 n + 4 n + 5 n+1 Logon NextExpectedMsgSeqNum=m+1 B) The FIX session continues with messages request 1 1 2 2 3 4 3 5 6 7 8 4 5 n m - 50 m - 2 m - 1 m n + 1 m - 49 m - 48 m - 17 m - 16 m - 50 m - 2 m - 1 m m + 1 n + 2 m + 2 m + 3 m + 4 n + 3 Message of server to client Message of client to server Menssage SequenceReset-GapFill sent from server to the client to skip the public messages (unrepeatable) n+1 Logon NextExpectedMsgSeqNum=m-50 - Scenarios for start or continuation of a FIX session - When a start of a communications session is rejected, the server answers with a Logout message. The client application should have into account that this Logout message may came with a sequence number 1 or with the sequence number corresponding to its late communication. The sequence number used by the client in its Logon message is not considered by MEFFGate and therefore does not alter the expected sequence number in subsequent communications. 30 July 2012 MEFF 2012 9

3. FIX Session 3.7 Synchronisation at application level When a client starts a communication session (Logon message accepted), it receives a series of information related with the current Market session. The information to be received depends on whether it is the start of a new session or the reconnection to an existing FIX session: Start of a FIX session. The client receives all the private messages, not associated to subscriptions, corresponding to the entire Market session. All or part of these messages may have been previously received in a previous FIX session. Reconnection to an existing FIX session. The client receives all the private messages, not associated to subscriptions, corresponding to the current Market session, not received previously. In this case MEFFGate ensures that there is no duplication of messages (except when it is explicitly requested). The messages that come from an explicit request for repetition (requested using a Resend Request message or a Logon message with NextExpectedMsgSeqNum lower than the last message received) will contain the value Y in the PossDupFlag field indicating this situation. This does not apply when it is a new FIX session (start of the session with sequence number 1). In both cases, both the private information associated with subscriptions and the public information can be requested using the messages that implement the corresponding functionalities. It should be taken into account that any subscription to information is cancelled when the communication session ends. If this service is required when reconnecting to a FIX session, it must be requested again. The series of private messages not associated to subscriptions referred to in this section correspond to the following messages: Execution Report with the ExecType values of New ( 0 ), Replace ( 5 ), Cancelled ( 4 ), Trade ( F ) and Trade Cancel ( H ) Execution Report with the ExecType value of Rejected ( 8 ) related to a cross trade that has been rejected by the MEFF central systems News Quote Status Report corresponding to the current situation of each quote 3.8 High availability To improve the availability of access to MEFF there will be various instances of the MEFFGate server executing in different computers. All the instances of MEFFGate will be connected with the central systems of MEFF. Therefore, they will have all the necessary information. When a MEFFGate server fails, the client can continue working with another MEFFGate. In this case, the client must start a new FIX session (beginning with the sequence number 1), as the status of the sessions is not replicated between different MEFFGate servers. The client must carry out the necessary processes to synchronise at the application level (see 3.6). 30 July 2012 MEFF 2012 10

3. FIX Session When a client application that has established a FIX session fails, the client application can restart in another computer that continues with the same session (using the same MEFFGate server). In this case, the client is responsible for restoring the status of the failed application. If it is not possible to restore this status, it is recommended that a new FIX session be started, although it is possible to maintain the current session and consult all the necessary data at the application level to restore the status. 3.9 PossResend field The implementation of FIX in MEFF does not allow the use of the PossResend field (see 2.3 for more information on unsupported fields). 3.10 Reception of information for all traders of the member Members can request the configuration of privileged traders that will receive the order related messages sent to all the traders of the member. The messages affected by this mechanism are the Execution Report which contains the following values in the ExecType field: New ( 0 ), Cancelled ( 4 ), Replace ( 5 ), Trade ( F ), Trade Cancel ( H ) and the Quote Status Report. The messages sent by MEFFGate to this trader contain the same information as the original messages, except for the TargetCompID and TargetCompSubID fields. When necessary, the information contained in the Parties block allows identification of the target trader in the original message. 3.11 Reception of information on actions taken on behalf of the trader MEFF s technological platform enables actions to be taken on behalf of a trader. This can be done, for instance, from a MEFFStation Multi-Trader of the member or by the MEFF traders pool. In these cases, the FIX client on whose behalf the action has been made, receives the messages corresponding to said operative. Accordingly, client applications must be prepared to receive messages originated by actions of third parties in their name. Note that in this case, the number of messages received by the client application can be less than it would have received if it had sent the equivalent message. The messages that are not received are those generated directly from MEFFGate to notify the reception of the message and sending the same message to the central systems. When necessary, the information contained in the Parties block (see 4.3) allows the member and trader who undertook the action to be identified. 3.12 Administrative messages that the FIX client must manage The FIX client must be able to manage all the administrative messages as described in this chapter, including the Resend Request message. The client can decide whether to respond to this by resending messages or simply sending a GapFill (Sequence Reset message). 3.13 List of messages The functionality at the session level is implemented in FIX 4.4 using seven administrative messages. All these are fully supported by the MEFFGate FIX protocol. 30 July 2012 MEFF 2012 11

3. FIX Session Message Logon (Msg Type = A) Logout (Msg Type = 5) Heartbeat (Msg Type = 0) Test Request (Msg Type = 1) Resend Request (Msg Type = 2) Sequence Reset (Msg Type = 4) Reject (Msg Type = 3) Description Request or confirmation of the start of a communication session Request or confirmation of the end of a communication session Periodic notification that the connection continues to be live Request to send a Heartbeat message to confirm that the connection is alive Request to resend messages that have not been received Fill a gap in messages re-establishing a higher sequence number Reject a message at session level 3.14 Message flow Start of communication session and start of FIX session A request to start a communication session (Logon message) that is accepted is replied to by the receiver with another Logon message. The initiator must not send another message until it has received this confirmation of acceptance. MEFFGate Client MEFFGate Server Logon ( A ) MsgSeqNum [34] = 1 Logon ( A ) MsgSeqNum [34] = 1 30 July 2012 MEFF 2012 12

3. FIX Session Start of communication session and continuation of FIX session A request to start a communication session (Logon message) that is accepted is replied to by the receiver with another Logon message. The initiator must not send another message until it has received this confirmation of acceptance. MEFFGate Client MEFFGate Server Logon ( A ) MsgSeqNum [34] = m NextExpectedMsgSeqNum [789] = n Logon ( A ) MsgSeqNum [34] = n NextExpectedMsgSeqNum [789] = m+1 Start of communication session rejected When the start of a communication session (Logon message) is not accepted, MEFFGate will reply with a Logout message. For more details on the behaviour of sequence numbers of both parties see section 3.6. MEFFGate Client MEFFGate Server Logon ( A ) Logout ( 5 ) End of a communication session started by the sender The client can end the communication session by sending a Logout message at any time. MEFFGate Client MEFFGate Server Logout ( 5 ) Logout ( 5 ) 30 July 2012 MEFF 2012 13

3. FIX Session End of a communication session started by the receiver In exceptional circumstances, the server can end the communication session with a Logout message. MEFFGate Client MEFFGate Server Logout ( 5 ) Logout ( 5 ) Sending messages with identification fields of session (SenderCompID, SenderSubID, TargetCompID and TargetSubID) with different values from those associated to the current FIX session All the messages associated to a FIX session must include the same identifying values of the session (SenderCompID, SenderSubID, TargetCompID and TargetSubID). If a message differs from the values indicated in the Logon of the session, it is rejected with a Reject message. MEFFGate Client MEFFGate Server Any message with wrong ID Reject ( 3 ) SessionRejectReason [373] = 9 (CompID problem) 3.15 Annotations and adaptations of FIX 4.4 The optional field ProprietaryFixProtocolVersion has been added to the Logon message to identify the version of the MEFF protocol The optional field FixEngineName has been added to the Logon message. It contains a descriptive text of the software application When a request to start a session (Logon message) is rejected, the receiver (MEFF) will always send a Logout message in reply The SenderSubID [50] and TargetSubID [57] fields in the header of messages (Standard Message Header) are now required The PossResend field is not supported The FIX method of encryption is not supported MEFFGate only accepts the Resend Request message after the Logon message The valid values of the ResetSeqNumFlag field in the Logon message are limited to the value N 30 July 2012 MEFF 2012 14

3. FIX Session 3.16 Definition of messages 3.16.1 Standard Message Header Header is present in all FIX messages. Tag Name Req Valid values Format Description 8 BeginString Y FIX.4.4 String Indicates the start of a new message. Contains the version of the FIX protocol. It is always the first field of the message 9 BodyLength Y Int Length of message in bytes, from the end of this field up to and including the delimiter before the Checksum field. It is always the second field of the message 35 MsgType Y All message types supported by MEFF String Identifies the type of message. It is always the third field of the message 49 SenderCompID Y String Identifier of the entity that sends the message. Contains MEFF when the message is sent by MEFFGate. It must contain the member code in the messages sent by the client application 56 TargetCompID Y String Identifier of the entity that the message is sent to. Must contain MEFF when the message is sent to MEFFGate. Contains the member code in the messages sent by MEFFGate 115 OnBehalfOfCompID N String Used by client when sending messages via a third party who has the appropriate privileges 128 DeliverToCompID N String Used by MEFFGate when receiving messages via a third party who has the appropriate privileges 34 MsgSeqNum Y SeqNum Sequence number of the message within the current FIX session 50 SenderSubID Y* See table 17 in document Codification Tables for details of the Market codes 57 TargetSubID Y* See table 17 in document Codification Tables for details of the Market codes String String The messages sent from MEFFGate to the client contain the code assigned to the platform with which the connection was established. Messages sent to MEFFGate must contain the trader code with which the FIX session was started The messages sent from MEFFGate contain the code of the trader which it is to be sent to. Messages sent to MEFFGate must contain the code of the platform with which the connection was established 116 OnBehalfOfSubID N String Used by client when sending messages via a third party who has the appropriate privileges 129 DeliverToSubID N String Used by MEFFGate when receiving messages via a third party who has the appropriate privileges 43 PossDupFlag N N = Original message sent (default value) Y = Duplicate Boolean Indicates if it is the first time within a FIX session that a message is sent ( N ) or if the same message is being sent again ( Y ), either due to 30 July 2012 MEFF 2012 15

3. FIX Session possible 52 SendingTime Y UTC Timestamp 122 OrigSendingTime N UTC Timestamp an explicit request from the other party or due to uncertainty about the reception of the original message Time message sent Time when original message was sent. Required in a resend. A message is considered to be a resend if the field PossDupFlag = Y and the field MsgType is not 4 (Sequence Reset) 30 July 2012 MEFF 2012 16

3. FIX Session 3.16.2 Standard Message Trailer Present in all FIX messages. Tag Name Req Valid values Format Description 10 CheckSum Y String(3) Checksum of the message, calculated in accordance with the standard. It is always the last field of the message and its length is exactly 3 bytes 30 July 2012 MEFF 2012 17

3. FIX Session 3.16.3 Logon (Msg Type = A) The Logon message is used to start a session by the client application and to accept it by the MEFFGate. Tag Name Req Valid values Format Description Standard Header Y MsgType = A 98 EncryptMethod Y 0 = None Int Ignored by MEFFGate 108 HeartBtInt Y >= 5 Int Interval at which messages are sent to verify the connection (Heartbeat message) expressed in seconds. 141 ResetSeqNumFlag N N Boolean Only allows the value N, as it is not required in the implementation of the protocol 789 NextExpectedMsgSe qnum N SeqNum Indicates the next sequence number (MsgSeqNum) that it expects to receive 464 TestMessageIndicato r N Y = Test N = Production Boolean Indicates whether it is a test or production session. The client can use it optionally to indicate if he wants to connect to the production or test environment. The start of a session is accepted only if this environment is valid for the MEFFGate If the client does not indicate anything, this parameter is not taken into account. In any event MEFFGate always informs this field 553 Username N String Identifier of the user assigned by MEFF. Required when the message is sent by the client application. It is currently comprised of the combination of the member code and the trader code assigned by MEFF 554 Password N String User Password. Required when the message is sent by the client application 5680* ProprietaryFixProtoco lversion N T1.2 String Exact identification of the version of the protocol used and expected by the client application. MEFFGate always accomplish this field independently if the client application informed it or not. 5679* FixEngineName N String Optional field, where the client can include a descriptive string of the software name used by the FIX connection. Only used for informative purposes. MEFFGate never sends this field Standard Trailer Y 30 July 2012 MEFF 2012 18

3. FIX Session 3.16.4 Logout (Msg Type = 5) The Logout message is used by both parties to request the end of a communication session and to accept said request. Tag Name Req Valid values Format Description Standard Header Y MsgType = 5 58 Text N String Explanatory text Standard Trailer Y 30 July 2012 MEFF 2012 19

3. FIX Session 3.16.5 Heartbeat (Msg Type = 0) The Heartbeat message is used by both parties to indicate that the connection is active. Tag Name Req Valid values Format Description Standard Header Y MsgType = 0 112 TestReqID N String If the message is the reply to a Test Request message, it must contain the same value as the original TestReqID field. Otherwise, this field should be omitted. Standard Trailer Y 30 July 2012 MEFF 2012 20

3. FIX Session 3.16.6 Test Request (Msg Type = 1) The Test Request message is used by both parties to request that a Heartbeat message be sent. Tag Name Req Valid values Format Description Standard Header Y MsgType = 1 112 TestReqID Y String Identifier of the request. It must be included in the Heartbeat message reply Standard Trailer Y 30 July 2012 MEFF 2012 21

3. FIX Session 3.16.7 Resend Request (Msg Type = 2) The Resend Request message can be used by both parties to request the resending of messages that have not been received. MEFFGate only makes use of this functionality after a Logon message. In any other case the reception of a message out of sequence is considered a serious error and the connection is terminated. MEFFGate will only accept this type of message immediately after receiving a Logon message in which the NextExpectedMsgSeqNum field has not been specified. Tag Name Req Valid values Format Description Standard Header Y MsgType = 2 7 BeginSeqNo Y Valid sequence number Int Sequence number of the first message in the range of messages requested to be resent. Its value must be less than the last sequence number received 16 EndSeqNo Y 0 = Infinite Valid sequence Number Standard Trailer Y Int Sequence number of the last message of the range of messages requested to be resent. Its value must be lower than the last sequence number received. If the request is only for one message, then EndSeqNo = BeginSeqNo If the request is for all the messages starting from a given one, then EndSeqNo = 0 30 July 2012 MEFF 2012 22

3. FIX Session 3.16.8 Sequence Reset (Msg Type = 4) The Sequence Reset message is used by both parties to fill a gap in the messages that are being sent, by reassigning the sequence number (see 3.6). The FIX standard allows other uses of this message that are not supported by MEFF (note that the GapFillFlag field is required and must always contain the value Y ). Tag Name Req Valid values Format Description Standard Header Y MsgType = 4 Note that the PossDupFlag must contain the value Y 123 GapFillFlag Y* Y = Indicates that the message is to fill a gap Boolean More information is available in the FIX 4.4 specifications documentation 36 NewSeqNo Y Int Sequence number of the message that will now be sent Standard Trailer Y 30 July 2012 MEFF 2012 23

3. FIX Session 3.16.9 Reject (Msg Type = 3) The Reject message is used by MEFFGate to reject a message that does not comply with the FIX protocol specified by MEFF. Tag Name Req Valid values Format Description Standard Header Y MsgType = 3 45 RefSeqNum Y SeqNum Sequence number of the rejected message 373 SessionRejectRe ason N 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 6 Incorrect data format for value 9 CompID 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 Int Code indicating the rejection motive 58 Text N String Contains a more detailed explanation of the reason for the rejection Standard Trailer Y 30 July 2012 MEFF 2012 24

4. General conventions in application messages 4. General conventions in application messages 4.1 Order identification 4.1.1 ClOrdID Any message related to an order (entry, cancellation, modification) sent by the client, must have a unique identifier in the ClOrdID field. As the standard indicates, the uniqueness of these identifiers must be maintained during the trading session. Once the message is accepted by MEFFGate, the client receives the corresponding confirmation message with the same ClOrdID code preceded by a prefix. It becomes the identifier of the order from this moment on. The client can now identify the order using either of the two ClOrdID values. MEFF implements this mechanism to ensure the unique identification of orders, independently of their issuer. The only exception to the above occurs in the case of order cancellation en masse, where all the orders cancelled by this procedure are identified by the same ClOrdID. More information on this is provided in section 0. The ClOrdID field assigned by the client must be 10 characters long or less. MEFFGate also accepts that messages sent by the client use a CIOrdID with a length of 30 characters, but in this case only the last 10 positions can be fixed freely, as the first 20 must coincide with the format that is shown below. The ClOrdID assigned by the client is in the format YYMMDDMmmmTttOoooSssNnnnnnnnnn, where the coding is defined as follows: YYMMDD. The date of the trading session MmmmTtt. Contains the member and trader codes of the SenderCompID and SenderSubID fields from the heading of the original message OoooSss. Contains the member and trader codes that are indicated in the Parties block as Originating Firm and Originating Trader (see 4.3) Nnnnnnnnnn. The value assigned by the client to the ClOrdID in the original message 4.1.2 OrderID The OrderID field is the order identifier, unique for member and trader, assigned by the MEFFGate server. This identifier is maintained associated with the order, even even after order modification. This field may be necessary to identify the order in communications with the Market by other means. 4.1.3 SecondaryOrderID The SecondaryOrderID field is an order identifier assigned by the central trading system. The period in which the uniqueness of this field is guaranteed is determined by each central trading host. 4.1.4 SecondaryExecID The field SecondaryExecID [527] informs the number of reported history of the order. Each time the status or the order is changed in the order book of the central system (modification, cancellation, trade) a new value is asigned to this field. In the MEFF trading system, any state of a specific order can be identified by the combination of the fields SecondaryOrderID [198] + SecondaryExecID [527] 30 July 2012 MEFF 2012 25

4. General conventions in application messages 4.2 Trade identification 4.2.1 ExecID The ExecID field is not an identifier of trades. It is an identifier assigned to each Execution Report message, without duplicates during the entire FIX session. 4.2.2 TrdMatchID The TrdMatchID field has the trade register number. This is the code assigned by the central trading system to the trade or the cross trade referred to in the message. The period in which the uniqueness of this field is guaranteed is determined by each central trading host. 4.3 Parties block The Parties block (or the NestedParties block) is used in many application messages to specify the parties involved in the transaction. In the detailed definition of the messages that this block contains, the block is incorporated exactly as shown below. The list of possible values is restricted by the specific characteristics of the message. Tag Name Req Valid values Format Description Start <Parties> 453 NoPartyIDs N NumInGroup PartyID N String Member or trader code assigned 448 447 452 PartyIDSource N D = Proprietary/ Custom code Char by MEFF Indicates the codification used in the PartyID field. MEFF s own codification is always used PartyRole N Int Indicates the role taken by the party indicated in the PartyID field End <Parties> 30 July 2012 MEFF 2012 26

4. General conventions in application messages Various roles are used in the messages contained in this manual. The interpretation of the PartyID field depends on the value of the PartyRole, as explained below: 1 (Executing Firm). o o Send. This value cannot be specified when sending messages. Receive. When this value is specified, the PartyID field corresponds with the member code for the trader that sent the original message (acting in his own name or on behalf of another trader). 3 ( Give-out internal reference) When this value is specified, the PartyID field corresponds to the reference assigned by the Executing Broker for internal purposes. It is associated to a Give-out mnemonic and it can be not unique. Need not be provided. 7 (Entering Firm) o o Send. When this value is specified, the PartyID field corresponds to the code of the member that acts as broker or intermediary in a cross trade. The use of this value is only allowed in the Trade Capture Report message. It only allows the member s own code to be specified. Receive. When this value is specified, the PartyID field corresponds to the code of the member that acts as broker or intermediary in a cross trade. MEFFGate does not use this field when the value is the code of the receiving member. 11 (Order Origination Trader). o o Send. In general it is not necessary to use this field when sending messages. When this value is specified, the PartyID field corresponds with the code of the trader on whose behalf it is acting. Only the code of the trader itself can be specified. The exception is the Trade Capture Report message, used to enter cross trades, where the trader associated to the legs of the cross trade can be indicated. Receive. When this value is specified, the PartyID field corresponds with the trader code related with the associated order. MEFFGate omits this field when the value is the trader code of the receiver. 12 (Executing Trader) o o Send. This value cannot be specified when sending messages. Receive. When this value is specified, the PartyID field corresponds with the code of the trader that sent the original message (acting in his own name or on behalf of another trader). 13 (Order Origination Firm). o o Send. In general it is not necessary to use this field when sending messages. When this value is specified, the PartyID field corresponds with the code of the trading member on whose behalf it is acting. Only the code of the member itself can be specified. The exception is the Trade Capture Report message, used to enter cross trades, where the member that the account belongs to can be indicated. Receive. When this value is specified, the PartyID field corresponds with the member code of the trading being handled. 30 July 2012 MEFF 2012 27

4. General conventions in application messages 14 (Give-up Clearing Firm) When this value is specified, the PartyID field corresponds to the Give-up Clearing Broker. 24 ( Give-up Reference) When this value is specified, the PartyID field corresponds to the Give-up reference. 33 ( Give-up mnemonic) When this value is specified, the PartyID field corresponds to the Give-out mnemonic. 36 (Entering Trader). o o Send. When this value is specified, the PartyID field corresponds with the code of the trader that acts as broker or intermediary in a cross trade. The use of this value is only allowed in the Trade Capture Report message. Only allows the trader s own code to be specified. Receive. When this value is specified, the PartyID field corresponds to the code of the member that acts as broker or intermediary in a cross trade. MEFFGate does not use this field when the value is the trader code of the receiver. The following flow diagram provides an example of the use of party blocks in an intervention made by the MEFF pool on an order by trader 301 of member AAAA. In this example trader 305 is considered to be configured as a privileged trader and therefore will also receive the information on the trade of trader 301 (see 3.10 for more information on privileged traders). Prvileged trader Member=AAAA Trader=305 Trader Member=AAAA Trader=301 MEFF Pool Member=PPPP Trader=001 MEFF side New order entered on behalf of trader 301 of member AAAA Execution Report - New (Executing Firm = PPPP ; Executing Trader = 001) Execution Report - New (Executing Firm = PPPP ; Executing Trader = 001; Order Origination Trader = 301) 30 July 2012 MEFF 2012 28

4. General conventions in application messages The next flow diagram provides an example of the use of party blocks in the entry of a cross trade by the MEFF Market Surveillance. In the example, expit trade trader 310 of member BBBB acts as intermediary and as one of the parties, whilst trader 301 of member AAAA acts as the other party. In this example trader 305 of member AAAA is configured as privileged trader and therefore also receives information on the trading activity of trader 301 of the same member (see 3.10 for more information on privileged traders). Prvileged trader Member=AAAA Trader=305 Trader Member=AAAA Trader=301 Intermediary Member=BBBB Trader=310 MEFF Pool Member=PPPP Trader=001 MEFF side Entry of cross trade in name of intermediary BBBB-310 with parties BBBB-310 and AAAA-301 Execution Report - New (Executing Firm = PPPP ; Executing Trader = 001) Execution Report - New (Executing Firm = PPPP ; Executing Trader = 001; Order Origination Firm = AAAA ; Order Origination Trader = 301) Execution Report - Trade (Executing Firm = PPPP ; Executing Trader = 001) Execution Report - Trade (Executing Firm = PPPP ; Executing Trader = 001; Order Origination Firm = AAAA ; Order Origination Trader = 301) Execution Report - Trade (Executing Firm = PPPP ; Executing Trader = 001; Entering Firm = BBBB ; Entering Trader = 310) Execution Report - Trade (Executing Firm = PPPP ; Executing Trader = 001; Entering Firm = BBBB ; Entering Trader = 310 ; Order Origination Trader = 301) 4.4 Symbol and SecurityID Symbol and SecurityID tags have different meanings depending on how the user associated to the FIX client has been configurated. These tags can be included in the Instrument, UnderlyingInstrument and InstrumentLeg blocks. The two possible configurations are: Type of Configuration Meaning of Symbol Meaning of SecurityID By contract Per asset MEFF Contract code Underlying asset (see Table 21 in Codification tables document) Underlying asset (see Table 21 in Codification tables document) MEFF Contract code All sections and messages described in this manual refer to type of configuration By contract. 30 July 2012 MEFF 2012 29

4. General conventions in application messages 4.5 Instrument block In some requests, the FIX client may specify selection criteria for the contracts. In these cases, they will only receive information on the contracts that meet these criteria. The possible selection criteria correspond to the fields of the Instrument block. The table below indicates which fields are accepted by MEFF and the type of request that can be made. Field Meaning Contract information request Price information request CFICode Coding of financial instruments according to ISO 10962 X X SecurityID MEFF Underlying asset X X MaturityMonthYear Contract expiration X X Symbol MEFF Contract code - X The use of these fields is explained in detail in the following sub-sections. 4.5.1 CFICode The CFICode field is the least selective criteria. It identifies the type of contract, such as all the futures or all the options. The values allowed for the CFICode are based on ISO 10962. The character X is used as a wildcard. Some examples for the CFICode as selection criteria are shown in the following table. Note that the values must have exactly 6 characters. CFICode XXXXXX FFXXSX FFSPSX FFSCSX OXXXXS OCXXXS OPXXXS XMXXXX Meaning All contracts supported by MEFF All futures All futures with physical delivery All futures with cash delivery All options All call options All put options All time-spread contracts (MultiLeg) See table 16 in document Codification Tables for a list of values. For further information about the Security List message refer to chapter 6 Market Information. 4.5.2 Underlying asset (SecurityID field) This code identifies the underlying asset of a contract (see table 21 in document Codification Tables ). 30 July 2012 MEFF 2012 30

4. General conventions in application messages 4.5.3 Expiration (MaturityMonthYear field) For contracts with standard maturities, indicates the month and year when the contract expires. In this case, the format for this field is YYYYMM (e.g. 200812) For contracts with non-standard maturities, indicates the date when the contract expires. In this case, the format for this field is YYYYMMDD (e.g. 20081219) For contracts with week standard maturities, the format for this field is YYYYMMwW (e.g. 200312w3). 4.5.4 Contract code (Symbol field) or using the combination SecurityID + CFICode + MaturityDate + ContractMultiplier + StrikePrice This is the most selective of the criteria, as it refers to a specific contract. MEFFGate allows a code 22 characters long. If you want to use the other selection criteria and do not want to specify a particular contract, complete this field with the value [N/A], as indicated in the FIX standard specifications. To identify a non-standard (flexible) contract that doesn t exist in the system, the following combination should be used in the cross trade functionality: SecurityID [48] + CFICode[461] + MaturityDate [541] + ContractMultiplier [231] + StrikePrice [202], with Symbol [55] = [N/A]. In this case, where appropiate, MEFFGate FIX will assign a new code following the existing rules and will populate these fields in all the messages associated (Trade Capture Report and Trade Capture Report Ack). For all other situations the contract is identified as usual, using the tag Symbol [55]. 4.5.5 Combination of selection criteria When various selection criteria are combined, only those contracts that meet all the requirements are selected. When a selection criteria is not specified it is understood that this criteria is to be ignored and no contract will be discarded for this reason. The following table shows some examples for the Financial Contract Group at MEFF. CFICode SecurityID MaturityMonthYear Symbol Meaning FFXXSX FIE (omitted) [N/A] All futures on IBEX index FFSPXX BBVA (omitted) [N/A] (omitted) FIE 200703 [N/A] All the BBVA futures contracts with physical delivery All the contracts with IBEX index as underlying, with March 2007 expiration OCXXXS (omitted) 200606 [N/A] All call options with June 2006 expiration XMXXXX TEF (omitted) [N/A] All time-spread contracts where Telefonica stocks is underlying of at least one leg (omitted) (omitted) (omitted) <specific contract> The contract specified (Omitted) (Omitted) (omitted) [N/A] All contracts 4.6 Error format (Text Field) The Text field is used in various messages to include the description of an error. In these cases the format of the field is: 30 July 2012 MEFF 2012 31

4. General conventions in application messages %MFsXXXXXX-Free text Where s indicates the importance of the error (I: information, W: warning, E: Error), XXXXXX is the error code, which is followed by an explanation. %MF text is always present. 4.7 Limitation on the maximum permitted number of subscriptions alive The maximum number of subscriptions alive of every type per connection is limited to 40. This limitation is related, for example, to the following messages: Security Status Request, Market Data Request, If, once reached that limit, the client application tries to establish new subscriptions (without unsubscribe from existing), they will be rejected with an error message indicating that the maximum permitted number of subscriptions has been reached. 30 July 2012 MEFF 2012 32

5. Common Application Messages 5. Common Application Messages 5.1 Introduction This chapter presents some common messages at the application level that cover three functions: the control of the communication status, the individual user password change and the rejection of messages by MEFFGate. 5.2 Network communication status MEFFGate includes a mechanism to inform the client application of the status of communication between MEFFGate itself and the central system. This functionality is achieved using the FIX Network Status messages. The request can be made on demand or by subscription. The information supplied with these messages only refers to the connection between the equipment and should not be confused with the status of the trading session, which is covered in 6.2. 5.3 Password change This functionality allows to change the individual user password used in the connection between the client application and MEFFGate. The new password is valid for all the next future communication sessions between the client application and MEFFGate. 5.4 Rejection of application messages When MEFFGate receives a supported message with correct syntax in an unsupported situation, but there is no specific rejection message, the Business Message Reject is used. In particular, this is used to reject the Network Counterparty System Status Request message. 5.5 List of messages Message Network Counterparty System Status Request (Msg Type = BC) Network Counterparty System Status Response (Msg Type = BD) User Request (Msg Type = BE) User Response (Msg Type = BF) Business Message Reject (MsgType = j) Description Request of connection status between MEFFGate and the central systems Report on status of connection between MEFFGate and the central systems Individual user password change request Reply to a User Request message Rejection of message at application level (used when there is no specific message) 30 July 2012 MEFF 2012 33

5. Common Application Messages 5.6 Message flow Check connection status on demand MEFFGate Client MEFFGate Server Network CounterParty System Status Request ( BC ) NetworkRequestType [935] = 1 (Snapshot) Network CounterParty System Status Response ( BD ) Subscription to connection status MEFFGate Client MEFFGate Server Network CounterParty System Status Request ( BC ) NetworkRequestType [935] = 2 (Subscribe) Network CounterParty System Status Response ( BD )... Individual password change MEFFGate Client MEFFGate Server User Request ( BE ) User Response ( BF ) 5.7 Annotations and adaptations of FIX 4.4 In the User Request message, the Password [554] and NewPassword [925] fields are now required. 30 July 2012 MEFF 2012 34

5. Common Application Messages 5.8 Definition of messages 5.8.1 Network Counterparty System Status Request (Msg Type = BC) Message sent by the client application to request information on the status of the connection between MEFFGate and the MEFF central systems. Tag Name Req Valid values Format Description Standard Header Y MsgType = BC 935 NetworkRequestType Y 1 = Snapshot 2 = Subscribe 4 = Stop subscribing Int 933 NetworkRequestID Y String(10) Message identifier Standard Trailer Y 30 July 2012 MEFF 2012 35

5. Common Application Messages 5.8.2 Network Counterparty System Status Response (Msg Type = BD) Message sent by MEFFGate as reply to a Network Counterparty System Status Request Message. It has information about the connectivity between MEFFGate and the MEFF central systems. Tag Name Req Valid values Format Description Standard Header Y MsgType = BD 937 NetworkStatusRespons Y 1 = Full Int etype 933 NetworkRequestID Y String Message identifier Network Counterparty System Status Request to which it is being responded 932 NetworkResponseID Y String Unique message identifier 936 NoCompIDs Y 1 NumInGr oup 930 RefCompID N MEFF String Contains the same value as the SenderCompID field in the header (see 3.3) This field is always included in the message 931 RefSubID N See table 17 in document Codification Tables for details of the Market codes String Contains the same value as the SenderSubID field in the header (see 3.3) This field is always included in the message 928 StatusValue N 1 = Connected 2 = Not connected down expected up 3 = Not connected down expected down Int Connection status This field is always included in the message 929 StatusText N String Additional information Standard Trailer Y 30 July 2012 MEFF 2012 36

5. Common Application Messages 5.8.3 User Request (Msg Type = BE) Message sent by the client to modify the password used in their connection to the MEFFGate Tag Name Req Valid values Format Description Standard Header Y MsgType = BE 923 UserRequestID Y String (10) Unique identifier for each User Request message 924 UserRequestType Y 3 = Change Int Password For User 553 Username Y String Identifier of the user assigned by MEFF. It is currently comprised of the combination of the member code and the user code assigned by MEFF 554 Password Y* String (10) Old Password 925 NewPassword Y* String (10) New Password Standard Trailer Y 30 July 2012 MEFF 2012 37

5. Common Application Messages 5.8.4 User Response (Msg Type = BF) Message sent by MEFFGate to notify the status of the request initiated with the User Request message. This message is only sent to the user who made the request. Tag Name Req Valid values Format Description Standard Header Y MsgType = BF 923 UserRequestID Y String Identifier assigned by the client in the User Request message 553 Username Y String User identifier 926 UserStatus N 5 = Password Changed 6 = Other Int Status of the User Request message If rejected (value 6), there is an explanation in the UserStatusText field 927 UserStatusText N String When UserStatus = 6 there is an explanation of the rejection Standard Trailer Y 30 July 2012 MEFF 2012 38

5. Common Application Messages 5.8.5 Business Message Reject (MsgType = j) Message sent by MEFFGate when it receives a supported message that is syntactically correct in an unsupported situation, and there is no specific rejection message. It is especially used to reject a Network Counterparty System Status Request message. Tag Name Req Valid values Format Description Standard Header Y MsgType = j 45 RefSeqNum Y SeqNum MsgSeqNum of the rejected message 372 RefMsgType Y. String MsgType of the rejected message 379 BusinessRejectRefID N String Optional Identifier of the rejected message 380 BusinessRejectReason Y 0 = Other 3 = Unsupported Message Type Int Reason for rejection 58 Text N String Explanation of rejection Standard Trailer Y 30 July 2012 MEFF 2012 39

6. Market Information 6. Market Information 6.1 Introduction Market information groups together various functionalities related to public market information, which are classified into three groups: Session status. Status of trading session Contract information. Definition and status of contracts selected Prices. Prices and indications of interest in selected contracts Each of these groups is covered in a separate section of this chapter. Section 6.5 provides details of the format of the corresponding messages. 30 July 2012 MEFF 2012 40

6. Market Information 6.2 Market information: Status of trading session 6.2.1 Description This functionality allows the client to obtain the status of the trading session for the market associated to the current FIX session and to be notified of the changes of status that occur. The client can request the current status, or request the current status and the changes in status that occur. It should be noted that there is no way of requesting updates without requesting the current status. This is essential to guarantee the completeness of information received. 6.2.2 List of messages Message Trading Session Status Request (Msg Type = g) Trading Session Status (Msg Type = h) Description Sent by the client to request the trading session status Sent by the server to return information on the session status or to notify that the request has been rejected 6.2.3 Message flow Session status request (without update) A session status request, without update, is answered by a single Trading Session Status message. MEFFGate Client MEFFGate Server Trading Session Status Request ( g ) SubscriptionRequestType [263] = 0 (Snapshot) Trading Session Status ( h ) Unsolicited Indicator [325] = N 30 July 2012 MEFF 2012 41

6. Market Information Session status request (with update) A session status request, with update, is answered with a Trading Session Status message with the current situation of the market and a new message each time there is a change in status. It should be noted that a request to end the subscription is only answered by MEFFGate when it is rejected. Trading Session Status Request ( g ) SubscriptionRequestType [263] = 1 (Subscribe) Trading Session Status ( h ) Unsolicited Indicator [325] = N Trading Session Status ( h )... Unsolicited Indicator [325] = Y Trading Session Status Request ( g ) SubscriptionRequestType [263] = 2 (Unsubscribe) Failed session status request A failed session status request is answered by a Trading Session Status message with the field TradeSesStatus = 6. MEFFGate Client MEFFGate Server Trading Session Status Request ( g ) Trading Session Status ( h ) TradeSesStatus [340] = 6 (Request Rejected) 6.2.4 Annotations and adaptations of FIX 4.4 No annotations or adaptations have been made to the messages in this section. 30 July 2012 MEFF 2012 42

6. Market Information 6.3 Market information: Contracts 6.3.1 Description This functionality allows contract information to be obtained. The information is organised in two groups: Contract definitions. Static information of the definition of the contracts Contract status. Dynamic information that shows the status of the contracts 6.3.2 Request contract information The request for the definition of contracts is made using the Security List Request and Security Status Request messages, as detailed in the following table: Contracts Snapshot Contracts Update Contracts Status Snapshot Security List Request SubscriptionRequestType = 0 X X Contracts Status Update Security List Request SubscriptionRequestType = 0 X X X NewSecuritySubscription = 1 Security List Request SubscriptionRequestType = 1 X X X Security List Request SubscriptionRequestType = 1 NewSecuritySubscription = 1 Security Status Request SubscriptionRequestType = 0 X X X X X Security Status Request SubscriptionRequestType = 1 X X The meaning of each column is explained below: Contracts - Snapshot. One or more Security List messages are obtained with the description of the contracts available that meet the selection criteria specified in the request Contracts - Update. One Security List message is obtained with information on a new contract when it is introduced into the system. Only information on new contracts that meet the selection criteria indicated in the request is received Contracts Status - Snapshot. A Security Status message is obtained with information on the status of each contract that meets the selection criteria indicated in the request Contracts Status Update. A Security Status message is obtained each time a change occurs in the status of a subgroup of contracts that meets the selection criteria indicated in the request. In addition, a Security Status message is received when a new contract is entered in the system that meets the selection criteria indicated in the request Note that the NewSecuritySubscription field has been added to the Security List Request message by MEFF to enable the subscription to the definition of contracts created during the session, usually new strikes for options and multi-leg contracts. 30 July 2012 MEFF 2012 43

6. Market Information MEFF recommends the use of the Security List Request message with NewSecuritySubscription = 1 and SubscriptionRequestType = 1 so that the client application will have the maximum information. In this way information is obtained on all the changes that occur, including the entry of new contracts. 6.3.3 Reception of contract definitions The information on the contract definitions is received in the Security List message. This message gives one contract per message. The TotNoRelatedSym field gives the total number of contracts that meet the selection criteria and the NoRelatedSym field gives the number of contracts contained in that particular message. When the current status plus updates is requested, first all the messages associated to the current status are sent and then the updates. This avoids confusion when following the list. It should be noted that the update messages only contain one contract per message. 6.3.4 Reception of contract status The information of the contract status is received in the Security Status message. Each Security Status message can contain information for a subgroup of contracts or a single one. The reply to a Security Status Request message may consist of several Security Status messages. In this case, there is no mechanism to know when all the information has been received. If necessary, the FIX client will have to first request the list of contracts using the Security List Request message to work out how many contracts meet certain criteria. If updates for this information have been requested, a new Security Status message is received when there is a change in the contract status with the new information. When a new contract is entered in the market that meets the selection criteria specified in the request, and the request is for updates, a Security Status message is received with the contract status, whether or not you have subscribed to the definition for this contract. In this case, client applications should be prepared to receive information on the status of those contracts for which no definition has been received. It is recommended not to subscribe to updates for the contract status without also subscribing to contract updates because new online contracts could be set during the session very often. 6.3.5 Ending subscriptions A Security List Request message is used to end a subscription to contract definitions, where the field NewSecuritySubscription = 2. When a subscription to the status of contracts has been made using the Security List Request message, it can be ended with the same type of message with the field SubscriptionRequestType = 2. When a Security List Request message contains a request to end a subscription (NewSecuritySubscription = 2 or SubscriptionRequestType = 2), the system will consider that the purpose of the message is exclusively to end the subscription and accordingly the other values specified in these two fields are ignored. 6.3.6 List of messages Message Security List Request (Msg Type = x) Security List (Msg Type = y) Description Sent by the client to request the definition of contracts. It also allows information on the status of the contracts to be requested Sent by the server to provide the contract definitions. It is also used to inform about the rejection of requests for this information Sent by the client to request the status of contracts Security Status Request (MsgType = e) 30 July 2012 MEFF 2012 44

6. Market Information Security Status (MsgType = f) Sent by the server to inform about the status of contracts. It is also used to inform about the rejection of requests for this information, or to inform that there is no contract meeting the selection criteria 6.3.7 Flow of messages Request contract definitions without updates After requesting contract definitions, one or more Security List messages will be received. Each of these messages indicates the total number of contracts that meet the selection criteria in the TotNoRelatedSym field and the number of contracts contained in the particular message in the NoRelatedSym field. MEFFGate Client MEFFGate Server Security List Request ( x ) SubscriptionRequestType [263] = 0 (Snapshot) Security List ( y )... Unsolicited Indicator [325] = N TotalNoRelatedSym [393] = 350 NoRelatedSym [146] = 1 Request contract definitions with updates If the request for contract definitions includes the updates (NewSecuritySubscription = 1) in addition to the messages detailed in the case above, when a new contract is entered in the system, a Security List message is received containing information on this contract. MEFFGate Client MEFFGate Server Security List Request ( x ) SubscriptionRequestType [263] = 1 (Snapshot + Update) Security List ( y )... Unsolicited Indicator [325] = N TotalNoRelatedSym [393] = 350 NoRelatedSym [146] = 1 For every new contract Security List ( y ) Unsolicited Indicator [325] = Y TotalNoRelatedSym [393] = 1 NoRelatedSym [146] = 1 Symbol [55] = New Symbol 30 July 2012 MEFF 2012 45

6. Market Information Request contract definitions with updates and contract status with updates If the request includes the status of contracts, a Security Status message is received with said information for each set of contracts that meets the selection criteria. If the request also includes updates (SubscriptionRequestType = 1), a new Security Status message is received each time there is a change in status. MEFFGate Client MEFFGate Server Security List Request ( x ) SubscriptionRequestType [263] = 1 (Snapshot + Update) NewSecuritySubscription [5682] = 1 (Updates) Security List ( y )... Unsolicited Indicator [325] = N TotalNoRelatedSym [393] = 350 NoRelatedSym [146] = 1 Security Status ( f )... Unsolicited Indicator [325] = N Security List ( y ) Unsolicited Indicator [325] = Y TotalNoRelatedSym [393] = 1 NoRelatedSym [146] = 1 Symbol [55] = New Symbol Security Status ( f ) Unsolicited Indicator [325] = Y For every new contract For every group of contracts Security List Request ( x ) SubscriptionRequestType [263] = 2 (Unsubscribe) Request contract status without updates A request for the status of contracts is answered with a Security Status message for each set of contracts, that meets the selection criteria. MEFFGate Client MEFFGate Server Security Status Request ( e ) SubscriptionRequestType [263] = 0 (Snapshot) Security Status ( f )... One message for every set of contracts requested Unsolicited Indicator [325] = N 30 July 2012 MEFF 2012 46

6. Market Information Request contract status with updates A request for the status of contracts with updates is initially answered with a Security Status message for each set of contracts that meets the selection criteria. From this point on, a new Security Status message is received when there is a change in status for any of the set of the contracts with the corresponding information. These later messages will have Y in the UnsolicitedIndicator field. In addition, when a new contract is entered in the system that meets the selection criteria, the server sends the corresponding Security Status message, also with the field UnsolicitedIndicator = Y. MEFFGate Client MEFFGate Server Security Status Request ( e ) SubscriptionRequestType [263] = 1 (Snapshot + Updates) Security Status ( f )... Unsolicited Indicator [325] = N Security Status ( f )... One message for every status change Unsolicited Indicator [325] = Y Security Status Request ( e ) SubscriptionRequestType [263] = 2 (Unsubscribe) Request contract definitions, without contracts that meet the selection criteria When there are no contracts that meet the selection criteria indicated in the contract definition request, MEFFGate will reply with a Security List message where the field SecurityRequestResult = 2. Note that in this case, if the request is made by subscription, that subscription will be active and therefore if new contracts are introduced that meet the selection criteria the corresponding messages will be received. MEFFGate Client MEFFGate Server Security List Request ( x ) Security List ( y ) SecurityRequestResult [560] = 2 (No instruments found that match selection criteria) 30 July 2012 MEFF 2012 47

6. Market Information Request contract status, without contracts that meet the selection criteria When there are no contracts that meet the selection criteria indicated in a contract status request, MEFFGate replies with a SecurityStatus message where the field SecurityTradingStatus = 19. Note that in this case, if the request is made by subscription, that subscription will be active and therefore if new contracts are introduced that meet the selection criteria the corresponding messages will be received. MEFFGate Client MEFFGate Server Security Status Request ( e ) Security Status ( f ) SecurityTradingStatus [326] = 19 (Not Traded on this market) Failed contract definition request When a contract definition request is erroneous, it is answered with a Security List message where the field SecurityRequestResult = 1. MEFFGate Client MEFFGate Server Security List Request ( x ) Security List ( y ) SecurityRequestResult [560] = 1 (Invalid or unsupported request) Failed contract status request When a contract status request is erroneous it is answered with a Security Status message where the field SecurityTradingStatus = 20. MEFFGate Client MEFFGate Server Security Status Request ( e ) Security Status ( f ) SecurityTradingStatus [326] = 20 (Unknown or Invalid) 30 July 2012 MEFF 2012 48

6. Market Information 6.3.8 Annotations and adaptations of FIX 4.4 The NewSecuritySubscription (5682) user field has been added to the Security List Request message to support the functionality of receiving the contract definition when a new contract is entered in the system The UnsolicitedIndicator field has been added to the Security List message The maximum number of allowable subscriptions alive is limited (see section 4.7 for details) In the Security List message the field EventType [865] with codes greater than 100 is used. The client application should be prepared to manage this situation in a correct way 30 July 2012 MEFF 2012 49

6. Market Information 6.4 Market information: Prices 6.4.1 Description This functionality allows information to be requested on the prices for a number of contracts. 6.4.2 Information request The request for information related to prices is made using the Market Data Request message. A number of contracts can be selected using a combination of fields of the Instrument block as explained in 4.5. As it can be seen in the detailed message description, various Instrument blocks can be included to make more than one selection simultaneously. A contract is considered selected if any of the selection criteria are met. The types of information offered by MEFF are listed below. A client can request a combination of these types of information in the same request. Bid Offer Last price Opening price (includes auction prices) Settlement price Session high Session low Session VWAP price Trade Volume Open Interest at the end of the previous session Prior settlement price When a request includes Bid or Offer, it is possible to specify the depth in three modes: maximum, best prices or an exact depth. The request may be just the current situation (snapshot) or include updates (snapshot + update). Note that requesting only the updates without the snapshot is not possible. This is fundamental to ensure the completeness of the information received. In addition to the information listed here, the Bid or Offer request implies receiving indications of interest for the contracts selected (See chapter 7 for a detailed explanation). 6.4.3 Receipt of information MEFFGate sends the information requested in Market Data Snapshot Full Refresh messages. In accordance with the FIX standard, messages in reply to the same request will not mix the Bid and Offer information with other information. In a snapshot request, a single message for each contract selected will be received if there is no mixing of information. In the event that the request combines Bid or Offer information with other information, the reply will consist of two Market Data Snapshot Full Refresh messages. 30 July 2012 MEFF 2012 50

6. Market Information If information updates have been requested, a new Market Data Snapshot Full Refresh message will be received every time there is a change. This message contains both the information that has changed as well as the rest of the fields requested in the subscription. In this case, the restriction of not mixing Bid or Offer information with other fields is maintained. Keep in mind that when there are no Bid or Offer prices for a contract, this is notified by the value zero in the MDEntrySize field. 6.4.4 List of messages Message Market Data Request (Msg Type = V) Market Data Snapshot Full Refresh (Msg Type = W) Market Data Request Reject (Msg Type = Y) Description Sent by the client to request price information Sent by the server to return price information Sent by the server to notify that a Market Data Request has been rejected 6.4.5 Message flow Price information request without updates A price information request, without updates, is answered by MEFFGate with a message for each of the contracts. Note that if the Bid and Offer information is requested along with other information, MEFFGate will return two messages for each contract, separating these two sets of information. MEFFGate Client MEFFGate Server Market Data Request ( V ) SubscriptionRequestType [263] = 0 (Snapshot) Market Data - Snapshot / Full refresh ( W ) (One or two messages for every contract requested) 30 July 2012 MEFF 2012 51

6. Market Information Request for price information with updates A request for price information with updates initially receives a series of messages for the selected contracts at the time of the request. From this moment on it receives messages notifying changes that occur in the market. Note that a request to end the subscription only receives a reply if there is an error. MEFFGate Client MEFFGate Server Market Data Request ( V ) SubscriptionRequestType [263] = 1 (Snapshot + Updates) Market Data - Snapshot / Full refresh ( W ) Snapshot (One or two messages for every contract requested) Market Data - Snapshot / Full refresh ( W )... Updates Market Data Request ( V ) SubscriptionRequestType [263] = 2 (Unsubscribe) Incorrect price information request When a price information request is incorrect the reply will be a Market Data Request Reject message. MEFFGate Client MEFFGate Server Market Data Request ( V ) Market Data Request Reject ( Y ) 6.4.6 Annotations and adaptations of FIX 4.4 The incremental update is not supported In the Market Data Request Reject message, the meaning of the value 0 (invalid symbol) in the MDReqRejReason field has been broadened to indicate an invalid selection criteria The maximum number of allowable subscriptions alive is limited (see section 4.7 for details) 30 July 2012 MEFF 2012 52

6. Market Information 6.5 Definition of messages 6.5.1 Trading Session Status Request (Msg Type = g) Used by the client to request the trading session status. Tag Name Req Valid values Format Description Standard Header Y MsgType = g 335 TradSesReqID Y String (10) Unique identifier for each Trading Session Status Request message. If SubscriptionRequestType = 2 it must contain the identifier of the original request 263 SubscriptionRequestType Y 0=Snapshot Char 1=Snapshot + Updates 2= Unsubscribe Standard Trailer Y 30 July 2012 MEFF 2012 53

6. Market Information 6.5.2 Trading Session Status (Msg Type = h) Sent by the server to inform on the trading session status or to reject a Trading Session Status Request message. Tag Name Req Valid values Format Description Standard Header Y MsgType = h 335 TradSesReqID N String Identifier of Trading Session Status Request message for reference. This field is always included in the message 336 TradingSessionID Y String Indicates market 338 TradSesMethod N 1 = Electronic Int 325 UnsolicitedIndicator N N = The message is part of a snapshot Y = The message is sent due to an update 340 TradSesStatus Y 1 = Halted 2 = Open 3 = Closed 4 = Pre-Open (Not started) 6 = Request Rejected Boolean Int Contains Y when the message is sent as the result of a subscription Session status. Contains the value 6 (Request Rejected) when the message is used to reject a request. The value 4 (Pre-Open) indicates that the market is not yet open for trading. This value must not be confused with the auction period, which in MEFF is specified by contract. (see field 326, SecurityTradingStatus, of the Security Status message). The value 3 (Closed) indicates the end of session but in special circumstances the status 2 (Open) may follows. 58 Text N String Explanation of error. Provided if TradSesStatus = 6 Standard Trailer Y 30 July 2012 MEFF 2012 54

6. Market Information 6.5.3 Security List Request (Msg Type = x) Used by the client to request the contract definitions, with the option of requesting contract status. Tag Name Req Valid values Format Description Standard Header Y MsgType = x 320 SecurityReqID Y String (10) Unique identifier for each Security List Request message If SubscriptionRequestType = 2 or NewSecuritySubscription = 2, it must contain the value of the original request 559 SecurityListRequestType Y 0 = Symbol 1 = Security type and/or CFICode Int Selection criteria used Start <Instrument> 55 Symbol Y [N/A] or contract code 48 SecurityID N See table 21 in document Codification Tables for a list of possible values String(22) String Contract code if SecurityListRequestType = 0 or [N/A] if SecurityList- RequestType = 1 Underlying asset Not allowed if SecurityListRequestType = 0 461 CFICode N Exact length. See 4.5.1 for a list of possible values 200 MaturityMonthYear N YYYYMM or YYYYMMDD or YYYYMMwW End <Instrument> 263 SubscriptionRequestType N 0=Snapshot (value by default) 1=Snapshot + Updates 2= Unsubscribe 5682 * NewSecuritySubscription N 0=Snapshot (value by default) 1= Updates (Subscribe) 2= Unsubscribe Standard Trailer Y String(6) 22 SecurityIDSource N 8 = Exchange Symbol String Required if SecurityID is present. Not allowed if Security- ListRequestType = 0 Month- Year Char Char Contract type Not allowed if SecurityListRequestType = 0 Contract expiration Not allowed if SecurityListRequestType = 0 Indicates the type of contract status request Indicates the type of contract definition request 30 July 2012 MEFF 2012 55

6. Market Information 6.5.4 Security List (Msg Type = y) Message sent by the server to provide the definition of one or more contracts. Tag Name Req Valid values Format Description Standard Header Y MsgType = y 320 SecurityReqID Y String Identifier of Security List Request message that it is replying to 322 SecurityResponseID Y String Unique identifier for each Security List message 560 SecurityRequestResult Y 0=Valid request 1=Invalid or unsupported request 2=No instruments found that match selection criteria 4=Instrument data temporarily unavailable 5=Request was rejected because the CFICode specified is not supported 325* UnsolicitedIndicator N N = The message is part of a snapshot Y = The message is sent due to an update (new contract) Int Boolean Result of request identified by SecurityReqID. If rejected (>0) there is an explanation in the Text [58] field Contains Y when the message is sent due to a subscription 393 TotNoRelatedSym N Int Total number of contracts that meet the selection criteria in the request. The number of contracts that the message contains is indicated in the NoRelated- Sym field. This field is always present when SecurityRequestResult = 0 893 LastFragment N Boolean Indicates when the message is the last in a sequence in response to a single request. This field is always present when SecurityRequestResult = 0 146 NoRelatedSym N 1 NumInGro up Indicates the number of elements contained in this message. Start <Instrument> 55 Symbol Y String(22) Contract code. Present if NoRelatedSym has been specified and SecurityRequestResult [560] = 0 48 SecurityID N See table 21 in String Underlying asset document Codification Tables for a list of possible values 22 SecurityIDSource N 8 = Exchange String Symbol 454 NoSecurityAltID N 30 July 2012 MEFF 2012 56

6. Market Information 455 SecurityAltID N String ISIN code for the contract 456 SecurityAltIDSource N 4 = ISIN number String 461 CFICode N Exact length See table 16 in document Codification Tables for a list of values String(6) Contract type in accordance with the ISO 10962 standard 200 MaturityMonthYear N YYYYMM or YYYYMMDD or YYYYMMwW Month- Year Contract expiration 541 MaturityDate N LocalMktD Expiration date ate 225 IssueDate N UTCDate Date contract issued 202 StrikePrice N Price Exercise price. Only present for options 968 StrikeValue N Float For stocks derivatives, number of shares for each security 231 ContractMultiplier N Float Conversion factor between price units and monetary units 107 SecurityDesc N String Description of the contract subgroup. See table 20 in document Codification Tables 969 MinPriceIncrement N Float Minimum amount allowed for price change. This field is always included in the message 864 NoEvents N NumInGro up 865 EventType N 101 = Last trading Int day 866 EventDate N UTCDate Last trading day End <Instrument> 711 NoUnderlyings N 1 NumInGro up Present if the contract has another contract as its underlying Start <UnderlyingInstrument> 311 UnderlyingSymbol Y String(22) Symbol for underlying contract End <UnderlyingInstrument> 15 Currency N Currency Currency code. Follows ISO 4217 standard 555 NoLegs N NumInGro up Number of contracts that make up the contract. Only present in time-spread contracts Start <InstrumentLeg> 600 LegSymbol N String(22) Contract code. Present if NoLegs has been specified 623 LegRatioQty N Always integer Float Number of LegSymbol contracts included in a Symbol contract 624 LegSide N 1 = Buy 2 = Sell Char Indicates if the contract LegSymbol is to buy or sell. Present if NoLegs has been specified End <InstrumentLeg> 561 RoundLot N Qty The trading lot size. The 30 July 2012 MEFF 2012 57

6. Market Information order volumes of this security must be a multiple of this quantity. 562 MinTradeVol N Qty The minimum trading volume for an order of this security 58 Text N String If SecurityRequestResult [560] > 0 there is an explanation of the rejection Start <Stipulations> 232 NoStipulations N 3 NumInGro up 233 StipulationType N O = Admission String orders H = Admission cross trade in trading hours A = Admission cross trade out of trading hours 234 StipulationValue N N, Y String Indicates whether the security admits orders or cross trades End <Stipulations> Standard Trailer Y 30 July 2012 MEFF 2012 58

6. Market Information 6.5.5 Security Status Request (MsgType = e) Used by the client to request the status of contracts. Tag Name Req Valid values Format Description Standard Header Y MsgType = e 324 SecurityStatusReqID Y String (10) Unique identifier for each Security Status Request message If SubscriptionRequestType = 2 it must contain the value of the original request Start <Instrument> 55 Symbol Y Contract code String(22) Contract code 48 SecurityID N See table 21 in String Underlying asset document Codification Tables for a list of possible values 22 SecurityIDSource N 8 = Exchange Symbol String Required if SecurityID is present 461 CFICode N Exact length. See String(6) Contract type 4.5.1 for a list of possible values 200 MaturityMonthYear N YYYYMM or Month-Year Contract expiration YYYYMMDD or YYYYMMwW End <Instrument> 263 SubscriptionRequestType Y 0=Snapshot Char 1=Snapshot + Updates 2= Unsubscribe Standard Trailer Y 30 July 2012 MEFF 2012 59

6. Market Information 6.5.6 Security Status (MsgType = f) Message sent by the server to inform on the status of one or more contracts. Tag Name Req Valid values Format Description Standard Header Y MsgType = f 324 SecurityStatusReqID N String Identifier of the Security Status Request message being replied to. This field is always included in the message Start <Instrument> 55 Symbol Y Contract code String(22) Contract code The value is [N/A] when the message corresponds to a set of contracts. 48 SecurityID N See table 21 in document Codification Tables for a list of possible values 22 SecurityIDSource N 8 = Exchange Symbol 461 CFICode N Exact length See table 16 in document Codification Tables for a list of values 200 MaturityMonthYear N YYYYMM or YYYYMMDD or YYYYMMwW End <Instrument> 325 UnsolicitedIndicator N N = The message is part of a snapshot Y = The message is sent as the result of an update 326 SecurityTradingStatus N 17 = Ready to trade 18 = Not available for trading 19 = Not Traded on this Market 20 = Unknown or Invalid 21 = Pre-Open 327 HaltReason N P = Halted by Regulator M = Halted by Market Surveillance String String String(6) Month- Year Boolean Int Char Underlying asset. If not specified means for all the underlying assets Present if SecurityID has been specified Contract type in accordance with the ISO 10962 standard. If not specified means for all the type contracts Contract expiration. If not specified means for all the contract expirations Contains Y when the message is sent due to a subscription, and otherwise N. Contains N if SecurityTrading- Status is 19 or 20. This field is always present in the message Informs on the contract status. The value 21 indicates that the contract is under auction. This value must not be confused with the Pre-Open market status, which indicates that no contract can be traded. (See field 340, TradSesStatus, of the Trading Session Status message) Halt reason 332 HighPx N Price Maximum price accepted for a contract. This value may vary during a trading session 333 LowPx N Price Minimum price accepted for a contract. This value may vary during a trading session 58 Text N String Contains an explanation of the error. Provided if SecurityTradingStatus = 19 or 20 Standard Trailer Y 30 July 2012 MEFF 2012 60

6. Market Information 6.5.7 Market Data Request (Msg Type = V) Used by the client to request price information. Tag Name Req Valid values Format Description Standard Header Y MsgType = V 262 MDReqID Y String (10) Unique identifier for each Market Data Request message. If SubscriptionRequestType = 2 it must contain the identifier of the original request 263 SubscriptionRequestType Y 0=Snapshot 1=Snapshot + Updates 2= Unsubscribe Char 264 MarketDepth Y 0 = Full Book 1 = Top of Book n = exact depth (n>1) Int Prices depth Ignored if none of the MDEntryType occurrences are Bid or Offer 265 MDUpdateType N 0 = Full refresh Int Required if SubscriptionRequestType = 1 267 NoMDEntryTypes Y NumInGro up Number of MDEntryType fields that contain the message 269 MDEntryType Y 0 = Bid 1 = Offer Char Type of market information requested 2 = Trade 4 = Opening Price 6 = Settlement Price 7 = Trading Session High Price 8 = Trading SessionLow Price 9 = Trading session VWAP price B = Trade Volume (total volume for contract in session) C = Open Interest M = Prior Settle Price 146 NoRelatedSym Y 1 NumInGro Number of selection criteria up Start <Instrument> 55 Symbol Y Contract code String(22) Contract code SecurityID N See table 21 in String Underlying asset 48 document Codification Tables for a list of possible values 22 SecurityIDSource N 8 = Exchange Symbol String Required if the SecurityID has been specified CFICode N Exact length. See String(6) Contract type 461 4.5.1 for a list of possible values MaturityMonthYear N YYYYMM or Month- Contract expiration 200 YYYYMMDD or YYYYMMwW Year End <Instrument> Standard Trailer Y 30 July 2012 MEFF 2012 61

6. Market Information 6.5.8 Market Data Request Reject (Msg Type = Y) Used by MEFFGate to reject a Market Data Request. Tag Name Req Valid values Format Description Standard Header Y MsgType = Y 262 MDReqID Y String Identifier of the request being rejected 281 MDReqRejReason N 0 = Invalid selection criteria 1 = Duplicate MDReqID 4 = Unsupported SubscriptionRequestType 5 = Unsupported MarketDepth 6 = Unsupported MDUpdateType 8 = Unsupported MDEntryType Char Reason for rejection. This field is always present in the message 58 Text N String Explanation of rejection motive Standard Trailer Y 30 July 2012 MEFF 2012 62

6. Market Information 6.5.9 Market Data Snapshot Full Refresh (Msg Type = W) Used by MEFFGate to communicate price information requested with a Market Data Request message. Tag Name Req Valid values Format Description Standard Header Y MsgType = W 262 MDReqID Y String Identifier of the Market Data Request message that is being replied to Start <Instrument> 55 Symbol Y Contract code String(22) Contract code End <Instrument> 268 NoMDEntries Y NumInGroup Number of entries to follow 269 MDEntryType Y 0 = Bid 1 = Offer 2 = Trade 4 = Opening Price 6 = Settlement Price 7 = Trading Session High Price 8 = Trading Session Low Price 9 = Trading session VWAP price B = Trade Volume (total volume for contract in session) C = Open Interest M = Prior Settle Price Char Type of information that the present entry contains. If the values 0 or 1 are present, the message does not contain any of the others 270 MDEntryPx N Price Price. Present when the MDEntryType is (0,1,2,4,6,7,8,9, M). When it is not present and MDEntryType is 6 or M, it should be considered as a value 0 271 MDEntrySize N Qty Volume. Present when the MDEntryType is (0,1,2,B,C) 273 MDEntryTime N UTCTimeOnly Time of update. Only present if MDEntryType is 0,1 or 2. In the case of Bid (0) or Offer (1) it is only present for one of the values (MDEntryPositionNo = 1) and refers to the update of Bid and Offer in general. 274 TickDirection N 0 = Plus Tick Char Present when MDEntryType = 2 1 = Zero-Plus Tick 2 = Minus Tick 3 = Zero-Minus Tick 290 MDEntryPositionNo N Int Position of order price amongst all positions of the same type (bid or offer). Numbered from the most to the least competitive, starting with 1. 30 July 2012 MEFF 2012 63

6. Market Information Present if MDEntryType is 0 or 1 811 PriceDelta N float Maybe present if MDEntryType = 6 or M Standard Trailer Y 30 July 2012 MEFF 2012 64

7. Request for Quote - Indication of Interest 7. Request for Quote - Indication of Interest 7.1 Introduction The Request for Quote functionality allows MEFFGate clients to enter and receive information about the indications of interest entered from its own member or through Market Services. 7.2 Description When a trader wishes to indicate interest in prices being quoted on a contract, he should use the Quote Request message. Only one Quote Request per option contract per every FIX client is allowed. When the client wants to modify an indication of interest on an specific option contract, it should cancel the existing indication of interest first and then send a new Quote Request. To cancel an indication of interest, a Request for Quote with a volume of zero is sent. When an indication of interest has been made, MEFFGate sends an Indication of Interest message to notify of this situation. Each message refers to a single contract and indicates the accumulated volume of all existing indications of interest for the contract. Accordingly, each new message replaces any previous messages for the same contract. When a trader requests the cancellation of their indication of interest, clients are notified of the remaining volume. If there is no remaining volume, clients receive a message showing zero volume. A client only receives information on the indications of interest for those contracts on which it has requested price information (Bid or Offer) in the Market Data Request message (see 6.4). The way of receiving this information (snapshot or snapshot + update) will be the same as that specified in the Market Data Request message. All indications of interest are cancelled at the end of the trading session. 7.3 List of messages Message Quote Request (Msg Type = R) Quote Request Reject (Msg Type = AG) Indication of Interest (Msg Type = 6) Description Message sent by the MEFFGate client to request or cancel an indication of interest on a specific contract Message sent by MEFFGate to reject a Quote Request message Message sent by MEFFGate to inform about an indication of interest in a contract 30 July 2012 MEFF 2012 65

7. Request for Quote - Indication of Interest 7.4 Message flow Quote request accepted by MEFFGate followed by its cancellation The client sends an indication of interest of 100x on contract A (having a total volume of indications of interest of 4900x). Once the request has been accepted, the client receives a private Indication of Interest (IOI), with the parties block included, indicating that the 100x have been accepted and a public IOI message (without the parties block) with the accumulated volume of the indications of interest on this contract (5000x). Then the indication of interest is cancelled. Once the cancelation is accepted the accumulated volume of the remaining indication of interest on contract A is sent (4900x) MEFFGate Client MEFFGate Server Market Data Request ( V ) Request including Bid or Offer with selection criteria that includes A contract Quote Request ( R ) Indication of Interest ( 6 ) Symbol [55] = A, IOIQty [27] = 4900, IOITransType [28] = R, <Parties block not informed> QuoteReqID [131] = X1, Symbol [55] = A, OrderQty [38] = 100 Indication of Interest ( 6 ) Symbol [55] = A, IOIQty [27] = 100, IOITransType [28] = N, <Parties block informed> Quote Request ( R ) QuoteReqID [131] = X2, Symbol [55] = A, OrderQty [38] = 0 Indication of Interest ( 6 ) Symbol [55] = A, IOIQty [27] = 5000, IOITransType [28] = R, <Parties block not informed> Indication of Interest ( 6 ) Symbol [55] = A, IOITransType [28] = C, <Parties block informed> Indication of Interest ( 6 ) Symbol [55] = A, IOIQty [27] = 4900, IOITransType [28] = R, <Parties block not informed> Quote Request rejected by MEFFGate MEFFGate Client MEFFGate Server Quote Request ( R ) QuoteReqID [131] = Y1, Symbol [55] = A, Quote Request Reject ( AG ) QuoteReqID [131] = Y2, ( Symbol [55] = A, QuoteRequestRejectReason [558] = 100 30 July 2012 MEFF 2012 66

7. Request for Quote - Indication of Interest Reception of indication of interest The client receives an indication of interest for 100 X0000001 contracts. The second message replaces the first and notifies that the volume has increased to 150 contracts. The third message cancels the previous two, notifying that the volume is 0 (all the indications of interest on this contract have been cancelled). MEFFGate Client MEFFGate Server Market Data Request ( V ) Request including Bid or Offer with selection criteria that includes X0000001 contract Indication of Interest ( 6 ) Symbol [55] = X0000001 IOIQty [27] = 100 Indication of Interest ( 6 ) Symbol [55] = X0000001 IOIQty [27] = 150 Indication of Interest ( 6 ) Symbol [55] = X0000001 IOIQty [27] = 0 7.5 Annotations and adaptations of FIX 4.4 In the Quote Request message, the OrderQty [38] field is now required 30 July 2012 MEFF 2012 67

7. Request for Quote - Indication of Interest 7.6 Definition of messages 7.6.1 Quote Request (Msg Type = R) Message sent by the MEFFGate client to request or cancel an indication of interest on a specific contract. Only one indication of interest can be sent in a single message Tag Name Req Valid values Format Description Standard Header Y MsgType = R 131 QuoteReqID Y String Identifier for this Quote Request message Start <QuotReqGrp> 146 NoRelatedSym Y 1 NumInGroup Always 1 Start <Instrument> 55 Symbol Y String (22) Contract code End <Instrument> Start <OrderQtyData> 38 OrderQty Y* 0 9999, integer numbers only End <OrderQtyData> End <QuotReqGrp> Standard Trailer Y Qty Volume of the request. A value of zero (0) indicates that the previously accepted indication of interest on the contract is to be cancelled.. 30 July 2012 MEFF 2012 68

7. Request for Quote - Indication of Interest 7.6.2 Quote Request Reject (Msg Type = AG) Message sent by MEFFGate to reject a Quote Request message. Tag Name Req Valid values Format Description Standard Header Y MsgType = AG 131 QuoteReqID Y String Identifier of Quote Request message that it is replying to 658 QuoteRequestRe jectreason Y 99 = Other 100 = Only one active request per member per user per contract 101 = Only requests on options are allowed int Indicates the status of the Quote Request message If the value is 99 (other) refer to tag Text [58] for further information 58 Text N String If QuoteRequestRejectReason [658] = 99 (Other), contains the reason for rejection Start <QuotReqRjctGr p> 146 NoRelatedSym Y 1 NumInGroup Start <Instrument> 55 Symbol Y String (22) Contract code End <Instrument> Start <OrderQtyData> 38 OrderQty N 0 9999, integer numbers only End <OrderQtyData> End <QuotReqRjctGr p> Standard Trailer Y Qty Volume of the request. A value of zero (0) indicates that the previously accepted indication of interest on the contract is to be cancelled. 30 July 2012 MEFF 2012 69

7. Request for Quote - Indication of Interest 7.6.3 Indication of Interest (Msg Type = 6) Message sent by MEFFGate to notify an indication of interest on a specific contract. Tag Name Req Valid values Format Description Standard Header Y MsgType = 6 23 IOIID Y String Unique identifier of the message 28 IOITransType Y N = New R = Replace C = Cancel Char Start <Instrument> 55 Symbol Y Contract code String(22) Contract code End <Instrument> Start <Parties> When the message refers to a request sent by the MEFFGate client: N = New Request C = Cancellation of Request When this message refers to all the indications of interest on this contract: R = Replace. Indicates that the message replaces the information referring to the same contract (if there is any) This block is sent when the message refers to a request sent by trader. This block is not sent when this message refers to all the indications of interest on this contract. 453 NoPartyIDs N NumInGroup PartyID N String Member or trader code 448 PartyIDSource N D = Proprietary/ Char 447 Custom code 452 PartyRole N 13 = Order Origination Firm Int Indicates the role taken vy the code specified in PartyID 11 = Order Origination Trader End <Parties> 54 Side Y 7 = Undisclosed Char The indications of interest only define the contract and the volume but not if it is to buy or sell 27 IOIQty Y 0 1000000000, integer numbers only. String If Parties block is informed: volume of the request sent by the trader. It contains zero when IOTransType [28] = C (Cancel) Standard Trailer Y If Parties block is not informed: accumulated volume of indications of interest made on the contract in question 30 July 2012 MEFF 2012 70

8. Order management and trades notification 8. Order management and trades notification 8.1 Introduction Order management covers various functions. From the perspective of a FIX client these are: Enter orders Modify orders Cancel orders Mass cancellation of orders Receive order status Notification of order execution and information of trades Request order status reports There is a separate section on each of these functions in this chapter. There is a description of the method of use, the list of related messages, the message flow and the additions or annotations incorporated in this implementation for each function. At the end of the chapter there is a detailed description of all the messages included in the chapter. All the information provided in this chapter is valid for both single contracts and time-spreads, as timespread orders are made on a previously defined contract (as opposed to the contracts that they are made up of). 8.2 Order management on behalf of a trader MEFFGate offers the possiblity, from a multi-trader user, to enter and manage orders on behalf of another authorized trader of the member. 30 July 2012 MEFF 2012 71

8. Order management and trades notification 8.3 Enter orders 8.3.1 Description The FIX client uses this function to enter orders in the trading system. Once an order has been accepted, it can be modified, cancelled or executed. These subjects are covered in detail in other sections of this chapter. In addition to the usual fields of an order such as price or quantity, the client can write in the Text field of the message. This text will remain associated with the order and is included in the associated Execution Report messages. This field is not considered by MEFF, so it can be used for the client s own reference for the order. The maximum length is 15 characters and the rest of the field is ignored. In the MEFF trading system each order is associated with an account. The FIX client usually indicates the account in the Account field. If the account is not specified when a new order is entered, the order will be assigned to the daily account. If a client does not have an daily account set up, an order without the account will be rejected. The account of an order can be modified while the order is alive, as described in 8.4. There are various relevant fields for the identification of orders. More information can be found in section 4.1 - Order identification. 8.3.2 Order entry status When the order request has been sent to MEFFGate it can be directly rejected by MEFFGate, in which case an Execution Report message is received where the field ExecType = 8 (Rejected). Otherwise an Execution Report message is received where the field ExecType = A (Pending New). In the later case, it only indicates that the request has been accepted by MEFFGate and is being sent to the central systems. Based on an optimistic model, the client application can send modifications or cancellations for an order with the status Pending new. When the request has been accepted by MEFFGate, an Execution Report message is received with the field ExecType = 0 (New). At this moment it can be considered that the order is active in the market. If a situation arises that causes the order to be rejected by the central systems, an Execution Report message will equally be received with the field ExecType = 0 (New), but in this case it will be followed by an Execution Report message with the field ExecType = 4 (Cancelled). If the order entered is a Stop, when the Stop is triggered, MEFFGate sends a new Execution Report message with the field ExecType = 0 (New) reflecting the situation of the order after the trigger. To determine if an order has been triggered, check the field WorkingIndicator in the Execution Report message. 8.3.3 Supported order types and validity of orders When sending the order request, the order type is specified by the combination of the OrdType and TimeInForce fields. Appendix A has a list of all order types supported in MEFF and the corresponding values of these two fields in each case. 8.3.4 Order persistence When sending an order request, it can be established if, in the event of a disconnection, the central system will cancel the pending volume or not. This functionality is only valid for certain order types, these are detailed in Appendix A. This functionality is not allowed in an order entered through a privileged user. This information is also available in the Execution Reports corresponding to an order inquiry. 30 July 2012 MEFF 2012 72

8. Order management and trades notification When an order is automatically cancelled in the event of a disconnection, a cancellation Execution Report message is sent with the tag 18 (ExecInst) = Q (Cancel on System Failure). 8.3.5 Give-up instructions in the order entry The member, who is entering or modifying an order, can also send all the necessary information to initiate an automatic give-up to the Clearing Broker once the trade is made with the corresponding give-up reference. This information is also available in the Execution Reports corresponding to an order inquiry. 8.3.6 List of messages Message New Order - Single (Msg Type = D) Execution Report (Msg Type = 8) Description Used by the client to enter a new order Sent by MEFF to confirm or reject the order 8.3.7 Message flow In the following diagrams the values next to Execution Report correspond to the ExecType and OrdStatus fields, respectively. New order entry accepted by MEFFGate and central systems MEFFGate Client MEFFGate Server New Order Single ( D ) Execution Report ( 8 ) ExecType [ 150] = A (Pending New) OrdStatus [39] = A (Pending New) Execution Report ( 8 ) ExecType [ 150] = 0 (New) OrdStatus [39] = 0 (New) 30 July 2012 MEFF 2012 73

8. Order management and trades notification New order entry rejected by MEFFGate When a new order message is directly rejected by MEFFGate, the client receives an Execution Report message with ExecType = 8 (Rejected). The value of OrdStatus is 8 (Rejected) except when the rejection occurs because the ClOrdID is duplicated, in which case this is notified in the order status corresponding to this ClOrdID. MEFFGate Client MEFFGate Server New Order Single ( D ) Execution Report ( 8 ) ExecType [ 150] = 8 (Rejected) OrdStatus [39] = 8 (Rejected) MEFFGate Client MEFFGate Server New Order Single ( D ) ClOrdID [11] = Duplicated ClOrdID Execution Report ( 8 ) ExecType [ 150] = 8 (Rejected) OrdStatus [39] = order status corresponing to the Duplicated ClOrdID New order entry accepted by MEFFGate and rejected by central systems MEFFGate Client MEFFGate Server New Order Single ( D ) Execution Report ( 8 ) ExecType [ 150] = A (Pending New) OrdStatus [39] = A (Pending New) Execution Report ( 8 ) ExecType [ 150] = 0 (New) OrdStatus [39] = 0 (New) Execution Report ( 8 ) ExecType [ 150] = 4 (Cancelled) OrdStatus [39] = 4 (Cancelled) 30 July 2012 MEFF 2012 74

8. Order management and trades notification Entry of a stop order and triggering of the order. MEFFGate Client MEFFGate Server New Order Single ( D ) Execution Report ( 8 ) ExecType [150] = A (Pending New) OrdStatus [39] = A (Pending New) Execution Report ( 8 ) ExecType [150] = 0 (New) OrdStatus [39] = 0 (New) WorkingIndicator [636] = N Execution Report ( 8 ) ExecType [ 150] = 0 (New) OrdStatus [39] = 0 (New) WorkingIndicator [636] = Y 8.3.8 Annotations and adaptations of FIX 4.4 In the New Order Single message, the OrderQty field is now required 30 July 2012 MEFF 2012 75

8. Order management and trades notification 8.4 Modify orders 8.4.1 Description When an order has been entered, but not fully executed it is possible to modify various attributes. The following order attributes can be modified on MEFF: Account Volume Price Stop price Text (client order reference) Give-up reference Give-out internal reference Give-out mnemonic The modification is made with the Order Cancel/Replace Request message, also called Order Modification Request. Every modification message must specify a unique ClOrdID, just like the new order entry messages. The order to be modified is identified by the tag OrigClOrdID. When a modification request is accepted and completed, the ClOrdID tag specified in the order modification request will become valid. Hence, the modified order replaces the original order through the use of this tag. As a general rule, the tags specified in the order modification request replace the same tags in the order to be modified. Fields that are not specified do not change, preserving the value they had at this time. Apart from the ClOrdID tag and the values to be modified, the FIX standard requires a number of redundant fields: Symbol, Side, Order Type and Handling Instructions. These fields must be completed in the order modification request with the same values as the original order. If any of the values fail to match, the request is rejected with a Order Cancel Reject message with CxlRejReason = 2 (Broker/Exchange Option) and there is an explanation in the Text field. The message flow supported by MEFF is set out in table D.2.d of the Order Status Change Matrices in volume 4 of the FIX 4.4 specification. The FIX standard also allows, as an optional feature, the volume of a fully filled order to be increased, effectively re-opening the order; this feature is not supported by MEFF. The specifications of FIX 4.4 present a group of tables in the appendices to volume 4 that describe the message flows and the effects on the order status. Modification of the following tables is supported: C.1.a, C.1.b, C.2.a, C.3.a, C.3.b, C.3.c, D.1.a, D.1.b, D.1.c, D.2.a, D.2.b and D.2.d. Table C.1.c is not supported. 8.4.2 Order modification request status When an order modification request is sent to MEFFGate, it can be rejected directly by MEFFGate, in which case an Order Cancel Reject message is received. Otherwise an Execution Report message is received with the field ExecType = E (Pending Replace). In the later case the report only indicates that the request has been accepted by MEFFGate and is being sent to the central systems. 30 July 2012 MEFF 2012 76

8. Order management and trades notification A request that has been accepted by MEFFGate can be rejected by the central systems, in which case an Order Cancel Reject message is received. Otherwise an Execution Report message is received with the field ExecType = 5 (Replaced), indicating that the modification has been done. 8.4.3 List of messages Message Order Modification Request (Msg Type = G) (a.k.a. Order Cancel / Replace Request) Execution Report (Msg Type = 8) Order Cancel Reject (Msg Type = 9) Description Used by the client to initiate order modification request Sent by MEFFGate to notify status of modification request Sent by MEFFGate to notify the rejection of order modification request 8.4.4 Message flow The following diagrams show the values that appear in the the Execution Report in the ExecType and OrdStatus fields respectively. When OrdStatus is shown as <status> it refers to the current status of the order, regardless of what its status is. Order modification accepted and completed MEFFGate Client MEFFGate Server Order Modification Request ( G ) Execution Report ( 8 ) ExecType [150] = E (Pending Replace) OrdStatus [39] = E (Pending Replace) Execution Report ( 8 ) ExecType [150] = 5 (Replace) OrdStatus [39] = <status> Order modification rejected by MEFFGate MEFFGate Client MEFFGate Server Order Modification Request ( G ) Order Cancel Reject ( 9 ) CxlRejReason [102] = rejection reason 30 July 2012 MEFF 2012 77

8. Order management and trades notification Order modification accepted by MEFFGate and rejected by central systems MEFFGate Client MEFFGate Server Order Modification Request ( G ) Execution Report ( 8 ) ExecType [150] = E (Pending Replace) OrdStatus [39] = E (Pending Replace) Order Cancel Reject ( 9 ) CxlRejReason [102] = rejection reason Modification request accepted by MEFFGate of an order executed in the moment it is requested If the order to modify is executed in the intervening period between sending the modification request and its reception, the system will inform of said execution with an Execution Report message with ExecType = Trade and OrdStatus = Filled. Also an Order Cancel Reject is sent by MEFFGate notifying the Order Modification Request has been rejected because the order execution on the fly. MEFFGate Client MEFFGate Server Order Modification Request ( G ) ClOrdID [11] = B OrigClOrdID [41] = A Execution Report ( 8 ) ExecType [150] = 6 (Pending Replace) OrdStatus [39] = 6 (Pending Replace) ClOrdID [11] = B OrigClOrdID [41] = A Execution Report ( 8 ) ExecType [150] = F (Trade) OrdStatus [39] = 2 (Filled) ClOrdID [11] = A Order Cancel Reject ( 9 ) 8.4.5 Annotations and adaptations of FIX 4.4 Orders cannot be re-opened (the volume of filled orders cannot be increased) 30 July 2012 MEFF 2012 78

8. Order management and trades notification 8.5 Cancel orders 8.5.1 Description Once an order has been entered, it can be cancelled at any time. The cancellation request is made with the Order Cancel Request message. The Order Cancel Request message is used to cancel a specific order. The order to be cancelled is identified by the OrigClOrdID tag. In addition, the cancellation message must have a unique ClOrdID tag, just like the order entry and order modification messages. The FIX standard requires certain redundant values to be included in the message: Symbol and Side. These fields must contain the same values as the order to be cancelled. If the values are not identical, the request will be rejected with the Order Cancel Reject message with the field CxlRejReason = 2 (Broker/Exchange Option) and an explanation in the Text field. Note that an order cancellation request can be sent when the status of the order is Pending New or Pending Replace. That is, the client does not have to wait for confirmation when it wants to cancel. In this case the client should use the ClOrdID of the pending request, assuming that it will be accepted. 8.5.2 Status of order cancellation request When an order cancellation request is sent to MEFFGate, it can be rejected directly by MEFFGate, in which case an Order Cancel Reject message is received. Otherwise, an Execution Report message is received with the field ExecType = 6 (Pending Cancel). In this case it only indicates that the request has been accepted by MEFFGate and is being sent to the central systems. After a request has been accepted by MEFFGate, and therefore sent to the central systems, one of the following situations will occur: Cancellation of the order. When the order is cancelled because of the request sent, an Execution Report message is received with ExecType = 4 (Cancelled) Cancellation of the order by Market Surveillance. If a cancellation request, for the same order, sent by the MEFF Market Surveillance reaches the central systems before the own request, an Execution Report message will be received with ExecType = 4 (Cancelled) due to the action of a third party. In the notification received with respect to the order, there will be no individual response to the own request made. Execution of the order. If the order to be cancelled is executed in the intervening period between sending the cancellation request and its reception, the system will inform of said execution with an Execution Report message with ExecType = Trade and OrdStatus = Filled. Also, an Order Cancel Reject is sent by MEFFGate notifying the Order Cancel Request has been rejected because the order is fully executed. When a cancellation is accepted and completed, the order is assigned the ClOrdID tag in the cancellation request message as its identifier. 8.5.3 List of messages Message Order Cancel Request (Msg Type = F) Execution Report (Msg Type = 8) Order Cancel Reject (Msg Type = 9) Description Used by the client to request the cancellation of an order Sent by MEFFGate to notify status of cancellation Sent by MEFFGate to notify rejection of cancellation request 30 July 2012 MEFF 2012 79

8. Order management and trades notification 8.5.4 Message flow In the following diagrams, the values that appear after the Execution Report correspond to the ExecType and OrdStatus fields, respectively. When OrdStatus is shown as <status> it refers to the current status of the order, regardless of its status. Cancellation request accepted and completed MEFFGate Client MEFFGate Server Order Cancel Request ( F ) Execution Report ( 8 ) ExecType [ 150] = 6 (Pending Cancel) OrdStatus [39] = 6 (Pending Cancel) Execution Report ( 8 ) ExecType [ 150] = 4 (Cancelled) OrdStatus [39] = 4 (Cancelled) Cancellation of order with Pending Replace status MEFFGate Client MEFFGate Server Order Modification Request ( F ) ClOrdID [11] = B OrigClOrdID [41] = A Order Cancel Request ( F ) Execution Report ( 8 ) ExecType [150] = E (Pending Replace) OrdStatus [39] = E (Pending Replace) ClOrdID [11] = B OrigClOrdID [41] = A ClOrdID [11] = C OrigClOrdID [41] = B Execution Report ( 8 ) ExecType [150] = 6 (Pending Cancel) OrdStatus [39] = 6 (Pending Cancel) ClOrdID [11] = C OrigClOrdID [41]= B Execution Report ( 8 ) ExecType [150] = 5 (Replace) OrdStatus [39] = <status> ClOrdID [11] = B OrigClOrdID [41] = A Execution Report ( 8 ) ExecType [ 150] = 4 (Cancelled) OrdStatus [39] = 4 (Cancelled) ClOrdID [11] = C OrigClOrdID [41] = B 30 July 2012 MEFF 2012 80

8. Order management and trades notification Cancellation request rejected by MEFFGate MEFFGate Client MEFFGate Server Order Cancel Request ( F ) Order Cancel Reject ( 9 ) CxlRejReason [102] = rejection reason Cancellation request accepted by MEFFGate of an order executed in the moment it is requested If the order to cancel is executed in the intervening period between sending the cancellation request and its reception, the system will inform of said execution with an Execution Report message with ExecType = Trade and OrdStatus = Filled. Also, an Order Cancel Reject is sent by MEFFGate notifying the Order Cancel Request has been rejected because the order is fully executed. MEFFGate Client MEFFGate Server Order Cancel Request ( F ) ClOrdID [11] = B OrigClOrdID [41] = A Execution Report ( 8 ) ExecType [150] = 6 (Pending Cancel) OrdStatus [39] = 6 (Pending Cancel) ClOrdID [11] = B OrigClOrdID [41] = A Execution Report ( 8 ) ExecType [150] = F (Trade) OrdStatus [39] = 2 (Filled) ClOrdID [11] = A Order Cancel Reject ( 9 ) 8.5.5 Annotations and adaptations of FIX 4.4 No annotations or adaptations have been made to the messages in this chapter 30 July 2012 MEFF 2012 81

8. Order management and trades notification 8.6 Mass cancellation of orders 8.6.1 Description This function allows a group of orders to be cancelled simultaneously. The orders to be cancelled can be identified by specifying selection criteria. Please note that with this message, the pending quotes will not be cancelled. 8.6.2 Selection criteria The selection criteria for orders to be cancelled provided by MEFF are the following: Instrument. Allows orders on a certain type of instrument to be selected using the Instrument block, as described in 4.5 Account. Allows orders on a specific account or group of accounts to be selected. This selection is done using the Account field. The use of the wildcard? to make multiple selection is only allowed in the five positions at a time or in the last two positions. In the later case it must be used in both simultaneously Buy/sell. Allows buy orders and sell orders to be selected When various criteria are used to make a selection, only the orders that meet all the criteria will be selected. Selection criteria that are not used will be ignored when selecting orders. If no selection criteria are specified all orders will be included. Given that MEFFGate supports selection criteria that are not defined in the FIX 4.4 standard, the field MassCancelRequestType is not used and its value should always be 7 (Cancel all orders). MEFF will handle the selection criteria to decide which orders to cancel as explained above. 8.6.3 Status of mass cancellation request Whether or not the mass cancellation is accepted or rejected, the server sends an Order Mass Cancel Report message. When the request is rejected, the MassCancelResponse field will be 0. When it is accepted the value of the field will be 7, even if there are no orders that meet the selection criteria. The acceptance message should not be considered as confirmation of the cancellation. The server will send an Execution Report message for each of the orders cancelled. 8.6.4 ClOrdID field In the corresponding Execution Report messages in which the cancellations are notified there is the OrigClOrdID field that identifies in an unique manner each of the cancelled orders. Note that, in accordance with the standard, the ClOrdID field will contain the same value in all these messages, which corresponds with the ClOrdID that was assigned in the Order Mass Cancel Request message. Accordingly, it should be noted that from this moment on, the cancelled orders will all have the same ClOrdID. More information on the ClOrdID field can be found in section 4.1.1. 30 July 2012 MEFF 2012 82

8. Order management and trades notification 8.6.5 List of messages Message Description Order Mass Cancel Request (Msg Type = q) Order Mass Cancel Report (Msg Type = r) Execution Report (Msg Type = 8) Request to cancel orders that meet selection criteria Message sent by MEFFGate to confirm if mass cancellation is accepted or rejected. It is not used to confirm that cancellations have been processed Message sent by MEFFGate to notify each individual cancellation due to the Order Mass Cancel Request message 8.6.6 Message flow Mass cancellation order request accepted MEFFGate Client MEFFGate Server Order Mass Cancel Request ( q ) ClOrdID [11] = A Order Mass Cancel Report ( r ) MassCancelResponse [531] = 7 (Cancel all orders that match criteria) Execution Report ( 8 )... One message for every cancelled order ClOrdID [11] = A OrigClOrdID [41] = previous ClOrdID ExecType [150] = 4 (Cancelled) OrdStatus [39] = 4 (Cancelled) Mass order request rejected MEFFGate Client MEFFGate Server Order Mass Cancel Request ( q ) ClOrdID [11] = A Order Mass Cancel Report ( r ) MassCancelResponse [531] = 0 (Cancel request rejected) 30 July 2012 MEFF 2012 83

8. Order management and trades notification 8.6.7 Annotations and adaptations of FIX 4.4 MEFF supports more selection criteria than specified in the FIX standard and allows wildcards to be used in some fields The optional Account field has been added to the Order Mass Cancel Request message The optional block Parties has been added to the Order Mass Cancel Request message 30 July 2012 MEFF 2012 84

8. Order management and trades notification 8.7 Notification of execution 8.7.1 Description When an order is filled or partially filled, MEFFGate sends an Execution Report message to notify this, where the field ExecType = F (Trade). When the Execution Report message is used to notify the execution of an order, it specifies the type of trade in the ExchangeTradeType user field. The table 19 in document Codification Tables has a list of possible values for this field and their descriptions. In general terms, an Execution Report message will be received once a trade is accepted by the host, including the cross trades. 8.7.2 Trade cancellation When a trade is cancelled, MEFFGate sends an Execution Report message with tag ExecType [150]= H (Trade Cancel). The ExecRefID [19] field contains the trade registration number (TrdMatchID) of the cancelled trade. 8.7.3 List of messages Message Execution Report (Msg Type = 8) (ExecType = F) Description Sent by MEFFGate to notify the order has been filled or partially filled 8.7.4 Message flow Notification of execution The client receives the Execution Report message for each partial fill or complete fill of an order. MEFFGate Client MEFFGate Server New Order Single ( D ) Execution Report ( 8 )... ExecType [150] = F (Trade) OrdStatus [39] = 1 (Paritially Filled) Execution Report ( 8 ) ExecType [150] = F (Trade) OrdStatus [39] = 2 (Filled) 30 July 2012 MEFF 2012 85

8. Order management and trades notification 8.7.5 Annotations and adaptations of FIX 4.4 The TrdMatchID [880] field has been added to the Execution Report message The ExchangeTradeType [5681] user field has been added to Execution Report message 30 July 2012 MEFF 2012 86

8. Order management and trades notification 8.8 Order Status Request 8.8.1 Description This section covers two functions related to queries on order status: Query status for a specific order. Allows a specific order to be checked using its ClOrdID Query status for group of orders. Allows a group of orders to be checked using certain selection criteria Both functions are limited to orders entered during the current trading session. In both cases the response is given as a single Execution Report message for each of the orders, showing the latest status of the order. If there is an error in the query, it is rejected with an Execution Report message with ExecType = 8 (Rejected). In the query of a specific order, the ClOrdID used will have to coincide with the last of the order. The query of a ClOrdID that has been replaced, through an order cancellation or modification, will be rejected with an Execution Report message with ExecType = 8 (Rejected). Unlike the majority of order management messages, the ClOrdID field in the Order Status Request message must contain the reference for the order being consulted. Note that the FIX standard for the order status request requires two redundant fields: Symbol and Side. The values for these fields must coincide with those in the original order. The query of the order status through the Order Status Request message can produce more than one Execution Report message when the ClOrdID given in the query coincides with the one used in a mass cancellation, as in this case all the orders cancelled by the same request share the same ClOrdID identifier. More information on mass cancellations is provided in section 0. 8.8.2 List of messages Message Order Status Request (Msg Type = H) Order Mass Status Request (Msg Type = AF) Execution Report (Msg Type = 8) Description Status request for a specific order Status request for a group of orders Information on the order status, or notification of error in request 30 July 2012 MEFF 2012 87

8. Order management and trades notification 8.8.3 Message flow Status request for a group of orders MEFFGate Client MEFFGate Server Order Mass Status Request ( AF ) Execution Report ( 8 )... ExecType [150] = I (Order Status) OrdStatus [39] = order status LastRptRequested [912] = N Execution Report ( 8 ) ExecType [150] = I (Order Status) OrdStatus [39] = order status LastRptRequested [912] = Y Status request for a specific order MEFFGate Client MEFFGate Server Order Status Request ( H ) Execution Report ( 8 ) ExecType [150] = I (Order Status) OrdStatus [39] = order status Status request for unknown order MEFFGate Client MEFFGate Server Order Status Request ( H ) Execution Report ( 8 ) ExecType [150] = 8 (Rejected) 8.8.4 Annotations and adaptations of FIX 4.4 Some fields have been declared as unsupported The Parties block has been added to the Order Mass Cancel Request message 30 July 2012 MEFF 2012 88

8. Order management and trades notification 8.9 Definition of messages 8.9.1 New Order - Single (Msg Type = D) Message sent by client to enter order in the system. Tag Name Req Valid values Format Description Standard Header Y MsgType = D 11 ClOrdID Y String(30) Unique order identifier Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup PartyID N String Member or Trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char 452 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader Int Required if NoPartyIDs is specified Indicates the role taken by the code specified in PartyID. Required if NoPartyIDs is specified End <Parties> 1 Account N Fixed length String(5) Account code. If there is no account code the daily account is used 78 NoAllocs N 1 NumInGroup Number of destinations. MEFFGate only accepts a single destination. In this block the member who is entering the order, can also send all the necessary information to initiate an automatic give-up to the Clearing Broker once the trade is made and for the whole volume. This information is: Give-up reference, give-out internal reference and Give-up mnemonic 79 539 524 525 538 AllocAccount N String This field is required by the standard when NoAllocs is present. Ignored by MEFFGate Start <NestedParties> NoNestedPartyIDs N NumInGroup NestedPartyID N String Required if NoNestedPartyIDs is specified. Give-out internal reference, Clearing Broker member code, Give-up reference or Give-out mnemonic. For the Give-out internal reference (NestedPartyRole=3) this tag has a maximum lengh of 18 characters. For the Give-Up Clearing Firm (NestedPartyRole=14) the length for this tag is 4 characters. For the Give-up reference (NestedPartyRole=24) this tag has a maximum lengh of 18 characters. For the Give-up mnemonic (NestedPartyRole=33) this tag has a maximum lengh of 10 characters NestedPartyIDSour N D = Proprietary/ Char Required if NoNestedPartyIDs is ce Custom code specified NestedPartyRole N 3 = Give-out internal reference 14 = Give-Up Clearing Firm 24 = Give-up Reference Int Required if NoNestedPartyIDs is specified. Value 3 indicates the value specified in NestedPartyID is the reference assigned by the Executing Broker for internal purposes. It is associated to a 30 July 2012 MEFF 2012 89

8. Order management and trades notification 33 = Give-up mnemonic End <NestedParties> 21 HandlInst Y 1 = Automated execution order, private 18 ExecInst N H = Not Cancel on System Failure (default) Q = Cancel on System Failure Char MultipleValue String Give-out mnemonic and it can be not unique. Need not be provided. Value 14 indicates the value specified in NestedPartyID is the Give-up Clearing Broker. Value 24 indicates the value specified in NestedPartyID is the Give-up reference. Value 33 indicates the value specified in NestedPartyID is the Give-out mnemonic Order persistence. Indicates the action taken by the MEFF central system in the event of a disconnection. Value Q means to cancel the pending volume. Not informing this tag or value H means the order will remain in the order book. Start <Instrument> 55 Symbol Y Contract code String(22) Contract code End <Instrument> 54 Side Y 1 = Buy Char 2 = Sell 60 TransactTime Y UTC Time order request was made Timestamp Start <OrderQtyData> 38 OrderQty Y* Qty Order volume End <OrderQtyData> 40 OrdType Y 1 = Market Char Order type 2 = Limit 3 = Stop 4 = Stop Limit 44 Price N Price Order price. Required if OrdType is 2 or 4 99 StopPx N Price Stop price. Required if OrdType is 3 or 4 59 TimeInForce N 0 = Day (default Char Indicates how long order is valid value) 2 = At the Opening (OPG) 3 = Immediate or Cancel (IOC) 4 = Fill or Kill 58 Text N String (15) Order reference given by client 77 PositionEffect N O=Open (default) C=Close Standard Trailer Y Char Indicates whether the resulting position after a trade should be an opening position or closing position 30 July 2012 MEFF 2012 90

8. Order management and trades notification 8.9.2 Order Cancel Request (Msg Type = F) Message sent by client to request cancellation of order. Tag Name Req Valid values Format Description Standard Header Y MsgType = F 41 OrigClOrdID Y String(30) ClOrdID of order to cancel 11 ClOrdID Y String(30) Cancellation identifier. It becomes the order identifier when the cancellation is processed Start <Parties> 453 NoPartyIDs N >0, <=2 NumInGroup PartyID N String Member or Trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader Int Indicates the role taken by the code specified in PartyID. Required if NoPartyIDs is specified End <Parties> Start <Instrument> 55 Symbol Y Contract code String(22) Must contain the same value as specified in the original order End <Instrument> 54 Side Y 1 = Buy 2 = Sell Char Must contain the same value as specified in the original order 60 TransactTime Y UTC Time order request was made Timestamp Standard Trailer Y 30 July 2012 MEFF 2012 91

8. Order management and trades notification 8.9.3 Order Modification Request (Msg Type = G) (This message is also known as Order Cancel/Replace Request) Message used to request order modification. Tag Name Req Valid values Format Description Standard Header Y MsgType = G Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup PartyID N String Member or Trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader Int Indicates the role taken by the code specified in PartyID. Required if NoPartyIDs is specified End <Parties> 41 OrigClOrdID Y String(30) ClOrdID of order to substitute 11 ClOrdID Y String(30) Modification identifier. It becomes the order identifier when the modification is made 1 Account N Fixed length String(5) New account code. If not specified, the account remains unchanged 78 NoAllocs N 1 NumInGroup Number of destinations. MEFFGate only accepts a single destination. In this block the member who is modifying the order, can also send all the necessary information to initiate an automatic give-up to the Clearing Broker once the trade is made and for the whole volume. This information is: Give-up reference, give-out internal reference and Give-up mnemonic If not specified, this block remain unchanged. 79 539 524 If specified then it is necessary to inform the whole information for this block AllocAccount N Exact length String(5) This field is required by the standard when NoAllocs is present. Ignored by MEFFGate Start <NestedParties> NoNestedPartyIDs N NumInGroup NestedPartyID N String Required if NoNestedPartyIDs is specified. Give-out internal reference, Clearing Broker member code, Give-up reference or Give-out mnemonic. For the Give-out internal reference (NestedPartyRole=3) this tag has a maximum lengh of 18 characters. For the Give-Up Clearing Firm 30 July 2012 MEFF 2012 92

8. Order management and trades notification 525 538 NestedPartyIDSourc e N D = Proprietary/ Custom code NestedPartyRole N 3 = Give-out internal reference 14 = Give-Up Clearing Firm 24 = Give-up Reference 33 = Give-up mnemonic Char Int (NestedPartyRole=14) the length for this tag is 4 characters. For the Give-up reference (NestedPartyRole=24) this tag has a maximum lengh of 18 characters. For the Give-up mnemonic (NestedPartyRole=33) this tag has a maximum lengh of 10 characters Required if NoNestedPartyIDs is specified Required if NoNestedPartyIDs is specified. Value 3 indicates the value specified in NestedPartyID is the reference assigned by the Executing Broker for internal purposes. It is associated to a Give-out mnemonic and it can be not unique. Need not be provided. Value 14 indicates the value specified in NestedPartyID is the Give-up Clearing Broker. Value 24 indicates the value specified in NestedPartyID is the Give-up reference. Value 33 indicates the value specified in NestedPartyID is the Give-out mnemonic End <NestedParties> 21 HandlInst Y 1 Char Must contain the same value as in the original order Start <Instrument> 55 Symbol Y Contract code String(22) Must contain the same value as in the original order End <Instrument> 54 Side Y 1 = Buy 2 = Sell Char Must contain the same value as in the original order 60 TransactTime Y UTC Timestamp Time order request was made Start <OrderQtyData> 38 OrderQty N Qty Total intended Order Quantity (including the amount already executed for this chain of orders). For example, if the original order were of 20 contracts, a partial execution of 5 contracts took place, and the original order is wanted to reduce it in 1, this field should be accomplished with value 19. If not specified it will remain unchanged End <OrderQtyData> 40 OrdType Y 1 = Market 2 = Limit 3 = Stop 4 = Stop Limit Char Must contain the same value as in the Execution Report sent by the Exchange 44 Price N Price Order price. If not specified, the 30 July 2012 MEFF 2012 93

8. Order management and trades notification price remains unchanged 99 StopPx N Price Stop price. If not specified, the price remains unchanged. Only allowed when OrdType = 4 58 Text N String (15) Order reference given by client. If not specified, it remains unchanged 77 PositionEffect N O=Open C=Close Char Indicates whether the resulting position after a trade should be an opening position or closing position. Only applies to the omnibus accounts. If not specified, the Position Effect remains unchanged Standard Trailer Y 30 July 2012 MEFF 2012 94

8. Order management and trades notification 8.9.4 Execution Report (Msg Type = 8) Message sent by MEFFGate to notify the status of an order, including if the order is filled or partially filled; also used to reject an invalid order request. Tag Name Req Valid values Format Description Standard Y MsgType = 8 Header 37 OrderID Y String Unique order identifier, assigned by MEFFGate or QuoteID sent by client in a quote. When ExecType = 8 (Rejected) it contains NONE 198 SecondaryOrder ID N String Order identifier, assigned by central system of MEFF or another exchange 527 SecondaryExecI D N String Order history number, assigned by central system of MEFF or another exchange. Each time there is a new event in the life of the order (modification, trade or cancellation) is assigned a new value to this field. 11 ClOrdID N String ClOrdID (see 4.1.1) sent by client. Only included if this message is related to an order 41 OrigClOrdID N String(30) OrigClOrdID sent by client. Only provided when the related message is a cancellation or modification request 5681* ExchangeTrade Type N See table 19 in document Codification Tables for details of the Trade Type codes String Only provided when ExecType = F (Trade) or H (Trade Cancel) 790 OrdStatusReqID N String Contains the same value that was specified in the associated Order Status Request message. Only provided when the associated message is this type and has this field 584 MassStatusReqI D N String Identifier of associated message. Only provided when the associated message is Order Mass Status Request 911 TotNumReports N Int Indicate the total number of messages in the reply to an Order Mass Status Request. Only present when the reply is to this type of request 912 LastRptRequest ed N Boolean Used to indicate that it is the last message sent as response to a Order Mass Status Request Start <Parties> 453 NoPartyIDs N NumInGroup 448 PartyID N String Member or trader code, Give-out internal reference, Clearing Broker member code, Give-up reference or Give-out mnemonic 447 PartyIDSource N D = Proprietary/ Custom code Char 452 PartyRole N 1 = Executing Firm 3 = Give-out internal reference 7 = Entering Firm (intermediary) 11 = Order Int Indicates the role taken by the code specified in PartyID. 30 July 2012 MEFF 2012 95

8. Order management and trades notification Origination Trader 12 = Executing Trader 13 = Order Origination Firm 14 = Give-Up Clearing Firm 24 = Give-up Reference 33 = Give-up mnemonic 36 = Entering Trader (intermediary) End <Parties> 548 CrossID N String Contains the value of the field SecondaryTradeReportID [818] in the Trade Capture Report message when it is a trade related to a cross trade. Only present if the associated message is this type 17 ExecID Y String Unique identifier of Execution Report assigned by MEFFGate. Displays 0 if ExecType = I (Order Status) 19 ExecRefID N String Trade registration number (TrdMatchID) of the cancelled trade. Present when ExecType [150] = H 150 ExecType Y 0 = New 4 = Cancelled 5 = Replace 6 = Pending Cancel 8 = Rejected A = Pending New E = Pending Replace F = Trade H = Trade Cancel I = Order Status 39 OrdStatus Y 0 = New 1 = Partially Filled 2 = Filled 4 = Cancelled 6 = Pending Cancel 8 = Rejected A = Pending New E = Pending Replace 636 WorkingIndicator N Y = Stop Order is currently triggered N = Stop Order is not currently triggered 103 OrdRejReason N 0 = Exchange option 3 = Order exceeds limit Char Char Boolean Int Indicates the status of the associated message, whereas OrdStatus provides the current order status. If cancelled (value 4) or rejected (value 8), there is an explanation in the Text field Indicates the current status of the order In a quote the content of this field should not be considered (always filled with 1 ) Indicates if a Stop order has been triggered Rejection or cancellation motive. It can be provided when ExecType = 4 or 8 30 July 2012 MEFF 2012 96

8. Order management and trades notification (price or volume filters) 6 = Duplicate ClOrdID 12 = Surveillance option 99 = Other 100 = Disconnection of the client application 103=No permission to enter/manage orders 104=Delta protection 1 Account N String(5) Account associated with order Start <Instrument> 55 Symbol Y Contract code String(22) Contract code associated with order End <Instrument> 54 Side Y 1 = Buy Char Indicates if the order is to buy or sell 2 = Sell Start <OrderQtyData> 38 OrderQty Y Qty Total Order volume, as indicated in the New Order message, or in the modification message In a quote the content of this field should not be considered (always filled with zero) End <OrderQtyData> 40 OrdType N 1 = Market Char Order type 2 = Limit 3 = Stop 4 = Stop Limit 44 Price N Price Order Price In a quote, if appears, the content of this field should not be considered (filled with zero) 99 StopPx N Price Stop price of order 59 TimeInForce N 0 = Day 2 = At the opening (OPG) 3 = Immediate or Cancel (IOC) 4 = Fill or Kill (FOK) Char Indicates how long order is valid 18 ExecInst N H = Not Cancel on System Failure Q = Cancel on System Failure MultipleValu estring 32 LastQty N Qty Volume on this fill. Provided if OrdStatus = 1 or 2 31 LastPx N Price Price of this fill. Provided if OrdStatus = 1 or 2 151 LeavesQty Y Qty Order volume pending Contains 0 when OrdStatus = 4 30 July 2012 MEFF 2012 97

8. Order management and trades notification (Cancelled) In a quote the content of this field should not be considered (always filled with zero) 14 CumQty Y Qty Total volume filled This field should not be considered when zero 6 AvgPx Y Price Average price of all fills on this order. This field should not be considered when CumQty=0 60 TransactTime N UTCTimesta mp Time when transaction represented by this Execution Report occurred. This field is not present when ExecType is equal to 6, A or E 381 GrossTradeAmt N Amt Effective amount 77 PositionEffect N O=Open C=Close Char Indicates whether the resulting position after a trade should be an opening position or closing position. Only applies to the omnibus accounts. 58 Text N String If ExecType = 8 (Rejection) there is an explanation of the rejection. Otherwise it has the client order reference, entered in the Text field of the order message 442 MultiLegReportin gtype N 1=Single Security 2=Individual leg of a multi-leg security 3=Multi-leg security Char Indicates whether the trade refers to a single contract a time-spread or the leg of a time spread. 880* TrdMatchID N String(13) Trade registration number. Identifier of partial fill or filled order, assigned by central system of MEFF or another exchange. Provided when ExecType = F (Trade) or H (Trade Cancel) Standard Trailer Y 30 July 2012 MEFF 2012 98

8. Order management and trades notification 8.9.5 Order Cancel Reject (Msg Type = 9) Message sent by MEFFGate to reject an order modification or cancellation message. Tag Name Req Valid values Format Description Standard Header Y MsgType = 9 37 OrderID Y See 4.1.2 String OrderID associated to order. It is NONE if CxlRejReason = 1 (Unknown order) Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup PartyID N String Member or Trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader Int Indicates the role taken by the code specified in PartyID. Required if NoPartyIDs is specified End <Parties> 11 ClOrdID Y String(30) ClOrdID of rejected message 41 OrigClOrdID Y String(30) ClOrdID of order that could not be modified or cancelled. Contains the same value as OrigClOrdID of the cancellation or modification request message 39 OrdStatus Y 0 = New 1 = Partially Filled 2 = Filled 4 = Cancelled 8 = Rejected C = Expired Char 60 TransactTime N UTC Timestamp 434 CxlRejResponseTo Y 1 = Order Cancel Char Request 2 = Order Cancel/Replace Request 102 CxlRejReason N 0 = Too late to cancel Int 1 = Unknown order 2 = Exchange option 3 = Order already in Pending Cancel or Pending Replace status 6 = Duplicate ClOrdID received 99=other Order status. It is 8 (Rejected) if CxlRejReason = 1 (Unknown order) Time rejection message generated Type of message responded to Rejection motive. If value is 99 there is an explanation in the Text field 58 Text N String Explanation of rejection Standard Trailer Y 30 July 2012 MEFF 2012 99

8. Order management and trades notification 8.9.6 Order Status Request (Msg Type = H) Message sent by the client to request information on the status of a specific order. Tag Name Req Valid values Format Description Standard Header Y MsgType = H 11 ClOrdID Y String(30) ClOrdID of the order for which status is required Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup PartyID N String Member or Trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader Int Indicates the role taken by the code specified in PartyID Required if NoPartyIDs is specified End <Parties> 790 OrdStatusReqID N String(10) Optional code to identify request. If given it will be returned in the corresponding Execution Report message Start <Instrument> 55 Symbol Y Contract code String(22) Must contain the same value as the order queried End <Instrument> 54 Side Y 1 = Buy 2 = Sell Standard Trailer Y Char Must contain the same value as the order queried 30 July 2012 MEFF 2012 100

8. Order management and trades notification 8.9.7 Order Mass Cancel Request (Msg Type = q) Message sent by the client to request the cancellation of orders that meet certain selection criteria. Tag Name Req Valid values Format Description Standard Header Y MsgType = q 11 ClOrdID Y String(30) Unique identifier of this Order Mass Cancel Request message 530 MassCancelRequestType Y 7 = Cancel all orders that match criteria Char Ignored by MEFFGate, as only those orders that meet the selection criteria are cancelled Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup PartyID N String Member or Trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 Int PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader End <Parties> Start <Instrument> 55 Symbol Y [N/A] or contract code String(22) 48 SecurityID N See table 21 in document Codification Tables for a list of possible values String 22 SecurityIDSource N 8 = Exchange String Symbol 461 CFICode N Fixed length. See String(6) 4.5.1 for a list of possible values 200 MaturityMonthYear N YYYYMM or Month-Year YYYYMMDD or YYYYMMwW End <Instrument> 54 Side N 1 = Buy Char 2 = Sell 60 TransactTime Y UTC Timestamp Indicates the role of the code specified in PartyID. Required if NoPartyIDs is specified Contract code. If it is [N/A] the orders for all contracts matching the rest of criteria will be selected Underlying asset Required if SecurityID is specified Contract type Contract expiration Selection criteria for long or short orders Time order request was made 1* Account N String(5) Account code. The use of the wildcard? for multiple selection is only permitted in the five positions at a time or in the last two positions. In the later case it must be used in both at the same time Standard Trailer Y 30 July 2012 MEFF 2012 101

8. Order management and trades notification 8.9.8 Order Mass Cancel Report (Msg Type = r) Message responding to a mass order cancellation request. It notifies whether the request is accepted or rejected. To ensure that the cancellations have been processed, it is necessary to wait until the corresponding Execution Reports are received. Tag Name Req Valid values Format Description Standard Header Y MsgType = r 11 ClOrdID N String(30 ) ClOrdID specified in the Order Mass Cancel Request message 37 OrderID Y String Unique identifier for the Order Mass Cancel Request message assigned by MEFF 530 MassCancelRequestType Y 7 Char Contains the same value as specified in request 531 MassCancelResponse Y 0 = Cancel Request Rejected 7 = Cancel all orders that match criteria 532 MassCancelRejectReason N 1 = Invalid or unknown Security 4 = Invalid or unknown CFICode 99 = other Char String 7 if the cancellation is accepted. 0 if rejected. If it is 0, the MassCancelRejectReason field gives the rejection motive Rejection motive. Provided if MassCancelResponse = 0. If value is 99, there is an explanation of the rejection motive in the Text field 58 Text N String Explanation of rejection motive Standard Trailer Y 30 July 2012 MEFF 2012 102

8. Order management and trades notification 8.9.9 Order Mass Status Request (Msg Type = AF) Message sent by the client to request status of orders meeting certain selection criteria. Note that the Parties block of the message is not part of the selection criteria and refers to the originator of the message. Consult 4.3 for more information on the Parties block. Tag Name Req Valid values Format Description Standard Header Y MsgType = AF 584 MassStatusReqID Y String(10) Unique identifier of this Order Mass Status Request message 585 MassStatusReqType Y 7 = Status for all orders Int Ignored by MEFFGate, as only the orders that meet selection criteria are selected Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup PartyID N String Member or Trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 Char PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader Indicates the role taken by the code specified in PartyID. Required if NoPartyIDs is specified End <Parties> 1 Account N String(5) Account code. The use of the wildcard? for multiple selection is only permitted in the five positions at a time or in the last two positions. In the later case it must be used in both at the same time Start <Instrument> 55 Symbol Y [N/A] or contract code 48 SecurityID N See table 21 in document Codification Tables String(22) String Contract code. If it is [N/A] the orders for all contracts matching the rest of criteria will be selected Underlying asset 22 SecurityIDSource N 8 = Exchange Symbol String Required if SecurityID is specified 461 CFICode N Fixed length. String(6) Contract type See 4.5.1 for list of possible values 200 MaturityMonthYear N YYYYMM or Month-Year Contract expiration YYYYMMDD or YYYYMMwW End <Instrument> 54 Side N 1 = Buy 2 = Sell Char Selection criteria for orders to buy or to sell Standard Trailer Y 30 July 2012 MEFF 2012 103

9. Quote management 9. Quote management 9.1 Introduction Quote management covers various functions. From the perspective of a FIX client these are: Enter quotes Modify quotes Cancel quotes Notification of quote execution Quote status request Configuration of the quote parameters: Account and delta protection Quote parameters report There is a separate section on each of these functions in this chapter. There is a description of the method of use, the list of related messages, the message flow and the additions or annotations incorporated in this implementation for each function. At the end of the chapter there is a detailed description of all the messages included in the chapter. 30 July 2012 MEFF 2012 104

9. Quote management 9.2 Enter quotes 9.2.1 Description The FIX client uses this function to enter quotes in the trading system Only one quote per contract per every FIX client is allowed. If a second quote for the same contract is entered (whether or not the account is the same), MEFFGate will cancel the old quote and will accept (or reject) the new one. Once a quote has been accepted, it can be modified, cancelled or executed. These subjects are covered in detail in other sections of this chapter. The client application can send a parcial quote (only the buy side or the sell side). In this event, only the corresponding side should be filled (BidPx/BidSize or OfferPx/OfferSize) and volume zero should be asumed in the other side and any previous notification will be cancelled The client application must be ready to receive a quote accepted only on one side (buy or sell) and rejected on the other one, for instance due to a price limits. In the event of any disconnection, the central system will automatically cancel the pending quotes. (only if the Market has activated the Order automatically canceled in the event of a disconnection functionality). 9.2.2 List of messages Message Quote (Msg Type = S) Quote Status Report (Msg Type = AI) Description Used by the client to enter a new quote Sent by MEFF to confirm or reject the new quote 30 July 2012 MEFF 2012 105

9. Quote management 9.2.3 Message flow New quote entry totally accepted by MEFFGate and central systems MEFFGate Client MEFFGate Server Quote ( S ) QuoteID [117] = a BidPx[132], OfferPx[133], BidSize[134], OfferSize[133] Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) OrdStatus 1 [39] = 0 (Accepted) OrdStatus 2 [39] = 0 (Accepted) New quote entry partially accepted by central host MEFFGate Client MEFFGate Server Quote ( S ) QuoteID [117] = a Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) OrdStatus 1 [39] = 8 (Rejected) OrdStatus 2 [39] = 0 (Accepted) 30 July 2012 MEFF 2012 106

9. Quote management New partial quote entry (sell-sided only) totally accepted by MEFFGate and central systems MEFFGate Client MEFFGate Server Quote ( S ) QuoteID [117] = a OfferPx[133], OfferSize[133] Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) NoSides [552] = 1 Side [54] = 2 (Sell) OrdStatus [39] = 0 (Accepted) New quote entry rejected by MEFFGate MEFFGate Client MEFFGate Server Quote ( S ) QuoteID [117] = a Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 5 (Rejected) New quote entry accepted by MEFFGate and rejected by central systems MEFFGate Client Quote ( S ) QuoteID [117] = a MEFFGate Server Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 5 (Rejected) 30 July 2012 MEFF 2012 107

9. Quote management A second correct quote is entered for the same contract (MEFF system automatically cancels the first quote and accepts the second one) MEFFGate Client Quote ( S ) QuoteID [117] = a Symbol [55] = x MEFFGate Server Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) Quote ( S ) QuoteID [117] = b Symbol [55] = x Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 4 (Canceled All) Quote Status Report ( AI ) QuoteID [117] = b QuoteStatus [297] = 0 (Accepted) 30 July 2012 MEFF 2012 108

9. Quote management A second erroneous quote, rejected by the MEFF central system, is entered for the same contract (MEFF system automatically cancels both quotes) MEFFGate Client MEFFGate Server Quote ( S ) QuoteID [117] = a Symbol [55] = x Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) Quote ( S ) QuoteID [117] = b Symbol [55] = x Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 4 (Canceled All) Quote Status Report ( AI ) QuoteID [117] = b QuoteStatus [297] = 5 (Rejected) 9.2.4 Annotations and adaptations of FIX 4.4 The optional fields Quote Status Report: TransactTime [60], NoSides [552], Side [54], SecondaryOrderID [198], SecondaryExecID [527], OrdStatus [39], OrdRejReason [103] and LeavesQty [151] have been added to the Quote Status Report message. 30 July 2012 MEFF 2012 109

9. Quote management 9.3 Modify quotes 9.3.1 Description When a quote has been accepted it is possible to modify various attributes The following quote attributes can be modified on MEFF: Bid price Ask price The modification request is done by using the Quote message (the same message used in a new quote entry) with the same QuoteID identifier used for the quote to be modified. As a general rule the fields specified in the modification request substitute the previous values. The fields not specified remain unchanged. A quote modification rejected by MEFF central systems means that the MEFF system automatically cancels the existing quote. A quote modification follows the same priority rules applied to limit orders. 9.3.2 List of messages Message Quote (Msg Type = S) Quote Status Report (Msg Type = AI) Description Used by the client to enter a quote modification Sent by MEFF to confirm or reject the quote modification 9.3.3 Message flow Quote modification rejected by MEFFGate MEFFGate Client Quote ( S ) QuoteID [117] = a, Symbol [55] = x Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) MEFFGate Server Quote ( S ) QuoteID [117] = a, Symbol [55] = x Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 5 (Rejected) 30 July 2012 MEFF 2012 110

9. Quote management Quote modification accepted by MEFFGate and central systems MEFFGate Client MEFFGate Server Quote ( S ) QuoteID [117] = a Symbol [55] = x Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) Quote ( S ) QuoteID [117] = a Symbol [55] = x Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) 30 July 2012 MEFF 2012 111

9. Quote management Quote modification rejected by the MEFF central system (MEFF system automatically cancels the existing quote) MEFFGate Client MEFFGate Server Quote ( S ) QuoteID [117] = a Symbol [55] = x Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 0 (Accepted) Quote ( S ) QuoteID [117] = a Symbol [55] = x Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 5 (Rejected) Quote Status Report ( AI ) QuoteID [117] = a QuoteStatus [297] = 4 (Cancelled All) 9.3.4 Annotations and adaptations of FIX 4.4 The optional fields Quote Status Report: TransactTime [60], NoSides [552], Side [54], SecondaryOrderID [198], SecondaryExecID [527], OrdStatus [39], OrdRejReason [103] and LeavesQty [151] have been added to the Quote Status Report message. 30 July 2012 MEFF 2012 112

9. Quote management 9.4 Cancel quotes 9.4.1 Description This function allows: a) To cancel a single quote or b) to cancel a block of quotes in a simultaneous way. To cancel a single quote the Quote message (Msg Type = S) should be used specifying the same QuoteID identifier used for the quote to be cancelled and the price and volume fields filled to zero (BidPx, OfferPx, BidSize and OfferSize). To cancel block of quotes the Quote Cancel message (Msg Type = Z) should be used specifying the selection criteria 9.4.2 Selection criteria The selection criteria for quotes to be cancelled provided by MEFF (using the Quote Cancel message) are the following: Instrument. Allows quotes on a certain type of instrument to be selected using the Instrument block, as described in 4.5 Selection criteria that are not used will be ignored when selecting quotes. If no selection criteria are specified all quotes will be included. 9.4.3 List of messages Message Quote (Msg Type = S) Quote Cancel (Msg Type = Z) Quote Status Report (Msg Type = AI) Description Used by the client to cancel a single quote Used by the client to cancel quotes that meet selection criteria Message sent by MEFFGate to accept or reject one or various quote cancellations 30 July 2012 MEFF 2012 113

9. Quote management 9.4.4 Message flow Mass cancellation quote request accepted MEFFGate Client MEFFGate Server Quote Cancel ( Z ) Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteStatus [297] = 4 (Canceled All) Individual cancellation quote request accepted MEFFGate Client MEFFGate Server Quote ( S ) QuoteID [117] = a BidPx [132] = OfferPx [133] = BidSize [134] = OfferSize [135] = 0 Quote Status Report ( AI ) QuoteStatus [297] = 10 (Pending) Quote Status Report ( AI ) QuoteStatus [297] = 4 (Canceled All) 30 July 2012 MEFF 2012 114

9. Quote management Cancellation quote request rejected MEFFGate Client MEFFGate Server Quote Cancel ( Z ) Quote Status Report ( AI ) QuoteStatus [297] = 5 (Rejected) 9.4.5 Annotations and adaptations of FIX 4.4 The optional fields Quote Status Report: TransactTime [60], NoSides [552], Side [54], SecondaryOrderID [198], SecondaryExecID [527], OrdStatus [39], OrdRejReason [103] and LeavesQty [151] have been added to the Quote Status Report message. 30 July 2012 MEFF 2012 115

9. Quote management 9.5 Notification of quote execution 9.5.1 Description When a quote is filled or partially filled, MEFFGate sends an Execution Report message to notify this, where the field ExecType = F (Trade). 9.5.2 List of messages Message Execution Report (Msg Type = 8) (ExecType = F) Description Sent by MEFFGate to notify the quote has been filled or partially filled 9.5.3 Message flow Notification of execution The client receives the Execution Report message for each partial fill or complete fill of a quote. MEFFGate Client MEFFGate Server Quote ( S )... QuoteID [117] Execution Report ( 8 ) ExecType [150] = F (Trade), OrderID [37] = QuoteID, LastPx[31], LastQty[32], Account [1] 9.5.4 Annotations and adaptations of FIX 4.4 No annotations or adaptions have been made to the messages in this chapter. 30 July 2012 MEFF 2012 116

9. Quote management 9.6 Quote Status Request 9.6.1 Description The types of information offered by MEFF are: Instrument. Allows quarying the quotes on a certain type of instrument to be selected using the Instrument block, as described in 4.5 9.6.2 List of messages Message Quote Status Request (Msg Type = a) Quote Status Report (Msg Type = AI) Description Status request for a group of quotes Information on the quote status, or notification of error in request 9.6.3 Message flow Quote status request MEFFGate Client MEFFGate Server Quote Status Request ( a ) Quote Status Report ( AI ) QuoteStatus [297] = 8 (Query) Quote status request failed MEFFGate Client MEFFGate Server Quote Status Request ( a ) Quote Status Report ( AI ) QuoteStatus [297] = 5 (Rejected) 9.6.4 Annotations and adaptations of FIX 4.4 No annotations or adaptions have been made to the messages in this chapter. 30 July 2012 MEFF 2012 117

9. Quote management 9.7 Definition of messages 9.7.1 Quote (Msg Type = S) Message sent by client to enter, modify or cancel a quote in the system Tag Name Req Valid values Format Description Standard Header Y MsgType = S 117 QuoteID Y String (10) Unique quote identifier. When it is a modification this field contains the quote identifier as in the original quote Start <Instrument> 55 Symbol Y Contract code String(22) Contract code When it is a modification or cancellation this field should contain the same value as in the original quote End <Instrument> 132 BidPx N Price Bid price. In a modification, if not specified, this field remains unchanged. In a cancellation it should contain zero 133 OfferPx N Price Ask price. In a modification, if not specified, this field remains unchanged. In a cancellation it should contain zero 134 BidSize N Qty Bid volume. In a modification this field must not be included. In a cancellation it should contain zero 135 OfferSize N Qty Ask volume. In a modification this field must not be included. In a cancellation it should contain zero 40 OrdType N 2 = Limit Char Quote type 59 TimeInForce N 0 = Day (default Char Indicates how long quote is valid value) Standard Trailer Y 30 July 2012 MEFF 2012 118

9. Quote management 9.7.2 Quote Cancel (Msg Type = Z) Message sent by the client to request the cancellation of quotes that meet certain selection criteria. Tag Name Req Valid values Format Description Standard Header Y MsgType = Z 117 QuoteID Y String (10) Unique identifier of this Quote Cancel Status Request message 298 QuoteCancelType Y 4 = Cancel All Int Quotes Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup 448 PartyID N String Member or Trader code whose quotes are to be cancelled 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader End <Parties> 295 NoQuoteEntries N 1 NumInGroup Start <Instrument> 55 48 22 461 200 Symbol Y [N/A] or contract code SecurityID N See table 21 in document Codification Tables for a list of possible values SecurityIDSource N 8 = Exchange Symbol CFICode N Fixed length. See 4.5.1 for a list of possible values MaturityMonthYear N YYYYMM or YYYYMMDD or YYYYMMwW End <Instrument> Standard Trailer Y Int String(22) String String String(6) Month-Year Indicates the role taken by the code specified in PartyID. Required if NoPartyIDs is specified Contract code. If it is [N/A] the quotes for all contracts matching the rest of criteria will be selected Underlying asset Required if SecurityID is specified Contract type Contract expiration 30 July 2012 MEFF 2012 119

9. Quote management 9.7.3 Quote Status Request (Msg Type = a) Message sent by the client to request status of quotes meeting certain selection criteria. Tag Name Req Valid values Format Description Standard Y MsgType = a Header 649 QuoteStatusReq ID N String(10) Identifier of the request. Present when the request is a Quote Status Request message Start <Instrument> 55 Symbol Y [N/A] or contract code 48 SecurityID N See table 21 in document Codification Tables for a list of possible values 22 SecurityIDSourc N 8 = Exchange e Symbol 461 CFICode N Fixed length. See 4.5.1 for a list of possible values 200 MaturityMonthYe ar N YYYYMM or YYYYMMDD or YYYYMMwW String(22) String String String(6) Month-Year Contract code.. If it is [N/A] the orders for all contracts matching the rest of criteria will be selected Underlying asset Required if SecurityID is specified Contract type Contract expiration End <Instrument> Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup 448 PartyID N String Member or Trader code owner of the quotes 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader End <Parties> Standard Trailer Y Int Indicates the role taken by the code specified in PartyID. Required if NoPartyIDs is specified 30 July 2012 MEFF 2012 120

9. Quote management 9.7.4 Quote Status Report (Msg Type = AI) Sent by MEFFGate to notify the status for a one or several quotes. It also notifies whether the request is accepted or rejected. Tag Name Req Valid values Format Description Standard Header Y MsgType = AI 649 QuoteStatusReqI D N String Identifier of the request. Present when the request is a Quote Status Request.. 117 QuoteID Y String QuoteID sent by the client in the Quote message 537 QuoteType N 1 = Tradeable Int Start <Parties> 453 NoPartyIDs N >0,<=2 NumInGroup PartyID N String Member or Trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char Required if NoPartyIDs is specified 452 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader Int Indicates the role taken by the code specified in PartyID. Required if NoPartyIDs is specified End <Parties> Start <Instrument> 55 Symbol Y Contract code String(22) Contract code for this quote End <Instrument> 1 Account N Fixed length String(5) Account code for this quote 132 BidPx N Price Bid price of the quote, as indicated in the Quote message 133 OfferPx N Price Ask price of the quote, as indicated in the Quote message 134 BidSize N Qty Bid volume of the quote, as indicated in the Quote message 135 OfferSize N Qty Ask volume of the quote, as indicated in the Quote message 40 OrdType N 2 = Limit Char Quote type 297 QuoteStatus N 0 = Accepted 4 = Canceled All 5 = Rejected 8 = Query Int Indicates the quote status. If rejected (value 5), there is an explanation in the Text field 9 = Quote not found 10 = Pending 58 Text N String If QuoteStatus = 5 (Rejected) there is an explanation of the rejection 60* TransactTime N UTCTimesta mp Time when transaction represented by this Quote Status Report occurred. This field is not present when QuoteStatus is equal to 10 552* NoSides N 1, 2 NumInGroup 54* Side N 1 = Buy Char 2 = Sell 198* SecondaryOrderID N String Identifier per side of the quote (one for the buyer and a different one for the seller), assigned by central system of MEFF or another exchange 527* SecondaryExecID N String Quote side history number, assigned by 30 July 2012 MEFF 2012 121

9. Quote management 39* OrdStatus N 0 = New 1 = Partially Filled 2 = Filled 4 = Cancelled 6 = Pending Cancel 8 = Rejected A = Pending New E = Pending Replace 103* OrdRejReason N 0 = Exchange option 3 = Order exceeds limit (price or volume filters) 12 = Surveillance option 99 = Other 100 = Disconnection of the client application 101 = Substituted by a new quote 102=Quote parameters missing 103=No permission to enter/manage quotes 104=Delta 151* Char Int central system of central system of MEFF or another exchange. Each time there is a new event in the life of the quote side (modification, trade or cancellation) is assigned a new value to this field. Indicates the current status of the buy side or the sell side of the quote Rejection or cancellation motive. Present when OrdStatus = 4 or 8 protection LeavesQty N Qty Quote volume pending of the buy side or the sell side of the quote. Standard Trailer Y Contains 0 when OrdStatus = 4 (Cancelled) 30 July 2012 MEFF 2012 122

9. Quote management 9.8 Delta protection and Account configuration for quotes 9.8.1 Introduction The FIX client uses this function to configure the values used by the MEFFGate the account configuration used in the Quote message and the delta protection for its quotes and orders These values are: Account Time period considered for delta protection Reasons for cancellation due to delta protection. Three limits, which act independently, can be configured during an established time period: o Total volume of traded contracts o Delta: abs[volume of (Calls buy + Puts sell + Futures buy) (Calls sell + Puts buy Futures sell)] o abs[total buy volume Total sell volume] VERY IMPORTANT NOTICE: From version 9.50 the delta protection functionality is available. 9.8.2 Delta Protection: Description Each FIX client can activate this protection for its quotes and orders, within an underlying asset and contract type, as follows: Time period considered for delta protection (between 1 and 60 seconds) Reasons for cancellation due to delta protection. Three limits, which act independently, can be configured during an established time period: o Total volume of traded contracts o Delta: abs[volume of (Calls buy + Puts sell + Futures buy) (Calls sell + Puts buy Futures sell)] o abs[total buy volume Total sell volume] When a value zero is configurated, MEFF central system will not control this specific concept. If the trader is not interested in delta protection, period of time for delta protection parameter has to be configured with a zero value. After each trade, a check is performed to ascertain if any of the three controls defined in the delta protection has been exceeded, in which case the MEFF central system will cancel all the trader s pending orders and quotes on this underlying asset and contract type, in order to protect from any order/quote executions on the fly. No new orders/quotes on this underlying asset and contract type on the same account will be admitted, until the MEFFGate client sends a new message re-establishing limits with RegistTransType [514] = 0 (New). Sending this message implies setting to zero trade counter in the corresponding underlying asset and contract type. 9.8.3 RegistID The field RegistID, present in a request initiated by a Registration Instructions message, is the identifier that relates to the request with Registration Instructions Response messages. The field RegistID assigned by the client should be ten characters length. If length is inferior, MEFFGate complete with spaces to achieve that length. MEFFGate also expects that messages sent by the client use an RegistID of 30 length, in this case only the last ten positions can be fixed free, since the 20 first should coincide with the format explained below. 30 July 2012 MEFF 2012 123

9. Quote management Message sending with RegistID unprefixed Client MEFFGate Registration Instructions RegistID = 10 Registration Instructions Response RegistID = 20 10 Registration Instructions Response RegistID =... Message sending with RegistID prefixed Client MEFFGate Registration Instructions RegistID = 20 10 Registration Instructions Response RegistID = 20 10 Registration Instructions Response RegistID =... - Assigning of the prefix to the RegistID identifier - A process in the MEFFGate of assigning a prefix to the RegistID field is performed to avoid duplicates in this identifier. The RegistID assigned by MEFFGate in the reply message has the format AAMMDDMmmmTttMmmmTttNnnnnnnnnn, made by the following codes: AAMMDD. It is the date of the clearing house session MmmmTtt. Contains the member and user code of connection from which the request was made Nnnnnnnnnn. It is the value assigned by the client application to AllocID in the original message A user who wants to modify or cancel a reference or a Give-up filter, must use this identifier in the field RegistRefID of the Registration Instructions request message. 30 July 2012 MEFF 2012 124

9. Quote management 9.8.4 List of messages Message Registration Instructions (Msg Type = o) Registration Instructions Response (Msg Type = p) Description Used by the client to manage the configuration of the Delta protection and Account configuration for quotes parameters Sent by MEFFGate to notify or reject the configuration of the Delta protection and Account configuration for quotes parameters request 9.8.5 Message flow Configuration of the quote parameters MEFFGate Client Registration Instructions ( o ) PartySubID [523] = QUOTE MEFFGate Server Registration Instructions Response ( p ) RegistStatus[506] = A (Accepted) Incorrect request MEFFGate Client Registration Instructions ( o ) PartySubID [523] = QUOTE MEFFGate Server Registration Instructions Response ( p ) RegistStatus[506] = R (Rejected) 30 July 2012 MEFF 2012 125

9. Quote management 9.8.6 Annotations and adaptations of FIX 4.4 In the Registration Instructions message, the fields NoPartyIDs (453) and NoPartySubIDs (802) are now required The field Text (58) has been added to the Registration Instructions Response message The block Instrument has been added as required to the Registration Instructions message The blocks Instrument and Stipulations have been added to the Registration Instructions Response message 30 July 2012 MEFF 2012 126

9. Quote management 9.8.7 Definition of messages 9.8.7.1 Registration Instructions (Msg Type = o) Message sent by the client to manage the configuration of the Delta protection and Account configuration for quotes for the futures and options of an underlying asset. Tag Name Req Valid values Format Description Standard Header Y MsgType = o 513 RegistID Y String Unique identifier for each Registration Instructions message 514 RegistTransType Y 0 = New Char 1 = Replace 2 = Cancel 508 RegistRefID N String Reference identifier for the RegistID (513) with Cancel and Replace RegistTransType (514) transaction types. Required if RegistTransType = 1 or 2 Start <Parties> 453 NoPartyIDs Y* 2 NumInGroup 448 PartyID Y String Member and Trader codes which acts this configuration 447 PartyIDSource Y D = Proprietary / Custom code String 452 802 523 803 PartyRole Y 13 = Order Origination Firm 11 = Order Origination Trader Int NoPartySubIDs Y* 1 NumInGroup PartySubID Y QUOTE = Delta protection and configuration of the quote account parameters String PartySubIDType Y Int This field is required by the standard. MEFFGate does not require this field to be present End <Parties> 1 Account Y* String (5) Account to be applied for the next quotes of futures or options of this underlying asset for this Member- Trader (Order Origination Firm-Order Origination Trader) Start <Instrument> 55* Symbol Y [N/A] String 48* SecurityID Y* See table 21 in String Underlying asset document Codification Tables for a list of possible values 22* SecurityIDSource Y* 8 = Exchange String Symbol 461* CFICode Y* FFXXSX String (6) Contract type OXXXXS FMXXXX End <Instrument> Start <Stipulations> 232* NoStipulations Y* NumInGroup StipulationType Y* TIMEDP= Period String 30 July 2012 MEFF 2012 127

9. Quote management 233* of time for delta protection VOLUMEMAX= Total volume of traded contracts ABSDELTAMAX = Resultant delta 234* DELTAMAX= Resultant net balance (buysell) StipulationValue Y* A numeric value, >= 0, no decimals String StipulationType = TIMEDP. This refers to the period of time to be applied for delta protection controls taking into account the futures and options of this underlying asset for this Member-Trader code (Order Origination Firm-Order Origination Trader). This is a value expressed in seconds (>1, <=60). If no control has to be applied, this field has to be filled with a 0 (zero). StipulationType = VOLUMEMAX. This refers to the total volume of traded contracts accumulated in the period of time established. These contracts correspond to the futures and options of this underlying asset and traded by this Member-Trader code (Order Origination Firm-Order Origination Trader). If no control has to be applied, this field has to be filled with a 0 (zero). StipulationType = ABSDELTAMAX. This refers to the resultant delta accumulated in the period of time established, for futures and options of this underlying asset and traded by this Member-Trader code (Order Origination Firm-Order Origination Trader). If no control has to be applied, this field has to be filled with a 0 (zero). End <Stipulations> Standard Trailer Y StipulationType = DELTAMAX. This refers to the resultant net balance (buy-sell) accumulated in the period of time established, for futures and options of this underlying asset and traded by this Member-Trader code (Order Origination Firm-Order Origination Trader). If no control has to be applied, this field has to be filled with a 0 (zero). 30 July 2012 MEFF 2012 128

9. Quote management 9.8.7.2 Registration Instructions Response (Msg Type = p) Message used by MEFFGate to indicate the status of the request initiated with the Registration Instructions message. This message is only sent to the user who made the request. Tag Name Req Valid values Format Description Standard Header Y MsgType = p 513 RegistID Y String Identifier assigned by the client in the Registration Instructions message 514 RegistTransType Y 0 = New Char 1 = Replace 2 = Cancel 508 RegistRefID N String Identifier of Registration Instructions message which is replaced or cancelled by this message. Included when RegistTransType = 1 or 2 Start <Parties> 453 NoPartyIDs N NumInGroup 448 PartyID N String Member and Trader codes which acts this configuration 447 PartyIDSource N D = Proprietary / Custom code String 452 802 523 803 PartyRole N 13 = Order Origination Firm 11 = Order Origination Trader Int NoPartySubIDs N 1 NumInGroup PartySubID Y QUOTE = Delta protection and configuration of the quote account parameters String PartySubIDType Y Int The content of this field should not be considered. It is included to meet requirements of the standard End <Parties> 1 Account N String Account to be applied for the next quotes of futures or options of this underlying asset for this Member- Trader (Order Origination Firm-Order Origination Trader) Start <Instrument> 55* Symbol Y [N/A] String 48* SecurityID N See table 21 in String Underlying asset document Codification Tables for a list of possible values 22* SecurityIDSource N 8 = Exchange String Symbol 461* CFICode N FFXXSX String (6) Contract type OXXXXS FMXXXX End <Instrument> Start <Stipulations> 232* NoStipulations N NumInGroup 233* StipulationType N TIMEDP= Period of time for delta String 30 July 2012 MEFF 2012 129

9. Quote management protection VOLUMEMAX= Total volume of traded contracts ABSDELTAMAX = Resultant delta 234* DELTAMAX= Resultant net balance (buysell) StipulationValue N String StipulationType = TIMEDP. This refers to the period of time to be applied for delta protection controls taking into account the futures and options of this underlying asset for this Member-Trader code (Order Origination Firm-Order Origination Trader). This is a value expressed in seconds (>1, <=60). If no control has to be applied, this field has to be filled with a 0 (zero). StipulationType = VOLUMEMAX. This refers to the total volume of traded contracts accumulated in the period of time established. These contracts correspond to the futures and options of this underlying asset and traded by this Member-Trader code (Order Origination Firm-Order Origination Trader). If no control has to be applied, this field has to be filled with a 0 (zero). StipulationType = ABSDELTAMAX. This refers to the resultant delta accumulated in the period of time established, for futures and options of this underlying asset and traded by this Member-Trader code (Order Origination Firm-Order Origination Trader). If no control has to be applied, this field has to be filled with a 0 (zero). StipulationType = DELTAMAX. This refers to the resultant net balance (buy-sell) accumulated in the period of time established, for futures and options of this underlying asset and traded by this Member-Trader code (Order Origination Firm-Order Origination Trader). If no control has to be applied, this field has to be filled with a 0 (zero). End <Stipulations> 506 RegistStatus Y A = Accepted R = Rejected Char Status of the Registration Instructions request message. If it contains the value R, there is an explanation for the rejection in the Text field 58* Text N String If RegistStatus = R there is an explanation of the rejection Standard Trailer Y 30 July 2012 MEFF 2012 130

9. Quote management 9.9 Parameters report for Delta protection and Account configuration for quotes 9.9.1 Description The client application can request a query of the Delta protection and Account configuration for quotes with a Registration Instructions message. In reply to this request, several Registration Instructions Response message are received (one for each underlying asset and contract type) available at this moment. 9.9.2 List of messages Message Registration Instructions (Msg Type = o) Registration Instructions Response (Msg Type = p) Description Used by the client to request the Delta protection and Account configuration for quotes parameters report Sent by MEFFGate to notify or reject the Delta protection and Account configuration for quotes parameters report request 9.9.3 Message flow Quote parameters report request MEFFGate Client MEFFGate Server Registration Instructions ( o ) SubscriptionRequestType = 0 (Snaphot) Registration Instructions Response ( p ) RegistStatus[506] = A (Accepted) Incorrect request MEFFGate Client MEFFGate Server Registration Instructions ( o ) SubscriptionRequestType = 0 (Snaphot) Registration Instructions Response ( p ) RegistStatus[506] = R (Rejected) 30 July 2012 MEFF 2012 131

9. Quote management 9.9.4 Annotations and adaptations of FIX 4.4 The field SubscriptionRequestType (263) has been added to the Registration Instructions message The fields LastRptRequested (912) and Text (58) have been added to the Registration Instructions Response message In the Registration Instructions message, the field NoPartyIDs (453) is now required The blocks Instrument and Stipulations have been added to the Registration Instructions Response message 30 July 2012 MEFF 2012 132

9. Quote management 9.9.5 Definition of messages 9.9.5.1 Registration Instructions (Msg Type = o) Message sent by the client to request the Delta protection and Account configuration for quotes parameters report. Tag Name Req Valid values Format Description Standard Header Y MsgType = o 513 RegistID Y String Unique identifier for each Registration Instructions message 514 RegistTransType Y Char Ignored by MEFFGate when SubscriptionRequestType[263] is specified Start <Parties> 453 NoPartyIDs Y* 2 NumInGroup 448 PartyID Y String Member and Trader codes which acts this configuration 447 PartyIDSource Y D = Proprietary / Custom code String 452 PartyRole Y 13 = Order Origination Firm 11 = Order Origination Trader End <Parties> 263* SubscriptionReques ttype Standard Trailer Int N 0 = Snasphot Char If this tag is specified indicates this is a request for all the existing quote parameters for this Member-Trader. In this case MEFFGate ignores the rest of the fields Y 30 July 2012 MEFF 2012 133

9. Quote management 9.9.5.2 Registration Instructions Response (Msg Type = p) Message used by MEFFGate to indicate the status of the request initiated with the Registration Instructions message. This message is only sent to the user who made the request. Tag Name Req Valid values Format Description Standard Header Y MsgType = p 513 RegistID Y String Unique identifier,assigned by the client, in the Registration Instructions message 514 RegistTransType Y 0 = New Char 912* LastRptRequested N Y = Last Boolean message N = Not last message Specific register information <Parties> Account <Instrument> <Stipulations> 506 RegistStatus Y A = Accepted R = Rejected Char Indicates the status for the Registration Instructions message. If rejected (value R ), there is an explanation in the Text field 58* Text N String If RegistStatus = R (Rejected) there is an explanation of the rejection Standard Trailer Y 30 July 2012 MEFF 2012 134

10. Cross trades 10. Cross trades 10.1 Introduction This chapter describes the mechanisms offered by MEFFGate FIX interface to manage the cross trades. This functionality allows members to request the registration of these cross trades on MEFF. In the cross trades between different members there are typically involved two members: one buy side and one sell side. They are entered in the system by one of the two members or an executing broker. The cross trade must be explicitly accepted by both the buy side and sell side members, furthermore, in certain circumstances, the Market Supervisor may also have to accept the cross trade. To request the register for a cross trade, the message Trade Capture Report is used. MEFFGate replies with a Trade Capture Report Ack message containing the same information as the Trade Captured Report received and including the trade status. Client systems of MEFFGate can subscribe the reception of Trade Capture Report messages using the Trade Capture Report Request message, which is replied by MEFFGate with a Trade Capture Report Request Ack message. The request may be just the current situation (snapshot) or include updates (snapshot + update). Client systems of MEFFGate can subscribe the reception of Trade Capture Report messages using the Trade Capture Report Request message, which is replied by MEFFGate with a Trade Capture Report Request Ack message. The request may be just the current situation (snapshot) or include updates (snapshot + update). Client systems of the MEFFGate, which have performed the relevant subscription, will receive a Trade Capture Report for each cross trade to be confirmed. It is not necessary to send as a response a Trade Capture Report Ack message; these messages are ignored by the MEFFGate. The client system can reject or accept a cross trade. When accepting the cross trade, the client code to which the cross trade is to be assigned has to be informed. This is done using the Trade Capture Report message to which the MEFFGate responds with a Trade Capture Report Ack. Each time a modification in the state of a cross trade is effected, MEFFGate, using a Trade Capture Report, will notify each of the parties involved: the buyer, the seller and, if present, the executing broker. Note that, MEFFGate only informs of the client account code or the reference to the interested parties (the buy side or sell side) Some cross trades, having been accepted by both parties, will need to be accepted also by Market Supervision. When Market Supervision accepts or rejects the cross trades, all the parties will receive a notification. Note that, for those cross trades which are in the end accepted, an Execution Report will be generated for each of the counterparties. 10.2 Entry of cross trades between different members There are three parties involved in these cross trades: the buyer and the seller in the cross trade, and the broker that sends the cross trade to MEFFGate. These cross trades are notified to MEFFGate using the Trade Capture Report message. Each of the parties is identified by the member and trader code. To identify a non-standard (flexible) contract, the following combination should be used in the cross trade functionality: SecurityID [48] + CFICode[461] + MaturityDate [541] + ContractMultiplier [231] + StrikePrice [202]. In this case, where appropiate, the central system will assign a new code following the existing rules and will populate these fields in all the messages associated (Trade Capture Report and Trade Capture Report Ack). 30 July 2012 MEFF 2012 135

10. Cross trades Once the cross trade has been sent to MEFFGate, it can be cancelled or modified by the sender, providing that it has not yet been accepted by any of the parties. Both the buyer and the seller can act as brokers, as well as an external member. This means there are four possible scenarios: Scenario Broker, buyer and seller are different members The buyer acts as broker The seller acts as broker The same member acts as buyer, seller and broker Identification of the parties in the message SenderCompID = Broking member code SenderSubID = Broking trader code Buyer PartyID = Buying member code Buyer PartySubID = Buying trader code Seller PartyID = Selling member code Seller PartySubID = Selling trader code SenderCompIDID = Buying member code SenderSubID = Buying trader code Buyer PartyID = Buying member code Buyer PartySubID = Buying trader code Seller PartyID = Selling member code Seller PartySubID = Selling trader code SenderCompID = Selling member code SenderSubID = Selling trader code Buyer PartyID = Buying member code Buyer PartySubID = Buying trader code Seller PartyID = Selling member code Seller PartySubID = Selling trader code SenderCompID = Member code SenderSubID = Trader code Buyer PartyID = Buying member code Buyer PartySubID = Buying trader code Seller PartyID = Selling member code Seller PartySubID = Selling trader code See 3.3 for more information on the use of the SenderCompID and SenderSubID fields. 10.3 Acceptance of cross trades between different members If the cross trade is finally accepted and executed, both the buyer and the seller receive the corresponding Execution Report messages (ExecType = F, Trade) notifying them of the execution of the cross trade. These messages will have the trader code corresponding to the one who accepted the cross trade. The CrossID field of the Execution Report message contains the SecondaryTradeReportID value assigned by the central host. As previously explained, when the cross trade is accepted and executed, the intermediary receives a Trade Capture Report message The Execution Report message allows the broker of the cross trade to be identified using the Entering Firm and Entering Trader roles in the Parties block (see 4.3 for more information on the Parties block). 10.4 Entry of cross trades within the member In this situation the confirmation for the sides involved is not necessary. 30 July 2012 MEFF 2012 136

10. Cross trades 10.5 Price and Effective amount The field GrossTradeAmt [381] indicates the effective amount. If informed, this value will be use instead of the rounded price. The System will determine the transaction price according to: Pr ecio _ trans Effective _ amount Volume multiplier and will be verified that this value Precio_trans is commensurate with the rounded price furnished by the client application in the field LastPx [31] of the Trade Capture Report message. If not, the cross trade will be rejected. 10.6 Cross trade groups and cash market cross trades Tag TradeLinkID [820] allows for the grouping of different cross trades on the same underlying into one single cross trade group. In this case, one of the trades may refer to the underlying contract. If this may be traded in SIBE, the cash market cross trade will be notified to the MEFF members and the SIBE members (Authenticating Member) who will be responsible for accepting of rejecting it. The final acceptance of the cash market cross trade is subject to the acceptance of some of the corresponding derivatives cross trades. 10.7 List of messages Message Trade Capture Report Request (Msg Type = AD) Trade Capture Report Request Ack (Msg Type = AQ) Trade Capture Report (Msg Type = AE) Trade Capture Report Ack (Msg Type = AR) Description Request for information on cross trades Acknowledgement of Trade Capture Report Request message Sent to MEFFGate to initiate, accept, reject or cancel a cross trade request about cross trades. Sent by MEFFGate to request the acceptance or rejection by the parties Sent by MEFFGate as Acknowledgement of Trade Capture Report message 30 July 2012 MEFF 2012 137

10. Cross trades 10.8 Message flow Request with update subscription, followed by subscription cancellation Gate Client Gate Server Trade Capture Report Request ( AD ) SubscriptionRequestType [263] = 1 (Snapshot+Updates) Trade Capture Report Request Ack ( AQ ) TotNumTradeReports [748] = 0 TradeRequestStatus [750] = 1 (Completed) Trade Capture Report ( AE )... One message for every trade in the snapshot Trade Capture Report ( AE )... One message for every update Trade Capture Report Request ( AD ) SubscriptionRequestType [263] = 2 (Unsubscribe) Request cross trades without update subscription, without cross trades that meet selection criteria When there are no cross trades that meet the selection criteria, the server sends a Trade Capture Report Request Ack message to notify the result of the request, with the value 0 in the TotNumTradeReports field. Gate Client Gate Server Trade Capture Report Request ( AD ) SubscriptionRequestType [263] = 0 (Snapshot) Trade Capture Report Request Ack ( AQ ) TotNumTradeReports [748] = 0 TradeRequestStatus [750] = 1 (Completed) 30 July 2012 MEFF 2012 138

10. Cross trades Request invalid cross trades When the clearing house cross trade request (Trade Capture Report Request message) is invalid, the request is rejected in a Trade Capture Report Request Ack message. Gate Client Gate Server Trade Capture Report Request ( AD ) SubscriptionRequestType [263] = 0 (Snapshot) Trade Capture Report Request Ack ( AQ ) TradeRequestStatus [750] = 2 (Rejected) A cross trade accepted (The buyer and the seller are the same member) Executing Broker Buyer and Seller Gate Server Trade Capture Report ( AE ) TradeReportType[856] = 0 (Submit) Trade Capture Report Ack ( AR ) TrdRprStatus[939] = 0 Trade Capture Report ( AE ) TradeReportTransType[487] = 0 (New) MatchType[574] = 8 Trade Capture Report ( AE ) TradeReportTransType[487] = 0 (New) MatchType[574] = 9 Execution Report ( 8 ) CrossID[548] = SecondaryTradeReportID Side [54] = 1 Execution Report ( 8 ) CrossID[548] = SecondaryTradeReportID Side [54] = 2 Cross trade request in Derivatives (entered by a member different than the buyer or the seller) The following diagram shows the message flow of a cross trade request entered by the Executing Broker, accepted first by the buy side and then by the sell side. Once the cross trade has been accepted by the Supervisor, the parties receive the corresponding Executing Report. 30 July 2012 MEFF 2012 139

10. Cross trades Buyer Executing Broker Trade Capture Report ( AE ) TradeReportType[856] = 0 (Submit) Trade Capture Report Ack ( AR ) Gate Server Seller TrdRprStatus[939] = 0 Trade Capture Report ( AE ) TradReportTransType[487] = 0 (New), MatchType[574] = 0 Trade Capture Report ( AE ) TradeReportType[856] = 2 (Accept) Trade Capture Report Ack ( AR ) TrdRprStatus[939] = 0 Trade Capture Report ( AE ) TradeReportTransType[487] = 2 (Replace), MatchType[574] = 1 Trade Capture Report ( AE ) TradeReportType[856] = 2 (Accept) Trade Capture Report Ack ( AR ) TrdRprStatus[939] = 0 Trade Capture Report ( AE ) TradeReportTransType[487] = 2 (Replace), MatchType[574] = 3 Trade Capture Report ( AE ) Accepted by Supervisor TradeReportTransType[487] = 2 (Replace), MatchType[574] = 8 Trade Capture Report ( AE ) TradeReportTransType[487] = 2 (Replace), MatchType[574] = 9 Execution Report ( 8 ) CrossID[548] = SecondaryTradeReportID Cash market cross trades request In this message flow it appears the figure of the Authenticating Firm, who accepts the transaction (in its bying or selling side). The buyer and seller receive information on the status of implementation at all times. 30 July 2012 MEFF 2012 140

10. Cross trades Authenticating Buyer Firm Authenticating Seller Firm Executing Broker Trade Capture Report ( AE ) TradeReportType[856] = 0 (Submit) Trade Capture Report Ack ( AR ) TrdRprStatus[939] = 0 Gate Server Seller Buyer Trade Capture Report ( AE ) TradReportTransType[487] = 0 (New), MatchType[574] = 0 Trade Capture Report ( AE ) TradeReportType[856] = 2 (Accept) Trade Capture Report Ack ( AR ) TrdRprStatus[939] = 0 Trade Capture Report ( AE ) TradeReportTransType[487] = 2 (Replace), MatchType[574] = 1 Trade Capture Report ( AE ) TradeReportType[856] = 2 (Accept) Trade Capture Report Ack ( AR ) TrdRprStatus[939] = 0 Trade Capture Report ( AE ) TradeReportTransType[487] = 2 (Replace), MatchType[574] = 3 Accepted by Supervisor Trade Capture Report ( AE ) TradeReportTransType[487] = 2 (Replace), MatchType[574] = 8 Trade Capture Report ( AE ) TradeReportTransType[487] = 2 (Replace), MatchType[574] = 9 Execution Report ( 8 ) CrossID[548] = SecondaryTradeReportID 30 July 2012 MEFF 2012 141

10. Cross trades 10.9 Annotations and adaptations of FIX 4.4 The Trade Capture Report Request only supports some of the selection criteria specified in the FIX standard Modifications of requests for the registering of cross trades is not supported. In the case of error, the old request must be cancelled and reenter a corrected new one The maximum number of allowable subscriptions alive is limited (see section 4.7 for details) 30 July 2012 MEFF 2012 142

10. Cross trades 10.10 Definition of messages 10.10.1 Trade Capture Report Request (Msg Type = AD) Message sent by the client to request information on cross trades; allows requests with or without new cross trade updates. Tag Name Req Valid values Format Description Standard Header Y MsgType = AD 568 TradeRequestID Y String (10) Identifier of the request assigned by the user. It must be a unique value when it is a new request, and the value previously assigned when it is for an unsubscription 569 TradeRequestType Y 0=All trades that match criteria Int 263 SubscriptionRequestType N 0=Snapshot (default value) 1=Snapshot + Updates 2= Unsubscribe Standard Trailer Y Char Indicates if it is a request with or without updates or the cancellation of a previous request 30 July 2012 MEFF 2012 143

10. Cross trades 10.10.2 Trade Capture Report Request Ack (Msg Type = AQ) Message used to notify that a Trade Capture Report Request message is invalid or no cross trade meets the selection criteria. Tag Name Req Valid values Format Description Standard Header Y MsgType = AQ 568 TradeRequestID Y String Identifier specified in the corresponding Trade Capture Report Request message 569 TradeRequestType Y Int Same value as specified in the request 263 SubscriptionRequestType N 0=Snapshot (default value) 1=Snapshot + Updates 2= Unsubscribe Char Same value as specified in the request 748 TotNumTradeReports N Int Number of trades that meet the selection criteria. 749 TradeRequestResult Y 0 = Successful 2 = Invalid TradeRequestTyp e 99=other 750 TradeRequestStatus Y 1 = Completed 2 = Rejected Int Int Result of request When the value is 99, there is an explanation in the Text field Request status. When an error is notified the value is 2. When there are no cross trades that meet the selection criteria the value is 1 58 Text N String An explanation of the rejection reason is given Standard Trailer Y 30 July 2012 MEFF 2012 144

10. Cross trades 10.10.3 Trade Capture Report (Msg Type = AE) sent to MEFFGate Message containing data for the registering on a cross trade. Tag Name Req Valid values Format Description Standard Header Y MsgType = AE 571 TradeReportID Y String (10) Unique identifier for each Trade Capture Report message. Unique per FIX session. 856 TradeReportType Y* 0 = Submit 2 = Accept 3 = Decline 6 = Trade Report Cancel Int Type of Trade Report.: 0 (Submit): This is the value indicated by the initiator when he sends the initial cross trade request 2 (Accept): Used by one counterparty to accept a cross trade 3 (Decline): Used by one counterparty to reject a cross trade 6 (Cancel): This is the value to indicate by the initiator to cancel the initial cross trade request 820 TradeLinkID N String Used by the MEFFGate client to associate a group of cross trades together 570 PreviouslyReported Y N,Y Boolean Indicates if the cross trade was notified to the counterparty 881 SecondaryTradeReportRefID N String Required except for the initial cross trade request. It must contain the value received from MEFFGate in the field SecondaryTradeReportID [818] of the Trade Capture Report or Trade Capture Report Ack messages. Start <Instrument> 55 Symbol Y Contract code, [N/A] 48 SecurityID N See table 21 in document Codification Tables for a list of possible values 22 SecurityIDSource N 8 = Exchange symbol 461 CFICode N Exact length See table 16 in document Codification Tables for a list of values String(22) String This is the cross trade request unique identifer through its whole life. Contract code or [N/A] Underlying asset String Required if SecurityID [48] is present. String(6) Contract type in accordance with the ISO 10962 standard 30 July 2012 MEFF 2012 145

10. Cross trades 541 MaturityDate N LocalMkt Expiration date Date 202 StrikePrice N Price Exercise price. Only present for options 231 ContractMultiplier N Float Conversion factor between price units and monetary units End <Instrument> 32 LastQty Y >= 0, no decimals Qty Volume bought/sold in the cross trade described. 31 LastPx Y Price Average price in the cross trade described. If this cross trade is expressed through an effective amount, GrossTradeAmt [381], this is the rounded transaction price. 552 NoSides Y 1, 2 NumInGr oup 54 Side Y 1 = Buy 2 = Sell Char Position that the party takes in the cross trade. 37 OrderID Y NONE String Start <Parties> Not needed in a cross trade within the member 453 NoPartyIDs N NumInGr Number of parties oup PartyID N String Member or trader code 448 447 PartyIDSource N D = Proprietary/ Custom code Char Present if NoPartyIDs has been specified 452 Int 80 2 523 803 PartyRole N 4 = Authenticating Firm 13 = Order Origination Firm 11 = Order Origination Trader 7 = Entering Firm 36 = Entering Trader NoPartySubIDs N NumInGr oup Indicates the role taken in the PartyID code specified. Present if NoPartyIDs has been specified. The Authenticating Firm (PartyRole=4) is only needed on cash market trades. Number of sub-identifiers. This sub-group is only present when PartyRole [452] = 11 PartySubID N String Phone number and contact name of the buyer/seller order origination trader PartySubIDType N 7 = Phone int number 9 = Contact name End <Parties> 1 Account N String Derivatives: Account code Cash market: Client account code 581 AccountType N 1 = On behalf of third parties 3 = House trader Int Capacity indicator (only for cash market trades) 381 GrossTradeAmt N Amt Effective amount. If informed, this value will be use instead of the price (LastPx [31]). It must be the same for the buying and selling party. 30 July 2012 MEFF 2012 146

10. Cross trades 58 Text N String(15) Reference Standard Trailer Y 30 July 2012 MEFF 2012 147

10. Cross trades 10.10.4 Trade Capture Report (Msg Type = AE) sent by MEFFGate Message containing data on a trade pending on registration and used to request the acceptance or rejection by the member Tag Name Req Valid values Format Description Standard Header Y MsgType = AE 571 TradeReportID Y String Unique identifier for each Trade Capture Report message 568 TradeRequestID N String Identifier of the subscription request used in the Trade Capture Report Request. message 487 TradeReportTransType N 0 = New 1 = Cancel 2 = Replace Int 0 (New): Indicates an initial cross trade request 1 (Cancel):Indicates the cross trade request has been cancelled 2 (Replace): Indicates the cross trade request has been modified (i.e. because has been accepted by the member counterparty) 912 LastRptRequested N Boolean Indicates if it is the last message of the snapshot reply to a request made with a Trade Capture Report Request message 325 UnsolicitedIndicator N N = The message is part of a snapshot Y = The message is sent as result of an update Boolean Contains Y when the message is sent as the result of a subscription 820 TradeLinkID N String Identifier sent by the MEFFGate client to associate a group of cross trades together 570 PreviouslyReported Y N,Y Boolean Indicates if the cross trade was notified to the counterparty 818 SecondaryTradeReportID N String Cross trade request unique identifer assigned by MEFF. The Trade Capture Report messages, sent by the client application to accept or reject the cross trade request, must reference this information in the field SecondaryTradeReportRefI D [881] Start <Instrument> 55 Symbol Y Contract code String(22) Contract code 48 SecurityID N See table 21 in String Underlying asset document Codification Tables for a list of possible values 22 SecurityIDSource N 8 = Exchange symbol String 30 July 2012 MEFF 2012 148

10. Cross trades 461 CFICode N Exact length See table 16 in document Codification Tables for a list of values String(6) 541 MaturityDate N LocalMkt Date Contract type in accordance with the ISO 10962 standard Expiration date 202 StrikePrice N Price Exercise price 231 ContractMultiplier N Float Conversion factor between price units and monetary units End <Instrument> 32 LastQty Y Qty Volume bought/sold in the cross trade described. 31 LastPx Y Price Average price in the cross trade described. If this cross trade is expressed through an effective amount, GrossTradeAmt [381], this is the rounded transaction price. 574 MatchType N 0 = Awaiting approval by both sides (buyer and seller) 1 = Awaiting approval by the sell side 2 = Awaiting approval by the buy side 3 = Awaiting approval by Market Supervision 4 = Cancelled 5 = Rejected by the sell side 6 = Rejected by the buy side 7 = Rejected by Market Supervision 8 = Accepted 9 = Registered A = Cancelled by the system B = Rejected by the system String 552 NoSides Y 2 NumInGr oup 54 Side Y 1 = Buy Char 2 = Sell 37 OrderID Y NONE String Start <Parties> 453 NoPartyIDs N NumInGr oup 448 PartyIDSource N D = Proprietary/ Char 447 Custom code 452 Describes the cross trade state Position that the party takes in the cross trade Number of parties PartyID N String Member or trader code PartyRole N 4 = Authenticating Firm Int Required if NoPartyIDs has been specified Indicates the role taken in the PartyID code specified. 30 July 2012 MEFF 2012 149

10. Cross trades 80 2 523 803 13 = Order Origination Firm 11 = Order Origination Trader 7 = Entering Firm 36 = Entering Trader NoPartySubIDs N NumInGr oup Present if NoPartyIDs has been specified Number of sub-identifiers. This sub-group is only present when PartyRole [452] = 11 PartySubID N String Phone number and contact name of the buyer/seller order origination trader PartySubIDType N 7 = Phone int number 9 = Contact name End <Parties> 1 Account N String Derivatives: Account code Cash market: Client account code 581 AccountType N 1 = On behalf of third parties 3 = House trader Int Capacity indicator (only for cash market trades) 381 GrossTradeAmt N Amt Effective amount. This value is use instead of the price (LastPx [31]) 58 Text N String(15) Reference Standard Trailer Y 30 July 2012 MEFF 2012 150

10. Cross trades 10.10.5 Trade Capture Report Ack (Msg Type = AR) Message used by MEFFGate as reply to a Trade Capture Report message. It contains the same information as the Trade Captured Report received, including the trade registration number assigned by the central host, the indication if the cross trade was accepted or rejected and the reason for rejection. Tag Name Req Valid values Format Description Standard Header Y MsgType = AR 571 TradeReportID Y String Contains the same information as the corresponding Trade Capture Report 487 TradeReportTransTy pe N 0 = New 1 = Cancel 2 = Replace 856 TradeReportType N 0 = Submit 2 = Accept 3 = Decline 6 = Trade Report Cancel 818 SecondaryTradeRepo rtid Int Int Contains the same information as the corresponding Trade Capture Report Contains the same information as the corresponding Trade Capture Report N String Trade registration number assigned by the central host. This number is kept during the whole trade history. 820 TradeLinkID N String Identifier sent by the MEFFGate client to associate a group of cross trades together 939 TrdRptStatus N 0 = Accepted 1 = Rejected 751 TradeReportRejectRe ason N 0 = Successful (Default) 1 = Invalid party information 2 = Unknown instrument 3 = Unauthorized to report trades 4 = Invalid trade type Int Trade Report Status. Indicates if the Trade Capture Report was accepted or not by MEFF Identifies the reason for rejection. Only present when TrdRptStatus [939] = 1 4000 = Incorrect SecondaryTradeReportR efid 4001 = Invalid effective amount 4002 = Invalid price 4003 = Invalid security 4004 = Invalid counterparty member 4005 = Account inactive 4006 = Not valid request 4007 = Invalid Side 4008 = Invalid Account 4010 = Invalid GrossTradeAmt Start <Instrument> 55 Symbol Y Contract code String(22) Contains the same information as the corresponding Trade Capture Report 48 SecurityID N See table 21 in document String Underlying asset Codification Tables for a list of possible values 22 SecurityIDSource N 8 = Exchange symbol String 30 July 2012 MEFF 2012 151

10. Cross trades 461 CFICode N Exact length See table 16 in document Codification Tables for a list of values String(6) 541 MaturityDate N LocalMktD ate Contract type in accordance with the ISO 10962 standard Expiration date 202 StrikePrice N Price Exercise price 231 ContractMultiplier N Float Conversion factor between price units and monetary units End <Instrument> 32 LastQty Y Qty Contains the same information as the corresponding Trade Capture Report 31 LastPx Y Price Contains the same information as the corresponding Trade Capture Report 552 NoSides Y 2 NumInGro up Always 2. Both parties are specified (buyer and seller) 54 Side Y 1 = Buy 2 = Sell Char Position that the party takes in the cross trade 37 OrderID Y NONE String Start <Parties> 453 NoPartyIDs N NumInGro Number of parties up 44 PartyID N String Member or trader code 8 44 7 PartyIDSource N D = Proprietary/ Custom code Char Present if NoPartyIDs has been specified 45 2 80 2 523 803 PartyRole N 4 = Authenticating Firm 13 = Order Origination Firm 11 = Order Origination Trader 7 = Entering Firm 36 = Entering Trader Int NoPartySubIDs N NumInGro up Indicates the role taken in the PartyID code specified. Present if NoPartyIDs has been specified Number of sub-identifiers. This sub-group is only present when PartyRole [452] = 11 PartySubID N String Phone number and contact name of the buyer/seller order origination trader PartySubIDType N 7 = Phone number int 9 = Contact name End <Parties> 1 Account N String Derivatives: Account code Cash market: Client account code 581 AccountType N 1 = On behalf of third parties 3 = House trader Int Capacity indicator (only for cash market trades) 381 GrossTradeAmt N Amt Effective amount.. Contains the same information as the corresponding Trade Capture Report. 58 Text N String(15) Contains the same information as the corresponding Trade Capture Report 30 July 2012 MEFF 2012 152

10. Cross trades Standard Trailer Y 30 July 2012 MEFF 2012 153

11. Communication of Events 11. Communication of Events 11.1 Introduction This chapter describes two functionalities based on the News message: Relay information from the market supervisor to one or more traders Send messages of a trader to the market supervisor In both cases the information transferred has a free text format. A client program does not need to subscribe to receive these messages. Every client is implicitly subscribed from the start of the session. On establishing a communications connection, if the client continues the FIX session he will receive all the pending News messages from the time of disconnection. When the client opts to begin a new FIX session, he receives all the News messages addressed to him that have been generated from the start of the session. 11.2 List of messages Message News (Msg Type = B) Description Used to receive text messages from the market supervisor. Also used to send text messages to the market supervisor 11.3 Message flow Message reception MEFFGate Client MEFFGate Server News ( B ) Sending message MEFFGate Client MEFFGate Server News ( B ) 11.4 Annotations and adaptations of FIX 4.4 Only one line of up to 78 characters per message is allowed 30 July 2012 MEFF 2012 154

11. Communication of Events 11.5 Definition of messages 11.5.1 News (Msg Type = B) Tag Name Req Valid values Format Description Standard Header Y MsgType = B 61 Urgency N 0 = Normal Char The default value is 0 1 = Flash 2 = Background 148 Headline Y String Message header. Ignored by MEFFGate 33 LinesOfText Y 1 NumInGroup Number of lines of text. Only one line allowed 58 Text Y String(78) One line of text Standard Trailer Y 30 July 2012 MEFF 2012 155

Appendix A. MEFF Order Types Appendix A MEFF Order Types The following table sets out the different order types on MEFF with the FIX OrdType and TimeInForce fields. MEFF Order Type OrdType TimeInForce Allows instructions for automatic cancellation in the event of a disconnection Limit order Limit (2) Day (0) YES Immediate limit order Limit (2) IOC (3) NO Market order (*) Market (1) Day (0) YES Market (1) IOC (3) YES Stop order Stop (3) Day (0) NO Stop limit order Stop Limit (4) Day (0) YES Fill or kill order Limit (2) FOK (4) NO Auction price order Market(1) At Opening(2) YES (*)The market order accepts two different combinations of values in the OrdType and TimeInForce fields. Irrespective of the TimeInForce value used, the market order behaviour is determined by the MEFF rules stated in the corresponding notices. 30 July 2012 MEFF 2012 A-1

Appendix B. User Fields Appendix B User Fields The following table shows the user fields that are found in the messages of this manual Tag Name Format Description 5680 ProprietaryFixProtocolVersion String Identification of the version of the protocol used and expected by the initiator. 5679 FixEngineName String Contains a descriptive chain of software used by the client for the FIX connection. Only used for informative purposes 5681 ExchangeTradeType String Exchange trade type (see table 19 in document Codification Tables 5682 NewSecuritySubscription Char Field to request subscription to the definition of new contracts 30 July 2012 MEFF 2012 B-1