BME Data Feed Interface Specifications. Version: Related to: BME Data Feed Release 13.0

1.1 BME Data Feed s Document Name: BME Data Feed s Version: 3.00 Related to: BME Data Feed Release 13.0 Last Updated

BME Data Feed s Page 2 of 2 REVISION HISTORY This section refers to the major changes of this version in comparison to the previous version. Version Date Comments 1.0 1.01 1.02 01.01.2009 First cut 21.10.2009 03.12.2012 1.03 03.0.2013 2.00 22.08.2014 3.00 28.07.2017 Several updated special requests in whole document additional value for Open Outcry in App. G+H Changed FID for field NEWS_ID. Graphics and text correction. Correction on section 5.15 Message - Remove Watch by Product Request. Revised Appendixes G and H Introduction of extended time resolution principles. Ch 3.7 Changed format and additional processing of MICRO and NANO seconds time stamps. Higher time resolution information. Ch. 5.1, 5.2, 5.6, 5.9, 5.11 Added Request codes. App D, App. E.3, E.3.1, E.3.2, E.3.3, App F. Updated fields in Listing Identification Folder. Ch. 5.14 and 5.23 Revised Appendixes D, G and H Relation between BME Data Feed Source ID and and MIC Code (ISO 10383). Added DNUM Special Values and Examples E.5.1 and E.5.2. Added new Date and Time format in Table 2-1 Data Type Definition for Fixed Length Field. See also E.3 Date and Time.Added Appendixes J and I.

BME Data Feed s Page 3 of 3 TABLE OF CONTENTS 1 INTRODUCTION...7 1.1 HOW TO USE THIS SPECIFICATION GUIDE...7 1.2 RELEVANT DOCUMENTS...7 2 COMMUNICATION INTERFACE...8 2.1 PRIVATE TCP/IP NETWORK...8 2.2 TCP DELIVERY...9 2.3 IP ADDRESS AND PORT NUMBER...9 2.4 BACKUP SYSTEM...10 3 BASIC CONCEPTS... 11 3.1 RELATION BETWEEN BME DATA FEED SOURCE ID AND AND MIC CODE (ISO 10383)...11 3.2 REQUEST / RESPONSE STYLE...11 3.3 MESSAGE-DRIVEN PROTOCOL...12 3.4 CONNECTION MODE...12 3.4.1 Broadcast Mode... 13 3.4.2 Interactive Mode... 13 3.4.3 Mixed Mode... 13 3.5 USER ENTITLEMENT...13 3.6 DELIVERY MODE...14 3.6.1 Tick-by-Tick Mode... 14 3.6.2 Refresh Mode... 14 3.7 MESSAGE RECOVERY...15 3.8 TIME RESOLUTION...16 4 PROCESSING LOGIC... 17 4.1 USER STATES...17 4.2 LOGIN TO THE SYSTEM...21 4.3 LOGOUT BY USER...23 4.4 FORCED LOGOUT BY SYSTEM...24 4.5 PROCESS BROADCAST DATA...24 4.6 INTERACTIVE REQUEST/ REPLY...26 4.6.1 Add Watch by Product... 26 4.6.2 Cancel News Retrieval... 28 4.6.3 Remove Watch by Product... 29 4.6.4 Retrieve News by Time... 30 4.6.5 Retrieve Static Data... 32 4.6.6 Retrieve Static Data by Time... 34 5 MESSAGE DESCRIPTION... 35 5.1 GENERAL MESSAGE STRUCTURE...35 5.1.1 Folder/Field Organisation... 36 5.1.2 Folder/Field Structure... 37 5.2 BME DATA FEED MESSAGE STRUCTURE...41 5.3 MESSAGE - ADD WATCH BY PRODUCT REQUEST...43 5.4 MESSAGE - CANCEL INSTRUMENT DATA RETRIEVAL REQUEST...44 5.5 MESSAGE - CANCEL NEWS RETRIEVAL REQUEST...45

BME Data Feed s Page 4 of 4 5.6 MESSAGE - DATA REQUEST ACKNOWLEDGEMENT DATA...46 5.7 MESSAGE - HEARTBEAT DATA...48 5.8 MESSAGE - LOGIN ACKNOWLEDGEMENT DATA...49 5.9 MESSAGE - LOGIN REQUEST...50 5.10 MESSAGE - LOGOUT ACKNOWLEDGEMENT DATA...52 5.11 MESSAGE - LOGOUT REQUEST...53 5.12 MESSAGE - MESSAGE RECOVERY REQUEST...54 5.13 MESSAGE - REFRESH NEWS DATA...55 5.14 MESSAGE - REFRESH QUOTE LISTING DATA...56 5.15 MESSAGE - REMOVE WATCH BY PRODUCT REQUEST...57 5.16 MESSAGE - RESUME BROADCAST REQUEST...58 5.17 MESSAGE - RETRIEVE NEWS BY TIME REQUEST...59 5.18 MESSAGE - RETRIEVE STATIC DATA BY TIME REQUEST...60 5.19 MESSAGE - RETRIEVE STATIC DATA REQUEST...61 5.20 MESSAGE - STATIC REFRESH INSTRUMENT DATA...62 5.21 MESSAGE - SYSTEM LOGOUT DATA...63 5.22 MESSAGE - SYSTEM STATE DATA...64 5.23 MESSAGE TICK-BY-TICK LISTING DATA...65 5.24 MESSAGE TICK-BY-TICK NEWS DATA...67 APPENDIX A - REQUEST MESSAGES SUMMARY... 68 APPENDIX B - DATA MESSAGES SUMMARY... 69 APPENDIX C - SYSTEM FOLDER LIST... 70 APPENDIX D - SYSTEM FIELD DEFINITION... 71 APPENDIX E - DATA VALUE PRESENTATION... 76 E.1 BOOLEAN...76 E.2 BYTE STREAM...76 E.3 DATE AND TIME...76 E.3.1 BCD DATE TIME...76 E.3.2 BCD TIME...78 E.3.3 BME DATA FEED REQUETS...80 E.4 CHAR...80 E.5 DNUM...80 E.5.1 SPECIAL VALUES...82 E.5.2 EXAMPLES...82 E.6 INTEGER...83 E.7 NETWORK BYTE ORDER...83 E.8 STRING...83 APPENDIX F - MESSAGE FOLDERS - CONSTANT VALUES TABLE... 84 APPENDIX G - INSTRUMENT TYPE (SORTED BY VALUE)... 86 APPENDIX H - INSTRUMENT TYPE (SORTED BY DESCRIPTION)... 87 APPENDIX I - LOGIN EXAMPLE... 88 APPENDIX J - LISTING IDENTIFICATION FOLDER... 90

BME Data Feed s Page 5 of 5 TABLES Table 1-1 BME Data Feed relevant Documents...7 Table 4-1 User State Transition...18 Table 5-1 MLB Bits Value...36 Table 5-2 Field GRP Definition...37 Table 5-3 Data Type Definition for Fixed Length Field...38 Table 5-4 Data Type Definition for Variable Length Field...39 Table 5-5 Layout of a Message ID Folder...41 Table 5-6 All available Message IDs supported by the BME Data Feed System...42 Table A-1 Possible requests made by users that are logged on...68 Table B-1 Possible messages sent to users that are logged on...69 Table C-1 System Folder List...70 Table D-1 Field ID Definition...71 Table E-1 Boolean Value Definition...76 Table E-2 Data Types for Date Time Representation...80 Table E-3 Decimal Number Data Types...81 Table E-4 Special Values for Decimal Number Data Types (see IEEE 754)...82 Table E-5 Examples of DNUMs...82 Table E-6 Integer Data Types...83 Table E-7 Code Set Definition...83

BME Data Feed s Page 6 of 6 FIGURES Figure 2-1 Private TCP/IP Network...8 Figure 2-2 TCP Delivery...9 Figure 2-3 Production Configuration...10 Figure 3-1 Response & Response Style...11 Figure 3-2 Message Structure...12 Figure 4-1 User State Transition...17 Figure 4-2 Login to the System...21 Figure 4-3 Logout by User...23 Figure 4-4 Forced Logout by System...24 Figure 4-5 Process Broadcast Data...25 Figure 4-6 Add Watch by Product...26 Figure 4-7 Cancel News Retrieval...28 Figure 4-8 Remove Watch by Product...29 Figure 4-9 Retrieve News by Time...30 Figure 4-10 Retrieve Static Data...32 Figure 4-11 Retrieve Static Data by Time...34 Figure 5-1 Basic Message Structure...35 Figure 5-2 Message Length Structure...35 Figure 5-3 MLB-1 Structure...35 Figure 5-4 Folder/Field Organisation...36 Figure 5-5 Field/Folder Structure...37 Figure 5-6 Field Header Structure...37 Figure 5-7 Example of a Block Length Field...40 Figure 5-8 General Structure of a BME Data Feed Message...41 Figure E-1 Decimal Number Structure...81

BME Data Feed s Page 7 of 7 2 Introduction This document provides a complete technical overview on the communication interface, message format and handling conventions for processing data from BME Data Feed. BME Data Feed is used by Bolsas y Mercados Españoles (hereinafter referred to as BME) as data dissemination system (hereinafter referred to as the BME Data Feed System) for the dissemination of real-time price data to external users. The BME Data Feed is an entitlement-driven Feed transmitted via TCP/IP and point-to-point connections. It enables users to receive different types of real-time price data from different data sources in a single Feed. By subscribing to BME Data Feed information products, users are able to control what type of data they wish to receive from the Feed. Data can be delivered either in broadcast mode, interactive mode or in mixed mode. Different data quality options are available to suit different users need: tick-by-tick or periodic refresh. The Feed also provides data recovery support to users for restoring data that was lost due to an unexpected event, such as a communication breakdown. 2.1 How to use this specification guide Chapter 1 contains a table of contents with a short introduction and references to related documents. Chapter 2 describes the communication interface with which users are connected to the dissemination system. Chapter 3 describes the basic concept of BME Data Feed. Chapter 4 describes the general processing logic of how to make a data request and how to process responses. Chapter 5 describes in greater detail how to handle messages. Appendices at the end of the document provide a quick reference to useful data. 2.2 Relevant Documents Table 2-1 BME Data Feed relevant Documents Item Document 1 BME Data Feed Fields and Products 2 BME Data Feed Fields and Products Guidelines 3 BME Data Feed Compression Guidelines

BME Data Feed s Page 8 of 8 3 Communication Interface This section describes the communication interface that connects users to the BME Data Feed System. 3.1 Private TCP/IP Network The current BME Data Feed System as set up by BME allows users to connect through leased lines (main and backup line). To establish a TCP/IP connection via Leased Line, users are required to set up appropriate TCP/IP communication equipment on their side. BME Data Feed System Network TCP/IP on leased line BME User User X Figure 3-1 Private TCP/IP Network

