Transaction Reporting. User Guide TRANSACTION REPORTING. User Guide. December. November 2010

Transcription

1 December November Transaction Reporting User Guide TRANSACTION REPORTING User Guide

2 This User Guide provides guidance for Investment Firms. Investment firms must comply with the requirements of the European Communities (Markets in Financial Instruments) Regulations, 2007, and Commission Regulation (EC) No.1287/2006 of 10 August 2006 implementing Directive 2004/39/EC (collectively referred to here as the MIFID requirements ). Failure to comply with the MIFID requirements may result in the Central Bank of Ireland taking an action under the Administrative Sanctions Procedure under Part IIIC of the Central Bank Act Sanctions which may be imposed under the Administrative Sanctions Procedure include monetary penalties, disqualification, imposition of a direction or reprimand. In deciding whether the MIFID requirements have been complied with, the Central Bank of Ireland will take into account the Transaction Reporting User Guide, and any other relevant guidance issued. Firms must not vary from the User Guide without first notifying the Central Bank of Ireland of their intention of doing so and obtaining its agreement in writing to a proposed alternative practice. 1

3 Transaction Reporting User Guide 1. Central Bank of Ireland contacts Please contact our Transaction Monitoring Section on (01) or (01) or via at 2. Obtaining a user ID and password Investment firms will need to inform the Central Bank of Ireland that they intend to report transactions. They will then be issued with an institution code, login name and default password before they are due to start reporting. 3. Access to the transaction reporting system Access is always given to specific individuals within an investment firm, never to the firm as a whole. It is intended that firms will be able to manage their own users and access levels. The Central Bank of Ireland will set up an initial firm administrator who can then set up as many additional users as required. 4. Reportable transactions An investment firm 1 that executes a transaction in financial instruments: (a) that are admitted to trading on a regulated market; (b) that are admitted to trading on a multilaterial trading facility ( MTF ) operated by a market operator; 1 The phrase investment firm is used throughout this User Guide to mean investment firm or credit institution. 2

4 (c) the value of which are derived from, or which are otherwise dependant upon, debt or equity instruments admitted to trading on a regulated market or an MTF operated by a market operator; (d) the value of which are derived from, or which are otherwise dependant upon, indices of financial instruments admitted to trading on a regulated market or an MTF operated by a market operator; shall report details of the transaction to the Central Bank of Ireland, whether or not executed on a regulated market or an MTF operated by a market operator. This obligation will apply not only to transactions executed in financial instruments admitted to trading on the Main Market of the Irish Stock Exchange, the Enterprise Securities Market (ESM) or the Global Exchange Market (GEM), but also to transactions executed in financial instruments admitted to trading on any other EEA Regulated Markets or Multilateral Trading Facilities operated by a market operator. The transaction reporting obligation will apply to trades whether executed on or off the market. Investment firms are required to make transaction reports electronically using the Central Bank of Ireland s online reporting system, by the close of the day following the day on which the transaction was executed. 5. Client Reference Data Reporting institutions are required to submit client reference data to the Central Bank of Ireland in order to facilitate the identification of clients using the client code entered on each transaction report. All internal client codes ( Client Internal ) and internal counterparty codes ( CounterParty Customer ) must be contained in firms Client Reference Data. Firms can submit this client data using the file upload facility on the online reporting system. Alternatively, firms can manually enter client details on the online reporting system. It is important to note when submitting Client Reference Data, that we require one entry for each client. Each entry should contain the client name and address and a list of all accounts for that client including the 3

5 name of the account and the account code. It is essential that the account code provided in the Client Reference Data matches exactly the client code provided in a transaction report. Please note: Once a client code (client key) has been assigned to a client account and uploaded to the Central Bank of Ireland, the code must never be reassigned to another client account. The use of a client code should always be unique to one client account. If you choose to upload your client data, you should upload the entire list initially, and then update your list on a monthly basis. You can either upload your complete client list on a monthly basis (with the necessary additions and amendments) or you can just upload the relevant additions and amendments, whichever is the most convenient for you. 6. Transaction report fields - Guidelines Reporting Firm Identification (Field 1) [Mandatory] This field should contain the unique SWIFT Bank Identifier Code ISO 9362 ( BIC ) to identify the firm, which executed the transaction. The BIC should be 8 or 11 alphanumeric characters. An eight character BIC should be appended with XXX. Firms who have appointed a reporting agent to submit transaction reports on their behalf should ensure that this field identifies them and not the reporting agent. Where a BIC is not already available, it can be requested from SWIFT. This request is free of charge and the investment firm does not have to be a member of the swift network to obtain a BIC. For details of how to obtain a BIC or look up BICs online please go to the SWIFT website at: Trading Day (Field 2) [Mandatory] The trading day on which the transaction was executed. 4

