Financial Services Authority

Transaction Reporting User Pack (TRUP)

Version 2 effective from 21 September 2009

Contents

1.

Introduction 1.1. 1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.1.6 Why transaction reports are important to the FSA Monitoring for market abuse and market manipulation Firm supervision Market supervision Exchange with other EEA competent authorities Other History

5 5 5 6 6 6 6 6 7 7 7 7 8 8 9 11 11 12 13 14 15 15 15

2.

The Transaction Reporting User Pack (TRUP) 2.1. 2.2. 2.3. 2.4. 2.5. What does the TRUP cover? What is not covered? Who should read the TRUP? FSA contacts Have your say

3. 4.

Reportable instruments Obligation to make a transaction report 4.1. 4.2. Firms providing a service of portfolio management Firms providing Direct Market Access (DMA)

5. 6. 7.

Obligations for branches of EEA firms How to send us transaction reports How to complete a transaction report 7.1. Transaction report fields guidelines Reporting firm
The Financial Services Authority 2009

 Trading date Trading time Buy/Sell indicator Trading capacity Instrument identification Instrument description Underlying instrument identification Instrument type Maturity date Derivative type Put/call Strike price Price multiplier Unit price Price notation Quantity Counterparty and customer/client identification fields Venue identification Transaction reference number Cancellation flag 7.2. 7.2.1. 7.2.2. 7.2.3. 7.2.4. 7.2.5. 7.2.6. 7.2.7 7.3. 7.3.1. 7.3.2. 7.3.3. 7.3.4. 7.3.5. Guidelines on reporting OTC derivatives Spread bets Spread bets on an option on an equity Contracts for difference Contract for difference on an option on an equity Credit default swaps Complex derivatives Equity forwards Guidelines on reporting certain scenarios Cancelling a previously submitted transaction report Amending the time or trade date of a previously submitted transaction report Amending a previously submitted transaction report OTC derivative events Contract for difference and spread bet white label providers

15 16 17 17 19 19 19 19 20 20 20 20 21 21 21 22 22 23 23 24 24 24 24 25 25 26 26 27 27 27 27 28 28 28

7.3.6. 7.3.7. 7.3.8. 7.3.9. 7.4. 7.4.1. 8.

Multiple executions for a client order Orders filled by external brokers Aggregated transactions Average price transactions Portfolio managers as counterparties Portfolio manager transactions

28 29 29 29 30 30 33 33 34 35 36 37 37 37 37 38 38 38 38 38 38 38 39 39 39 39 39 40 40 40 41 42

Data integrity 8.1. 8.2. 8.3. 8.4. Firms obligations Transaction reporting arrangements within firms Transaction reporting failures and errors Resources available to firms

9.

Frequently Asked Questions (FAQs) 9.1. 9.2. 9.3. 9.4. 9.5. 9.6. 9.7. 9.8. 9.9. 9.10. 9.11. 9.12. 9.13. 9.14. 9.15. 9.16. 9.17. 9.18. What else can we do to ensure we report correctly? We have started to trade a new product, what do we do? We may have misreported, what do we do? What about UK public holidays? What time is the close of the working day? Are internal transactions reportable? Are grey market transactions reportable? Is over reporting OK? What about COBS 16 Annex 1 R? We have concerns about certain rules, what should we do? Are results of option transactions reportable? Are primary market transactions reportable? Are the individual fund allocations reportable? Are in specie transfers reportable? What about when we outsource a portfolio? What about when our ARM has a technical problem? What about mirrors of on exchange derivatives? What about when we act as an introducing broker?

10. 11.

Glossary of Terms Index

1 Introduction
We have produced this pack in conjunction with various firms and trade bodies. It aims to bring together the detailed instructions and guidelines we have published previously, providing firms with a consolidated point of reference to help them understand and comply with their transaction reporting obligations. Firms should therefore use the information contained in this guide together with any subsequent guidance issued on our website or through MarketWatch.

1.1. Why transaction reports are important to the FSA

Chapter 17 (Transaction Reporting) of the FSA Handbook Supervision Manual (SUP17) requires firms entering into reportable transactions to send us reports containing mandatory details for those transactions by the end of the following business day. At the end of each working day, transaction reports received from firms are loaded in to our transaction monitoring system, SABRE II. This is used by us and external parties for the following purposes.

1.1.1. Monitoring for market abuse and market manipulation

The main thing we use transaction reports for is to detect and investigate suspected market abuse (insider trading and market manipulation) in support of our statutory objectives of maintaining confidence in financial markets and reducing financial crime. SABRE II users in the Transaction Monitoring Unit (TMU) and the Market Conduct teams may, for example, use the data to view all transactions executed by a given firm, in a given stock, over a given period or to view all transactions in a given stock, for a given client, over a given period, etc. When we receive an allegation of market abuse or we identify an issue that needs to be followed up, interrogation of transaction reports in SABRE II is a key part of our work. We need to identify the transactions in question and establish their nature, timing and parties involved. So, the transaction reports are a key piece of the jigsaw in enabling us to determine whether there is a case of market abuse that warrants enforcement action by
Financial Services Authority 5

us. Similarly, transaction reports are very important as evidence when we (or other authorities) are bringing market abuse cases: they provide an audit trail of the complete transaction.

1.1.2. Firm supervision

Firm supervisors may view firms transaction reports to help identify and investigate potential breaches of various Conduct of Business rules, etc.

1.1.3. Market supervision

We undertake market surveillance to alert us to potential new risks to market confidence that may arise from significant market developments. Transaction reports provide us with useful market information that can help with such surveillance, e.g. statistics showing rate of growth in the use of certain instruments.

1.1.4. Exchange with other EEA competent authorities

MiFID requires us to exchange certain transaction reports with other EEA competent authorities through the Transaction Reporting Exchange Mechanism (TREM) of the Committee of European Securities Regulators (CESR). We send transaction reports from branches of non-UK EEA firms to their respective home competent authority and we send them to the most relevant competent authority when that is not us.

1.1.5. Other
Transaction reports are used by certain external parties, including the Bank of England and the Takeover Panel.

1.1.6. History
This version of the TRUP is the second version, which replaces the first version, which was published in July 2007.

Document TRUP Version 1

Effective date November 2007

6 Transaction Reporting User Pack (TRUP)

The Transaction Reporting User Pack (TRUP)

2.1. What does the TRUP cover?

The TRUP has been developed in conjunction with various firms and trade bodies. The TRUP helps firms understand the transaction reporting obligations that come from the Directive 2004/39/EC on Markets in Financial Instruments (MiFID) and is implemented through SUP 17. It aims to give detailed instructions and guidelines to help firms understand their transaction reporting obligations after MiFID implementation in November 2007.

2.2. What is not covered?

The TRUP is not intended to be a replacement for SUP 17 and the Handbook glossary and it will not provide technical specifications for the format of transaction reports. We would expect firms to read the TRUP in conjunction with SUP17, the Handbook glossary and the technical specifications of their respective Approved Reporting Mechanism (ARMs). Whenever there is a particular transaction reporting issue or concern to address, we will continue to publish articles in the MarketWatch newsletter. Firms are encouraged to review all MarketWatch newsletters. You can download previous issues of MarketWatch from our website: http://www.fsa.gov.uk/Pages/About/What/financial_crime/market_abuse/ library/newsletters/index.shtml. To receive MarketWatch by email contact: market.watch@fsa.gov.uk. For further information, please see the transaction reporting section of our website at: http://www.fsa.gov.uk/transactionreporting.

2.3. Who should read the TRUP?

We expect compliance departments and compliance officers to ensure that the TRUP is fully understood and that any necessary amendments to transaction reporting processes are initiated. It should be distributed to all relevant staff in
Financial Services Authority 7