BME Data Feed s Page 9 of 9 3.2 TCP Delivery In order to access the BME Data Feed content, users have to establish a TCP connection to the BME Data Feed System. Once a connection is established, Feed data flows through this connection until the connection is interrupted. BME Data Feed System TCP Connection User X Figure 3-2 TCP Delivery 3.3 IP Address and Port Number In order to connect to the BME Data Feed System, users need to obtain a valid IP address and TCP port number from BME. BME may assign different IP addresses to different users. When connecting to the BME Data Feed System, users should always continue to use their assigned IP addresses, otherwise the system may reject their connection requests. A fixed TCP port number is used for the BME Data Feed. To avoid conflicts with existing registered ports, the assigned port number lies within the range of temporary ports outside the Internet Assigned Numbers Authority s (IANA) registered ports range.

BME Data Feed s Page 10 of 10 3.4 Backup System There are two systems for backup purposes, running in different physical locations, which offer an identical level of service in parallel. Users will be given TWO IP addresses with which they can connect to the BME Data Feed System: 1 st IP address for connecting to Primary BME Data Feed System 2 nd IP address for connecting to Secondary BME Data Feed System Users are advised to design their application and configure their communication in such a way to allow for switching connections between these two sites whenever they need to. Recommendation: As BME Data Feed provides identical data streams via both BME Data Feed Systems, users shall connect to both BME Data Feed Systems in parallel with 2 users, using one of the 2 connections as primary data source. In case of an outage of the connection, which is used as primary data source, users shall switch to the second one as primary data source. No matter which of the 2 connections has an outage, the user shall try to reestablish the connection on this side as fast as possible. In the event that a connection to one BME Data Feed System cannot be established, users should switch with both userids to the BME Data Feed System that is available. Primary BME Data Feed System Secondary BME Data Feed System Private TCP/IP Network User X Figure 3-3 Production Configuration

BME Data Feed s Page 11 of 11 4 Basic Concepts 4.1 Relation between BME Data Feed Source ID and and MIC Code (ISO 10383) Within the BME Data Feed system, the so called SOURCE_NAME field will be delivered / handled to identify Listings with their trading venue. In many cases, the BME SOURCE_NAME is derived from the Market Identifier Code (MIC) as defined in ISO 10383. But: The BME Data Feed field SOURCE_NAME is not identical to the ISO MIC Code, so both fields are not comparable. 4.2 Request / Response Style The BME Data Feed supports a wide range of data requests. Chapter 4 provides a general description of the required processing logic on how to issue requests and handle responses. Requests and responses in the Feed take on the shape of BME Data Feed Messages. To make a request users have to send a message containing the appropriate request data, in a specific message layout. Upon completion, the BME Data Feed System transmits to users another message with the relevant response data in a different message layout. In both cases, users need to be very familiar with the structure of these types of messages and must know which data is stored inside which layout. This part is fully covered in chapter 5. BME Data Feed System Request Response User X Figure 4-1 Response & Response Style

BME Data Feed s Page 12 of 12 4.3 Message-Driven Protocol The BME Data Feed adopts a message-driven protocol to control the exchange of data between the BME Data Feed System and its users. Messages are the basic communication unit. The protocol specifies rules on how messages are formatted and exchanged. The data inside a message is structured into folders and fields. A folder is a collection of related fields (or folders). A field contains the actual data with a description on how the data is stored. Data inside a message can be accessed by accessing the correct field in the relevant folder. Details with respect to the identification of folders and fields are provided in chapter 5.1, further information about folder structuring in chapter 5.1.1. Important hint: the sequence of fields within a folder is never guaranteed. Thus, all examples for fields within a folder in this document only describe one possible sequence. Message Folder Folder Field Field Folder Folder Field Field Field Field Field Figure 4-2 Message Structure 4.4 Connection Mode The BME Data Feed System supports the following connection modes: Broadcast Mode Interactive Mode Mixed Mode Different connection modes control the type of requests that can be sent to the System, as well as the possible responses returned by the System. The connection mode is a pre-defined setting in the user s entitlement profile. The BME Data Feed System automatically determines the relevant connection mode for a user as soon as the connection has been established.

BME Data Feed s Page 13 of 13 4.4.1 Broadcast Mode In Broadcast Mode, users receive directly data according to their entitled products. They have also the possibility to send recovery requests by time and date as well as outbound message keys. By referring to the user s entitlement profile, the BME Data Feed System is able to determine what data the user receives from the data feed. 4.4.2 Interactive Mode Interactive Mode gives users control over their entitled products. After login, they need to select the desired BME Data Feed products they want to receive from the BME Data Feed. For reference, see chapter Add watch by product request. They have also the possibility to send recovery requests by time and date as well as outbound message keys. The BME Data Feed System will not transmit any unrequested data. The BME Data Feed System has implemented the User Request Throttling mechanism to ensure that a single user is blocked from transmitting a flood of requests. When the limit is exceeded, the excessive requests will be suspended for service and it will take a long time before the user receives any reply. This does not affect other users and, unless a user tries to flood the BME Data Feed System intentionally, such incidents should occur rarely. 4.4.3 Mixed Mode As is the case with Broadcast Mode, the BME Data Feed System automatically determines and transmits the type of data requested by the user in Mixed Mode based on his entitlement profile. Users do not need to issue any request for the data. They also have the possibility to send recovery requests by time and date as well as outbound message keys. Mixed Mode users are given the option of defining the watch list of a session by reducing it on Product level. They have to provide a Remove Watch by Product Request in this case. They are allowed to make use of Add Watch by Product Request as well. Similar to Interactive Mode, the BME Data Feed System will guard the Feed against a flood of requests by applying the User Request Throttling mechanism (for details please refer to the previous section). 4.5 User Entitlement The BME Data Feed can supply many different types of price data from many different sources. Users may select the type of data they wish to receive from their own Feed connection. To do this, they must only subscribe to the information products that they are interested in. When processing the customer's login request, the BME Data Feed System uses the identification to check on the user s entitlement profile and determine the type of data that the user who has just logged on is allowed to receive.

BME Data Feed s Page 14 of 14 4.6 Delivery Mode User entitlement also determines the quality of the data that users are entitled to receive. There are different types of data quality, which are controlled by the Delivery Mode concept. Price data can be delivered to users in any one of the following modes: Tick-by-Tick Mode Refresh Mode The following sections provide more details on each mode. 4.6.1 Tick-by-Tick Mode When data is delivered in tick-by-tick mode, every update or change in a field is transmitted immediately to users in their chronological order. Tick-by-Tick is applied for Trade prices, order book information and indices. 4.6.2 Refresh Mode Refresh is applied for fundamental updates in the morning, listing updates in the morning and daily statistics in the evening. BME Data Feed uses a time parameter to control the amount of data triggered by an individual Refresh Event: Fundamental and Listing Refreshes usually cover only information changed recently, e.g. within the last 5 days, whereas daily statistics are disseminated for all listings, no matter when the last update happened.

BME Data Feed s Page 15 of 15 4.7 Message Recovery The BME Data Feed System provides a message recovery function for users who have lost messages due to whatever reason. Users may enter recovery mode as follows: During logon: in their logon request, users indicate that they wish to switch to recovery mode after a connection has been established. After the connection has been established: users issue a Message Recovery Request in order to switch to recovery mode. When users are in recovery mode, the BME Data Feed System will re-transmit messages that were sent earlier but where not received by the user. During this procedure, the real-time update is temporarily suspended. After all messages have been re-transmitted, the BME Data Feed System will generate a notification (Message - Data Request Acknowledgement Data) after which the real-time update is resumed. In order to request recovery users have to define a starting point for the re-transmission. For this parameter the following options are available: by Time / Date (optional) by Outbound Message Key The time option determines the message history by specifying a starting time. Messages that occurred on or after the specified time are re-transmitted. Please note that time details should be specified in Greenwich Mean Time (GMT). Optionally, the date can be submitted in combination with the time. If no date is specified with the recovery request, only data from the current GMT day is re-transmitted. Please note that time details for recovery always are supposed to be specified in Greenwich Mean Time (GMT), resp. universal time coordinated (UTC). Optionally, the date can be submitted in combination with the time. If no date is specified with the recovery request, only data of the current day based on time zone UTC +0 - is re-transmitted. If a given recovery time is in the future, BME Data Feed will switch to broadcast mode immediately. Outbound Message Key (OMK, also called OMID=Outbound Message ID) determines the message history by specifying the exact message from which to start the re-transmission. The specified message and the following messages are then re-transmitted. To specify the starting message, users must provide the OMK of the starting message. The OMK is found in every real-time broadcast message.

BME Data Feed s Page 16 of 16 Note: Please be aware that the Outbound Message Log (OML) file, on which recovery requests are based, is deleted on every business day. Recovery Requests with OMK parameter = 0: All messages of the current valid OML file will be recovered. The definition of OMK parameter = 0 ensures that a customer is able to recover all messages of the last business day over the weekend. 4.8 Time resolution BME Data Feed is technically able to process time formats with a resolution down to nanoseconds. In BME Data Feed Core, all fields of the two data types BCD_TIME and BCD_DATE_TIME are potentially affected. Customers have the opportunity to select between 3 different time resolution formats: 1. Time format in hundredth of seconds 2. Time format in microseconds 3. Time format in nanoseconds For this purpose different connectivity request types have been introduced (MID_CONNECTIVITY_REQUEST_MICRO and MID_CONNECTIVITY_REQUEST_NANO). Depending on the selected time format, the format has impact on all time related fields within BME Data Feed. E.g. OPEN_TIME, LOW_TIME, HIGH_TIME, CLOSE_TIME, LAST_TRADE_TIME, LAST_AUCTION_TIME, QUOTATION_TIME. See Appendix E.3 for more detailed explanation of requests and formats.

BME Data Feed s Page 17 of 17 5 Processing Logic 5.1 User States A user can be in any one of the following states: Disconnected Connected Broadcast User Recovery Broadcast (Broadcast User in Recovery Mode) Interactive User Recovery Interactive (Interactive User in Recovery Mode) Mixed Mode User Recovery Mixed (Mixed Mode User in Recovery Mode) The diagram below summarizes the possible state transition paths. DISCONNECTED TCP Connection / Disconnection CONNECTED Logon RECOVERY BROADCAST BROADCAST Request Recovery / Resume Broadcast RECOVERY INTERACTIVE INTERACTIVE Request Recovery / Resume Broadcast MIXED Request Recovery / Resume Broadcast RECOVERY MIXED Logout/ TCP Disconnection Figure 5-1 User State Transition The table below summarizes the characteristics of each state.