6 The compacted ISO 8601 Date Format standard YYYY-MM-DD must be used to identify the trading date. Trading Time (Field 3.1) [Mandatory] This field should contain the time at which the transaction was executed. The compacted ISO 8601 Time Format HH:MM:SS should be used to identify the time at which the transaction was executed, reported in local time, specified to the second 2. Coordinated Universal Time (Field 3.2) [Mandatory] This field should always be populated +00. The Central Bank of Ireland will populate Summer Time automatically. Buy/Sell Indicator (Field 4) [Mandatory] A single alpha character, 'B' or 'S' should be used to identify whether the transaction was a buy or a sell from the perspective of the reporting firm or, in the case of reporting an agency transaction, of the client. For example: A client buys from a reporting firm acting in a principal capacity - the buy/sell indicator should be set to sell. A client sells to a reporting firm acting in a principal capacity - the buy/sell indicator will be set to buy. A reporting firm acting in an agency capacity for a buying client - the buy/sell indicator should be set to buy. A reporting firm acting in an agency capacity for a selling client - the buy/sell indicator will be set to sell. Trading Capacity (Field 5) [Mandatory] A one alpha character, 'P' or 'A', should be used to indicate whether the reporting firm executed the transaction on its own account P (i.e., as principal, either for its own behalf or to facilitate an order for a client) or as an agent for a client A. Where the reporting firm acts as agent for both the selling and buying counterparties a single transaction report representing both of these 2 Where seconds are not known, they should be defaulted to 00 5

7 transactions can be used. In this case a Client Code will be entered in the Client Identification field and the Counterparty field and the Buy/Sell Indicator should be used to identify whether the transaction was a buy or a sell from the perspective of the client in the Client Identification field. Where the reporting firm acts simultaneously for two counterparties as principal in a single product, at the same price and quantity the reporting firm should send two transaction reports. Instrument Identification (Field 6) [Mandatory] Depending on the type of financial instrument which is the subject of the transaction, one of the following four options must be selected: ISIN Code; SEDOL Code; Over the Counter (OTC) Derivative; Alternative Instrument Identifier (AII) Derivative. The option selected will determine the information to be reported. If ISIN Code is selected complete the following field: Instrument ISIN (Field 6.1) [Mandatory] The ISO 6166 ISIN of the financial instrument, which is the subject of the transaction, should be used. If SEDOL Code selected complete the following field: Instrument SEDOL (Field 6.2) [Mandatory] Where the financial instrument which is the subject of the transaction does not have an ISIN or an AII code, a SEDOL code should be used. If OTC Derivative is selected complete the following fields: Underlying Instrument Identification (Field 7) [Optional] This field is required where the transaction is in an OTC derivative and there is only one underlying instrument or all underlying instruments have been issued by the same issuer. The ISO 6166 ISIN of the underlying instrument should be used. 6

8 Instrument Type (Field 8) [Optional] This field should be used to classify the instrument type of the underlying instrument. The description must at least indicate whether the instrument belongs to one of the top level categories as provided by a uniform internationally accepted standard for financial instrument classification. The ISO is the CFI (Classification of Financial Instruments) code, it is an alphabetical code consisting of 6 capital letters, the first letter is the category, the second letter is the group and the remaining letters show special attributes of the group. One of the following top level values should be used: E - equity D - debt instrument R - entitlements O - option F - future M - other Where there is more than one underlying instrument and the issuers of these underlying instruments are not the same then the instrument type must be INDEX. Maturity Date (Field 9) [Optional] This field should represent the maturity date of a derivative contract. The compacted ISO 8601 Date Format standard YYYY-MM-DD should be used. Derivative Type (Field 10) [Mandatory] One of the following categories should be used to describe the derivative type: O - option F - future W- warrant D - contract for difference X - spread bet Z - credit default swap S - other types of swap agreements Y - other 7