the compliance, systems and operational areas, to the extent that they are involved in transaction reporting.

2.4. FSA contacts

If you have any transaction reporting queries, please contact our Transaction Monitoring Unit on 020 7066 6040 or by email at tmu@fsa.gov.uk.

2.5. Have your say

We would like the TRUP to be a document that continues to develop after MiFID. To inform us of issues you would like to be included in future, please email us at tmu@fsa.gov.uk or call us on 020 7066 6040. We produced this version of the TRUP in conjunction with various firms and trade bodies and would like to thank all parties involved for their willingness to engage with us and for their valuable assistance.

8 Transaction Reporting User Pack (TRUP)

Reportable instruments

Under SUP 17.1.4 R, a firm that executes a transaction must report the details to us if it is executed: (1) in any financial instrument admitted to trading on a regulated market1 or prescribed market (whether or not the transaction was carried out on such a market); or (2) in any Over The Counter (OTC) derivative, the value of which is derived from or is otherwise dependent on an equity or debt-related financial instrument that is admitted to trading on a regulated market or on a prescribed market. Reporting firms should also consider the following exceptions: a. SUP 17.1.4R(2) does not apply to a transaction in any OTC derivative, the value of which is derived from or is otherwise dependent on multiple equity or multiple debt-related financial instruments, except where the multiple financial instruments are all issued by the same issuer. For example, we no longer require firms to transaction report OTC derivatives on the FTSE 100 index. b. Firms can be relieved of their obligation to make a transaction report if the transaction is instead reported directly to us by an ARM or by a regulated market or multi-lateral trading facility (MTF) through whose systems the transaction was completed. A list of ARMs is available on our website at: http://www.fsa.gov.uk/Pages/Doing/Regulated/Returns/mtr/ arms/index.shtml.

For a list of regulated markets, please see the CESR MiFID database at: http://mifiddatabase.cesr.eu/

Financial Services Authority 9

A list of trading venues that report directly to us is available on our website at: http://www.fsa.gov.uk/Pages/Doing/Regulated/Returns/mtr/ regulated_markets/index.shtml. c. Transactions in commodity, interest rate and foreign exchange derivatives are not reportable It has been agreed by CESR and the European Commission that competent authorities need not require firms to report transactions in non-securities derivatives (i.e. commodity, interest rate and FX derivatives) admitted to trading on regulated markets. We do not require firms to report transactions in these derivatives and we will work with LIFFE, the London Metal Exchange (LME) and Intercontinental Exchange (ICE) to ensure that, where another competent authority requires information on transactions in these derivatives, it is made available.

10 Transaction Reporting User Pack (TRUP)

Obligation to make a transaction report

When a firm executes a transaction in an instrument that is reportable under SUP 17.1.4 R it needs to report that transaction to us. MiFID has not defined the term execute. However, we interpret this in light of Level 3 guidelines from CESR to mean that a firm will execute a transaction in the following scenarios: a. a firm transacts directly with an execution venue2 (immediate market-facing firms); or b. a firms that falls outside (a) transacts on its own account (whether through a regulated market or multi-lateral trading facility or outside of them). In addition, we will require the identity of the ultimate client on whose behalf the transaction is carried out, or the identity of the firm dealing with the ultimate client, where this information is not already known to us (see section 7.1). Therefore, where a firm executes a transaction in a reportable instrument on its own account (either on its own behalf or on behalf of a client, (that is as principal)) or for the account and on behalf of a client (that is as agent) the transaction must be reported and the client must be identified. Text in this section may be subject to change since CESR intends to undertake a review in 2009 with a view to produce definitive guidelines.

4.1. Firms providing a service of portfolio management

SUP 17.2.2 G outlines the scenarios in which we would treat a firm providing a service of portfolio management as relying on a third party to make the transaction report and so would not be required to make the transaction report itself. Where a firm, in the course of providing a service of portfolio

For example, a regulated market, an MTF or a systematic internaliser etc.

Financial Services Authority 11

management, undertakes a transaction in an agency or principal capacity on behalf of a client on a discretionary basis, or does so having specifically recommended the transaction to the client, and the firm has reasonable grounds to be satisfied that another party (typically, the broker) will report to the FSA or another competent authority, there is no requirement for an additional report to be submitted by the firm providing the service of portfolio management. In these circumstances reasonable grounds could include making a check not less than annually that the reporting firm continues to be an investment firm subject to the obligation to report transactions. There are a number of scenarios in which SUP 17.2.2 G does not exempt a firm providing a service of portfolio management from reporting. For information on how to report in these scenarios, please see section 7.4.1. Please note that this exemption may cease subject to the outcome of CESRs consultation on defining execution of a transaction, the consultation closes on 1 October 2009.

4.2. Firms providing Direct Market Access (DMA)

DMA is where a customer uses a firms facilities to enter orders directly into an exchanges order book, even though they have no membership of that exchange. If the order is hit, it registers as a transaction in the name of the firm. Firms may subsequently make another transaction to transfer stock ownership to the client. These transactions should be reported by the firm whose facilities are being used to make the trade. One transaction should identify the market counterparty in a principal transaction and a second principal transaction should identify the entity using the DMA facilities. Where the entity using the DMA facility is a MiFID investment firm, the entity should also make a transaction report (unless the MIFID investment entity is acting as a Portfolio manager undertaking transactions on a discretionary basis).

12 Transaction Reporting User Pack (TRUP)

Obligations for branches of EEA firms

All transactions executed by branches of EEA firms where the service is provided within the UK should be reported to us. Where a transaction is executed outside of the UK, the transaction can be reported to either the home Member State competent authority or to us as the host Member State competent authority, at the reporting firms discretion. Following discussion among the Member States, CESR issued guidelines permitting branches to make transaction reports to the host Member State regulator only. CESR recognised that, from a practical point of view, it may be burdensome for branches to be obliged to report their transactions to two different national regulators. So a UK branch of an EEA firm can choose to report all its transactions to us. Likewise, the EEA branch of a UK firm may report its transactions to the local regulator rather than us. The branch is required to provide transaction reports in the format required by the Member State it is submitting transaction reports to.

Financial Services Authority 13

How to send us transaction reports

A regulated market or MTF has the option of reporting to us transactions that have been completed through their systems. A list of these trading venues is available on the transaction reporting section of our website. For all other transactions you may use any one or more of the ARMs to send transaction reports to us. Reporting by fax or email is not permissible. For more information on ARMs please see the transaction reporting section of our website at: http://www.fsa.gov.uk/Pages/Doing/Regulated/Returns/mtr/arms/index.shtml

14 Transaction Reporting User Pack (TRUP)

How to complete a transaction report

We use transaction reports for a variety of purposes and to perform these functions effectively it is vital that firms provide us with accurate data. Transaction reports should contain all mandatory fields applicable to the transaction being reported in line with new SUP 17 Annex 1, Minimum content of a transaction. In this section, we will provide some additional guidelines on how some of these fields should be populated and guidelines on how transactions in certain instruments and OTC derivatives should be reported. Where we refer to specific fields, firms should complete these in the formats described or be assured that these will be the formats that their ARM(s) will use when sending their transaction reports to us. Please note that field names and classifications may differ across ARMs. For clarification, please contact your respective ARM(s). Since the implementation of MiFID, we are also required to transfer certain transaction reports to other competent authorities. This means that, as well as us, other competent authorities may be reviewing the integrity of your data. Please see MarketWatch 28 for further information.

7.1. Transaction report fields guidelines

Reporting firm

