Final Notice

On , the Financial Conduct Authority issued a Final Notice to UBS AG

1

FINAL NOTICE

To:
UBS AG (“UBS”)

1.
ACTION

1.1.
For the reasons given in this Final Notice, the Authority hereby imposes on UBS a

financial penalty of £27,599,400 pursuant to section 206 of the Act.

1.2.
UBS agreed to resolve this matter and qualified for a 30% (stage 1) discount under

the Authority’s executive settlement procedures. Were it not for this discount, the

Authority would have imposed a financial penalty of £39,427,795.

2

2.
SUMMARY OF REASONS

2.1
Effective market oversight depends on complete, accurate and timely reporting of

transactions. A transaction report is data submitted to the Authority which contains

information relating to a transaction, such as information about the buyer and seller.

These transaction reports help the Authority to meet its objective of protecting and

enhancing the integrity of the UK’s financial system by providing information which

might identify situations of potential market abuse, insider dealing, market

manipulation and related financial crime.

2.2
UBS1 breached the Authority’s rules, as found within its Supervision manual (“SUP”),

requiring firms to submit complete and accurate transaction reports. SUP 17 requires

firms entering into reportable transactions to send complete and accurate transaction

reports to the Authority on a timely basis, and sets out the mandatory details required

to be included in those transaction reports. The following SUP 17 breaches occurred

between 5 November 2007 and 24 May 2017 (the “SUP 17 Relevant Period”):

(1)
A failure to report approximately 3.65 million transaction reports (SUP

17.1.4R); and

(2)
A failure to accurately report approximately 83 million executed transactions

(SUP 17.4.1EU and SUP 17.4.2R), e.g. by using an incorrect identifier code for

the counterparty to a transaction.

2.3
Between 5 November 2007 and 31 July 2014 (the “P3 and SUP 15 Relevant Period”),

UBS also:

(1)
breached Principle 3 of the Authority’s Principles for Businesses, which

requires firms to take reasonable care to organise and control their affairs

responsibly and effectively, with adequate risk management systems; and

(2)
failed to take reasonable steps to prevent the erroneous reporting of

transactions when those transactions either did not occur or occurred but

were not reportable (in breach of SUP 15.6.1R). This affected approximately

49.1 million transactions.

1 The enforcement investigation conducted by the Authority was in relation to compliance with the Authority’s
transaction reporting requirements by UBS Limited and UBS AG (London Branch). With effect from 1 March 2019,
pursuant to a combined Part VII business transfer and cross-border merger, the assets and liabilities of UBS
Limited were transferred to UBS Europe SE, a subsidiary of UBS AG established in Germany. However, all rights,
obligations and liabilities of UBS Limited in respect of the FCA’s investigation have been transferred to and
assumed by UBS AG, and this notice is therefore addressed solely to UBS AG.

3

2.4
Over the course of the P3 and SUP 15 Relevant Period, UBS traded a wide variety of

financial products and in increasing volumes. The Authority recognises that investment

banks operate in a complex and fast-moving global financial services environment. It

is therefore important that they take reasonable care to ensure that their systems and

controls in relation to transaction reporting are effective in the context of the nature

and scale of their businesses, activities and products offered and any changes made

to those businesses, activities and products. The complexity of the systems

architecture used by UBS to support both its trading activity and its transaction

reporting increased the risks UBS faced in effectively managing its transaction

reporting processes. In the context of the nature, scale and complexity of UBS’s

activities and transaction reporting arrangements, UBS breached Principle 3 by:

(1)
failing to have adequate systems and controls to ensure that reference or

‘static’ data used for various mandatory fields in the transaction reports

submitted to the Authority were complete and accurate;

(2)
failing to have in place adequate change management controls to manage

changes affecting transaction reporting processes and systems; and

(3)
failing to undertake appropriate testing to ensure the completeness and

accuracy of transaction reports.

2.5
As explained above, the breaches of SUP 17 continued until 24 May 2017. Nonetheless,

the Authority considers that UBS had recognised the failures within its control

framework and either remediated, or had substantially commenced the process of

doing so, following 31 July 2014.

2.6
The total number of transaction reports impacted by the errors set out above was

approximately 135.8 million. The Authority acknowledges that UBS self-identified and

notified the Authority of over 85% of the reporting errors described in this Notice, and

has committed significant resources to improving its transaction reporting controls

throughout the Relevant Periods. The Authority had previously issued a Final Notice

and £100,000 financial penalty against UBS on 17 November 2005 for transaction

reporting failings.

2.7
Prior to or during the Relevant Periods, the Authority has issued Final Notices and

financial penalties against a number of other firms for transaction reporting failings,

and has issued numerous communications highlighting the importance of complete

and accurate transaction reporting (see Annex D).

2.8
The Authority hereby imposes a financial penalty on UBS for these failings in the

amount of £27,599,400 pursuant to section 206 of the Act.

3.
DEFINITIONS

3.1.
The definitions below are used in this Final Notice:

“ARM” means an Approved Reporting Mechanism. Under Article 25(5) of MiFID, all

reportable transactions were to be reported through systems which complied with

specific requirements detailed in Article 12 of Commission Regulation (EC) No

1287/2006;

“the Act” means the Financial Services and Markets Act 2000;

“the Authority” means the body corporate previously known as the Financial Services

Authority and renamed on 1 April 2013 as the Financial Conduct Authority;

“DEPP” means the part of the Authority’s handbook entitled “The Decision Procedure

and Penalties Manual”;

“Market Watch” means a newsletter published by the Authority on market conduct and

transaction reporting issues;

“MiFID” means the Markets in Financial Instruments Directive (2004/39/EC);

“P3 and SUP 15 Relevant Period” means the period from 5 November 2007 to 31 July

2014;

“R3 Programme” means the ‘Regulatory Reporting Review’ transaction reporting

remediation programme initiated by UBS in September 2013;

“the Relevant Periods” means, collectively, the SUP 17 Relevant Period, and the P3

and SUP 15 Relevant Period.

“SUP 17 Relevant Period” means the period from 5 November 2007 to 24 May 2017;

“SUP” means the part of the Authority’s handbook entitled “Supervision”;

“the Tribunal” means the Upper Tribunal (Tax and Chancery Chamber);

“TRUP” means the Authority’s Transaction Reporting User Pack;

5

“UBS” means UBS AG (London Branch), a third country investment firm which is

required to comply with the Authority’s reporting requirements;

“2007 TOM” means the target operating model established by UBS and which

implemented a new framework of principles and processes for transaction reporting

from the date of MiFID coming into force on 5 November 2007 covering, amongst other

things, change management, IT architecture, monitoring and quality assurance, and

governance;

the “2006 Programme” means a programme initiated by UBS to remediate identified

transaction reporting issues and to identify shortcomings in UBS’s existing transaction

reporting procedures following the 2005 Final Notice, the findings of which were

reflected in the 2007 TOM; and

the “2012/13 Review” means the review undertaken from July 2012 to May 2013 by a

dedicated team at UBS with the support of an external professional services firm.

4. FACTS AND MATTERS

4.1.
The implementation of MiFID across all EEA (“European Economic Area”) member

states on 1 November 2007 (effective from 5 November 2007 for transaction

reporting) introduced changes to the list of products in which transactions had to be

reported to the Authority and standardised the list of information which had to be

included in the reports.

4.2.
SUP 17.1.4R required such firms which execute transactions to report the details of

their transactions to the Authority. Under SUP 17.4.1 EU reports of such transactions

had to contain the information specified in SUP 17 Annex 1 EU. SUP 17 Annex 1 EU

set out the minimum information required for a transaction report in a table, including

buy/sell indicator, trading capacity, price, date, time and quantity traded. MiFID

applied to UBS and therefore it was required to comply with SUP 17 when entering

into reportable transactions.

4.3.
Furthermore, SUP 15.6.1R required firms to take reasonable steps to ensure that all

the information they gave to the Authority in accordance with a rule in any part of the

Handbook was factually complete and accurate.