9 Derivative Description (Field 11) [Mandatory] This field must describe the derivative. When identifying multiple underlying instruments as much of the full name of each instrument should be provided. The use of market recognised abreviations e.g. ISEQ for Irish Stock Exchange Equity Index, is acceptable only when identifying indices. Put/Call (Field 12) [Optional] This field is required when reporting a transaction in an OTC option or warrant. A single character C should be used to identify a call, and a single character P should be used to identify a put. Strike Price (Field 13) [Optional] This field is required when reporting a transaction in an OTC option or warrant. This field is sometimes referred to as the exercise price. Price Multiplier (Field 14) [Optional] This field is required when reporting a transaction in an OTC derivative such that 'price (premium) x quantity x price multiplier = trade value', e.g. if the unit price of a warrant contract represents units of 50 warrants then the price multiplier equals 50. The number of units of the financial instrument in question which are contained in a trading lot; for example, the number of derivatives or securities represented by one contract. If Alternative Instrument Identifier (AII) Derivative is selected complete the following fields: Exchange Code (Field 6.3.1) [Mandatory] This field should contain the four character ISO MIC code of the regulated market that admits the derivative to trading. 8

10 Exchange Product Code (Field 6.3.2) [Mandatory] This field should contain the code maintained by the derivatives exchange, uniquely associated with a particular underlying instrument, settlement type and other characteristics of the contract. It can be up to 12 characters in length. Derivative Type (Field 10)[Mandatory] This field should contain a single character, identifying if the instrument is an option O or a future F. O - Option F - Future Put Call Indicator (Field 12) [Mandatory] When the derivative type is an option, this field should contain a single character, identifying whether the option is a put P or a call C. When the derivative type is a future, this field should be populated with the character F. P Put C Call F - Future Expiry Date (Field 9) [Mandatory] This field should contain the maturity/expiry date of the derivative contract. The compacted ISO 8601 Date Format standard YYYY-MM- DD must be used to identify the maturity/expiry date. Strike Price (Field 13) [Mandatory] When the derivative type is an option, this field should be greater than zero. When the derivative type is a future, this field should be zero. Unit Price (Field 15) [Mandatory] The price per security or derivative contract excluding commission and (where relevant) accrued interest should be used. The trade price for a transaction in a bond should be the percentage clean price (i.e. the actual transaction price not including any commission and/or accrued interest). The major currency should be used, e.g. euros rather than cents, pounds rather than pence, etc. For bonds, the price 9

11 must be the percentage price. The Unit Price of a derivative is often referred to as the Premium. Price Notation (Field 16) [Mandatory] This field should contain the alpha ISO 4217 currency code of the currency in which the price is expressed. Quantity (Field 17) [Mandatory] This field should be used to indicate the volume of the trade, e.g. the number of units of the financial instrument, the nominal value of bonds, the number of lots or number of derivative contracts in the transaction. Counterparty (Field 18) [Mandatory] Identification of the counterparty to the transaction. That identification shall consist in: where the counterparty is an investment firm, a BIC code must be used; where the counterparty is a regulated market or an MTF or an entity acting as its central counterparty, a SWIFT Market Identifier Code ( MIC ) ISO or ISO 9362 BIC code must be used; where the counterparty is not an investment firm, a regulated market, an MTF or an entity acting as central counterparty, it should be identified as a client of the investment firm which executed the transaction. Where a BIC or MIC exists for the counterparty that code must be used. Where the counterparty does not have a BIC or MIC, the reporting firm will need to use a unique and consistent internal reference code to identify each client. This internal code should be included in the client reference data (see section 5). Please note: It is acceptable to use a client code (client key) as a substitute for a BIC only when the entity concerned does not have a BIC allocated to them by SWIFT. It is not acceptable to use a client code in place of an existing BIC. 10