BME Data Feed s Page 18 of 18 Table 5-1 User State Transition State Description Remarks Disconnected User is not connected to the BME Data Feed System. User needs to establish physical connection before any data can be accessed. Possible state change = from Disconnected to Connected. Connected User is physically connected to the BME Data Feed System via TCP connection. In this state, the user will receive a system notification message indicating whether or not the system is ready. Three actions are possible: 1. Return to Disconnected state by disconnecting the TCP or physical connection. 2. Change to one of the three User modes by logging on without recovery. The user mode is pre-defined in the user profile and therefore not controlled by login parameters. 3. Change to Recovery Broadcast or Recovery Mixed mode by logging on with recovery. The entitled recovery mode is pre-defined in the user profile. Please note that Interactive Users should not log on with recovery, as their broadcast watch list has not been set up properly. Broadcast User User is logged on as Broadcast User Possible events and actions: 1. Change to Disconnected state by issuing logout request or upon receipt of forced logout message. 2. Change to Disconnected state upon abnormal breakdown of the TCP and physical connection. 3. Change to Recovery Broadcast state by issuing Recovery Request. 4. Broadcast data will be automatically received according to user entitlement. Recovery Broadcast User is physically connected to the BME Data Feed System via TCP connection. Based on the specified recovery option, the user will receive past messages transmitted by the BME Data Feed System. After all past messages have been transmitted, a notification message is generated. Then the BME Data Feed System automatically switches the user s state to Broadcast User. User might also issue Resume Broadcast request to switch to Broadcast User immediately.

BME Data Feed s Page 19 of 19 State Description Remarks Interactive User User is logged on as Interactive User Possible events and actions: 1. Change to Disconnected state by issuing logout request or upon receipt of forced logout message. 2. Change to Disconnected state upon abnormal breakdown of the TCP and physical connection. 3. Change to Recovery Interactive state by issuing Recovery Request. 4. Reception of appropriate broadcast data according to the watch list set up by the user. 5. Entitlement to all of the interactive requests supported by the system. Recovery Interactive User is physically connected to the BME Data Feed via TCP connection. User will receive past messages transmitted by the BME Data Feed System based on the specified recovery option. After all past messages have been transmitted, a notification message is generated. Then the BME Data Feed System automatically switches the state to Interactive User. Similar to real-time broadcast data, the recovery messages are filtered against the current watch list of the user. User might also issue Resume Broadcast to switch to Interactive User immediately. Mixed Mode User User is logged on as Mixed Mode User Possible events and actions: 1. Change to Disconnected state by issuing logout request or upon receipt of forced logout message. 2. Change to Disconnected state upon abnormal breakdown of the TCP and physical connection. 3. Change to Recovery Mixed state by issuing Recovery Request. 4. Automatic reception of broadcast data in accordance with user entitlement. 5. Entitlement to all of the interactive requests supported by the system.

BME Data Feed s Page 20 of 20 State Description Remarks Recovery Mixed User is physically connected to the BME Data Feed via TCP connection. User will receive past messages transmitted by the BME Data Feed System based on specified recovery option. After all past messages have been transmitted, a notification message is generated. Then the BME Data Feed System automatically switches state to Mixed User. Similar to real-time broadcast data, the recovery messages are filtered against the current watch list of the user. User might also issue Resume Broadcast to switch to Mixed User immediately. In order to access data, users must first establish a TCP connection. When this connection is established, the state of the user will change from Disconnected to Connected. The next step is to be acknowledged by the BME Data Feed System via the login process. A successful login will change the user s state from Connected to one of the following: Broadcast User Recovery Broadcast Interactive User Mixed Mode User Recovery Mixed If desired, users may change back to the Disconnected state by going through the logout procedure. The BME Data Feed may also force users to logout when necessary. When there is a problem with the TCP or physical connection, users may be forced to change from any of the above user states to Disconnected. Users only have access to the latest market data when they are in one of the 3 user states. In the recovery states, only past messages are transmitted.

BME Data Feed s Page 21 of 21 5.2 Login to the System BMEDF Figure 5-2 Login to the System System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. Notify user of system state: either READY or MAINTENANCE. The message is sent when the TCP connection is first established or the system state changes. (Message Name, FIELD_NAME) System State Data SYS_STATE 2. If system state is READY, then request login. Login Request USER_ID PASSWORD 3. Acknowledge user login by sending login reply: either SUCCESSFUL or FAIL Login Acknowledgement Data RESPONSE_SUBJECT REQ_END_REASON

BME Data Feed s Page 22 of 22 System Actions & Reactions User Actions & Reactions Related Messages & Fields 4. If login is SUCCESSFUL, then users are ready to access market data. (Message Name, FIELD_NAME) Possible FAIL reasons could be: The BME Data Feed is not available Incorrect password Unknown user ID User already logged on BME Data Feed error In the event of an incorrect password or unknown user ID, the TCP connection will be terminated if the login fails 3 consecutive times or if the login period times out.

BME Data Feed s Page 23 of 23 5.3 Logout by User BMEDF CEF USER Logout Request Logout Acknowledgement Data - Logout Successful Figure 5-3 Logout by User System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. Request for logout Logout Request (Message Name, FIELD_NAME) USER_ID 2. Acknowledge user logout by sending logout reply: always SUCCESSFUL Logout Acknowledgement Data RESPONSE_SUBJECT

BME Data Feed s Page 24 of 24 5.4 Forced Logout by System BMEDF CEF USER System Logout Data Figure 5-4 Forced Logout by System System Actions & Reactions User Actions & Reactions Related Messages & Fields (Message Name, FIELD_NAME) 1. Send logout notification to user System Logout Data LOGOUT_REASON 2. Check reason for failure. Whatever reason it may be, users must log in again to be able to access market data when the system is ready for service. 5.5 Process Broadcast Data BMEDF

BME Data Feed s Page 25 of 25 Figure 5-5 Process Broadcast Data System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User has logged on successfully (Message Name, FIELD_NAME) 2. Send out broadcast data depending on the user login state and user entitlement All users that are logged on will receive system notification and heartbeat data. System State Data System Logout Data For Broadcast and Mixed Mode users, market data disseminated as broadcast data will be received depending on the user s entitlement. Heartbeat Data Tick-by-Tick Listing Data Refresh Quote Listing Data Static Refresh Instrument Data Interactive users will receive market data disseminated as broadcast data only after sending the watch request. Refer to subsequent sections for details. Tick-by-Tick News Data

BME Data Feed s Page 26 of 26 5.6 Interactive Request/ Reply 5.6.1 Add Watch by Product Figure 5-6 Add Watch by Product System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests to add watch for a product. This action is only available for Interactive and Mixed Mode users. (Message Name, FIELD_NAME) Add Watch by Product Request PRODUCT_ID 2. Add all listings covered by the entitled product to the user s watch list to enable the user to continuously receive related market data as broadcast data. Add all news sources of the product to the user news watch list for upcoming news broadcast. 3. When the required modifications Tick-by-Tick Listing Data Refresh Quote Listing Data Tick-by-Tick News Data

BME Data Feed s Page 27 of 27 System Actions & Reactions User Actions & Reactions Related Messages & Fields of the watch list are completed, a Data Request Acknowledgement Data message will be sent to the user to indicate that the Add Watch by Product request has been completed successfully. No Request ID will be added for the upcoming market data and news as broadcast data. (Message Name, FIELD_NAME) This is regarded as the signal for request completion. 4. Send out acknowledgement message to end the request prematurely due to the following reasons: Data Request Acknowledgement Data REQ_END_REASON Entitlement not covered Unauthorized request by Broadcast users BME Data Feed error Entitlement not covered is sent to end request for undefined products as well.

BME Data Feed s Page 28 of 28 5.6.2 Cancel News Retrieval CEF BMEDF USER Cancel News Retrieval Request Data Request Acknowledgement Data - for target request to cancel Data Request Acknowledgement Data - for this cancellation request Figure 5-7 Cancel News Retrieval System Actions & Reactions User Actions & Reactions Related Messages & Fields 2. Send out acknowledgement message to end the target request to cancel 3. Send out acknowledgement message to end this cancellation request due to the following reasons: Completed successfully Invalid argument Unauthorized request by Broadcast users BME Data Feed error 1. User requests to cancel the previous news retrieval requests. This action is only available for Interactive and Mixed Mode users. The cancellation applies to the following requests Retrieve News by Time Request The specified news retrieval request to be cancelled does not exist. (Message Name, FIELD_NAME) Cancel News Retrieval Request REQUEST_ID_FOR_CANCEL Data Request Acknowledgement Data REQ_END_REASON Data Request Acknowledgement Data REQ_END_REASON

Data Request Acknowledgement Data This document is subject to copy rights BME Data Feed s Page 29 of 29 5.6.3 Remove Watch by Product BMEDF CEF USER Remove Watch by Product Request Figure 5-8 Remove Watch by Product System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests to remove watch by product. (Message Name, FIELD_NAME) Remove Watch by Product Request This action is only available for Interactive and Mixed Mode users. PRODUCT_ID 2. Remove all related listings and news sources of a product from the user s watch list. Data Request Acknowledgement Data REQ_END_REASON Stop sending any related upcoming broadcast listing market data and news to the user. Send out acknowledgement message to end the request due to the following reasons: Completed successfully Unauthorised request by non-interactive users BME Data Feed error Unknown product is sent to end removal request of product that is not current in the watch list.

Data Request Acknowledgement Data This document is subject to copy rights BME Data Feed s Page 30 of 30 5.6.4 Retrieve News by Time BMEDF CEF USER Retrieve News by Time Request Refresh News Data Figure 5-9 Retrieve News by Time System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests news retrieval for specific time range. This action is only available for Interactive and Mixed Mode users. (Message Name, FIELD_NAME) Retrieve News by Time Request SOURCE_NAME RETRIEVE_FROM RETRIEVE_TO User should note that both date and time are required to be supplied in RETRIEVE_FROM and RETRIEVE_TO for making the request. 2. Send out news data within specified time range. Again, everything that is transmitted is bound by user entitlement. Note that the watch list is not affected by this request. Refresh News Data When the last up-to-date refresh has been sent, label it as the last response. This is regarded as request completion. 3. Send out acknowledgement message to end the request prematurely due to the following reasons: Data Request Acknowledgement Data REQ_END_REASON

BME Data Feed s Page 31 of 31 System Actions & Reactions User Actions & Reactions Related Messages & Fields Completed successfully Entitlement not covered Unknown news source Unauthorised request by Broadcast users BME Data Feed error No relevant news is available in the specified time range. (Message Name, FIELD_NAME)