4.4.
The transaction reporting arrangements within firms are not prescribed by the

Authority and should be tailored to the firm’s activities. Nonetheless, a firm must take

reasonable care to establish systems and processes which are able to ensure that a

transaction is booked in a firm’s records in a way in which it can then be accurately

6

reported in accordance with the Authority’s requirements. When a firm reports its

transactions, it may do so through an Approved Reporting Mechanism (ARM), a

system which complies with specific requirements detailed in MiFID. In addition,

transaction reports can be sent through the regulated market or multilateral trading

facilities on which the transaction was completed.

Evolution of UBS’s transaction reporting arrangements

4.5.
A Final Notice was previously issued to UBS in respect of transaction reporting failings

on 17 November 2005. These failings occurred when UBS AG’s Wealth Management

division submitted reports directly, and where they relied on its Investment Banking

division to submit certain reports on its behalf. Following the issuance of that notice,

UBS undertook a detailed review and remediation of its regulatory reporting processes

throughout 2006 (the “2006 Programme”) and conducted an internal audit of its

transaction reporting procedures. The internal audit was issued in August 2006 with

a “qualified” rating and found significant transaction reporting deficiencies with its

Investment Bank.

4.6.
In response to these findings and leading up to the implementation of MiFID in

November 2007, UBS designed and implemented updated processes for transaction

reporting, known as the 2007 Target Operating Model (the “2007 TOM”). The design

and implementation of the 2007 TOM was based on the findings of the 2006

Programme. The 2007 TOM included, amongst other things, procedures for

monitoring and quality assurance, training, documentation and processes to govern

change management.

4.7.
UBS initiated an internal audit in 2008 to obtain assurance that all necessary changes

as a result of MiFID had been made to transaction reporting. The review also assessed

the steps taken to remediate the gaps in governance and oversight of transaction

reporting that were identified during the internal audit in 2006. In September 2008,

UBS’s internal audit function issued a report with a “satisfactory” rating and found

that the 2007 TOM provided a comprehensive and effective transaction reporting

control framework.

4.8.
In November 2008, approximately one year after the implementation of the 2007

TOM, UBS’s Operations function conducted a review of the firm’s transaction reporting

arrangements. The review identified some weaknesses in and ways to strengthen

UBS’s transaction reporting processes. Some of the issues that UBS identified had

arisen due to weaknesses in understanding in certain instances between business

areas and IT teams. In response to the findings of this review, in March 2009, UBS

7

established a dedicated cross-product team to coordinate improvements to its

transaction reporting process.

4.9.
Known as the Transaction Reporting Utility, this team’s responsibilities included,

amongst other things, advising on transaction reporting best practice, identifying and

resolving identified reporting issues, testing and change management. This team was

responsible for implementing what UBS called the Enhanced Control Framework for

transaction reporting throughout 2009 and 2010. The Enhanced Control Framework

included the development of more detailed documentation to support reporting logic

and testing; additional testing and assurance arrangements; and improved

management information. UBS continued to monitor and update its Enhanced Control

Framework throughout 2011.

4.10.
Following the detection of some additional transaction reporting errors, a further

review was undertaken from July 2012 to May 2013 by a dedicated team at UBS with

the support of an external professional services firm (the “2012/13 Review”). This

review was established to evaluate the effectiveness of the transaction reporting

process. The 2012/13 Review identified certain improvements to be made to UBS’s

transaction reporting processes, including, amongst other things, additional controls

to test the accuracy and completeness of reports.

4.11.
Towards the conclusion of the 2012/13 Review, there was an increased awareness

that the complex nature of UBS’s underlying trading systems contributed to

complexity in UBS’s transaction reporting IT architecture, and that whilst a range of

preventative and detective controls had been implemented to mitigate this risk, there

was scope to undertake a more comprehensive and strategic review of its reporting

architecture to address this underlying complexity.

4.12.
This issue was formally recognised in UBS’s operational risk reporting framework in

August 2013, and the following month UBS initiated a comprehensive programme of

review and remediation work in relation to its transaction reporting arrangements,

which later became known as the R3 Programme. The R3 Programme involved a

detailed re-examination of all of the firm’s booking models and transaction reporting

flows to validate them for completeness and accuracy, as well as the development of

a new transaction reporting infrastructure and control framework with significant

simplifications to the underlying IT architecture required to support UBS’s transaction

reporting. The approach taken by the R3 Programme was informed by a separate

project, conducted with the assistance of external legal counsel, to review the causes

of historic reporting errors and identify lessons learned.

4.13.
In November 2013, UBS internal audit issued a report on the outcome of a further

internal audit of its transaction reporting arrangements. The audit had been initiated

prior to the commencement of the R3 Programme and the report had a “not effective”

rating. The report found that whilst UBS had detected significant issues related to

transaction reporting it had failed to take sufficient action to remediate these while a

strategic solution was being investigated. In particular, it found that while

reconciliations and sample testing for completeness and accuracy of trades was

occurring, its Investment Banking Division had not reconciled the completeness and

accuracy of all transaction reporting fields from the front office systems to the reports

sent by the ARM to the Authority. In response to the audit report, UBS Operations

management confirmed that the R3 Programme would address both the immediate

actions arising from the audit findings and deliver a new transaction reporting systems

and controls framework for the future.

4.14.
Through the work of the R3 Programme, UBS self-identified most of the reporting

errors which are described in this Notice. By 31 July 2014, UBS had either remediated

or initiated key reforms to its transaction reporting arrangements. In October 2016,

a further audit of UBS’s transaction reporting processes determined that these were

“effective”. This was attributed to the improvements made by UBS as part of the R3

Overview of transaction reporting errors

(1) failed to report 3,658,423 transactions;

(2) inaccurately reported 83,074,015 transactions; and

(3) erroneously reported 49,152,274 transactions.

4.16.
UBS submitted approximately 1.8 billion transaction reports during the Relevant

Periods. These issues were therefore equivalent to approximately 7.5% of all

transaction reports submitted by UBS during this time. The transactions that UBS

failed to report were reportable under MiFID. The inaccurate reports provided details

of reportable transactions with various errors, such as using an incorrect identifier for

the counterparty or reporting an inaccurate execution time for a transaction. The

erroneous reports provided details of transactions that were not reportable. This

included: internal transactions that did not need to be reported; transactions that had

previously been reported to the Authority and so did not need to be reported again,

but when reported for a second time contained errors in certain of the reporting fields;

and intra-group transactions which had in fact not occurred but which were reported

due to errors in UBS’s IT reporting logic arising out of an incorrect assumption

regarding the contractual arrangements between certain UBS entities and clients for

certain transaction types.

4.17.
The approximately 135.8 million absent, inaccurate or erroneous transaction reports

were the result of 42 errors. There were 3 main root causes for the 42 errors, with

some errors arising due to a combination of these causes:

(1) errors in UBS’s systems, IT logic and/or reporting processes;

(2) weaknesses in change management controls; and

(3) weaknesses in controls around the maintenance of static data.

4.18.
The table at Annex A to this Notice summarises each transaction reporting error and

applicable root causes. It also specifies the length of time that each error persisted.

The duration of errors ranged from 1 month (Annex A, item 33) through to 8 years

(Annex A, items 29 and 32). On average, the errors lasted 61 months.

Transaction reporting systems

4.19.
Over the course of the Relevant Periods, UBS traded a wide variety of financial

products and in increasing volumes. The transaction reporting processes which UBS

had in relation to these different products were complex, with each product aligned

team at UBS having some responsibilities in relation to transaction reporting for their

product(s), and relying on different systems for the purposes of making transaction

reports to the Authority. Further, multiple trading systems were used by UBS to book

and settle transactions, which also increased the risks UBS faced in its transaction

reporting processes.

4.20.
UBS relied on automation for certain aspects of its transaction reporting process. This

process relied on IT logic, computer code that determined how information would be

sourced and incorporated into UBS’s transaction reports. However, a number of errors