12 Client Code (Field 19) [Mandatory] This is a unique code to identify each client on whose behalf the investment firm has executed a transaction. The ISO 9362 BIC must be used where applicable. Otherwise the reporting firm should use a unique and consistent internal reference code to identify each client. Venue Identification (Field 20) [Mandatory] This field should be used to identify where the transaction was executed. Where the venue is a trading venue or a multi-lateral trading facility (MTF) the four character Swift Market Identifier Code (MIC) ISO must be used. Where the venue is a Central Counterparty or Systematic Internaliser a BIC must be used. If the transaction is in a financial instrument admitted to trading on a regulated market or on a MTF operated by a market operator but the transaction is made off market the code XOFF must be used. If a transaction has been trade reported by a member firm to the market operator of a Regulated Market or a MTF operated by a market operator and is conducted in accordance with the trading rules of the market operator, the venue should be the Regulated Market or the MTF. If the transaction is in an OTC derivative (e.g. CFDs, spread bets or non exchange traded instruments) the code XXXX must be used. Transaction Reference Number (Field 21)[Mandatory] This should be a unique identification number for the transaction provided by the investment firm or a third party reporting on its behalf. The unique reference number will enable the firm to provide us with more information about the transaction should we require it. The format and content of the transaction reference number is at the discretion of the firm making the transaction report. 11

13 7. Amending a previously submitted transaction report Where a previously submitted transaction report is amended, the amended report should have the same unique transaction reference number and contain values identical to all those contained in the original transaction report except for the amended values. If submitting an XML file the record must be explicitly marked as an update by setting the update Flag attribute to Y on the root transaction record element. In order to amend a transaction report manually it is necessary to use the Edit function to change the required field. An amendment to a previously submitted transaction report would be appropriate where an investment firm has reported an incorrect price or quantity, or reported an incorrect client code or trade date. 8. Cancelling a previously submitted transaction report Where there is a requirement to cancel a previously submitted transaction report this should be done as soon as possible. If submitting an XML file, send a cancellation transaction record containing the unique transaction reference number of the transaction to be cancelled. If entering the cancellation manually on the website, click on the Cancel option for that transaction. A cancellation would be appropriate where a previously reported transaction should never have been reported in the first instance or if more than two fields on a previously reported transaction were incorrect. 9. Aggregated transactions A firm may aggregate two or more orders for different clients and execute them in a single trade. Where Firm X buys, for example, 100,000 shares from Firm Y on behalf of 3 different clients in an aggregated order Firm X should report a buy from Firm Y (identified in the Counterparty field) on behalf of an aggregated account (identified in the Client Identification field). Firm X should then report three agency buy transactions from the 12

14 aggregated account (identified in the Counterparty field), one for each client (identified in the Client Identification field). 10. Average price transactions A firm may receive an order from a client that can only be filled by executing two or more transactions at different prices but the client wants one or more contract notes showing an average price. For example, Firm X gives an order to Firm Y to buy 100,000 shares as agent and Firm Y completes the order in two tranches, one of 50,000 shares and the other of 50,000 shares at unit prices of 100p and 102p respectively. As there is only one client the firm can report the two transactions in the same shapes, and include the identity of the client on each (even if the firm has issued a single contract note at the average price). Where there is more than one client, for example, Firm X fills orders from ten clients by conducting five market side bought transactions and needs to book the stock to the ten clients. To cut down on the number of transaction reports but to maintain an audit trail we recommend that Firm X reports five agency transactions for the market side in to a designated average price account (identified in the Client Identification field) and ten agency crosses out of that designated average price account (identified in the Counterparty field) to the respective clients (identified in the Client Identification field). 13

15 11. Agency Cross and Bulk Trades Where a firm has to take stock onto an internal account to fill an agency order the firm may use a Bulk Account or an Agency Cross Account. This internal account must be contained in the firm s client reference data upload. Firms are required to submit reports for both the market executions and each client leg. 12. Principal Transactions When reporting principal transactions the reporting firm is required to identify themselves in the client or counterparty field using their reporting firm BIC code. 13. Financial Contracts for Differences (CFDs) A CFD on a share is a derivative product that gives the holder an economic exposure, which can be long or short, to the change in price of a specific share over the life of the contract. Contracts are normally openended, and can be closed out by the CFD holder on demand. The contract does not give the holder either ownership of the referenced shares or any ownership rights, such as voting rights. As the contract is normally cashsettled, it does not usually create any right to take delivery of the shares in place of cash settlement. CFDs offer all the benefits of trading shares without having to physically own them. CFDs mirror the performance of a share or an index. When applied to equities, such a contract is an equity derivative that allows investors to speculate on share price movements. CFDs allow investors to take long or short positions, and unlike futures contracts usually have no fixed expiry dates, standardised contract or contract size. Reporting requirements Under Instrument Identification, OTC should be selected. The derivative type should be Contract for Difference. 14