Data Request Acknowledgement Data This document is subject to copy rights BME Data Feed s Page 32 of 32 5.6.5 Retrieve Static Data BMEDF CEF USER Retrieve Static Data Request Static Refresh Instrument Data Figure 5-10 Retrieve Static Data System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests retrieval of static data of an instrument. This action is only available for Interactive and Mixed Mode users. (Message Name, FIELD_NAME) Retrieve Static Data Request SYMBOL SOURCE_NAME 2. Send out instrument static data images for valid users in Static Refresh Instrument Data messages. Note that the watch list is not affected by this request. Static Refresh Instrument Data When the last up-to-date refresh has been sent, label it as the last response. Send out acknowledgement message to mark the completion of this request. Completed Successfully This is regarded as request completion. 3. Send out acknowledgement message to end the request prematurely due to the following reasons: Data Request Acknowledgement Data REQ_END_REASON Data Request Acknowledgement Data REQ_END_REASON

BME Data Feed s Page 33 of 33 System Actions & Reactions User Actions & Reactions Related Messages & Fields Entitlement not covered Unknown instrument Unauthorised request by Broadcast users BME Data Feed error (Message Name, FIELD_NAME)

Data Request Acknowledgement Data This document is subject to copy rights BME Data Feed s Page 34 of 34 5.6.6 Retrieve Static Data by Time BMEDF CEF USER Retrieve Static Data by Time Request Static Refresh Instrument Data Figure 5-11 Retrieve Static Data by Time System Actions & Reactions User Actions & Reactions Related Messages & Fields 1. User requests retrieval of static data of all instruments that have been updated during the specific date range. (Message Name, FIELD_NAME) Retrieve Static Data by Time Request SOURCE_NAME RETRIEVE_DATE_FROM This action is only available for Interactive and Mixed Mode users. RETRIEVE_DATE_TO 2. Send out static data for all instruments that were updated during the specified date range. Again, everything that is transmitted is bound by user entitlement. When the last up-to-date refresh has been sent, label it as the last response. 3. Send out acknowledgement message to end the request prematurely due to the following reasons: This is regarded as request completion. Static Refresh Instrument Data Data Request Acknowledgement Data REQ_END_REASON Completed successfully Entitlement not covered Unauthorised request by Broadcast users BME Data Feed error No relevant static data is available in the specified time range.

BME Data Feed s Page 35 of 35 6 Message Description 6.1 General Message Structure A message consists of two segments: Message Length Message Content Figure 6-1 Basic Message Structure Message Content This segment contains the actual contents of the message. Its size is determined by the Message Length segment. Message Length This segment contains 1 to 3 bytes. They are MLB-1, MLB-2 and MLB-3 as shown in the diagram below. The encoded message length is always including the size of the length field itself. Byte MLB-1 is mandatory whilst the other two are optional, depending on the data in MLB-1. Byte 1 MLB-1 Byte 2 (optional) MLB-2 Byte 3 (optional) MLB-3 Byte MLB-1 has the following structure: Figure 6-2 Message Length Structure Bit 8 CF Bit Bit 7 & 6 MLB Bits Bit 5-1 Length Bits Figure 6-3 MLB-1 Structure CF Bit determines whether compressed data is stored in the Message Content segment. If set to OFF, the Message Content segment contains uncompressed data. If set to ON, the Message Content segment contains compressed data. Remark: If the CF bit is set on for compression, the compression feature works if the compression is needed. E.g. in case of too small line bandwidth and message queues. So the effect is that not every data block is compressed. Therefore every data block needs to be checked if the CF bit is set on for following compressed data or not for uncompressed data. MLB Bits determines the length of the Message Content segment.

BME Data Feed s Page 36 of 36 Table 6-1 MLB Bits Value MLB Bits Description 0 0 Message Content segment size is stored in MLB-1 only. Length bits: size of Message Content segment MLB-2: not required MLB-3: not required 0 1 Message Content segment size is stored in MLB-1 and MLB-2. Length bits: most significant bits (bit 9-13) MLB-2: remaining least significant bits (bit 1-8) MLB-3: not required 1 0 Message Content segment size is stored in MLB-1, MLB-2 and MLB-3. Length bits: most significant bits (bit 17-21) MLB-2: remaining least significant bits (bit 9-16) MLB-3: remaining least significant bits (bit 1-8) 6.1.1 Folder/Field Organisation The contents of a message are stored inside the Message Content segment which is organised on the basis of the folder and field concept. The diagram below is an example of a message with contents structured in folders and fields: Message Length Message Content Folder Folder Field Field Folder Folder Field Field Field Field Field Figure 6-4 Folder/Field Organisation A folder is a logical collection of related fields. If necessary, it may also contain folders as shown in the diagram above. A field is the basic unit that carries the actual data. The data in the field is encoded depending on the type of data.

BME Data Feed s Page 37 of 37 6.1.2 Folder/Field Structure Folder and field share the same structure which contains two segments: 2 bytes 0 N bytes Field Header Field Content Figure 6-5 Field/Folder Structure Field Content If it is a field, the Field Content segment stores the actual field data. If it is a folder, the Field Content segment stores the definition of fields/folders inside this folder. To determine whether the Field Content segment contains data for a field or for a folder, refer to the Field Header segment. The whole Field Header segment is also called 16-bit FID. Field Header The field header representing the 16-bit FID is the unique Field Identifier in BME Data Feed and has the following structure: 2 bits 4 bits 10 bits GRP TYPE 10bit FID Group Bits Type Bits FID bits Figure 6-6 Field Header Structure Field GRP designates whether it is a field or a folder. Table 6-2 Field GRP Definition Group Bits Description 0 0 The structure is a zero length field. 0 1 This structure is a fixed size field. 1 0 This structure is a variable size field. 1 1 This structure is a folder. Zero length fields denote a field without data. The size of the Field Content segment is 0.

BME Data Feed s Page 38 of 38 Fixed size field denotes a field whose size is implied by its data type. Refer to Field TYPE for more details. Variable size field denotes a field with variable length data. Both the size and the actual data are stored together in the Field Content segment. Refer to section Size of Variable Length Field for more details on processing such fields. A folder is treated as a variable size field. Its definition is stored in the Field Content segment whose size is determined by the same method applied to the variable size field. Refer to section Size of Variable Length Field for more details. Field TYPE indicates the type of data contained in a field. If field GRP indicates that it is a zero length field, field TYPE is ignored. If field GRP indicates that it is a fixed length field, then field TYPE is used to check on the type of data contained in this field in the following table. Table 6-3 Data Type Definition for Fixed Length Field Type Bits Data Type Size of Field Content 0x00 CHAR 1 0x01 Integer INT16 2 0x02 Integer INT32 4 0x03 Boolean 1 0x04 BCD Date and Time 8 0x04 BCD Date and Time (microseconds) 10 0x04 BCD Date and Time (nanoseconds) 12 0x05 BCD Date 4 0x06 BCD Time 4 0x06 BCD Time (microseconds) 6 0x06 BCD Time (nanoseconds) 8 0x07 DNUM16 3 0x08 DNUM32 5 0x09 DNUM64 9 0x0A BCD Date and Time UTC 12 0x0D INT64 8

BME Data Feed s Page 39 of 39 If field GRP indicates it is a variable length field, field TYPE is used to check the type of data in the field in the following table. For details on size, please refer to the section Size of Variable Length Field. Table 6-4 Data Type Definition for Variable Length Field Type Bit Data Type Size of Field Content 0x00 Byte Stream Variable 0x01 String Variable If field GRP indicates it is a folder, field TYPE is set to 0x00. More information on the data types mentioned in the above tables can be found in the chapter Data Value Presentation. Field NUMBER indicates the content in a field. It is no longer guaranteed that the 10-bit Number is unique over all data types, e.g. there will be only one field of data type DNUM32 with 10-bit Number value 2: 16-bit FID 0x6002 : Field of Data Type DNUM32 Best Ask But there may be fields of other data type with 10 Bit Number value 2, e.g. 16-bit FID 0x4002 : Field of Data Type CHAR 16-bit FID 0x5C02 : Field of Data Type DNUM16 16-bit FID 0x5802 : Field of Data Type BCD Time

BME Data Feed s Page 40 of 40 Size of Variable Length Field Size and contents are stored in the Field Content segment. Size information is stored in the Block Length Field. Block Length Field is always at the beginning of the Field Content segment. Block Length Field is a multi-bit integer presented as a series of bytes. The first byte of Block Length Field contains the most significant bits. The last byte of a Block Length Field contains the least significant bits. Each byte in the Block Length Field uses 7 bits only. The high order bit is reserved to indicate the end of a Block Length Field. If it is set to 1, the next following byte is part of the Block Length Field. If it is set to 0, this byte is the last byte of a Block Length Field. Size is determined by combining all bits in the Block Length Field to form a long integer. The integer value represents the data s actual size following the Block Length Field. The diagram below shows an example of Block Length Field. In the example, the first byte of the Block Length Field indicates that a second byte is to follow (high bit set to 1). The second byte indicates that this is the last byte of the Block Length Field (high bit set to 0). The precise length of the data following the Block Length Field is indicated by the 14-bit values stored across two bytes. The most significant bits (denoted here by X ) are in the first byte and the least significant bits (denoted here by Y ) are in the second byte. Block Length Field (2 bytes) First byte Bit 14-8 1 X X X X X X X Second byte Bit 7-1 0 Y Y Y Y Y Y Y Figure 6-7 Example of a Block Length Field

BME Data Feed s Page 41 of 41 6.2 BME Data Feed Message Structure A message is defined as a collection of folders where the Message ID Folder is always the leading folder. BME Data Feed Message Folder Folder Folder Message ID Field Figure 6-8 General Structure of a BME Data Feed Message The layout of the Message ID folder is presented below: Table 6-5 Layout of a Message ID Folder Message ID Folder Field (Field ID) Description * MESSAGE_ID Message ID REQUEST_ID LAST_RESPONSE_INDICATOR Request ID Indicator of the last response message for the request it refers to. Remarks: * Mandatory Field Message ID is always the first field in the folder. Depending on the nature of the message there may be other fields that follow it. It is stored as a CHAR in the Message ID Field. Please refer to the Appendix for the actual values. Request ID is an optional field for the Message ID Folder. A message from the BME Data Feed System to a user might not carry a Request ID. This may be the case for those broadcast messages which are not delivered upon any request issued by the user. However, Request ID is essential for a request message. It is assigned by the person issuing the request. It should not be a duplicate of any outstanding or uncompleted request. Responses referring to a request should also carry the same Request ID for identification purposes.