arose with certain aspects of its IT reporting logic and this led to transaction reporting

errors (see Annex A). These include erroneously reporting to the Authority 58,754,060

intercompany transactions (44,510,652 of which fall within the P3 and SUP 15

Relevant Period) between May 2010 and November 2015 that had been reported due

to UBS’s IT reporting logic based on its expected booking model but which had not in

fact taken place (item 35).

4.21.
By 31 July 2014, UBS had either remediated or initiated key reforms which aimed to

identify and resolve these issues as part of the R3 Programme. Amongst other things,

UBS simplified its systems by consolidating all of its trade and transaction data within

a single transaction reporting hub. IT reporting logic and filters (including filters

reflecting if a transaction should be reported) were applied at the hub level, rather

than being applied across multiple IT systems. UBS also created a common platform

for implementing changes, testing, and quality assurance.

4.22.
The Authority recognises that transaction reporting arrangements should be tailored

to a firm’s activities and is not prescriptive about the approach taken. However,

irrespective of what process a firm follows, they must take reasonable care to ensure

that their systems, controls and reporting arrangements are appropriate to deliver

compliance with the Authority’s rules, including SUP 15 and 17.

Static data

4.23.
The Authority encourages firms to regularly validate static data to ensure its integrity.

This data is information used to populate certain mandatory fields on transaction

reports.

4.24.
UBS utilised reference or ‘static’ data as part of its transaction reporting

arrangements. For example, the client identification field of a transaction report is

sourced from fields within separate systems which were used to store client / account

information and which were used for a range of purposes within UBS.

4.25.
UBS developed its controls in relation to static data over the course of the P3 and SUP

15 Relevant Period. Weaknesses in those controls, however, led to a number of static-

data related transaction reporting failings (summarised at Annex A). For example,

weaknesses in the controls in place to ensure that accounts were linked to the correct

legal entity within a client group; that up to date and accurate BIC / FRN information

had been stored in the relevant client data systems; and that this data was fed

accurately to the firm’s transaction reporting systems led to UBS inaccurately

reporting transactions with the wrong BIC, FRN or internal identifier code, or with an

internal identifier code when a BIC or FRN was available (see items 22 to 26, 28, 29,

30 and 42).

4.26.
A series of UBS initiatives, including those looking at the reasons for transaction

reporting issues, recognised the importance of proper controls over static data. In

December 2007, UBS commenced a project designed to ensure the accuracy of its

static data related to client identification. This also established and documented

processes regarding the maintenance of static data. UBS continued to enhance its

static data controls throughout the P3 and SUP 15 Relevant Period including a project

in 2008 which implemented consistent client identifiers, and in 2011 through an

automated data cleansing process with the assistance of a third-party vendor. In

2012, UBS recognised that additional controls were required to support the regular

maintenance of accurate static data in order to provide complete and accurate

submissions to the Authority and recommended the introduction of monthly

reconciliations of reference data. This recommendation was implemented as part of

the R3 Programme between January and April 2014.

4.27.
UBS’s transaction reporting systems and processes relied upon the timely and

accurate flow of data from front and middle office systems to its transaction reporting

systems, and the application of accurate IT logic and filtering to determine how such

data should be reflected in the firm’s transaction reports. Any changes to front and

middle office systems or to IT logic therefore had the potential to have a knock-on

impact on the overall completeness and accuracy of the firm’s transaction reporting

process.

4.28.
UBS recognised the risk that system changes had the potential to interfere with the

completeness and accuracy of its transaction reports. UBS developed a range of

systems and controls intended to mitigate this risk, and revised these over the course

of the P3 and SUP 15 Relevant Period. For example, the impact of new business

initiatives on transaction reporting was required to be considered as part of the

business approval process, and steps were taken also to progressively document and

map reporting logic and business flows, including as part of the Enhanced Control

Framework introduced in 2009-2010, described at 4.9 above.

4.29.
However, during the course of the P3 and SUP 15 Relevant Period UBS identified that,

despite the various improvements to its change management processes and

procedures, transaction reporting errors had still arisen following the introduction of

new front or middle office systems. The 2012/13 Review undertaken by UBS found

that a number of weaknesses persisted in UBS’s change management controls and

the documentation of its change management processes as they related to transaction

reporting. This review highlighted that further improvements could be made to UBS’s

change management framework to improve the identification of change management

issues related to transaction reporting, including improving awareness as to what

system changes might have an impact on transaction reporting. Those improvements

included a recommendation to establish a dedicated cross-functional forum focused

on management of change from a transaction reporting perspective. This was to

ensure that all relevant changes were communicated to those involved in the

transaction reporting process. The November 2013 internal audit review made similar

findings to the 2012/13 Review, finding that some of the testing introduced in

November 2007 or subsequently to test and validate reporting logic and changes to

that logic had not been sustained.

4.30.
During the P3 and SUP 15 Relevant Period, change management weaknesses were a

root cause, at least in part, of some transaction reporting errors. These are

summarised at Annex A and include, for example, a failure to accurately report

10,061,907 transactions between May 2010 and February 2015 (item 36). UBS

incorrectly reported that it had transacted in an agency capacity when it had in fact

dealt in a principal capacity. This arose when a new system was implemented at UBS.

4.31.
By 31 July 2014, UBS had either remediated or initiated key reforms which would

resolve these issues. This included the establishment of the change management

forum recommended in the 2012/13 Review, remediation of specific errors caused by

this issue, and the introduction of enhanced user acceptance and regression testing.

Reconciliations and testing

4.32.
Firms must take reasonable steps to ensure the accuracy and completeness of the

transaction reports that they submit to the Authority. One way that firms can help to

achieve this is by having controls in place to reconcile the completeness and accuracy

of their transaction reporting process.

4.33.
UBS’s approach to reconciliations and testing evolved over the P3 and SUP 15

Relevant Period. From December 2007, UBS undertook periodic, sample-based testing

across the various product lines which would vary in frequency depending on the

results of the testing, and which from January 2008 included reconciliations against

the data received by the Authority, using a data extract provided by the Authority to

UBS at the firm’s request. Further iterative enhancements were made to the approach

to testing throughout 2008 and 2009, which included testing of reporting logic and

against live system data and reconciliations. In 2009, UBS introduced an automated

testing framework for Cash Equities intended to ensure that data included in

transaction reports met expected outcomes based on pre-defined characteristics and

attributes of the relevant reporting fields. Aspects of this automated framework were

subsequently applied to other product lines. From 2010, to check the accuracy and

completeness of the reports received by the Authority, UBS conducted additional

monthly reconciliations of its reporting data as submitted to its ARM(s) against the

data held by the Authority.

4.34.
However, as explained above at paragraph 4.13, the internal audit review in 2013

found that while UBS was conducting testing and reconciliations of data at various

stages of the reporting process, UBS’s framework did not adequately test and

reconcile the completeness and accuracy of all transaction reporting data from its

front office systems to the ARM reporting to the Authority.

4.35.
This weakness contributed to a number of transaction reporting errors not being

identified for significant periods of time. For example, UBS submitted 31,496,430

inaccurate transaction reports to the Authority, which incorrectly reported the time

the transaction was booked, rather than when it was executed, or reported the time

to the minute rather than to the second (see Annex A, item 32). This happened

because the relevant front office booking system was not designed to retain the

execution time for all of the relevant flows, an issue which originated in November

2007, on the implementation of MiFID, and persisted for 8 years until November 2015.

4.36.
By July 2014, UBS had either remediated or initiated key reforms which would result

in adequate controls being put in place to monitor the accuracy and completeness of

transaction reports. This included the establishment of a new quality assurance

process that periodically reviewed the completeness, accuracy and timeliness of

transaction reporting across all product lines.

5. FAILINGS

5.1.
The regulatory provisions relevant to this Notice are referred to in Annex B.

5.2.
Section 206 of the Act gives the Authority the power to impose a penalty on an

authorised firm if that firm has contravened a requirement imposed on it by or under

the Act or by any directly applicable European Community regulation or decision

