Final Notice
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”.