BME Data Feed s Page 42 of 42 The Message ID Folder carries information that defines the nature of this message. In particular, it carries a Message ID field that provides the following indications: Message class to which it belongs Message format Message handling The Message ID defines the layout of a message and the possible folder for a message. The table below illustrates all available Message IDs which are currently supported by the BME Data Feed System. Table 6-6 All available Message IDs supported by the BME Data Feed System Message ID Description Messages Initiated by Users MID_CONNECTIVITY_REQUEST MID_CONNECTIVITY_REQUEST_MICRO MID_CONNECTIVITY_REQUEST_NANO MID_INSTRUMENT_REQUEST MID_NEWS_REQUEST MID_SPECIAL_REQUEST Connectivity request Connectivity request for microsecond time resolution Connectivity request for nanosecond time resolution Primary data request for instrument News request Special request Messages Generated by the BME Data Feed System MID_GENERAL_RESPONSE MID_HEARTBEAT MID_INSTRUMENT_DATA MID_LISTING_DATA MID_NEWS_DATA MID_SYSTEM_NOTIFICATION General response upon user request Heartbeat for user reference Primary data of instrument Market data of listing News information Notification generated by the System

BME Data Feed s Page 43 of 43 6.3 Message - Add Watch by Product Request Purpose: Add all listings to the corresponding watch list covered by the specified BME Data Feed product. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SPECIAL_REQUEST * REQUEST_ID * Special Request Folder * SPECIAL_REQUEST_SUBJECT WATCH_ADD_BY_PRODUCT * PRODUCT_ID BME Data Feed product id Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Scope is governed by user entitlement.

BME Data Feed s Page 44 of 44 6.4 Message - Cancel Instrument Data Retrieval Request Purpose: Cancel non-completed instrument retrieval requests. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_INSTRUMENT_REQUEST * REQUEST_ID * Instrument Request Folder * INST_REQUEST_SUBJECT INSTRUMENT_DATA_RETRIEVAL_CANCELLAT ION * REQUEST_ID_FOR_CANCEL Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. The cancellation applies to the following retrieval requests Retrieve Static Data Request Retrieve Static Data by Time Request

BME Data Feed s Page 45 of 45 6.5 Message - Cancel News Retrieval Request Purpose: Cancel non-completed news retrieval requests. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_NEWS_REQUEST * REQUEST_ID * News Request Folder * NEWS_REQUEST_SUBJECT NEWS_RETRIEVAL_CANCELLATION * REQUEST_ID_FOR_CANCEL Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. The cancellation applies to the following retrieval requests Retrieve News by Time Request

BME Data Feed s Page 46 of 46 6.6 Message - Data Request Acknowledgement Data Purpose: This message acknowledges the receipt of user requests and returns the results. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_GENERAL_RESPONSE * REQUEST_ID * General Response Folder * RESPONSE_SUBJECT DATA_REQUEST_ACKNOWLEDGEMENT REQ_END_REASON 1 - BEGIN OF BROADCAST 2 - BEGIN OF RECOVERY 3 - CANCELLED BY USER 4 - COMPLETED SUCCESSFULLY -1 - BME DATA FEED ERROR -3 - ENTITLEMENT NOT COVERED -5 - INVALID ARGUMENT -6 - INVALID OUTBOUND_MESSAGE_KEY FOR RECOVERY -7 - INVALID RETRAN_TIME FOR RECOVERY -8 - UNAUTHORIZED REQUEST -9 - UNKNOWN INSTRUMENT -10 - UNKNOWN LISTING -11 - UNKNOWN NEWS SOURCE -12 - UNKNOWN PRODUCT -15 - REQUEST LIMIT EXCEED -16 - REQUEST WHILE RECOVERING -17 - RESUME WHILE NOT RECOVERING -18 - REQUEST TIMEOUT -19 - RECOVERY ABORT -21 - MISSING REQUEST ID

BME Data Feed s Page 47 of 47 Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. REQ_END_REASON indicates that the request is completed or provides the reason why the request was aborted. 3. LAST_RESPONSE_INDICATOR is provided if the message is the last of a series of messages (response to a particular request); e.g. if a recovery request has been completed and this message contains the transition on broadcast.

BME Data Feed s Page 48 of 48 6.7 Message - Heartbeat Data Purpose: This message informs users that the system is up and running. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_HEARTBEAT * Heartbeat Folder * SYSTEM_TIME Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. This message is transmitted once a minute.

BME Data Feed s Page 49 of 49 6.8 Message - Login Acknowledgement Data Purpose: This message acknowledges the receipt of a user login request and returns the results. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_GENERAL_RESPONSE * REQUEST_ID LAST_RESPONSE_INDICATOR * General Response Folder * RESPONSE_SUBJECT LOGIN_ACKNOWLEDGEMENT * REQ_END_REASON 5 - LOGIN SUCCESSFUL - BEGIN OF BROADCAST 6 - LOGIN SUCCESSFUL - BEGIN OF RECOVERY -1 - BME Data Feed ERROR -2 - BME Data Feed NOT AVAILABLE -3 - ENTITLEMENT NOT COVERED -4 - INCORRECT PASSWORD -5 - INVALID ARGUMENT -6 - INVALID OUTBOUND_MESSAGE_KEY FOR RECOVERY -7 - INVALID RETRAN_TIME FOR RECOVERY -13 - INVALID USER ID OR PASSWORD -14 - USER ALREADY LOGGED IN -20 - CURRENT DATE IS NOT COVERED BY SUBSCRIPTION PERIOD. -21 - MISSING REQUEST ID Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. REQ_END_REASON indicates whether the login was successful or provides the reason for the failure.

BME Data Feed s Page 50 of 50 6.9 Message - Login Request Purpose: This message is used to log in to the system. Users may initialise message recovery by Outbound Message Key or time. Users may also enable compression. In this case BME Data Feed will compress messages only in case of bandwidth bottlenecks. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_CONNECTIVITY_REQUEST or MID_CONNECTIVITY_REQUEST_MICRO or MID_CONNECTIVITY_REQUEST_NANO * REQUEST_ID * Connectivity Request Folder * CONNECTIVITY_REQUEST_SUBJECT LOGIN * USER_ID * PASSWORD OUTBOUND_MESSAGE_KEY MESSAGE_OFFSET RECOVERY_DATE RECOVERY_TIME ENABLE_COMPRESSION

BME Data Feed s Page 51 of 51 Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Depending on the desired time format there are 3 different Requests available. For further reference see also Ch. 3.7 and Appendix E3. 3. USER_ID and PASSWORD are assigned by the BME Data Feed Administration. 4. If the user supplies OUTBOUND_MESSAGE_KEY or RECOVERY_TIME, recovery request is assumed. However, the user should note that these two fields should not coexist. 5. If recovery by Outbound Message Key is requested, the user may also supply MESSAGE_OFFSET to define the recovery start position relative to the message specified by the OUTBOUND_MESSAGE_KEY. 6. Depending on the selected MESSAGE_ID value the client has to send the RECOVERY_TIME field with the selected time resolution. 7. The RECOVERY_TIME field has to be sent in GMT.

BME Data Feed s Page 52 of 52 6.10 Message - Logout Acknowledgement Data Purpose: This message acknowledges the receipt of a user logout request and returns the results. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_GENERAL_RESPONSE * REQUEST_ID LAST_RESPONSE_INDICATOR * General Response Folder * RESPONSE_SUBJECT LOGOUT_ACKNOWLEDGEMENT * REQ_END_REASON 7 - LOGOUT SUCCESSFUL Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. REQ_END_REASON indicates that the logout was successful.

BME Data Feed s Page 53 of 53 6.11 Message - Logout Request Purpose: This message is used to log out from the system. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_CONNECTIVITY_REQUEST * REQUEST_ID * Connectivity Request Folder * CONNECTIVITY_REQUEST_SUBJECT LOGOUT USER_ID Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. USER_ID is assigned by the BME Data Feed Administration.

BME Data Feed s Page 54 of 54 6.12 Message - Message Recovery Request Purpose: Initialise message recovery by Outbound Message Key or time. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SPECIAL_REQUEST * REQUEST_ID * Special Request Folder * SPECIAL_REQUEST_SUBJECT MESSAGE_RECOVERY OUTBOUND_MESSAGE_KEY MESSAGE_OFFSET RECOVERY_DATE RECOVERY_TIME Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. If the user supplies OUTBOUND_MESSAGE_KEY or RECOVERY_TIME, recovery request is assumed. However, the user should note that these two fields should not coexist. 3. If recovery by Outbound Message Key is requested, the user may also supply MESSAGE_OFFSET to define the recovery start position relative to the message specified by the OUTBOUND_MESSAGE_KEY. 4. Please note that this request is eligible for users of different connection modes. 5. The REQUEST_ID should have a value higher than zero. 6. Depending on the selected MESSAGE_ID value the client has to send the RECOVERY_TIME field with the selected time resolution. 7. The RECOVERY_TIME field has to be sent in GMT.

BME Data Feed s Page 55 of 55 6.13 Message - Refresh News Data Purpose: This message contains a news refresh from a news source. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_NEWS_DATA * REQUEST_ID * News Identification Folder * NEWS_DATA_SUBJECT NEWS_DATA_REFRESH * NEWS_ID * SOURCE_NAME * News Folder * NEWS_HEADLINE NEWS_STORY NEWS_METADATA NEWS_TIME NEWS_SRC_TIME Product ID Folder PRODUCT_ID <more PRODUCT_ID fields> Remarks: Mandatory folders and fields are labelled with a leading asterisk.

BME Data Feed s Page 56 of 56 6.14 Message - Refresh Quote Listing Data Purpose: This message contains quote refreshes. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_LISTING_DATA OUTBOUND_MESSAGE_KEY REQUEST_ID * Listing Identification Folder * LISTING_DATA_SUBJECT LIST_DATA_QUOTE_REFRESH * SOURCE_NAME * INSTRUMENT_TYPE * SYMBOL <any source-specific listing identification fields> Refer to document BME Data Feed Interface Specifications Appendix J - and BME Data Feed Fields and Products for field descriptions * Quote Folder * <any source-specific quote fields> Refer to document BME Data Feed Interface Specifications / Fields and Products for field descriptions Product ID Folder PRODUCT_ID <more PRODUCT_ID fields> Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. OUTBOUND_MESSAGE_KEY is only available for broadcast message. 3. REQUEST_ID is not available for broadcast message. 4. The SYMBOL of an instrument could be an ISIN (International Security Identification Number) or another product identifier code. 5. A Quote Folder can hold multiple fields, but no duplicates. They are source-specific and should be referenced in the document BME Data Feed Fields and Products.

BME Data Feed s Page 57 of 57 6.15 Message - Remove Watch by Product Request Purpose: Remove all listings and news sources to the corresponding watch list covered by the specified product. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SPECIAL_REQUEST * REQUEST_ID * Special Request Folder * SPECIAL_REQUEST_SUBJECT WATCH_REMOVE_BY_PRODUCT * PRODUCT_ID BME Data Feed product id. Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Scope is governed by user entitlement.

BME Data Feed s Page 58 of 58 6.16 Message - Resume Broadcast Request Purpose: Resume broadcast from recovery. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SPECIAL_REQUEST * REQUEST_ID * Special Request Folder * SPECIAL_REQUEST_SUBJECT RESUME_BROADCAST Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Please note that this request is available for users of different connection modes.

