Every fact below comes from the public sources listed at the end. Numbers in brackets like [1, 4.60] are paragraph references in the FCA's final notice. ShipDataFast had no involvement in this case.

On 27 March 2019 the Financial Conduct Authority (FCA) fined Goldman Sachs International (GSI) £34,344,700 for transaction reporting failures [1, 1.1]. The penalty would have been £49,063,900 without the 30% discount the firm received for settling [2]. Between November 2007 and March 2017, 220.2 million of the transaction reports it sent the FCA were affected by errors [1, 2.3]. That was about 15% of the roughly 1.5 billion reports it submitted in the period [1, 2.5].

Transaction reports are a textbook case of a report built from a golden source. The front-office and booking systems hold the trades. The report is meant to be a faithful copy of the reportable ones, field by field. The FCA uses them to look for market abuse [1, 2.4]. This case is useful to anyone in investment, fund or finance operations because the failure was not one bad day. It was a reconciliation gap that lasted years.

What broke in the data

The final notice groups the errors into 11 main issues covering 212.7 million reports, plus 7.5 million lower-volume errors [1, 2.3]. Five of them show the main ways a report drifts from its source.

The wrong identifier for the counterparty. Between November 2007 and April 2011 the firm reported the identifier (BIC) of three central counterparties' beneficial owners instead of the central counterparties themselves. That affected about 72.7 million reports [1, 4.24 and 4.25]. Separately, between November 2007 and December 2014, it reported an internal code for some counterparties when an official BIC or FRN existed, affecting about 50.4 million reports [1, 4.30 and 4.31]. The notice links this to counterparty reference data: there was no fully automated process to check whether a BIC or FRN had become available for existing entities [1, 4.66].

Many executions squashed into one row. Between November 2007 and March 2017, where listed derivative executions had the same date, price and product and matched to the same second, they were aggregated and reported as one transaction. Some client-side reports were also "reshaped" rather than matching the individual executions. About 17.2 million reports were affected, and the issue was found in early 2016 after the firm enhanced its reconciliation controls [1, 4.32 and 4.33].

Trades that never made it into the report. An estimated 9.5 million transactions were not reported at all [1, 2.2]. In one example, transactions in equities traded on the BATS Chi-X exchange between June 2013 and July 2015 were missed because those instruments were not on the ESMA list the firm used as one of its sources for what was reportable, which led to about 8.8 million unreported transactions [1, 4.34 and 4.35].

Reports that should not have existed. About 6.6 million reports covered activity that either did not happen or was not reportable [1, 2.2], including clearing activity on listed derivative "give-in" trades (about 2.3 million) [1, 4.38 and 4.39].

A price that wasn't the price. Between November 2007 and March 2016 the reported price of certain cash equity products included commission, and sometimes other costs, affecting about 1 million reports [1, 4.45 and 4.46].

Why the checks didn't catch it sooner

The firm did have controls. From MiFID go-live it ran periodic reviews comparing a sample of transactions from front-office systems with the reports submitted and with the FCA's own records, and from early 2009 those reviews ran every quarter [1, 4.59].

In June 2009 an internal audit review made a "significant" finding that the controls focused on testing the accuracy of the reports rather than their completeness [1, 4.60]. The firm planned a redesigned quarterly programme that would reconcile the transactions in its reporting systems against front-office systems, books and records, and compare reported transactions to its trade booking system [1, 4.60].

Even so, the FCA found that until 31 March 2015 the controls were not robust enough to prevent or promptly detect some of the larger errors [1, 4.62]. By then the firm's enhanced controls worked "at a detailed level to test for specific transaction reporting errors", with limited thematic or macro-level controls [1, 4.63]. The firm then built an end-to-end reconciliation that independently re-created the population of transactions it had executed and reconciled it against the reports it had sent. That exercise found errors the detailed controls had not [1, 4.63].

Change was a factor too. Before April 2010, the team responsible for transaction reporting did not always know when front-office IT systems changed, so it could not always update the reporting systems to match [1, 4.55].

In fairness to the firm, the FCA notes it devoted significant resources to fixing the problems, co-operated fully, and self-identified the majority of the errors [1, 2.10].

The FCA's wider view has not changed since. In November 2024 it wrote that reconciliations must include front-office records, and that reconciling only specific fields, or only irregularly, may not be enough to find all errors and omissions [3].

What isn't public: the systems involved, how the end-to-end reconciliation was built, how long it took to run, and what the remediation cost beyond the fine. We won't guess at those.

5 reconciliation checks that catch this kind of drift

These apply to any report or extract built from a golden source: regulatory reports, fund accounting extracts, Finance spreadsheets, custodian files.

  1. Matching key at the lowest level. Agree the key that identifies one real-world record (for example one execution), and reconcile on it. If the report aggregates, the counts on each side will not match, and the key shows you where. That is the 17.2 million issue.
  2. Tolerances written down. For every compared field, agree the allowed difference before you run. For a price, that is usually zero. Commission in the price [1, 4.45] is a break, not rounding.
  3. Expected differences listed. Every row you deliberately drop (non-reportable activity, out-of-scope instruments) goes on a list with its rule and reason. Anything missing that is not on the list is a break. Check the list's sources too: an incomplete reportable-instrument list caused 8.8 million missed reports [1, 4.34].
  4. Named owners for mappings and change. Someone owns each reference-data rule (which code wins, BIC, FRN or internal ID), and someone tells the reconciliation owner when an upstream system changes [1, 4.55 and 4.66].
  5. Sign-off on the full population, both directions. In source but not in the report, in the report but not in the source, then field by field on the matched rows. A sample proves the rows you picked. It says nothing about the rows that never arrived.

Get the one-page version

We turned this case into a one-page PDF, How to avoid a report that doesn't match your golden source, with the 5 checks, the evidence to ask for and the red flags. For the full set of sign-off checks, get the free checklist at shipdatafast.com/checklist.

Sources

  1. Financial Conduct Authority, Final Notice: Goldman Sachs International, 27 March 2019. References are paragraph numbers. FCA final notice (PDF)
  2. Financial Conduct Authority, "FCA fines Goldman Sachs International £34.3 million for transaction reporting failures", 28 March 2019. FCA press release
  3. Financial Conduct Authority, Market Watch 81, 7 November 2024. FCA Market Watch 81