made under MiFID.

5.3.
The Authority considers that UBS has breached SUP 17.1.4R, SUP 17.4.1EU, SUP

15.6.1R, and Principle 3 of the Authority’s Principles for Businesses.

5.4.
SUP 17.1.4R provides that a firm which executes a reportable transaction must report

details of the transaction to the Authority. The definition of what constitutes a

reportable transaction is set out at Annex B.

5.5.
UBS failed to report transactions that should have been reported to the Authority in

accordance with SUP 17.1.4R. Specifically, it failed to submit reports in relation to

3,658,423 transactions as described at Annex A.

5.6.
Furthermore, SUP 17.4.1EU provides that reportable transactions must contain

specified information. The information specified is described in SUP Annex 1 EU and

SUP 17.4.2R. These provisions are set out at Annex B and include firm identification

codes, transaction times, and trading capacity.

5.7.
UBS failed to accurately report certain transactions to the Authority in accordance

with SUP 17.4.1EU. There were 83,074,015 transactions that UBS inaccurately

reported as described at Annex A.

5.8.
The relevant period for these SUP 17 breaches covers the date on which the errors

arose to the date on which the incomplete or inaccurate reports ceased. The relevant

periods for each of these errors are specified at Annex A.

5.9.
SUP 15.6.1R requires a firm to take reasonable steps to ensure that all information

it provides to the Authority in accordance with a rule is complete and accurate.

5.10.
UBS breached SUP 15 between 5 November 2007 and 31 July 2014 by erroneously

reporting 49,152,274 transactions. In doing so, UBS failed to take reasonable steps

to ensure that it did not provide the Authority with erroneous information. These

errors arose due to one or a combination of the following issues:

(1)
erroneous IT logic used to generate intra-entity transaction reports for a

particular transaction flow;

(2)
weaknesses in change management controls, including inadequate testing of

the impact of an IT change on transaction reporting before the changes were

implemented; and

(3)
weaknesses in the controls used to maintain static data used in transaction

reports submitted to the Authority.

5.11.
UBS continued to submit erroneous reports after 31 July 2014. However, the

Authority considers that after that date the firm had recognised these failings and

taken reasonable steps to remediate the cause of the erroneous reports or

substantially commence the process for doing so.

5.12.
Principle 3 requires a firm to take reasonable care to organise and control its affairs

responsibly and effectively, with adequate risk management systems.

5.13.
During the P3 and SUP 15 Relevant Period, UBS failed to take reasonable care to put

in place effective controls to ensure that the transaction reports they submitted or

should have submitted to the Authority were complete and accurate.

5.14.
During the P3 and SUP 15 Relevant Period, UBS traded a wide variety of financial

products and in increasing volumes using complex IT systems. The complexity of the

systems architecture used by UBS to support both its trading activity and its

transaction reporting, and the division of responsibilities between those involved in

the transaction reporting process, increased the risks UBS faced in effectively

managing its transaction reporting processes.

5.15.
The Authority has not sought to be prescriptive in terms of what controls and reviews

firms should undertake. The Authority recognises that UBS improved its transaction

reporting processes in many respects over the course of the P3 and SUP 15 Relevant

Period. However, in the context of the nature, scale and complexity of UBS’s activities

and transaction reporting arrangements, UBS breached Principle 3 between 5

November 2007 and 31 July 2014 by:

(1)
failing to have adequate systems and controls to ensure that reference or

‘static’ data used for various mandatory fields in the transaction reports

submitted to the Authority were complete and accurate;

(2)
failing to have in place adequate change management controls to manage

changes affecting transaction reporting processes and systems; and

(3)
failing to undertake sufficiently robust reconciliations and testing to ensure

the completeness and accuracy of transaction reporting data from front office

systems through to the Authority.

5.16. These weaknesses contributed to a number of the transaction reporting errors arising

or going undetected for, in some cases, a significant period of time.

5.17. As explained above, the breaches of SUP 17 as specified in this Notice continued until

24 May 2017. Nonetheless, the Authority considers that UBS had recognised the

failures within its control framework and either remediated, or had substantially

commenced the process of doing so, by 31 July 2014.

6.
SANCTION

6.1
The Authority has given substantial and ongoing support to the industry regarding

transaction reporting requirements through the Transaction Reporting User Pack,

Transaction Reporting Forums and Market Watch, and various tools have been

provided to facilitate compliance. The Transaction Reporting User Pack (first published

in July 2007) made clear that reportable transaction data is used for the following

purposes: (1) monitoring for market abuse and market manipulation; (2) firm

supervision; (3) market supervision; and (4) used by certain external parties, such as

the Bank of England. Despite the imposition of other financial penalties against firms

during the Relevant Periods for transaction reporting failings, industry standards have

not improved to a sufficiently high standard. The Authority therefore considers that

there is a need to increase transaction reporting standards throughout the industry.

6.2
The conduct at issue occurred both before and after 6 March 2010, the date on which

the Authority’s new financial penalty regime came into force. The Authority must

therefore have regard to both the penalty regime which was effective before 6 March

2010 (“the Old Penalty Regime”) and the penalty regime that was effective on and

after 6 March 2010 (“the New Penalty Regime”).

6.3
The Authority has adopted the following approach in this case:

(1)
calculated the financial penalty in respect of UBS’s transaction reporting

breaches taking place from 5 November 2007 to 5 March 2010 (inclusive) by

applying the Old Penalty Regime;

(2)
calculated the financial penalty in respect of UBS’s transaction reporting

breaches taking place under SUP 17 from 6 March 2010 to 24 May 2017

(inclusive) and under SUP 15 from 6 March 2010 to 31 July 2014 (inclusive) by

applying the New Penalty Regime; and

(3)
added the penalties under (1) and (2) above to determine the total penalty to

be imposed.

6.4
For the purposes of establishing penalty figures applicable to the transaction reporting

breaches falling within the old and new regimes, the Authority has determined the

number of transactions that were not reported at all, inaccurately reported or

erroneously reported both before and after 6 March 2010. These figures are set out

in Annex C.

Financial Penalty under the Old Penalty Regime

6.5
The Authority’s policy on the imposition of financial penalties relevant to the

transaction reporting failures occurring prior to 6 March 2010 is set out in the version

of Chapter 6 of DEPP that was in force prior to 6 March 2010. For the purposes of

calculating the penalty under the Old Penalty Regime the Authority has considered the

factors set out below.

Deterrence (DEPP 6.5.2G(1))

6.6
The principal purpose of imposing a financial penalty is to promote high standards of

regulatory and market conduct. The Authority considers that a penalty of the amount

set out below will deter it and other firms from committing similar breaches.

6.7
The Authority considers that the penalty will reinforce generally to other firms the

importance of accurate transaction reporting to the orderly conduct of markets in the

UK.

Seriousness and Impact (DEPP 6.5.2G(2))

6.8
UBS’s transaction reporting failures continued over an extensive period of time and

affected a number of different areas.

6.9
The breaches indicate weaknesses in the handling of transaction reporting issues. In

some instances, they were not prevented or effectively remedied for a considerable

period of time, although it is recognised that UBS made significant efforts to

continuously to improve its transaction reporting compliance throughout the Relevant

Periods by initiating a range of remediation programmes.

6.10
UBS’s failure to submit transaction reports, errors in the transaction reports submitted

and the submission of erroneous reports had the potential to hinder the Authority’s

market surveillance and monitoring capabilities. This includes, in particular, its ability

to detect and investigate suspected incidences of market abuse, insider dealing and

market manipulation.

6.11
Given UBS’s size and the high volume of transaction reporting errors the potential

impact of the failings in this case was significant.

6.12
The breaches did not cause loss to consumers, investors or other market users.

Deliberate or Reckless (DEPP 6.5.2G(3))

6.13
The Authority does not consider that UBS’s conduct was deliberate or reckless.

Financial Resources (DEPP 6.5.2G(5))

6.14
Given UBS’s size, the Authority considers that it has sufficient financial resources to