BME Data Feed s Page 59 of 59 6.17 Message - Retrieve News by Time Request Purpose: Retrieve news that occurred during the specified time period from a news source. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_NEWS_REQUEST * REQUEST_ID * News Request Folder * NEWS_REQUEST_SUBJECT NEWS_TIME_RETRIEVAL * SOURCE_NAME * RETRIEVE_FROM * RETRIEVE_TO Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Scope is governed by user entitlement. 3. Time range is specified in BCD date time format. 4. The time resolution of the RETRIVE_FROM and RETRIVE_TO fields depends on the MESSAGE_ID value of the Login Request.

BME Data Feed s Page 60 of 60 6.18 Message - Retrieve Static Data by Time Request Purpose: Retrieve static data of all instruments that were updated during the specified period. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_INSTRUMENT_REQUEST * REQUEST_ID * Instrument Request Folder * INST_REQUEST_SUBJECT STATIC_DATA_TIME_RETRIEVAL * SOURCE_NAME * RETRIEVE_DATE_FROM * RETRIEVE_DATE_TO Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. Static data of all instruments that were updated during the specified date range will be transmitted. Scope is governed by user entitlement.

BME Data Feed s Page 61 of 61 6.19 Message - Retrieve Static Data Request Purpose: Retrieve static data of an instrument. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_INSTRUMENT_REQUEST * REQUEST_ID * Instrument Request Folder * INST_REQUEST_SUBJECT STATIC_DATA_RETRIEVAL * SYMBOL * SOURCE_NAME Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. The SYMBOL of an instrument could be an ISIN (International Security Identification Number) or another product identifier code. 3. Futures contract requires expiry to identify the actual contract. It has to be added to the ISIN within the SYMBOL field, the two items are separated by a semicolon (e.g. TEFM09C;200906 for a contract expiring in June, 2009) 4. Options contract requires expiry, category, generation number, and original strike price in addition to the ISIN to identify the actual contract. (e.g. T0 900X;201012;P;1;9 for a put option on Telefonica expiring in December, 2010, with a generation number of 1 and a strike of 9). This complete string has to be filled into the SYMBOL field. 5. Interactive Users may send one Static data request for an instrument during one second. Requests of higher frequency will be processed.

BME Data Feed s Page 62 of 62 6.20 Message - Static Refresh Instrument Data Purpose: This message contains refreshes of the static data of an instrument. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_INSTRUMENT_DATA OUTBOUND_MESSAGE_KEY REQUEST_ID * Instrument Identification Folder * INSTRUMENT_DATA_SUBJECT INST_DATA_STATIC_REFRESH * SOURCE_NAME * INSTRUMENT_TYPE * SYMBOL <any source-specific listing identification fields> Refer to document BME Data Feed Interface Specifications Appendix J - and BME Data Feed Fields and Products for field descriptions * Static Data Folder * <any source-specific static fields> Refer to document Fields and Products for field descriptions Product ID Folder Product ID F PRODUCT_ID <more PRODUCT_ID fields> Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. OUTBOUND_MESSAGE_KEY is only available for broadcast message. 3. REQUEST_ID is not available for broadcast message. 4. The SYMBOL of an instrument could be an ISIN (International Security Identification Number) or another product identifier code. 5. A Static Data Folder can hold multiple fields, but no duplicates. They are sourcespecific and should be referenced in the document BME Data Feed Fields and Products.

BME Data Feed s Page 63 of 63 6.21 Message - System Logout Data Purpose: This message forces users to log out. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_SYSTEM_NOTIFICATION * System Notification Folder * SYS_NOTIFICATION_SUBJECT LOGOUT_BY_SYSTEM * LOGOUT_REASON 1 - TERMINATED FOR MAINTENANCE 2 - TERMINATED BY OPERATOR 3 - LOGOUT BY REALTIME QUEUE FULL 4 - LOGOUT BY ENTITLEMENT CHANGE 5 - LOGIN PERIOD TIMEOUT -1 - AUTHORIZATION EXPIRED Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. This message is generated by the system when required. Users cannot control or predict when the system will generate such message. 3. In some cases e.g. slow connection lines, it might be possible that the LOGOUT_REASON as last message is not received by the user application.

BME Data Feed s Page 64 of 64 6.22 Message - System State Data Purpose: This message indicates whether the system is ready for service or in maintenance mode. Direction: BMEDF USER Layout: Field Name Values * Message ID Folder * MESSAGE_ID MID_SYSTEM_NOTIFICATION * System Notification Folder * SYS_NOTIFICATION_SUBJECT SYSTEM_STATE * SYS_STATE READY MAINTENANCE Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. This message is sent when a TCP connection is first established. 3. This message is sent when the system s state changes.

BME Data Feed s Page 65 of 65 6.23 Message Tick-by-Tick Listing Data Purpose: This message contains a tick-by-tick update (insertion) of the quote and intraday trades. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_LISTING_DATA * OUTBOUND_MESSAGE_KEY REQUEST_ID * Listing Identification Folder * LISTING_DATA_SUBJECT LIST_DATA_TICK_BY_TICK * SOURCE_NAME * INSTRUMENT_TYPE * SYMBOL <any source-specific listing identification fields> Refer to document BME Data Feed Interface Specifications Appendix J - and BME Data Feed Fields and Products for field descriptions * Quote Folder * <any source-specific quote fields> Refer to document BME Data Feed Interface Specifications / Fields and Products for field descriptions <more Quote Folder> Product ID F <any source-specific quote fields> Refer to document BME Data Feed BME Data Feed s / Fields and Products for field descriptions Product ID Folder Product ID F PRODUCT_ID <more PRODUCT_ID fields>

BME Data Feed s Page 66 of 66 Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. The SYMBOL of an instrument could be an ISIN (International Security Identification Number) or another product identification code. 3. A Quote Folder can hold multiple fields, but no duplicates. They are source-specific and should be referenced in the document BME Data Feed Fields and Products. 4. A Tick-by-Tick Listing Data message may contain multiple Quote Folders to accommodate multiple quotations of the listing. This feature is only available for those inbound sources which are capable of delivering multiple quotations of a listing in one message. 5. A Quote Folder may, but not necessarily, define an Intraday Tick. 6. Depending on the definition for each source, not every Quote Folder is sufficient to construct an Intraday Tick. 7. Not all data fields of a Quote Folder containing an Intraday Tick are associated with the tick. It totally depends on the source s definition of the tick. Please refer document BME Data Feed Fields and Products for the respective source definition. 8. An Intraday Tick in a Quote Folder must contain a TICK_ID and a TICK_ACTION_INDICATOR for the purpose of identification. Correction and deletion ticks contain a CORRECTION_TICK_ID to refer to the tick that is to be corrected as well. 9. There will be a REQUEST_ID if this is a recovered message.

BME Data Feed s Page 67 of 67 6.24 Message Tick-by-Tick News Data Purpose: This message contains a tick-by-tick news update of a news source. Direction: BMEDF USER Layout: Field Name Value * Message ID Folder * MESSAGE_ID MID_NEWS_DATA * OUTBOUND_MESSAGE_KEY REQUEST_ID News Identification Folder * NEWS_DATA_SUBJECT NEWS_DATA_TICK_BY_TICK * NEWS_ID * SOURCE_NAME * News Folder * NEWS_HEADLINE NEWS_STORY NEWS_METADATA NEWS_TIME NEWS_SRC_TIME Product ID Folder PRODUCT_ID <more PRODUCT_ID fields> Remarks: 1. Mandatory folders and fields are labelled with a leading asterisk. 2. There will be a REQUEST_ID if this is a recovered message.

BME Data Feed s Page 68 of 68 Appendix A - Request Messages Summary Table A-1 Possible requests made by users that are logged on Connection Mode Request Messages Broadcast Interactive Mixed Connectivity Request (MESSAGE_ID = MID_CONNECTIVITY_REQUEST) Login Request Logout Request Instrument Requests (MESSAGE_ID = MID_INSTRUMENT_REQUEST) Retrieve Static Data Request Retrieve Static Data by Time Request Cancel Instrument Data Retrieval Request News Requests (MESSAGE_ID = MID_NEWS_REQUEST) Retrieve News by Time Request Cancel News Retrieval Request Special Requests (MESSAGE_ID = MID_SPECIAL_REQUEST) Add Watch by Product Request Remove Watch by Product Request Message Recovery Request Resume Broadcast Request

BME Data Feed s Page 69 of 69 Appendix B - Data Messages Summary Table B-1 Possible messages sent to users that are logged on Connection Mode Data Messages Broadcast Interactive Mixed System Notification Messages (MESSAGE_ID = MID_SYSTEM_NOTIFICATION) System State Data System Logout Data Heartbeat Message (MESSAGE_ID = MID_HEARTBEAT) Heartbeat Data Listing Data Messages (MESSAGE_ID = MID_LISTING_DATA) Tick by Tick Listing Data Refresh Quote Listing Data Instrument Data Messages (MESSAGE_ID = MID_INSTRUMENT_DATA) Static Refresh Instrument Data News Data Messages (MESSAGE_ID = MID_NEWS_DATA) Tick-by-Tick News Data Refresh News Data General Response Messages (MESSAGE_ID = MID_GENERAL_RESPONSE) Login Acknowledgement Data Logout Acknowledgement Data Data Request Acknowledgement Data

BME Data Feed s Page 70 of 70 Appendix C - System Folder List Table C-1 System Folder List Folder CONNECTIVITY_REQUEST_FOLDER GENERAL_RESPONSE_FOLDER 16bit FID C2BE C2C1 HEARTBEAT_FOLDER C2C2 INSTRUMENT_IDENTIFICATION_FOLDER INSTRUMENT_REQUEST_FOLDER LISTING_IDENTIFICATION_FOLDER LISTING_REQUEST_FOLDER MESSAGE_ID_FOLDER C2C3 C2C4 C2C9 C2CA C2CC NEWS_FOLDER C2CD NEWS_IDENTIFICATION_FOLDER NEWS_REQUEST_FOLDER PRODUCT_ID_FOLDER C2CE C2CF C2D1 QUOTE_FOLDER C2D2 SPECIAL_REQUEST_FOLDER STATIC_DATA_FOLDER SYSTEM_NOTIFICATION_FOLDER C2D3 C2D4 C2D5

