Transaction Reporting User Pack
Transaction Reporting User Pack
Transaction Reporting User Pack
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
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.
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.
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.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.
the compliance, systems and operational areas, to the extent that they are involved in transaction reporting.
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/
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.
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.
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.
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.
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
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.
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).
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.
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.
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.
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
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.
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.
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.
Cancellation flag
Please see section 7.3.1 and submit your cancellations in accordance with the technical specifications provided by your ARM(s).
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.
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.
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.
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.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.
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.
field using the code INTERNAL only) to the respective clients (identified in the customer/client identification field).
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).
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).
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.
6 7 8
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
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).
Contact us by calling: 020 7066 6040 or by emailing: [email protected]. 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
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.
Here, we answer FAQs that may be helpful to all firms with a requirement to report transactions.
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
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
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.