pay a penalty of the level that the Authority has decided to impose. The fine is, in the

Authority’s view, sufficient to achieve credible deterrence and is consistent with the

Authority’s objective of protecting and enhancing the integrity of the UK financial

system.

Benefit Gained/Loss Avoided (DEPP 6.5.2G(6))

6.15
UBS did not profit from the inaccurate transaction reporting nor did it avoid a loss.

Conduct following the breaches (DEPP 6.5.2G(8))

6.16
UBS has committed significant resources throughout the Relevant Periods to

identifying and rectifying the breaches specified in this Notice and their underlying root

causes. This includes the R3 Programme, which resulted in UBS identifying and self-

reporting approximately 86% of these breaches (by number of errors within scope of

the investigation) to the Authority, and which delivered enhanced transaction reporting

control standards and a new transaction reporting infrastructure and control

framework.

6.17
UBS has co-operated with the Authority in relation to its investigation.

Disciplinary Record and Compliance History (DEPP 6.5.2G(9))

6.18
UBS AG was fined by the Authority in November 2005 in respect of transaction

reporting failings within its Wealth Management Division, some of which involved its

Investment Bank Division reporting on its behalf.

Authority guidance and other published materials (DEPP 6.5.2G(12))

6.19
As referred to at 6.1 above and Annex D, either prior to or during the period from 5

November 2007 to 5 March 2010, the Authority has given substantial and ongoing

support to the industry regarding transaction reporting requirements. The Authority

recognises that UBS did make use of the facility the Authority provided to review

transaction data submitted to it and also took many steps during the course of the

Relevant Periods (both proactively and in response to the Authority’s communications

referred to above) to review and enhance its transaction reporting arrangements.

However, for the reasons set out in this Notice, the Authority has also concluded that

in certain respects UBS failed to take reasonable care to put effective controls in place

to ensure that the transaction reports it submitted to the Authority were complete and

accurate.

6.20
The total number of absent, inaccurate or erroneous transaction reports falling within

the Old Penalty Regime is 20,127,460. Applying the above factors, in particular, the

number and breadth of breaches and the disciplinary history of UBS in relation to

transaction reporting breaches, and the breach of Principle 3, the Authority considers

the appropriate level of penalty to be imposed under the Old Penalty Regime to be

£3,650,000.

6.21
Following the application of the 30% discount for Stage 1 Settlement, the penalty to

be imposed under the old regime is £2,555,000.

Financial penalty under the New Penalty Regime

6.22
The Authority’s policy for imposing a financial penalty is set out in Chapter 6 of DEPP.

In respect of conduct occurring on or after 6 March 2010, the Authority applies a five-

step framework to determine the appropriate level of financial penalty. DEPP 6.5A

sets out the details of the five-step framework that applies in respect of financial

penalties imposed on firms. The total number of absent, inaccurate or erroneous

transaction reports falling within the New Penalty Regime is 115,757,252, of which

66,633,787 are breaches of SUP 17 and 49,123,464 are breaches of SUP 15.6.1R.

Step 1: Disgorgement (DEPP 6.5A.1G)

6.23
Pursuant to DEPP 6.5A.1G, at Step 1 the Authority seeks to deprive a firm of the

financial benefit derived directly from the breach where it is practicable to quantify

this.

6.24
The Authority has not identified any financial benefit that UBS derived directly from its

breach.

6.25
Step 1 is therefore £0.

Step 2: The seriousness of the breach (DEPP 6.5A.2G)

6.26
Pursuant to DEPP 6.5A.2G, at Step 2 the Authority determines a figure that reflects

the seriousness of the breach. Where the amount of revenue generated by a firm from

a particular product line or business area is indicative of the harm or potential harm

that its breach may cause, that figure will be based on a percentage of the firm’s

revenue from the relevant products or business area.

6.27
The Authority considers that the revenue generated by UBS is not an appropriate

indicator of the harm or potential harm caused by its breach. For cases where a firm

has failed to report transactions in accordance with SUP 17, such as when it should

have reported a transaction and failed to do so or reported the transaction(s)

inaccurately, depending on the facts of the case, the Authority will attribute a value of

£1.50 for each report under the Authority’s new penalty regime, which came into effect

from 6 March 2010. The Authority has determined that the application of £1.50 per

report reflects not only the serious nature of failing to report transactions in accordance

with SUP 17 but also the failure by firms to comply with their transaction reporting

obligations in light of previous publications and action taken against other firms.

6.28
The Authority has established that a value of £1.50 for each of UBS’s 66,633,787

failures to report in accordance with SUP 17 during the part of the SUP Relevant Period

covered by the New Penalty Regime (6 March 2010 to 24 May 2017) should be applied

in this case. This equates to £99,950,681.

6.29
UBS also erroneously reported 49,123,464 transactions that were not in fact

reportable. The Authority has determined that a value of £1 should be attributed to

each non-reportable erroneous report to reflect the failure by UBS to take reasonable

steps to ensure that it did not provide the Authority with this erroneous information in

6.30
The Authority has established that a value of £1 for each of UBS’s 49,123,464 breaches

of SUP 15 during the part of the SUP Relevant Period covered by the New Penalty

Regime (6 March 2010 to 24 May 2017) should be applied in this case. This equates

to £49,123,464. This means that the breaches of SUP 17 and SUP 15 in total equate

to £149,074,145.

6.31
Furthermore, the Authority has determined the seriousness of UBS’s breaches to be

Level 3 for the purposes of Step 2 having taken into account:

(1)
DEPP 6.5A.2G (6-9) which lists factors the Authority will generally take into

account in deciding which level of penalty best indicates the seriousness of the

breach;

(2)
DEPP 6.5A.2G (11) which lists factors likely to be considered ‘level 4 or 5

factors’; and

(3)
DEPP 6.5A.2G (12) which lists factors likely to be considered ‘level 1, 2 or 3

factors.’

6.32
Of these, the Authority considers the following factors to be relevant:

(1)
the Authority relies on firms to submit complete and accurate transaction

reports to enable it to carry out its market surveillance obligations and to detect

and investigate cases of market abuse and uphold proper conduct in the

financial system. The Authority relies on firm’s such as UBS taking reasonable

care to establish and maintain appropriate systems and controls in order to

ensure it submits complete and accurate transaction reports on a timely basis;

(2)
the breaches are considered to be serious because they revealed weaknesses

in certain aspects of UBS’s systems and controls relating to transaction

reporting, some of which persisted for a significant period of time;

(3)
the breaches are considered to be serious as they are wide ranging in nature

and affected the majority of the product lines in respect of which UBS submitted

transaction reports;

(4)
during the Relevant Periods, UBS has committed significant resources to

improving its transaction reporting arrangements, systems and controls, and

that the reviews it initiated led to the identification of over 85% of the errors

described in this Notice;

(5)
UBS did not make any profit or avoid any loss as a result of the breaches;

(6)
there was no loss to consumers, investors, or other market users;

(7)
there was no potential significant effect on market confidence; and

(8)
the breach was not committed deliberately or recklessly.

6.33
In accordance with DEPP 6.5A.2G(13), the Authority has applied the following

percentages to the seriousness factors considered above:

(1)
level 1- 0%

(2)
level 2- 10%

(3)
level 3- 20%

(4)
level 4- 30%

(5)
level 5- 40%

6.34
Having taken into account all the factors above, the Authority has determined that a

seriousness factor of level 3 is appropriate. The penalty calculation is therefore 20%

of £149,074,145. The penalty figure after Step 2 is therefore £29,814,829.

Step 3: Mitigating and aggravating factors (DEPP 6.5A.3G)

6.35
Pursuant to DEPP 6.5A.3G, at Step 3 the Authority may increase or decrease the

amount of financial penalty arrived at after Step 2, but not including any amount to be

disgorged as set out in Step 1, in order to take account of any mitigating or aggravating

factors.

6.36
The Authority considers that the following factors aggravate the breaches:

(1)
the Authority issued UBS AG with a Final Notice in 2005 imposing a financial