BME Data Feed s Page 71 of 71 Appendix D - System Field Definition Table D-1 Field ID Definition Field Data Type Description 16bit FID CONNECTIVITY_REQUEST_SUBJECT CHAR The actual subject of the request. 4321 LOGIN LOGOUT EXPIRY STRING Expiry year and month of the contract, in the format YYYYMM. GENERATION_NUMBER CHAR Generation number of options. Valid range = 1-9 8420 4021 INST_REQUEST_SUBJECT CHAR Type of static data request. 4329 INSTRUMENT_DATA_SUBJECT CHAR The type of data contained in this message. 432A INST_DATA_STATIC_REFRESH INSTRUMENT_TYPE CHAR A value representing the instrument type of the listing or instrument. 4010 LAST_RESPONSE_INDICATOR N/A (Empty) Indicator of the last response message for the request to which it refers. 032B LISTING_DATA_SUBJECT CHAR The type of data contained in this message. 432C LIST_DATA_TICK_BY_TICK LIST_DATA_QUOTE_REFRESH LOGOUT_REASON STRING Reason for system logout 872E 1 - TERMINATED FOR MAINTENANCE 2 - TERMINATED BY OPERATOR 3 - LOGOUT BY REAL-TIME QUEUE FULL 4 - LOGOUT BY ENTITLEMENT CHANGE 5 - LOGIN PERIOD TIMEOUT -1 - AUTHORISATION EXPIRED MESSAGE_ID CHAR Message ID 4331 MID_SYSTEM_NOTIFICATION MID_HEARTBEAT MID_CONNECTIVITY_REQUEST MID_CONNECTIVITY_REQUEST_MICRO MID_CONNECTIVITY_REQUEST_NANO MID_NEWS_REQUEST MID_SPECIAL_REQUEST MID_LISTING_DATA MID_INSTRUMENT_DATA MID_NEWS_DATA MID_GENERAL_RESPONSE

BME Data Feed s Page 72 of 72 Field Data Type Description 16bit FID MESSAGE_OFFSET INT32 Specifies the relative position for requesting message recovery by Outbound Message Key. NEWS_DATA_ SUBJECT CHAR The type of data contained in this message. 4B63 4335 NEWS_DATA_TICK_BY_TICK NEWS_DATA_REFRESH NEWS_HEADLINE STRING News headline. 8737 NEWS_ID INT32 ID given by news source for identification. 4B58 NEWS_METADATA STRING Meta-data content. 8739 NEWS_REQUEST_SUBJECT CHAR The actual subject of the request: 433A NEWS_TIME_RETRIEVAL NEWS_RETRIEVAL_CANCELLATION NEWS_SRC_TIME BCD Date Time News, time-stamped by source. 533E NEWS_STORY STRING News story content. 873F NEWS_TIME BCD Date Time News, time-stamped by the BME Data Feed System. 5340 OPTION_CATEGORY CHAR P Put option. C Call option. 4022 ORIGINAL_STRIKE_PRICE DNUM32 Original strike price of options. 6023 OUTBOUND_MESSAGE_KEY INT64 Identification key of a BME Data Feed outbound message (OMK, OMID) PASSWORD STRING Login password assigned by the BME Data Feed Administration. PRODUCT_ID STRING BME Data Feed Product ID to which this market data message refers. 7762 8741 8742 RECOVERY_DATE BCD Date Specifies the date for the recovery request. 5720 RECOVERY_TIME BCD Time Specifies the time for requesting message recovery. Please note that this field should be in GMT. REQ_END_REASON STRING Reason for ending the request: 1 - BEGIN OF BROADCAST 2 - BEGIN OF RECOVERY 3 - CANCELLED BY USER 4 - COMPLETED SUCCESSFULLY 5 - LOGIN SUCCESSFUL - BEGIN OF BROADCAST 6 - LOGIN SUCCESSFUL - BEGIN OF RECOVERY 7 - LOGOUT SUCCESSFUL 5B61 8743

BME Data Feed s Page 73 of 73 Field Data Type Description 16bit FID -1 - BME DATA FEED ERROR -2 - BME DATA FEED NOT AVAILABLE -3 - ENTITLEMENT NOT COVERED -4 - INCORRECT PASSWORD -5 - INVALID ARGUMENT -6 - INVALID OUTBOUND_MESSAGE_KEY FOR RECOVERY -7 - INVALID RETRAN_TIME FOR RECOVERY -8 - UNAUTHORIZED REQUEST -9 - UNKNOWN INSTRUMENT -10 - UNKNOWN LISTING -11 - UNKNOWN NEWS SOURCE -12 - UNKNOWN PRODUCT -13 - INVALID USER ID OR PASSWORD -14 - USER ALREADY LOGGED IN -15 - REQUEST LIMIT EXCEED -16 - REQUEST WHILE RECOVERING -17 - RESUME WHILE NOT RECOVERING -18 - REQUEST TIMEOUT -19 - RECOVERY ABORT -20 - CURRENT DATE IS NOT COVERED BY SUBSCRIPTION PERIOD -21 - MISSING REQUEST ID -22 - MISSING SOURCE_NAME -23 - UNKNOWN SOURCE OR MISSING ENTITLEMENT -24 - NO SYMBOL OR SERIES FOUND -25 - TOO MANY SYMBOLS (PER MESSAGE) -26 - TOO MANY SYMBOLS (IN TOTAL) RESPONSE_SUBJECT CHAR The type of response to which this message refers: 4345 LOGIN_ACKNOWLEDGEMENT LOGOUT_ ACKNOWLEDGEMENT DATA_REQUEST_ ACKNOWLEDGEMENT

BME Data Feed s Page 74 of 74 Field Data Type Description 16bit FID RETRIEVE_DATE_FROM BCD Date Date from which the retrieval start. 5746 RETRIEVE_DATE_TO BCD Date Date on which the retrieval ends. 5747 RETRIEVE_FROM BCD Date Time Date and time from which the retrieval starts. 5348 RETRIEVE_TO BCD Date Time Date and time on which the retrieval ends. 534B REQUEST_ID INT32 Request ID chosen by user. It must not be a duplicate of any uncompleted request of the system. 4B4C Request ID of the request to which this message is a response. REQUEST_ID_FOR_CANCEL INT32 Request ID of the uncompleted request for cancelling. SOURCE_NAME STRING BME Data Feed source name. Source is a logical grouping of data in the BME Data Feed System. It usually represents the origin or supplier of the data. For example, the market data of a listing is usually supplied by an exchange. SPECIAL_REQUEST_SUBJECT CHAR The actual subject of the request: 4B4D 874E 4350 WATCH_ADD_BY_PRODUCT WATCH_REMOVE_BY_PRODUCT MESSAGE_RECOVERY RESUME_BROADCAST SYMBOL STRING Symbol (name) of the instrument. International Security Identification Number (ISIN). SYS_NOTIFICATION_SUBJECT CHAR Subject of the user notification: 8751 4352 SYSTEM_STATE LOGOUT_BY_SYSTEM SYS_STATE STRING The state of the BME Data Feed System. 8753 SYSTEM_TIME BCD Time System time at which the message is generated. 5B54 TICK_ID INT32 Tick ID unique to a listing within a day. 4B55 USER_ID STRING User identification assigned by the BME Data Feed Administration. 8757 ENABLE_COMPRESSION N/A (Empty) BME Data Feed is enabled to compress outbound data. 031F SECURITY_ID STRING MEFF Contract group. 8470 CONTRACT_SIZE DNUM32 Contract size of the derivatives 6006 EXERCISE_STYLE STRING Type of exercise of the security E European A American 85CC

BME Data Feed s Page 75 of 75 Field Data Type Description 16bit FID FLEXIBLE_IND BOOL Indicates if the security has been defined as flexible according to non-standard means. 4C03 Y Flexible N Standard (default)

BME Data Feed s Page 76 of 76 Appendix E - Data Value Presentation This chapter summarises all possible data types supported by the BME Data Feed. E.1 Boolean Boolean data field contains ONE byte that may have the following possible values: Table E-1 Boolean Value Definition Value Meaning 0 FALSE/NO/OFF 1 TRUE/YES/ON E.2 Byte stream The byte stream data field contains binary data. Its length is variable. Refer to section Size of Variable Length Data Type for details on how to determine the size of a byte stream data field. E.3 Date and Time Fields BCD_TIME and BCD_DATE_TIME will be extended internally with BME Data Feed R9.0. BCD_TIME will internally be 8 Bytes and BCD_DATE_TIME will internally be 12 Bytes long. Before BME Data Feed R9.0 the length of the time component was 4 Bytes and 8 Bytes. In order to find all affected fields please cf. BME Data Feed Fields and Products, filter column Format for those fields of data types BCD_DATE_TIME or BCD_TIME. The BME Data Feed client can decide via Login Request which data format will be used for the time representation. With BME Data Feed R13.0 has been introduced a new Date and Time format named BCDDateTimeUTC, it has the same format that current BCDDateTime (12 Bytes (4 Bytes Date + 8 Bytes Time)), but it is always in UTC. E.3.1 BCD Date Time This data type encodes both date and time information inside a single field and has the following characteristics: 12-byte internal to represent both DATE and TIME First 4-byte integer is the value for DATE Last 8-byte integer is the value for TIME Both DATE and TIME are in BCD format. DATE offers precision up to the year 9999. BCD format is in YYYYMMDD

BME Data Feed s Page 77 of 77 TIME is represented in the format HHMMSSNNNNNNNNNN where HHMMSS is in 24-hour format. NNNNNNNNNN values represents hundredth, micro or nanoseconds. A value of 0xFFFFFFFF in DATE implies NO DATE A value of 0xFFFFFFFF in TIME implies NO TIME. Examples of BCD Date Time Data Type

BME Data Feed s Page 78 of 78 E.3.2 BCD Time 8-byte internal to represent extended TIME down to nanoseconds. TIME is in BCD format. Customers have the choice between 3 different formats of delivery via BME Data Feed Core: Existing time format (hundredth of seconds). BCD_TIME format 4 Bytes BCD_DATE_TIME format 8 bytes Time format in microseconds. BCD_TIME format 6 Bytes BCD_DATE_TIME format 10 bytes Time format in nanoseconds (lowest digit expected to be always 0). BCD_TIME format 6 Bytes BCD_DATE_TIME format 10 bytes The Fields ID for each field will be the same for all 3 options. Overview: Formats and content of time fields

BME Data Feed s Page 79 of 79 The table below assumes that only TIME in BCD format is stored inside the field. Please refer to the section BCD Date Time for details on how time information is encoded. Example for BCD_TIME The difference in which time format the data is delivered, depends on the client connecting process. During the Login there are three different values available: 1. MID_CONNECTIVITY_REQUEST 2. MID_CONNECTIVITY_REQUEST_MICRO 3. MID_CONNECTIVITY_REQUEST_NANO