This field should contain the FSA reference number (FRN) or the Swift Bank Identifier Code (BIC) of the firm that executes the transaction and on whose behalf the transaction report is being made. If you have appointed a reporting agent to submit transaction reports on your firms behalf, please ensure this field identifies your firm and not the reporting agent. Trading date

The trading date for a transaction entered in to the trading date field must be presented in the correct format as specified by that ARM (e.g. in UK format rather than US format).

Financial Services Authority 15

Please note that, where a transaction has been undertaken outside of the UK, the trading date and, where applicable, the maturity date should reflect the day in UK time. For example, a trade executed in Tokyo on Wednesday 21 February 2007 at 08:30 local time would be reported to us with the UK trading date, Tuesday 20 February 2007 and UK time 23:30. Failure to ensure the trading date and maturity date are reported to us in UK time (i.e. in Greenwich Mean Time (GMT) or, during the summer, in British Summer Time (BST)) may cause a one-day contract traded outside of the UK to be rejected by your reporting system(s) as the contract may appear to be expiring before the trading date. Trading time

This field should contain the time at which the transaction took place. Firms should note that, where a transaction has been undertaken outside of the UK, the trading time should reflect UK time. The trading time should therefore be reported in GMT or, during the summer, in BST. Firms may need to contact their ARM(s) to see whether they need to switch from/to GMT/BST or whether their ARM(s) will meet this requirement for them. Firms must ensure we receive the trading time information as in ISO 8601 Time Format HH:MM:SS and they should contact their ARM(s) to see if this requirement is met. If your firm works a clients order as riskless principal and holds the stock on your own book until the order is complete, you must book the client transaction at the time you have agreed with the client. When a firm uses an external broker to fill an order on a market and that external broker fills the order in several transactions, the time of trade in the transaction reports should reflect the time at which the firm becomes the beneficial owner (i.e. the allocation time). Where the trading time is not made available, the default time of 00:01:00 UK time must be used (this value will need to be presented in the format applicable to the ARM(s) used). Using this default time will ensure that these transaction reports are picked up during our monitoring of trading before a price sensitive announcement. Where the seconds element of the trading time is unknown or not captured, it should be defaulted to 00. However, firms should strive to capture this information correctly. Where reporting firms are unable to meet the requirement to populate the trading time field with the correct trading time and instead provide the time at which the trade is entered into their system, firms should make best efforts to minimise any discrepancy between the trading time and the booking time.

16 Transaction Reporting User Pack (TRUP)

Buy/sell indicator

This field must contain buy or sell to show whether the transaction was a buy or a sell from the perspective of the reporting firm or, in the case of an agency transaction, of the client. For examples:

Firm X buys as principal from Client Y. Firm X would report a transaction where the dealing capacity is principal, Client Y is identified in the counterparty field and the buy/sell indicator is buy. Firm X sells to Firm A on behalf of Client Y in an agency capacity. Firm X would report a transaction where the dealing capacity is agent, Firm A is identified in the counterparty field, Client Y is identified in the customer/ client identification field and the buy/sell indicator is sell.

Where a client sells to the reporting firm who is acting in a principal capacity, the buy/sell indicator should be set to buy. Where the reporting firm is acting in an agency capacity for a selling client, the reporting firm is also selling, so the buy/sell indicator should be set to sell. Trading capacity

The table below shows which counterparties may be identified in which fields for each trading capacity.
Counterparty field (also known as the counterparty one field) Principal The BIC, FRN or internal code (where a BIC/FRN has not been assigned to that entity) of the market counterparty/executing or clearing broker/client; or the BIC of the central counterparty (e.g. LCHLGB2EXXX for LCH.CLEARNET).3 Principal cross The BIC, FRN or internal code (where a BIC/FRN has not been assigned to that entity) of the market counterparty/executing or clearing broker/client; or the BIC of the central counterparty (e.g. LCHLGB2EXXX for LCH.CLEARNET); or INTERNAL. The BIC, FRN or internal code (where a BIC/FRN has not been assigned to that entity) of the counterparty or underlying client; or INTERNAL. Customer/client identification field (also known as the counterparty two field) Blank

Where firms identify a central counterparty with no BIC assigned, we expect firms to inform us so that we contact SWIFT and ensure that a BIC is made available for that central counterparty.

Financial Services Authority 17

Counterparty field (also known as the counterparty one field) Agency The BIC, FRN or internal code (where a BIC/FRN has not been assigned to that entity) of the market counterparty/executing or clearing broker/underlying client; or the BIC of the central counterparty (e.g. LCHLGB2EXXX for LCH.CLEARNET); or INTERNAL. Agency cross The BIC, FRN or internal code (where the BIC/FRN have not been assigned to that entity) of Client 1; or INTERNAL.

Customer/client identification field (also known as the counterparty two field) The BIC, FRN or internal code (where a BIC/FRN has not been assigned to that entity) of the underlying client; or INTERNAL.

The BIC, FRN or internal code (where the BIC/FRN have not been assigned to that entity) of Client 2.

An agency cross is defined to be where the reporting firm acted as agent for both the selling and buying counterparties and the single transaction report represents both of these transactions. For example, to report in a single transaction report a buy as agent on behalf of Client A and a sell as agent on behalf of Client B in a single product at the same time, price and quantity, the trading capacity would be agency cross, Client A would be in the counterparty field (in this scenario the buy/sell indicator would be sell) and Client B would be in the customer/client identification field. A principal cross is a transaction type, which is defined to be where the reporting firm simultaneously executes a buy and a sell as principal in a single product, at the same price and quantity and the single transaction report represents both of these transactions. For example, to report in a single transaction report a buy from a central counterparty and a simultaneous sell to Firm A in a single product, at the same time and quantity, the trading capacity would be principal cross, the central counterparty would be in the counterparty field (in this scenario, the buy/sell indicator would be buy) and Firm A would be in the customer/client identification field. Firms should note there is no requirement to report transactions matching the definition of an agency cross or the definition of a principal cross outlined above in a single transaction report. However, reporting such transactions in a single transaction report may help firms to reduce the fees charged by their ARMs.

18 Transaction Reporting User Pack (TRUP)

Instrument identification

Where the subject of a transaction is a financial instrument admitted to trading on a regulated market or prescribed market that is an equity, a debt instrument or a warrant, or a derivative admitted to trading on a regulated market where the industry method of identification is the ISIN, this field must contain an ISO 6166 ISIN. Where the subject of a transaction is an OTC derivative where the underlying is a financial instrument admitted to trading on a regulated market or prescribed market, the instrument identification field must be blank. Instrument description

When reporting a transaction in an OTC derivative, you should supply a full description of the security in the following format: reference security, derivative type and, where applicable, strike price and maturity date. For further information on how to report transactions in OTC derivatives, see section 7.2. Firms do not have to populate this field where they are reporting an ISIN . Underlying instrument identification

This field must contain the ISO 6166 ISIN of the underlying instrument when reporting a transaction in an OTC derivative unless the OTC derivative is in respect of an index4 or multi-name basket. This field must be used to identify the ultimate underlying instrument. For example, a spread bet on an option on an equity must have the underlying ISO 6166 ISIN identified in this field. Instrument type

This field must contain the instrument type of the ultimate underlying instrument when reporting a transaction in an OTC derivative (e.g. a spread bet on an equity would have an instrument type of A for equity and a contract for difference on an option on an equity would have an instrument type of A for equity). This field is not required for exchange traded instruments. Where the underlying debt instruments have all been issued by the same issuer, e.g. a single name CDS the instrument type should be B for bond.

