Transaction Reporting User Pack

Financial Services Authority

Transaction ReportingUser Pack (TRUP)

Version 2effective from 21 September 2009

1. Introduction 5

1.1. Why transaction reports are important to the FSA 5

1.1.1. Monitoring for market abuse and market manipulation 5

1.1.2. Firm supervision 6

1.1.3. Market supervision 6

1.1.4. Exchange with other EEA competent authorities 6

1.1.5. Other 6

1.1.6 History 6

2. The Transaction Reporting User Pack (TRUP) 7

2.1. What does the TRUP cover? 7

2.2. What is not covered? 7

2.3. Who should read the TRUP? 7

2.4. FSA contacts 8

2.5. Have your say 8

3. Reportable instruments 9

4. Obligation to make a transaction report 11

4.1. Firms providing a service of portfolio management 11

4.2. Firms providing Direct Market Access (DMA) 12

5. Obligations for branches of EEA firms 13

6. How to send us transaction reports 14

7. How to complete a transaction report 15

7.1. Transaction report fields guidelines 15

• Reporting firm 15

Contents

© The Financial Services Authority 2009

• Trading date 15

• Trading time 16

• Buy/Sell indicator 17

• Trading capacity 17

• Instrument identification 19

• Instrument description 19

• Underlying instrument identification 19

• Instrument type 19

• Maturity date 20

• Derivative type 20

• Put/call 20

• Strike price 20

• Price multiplier 21

• Unit price 21

• Price notation 21

• Quantity 22

• Counterparty and customer/client identification fields 22

• Venue identification 23

• Transaction reference number 23

• Cancellation flag 24

7.2. Guidelines on reporting OTC derivatives 24

7.2.1. Spread bets 24

7.2.2. Spread bets on an option on an equity 24

7.2.3. Contracts for difference 25

7.2.4. Contract for difference on an option on an equity 25

7.2.5. Credit default swaps 26

7.2.6. Complex derivatives 26

7.2.7 Equity forwards 27

7.3. Guidelines on reporting certain scenarios 27

7.3.1. Cancelling a previously submitted transaction report 27

7.3.2. Amending the time or trade date of a previously submitted transaction report 27

7.3.3. Amending a previously submitted transaction report 28

7.3.4. OTC derivative events 28

7.3.5. Contract for difference and spread bet white label providers 28

7.3.6. Multiple executions for a client order 28

7.3.7. Orders filled by external brokers 29

7.3.8. Aggregated transactions 29

7.3.9. Average price transactions 29

7.4. Portfolio managers as counterparties 30

7.4.1. Portfolio manager transactions 30

8. Data integrity 33

8.1. Firms’ obligations 33

8.2. Transaction reporting arrangements within firms 34

8.3. Transaction reporting failures and errors 35

8.4. Resources available to firms 36

9. Frequently Asked Questions (FAQs) 37

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

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

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

9.4. What about UK public holidays? 38

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

9.6. Are internal transactions reportable? 38

9.7. Are ‘grey market’ transactions reportable? 38

9.8. Is over reporting OK? 38

9.9. What about COBS 16 Annex 1 R? 38

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

9.11. Are results of option transactions reportable? 39

9.12. Are primary market transactions reportable? 39

9.13. Are the individual fund allocations reportable? 39

9.14. Are ‘in specie’ transfers reportable? 39

9.15. What about when we outsource a portfolio? 39

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

9.17. What about mirrors of on exchange derivatives? 40

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

10. Glossary of Terms 41

11. Index 42

Introduction1

Financial Services Authority 5

We have produced this pack in conjunction with various firms and tradebodies. It aims to bring together the detailed instructions and guidelineswe have published previously, providing firms with a consolidated pointof reference to help them understand and comply with their transactionreporting obligations. Firms should therefore use the information containedin this guide together with any subsequent guidance issued on our website orthrough 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 reportscontaining mandatory details for those transactions by the end of the followingbusiness day. At the end of each working day, transaction reports received fromfirms are loaded in to our transaction monitoring system, SABRE II. This isused 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 investigatesuspected market abuse (insider trading and market manipulation) in supportof our statutory objectives of maintaining confidence in financial markets andreducing financial crime. SABRE II users in the Transaction Monitoring Unit(TMU) and the Market Conduct teams may, for example, use the data to viewall transactions executed by a given firm, in a given stock, over a given periodor to view all transactions in a given stock, for a given client, over a givenperiod, 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, thetransaction reports are a key piece of the jigsaw in enabling us to determinewhether there is a case of market abuse that warrants enforcement action by

6 Transaction Reporting User Pack (TRUP)

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

1.1.2. Firm supervision

Firm supervisors may view firms’ transaction reports to help identify andinvestigate 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 tomarket confidence that may arise from significant market developments.Transaction reports provide us with useful market information that can helpwith such surveillance, e.g. statistics showing rate of growth in the use ofcertain instruments.

1.1.4. Exchange with other EEA competent authorities

MiFID requires us to exchange certain transaction reports with otherEEA competent authorities through the Transaction Reporting ExchangeMechanism (TREM) of the Committee of European Securities Regulators(CESR). We send transaction reports from branches of non-UK EEA firms totheir respective home competent authority and we send them to the mostrelevant 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 firstversion, which was published in July 2007.

Document Effective date

TRUP Version 1 November 2007

The Transaction ReportingUser Pack (TRUP)2


2.1. What does the TRUP cover?

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

2.2. What is not covered?

The TRUP is not intended to be a replacement for SUP 17 and theHandbook glossary and it will not provide technical specifications for theformat of transaction reports. We would expect firms to read the TRUP inconjunction with SUP17, the Handbook glossary and the technicalspecifications of their respective Approved Reporting Mechanism (ARMs).