16 If the underlying instrument has an ISIN this should be used to populate the Underlying Instrument Identification field. The instrument type should classify the instrument type of the underlying instrument (e.g. a CFD on a stock would have an instrument type of equity). The text in the derivative description field should begin with the full name of the underlying instrument e.g. "Ryanair CFD" rather than "CFD Ryanair". The venue should always be XXXX A transaction report is required for opening and closing a CFD position. The end of the derivative description field should contain the letters CLS or OPN to denote whether it is an opening or closing transaction. 14. Credit Default and Equity Swaps A Credit Default Swap ( CDS ) transfers the credit exposure of fixed income products between parties. The buyer of a CDS receives protection against a default so that the risk is transferred from the holder of the fixed income security to the seller of the swap. In return for this protection, the buyer has to pay an interest rate a number of basis points above a 'riskless' benchmark. An equity swap is an exchange of cash flows between two parties that allows each party to diversify its income, while still holding its original assets. The two sets of nominally equal cash flows are exchanged as per the terms of the swap, which may involve an equity-based (variable) cash flow that is traded for a fixed-income cash flow. The two cash flows are usually referred to as "legs" of the swap, one leg is usually pegged to a floating rate e.g. LIBOR, commonly referred to as the "floating leg". The other leg of the swap is based on the performance (total return) of either a share or a stock market index, commonly referred to as the "equity leg" Reporting requirements Under Instrument Identification, OTC should be selected. The derivative type should be credit default swap or other types of swap agreeements. 15

17 The derivative description field should be used to identify the reference entity name. The quantity field should contain the nominal size of the transaction. For a CDS the unit price field should contain the spread at which the transaction was executed, in basis points. For an equity swap, this is the reference price of the underlying equity on which the equity returns are calculated. The maturity date field should contain the maturity date of the contract. The Price Multiplier field must contain the number of underlying instruments that one contract represents. The underlying instrument field should contain either the ISIN of the reference obligation, or the ISIN of any of the deliverable obligations. The venue should always be XXXX. 15. Spread bets Spread bets are similar to CFDs in that they enable investors to gain economic exposure to a financial instrument without actually owning the financial instrument itself, while also offering leverage. Unlike CFDs, spread bets have an expiry date usually on the futures quarterly cycle of March, June, September and December (although they can be closed out at any time). Typically, a spread bet will allow the investor to 'bet' an amount of euro/pound for every one point movement (normally one cent/penny) in the underlying stock. Reporting requirements Under Instrument Identification, OTC should be selected. The derivative type should be Spread Bet. If the underlying instrument has an ISIN this should be used to populate the Underlying Instrument Identification field. The instrument type should classify the instrument type of the underlying instrument (e.g. a spread bet on a stock would have an instrument type of equity). 16

18 The text in the derivative description field should begin with the full name of the underlying instrument e.g. "Ryanair BET" rather than "BET Ryanair". A transaction report is required for opening and closing a spread bet and for the expiration of a spread bet, with the exception of daily rolling spread bets (where only the initial opening and final closing transactions should be reported). The end of the derivative description field should contain the letters CLS or OPN to denote whether it is an opening or closing transaction. The Price Notation field should contain the currency of the spread bet rather than the currency of the underlying reference price. The Venue should always be XXXX. The Maturity Date field should contain the final expiration date for the spread bet, unless it is a rolling bet. The Price Multiplier field should only be populated when the spread bet is not based on a movement of one point (cent/penny). 16. American Depositary Receipts (ADRs) Where a firm executes an order in the US or passes an order to a US broker for execution in the US, and the instrument is an ADR whose related underlying Ordinary share is an Equity instrument that is otherwise reportable, then the transaction should be reported to the Central Bank of Ireland in the same way as an equity instrument. In the case where the reporting firm has executed the trade itself, the relevant MIC code should be identified. In all other circumstances the MIC code XOFF should be used. 17. Use of Direct Market Access (DMA) Providers Reporting firms make use of Direct Market Access (DMA) providers to execute orders in overseas securities in the foreign local market where the DMA provider is a member. The firm uses the DMA provider s market 17