We no longer require firms to transaction report OTC derivatives the value of which is derived from, or which is otherwise dependent on multiple equity or multiple debt-related financial instruments except where the multiple financial instruments are all issued by the same issuer. Please see MarketWatch 29 and Handbook Notice 85 available online at: http://www.fsa.gov.uk/pubs/handbook/hb_notice85.pdf

Financial Services Authority 19

Maturity date

This field must contain the maturity/expiry/delivery date when you are reporting a transaction in an OTC derivative that is an option, future, warrant, spread bet, credit default swap, other swap, spread bet on an option on an equity, or a contract for difference on an option on an equity. Where the derivative type is a spread bet on an option on an equity or a contract for difference on an option on an equity, this field must contain the expiry date of the option. This field should not be populated for financial instruments admitted to trading on a regulated market or prescribed market where the industry method of identification is the ISIN. Firms are not required to populate this field for complex OTC derivatives (derivative type K). For further information, see section 7.2.1.6. Derivative type

This field must contain the derivative type when reporting a transaction in an OTC derivative, e.g. option (O), future (F), warrant (W), spread bet (X), contract for difference (D), credit default swap (Z), other swap (S), spread bet on an option on an equity (Q), contract for difference on an option on an equity (Y) or complex derivative (K). For guidelines on reporting transactions in OTC derivatives see section 7.2. This field should not be populated for financial instruments admitted to trading on a regulated market or prescribed market where the industry method of identification is the ISIN. Put/call

This field must contain either P for put or C for call when reporting a transaction in an OTC derivative that is an option, warrant, spread bet on an option on an equity or contract for difference on an option on an equity. Where the derivative type is a spread bet on an option on an equity or a contract for difference on an option on an equity this field must be used to indicate whether the option is a put or a call option. This field should not be populated for financial instruments admitted to trading on a regulated market or prescribed market where the industry method of identification is the ISIN. Firms are not required to populate this field for complex OTC derivatives (derivative type K). For further information, see section 7.2.1.6. Strike price

This field must contain the strike price when reporting a transaction in an OTC derivative that is an option, a warrant, a spread bet on an option on an
20 Transaction Reporting User Pack (TRUP)

equity, or a contract for difference on an option on an equity. Where the derivative type is a spread bet on an option on an equity or a contract for difference on an option on an equity, this field must be used to indicate the strike price of the option. This field is sometimes referred to as exercise price. This field should not be populated for financial instruments admitted to trading on a regulated market or prescribed market where the industry method of identification is the ISIN. Firms are not required to populate this field for complex OTC derivatives (derivative type K). For further information, see section 7.2.1.6. Price multiplier

The price multiplier is the number of underlying instruments that are represented by a single derivative contract, e.g. if a warrant contract represents 50 units of the underlying instrument, then the price multiplier equals 50. Unit price

This field must contain the unit price of the transaction. Firms may report the price that they have confirmed to the customer or counterparty. In most cases, this will be the gross price. For equities, there are circumstances where the net price is the only price available to the trade and in such circumstances the net price may be reported. The trade price for a transaction in a bond or a bond option should be the percentage clean price (i.e. the actual transaction price not including any commission and/or accrued interest). The unit price must not be negative. The unit price must be provided in the major currency, e.g. pounds rather than pence, euros rather than cents, etc. For derivatives, the unit price must be the decimal value per contract, not the tick value. Price notation

This field must contain the alpha ISO 4217 currency code of the currency in which the unit price is expressed. If in the case of a bond or other form of debt the price is expressed as a percentage of nominal value, then this field must contain the alpha ISO 4217 code of the currency of the nominal value, including the legacy currency codes if issued pre-conversion to the euro. For spread bets, the price notation field will be the currency in which the unit price of the underlying instrument is expressed.

Financial Services Authority 21

Quantity

This field must contain the volume of the transaction, e.g. the number of units of the financial instrument, the nominal value of bonds or bond options, the number of lots or number of derivative contracts in the transaction. The quantity must be positive. For spread bets, this field must contain the monetary value wagered per point movement in the underlying instrument. For example, a 10 per point spread bet in Vodafone common stock at 1.35 and closed at 1.55 would result in a profit of 200 (10 x 20 point rise) and so the quantity would be 10 for both the buy and sell transactions. Where the spread bet is denominated in a foreign currency, the quantity field should still be the amount of the bet in sterling, foreign currency amounts being converted at spot rates. Where the subject of the transaction is an option, the quantity field must contain the number of contracts traded. For example, a trade of 100 option contracts on BT where each option contract equals rights over 1,000 shares would be reported with a quantity of 100 and a price multiplier of 1,000. Counterparty and customer/client identification fields

The counterparty field is sometimes referred to as the counterparty one field and should contain a code to identify your counterparty. The customer/client identification field is sometimes referred to as the counterparty two field. This field must be blank when reporting a transaction where the trading capacity is principal.5 Where a BIC or FRN exists for your counterparty or client, you must use one of these codes. Where your counterparty (or client) does not have either of these codes, you will need to use an internal code. In these circumstances the internal code must be unique to that entity and must be used consistently across all instrument types and platforms for that entity. Where the counterparty is a central counterparty (CCP), e.g. LCH, the BIC for that central counterparty must be used. A list of EEA central counterparties and their BICs can be found under the Central Counterparties section of the CESR MiFID Database at: http://mifiddatabase.cesr.eu/. A BIC should be eight or 11 alphanumeric characters long. Firms should contact their reporting system(s) for confirmation of whether eight character BICs should be appended with XXX. We recognise that some firms may have more than one BIC. Any of the available BICs can be used to identify these firms.

Please refer to trading capacity for further details on how to populate the counterparty and customer/client identification fields.

22 Transaction Reporting User Pack (TRUP)

For details of how to obtain a feed of BICs or look up BICs online, please go to the Swift website at: www.swift.com. For details of how to obtain a feed of FRNs, or look up FRNs online, please go to our register at: www.fsa.gov.uk/register. A unique code (BIC, FRN or internal code) allows us to view all trading across all products and thereby gauge whether a firm or clients transaction is consistent with historic trading behaviour. When identifying an internal account (e.g. an aggregated account or an average price account etc), where possible, we recommend firms use the code INTERNAL only. Reporting transactions in line with this guideline will greatly reduce the number of requests for information that we make to firms. This will help to reduce the resources that firms need to dedicate to those enquiries. Venue identification

This field must contain the four-character Swift ISO 10383 Market Identifier Code (MIC) where the transaction was executed on a regulated market or a multi-lateral trading facility (MTF). This field must contain the code XOFF where the transaction is in a financial instrument admitted to trading on any market, but the transaction is made off market. This field must contain the code XOFF where the firm executes a transaction in a financial instrument admitted to trading on a regulated market or prescribed market using an external broker and the identity of the trading venue is not made available before the reporting deadline . This field must contain the code XXXX where the transaction is in an OTC derivative. This field should contain the BIC of the systematic internaliser where the reporting firm or the counterparty executed the transaction as a systematic internaliser. Firms often need to execute transactions on multiple trading venues to satisfy a single client order for a single particular instrument. While the firm needs to report each of the market side transactions and populate the venue identification field in accordance with the above guidelines, it may report the resulting aggregate transaction to the client using the code XOFF. Transaction reference number

This field must contain a unique reference, internal to the firm making the report, which 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 firms discretion.

Financial Services Authority 23

Cancellation flag

Please see section 7.3.1 and submit your cancellations in accordance with the technical specifications provided by your ARM(s).

7.2. Guidelines on reporting OTC derivatives