Whenever there is a particular transaction reporting issue or concern toaddress, we will continue to publish articles in the MarketWatch newsletter.Firms are encouraged to review all MarketWatch newsletters. You candownload 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: [email protected].

For further information, please see the transaction reporting section of ourwebsite at: http://www.fsa.gov.uk/transactionreporting.

2.3. Who should read the TRUP?

We expect compliance departments and compliance officers to ensure that theTRUP is fully understood and that any necessary amendments to transactionreporting processes are initiated. It should be distributed to all relevant staff in

http://www.fsa.gov.uk/transactionreporting

mailto:[email protected]

http://www.fsa.gov.uk/Pages/About/What/financial_crime/market_abuse/

http://www.fsa.gov.uk/Pages/About/What/financial_crime/market_abuse/


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

2.4. FSA contacts

If you have any transaction reporting queries, please contact our TransactionMonitoring Unit on 020 7066 6040 or by email at [email protected].

2.5. Have your say

We would like the TRUP to be a document that continues to develop afterMiFID. To inform us of issues you would like to be included in future, pleaseemail us at [email protected] or call us on 020 7066 6040.

We produced this version of the TRUP in conjunction with various firms andtrade bodies and would like to thank all parties involved for their willingnessto engage with us and for their valuable assistance.



Reportable instruments3


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

Under SUP 17.1.4 R, a firm that executes a transaction must report the detailsto us if it is executed:

(1) in any financial instrument admitted to trading on a regulated market1 orprescribed market (whether or not the transaction was carried out on sucha market); or

(2) in any Over The Counter (OTC) derivative, the value of which is derivedfrom or is otherwise dependent on an equity or debt-related financialinstrument that is admitted to trading on a regulated market or on aprescribed 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 multipleequity or multiple debt-related financial instruments, except where themultiple financial instruments are all issued by the same issuer.For example, we no longer require firms to transaction reportOTC 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 aregulated market or multi-lateral trading facility (MTF) through whosesystems 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.

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


http://mifiddatabase.cesr.eu/


A list of trading venues that report directly to us is available on ourwebsite at: http://www.fsa.gov.uk/Pages/Doing/Regulated/Returns/mtr/regulated_markets/index.shtml.

c. Transactions in commodity, interest rate and foreign exchange derivativesare not reportable

It has been agreed by CESR and the European Commission thatcompetent authorities need not require firms to report transactions innon-securities derivatives (i.e. commodity, interest rate and FX derivatives)admitted to trading on regulated markets. We do not require firms toreport transactions in these derivatives and we will work with LIFFE, theLondon Metal Exchange (LME) and Intercontinental Exchange (ICE) toensure that, where another competent authority requires information ontransactions in these derivatives, it is made available.

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

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

Obligation to make a transaction report4


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

When a firm executes a transaction in an instrument that is reportable underSUP 17.1.4 R it needs to report that transaction to us. MiFID has not definedthe term execute. However, we interpret this in light of Level 3 guidelines fromCESR to mean that a firm will ‘execute’ a transaction in the following scenarios:

a. a firm transacts directly with an execution venue2 (immediatemarket-facing firms); or

b. a firms that falls outside (a) transacts on its own account (whetherthrough a regulated market or multi-lateral trading facility or outside of them).

In addition, we will require the identity of the ultimate client on whosebehalf the transaction is carried out, or the identity of the firm dealing withthe 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 onits own account (either on its own behalf or on behalf of a client, (that is asprincipal)) or for the account and on behalf of a client (that is as agent) thetransaction must be reported and the client must be identified.

Text in this section may be subject to change since CESR intends to undertakea 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 providinga service of portfolio management as relying on a third party to make thetransaction report and so would not be required to make the transaction reportitself. 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 specificallyrecommended the transaction to the client, and the firm has reasonablegrounds to be satisfied that another party (typically, the broker) will report to the FSA or another competent authority, there is no requirement for anadditional report to be submitted by the firm providing the service of portfoliomanagement. In these circumstances ‘reasonable grounds’ could includemaking 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. Forinformation 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 CESR’sconsultation on defining ‘execution of a transaction’, the consultation closeson 1 October 2009.

4.2. Firms providing Direct Market Access (DMA)

DMA is where a customer uses a firm’s facilities to enter orders directly intoan exchanges order book, even though they have no membership of thatexchange. If the order is hit, it registers as a transaction in the name of thefirm. Firms may subsequently make another transaction to transfer stockownership to the client. These transactions should be reported by the firmwhose facilities are being used to make the trade. One transaction shouldidentify the market counterparty in a principal transaction and a secondprincipal transaction should identify the entity using the DMA facilities.

Where the entity using the DMA facility is a MiFID investment firm, theentity should also make a transaction report (unless the MIFID investmententity is acting as a Portfolio manager undertaking transactions on adiscretionary basis).

Obligations for branchesof EEA firms5


All transactions executed by branches of EEA firms where the service isprovided within the UK should be reported to us. Where a transaction isexecuted outside of the UK, the transaction can be reported to either thehome Member State competent authority or to us as the host Member Statecompetent authority, at the reporting firm’s discretion.

Following discussion among the Member States, CESR issued guidelinespermitting branches to make transaction reports to the host Member Stateregulator only. CESR recognised that, from a practical point of view, it may be burdensome for branches to be obliged to report their transactions to twodifferent national regulators. So a UK branch of an EEA firm can choose toreport all its transactions to us. Likewise, the EEA branch of a UK firm mayreport its transactions to the local regulator rather than us.

The branch is required to provide transaction reports in the format requiredby the Member State it is submitting transaction reports to.