19 membership and connectivity to allow its clients to trade in a range of foreign instruments trading in foreign exchanges. Where a reporting firm receives orders for execution as an agent from a client and the order is passed electronically to the DMA provider for execution, we require the firm to report each client leg of the order showing each individual trade execution with the DMA provider, using the venue XOFF. Where the order is passed to the DMA provider for execution on behalf of the reporting firm itself, we require the firm to report the order (as principal) showing each individual trade execution with the DMA provider (and relevant client legs if appropriate), using the venue XOFF. 18. Multiple venues and client reporting Firms often need to transact on multiple trading venues to satisfy a single client order for a single particular instrument. Whilst the firm needs to transaction report each of the market side transactions with the relevant trading venue identification code, it may report the resulting aggregate transaction to the client with the trading venue identification code XOFF. 19. Put/Call Where complex products have multiple put and call features, firms may report based on the overall nature of the transaction. 20. Results of options transactions Under Article 5 of the MiFID Level 2 Implementing Regulation, the exercise of options or of covered warrants is not transaction reportable. 21. Internal transactions Transactions entered in to within the same Central Bank of Ireland authorised entity, where there is no change of beneficial ownership of the financial instruments, do not need to be reported. 18

20 22. Introducing broker Where a firm acts as an introducing broker, and passes a client order to another firm who then executes the transaction and has the relationship with the underlying client the introducing broker does not have to report the transaction to the Central Bank of Ireland. 23. Give ups Where a firm takes an order from a client and executes a transaction that transaction needs to be reported to the Central Bank of Ireland. Where the firm then gives up the transaction to a third party whoever has the relationship with the client has the responsibility to identify the client in the transaction report. 24. Give ups to hedge Where a firm enters in to a transaction in the market and gives it up to another firm for hedging purposes the Central Bank of Ireland would expect to see a transaction report from both parties. 25. Trading in a new product Investment firms should ensure that in advance of beginning to trade in a new product type the transaction reporting implications are fully considered and, where required, advance arrangements are made. 26. Primary market transactions Primary market transactions (such as issuance allotment or subscription) in financial instruments will not be reportable. This means that all transactions, other than those in derivative products, between the issuer and the first taker as Principal are exempt. However if an instrument is already dealt on a regulated market or a Multilateral Trading Facility operated by a market operator, all secondary issue transactions are reportable. 19

21 27. When Issued dealing (Grey Market) A transaction in a financial instrument admitted to trading on a regulated market or on a Multilateral Trading Facility operated by a market operator or in any over the counter derivative (OTC) the value of which is derived from, or which is otherwise dependent upon, an equity or debt-related financial instrument which is admitted to trading on a regulated market or on a Multilateral Trading Facility operated by a market operator undertaken in the grey market is transaction reportable. 28. Collective Investment Undertakings The Central Bank of Ireland does not expect to receive transaction reports for subscriptions and redemptions of units of investment funds admitted to trading on a regulated market. However, should an investment firm execute a secondary market transaction in a fund which has been admitted to trading on a regulated market or MTF operated by a market operator, it will have an obligation to report. 29. Branches All transactions executed by branches located in this State where the service is provided within the territory of this State, shall be reported to the Central Bank of Ireland. Other transactions executed by branches should be reported to the home Member State competent authority, unless the branch elects to report to the Central Bank of Ireland. 30. Appointing a third party to transaction report on behalf of a firm 1. If an investment firm wants to use the services of a reporting agent to transaction report on its behalf it must notify the Central Bank of Ireland in writing. 2. The letter to the Central Bank of Ireland should be signed by the Chairperson, Managing Director, CEO or Secretary of the investment firm and must: 20