In this section, we aim to confirm the way in which certain transactions should be reported to us. Transaction reports should contain all mandatory fields in line with SUP 17 Annex 1. Where we refer to specific fields in a transaction report, firms should complete these fields in the formats described or be assured that these will be the formats that their ARMs will use when sending their transaction reports to us. Additional guidelines in respect of some of these fields have been provided below. Reporting transactions in line with these guidelines will greatly reduce the number of requests for information that we make to firms. This will help to reduce the resources that firms need to dedicate to those enquiries. Firms should note that following Chapter 5 of CP08/16: Quarterly Consultation (No. 18), Handbook 85 and MarketWatch (No.29, page 9), transactions in OTC derivatives, the value of which is derived from or is otherwise dependent on multiple equity or multiple debt-related financial instruments except where the multiple financial instruments are all issued by the same issuer are not reportable.

7.2.1. Spread bets

Where the transaction is in an OTC derivative that is a spread bet, the derivative type field must contain X for spread bet, unless it is a spread bet on an option on an equity (see section below). The instrument type must classify the instrument type of the underlying instrument (e.g. a spread bet on an equity would have an instrument type of A for equity). Text in the instrument description field should begin with the full name of the underlying instrument, e.g. Vodafone BET rather than BET Vodafone. The underlying instrument identification field must contain the ISIN of the ultimate underlying instrument.

7.2.2. Spread bets on an option on an equity

We are implementing a new derivative type to identify spread bets on an option admitted to trading on a regulated market, where the underlying is a single equity admitted to trading on a regulated market or prescribed market.

24 Transaction Reporting User Pack (TRUP)

Where this derivative type classification is used, the: derivative type must be Q; instrument type should classify the type of the ultimate underlying instrument (e.g. a spread bet on an option on an equity would have an instrument type A for equity); text in the instrument description field should begin with the full name of the underlying instrument; underlying instrument identification field should contain the ISIN of the ultimate underlying (e.g. when reporting a transaction in a spread bet on a LIFFE traded equity option this field must contain the ISIN of the equity); and the maturity date, put/call and strike price fields must be used to indicate the terms of the underlying option.

7.2.3. Contracts for difference

Where the transaction is in an OTC derivative that is a contract for difference, the derivative type field must contain D for contract for difference, unless it is a contract for difference on an option on an equity (see section below). The instrument type must classify the instrument type of the underlying instrument (e.g. a CFD on an equity would have an instrument type of equity). The text in the instrument description field should begin with the full name of the underlying instrument, e.g. Vodafone CFD rather than CFD Vodafone. The underlying instrument identification field must contain the ISIN of the underlying instrument.

The Complex OTC Derivatives Working Group is reviewing the scope of this derivative type classification and will draft a definition of CFD to ensure that total return swaps are included in this classification. Once this work is complete, this section will be updated accordingly.

7.2.4. Contract for difference on an option on an equity

We are introducing a new derivative type to identify contracts for difference on an option admitted to trading on a regulated market where the underlying is a single equity admitted to trading on a regulated market or prescribed market. Where this derivative type classification is used, the: derivative type must be Y;

Financial Services Authority 25

instrument type field must be A for equity; text in the instrument description field should begin with the full name of the underlying instrument; underlying instrument identification field must contain the ISIN of the ultimate underlying equity; and the maturity date, put/call indicator and strike price fields must be used to indicate the terms of the underlying option.

7.2.5. Credit default swaps

Where the transaction is in an OTC derivative that is a credit default swap, the derivative type must contain Z for credit default swap. The buy/sell indicator must reflect whether the reporting firm is buying or selling protection. The instrument description field should be used to identify the reference entity. The quantity field must contain the nominal size of the transaction. The unit price field must contain the spread at which the transaction was executed, in basis points. Where the price cannot be determined, a default value of 1 may be used. The maturity date field must contain the maturity date of the contract. Where the underlying financial instruments have all been issued by the same issuer, the instrument type should be B for bond and the underlying instrument identification field should contain either the ISIN of the reference obligation, or the ISIN of any of the deliverable obligations.

7.2.6. Complex derivatives

We are introducing a new derivative type to identify OTC derivatives that are too complex for other derivative type classifications. Where this derivative type classification is used the derivative type must be K. This derivative type classification should be used where the OTC derivative is: an option that cannot be classified as a call or put option at the time the transaction is entered in to; an option or warrant that has multiple puts and calls;

26 Transaction Reporting User Pack (TRUP)

an option that allows the purchaser to choose whether the option is a call or a put on a particular date in the future (often referred to as a chooser option); an option or a warrant and the strike price is not known at the time the transaction is entered into and is instead based on the average price over an averaging period.

We expect firms to contact us if they have any doubts about the suitability of this category for certain OTC derivatives.

7.2.7. Equity forwards

Where the transaction is in an equity forward, the transaction should be reported as an OTC future.

7.3. Guidelines on reporting certain scenarios

In this section, we provide guidelines on how to report in specific scenarios. Please note that field name classifications may differ across ARMs. For clarification, please contact your respective ARM(s).

7.3.1. Cancelling a previously submitted transaction report

If you need to cancel a previously submitted transaction report, you must submit a cancellation transaction report as soon as possible. The cancellation transaction report should contain values identical to all those contained in the original transaction report except for the report status field, which you should use to mark the transaction report as a cancellation and any information required by your ARM(s).

7.3.2. Amending the time or trade date of a previously submitted transaction report
Where there is a requirement to amend the trading time or date of a previously submitted transaction report, you will need to submit a cancellation transaction report and submit a new transaction report with the corrected trading time or date. The reason an amendment to a previously submitted transaction report is not possible is that the trading date and trading time fields, in addition to the transaction reference number and reporting firm ID, form the identifiers we use to uniquely identify a transaction report. As a consequence, if an amendment to a transaction report is submitted to us with a new trading time or trading date, our systems will be unable to locate the original transaction report and will therefore reject the amendment transaction report.

Financial Services Authority 27

7.3.3. Amending a previously submitted transaction report

Where there is a requirement to amend a previously submitted transaction report, you may need to contact your ARM to understand what action to take. Some ARMs may allow you to send a transaction report marked as an amendment to a previously submitted transaction report. Other ARMs may require you to cancel the originally submitted transaction report and submit the new amended version. If your ARM has already sent the transaction report to us then you may need to send us a cancellation transaction report (in line with the guidelines in the section above). If your ARM has not yet sent the transaction report to us and will simply replace the original with the amended version, you do not need to do anything. If your ARM has not yet sent the transaction report to us and will send it along with your new amended version, you may need to send us a cancellation transaction report to cancel the original transaction report (in line with the guidelines in the section above).

7.3.4. OTC derivative events

The Complex OTC Derivatives Working Group is reviewing the reporting of OTC derivative events such as partial terminations of swap transactions. Once this work is complete, this section will be updated accordingly.

7.3.5. Contract for difference and spread bet white label providers
A CFD white labelling solution provided by a firm, e.g. Firm A allows another firm, Firm B, to offer Firm As CFD trading services (e.g. trading platform etc) to their clients. There are various ways that a white label solution can be structured. With respect to transaction reporting, where a client of Firm B executes a transaction using the CFD white labelling solution and Firm A reports the transaction and identifies the client of Firm B, Firm B would not need to send us a transaction report.

7.3.6. Multiple executions for a client order

Where a firm fills an order for a client by undertaking multiple transactions, each transaction and the identity of the client must be reported.

28 Transaction Reporting User Pack (TRUP)

7.3.7. Orders filled by external brokers

There may be instances where Firm A gives an order to Firm B for execution, (e.g. because Firm A is not a member of an exchange etc) and Firm B fills the order by undertaking multiple transactions. Transaction reports submitted by Firm A will need to reflect the time at which Firm A became the beneficial owner. Firm A may therefore need to report each transaction individually, if known, or the transaction undertaken once the order is complete.

7.3.8. Aggregated transactions