penalty of £100,000 in respect of transaction reporting failures in UBS AG’s

Wealth Management Division. Some of these reporting failures were as a result

of the Wealth Management Division relying on the Investment Banking Division

to carry out reporting on its behalf;

(2)
throughout the Relevant Periods, the Authority has provided a significant

amount of support to firms on how to report transactions and communicated

with UBS directly regarding its transaction reporting processes; and

(3)
the Authority published, both before and during the Relevant Periods, a number

of Final Notices in relation to transaction reporting.

6.37
The Authority considers that the following factors mitigate the breaches:

(1)
UBS and its senior management initiated numerous reviews and projects aimed

at identifying and remediating reporting errors and strengthening UBS’s

transaction reporting arrangements. In particular, UBS carried out the R3

Programme, an extensive transformation programme in response to errors and

risks which had been self-identified by UBS. This was before the

commencement of the investigation and had the aim of delivering a sustainable

transaction reporting infrastructure and control framework which would reduce

the risk of similar problems arising in the future. This programme, which has

cost UBS approximately £39m to implement, has led to the identification and

prompt reporting to the Authority of over 85% of the reporting errors which

are the subject of this Notice;

(2)
UBS identified and self-reported over 85% of the errors described in this Notice

to the Authority; and

(3)
UBS has co-operated with the Authority during the course of its investigation.

6.38
Having taken into account these aggravating and mitigating factors, the Authority

considers that the Step 2 figure should be increased by 20%.

6.39
Step 3 is therefore £35,777,794.

Step 4: Adjustment for Deterrence (DEPP 6.5A.4G)

6.40
Pursuant to DEPP 6.5A.4G, if the penalty figure arrived at after Step 3 is insufficient

to deter the firm which committed the breaches, or others, from committing further or

similar breaches, the Authority may increase that penalty.

6.41
The Authority considers that the Step 3 figure of £35,777,794 represents a sufficient

deterrent to UBS and others, and so has not increased the penalty at Step 4.

6.42
Step 4 is therefore £35,777,794.

Step 5: Settlement Discount (DEPP 6.5A.5G)

6.43
Pursuant to DEPP 6.5A.5G, if the Authority and the firm on whom a penalty is to be

imposed agree the amount of the financial penalty and other terms, DEPP 6.7 provides

that the amount of the financial penalty which might otherwise have been payable will

be reduced to reflect the stage at which the Authority and the firm reached agreement.

The settlement discount does not apply to the disgorgement of any benefit calculated

at Step 1.

6.44
The Authority and UBS reached agreement at Stage 1 and so a 30% discount applies

to the Step 4 figure.

6.45
Step 5 is therefore £25,044,400 (rounded down to the nearest £100).

6.46
The Authority considers that combining the two separate penalties calculated under

the old and new penalty regimes produces a figure which is proportionate and

consistent with the Authority’s statements that the New Penalty Regime may lead to

increased penalty levels.

The Authority therefore imposes a total financial penalty of £27,599,400 on UBS for

breaching SUP 17.1.4R, SUP 17.4.1EU, SUP 17.4.2R, SUP 15.6.1R and Principle 3.

7.
PROCEDURAL MATTERS

7.1
This Notice is given to UBS under and in accordance with section 390 of the Act.

7.2
The following statutory rights are important.

Decision maker

7.3
The decision which gave rise to the obligation to give this Notice was made by the

Settlement Decision Makers.

Manner and time for payment

7.4
The financial penalty must be paid in full by UBS to the Authority no later than 1 April

2019.

If the financial penalty is not paid

7.5
If all or any of the financial penalty is outstanding on or after 2 April 2019, the Authority

may recover the outstanding amount as a debt owed by UBS and due to the Authority.

7.6
Sections 391(4), 391(6) and 391(7) of the Act apply to the publication of information

about the matter to which this notice relates. Under those provisions, the Authority

must publish such information about the matter to which this notice relates as the

Authority considers appropriate. The information may be published in such manner as

the Authority considers appropriate. However, the Authority may not publish

information if such publication would, in the opinion of the Authority, be unfair to you

or prejudicial to the interests of consumers or detrimental to the stability of the UK

financial system.

7.7
The Authority intends to publish such information about the matter to which the Final

Notice relates as it considers appropriate.

Authority contacts

7.8
For more information concerning this matter generally, contact Stephen Robinson

(direct line: 020 7066 1338) or Ross Murdoch (direct line: 020 7066 5396) of the

Enforcement and Market Oversight Division of the Authority.

Financial Conduct Authority, Enforcement and Market Oversight Division

Annex A – transaction reporting errors

no.

DESCRIPTION
ROOT CAUSES

Absent reports

1
Between July 2008 and October 2013, UBS

failed to report 717,102 GSE Equities

Derivatives transactions with another UBS

entity. Identified in October 2013.


Static data error / human error

2
Between November 2008 and November

2013 UBS failed to report 1,602,004

execution only transaction flows for Affiliate

Entities. Identified in October 2013.


Error in systems/ IT logic and/or

reporting flow


Weaknesses in change

management controls

3
Between November 2011 and November

2013
UBS
failed
to
report
304,880

transactions not executed directly on the

Eurex graphical user interface. Identified in

October 2013.


Error in systems/ IT logic and/or

reporting flow


Weaknesses in change

management controls

4 Between November 2007 and December

2014
UBS
failed
to
report
866,580

transactions
executed
for
portfolio

managers. Identified in April 2014.


Error in systems/ IT logic and/or

reporting flow


Weaknesses in change

management controls

5
Between November 2013 and May 2014

UBS failed to report the execution of 92,711

transactions entered into to fill orders of

another UBS entity’s US-based clients.

Identified in March 2014.


Weaknesses in change

management controls

6
Intentionally left blank*


Intentionally left blank*

7
Between November 2008 and April 2014

UBS failed to report 53,037 proprietary

transactions given up to a third party

clearing broker. Identified in January 2014.


Error in systems/ IT logic and/or

reporting flow

8
Between November 2007 and September

2014 UBS failed to report 720 fixed income

transactions that were set up on a dummy

ISIN. Identified in July 2014.


Error in systems/ IT logic and/or

reporting flow

9
Between November 2007 and April 2014

UBS failed to report 6,807 transactions by

erroneously
suppressing
debt
warrant

transaction reports. Identified March 2014.


Error in systems/ IT logic and/or

reporting flow

10
Between November 2007 and December

2014 UBS failed to report 14,582 CDS

transactions
by
incorrectly
filtering-out

these transactions based on their ISIN.

Identified May 2014.


Error in systems/ IT logic and/or

reporting flow

Inaccurate reports

11
Between November 2007 and February

2012 UBS failed to accurately report

1,312,532
fixed
income
securities

transactions by using the reporting code for

the wrong UBS entity firm identification

code. Identified in January 2012.


Error in systems/ IT logic and/or

reporting flow

12
Between November 2010 and February

2012 UBS failed to accurately report

4,993,480 transactions by using the firm

identification code for the wrong UBS entity

for transactions conducted on Chi-X, BATS

and UBS MTF. Identified in January 2012.


Error in systems/ IT logic and/or

reporting flow


Weaknesses in change

management controls

13
Between June 2011 and April 2013 UBS

failed
to
accurately
report
22,082

transactions by using the firm identification

code
for
the
wrong
UBS
entity
for

transactions
conducted
on
ITG
Posit.

Identified in February 2013.


Error in systems/ IT logic and/or

reporting flow


Weaknesses in change

management controls

15
Between November 2007 and December

2014 UBS failed to accurately report

507,193
transactions
by
noting
an

incorrect trading time for OTC equities.

Identified in November 2013.


Error in systems/ IT logic and/or

reporting flow


Weaknesses in change

management controls

16
Between March 2012 and April 2014 UBS

failed
to
accurately
report
34,055

transactions by using the incorrect BIC for

an external entity. Identified in April 2014.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

17
Between November 2007 and January 2014