How to send ustransaction reports6


A regulated market or MTF has the option of reporting to us transactionsthat have been completed through their systems. A list of these trading venuesis available on the transaction reporting section of our website. For all othertransactions you may use any one or more of the ARMs to send transactionreports to us. Reporting by fax or email is not permissible. For moreinformation on ARMs please see the transaction reporting section of ourwebsite at:



How to complete a transaction report7


We use transaction reports for a variety of purposes and to perform thesefunctions effectively it is vital that firms provide us with accurate data.Transaction reports should contain all mandatory fields applicable to thetransaction being reported in line with new SUP 17 Annex 1, Minimumcontent of a transaction. In this section, we will provide some additionalguidelines on how some of these fields should be populated and guidelineson how transactions in certain instruments and OTC derivatives should bereported. Where we refer to specific fields, firms should complete these in the formats described or be assured that these will be the formats that theirARM(s) will use when sending their transaction reports to us. Please notethat field names and classifications may differ across ARMs. Forclarification, please contact your respective ARM(s).

Since the implementation of MiFID, we are also required to transfer certaintransaction reports to other competent authorities. This means that, as well asus, 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 BankIdentifier Code (BIC) of the firm that executes the transaction and on whosebehalf the transaction report is being made. If you have appointed a reportingagent to submit transaction reports on your firm’s behalf, please ensure thisfield identifies your firm and not the reporting agent.

• Trading date