A firm may aggregate two or more orders for different clients and execute them in a single transaction. For example, where Firm X buys 100,000 shares from Firm Y on behalf of three 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 customer/client identification field using the code INTERNAL only). Firm X should then report three agency buy transactions from the aggregated account (identified in the counterparty field using the code INTERNAL only) for each client (identified in the customer/client identification field).

7.3.9. 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 transactions, one of 20,000 shares and the other of 80,000 shares at unit prices of 100p and 102p respectively. As there is only one client the firm can report the two agency buy transactions from Firm Y (identified in the counterparty field) and include the identity of the client on each (in the customer/client identification field) (even if the firm has issued a single contract note at the average price). A more complex scenario would be where there is more than one client, for example, Firm X fills orders from ten clients by conducting five market side buy transactions and needs to book the stock to the ten clients. In such a scenario, the firm could report all the individual transactions separately. To cut down on the number of transaction reports, but to maintain an audit trail, we would recommend that Firm X reports five agency buy transactions from the market counterparty (identified in the counterparty field) in to a designated average price account (identified in the customer/client identification field using the code INTERNAL only) and ten agency/agency crosses of that designated average price account (identified in the counterparty

Financial Services Authority 29

field using the code INTERNAL only) to the respective clients (identified in the customer/client identification field).

7.4. Portfolio managers as counterparties

To report a transaction where your counterparty is a firm providing the service of portfolio management, the transaction report should identify the firm providing the service of portfolio management using their FSA Reference Number or Swift Bank Identifier Code (BIC), or, if neither is available, an internal unique code. There is no requirement for the transaction report to identify the fund managed by the firm providing the service of portfolio management. There is no requirement to report separate transactions for the respective funds managed by the firm providing the service of portfolio management; it is only necessary to report the bulk trade with the portfolio manager.

7.4.1. Portfolio manager transactions

SUP 17.2.2 G outlines the scenarios in which a firm providing a service of portfolio management is exempt from transaction reporting. Where a firm in the course of providing a service of portfolio management undertakes a transaction in an agency or principal capacity on behalf of a client on a discretionary basis, or does so having specifically recommended the transaction to the client, and the firm has reasonable grounds to be satisfied that another party (typically, the broker) will report to us or another competent authority, the firm does not need to submit an additional report. There are several scenarios in which a firm providing a service of portfolio management undertakes a transaction in an agency or principal capacity on behalf of a client and SUP 17.2.2 G does not exempt them from reporting. These include the following: Where the broker is not a MiFID investment firm (and so will not be required to report the transaction to us or another competent authority) and the financial instrument is admitted to trading on a regulated market or prescribed market. When the firm providing a service of portfolio management undertakes an inter fund transaction without using a broker who is a MiFID investment firm. Where the transaction is reportable under SUP 17 but is not a transaction in a financial instrument admitted to trading on a regulated market and the broker is a non-UK MiFID investment firm. This covers areas where the UK is super-equivalent to the MiFID requirements. It includes transactions in OTC derivatives where the underlying instrument is traded on a regulated

30 Transaction Reporting User Pack (TRUP)

market or prescribed market and transactions in financial instruments admitted to trading on prescribed markets. In such circumstances, the nonUK broker is not expected to make a transaction report as the transaction is likely to be outside the reporting rules applicable in the brokers home state. Consequently, the firm providing the service of portfolio manager cannot rely on the exemption under SUP 17.2.2 G. Where the counterparty is another firm providing a service of portfolio management, in which case both firms will have to transaction report. When a firm providing a service of portfolio management undertakes a transaction in an agency or principal capacity on behalf of a client on an execution-only basis. In the event that a firm providing a service of portfolio management contacts an EEA broker to conduct a transaction in a reportable instrument on a non-EEA exchange, that broker may pass the order to a non-EEA broker to execute the trade. If the EEA broker is not itself entering into the transaction in an agency or principal capacity because the relationship with the firm providing the service of portfolio management has been given up to the non-EEA broker, then the firm providing a service of portfolio management, rather than the EEA broker, would have an obligation to transaction report. However, it would be perfectly permissible for the EEA broker to report this transaction either in its own name or the name of the firm providing a service of portfolio management so that the firm providing a service of portfolio management need not report directly. This would form part of an agreement that the firm providing a service of portfolio management may wish to undertake with the EEA broker. Where an EEA broker reports a transaction in its own name, as if it were acting in an agency capacity, the transaction report should identify itself in the reporting firm field, the counterparty in the counterparty field (sometimes referred to as the counterparty one field) and the firm providing a service of portfolio management in the client/customer field (sometimes referred to as the counterparty two field). Where an EEA broker agrees to report a transaction in the name of the firm providing a service of portfolio management, the transaction report should identify the firm providing a service of portfolio management in the reporting firm field, the counterparty in the counterparty field (sometimes referred to as the counterparty one field) and the firm providing a service of portfolio management in the client/customer field (sometimes referred to as the counterparty two field).

Financial Services Authority 31

In the event that a firm providing a service of portfolio management is unable to rely on a third party to meet its reporting obligations under SUP 17.2.2 G, the firm will need to make arrangements for the transaction to be reported via an ARM in accordance with the guidelines below: Where a firm providing a service of portfolio management undertakes a transaction in an agency capacity on behalf of a client on a discretionary basis and SUP 17.2.2 G does not exempt the firm from reporting, the transaction report should identify the firm providing a service of portfolio management in the reporting firm field, the counterparty in the counterparty field (sometimes referred to as the counterparty one field) and the firm providing a service of portfolio management in the client/customer field (sometimes referred to as the counterparty two field). Where a firm providing a service of portfolio management undertakes a transaction in an agency capacity on behalf of a client on an execution only basis, SUP 17.2.2 G does not exempt the firm from reporting. The transaction report should identify the firm providing a service of portfolio management in the reporting firm field, the counterparty in the counterparty field (sometimes referred to as the counterparty one field) and the client in the client/customer field (sometimes referred to as the counterparty two field). Where a firm providing a service of portfolio management undertakes an inter fund transaction, where no broker who is a MiFID investment firm is involved, SUP 17.2.2 G does not exempt the firm from reporting. The transaction report should identify the firm providing a service of portfolio management in the reporting firm field, the counterparty field (sometimes referred to as the counterparty one field) and the client/customer field (sometimes referred to as the counterparty two field).

All fields should be populated in accordance with the post MiFID transaction reporting rules and the technical specifications of the respective ARM(s).

32 Transaction Reporting User Pack (TRUP)

Data integrity

Transaction reports are an important component of our toolkit for investigating instances of market abuse, including insider trading. Your transaction reports may also be reviewed by other competent authorities (see section 1.1.4 for further information). In MarketWatch 28, we said that we expect firms to be fully compliant with our transaction reporting requirements. In this section, we provide some guidelines that may assist you in managing the integrity of your data.

8.1. Firms obligations

As stated in MarketWatch 29, firms must meet specified standards when reporting transactions to us in terms of the submission of reports and their content. To ensure accuracy and completeness, firms, under SYSC in the Handbook (Senior Management Arrangements, Systems and Controls)6 and under Principle 3 (Management and Control)7, must have appropriate systems and controls in place to enable them to comply with their regulatory obligations. The obligation of firms under SUP 17.3.6 (G) is to ensure they have successfully provided their transaction reports to us.8 The successful submission of reports to an ARM may be a step in this process; however, firms also need to take reasonable steps to verify that the ARM is successfully passing these reports on to us. Firms can check the completeness of the reports they send us by requesting a sample from our website (details provided below). SUP 17.4 and SUP 17 Annex 1 Minimum content of a transaction also detail the obligation firms have to ensure their transaction reports contain the required information and are provided in the correct format.