UBS failed to accurately report 271,189

transactions by noting an incorrect trading

capacity on seven give-up books. Identified

in November 2013.


Error in systems/IT logic and/or

reporting flow

18
Between November 2012 and April 2014

UBS failed to accurately report 3,615,336

transactions by using an incorrect dealing

capacity on reports for UBS MTF executions

in the UK Market. Identified in February

2014.


Error in systems/IT logic and/or

reporting flow


Weaknesses in change

management controls

19
Between November 2007 and September

2014 UBS failed to accurately report

2,592,885
transactions
by
using
the

incorrect
trading
capacity
on
reports

relating to cash equity portfolio hedges for

proprietary
OTC
equity
transactions.

Identified in June 2014.


Error in systems/IT logic and/or

reporting flow

21
Between November 2008 and November

2013 UBS failed to accurately report

4,577,523 exchange traded derivative

transactions
undertaken
as
executing

broker for certain UBS affiliates by using an

incorrect Counterparty 1 in Principal Cross

transaction reports. Identified in October

2013.


Error in systems/IT logic and/or

reporting flow


Weaknesses in change

management controls

22
Between November 2011 and September

2013 UBS failed to accurately report

133,763 transactions by reporting an

internal counterparty code instead of a BIC

for “full service” trades undertaken on a

particular exchange. Identified in Aug 2013.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

23
Between November 2007 and November

2013 UBS failed to accurately report

3,903,934 transactions by reporting the

incorrect counterparty identification code

for another UBS entity. Identified in October

2013.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

24
Between November 2007 and August 2012

UBS failed to accurately report 270,791

transactions
by
using
an
internal

counterparty identification code when there

were BICs or FRNs available. Identified in

March 2012.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

25
Between November 2007 and July 2013

UBS failed to accurately report 3,847,201

transactions
by
using
the
incorrect

counterparty identification code for a central

counterparty following a change in clearing

arrangements for the relevant exchange.

Identified in July 2013.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

30

26
Between June 2010 and April 2014 UBS

failed
to
accurately
report
166,506

transactions by using the counterparty

identification code for the wrong entity

within the external counterparty’s group in

transaction reports. Identified in April 2014.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

28
Between November 2007 and June 2014

UBS failed to accurately report 8,706

transactions by using the counterparty

identification code for the wrong entity

within the external counterparty’s group in

transaction reports. Identified in May 2014.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

29
Between November 2007 and November

2015 UBS failed to accurately report

473,532 transactions by using an internal

counterparty identification code when a BIC

or FRN was available. Identified in June

2014.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

30
Between November 2008 and July 2014

UBS failed to accurately report 3,653,575

transactions by using the counterparty

identification code for the wrong entity

within the external counterparty’s group in

transaction reports. Identified in July 2014.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

31
Between November 2007 and August 2011

UBS failed to accurately report 345,667

transactions by erroneously reporting with

time in CET rather than GMT. Identified in

March 2012.


Third party error


Weaknesses in monitoring and

assurance testing

32
Between November 2007 and November

2015 UBS failed to accurately report

31,496,430 transactions by erroneously

reporting consumption time rather than

actual execution time and/or defaulting

seconds to “00”. Identified in July 2014.


Error in systems/IT logic and/or

reporting flow

33
Between May 2012 and June 2012 UBS

failed to accurately report 1,553,532

transactions by using the incorrect buy/sell

indicator. Identified in May 2012.


Error in systems/IT logic and/or

reporting flow


Weaknesses in change

management controls

34
Between December 2008 and February

2014 UBS failed to accurately report

591,168
transactions
by
erroneously

reporting of “book” currency rather than

“dealt” currency. Identified in December

2013.


Error in systems/IT logic and/or

reporting flow

36
Between May 2010 and February 2015 UBS

failed to accurately report 10,061,907

transactions by using an incorrect dealing

capacity of agency instead of principal.

Identified in September 2014.


Error in systems/IT logic and/or

reporting flow

37
Between November 2007 and June 2017

UBS failed to accurately report 331,229

transactions for certain exchange trades by

using the gross price inclusive of market

fees. Identified in January 2015.


Error in systems/IT logic and/or

reporting flow


Weaknesses in change

management controls

38
Between November 2007 and May 2017

UBS failed to accurately report 231,017

transactions by using the incorrect venue.

Identified in September 2015.


Error in systems/IT logic and/or

reporting flow

39
Between November 2007 and December

2016 UBS failed to accurately report

1,970,139 transactions by using incorrect

execution time and venue. Identified in

December 2016.


Error in systems/IT logic and/or

reporting flow

40
Between November 2007 and February

2015 UBS failed to accurately report

290,154 transactions by using an incorrect

dealing capacity of agency instead of

principal. Identified in July 2014.


Error in systems/IT logic and/or

reporting flow/ static data


Weaknesses in change

management controls

41
Between November 2007 and June 2016

UBS failed to accurately report 2,059,609

transactions by including the incorrect

venue of execution. Identified in March

2015.


Error in systems/IT logic and/or

reporting flow


Weaknesses in change

management controls

42
Between November 2007 and November

2015 UBS failed to accurately report

3,304,706
transactions
by
using
the

counterparty identification code for the

incorrect
entity
within
the
relevant

counterparties’ groups. Identified in April

2015.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

43
Between February 2012 and December

2015 UBS failed to accurately report

454,174 transactions by including the

incorrect execution time. Identified in

September 2014.


Error in systems/IT logic and/or

reporting flow

Erroneous reports

14
Between November 2008 and April 2014

UBS
submitted
117,040
reports

erroneously
by
reporting
internal

transaction allocations in exchange –traded

derivatives
between
UBS
AG
house


Error in systems/IT logic and/or

reporting flow

accounts as though these transactions took

place on an exchange. Identified in January

2014.

20
Between March 2014 and February 2015

UBS
erroneously
submitted
1,190,796

reports relating to UBS AG and UBS Limited

transactions
that
had
already
been

reported. These duplicate reports also

contained errors relating to dealing capacity

and execution venue. Identified in July

2014, by which time 433,017 reports had

been submitted.


Error in systems/IT logic and/or

reporting flow


Weaknesses in change

management controls

27
Between October 2013 and July 2014 UBS

submitted 4,091,566 reports erroneously

reporting
Cash
Equities
transactions

between different UBS AG businesses.

Identified in June 2014.


Error in, and weaknesses in

controls around

refreshing/maintaining,

client/counterparty static data

35
Between May 2010 and November 2015

UBS
submitted
58,754,060
reports

erroneously
by
reporting
intra-group

transactions in relation to certain swap

transactions undertaken for clients. The

intra-group transactions had been reported

due to reporting logic based on the expected

booking model but, due to the contracting

arrangements between the clients and the

relevant UBS entities, had not in fact

occurred. Identified in July 2014, by which

time
44,510,652
reports
had
been

submitted.


Error in systems/IT logic and/or

reporting flow


Change management

*Item number 6 is intentionally left blank. For the avoidance of doubt, the above table

specifies 42 transaction reporting errors.

ANNEX B - RELEVANT STATUTORY AND REGULATORY PROVISIONS

1.
RELEVANT STATUTORY PROVISIONS

1.1.
The Authority’s general duties established in section 1B of the Act include the strategic

objective of ensuring that the relevant markets function well and the operational

objectives of protecting and enhancing the integrity of the UK financial system and

securing an appropriate degree of protection for consumers.

1.2.
Section 206 of the Act gives the Authority the power to impose a penalty on an

authorised firm if that firm has contravened a requirement imposed on it by or under

the Act or by any directly applicable European Community regulation or decision made

under MiFID.

2.
RELEVANT REGULATORY PROVISIONS

2.1.
In exercising its powers to impose a financial penalty and to impose a restriction in

relation to the carrying on of a regulated activity, the Authority has had regard to the

relevant regulatory provisions published in the Authority’s Handbook. The main

provisions that the Authority considers relevant are set out below.

Principles for Businesses (PRIN)