The trading date for a transaction entered in to the trading date field must bepresented in the correct format as specified by that ARM (e.g. in UK formatrather 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 theday in UK time. For example, a trade executed in Tokyo on Wednesday21 February 2007 at 08:30 local time would be reported to us with theUK trading date, Tuesday 20 February 2007 and UK time 23:30.

Failure to ensure the trading date and maturity date are reported to us inUK time (i.e. in Greenwich Mean Time (GMT) or, during the summer, inBritish Summer Time (BST)) may cause a one-day contract traded outside ofthe UK to be rejected by your reporting system(s) as the contract may appearto be expiring before the trading date.

• Trading time

This field should contain the time at which the transaction took place. Firmsshould note that, where a transaction has been undertaken outside of the UK,the trading time should reflect UK time. The trading time should therefore bereported in GMT or, during the summer, in BST. Firms may need to contacttheir ARM(s) to see whether they need to switch from/to GMT/BST orwhether their ARM(s) will meet this requirement for them.

Firms must ensure we receive the trading time information as in ISO 8601Time Format HH:MM:SS and they should contact their ARM(s) to see if thisrequirement is met.

If your firm works a client’s order as riskless principal and holds the stock on your own book until the order is complete, you must book the clienttransaction at the time you have agreed with the client.

When a firm uses an external broker to fill an order on a market and thatexternal broker fills the order in several transactions, the time of trade in thetransaction reports should reflect the time at which the firm becomes thebeneficial owner (i.e. the allocation time).

Where the trading time is not made available, the default time of 00:01:00UK time must be used (this value will need to be presented in the formatapplicable to the ARM(s) used). Using this default time will ensure that thesetransaction reports are picked up during our monitoring of trading before aprice 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 thisinformation correctly.

Where reporting firms are unable to meet the requirement to populate thetrading time field with the correct trading time and instead provide the time atwhich the trade is entered into their system, firms should make best efforts tominimise any discrepancy between the trading time and the booking time.

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

• Buy/sell indicator

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

– Firm X buys as principal from Client Y. Firm X would report a transactionwhere the dealing capacity is principal, Client Y is identified in thecounterparty field and the buy/sell indicator is ‘buy’.

– Firm X sells to Firm A on behalf of Client Y in an agency capacity. Firm Xwould report a transaction where the dealing capacity is ‘agent’, Firm A isidentified 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, thereporting 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 fieldsfor each trading capacity.

Counterparty field (also knownas the counterparty one field)

Customer/client identificationfield (also known as thecounterparty two field)

Principal • The BIC, FRN or internal code(where a BIC/FRN has not beenassigned to that entity) of themarket counterparty/executingor clearing broker/client; or

• the BIC of the centralcounterparty (e.g. LCHLGB2EXXXfor LCH.CLEARNET).3

Blank

Principalcross

• The BIC, FRN or internal code(where a BIC/FRN has not beenassigned to that entity) of themarket counterparty/executingor clearing broker/client; or

• the BIC of the centralcounterparty (e.g. LCHLGB2EXXXfor LCH.CLEARNET); or

• ‘INTERNAL’.

• The BIC, FRN or internal code(where a BIC/FRN has not beenassigned to that entity) of thecounterparty or underlyingclient; or

• ‘INTERNAL’.



An agency cross is defined to be where the reporting firm acted as agent forboth the selling and buying counterparties and the single transaction reportrepresents both of these transactions. For example, to report in a singletransaction report a ‘buy’ as agent on behalf of Client A and a ‘sell’ as agenton 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 thecounterparty field (in this scenario the buy/sell indicator would be ‘sell’) andClient B would be in the customer/client identification field.

A principal cross is a transaction type, which is defined to be where thereporting firm simultaneously executes a ‘buy’ and a ‘sell’ as principal in asingle product, at the same price and quantity and the single transactionreport represents both of these transactions. For example, to report in a singletransaction 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 tradingcapacity would be principal cross, the central counterparty would be in thecounterparty field (in this scenario, the buy/sell indicator would be ‘buy’) andFirm A would be in the customer/client identification field.

Firms should note there is no requirement to report transactions matchingthe definition of an agency cross or the definition of a principal crossoutlined above in a single transaction report. However, reporting suchtransactions in a single transaction report may help firms to reduce the feescharged by their ARMs.

Counterparty field (also knownas the counterparty one field)

Customer/client identificationfield (also known as thecounterparty two field)

Agency • The BIC, FRN or internal code(where a BIC/FRN has not beenassigned to that entity) of themarket counterparty/executingor clearing broker/underlyingclient; or

• the BIC of the centralcounterparty (e.g. LCHLGB2EXXXfor LCH.CLEARNET); or

• ‘INTERNAL’.

• The BIC, FRN or internal code(where a BIC/FRN has not beenassigned to that entity) of theunderlying client; or

• ‘INTERNAL’.

Agency cross

• The BIC, FRN or internal code(where the BIC/FRN have notbeen assigned to that entity) of Client 1; or

• ‘INTERNAL’.

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


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

• Instrument identification

Where the subject of a transaction is a financial instrument admitted totrading on a regulated market or prescribed market that is an equity, a debtinstrument or a warrant, or a derivative admitted to trading on a regulatedmarket where the industry method of identification is the ISIN, this field mustcontain an ISO 6166 ISIN.

Where the subject of a transaction is an OTC derivative where the underlyingis a financial instrument admitted to trading on a regulated market orprescribed market, the instrument identification field must be blank.

• Instrument description

When reporting a transaction in an OTC derivative, you should supply afull description of the security in the following format: reference security,derivative type and, where applicable, strike price and maturity date. Forfurther 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 whenreporting a transaction in an OTC derivative unless the OTC derivative is inrespect of an index4 or multi-name basket.

This field must be used to identify the ultimate underlying instrument. Forexample, a spread bet on an option on an equity must have the underlyingISO 6166 ISIN identified in this field.

• Instrument type

This field must contain the instrument type of the ultimate underlyinginstrument when reporting a transaction in an OTC derivative (e.g. a spreadbet on an equity would have an instrument type of ‘A’ for equity and acontract for difference on an option on an equity would have an instrumenttype of ‘A’ for equity).

This field is not required for exchange traded instruments.

Where the underlying debt instruments have all been issued by the sameissuer, e.g. a single name CDS the instrument type should be ‘B’ for bond.

http://www.fsa.gov.uk/pubs/handbook/hb_notice85.pdf


• Maturity date

This field must contain the maturity/expiry/delivery date when you arereporting a transaction in an OTC derivative that is an option, future,warrant, spread bet, credit default swap, other swap, spread bet on an optionon an equity, or a contract for difference on an option on an equity. Where thederivative type is a spread bet on an option on an equity or a contract fordifference on an option on an equity, this field must contain the expiry date ofthe option.

This field should not be populated for financial instruments admitted totrading on a regulated market or prescribed market where the industrymethod 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 inan OTC derivative, e.g. option (O), future (F), warrant (W), spread bet (X),contract for difference (D), credit default swap (Z), other swap (S), spreadbet on an option on an equity (Q), contract for difference on an option onan equity (Y) or complex derivative (K). For guidelines on reportingtransactions in OTC derivatives see section 7.2.


• Put/call

This field must contain either ‘P’ for put or ‘C’ for call when reporting atransaction 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 acontract for difference on an option on an equity this field must be used toindicate whether the option is a put or a call option.



• Strike price

This field must contain the strike price when reporting a transaction in anOTC derivative that is an option, a warrant, a spread bet on an option on an


equity, or a contract for difference on an option on an equity. Where thederivative type is a spread bet on an option on an equity or a contract fordifference on an option on an equity, this field must be used to indicate thestrike price of the option. This field is sometimes referred to as ‘exercise price’.



• Price multiplier

The price multiplier is the number of underlying instruments that arerepresented by a single derivative contract, e.g. if a warrant contractrepresents 50 units of the underlying instrument, then the price multiplierequals 50.

• Unit price

This field must contain the unit price of the transaction. Firms may report theprice 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 netprice is the only price available to the trade and in such circumstances the netprice may be reported.

The trade price for a transaction in a bond or a bond option should be thepercentage clean price (i.e. the actual transaction price not including anycommission 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 thanpence, euros rather than cents, etc.

For derivatives, the unit price must be the decimal value per contract, not thetick value.

• Price notation

This field must contain the alpha ISO 4217 currency code of the currency inwhich the unit price is expressed. If in the case of a bond or other form ofdebt the price is expressed as a percentage of nominal value, then this fieldmust 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. Forspread bets, the price notation field will be the currency in which the unitprice of the underlying instrument is expressed.


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

• Quantity

This field must contain the volume of the transaction, e.g. the number of unitsof the financial instrument, the nominal value of bonds or bond options, thenumber 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 pointmovement in the underlying instrument. For example, a £10 per point spreadbet in Vodafone common stock at £1.35 and closed at £1.55 would result in aprofit of £200 (£10 x 20 point rise) and so the quantity would be £10 forboth the buy and sell transactions. Where the spread bet is denominated in aforeign currency, the quantity field should still be the amount of the bet insterling, foreign currency amounts being converted at spot rates.

Where the subject of the transaction is an option, the quantity field mustcontain the number of contracts traded. For example, a trade of 100 optioncontracts on BT where each option contract equals rights over 1,000 shareswould 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 fieldand should contain a code to identify your counterparty.

The customer/client identification field is sometimes referred to as thecounterparty two field. This field must be blank when reporting a transactionwhere the trading capacity is ‘principal’.5

Where a BIC or FRN exists for your counterparty or client, you must use oneof these codes. Where your counterparty (or client) does not have either ofthese codes, you will need to use an internal code. In these circumstances theinternal code must be unique to that entity and must be used consistentlyacross all instrument types and platforms for that entity. Where thecounterparty is a central counterparty (CCP), e.g. LCH, the BIC for thatcentral counterparty must be used. A list of EEA central counterparties andtheir BICs can be found under the ‘Central Counterparties’ section of theCESR MiFID Database at: http://mifiddatabase.cesr.eu/.

A BIC should be eight or 11 alphanumeric characters long. Firms shouldcontact their reporting system(s) for confirmation of whether eight characterBICs should be appended with XXX.

We recognise that some firms may have more than one BIC. Any of theavailable BICs can be used to identify these firms.

http://mifiddatabase.cesr.eu/


For details of how to obtain a feed of BICs or look up BICs online, please goto the Swift website at: www.swift.com. For details of how to obtain a feed ofFRNs, 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 tradingacross all products and thereby gauge whether a firm or client’s transaction isconsistent 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 greatlyreduce the number of requests for information that we make to firms. This willhelp 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 IdentifierCode (MIC) where the transaction was executed on a regulated market or amulti-lateral trading facility (MTF).

This field must contain the code ‘XOFF’ where the transaction is in afinancial instrument admitted to trading on any market, but the transactionis made off market.

This field must contain the code ‘XOFF’ where the firm executes a transactionin a financial instrument admitted to trading on a regulated market orprescribed market using an external broker and the identity of the tradingvenue is not made available before the reporting deadline .

This field must contain the code ‘XXXX’ where the transaction is in anOTC derivative.

This field should contain the BIC of the systematic internaliser where thereporting firm or the counterparty executed the transaction as a systematicinternaliser.

Firms often need to execute transactions on multiple trading venues tosatisfy a single client order for a single particular instrument. While the firmneeds to report each of the market side transactions and populate the venueidentification field in accordance with the above guidelines, it may report theresulting aggregate transaction to the client using the code ‘XOFF’.

• Transaction reference number

This field must contain a unique reference, internal to the firm making thereport, which will enable the firm to provide us with more information aboutthe transaction should we require it. The format and content of thetransaction reference number is at the firm’s discretion.

http://www.fsa.gov.uk/register

http://www.swift.com


• Cancellation flag

Please see section 7.3.1 and submit your cancellations in accordance with thetechnical 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 transactionsshould be reported to us. Transaction reports should contain all mandatoryfields in line with SUP 17 Annex 1. Where we refer to specific fields in a transaction report, firms should complete these fields in the formatsdescribed 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. Reportingtransactions in line with these guidelines will greatly reduce the number ofrequests for information that we make to firms. This will help to reduce theresources that firms need to dedicate to those enquiries.

Firms should note that following Chapter 5 of CP08/16: QuarterlyConsultation (No. 18), Handbook 85 and MarketWatch (No.29, page 9),transactions in OTC derivatives, the value of which is derived from or isotherwise dependent on multiple equity or multiple debt-related financialinstruments – except where the multiple financial instruments are all issued bythe same issuer – are not reportable.

7.2.1. Spread bets

Where the transaction is in an OTC derivative that is a spread bet, thederivative type field must contain ‘X’ for ‘spread bet’, unless it is a spread beton an option on an equity (see section below).

• The instrument type must classify the instrument type of the underlyinginstrument (e.g. a spread bet on an equity would have an instrument typeof ‘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 ‘BETVodafone’.

• The underlying instrument identification field must contain the ISIN ofthe 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 anoption admitted to trading on a regulated market, where the underlying is asingle equity admitted to trading on a regulated market or prescribed market.


Where this derivative type classification is used, the:

• derivative type must be ‘Q’;

• instrument type should classify the type of the ultimate underlyinginstrument (e.g. a spread bet on an option on an equity would have aninstrument type ‘A’ for ‘equity’);

• text in the instrument description field should begin with the full name ofthe underlying instrument;

• underlying instrument identification field should contain the ISIN of theultimate underlying (e.g. when reporting a transaction in a spread bet on aLIFFE 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 indicatethe 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 itis a contract for difference on an option on an equity (see section below).

• The instrument type must classify the instrument type of the underlyinginstrument (e.g. a CFD on an equity would have an instrument type ofequity).

• The text in the instrument description field should begin with the fullname of the underlying instrument, e.g. ‘Vodafone CFD’ rather than ‘CFDVodafone’.

• The underlying instrument identification field must contain the ISIN ofthe underlying instrument.

The Complex OTC Derivatives Working Group is reviewing the scope of thisderivative type classification and will draft a definition of CFD to ensure thattotal return swaps are included in this classification. Once this work iscomplete, 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 onan option admitted to trading on a regulated market where the underlying is asingle equity admitted to trading on a regulated market or prescribed market.

Where this derivative type classification is used, the:

• derivative type must be ‘Y’;


• instrument type field must be ‘A’ for ‘equity’;

• text in the instrument description field should begin with the full name ofthe underlying instrument;

• underlying instrument identification field must contain the ISIN of theultimate underlying equity; and

• the maturity date, put/call indicator and strike price fields must be used toindicate 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 referenceentity.

• The quantity field must contain the nominal size of the transaction.

• The unit price field must contain the spread at which the transaction wasexecuted, 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 thesame issuer, the instrument type should be ‘B’ for bond and the underlyinginstrument identification field should contain either the ISIN of thereference 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 aretoo 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 thetransaction is entered in to;

• an option or warrant that has multiple puts and calls;


• an option that allows the purchaser to choose whether the option is a callor a put on a particular date in the future (often referred to as a chooseroption);

• an option or a warrant and the strike price is not known at the time thetransaction is entered into and is instead based on the average price overan averaging period.

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

7.2.7. Equity forwards

Where the transaction is in an equity forward, the transaction should bereported 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. Forclarification, 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 mustsubmit a ‘cancellation’ transaction report as soon as possible. The ‘cancellation’transaction report should contain values identical to all those contained in theoriginal transaction report except for the report status field, which you shoulduse to mark the transaction report as a ‘cancellation’ and any informationrequired by your ARM(s).

7.3.2. Amending the time or trade date of a previously submittedtransaction report

Where there is a requirement to amend the trading time or date of a previouslysubmitted transaction report, you will need to submit a ‘cancellation’transaction report and submit a ‘new’ transaction report with the correctedtrading 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 thetransaction reference number and reporting firm ID, form the identifiers we useto uniquely identify a transaction report. As a consequence, if an amendment toa 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 willtherefore reject the amendment transaction report.


7.3.3. Amending a previously submitted transaction report

Where there is a requirement to amend a previously submitted transactionreport, you may need to contact your ARM to understand what action totake. Some ARMs may allow you to send a transaction report marked as anamendment to a previously submitted transaction report. Other ARMs mayrequire you to cancel the originally submitted transaction report and submitthe new amended version.

• If your ARM has already sent the transaction report to us then you mayneed to send us a ‘cancellation’ transaction report (in line with theguidelines 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 ofOTC derivative events such as partial terminations of swap transactions. Oncethis 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 anotherfirm, Firm B, to offer Firm A’s CFD trading services (e.g. trading platform etc)to their clients. There are various ways that a white label solution can bestructured. With respect to transaction reporting, where a client of Firm Bexecutes a transaction using the CFD white labelling solution and Firm Areports the transaction and identifies the client of Firm B, Firm B would notneed 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.


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 theorder by undertaking multiple transactions. Transaction reports submitted byFirm A will need to reflect the time at which Firm A became the beneficialowner. Firm A may therefore need to report each transaction individually, ifknown, 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 executethem in a single transaction. For example, where Firm X buys 100,000 sharesfrom Firm Y on behalf of three different clients in an aggregated order, FirmX should report a buy from Firm Y (identified in the counterparty field) onbehalf of an aggregated account (identified in the customer/clientidentification field using the code ‘INTERNAL’ only). Firm X should thenreport three agency buy transactions from the aggregated account (identifiedin 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 executingtwo or more transactions at different prices, but the client wants one or morecontract notes showing an average price. For example, Firm X gives an orderto Firm Y to buy 100,000 shares as agent and Firm Y completes the order intwo transactions, one of 20,000 shares and the other of 80,000 shares at unitprices of 100p and 102p respectively.

As there is only one client the firm can report the two agency buy transactionsfrom Firm Y (identified in the counterparty field) and include the identity ofthe client on each (in the customer/client identification field) (even if the firmhas issued a single contract note at the average price).

A more complex scenario would be where there is more than one client, forexample, 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 ascenario, the firm could report all the individual transactions separately. Tocut down on the number of transaction reports, but to maintain an audit trail,we would recommend that Firm X reports five agency ‘buy’ transactions fromthe market counterparty (identified in the counterparty field) in to adesignated average price account (identified in the customer/clientidentification field using the code ‘INTERNAL’ only) and ten agency/agencycrosses of that designated average price account (identified in the counterparty


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

7.4. Portfolio managers as counterparties

• To report a transaction where your counterparty is a firm providing theservice of portfolio management, the transaction report should identify thefirm providing the service of portfolio management using their FSAReference Number or Swift Bank Identifier Code (BIC), or, if neither isavailable, an internal unique code.

• There is no requirement for the transaction report to identify the fundmanaged by the firm providing the service of portfolio management.

• There is no requirement to report separate transactions for the respectivefunds 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 ofportfolio management is exempt from transaction reporting. Where a firm in the course of providing a service of portfolio management undertakes atransaction in an agency or principal capacity on behalf of a client on adiscretionary basis, or does so having specifically recommended the transactionto the client, and the firm has reasonable grounds to be satisfied that anotherparty (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 portfoliomanagement undertakes a transaction in an agency or principal capacity onbehalf 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 berequired to report the transaction to us or another competent authority)and the financial instrument is admitted to trading on a regulated marketor prescribed market.

• When the firm providing a service of portfolio management undertakesan inter fund transaction without using a broker who is a MiFIDinvestment firm.

• Where the transaction is reportable under SUP 17 but is not a transactionin a financial instrument admitted to trading on a regulated market and thebroker is a non-UK MiFID investment firm. This covers areas where the UKis super-equivalent to the MiFID requirements. It includes transactions inOTC derivatives where the underlying instrument is traded on a regulated


market or prescribed market and transactions in financial instrumentsadmitted to trading on prescribed markets. In such circumstances, the non-UK broker is not expected to make a transaction report as the transaction islikely to be outside the reporting rules applicable in the broker’s home state.Consequently, the firm providing the service of portfolio manager cannotrely on the exemption under SUP 17.2.2 G.

• Where the counterparty is another firm providing a service of portfoliomanagement, in which case both firms will have to transaction report.

• When a firm providing a service of portfolio management undertakes atransaction in an agency or principal capacity on behalf of a client on anexecution-only basis.

• In the event that a firm providing a service of portfolio managementcontacts an EEA broker to conduct a transaction in a reportable instrumenton a non-EEA exchange, that broker may pass the order to a non-EEAbroker to execute the trade. If the EEA broker is not itself entering into thetransaction in an agency or principal capacity because the relationship withthe firm providing the service of portfolio management has been given upto the non-EEA broker, then the firm providing a service of portfoliomanagement, rather than the EEA broker, would have an obligation totransaction report.

However, it would be perfectly permissible for the EEA broker to reportthis transaction either in its own name or the name of the firm providing aservice of portfolio management so that the firm providing a service ofportfolio management need not report directly. This would form part ofan agreement that the firm providing a service of portfolio managementmay wish to undertake with the EEA broker.

• Where an EEA broker reports a transaction in its own name, as if it wereacting 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 firmproviding 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 thefirm providing a service of portfolio management, the transaction reportshould identify the firm providing a service of portfolio management inthe reporting firm field, the counterparty in the counterparty field(sometimes referred to as the counterparty one field) and the firmproviding 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 unableto 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 viaan ARM in accordance with the guidelines below:

• Where a firm providing a service of portfolio management undertakes atransaction in an agency capacity on behalf of a client on a discretionarybasis and SUP 17.2.2 G does not exempt the firm from reporting, thetransaction report should identify the firm providing a service of portfoliomanagement in the reporting firm field, the counterparty in thecounterparty field (sometimes referred to as the counterparty one field)and the firm providing a service of portfolio management in theclient/customer field (sometimes referred to as the counterparty two field).

• Where a firm providing a service of portfolio management undertakes atransaction in an agency capacity on behalf of a client on an executiononly basis, SUP 17.2.2 G does not exempt the firm from reporting. Thetransaction report should identify the firm providing a service of portfoliomanagement in the reporting firm field, the counterparty in thecounterparty field (sometimes referred to as the counterparty one field)and the client in the client/customer field (sometimes referred to as thecounterparty two field).

• Where a firm providing a service of portfolio management undertakes aninter fund transaction, where no broker who is a MiFID investment firm isinvolved, SUP 17.2.2 G does not exempt the firm from reporting. Thetransaction report should identify the firm providing a service of portfoliomanagement in the reporting firm field, the counterparty field (sometimesreferred 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 transactionreporting rules and the technical specifications of the respective ARM(s).

Data integrity 8


6 http://fsahandbook.info/FSA/html/handbook/SYSC

7 http://fsahandbook.info/FSA/html/handbook/PRIN/2/1

8 http://fsahandbook.info/FSA/html/handbook/SUP/17/3

Transaction reports are an important component of our toolkit forinvestigating instances of market abuse, including insider trading. Yourtransaction 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 reportingrequirements. 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 whenreporting transactions to us in terms of the submission of reports and theircontent. To ensure accuracy and completeness, firms, under SYSC in theHandbook (Senior Management Arrangements, Systems and Controls)6

and under Principle 3 (Management and Control)7, must have appropriatesystems and controls in place to enable them to comply with their regulatoryobligations.

The obligation of firms under SUP 17.3.6 (G) is to ensure they havesuccessfully provided their transaction reports to us.8 The successfulsubmission 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 successfullypassing these reports on to us. Firms can check the completeness of the reportsthey send us by requesting a sample from our website (details providedbelow). SUP 17.4 and SUP 17 Annex 1 Minimum content of a transactionalso detail the obligation firms have to ensure their transaction reportscontain the required information and are provided in the correct format.

http://fsahandbook.info/FSA/html/handbook/SUP/17/3

http://fsahandbook.info/FSA/html/handbook/PRIN/2/1

http://fsahandbook.info/FSA/html/handbook/SYSC


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

8.2. Transaction reporting arrangements within firms

We have not sought to be prescriptive in terms of what controls and reviewprocesses firms should follow. These should be tailored to the firm’s activities.However, we would expect them to embody Principle 3 and comply withSYSC. 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 properoversight of the transaction reporting process;

• testing wherever alternative reporting mechanisms are used;

• appropriate oversight of transaction reporting by compliance, includingreviews, as part of the compliance monitoring programme;

• the nature and scale of the reviews and testing is tailored to the activitiesof 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 beingcorrectly reported; and

• testing is comprehensive so that the full reporting process is tested not justpart of it. This means that testing should include ensuring that the reportsare properly submitted to us.

To help check reports have been successfully submitted to us, firms canrequest a sample of their transaction reports using an online form on ourwebsite.9 We encourage firms to periodically use this facility as part of theirreview process to compare the reports we receive with the reports they sendfrom their own systems. Such an exercise should also involve checking theaccuracy of the individual data elements and their compliance with theguidance we have issued. In particular, if you request a sample of your firm’stransaction 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 yourfirm executed the transaction (e.g. agent, principal, agency cross orprincipal 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 youwill 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 allinstrument types and platforms for that counterparty or client);

• an FRN or BIC has been correctly tagged as an FRN or BIC in thecounterparty code type fields;

• the unit price and, where applicable, strike price, contain values in themajor currency unit (e.g. in pounds as opposed to pence);

• where the transaction is in an OTC derivative, a complete description hasbeen 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 willtailor their checks and validation process for their own purposes. However,any checks carried out on the content of reports must be made with referenceto 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 tonotify 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 firm’s plan, including a timetable, to submit corrected transactionreports;

• details of your firm’s systems and controls around transaction reporting, including its processes for addressing response files from your chosen ARM(s);

• any weaknesses in your firm’s systems and controls and your plans toaddress these; and

• any planned audit or compliance monitoring reviews of transactionreporting and the scope of these.

Contact us by calling: 020 7066 6040 or by emailing: [email protected].

Where transaction reporting issues are identified, we will review thecircumstances of the issue and decide on an appropriate course of action. Ourpolicy 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 historictransaction reporting data for our surveillance activities.

In those cases which we consider to be particularly serious, we will considerusing our enforcement tools (e.g. a private warning, a public warning, a fineor a skilled person report, as defined under section 166 of the FinancialServices and Markets Act).

In such cases, we will consider the extent to which the firm’s systems andcontrols around transaction reporting were appropriate to the nature, scaleand complexity of the business. We will also review the extent to which theidentified failings are due to failings by individuals to exercise their oversightrole where they undertake a significant influence function in respect oftransaction 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 inMarketWatch as well as on our website at: www.fsa.gov.uk/transactionreporting.Should you have any queries after having reviewed our guidance, please contactour transaction reporting help desk on: 0207 066 6040 or email us at:[email protected].


http://www.fsa.gov.uk/transactionreporting

Frequently AskedQuestions (FAQs)9


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

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

We encourage firms to regularly review the integrity of their transaction reportsto ensure they are completing all the fields that are mandatory for the respectiveproduct types that are being transacted (in line with SUP 17 Annex 1) and werecommend they check that they are reporting all transactions reportable underSUP 17 to us.

To help you review the integrity of your data we are happy to supply copiesof transaction reports received so you can cross-check them against internalrecords. To request copies of transaction reports received please complete ouronline 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 ensureyour data is accurate and to make sure we receive transaction reports on atimely basis. If you believe your firm may have misreported some transactions,inform our Transaction Monitoring Unit and your supervisor in writing assoon as you can.




9.4. What about UK public holidays?

Under SUP 17.2.7, you must report the transaction by the close of theworking day following the day on which that transaction took place, e.g.transactions entered into on the Friday before a Bank Holiday Monday willneed 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 Rwhere that transaction report has been accepted by an approved reportingmechanism, or regulated market or MTF that reports to us by the end of thatreporting channel’s working day. For further clarification, you should contactyour respective ARM(s).

9.6. Are internal transactions reportable?

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

9.7. Are ‘grey market’ transactions reportable?

A transaction in a financial instrument admitted to trading on a regulatedmarket, or a prescribed market, or in any OTC derivative the value of whichis derived from or is otherwise dependent on an equity or debt-relatedfinancial 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 becostly. 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 aretail client in line with SUP 17 Annex 1R. However, in some instances theformat specified by SUP 17 is not relevant to the needs of the customer. Pleasesee 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 reportingrule should contact their supervisor and the Transaction Monitoring Unit assoon as possible.


9.11. Are results of option transactions reportable?

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

9.12. Are primary market transactions reportable?

The MiFID definition of a transaction excludes primary market transactionsin 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 atransaction on behalf of a client of a firm providing a service of portfoliomanagement, the report submitted by the broker should identify the firmproviding the service and not the underlying client. It is therefore onlynecessary to report the bulk trade; the allocations for each respective clientare not reportable.

9.14. Are ‘in specie’ transfers reportable?

In specie transfers involve the direct transfer of assets into or out of aportfolio or trust. Often in specie transfers are used as a means of reducingthe costs involved in the sale or purchase of assets. On this basis, we do notconsider that in specie transfers should be reported, as long as they do notinvolve a change in beneficial ownership. In addition, there may be caseswhere a technical change in beneficial ownership occurs but there is norequirement for transaction reporting. For example, in specie transfers in andout of unit-linked insurance funds of assets involve a change in beneficialownership since the assets are owned by the insurance company and thepolicyholder only has contractual rights valued on the assets. Nonetheless,we would not require reporting of such transfers. If you are in any doubt asto whether a particular transfer should be reported, please contact theTransaction Monitoring Unit.

9.15. What about when we outsource a portfolio?

If you have outsourced the management of a portfolio to another EEA MiFIDinvestment firm providing a service of portfolio management, then it has anobligation to report to its relevant competent authority in compliance with therules of that competent authority. If you have further queries related tooutsourcing a portfolio, please contact the Transaction Monitoring Unit byemail at: [email protected], or by calling the transaction reporting helpline on:02070666040.



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 allreasonable efforts to report correctly via an ARM, but the ARM fails totransmit the correct information to us. In these instances, we recognise thatthis 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-relatedderivatives, but that are not admitted to trading on a regulated market, areconsidered to be OTC derivatives for transaction reporting purposes.Transactions in these instruments are reportable and should be identified in atransaction report in accordance with the requirements of OTC derivatives setout 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 aprincipal or agency capacity, and passes a client order to another firm, whothen executes the transaction and has the relationship with the underlyingclient, the introducing broker does not have to report the transaction to us.

Glossary of terms10


Agency cross Where the reporting firm acted as agent for both the selling and buying counterparties and the singletransaction report represents both of these transactions.

ARM Approved Reporting Mechanism

BIC Swift Bank Identification Code

CFD Contract for difference

FRN FSA Reference Number

ISD The Investment Services Directive 93/22/EEC

ISIN ISO 6166 International Securities Identifying Number

ISO International Organization for Standardization

SUP 17 Chapter 17 (Transaction Reporting) of theFSA Handbook Supervision Manual

TMU The FSA’s Transaction Monitoring Unit

MiFID The Directive 2004/39/EC on Markets inFinancial Instruments

OTC derivative A derivative that is traded over-the-counter and is notadmitted to trading on any market.

Prescribed market A market that has been prescribed by Treasury as amarket that comes within the scope of the market abuseregime contained in Part VIII of FSMA.

Principal cross A principal cross is defined to be where the reportingfirm has acted simultaneously for two counterparties asprincipal in a single product, at the same price andquantity and the single transaction report represents bothof these transactions.

TRUP Transaction Reporting User Pack

Index11


accrued interest, 21

agency, 12, 17, 29, 30, 32, 40

agency cross, 18

aggregated account, 23, 29

allotment. See primary markettransactions

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. Seecustomer/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 markettransactions

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 competentauthority

MTF, 14

multi-lateral trading facility. SeeMTF

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 markettransactions

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

XOFF, 23

XXXX, 23

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

Documents

Transaction Reporting User Pack