6 7 8

http://fsahandbook.info/FSA/html/handbook/SYSC http://fsahandbook.info/FSA/html/handbook/PRIN/2/1 http://fsahandbook.info/FSA/html/handbook/SUP/17/3

Financial Services Authority 33

8.2. Transaction reporting arrangements within firms

We have not sought to be prescriptive in terms of what controls and review processes firms should follow. These should be tailored to the firms activities. However, we would expect them to embody Principle 3 and comply with SYSC. This may, among other things, require: a clear allocation of responsibility for transaction reporting within an organisation; appropriate training for staff in transaction reporting; appropriate information produced on a regular basis to enable proper oversight of the transaction reporting process; testing wherever alternative reporting mechanisms are used; appropriate oversight of transaction reporting by compliance, including reviews, as part of the compliance monitoring programme; the nature and scale of the reviews and testing is tailored to the activities of the organisation and its transaction reporting arrangements; where reliance is placed on reporting by an ARM or another third party, periodic checks are carried out to ensure that the transactions are being correctly reported; and testing is comprehensive so that the full reporting process is tested not just part of it. This means that testing should include ensuring that the reports are properly submitted to us.

To help check reports have been successfully submitted to us, firms can request a sample of their transaction reports using an online form on our website.9 We encourage firms to periodically use this facility as part of their review process to compare the reports we receive with the reports they send from their own systems. Such an exercise should also involve checking the accuracy of the individual data elements and their compliance with the guidance we have issued. In particular, if you request a sample of your firms transaction reports, we would suggest you review whether: the counterparty field and customer/client identification fields have been correctly filled in depending on the trading capacity in which your firm executed the transaction (e.g. agent, principal, agency cross or principal cross); a BIC or FRN has been used if one exists for the counterparty or client (where your counterparty or client does not have either of these codes you will need to use an internal code. Where an internal code is used, it must

http://www.fsa.gov.uk/Pages/Doing/Regulated/Returns/mtr/managing/request/index.shtml

34 Transaction Reporting User Pack (TRUP)

be unique to that counterparty or client and used consistently across all instrument types and platforms for that counterparty or client); an FRN or BIC has been correctly tagged as an FRN or BIC in the counterparty code type fields; the unit price and, where applicable, strike price, contain values in the major currency unit (e.g. in pounds as opposed to pence); where the transaction is in an OTC derivative, a complete description has been provided in the instrument description field; and the buy/sell indicator has been completed correctly.

The above list is not intended to be prescriptive and we are aware firms will tailor their checks and validation process for their own purposes. However, any checks carried out on the content of reports must be made with reference to the transaction reporting rules and requirements under SUP 17 Annex 1, this document and the technical specifications of your chosen ARM(s).

8.3. Transaction reporting failures and errors

If your firm finds errors in transaction reports or fails to submit some or all of its transaction reports as required under SUP 17, we would expect you to notify us of: the nature and extent of the reporting failure, including the volume of transactions affected and length of time the problem has persisted; the causes of the failure and how it was identified; who within the firm has oversight responsibility for transaction reporting; your firms plan, including a timetable, to submit corrected transaction reports; details of your firms systems and controls around transaction reporting, including its processes for addressing response files from your chosen ARM(s); any weaknesses in your firms systems and controls and your plans to address these; and any planned audit or compliance monitoring reviews of transaction reporting and the scope of these.

Contact us by calling: 020 7066 6040 or by emailing: tmu@fsa.gov.uk. Where transaction reporting issues are identified, we will review the circumstances of the issue and decide on an appropriate course of action. Our policy is to require firms to submit corrected transaction reports at their earliest

Financial Services Authority 35

convenience in all cases. This is necessary as we require a full set of historic transaction reporting data for our surveillance activities. In those cases which we consider to be particularly serious, we will consider using our enforcement tools (e.g. a private warning, a public warning, a fine or a skilled person report, as defined under section 166 of the Financial Services and Markets Act). In such cases, we will consider the extent to which the firms systems and controls around transaction reporting were appropriate to the nature, scale and complexity of the business. We will also review the extent to which the identified failings are due to failings by individuals to exercise their oversight role where they undertake a significant influence function in respect of transaction reporting.

8.4. Resources available to firms

To help firms comply with their reporting requirements, in addition to this document, we provide further guidance on transaction reporting in MarketWatch as well as on our website at: www.fsa.gov.uk/transactionreporting. Should you have any queries after having reviewed our guidance, please contact our transaction reporting help desk on: 0207 066 6040 or email us at: tmu@fsa.gov.uk.

36 Transaction Reporting User Pack (TRUP)

Frequently Asked Questions (FAQs)

Here, we answer FAQs that may be helpful to all firms with a requirement to report transactions.

9.1. What else can we do to ensure we report correctly?

We encourage firms to regularly review the integrity of their transaction reports to ensure they are completing all the fields that are mandatory for the respective product types that are being transacted (in line with SUP 17 Annex 1) and we recommend they check that they are reporting all transactions reportable under SUP 17 to us. To help you review the integrity of your data we are happy to supply copies of transaction reports received so you can cross-check them against internal records. To request copies of transaction reports received please complete our online form at: http://www.fsa.gov.uk/pages/Doing/Regulated/Returns/mtr/managing/ request/index.shtml

9.2. We have started to trade a new product, what do we do?

We encourage you to ensure that before starting to trade a new product type, you fully consider the transaction reporting implications and, where required, make advance arrangements.

9.3. We may have misreported, what do we do?

You need to ensure you have the systems and controls in place, to ensure your data is accurate and to make sure we receive transaction reports on a timely basis. If you believe your firm may have misreported some transactions, inform our Transaction Monitoring Unit and your supervisor in writing as soon as you can.

Financial Services Authority 37

9.4. What about UK public holidays?

Under SUP 17.2.7, you must report the transaction by the close of the working day following the day on which that transaction took place, e.g. transactions entered into on the Friday before a Bank Holiday Monday will need to be reported by the end of the Tuesday.

9.5. What time is the close of the working day?

A firm will be deemed to have reported a transaction in line with SUP 17.2.7 R where that transaction report has been accepted by an approved reporting mechanism, or regulated market or MTF that reports to us by the end of that reporting channels working day. For further clarification, you should contact your respective ARM(s).

9.6. Are internal transactions reportable?

Transactions entered into within the same FSA-authorised entity do not need to be reported.

9.7. Are grey market transactions reportable?

A transaction in a financial instrument admitted to trading on a regulated market, or a prescribed market, or in any OTC derivative the value of which is derived from or is otherwise dependent on an equity or debt-related financial instrument that is admitted to trading on a regulated market, or on a prescribed market undertaken in the grey market, is transaction reportable.

9.8. Is over reporting ok?

We recognise that separating out transactions that are not reportable may be costly. So we are content for firms to over report transactions.

9.9. What about COBS 16 Annex 1 R?

COBS 16 Annex 1 R states that certain information must be reported to a retail client in line with SUP 17 Annex 1R. However, in some instances the format specified by SUP 17 is not relevant to the needs of the customer. Please see the our response section under 19.9 of Policy Statement 07/6.

9.10. We have concerns about certain rules, what should we do?

Any firm with concerns about their ability to meet any transaction reporting rule should contact their supervisor and the Transaction Monitoring Unit as soon as possible.

38 Transaction Reporting User Pack (TRUP)

9.11. Are results of option transactions reportable?

The MiFID definition of a transaction excludes the exercise of options and so these transactions are not reportable.

9.12. Are primary market transactions reportable?

The MiFID definition of a transaction excludes primary market transactions in financial instruments falling within Article 4(1)(a) and (b) of MiFID, such as issuance, subscription and allotment and so these transactions are not be reportable.

9.13. Are the individual fund allocations reportable?

As we outlined in our Policy Statement PS07/2, when a broker reports a transaction on behalf of a client of a firm providing a service of portfolio management, the report submitted by the broker should identify the firm providing the service and not the underlying client. It is therefore only necessary to report the bulk trade; the allocations for each respective client are not reportable.

9.14. Are in specie transfers reportable?

In specie transfers involve the direct transfer of assets into or out of a portfolio or trust. Often in specie transfers are used as a means of reducing the costs involved in the sale or purchase of assets. On this basis, we do not consider that in specie transfers should be reported, as long as they do not involve a change in beneficial ownership. In addition, there may be cases where a technical change in beneficial ownership occurs but there is no requirement for transaction reporting. For example, in specie transfers in and out of unit-linked insurance funds of assets involve a change in beneficial ownership since the assets are owned by the insurance company and the policyholder only has contractual rights valued on the assets. Nonetheless, we would not require reporting of such transfers. If you are in any doubt as to whether a particular transfer should be reported, please contact the Transaction Monitoring Unit.

9.15. What about when we outsource a portfolio?

If you have outsourced the management of a portfolio to another EEA MiFID investment firm providing a service of portfolio management, then it has an obligation to report to its relevant competent authority in compliance with the rules of that competent authority. If you have further queries related to outsourcing a portfolio, please contact the Transaction Monitoring Unit by email at: tmu@fsa.gov.uk, or by calling the transaction reporting helpline on: 02070666040.

Financial Services Authority 39

9.16. What about when our ARM has a technical problem?

Under our rules (SUP 17.2.5 R), it is the responsibility of the reporting firm to ensure the accuracy of the information contained in a transaction report. However, we recognise that there may be instances where the firm takes all reasonable efforts to report correctly via an ARM, but the ARM fails to transmit the correct information to us. In these instances, we recognise that this is not a fault of the firm.

9.17. What about mirrors of on exchange derivatives?

Instruments that mirror the specifications of on exchange equity or debt-related derivatives, but that are not admitted to trading on a regulated market, are considered to be OTC derivatives for transaction reporting purposes. Transactions in these instruments are reportable and should be identified in a transaction report in accordance with the requirements of OTC derivatives set out in SUP17 and the TRUP.

9.18. What about when we act as an introducing broker?

Where a firm acts as an introducing broker only and does not act in a principal or agency capacity, 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 us.

40 Transaction Reporting User Pack (TRUP)

10

Glossary of terms

Agency cross

Where the reporting firm acted as agent for both the selling and buying counterparties and the single transaction report represents both of these transactions. Approved Reporting Mechanism Swift Bank Identification Code Contract for difference FSA Reference Number The Investment Services Directive 93/22/EEC ISO 6166 International Securities Identifying Number International Organization for Standardization Chapter 17 (Transaction Reporting) of the FSA Handbook Supervision Manual The FSAs Transaction Monitoring Unit The Directive 2004/39/EC on Markets in Financial Instruments A derivative that is traded over-the-counter and is not admitted to trading on any market. A market that has been prescribed by Treasury as a market that comes within the scope of the market abuse regime contained in Part VIII of FSMA. A principal cross is defined to be where the reporting firm has acted simultaneously for two counterparties as principal in a single product, at the same price and quantity and the single transaction report represents both of these transactions. Transaction Reporting User Pack
Financial Services Authority 41

ARM BIC CFD FRN ISD ISIN ISO SUP 17 TMU MiFID OTC derivative Prescribed market

Principal cross

TRUP

11

Index

accrued interest, 21 agency, 12, 17, 29, 30, 32, 40 agency cross, 18 aggregated account, 23, 29 allotment. See primary market transactions amend, 27 amendment. See amend ARM, 15, 24, 32, 40, 41 average price account, 23, 29 basis points, 26 BIC. See Swift Bank Identifier Code bond, 21, 26 branch, 13 bulk trade, 30, 39 buy/sell indicator, 17 cancel, 27, 28 cancellation. See cancel cancellation flag, 24 CCP. See central counterparty central counterparty, 18, 22

CESR, 10, 11, 13 CFD. See contracts for difference clean price, 21 client, 5, 11, 12, 16, 17, 28, 29, 32, 38, 39, 40 close of the working day, 38 commission, 21 commodity, interest rate and FX derivatives, 10 competent authority, 12, 13, 30 contract for difference, 25 counterparty field, 18, 29-30 counterparty two. See customer/client identification currency. See Price Notation customer/client identification field, 18, 29, 30 debt, 9, 19, 21, 38 default time, 16 deliverable obligations, 26 derivative type, 19, 24, 25, 26 derivatives, 19, 21

42 Transaction Reporting User Pack (TRUP)

discretionary basis, 12, 30, 32 equity, 9, 19, 24, 25, 26, 38 execute, 11, 29 execution only, 32 exercise of options, 39 exercise price. See strike price external broker, 16, 23 FAQs. See frequently asked questions fees, 18 Frequently Asked Questions, 37 FRN. See FSA Reference Number future, 20 grey market, 38 in specie transfers, 39 insider trading, 5 instrument description field, 24, 25, 26 instrument identification field, 19 instrument type, 19, 24, 25, 26 inter fund transaction, 32 internal account, 23 internal transactions, 38 introducing broker, 40 ISIN, 19, 26, 41 ISO 10383. See MIC ISO 6166 ISIN. See ISIN issuance. See primary market transactions issuer, 19, 26 lots. See quantity

market abuse, 5, 6, 41 Market Identifier Code. See MIC market manipulation, 5 market-facing firms, 11 MarketWatch, 7 maturity date ,16, 26 Member State. See competent authority MTF, 14 multi-lateral trading facility. See MTF multiple trading venues, 23 newsletter. See MarketWatch nominal value. See quantity off market. See XOFF option, 20, 24 OTC derivative, 9, 41 over reporting, 38 portfolio management, 11, 30, 32, 39 prescribed market, 9, 19, 20, 21, 38 price, 18, 21, 29, 41 primary market transactions, 39 principal, 11, 12, 16, 17, 30, 40 principal cross, 18, 41 quantity, 18, 26, 41 reasonable grounds, 12, 30 reference obligation, 26 regulated market, 9, 11, 19, 20, 21, 23, 24, 38 reporting agent, 15

Financial Services Authority 43

reporting by fax or email, 14 reporting firm, 15 SABRE, 5 spread, 26 spread bet, 19, 20, 24 strike price, 19 subscription. See primary market transactions SUP 17, 7, 37, 38, 41 SUP 17.1.4 R, 11 SUP 17.2.2 G, 11, 12, 30, 32 swap, 26 Swift Bank Identifier Code, 15, 30 technical specifications, 7, 24, 32 tick value, 21 trading capacity, 17 trading date, 15, 16 trading time, 16 trading venue, 23 Transaction Monitoring Unit, 5, 8, 37, 41 Transaction reference number, 23 Transaction Reporting User Pack. See TRUP TRUP, 7, 8, 41 Underlying instrument identification, 19 unit price, 21, 26 units. See quantity volume. See quantity warrant, 19, 20, 21
44 Transaction Reporting User Pack (TRUP)

XOFF, 23 XXXX, 23

The Financial Services Authority 25 The North Colonnade Canary Wharf London E14 5HS Telephone: +44 (0)20 7066 1000 Fax: +44 (0)20 7066 1099 Website: http://www.fsa.gov.uk
Registered as a Limited Company in England and Wales No. 1920623. Registered Office as above.