22 2.1 name the reporting agent to be appointed by the investment firm; 2.2 authorise the Central Bank of Ireland to send any information regarding the firm s transactions or transaction reports to the reporting agent; 2.3 confirm that the reporting agent has the ability and capacity to transaction report on behalf of the investment firm; 2.4 set out clearly any roles which are being retained by the firm (e.g. client codes); 2.5 confirm that the investment firm has arrangements in place to manage the ongoing relationship with the reporting agent and that Central Bank of Ireland requirements in relation to outsourcing have been adhered to; 2.6 confirm that the firm will be responsible for the actions of the reporting agent in meeting the firm s transaction reporting obligations; 2.7 acknowledge that the firm remains responsible for reporting its transactions to the Central Bank of Ireland; 2.8 confirm that the firm will advise the Central Bank of Ireland in writing of any changes in the arrangements with the reporting agent; and 2.9 acknowledge that the Central Bank of Ireland may, entirely at its discretion, require the firm to cease using the services of the reporting agent and to report transactions directly to the Central Bank of Ireland. 3. On receipt of a letter certifying these matters and, generally, providing all the information which it considers required for the effective operation of transaction reporting, the Central Bank of Ireland will deal with a reporting agent as a representative of the firm. Where the firm retains any role, it is a matter for the firm to determine with the reporting agent who shall have the role of administrator for the purposes of controlling access codes etc. 31. Immediate market facing firm The concept of an immediate market facing investment firm has been developed by CESR. The Central Bank of Ireland s guidance is that you 21

23 should take this as meaning a firm (whether on its own account or on behalf of another) that: (a) executes transactions on a regulated market or an MTF operated by a market operator; or (b) executes transactions, other than those falling within (a), where there is a transfer of the ultimate beneficial ownership of a financial instrument from one person to another. 32. Arrangements for reporting transactions in derivatives traded on regulated markets During the period 1st November November 2008, the Central Bank of Ireland did not require investment firms to report transactions in derivatives admitted to trading on regulated markets which did not use ISINs as the instrument identifier. Where firms executed transactions in products for which an ISIN was already employed by the regulated market as the instrument identifier, firms were required to make transaction reports and use the relevant ISIN for the product. The Committee of European Securities Regulators (CESR) decided to adopt an alternative way for the identification of securities derivatives on some derivative markets. The new identifier is based on a number of fields rather than a single identifier, but in order to facilitate communication, they are commonly called the Alternative Instrument Identifier (AII). CESR members have agreed with their regulated markets on a market-by-market basis which code the instruments will use (i.e., each individual instrument will be identified either with an ISIN code or an AII code depending on the regulated market). For a full list of regulated markets that use AII codes as the instrument identifier please refer to the CESR MiFID database at From 3 November 2008 investment firms were required to report to the Central Bank of Ireland transactions executed in derivatives admitted to trading on regulated markets that use an AII code as the instrument identifier. In order to facilitate the reporting of these transactions, the Online Reporting system was upgraded to allow investment firms to use 22

24 an AII to identify instruments where applicable. These changes apply both to file upload and to online entry. A letter providing further details on the new reporting requirments was sent to all transaction reporting firms in early October Transaction reporting due on an Irish public holiday Under Regulation 112 of the European Communities (Markets in Financial Instruments) Regulations 2007 (Statutory Instrument No 60 of 2007) an investment firm is required to report details of a transaction as quickly as possible, and no later than the close of the following working day, e.g. transactions entered in to on the Friday before a Bank Holiday Monday will need to be reported by the end of the Tuesday. 34. Data retention Regulation 112 of the European Communities (Markets in Financial Instruments) Regulations 2007 (Statutory Instrument No 60 of 2007) requires that an investment firm shall keep at the disposal of the Central Bank of Ireland, for at least five years, the relevant data relating to all transactions in financial instruments, which it has carried out, whether on own account or on behalf of a client. In the case of transactions carried out on behalf of clients, the records shall contain all the information and details of the identity of the client. 35. Online Reporting website For detailed information on the Online Reporting website, please review the Online Reporting System User Manual. This document provides detailed information on logging in to the website, management of the different user types, reseting passwords etc. This documents is available online on the Central Bank of Irelands website at 23

25 T F transactionreporting@centralbank.ie Bhosca OP 559, Sráid an Dáma, Baile Átha Cliath 2, Éire PO. Box No 559, Dame Street, Dublin 2, Ireland