2.2.
The Principles are general statement of the fundamental obligations of firms under the

regulatory system and are set out in the Authority’s Handbook. They derive their

authority from the Authority’s statutory objectives.

2.3.
Principle 3 provides that a firm must take reasonable care to organise and control its

affairs responsibly and effectively, with adequate risk management systems.

2.4.
The SUP 17 requirements set out below were in force throughout the SUP Relevant

Period and until 2 January 2018.

2.5.
SUP 17.1.4R states:

A firm which executes a transaction:

(1)
in any financial instrument admitted to trading on a regulated market

or a prescribed market (whether or not the transaction was carried out

on such a market); or

(2)
in any OTC derivative the value of which is derived from, or which is

otherwise dependent upon, an equity or debt-related financial

instrument which is admitted to trading on a regulated market or on a

prescribed market;

must report the details of the transaction to the Authority.

2.6.
SUP 17.4.1EU states:

Reports of transactions made in accordance with Articles 25(3) and (5) of MiFID

shall contain the information specified in SUP 17 Annex 1 EU which is relevant

to the type of financial instrument in question and which the FCA declares is

not already in its possession or is not available to it by other means.

2.7.
SUP 17 Annex 1 EU sets out the minimum information required for a transaction report

in a table including Field Identifiers and Descriptions. The fields in the transaction

report that need to be completed include, amongst other things: buy/sell indicator,

trading capacity and counterparty.

2.8.
SUP 17.4.2R required:

The reports referred to in SUP 17.4.1 EU shall, in particular include details of

the names and the numbers of the instruments bought or sold, the quantity,

the dates and times of execution and the transaction prices and means of

identifying the firms concerned.

2.9.
SUP 15.6.1R requires that:

A firm must take reasonable steps to ensure that all information it gives to the

appropriate regulator in accordance with a rule in any part of the Handbook (including

(1)
factually accurate or, in the case of estimates and judgments, fairly and

properly based after appropriate enquiries have been made by the firm; and

(2)
complete, in that it should include anything of which the appropriate regulator

would reasonably expect notice.

36

Decision Procedure and Penalties Manual

2.10. Chapter 6 of DEPP, which forms part of the Authority’s Handbook, sets out the

Authority’s statement of policy with respect to the imposition and amount of financial

penalties under the Act. In particular, DEPP 6.5A sets out the five steps for penalties

imposed on firms in respect of conduct taking place after 6 March 2010.

3.
RELEVANT REGULATORY GUIDANCE

The Enforcement Guide

3.1.
The Enforcement Guide sets out the Authority’s approach to exercising its main

enforcement powers under the Act.

3.2.
Chapter 7 of the Enforcement Guide sets out the Authority’s approach to exercising its

power to impose a financial penalty.

ANNEX C – BREAKDOWN OF BREACHES UNDER OLD AND NEW PENALTY REGIMES

No.

Old Regime
New Regime
Total breaches

489,451
717,102

3
N/A
304,880

304,880

581,118
866,580

5
N/A

6
Intentionally left
blank*

Intentionally left
blank*

Intentionally left
blank*


7
13,055


39,982


53,037

720

11
720,606

591,926

12
N/A

13
N/A

340,118
507,193

16
N/A

34,055

34,055

38

18
N/A

3,615,336

3,615,336

3,356,850

22
N/A

3,903,934

3,847,201

26
N/A

27
N/A

28
3,086

5,620

335,419

2,793,910
3,653,575

345,667

31,496,430

33
N/A

448,143
591,168

35
N/A
44,510,652


36
N/A

37
80,647
250,582
331,229

38
56,741
174,276
231,017

39
506,091

41
559,894

42
963,873
2,340,833
3,304,706

43
N/A

*Item number 6 is intentionally left blank. For the avoidance of doubt, the above table

specifies 42 transaction reporting errors.

ANNEX D – THE AUTHORITY’S TRANSACTION REPORTING PUBLICATIONS

1.1
Both prior to or during the Relevant Periods, the Authority issued numerous

communications on transaction reporting including TRUP (first published in July 2007)

and Market Watch articles. It also provided a transaction reporting library on the

Authority’s website. During the Relevant Periods, the Authority also published Final

Notices and imposed financial penalties in relation to a number of firms for transaction

reporting failures.

1.2
The Authority has regularly emphasised in publications that firms should have

adequate processes and controls to enable it to meet its reporting requirements,

including having systems and controls to ensure that data is correctly reported. Since

late 2007 the Authority has also made available copies of submitted transaction

reports to enable firms to perform a reconciliation of transaction reports received by

FCA versus the firm’s internal records.

Transaction Reporting User Pack (TRUP)

1.3
In relation to transaction reporting arrangements within firms, the Authority noted in

version 2 of TRUP (effective September 2009), and in subsequent versions, that a

firm’s controls and review processes should be tailored to the firm’s activities and

should embody Principle 3 and SYSC. Version 2 of TRUP provided a statement that

the Authority had not sought to be prescriptive in terms of what controls and reviews

firms should follow and Version 3 (effective March 2012) provides a similar statement.

Version 3.1 (effective February 2015) referred to the Authority not prescribing exactly

how transaction reporting reconciliations should be carried out.

1.4
Version 2 of TRUP gave the following examples of what this might, amongst other

things, require:

a.
a clear allocation of responsibility for transaction reporting within an organisation;

b.
appropriate training for staff in transaction reporting;

c.
appropriate information produced on a regular basis to enable proper oversight

of the transaction reporting process;

d.
testing wherever alternative reporting mechanisms are used;

e.
appropriate oversight of transaction reporting by compliance, including reviews,

as part of the compliance monitoring programme;

f.
the nature and scale of the reviews and testing should be tailored to the firm’s

activities and its transaction reporting arrangements;

g.
where reliance is placed on reporting by an ARM or another third party, periodic

checks are carried out to ensure that the transactions are being correctly

reported; and

h.
testing is comprehensive so that the full reporting process is tested not just part

of it and that testing should ensure that the reports are properly submitted to us.

1.5
This above was repeated in Version 3 of TRUP. Version 3.1 of TRUP provided additional

guidance in relation to how transaction report reconciliations could be carried out. It

stated that “Firms could perform front-to-back reconciliation or several point-to-point

reconciliations. However, the effect of such reconciliations should achieve the same

result as a straight-through end-to-end reconciliation.” Version 3.1 also referred to

“change management processes that are designed to ensure IT changes do not impact

the accuracy and completeness of reported transactions; including unit, functional

and regression testing and formal change sign-off as appropriate to the nature and

scales of the business.”

1.6
There were a number of Market Watch publications both prior to and during the

Relevant Periods, which referred to transaction reporting. These included covering

the importance of transaction reporting and highlighting transaction reporting issues.

The following are particularly relevant.

1.7
Market Watch Issue 19 was issued in March 2007 and included a reference to the fact

that TMU would supply sample data which firms can check against their internal

records. It also states, “We continue to encourage you to regularly review the

integrity of your transaction reporting data”.

1.8
Market Watch Issue 29 was issued in October 2008 and included details of controls

and reviews firms should follow, similar to the wording of the content of TRUP version

2 as set out above. It also referred “processes for ensuring continued transaction

reporting accuracy and completeness post any system or process changes” as

something that might be required. The issue referred to Principle 3 and that firms

must have appropriate systems and controls in place to enable them to comply with

their regulatory obligations.

1.9
Market Watch Issue 39 was issued in May 2011 and was focussed on transaction

reporting. It included a reminder about data integrity and the importance of

transaction reports in detecting and investigating potential market abuse. This

included a reference to seven firms where, between August 2009 to July 2011, fines

were issued for transaction reporting breaches. It again referenced systems and

controls and stated that in “In addition to complying with the transaction reporting

obligations in Chapter 17 of the Supervision Manual (SUP 17), firms must also have

appropriate systems and controls in place to ensure compliance with their obligations

under the regulatory system, including transaction reporting”.


© regulatorwarnings.com

Regulator Warnings Logo