BME Data Feed s Page 80 of 80 E.3.3 BME Data Feed Requets The choice of the required format of time fields within a session has to be provided with the Login Request. In order no to force customers to change anything within their application in case they want to receive time fields in an unchanged format there will be separate types of message for Login Request available. A client using the existing Login request will receive time information in hundredth seconds resolution. For the 2 new options there will be new Login Request. As the time resolution is expected to be the same for messages disseminated by BME Data Feed and for messages sent to BME Data Feed by the client, any time field within the new Login Resquests has to be in the appropriate format. In particular, the parameter RECOVERY_TIME has to be provided in the appropriate format. The following table defines the respective BME Data Feed messages. Request Affected Field Resolution Login Request MID_CONNECTIVITY_REQUEST Login Request Micro MID_CONNECTIVITY_REQUEST_MICRO Login Request Nano MID_CONNECTIVITY_REQUEST_NANO RECOVERY_TIME FID 0x5B61 RECOVERY_TIME FID 0x5B61 RECOVERY_TIME FID 0x5B61 Hundredths Microseconds Nanosecons Possible data types for representing date and time information are listed in the table below. Table E-2 Data Types for Date Time Representation Data Type Length Precision Internal Representation BCD Date Time 12 bytes YYYY/MM/DD HH:MM:SS.SS.NNNNNNNNNN BCD BCD Date 4 bytes YYYY/MM/DD BCD BCD Time 8 bytes HH:MM:SS.SS.NNNNNNNNNN BCD E.4 CHAR CHAR data type field contains single-byte characters only. There are two ways to express its value: As a number: value is between 0 255. As a presentable ASCII character: for example, A E.5 DNUM Decimal Number (DNUM) is another encoding methodology for representing numeric values. This encoding method has the following characteristics:

BME Data Feed s Page 81 of 81 It stores a value without precision loss It has a fixed size storage It supports decimal values only The diagram below shows the structure of a Decimal Number. 1 Byte 2, 4, or 8 Bytes E Mantissa Exponent A DNUM value is composed of two parts: Figure E-1 Decimal Number Structure Exponent Mantissa Exponent is a single-byte signed integer that defines the order of magnitude of base 10 of the number. It ranges from between -128 and 127. Mantissa is a 2, 4, or 8-byte signed integer that contains the value of the number. Actual Value = Mantissa * 10Exponent The BME Data Feed supports three kinds of DNUMs: Table E-3 Decimal Number Data Types Type BYTE Mantissa Range DNUM16 3 (-2 15 ) (2 15-1) DNUM32 5 (-2 31 ) (2 31-1) DNUM64 9 (-2 63 ) (2 63-1)

BME Data Feed s Page 82 of 82 E.5.1 Special Values Table E-4 Special Values for Decimal Number Data Types (see IEEE 754) DNUM16 DNUM32 DNUM64 Exponent Mantissa Exponent Mantissa Exponent Mantissa NoValue -128 0-128 0-128 0 + 127 999 127 999,999,999 127 999,999,999,999,999,999-127 -999 127-999,999,999 127-999,999,999,999,999,999 NaN -127 0-127 0-127 0 E.5.2 Examples Table E-5 Examples of DNUMs Representation Actual Value Type Exponent Mantissa 123.45 DNUM16 FE 30 39 123450000 DNUM16 04 30 39 NoValue DNUM16 80 00 00 + DNUM16 7F 03 E7 - DNUM16 7F FC 19 NaN DNUM16 81 00 00 123.45 DNUM32 FE 00 00 30 39-12345.67 DNUM32 FE FF ED 29 79-123450000 DNUM32 04 FF FF CF C7 NoValue DNUM32 80 00 00 00 00 + DNUM32 7F 3B 9A C9 FF - DNUM32 7F C4 65 36 01 NaN DNUM32 81 00 00 00 00 123.45 DNUM64 FE 00 00 00 00 00 00 30 39-12345.67 DNUM64 FE FF FF FF FF FF ED 29 79 1234567890.123 DNUM64 FD 00 00 01 1F 71 FB 04 CB -123456789012300 DNUM64 02 FF FF FE E0 8E 04 FB 35 NoValue DNUM64 80 00 00 00 00 00 00 00 00 + DNUM64 7F 0D E0 B6 B3 A7 63 FF FF - DNUM64 7F F2 1F 49 4C 58 9C 00 01 NaN DNUM64 81 00 00 00 00 00 00 00 00

BME Data Feed s Page 83 of 83 E.6 Integer The System supports the following kinds of signed integers: Table E-6 Integer Data Types Type BYTE Range INT16 2 (-2 15 ) (2 15-1) INT32 4 (-2 31 ) (2 31-1) INT64 8 (-2 63 ) (2 63-1) The byte order of the signed integer type follows the standard described in the section Network Byte Order. E.7 Network Byte Order When transmitting a numeric data type, the BME Data Feed System adopts the following Network Byte Order standard: High order byte of high order bits is transmitted first. For example, for an INT16 data field with value 0x0F0A, byte 0x0F is transmitted first, followed by byte 0x0A. E.8 String The string data type is used to store a text string. Basic facts: If the highest bit of the first byte is OFF, then the whole string is assumed to be an ASCII string. If the highest bit of the first byte is ON, then the first byte itself is a code set indicator which indicates the code set of that string (see table below): Table E-7 Code Set Definition Code Set Indicator Code Set 0x81 Big 5 0x82 0x83 0x84 0x85 GB JIS Shift JIS Unicode 0x86 ISO 2022 0x87 0x88 ISO 8859-1 (Latin-1) ISO 8859-15 (Latin-15)

BME Data Feed s Page 84 of 84 Appendix F - Message Folders - constant values table MESSAGE_ID Value MID_SYSTEM_NOTIFICATION 1 MID_HEARTBEAT 2 MID_CONNECTIVITY_REQUEST MID_CONNECTIVITY_REQUEST_MICRO MID_CONNECTIVITY_REQUEST_NANO 3 (regular time format) 14 (time format for micro seconds) 15 (time format for nanoseconds MID_INSTRUMENT_REQUEST 5 MID_NEWS_REQUEST 6 MID_SPECIAL_REQUEST 7 MID_LISTING_DATA 9 MID_INSTRUMENT_DATA 10 MID_NEWS_DATA 11 MID_GENERAL_RESPONSE 12 SYS_NOTIFICATION_SUBJECT Value SYSTEM_STATE 1 LOGOUT_BY_SYSTEM 2 CONNECTIVITY_REQUEST_SUBJECT Value LOGIN 1 LOGOUT 2 INST_REQUEST_SUBJECT Value STATIC_DATA_RETRIEVAL 1 STATIC_DATA_TIME_RETRIEVAL 2 INSTRUMENT_DATA_RETRIEVAL_CANCELLATION 4 NEWS_REQUEST_SUBJECT Value NEWS_TIME_RETRIEVAL 3 NEWS_RETRIEVAL_CANCELLATION 5

BME Data Feed s Page 85 of 85 SPECIAL_REQUEST_SUBJECT Value WATCH_ADD_BY_PRODUCT 1 WATCH_REMOVE_BY_PRODUCT 2 MESSAGE_RECOVERY 3 RESUME_BROADCAST 4 LISTING_DATA_SUBJECT Value LIST_DATA_TICK_BY_TICK 1 LIST_DATA_QUOTE_REFRESH 4 LIST_DATA_INTRADAY_REFRESH 7 (not used) INSTRUMENT_DATA_SUBJECT Value INST_DATA_STATIC_REFRESH 1 NEWS_DATA_ SUBJECT Value NEWS_DATA_TICK_BY_TICK 1 NEWS_DATA_REFRESH 2 RESPONSE_SUBJECT Value LOGIN_ACKNOWLEDGEMENT 1 LOGOUT_ACKNOWLEDGEMENT 2 DATA_REQUEST_ACKNOWLEDGEMENT 3

BME Data Feed s Page 86 of 86 Appendix G - Instrument Type (sorted by value) Description (sorted by value) Value Roll-over 2 (50) Growth Companies 3 (51) Savings Banks Participations 4 (52) Open Outcry (Floor markets) 5 (53) Market State A (65) Bond B (66) Certificates C (67) Funds D (68) Equity E (69) Future Contract F (70) Future Product G (71) Sicavs H (72) Swap K (75) Index I (73) News N (78) Option Contract O (79) Strategy Q (81) Subscription Rights R (82) Other Security (incl. Participation certificates) S (83) Option Product U (85) Warrant W (87) Venture Capital Funds Z (90) Notes: The value A (65) Market State is the instrument type used for Market Halt messages Instruments with value S (83) can be bonds or equities or indices etc. But the value S may be assigned to them owing to internal processing within the BME Data Feed System. If customers want to use real instrument types in their applications we recommend to use reference data fields instead (SECURITY_GROUP_ID, SECURITY_TYPE, SECURITY_ID, EXERCISE_STYLE, FLEXIBLE_IND).

BME Data Feed s Page 87 of 87 Appendix H - Instrument Type (sorted by description) Description Value Bond B (66) Certificates C (67) Equity E (69) Funds D (68) Future Contract F (70) Future Product G (71) Growth Companies 3 (51) Index I (73) Market State A (65) News N (78) Open Outcry (Floor markets) 5 (53) Option Contract O (79) Option Product U (85) Other Security (incl. Participation certificates) S (83) Roll-over 2 (50) Savings Banks Participations 4 (52) Strategy Q (81) Sicavs H (72) Swap K (75) Subscription Rights R (82) Venture Capital Funds Z (90) Warrant W (87) Notes: The value A (65) Market State is the instrument type used for Market Halt messages Instruments with value S (83) can be bonds or equities or indices etc. But the value S may be assigned to them owing to internal processing within the BME Data Feed System. If customers want to use real instrument types in their applications we recommend to use reference data fields instead (SECURITY_GROUP_ID, SECURITY_TYPE, SECURITY_ID, EXERCISE_STYLE, FLEXIBLE_IND).

BME Data Feed s Page 88 of 88 Appendix I - Login Example Example for a Login Request with time resolution micro seconds, USER_ID USER1234 and PASSWORD PASS5678. Coding of Message ID Folder The folder contains two fixed size fields, the MESSAGE_ID field and the REQUEST_ID field. The value used for the message ID is MID_CONNECTIVITY_REQUEST_MICRO (Type: CHAR). The value used for the request ID is 1 (Type: INT32). Coding of the Connectivity Request Folder The folder contains three mandatory fields, the CONNECTIVITY_REQUEST_SUBJECT, the USER_ID and the PASSWORD. The latter two are variable length fields. The length of both fields can be coded in one byte. Coding of the USER_ID field: Coding of the PASSWORD field:

BME Data Feed s Page 89 of 89 Coding of complete Connectivity Request Folder: The length of the folder contents is the summary of the coding of the fields within the folder: 3 Byte for the CONNECTIVITY_REQUEST_SUBJECT and USER_ID and PASSWORD each with 11 Byte, in total 25 byte. Coding of the complete message: The contents length of the message is 12 (length of Message ID Folder) plus 28 (length of Connectivity Request Folder) = 40. This is more than 31. Thus, a 2 byte Message Length Block (MLB) is needed. The coding of the MLB: The complete message will be coded as: