The Citi fat finger fines ... and UI design

The PRA's and FCA's Citi fines about algorithmic trading controls - provoked by a 2022 fat finger incident - tell a cautionary tale about gaps in trading controls.  If that was all, the fines would merely be headline-grabbing.

But there's more.  The final notices contain key new guidance and messaging. And suggest opportunities to apply inter-disciplinary learnings to your risk management.  So let's extract some key lessons learned.

Fat finger

The regulators' final notices paint a picture of protracted trading controls gaps, persisting despite remedial work and PRA engagement. (Insert here the usual advice about adequately resourcing remedial work and staying responsive to regulators.) 

And there were some trading mishaps, culminating on 2 May 2022 when a trader, attempting a routine hedge, mistakenly placed 7600x (USD444bn) their intended notional.  Automated systems blocked 95% of it; manual controls failed to catch the remaining 5%, of which USD1.4bn was executed causing European flash crashes before the trader noticed and cancelled the trades about 10 minutes later.

The final notices deal with shortcomings in three key controls categories.

(1) Trade order management systems: UI is for everyone

The 2 May 2022 incident had user interface (UI) design at its core.

The trader erroneously typed the desired notional into the unit quantity field.  This generated some hard blocks and hundreds of soft warnings, which the trader overrode without reviewing them.  The UI permitted this and indeed the UI may even have trained that behaviour over time: the warnings were presented in one window requiring lots of scrolling and capable of being dismissed with a single click.  (Just like the terms and conditions screens on online services?)

Then the trader checked the "Value at Benchmark" field but had no concerns.  Why? Because it simply displaying the negative of the notional value (presumably a minus sign is easy to overlook). It had defaulted to multiplying the unit quantity by -1 because an external benchmark price feed was unavailable.

The takeaway: you can materially mitigate regulatory risk here by focusing - very practically - on trading systems UI design and examining how traders interact with those systems. 

Here, an inter-disciplinary approach can bear fruit. Hear me out.  UI designers have developed relevant approaches over decades. UI design principles strive to present information in a way that supports usability.  (I'm even starting to see Consumer Duty parallels here …) 

And where this is a matter of life or death, as in aviation, great attention is given e.g. to cockpit design to enhance pilot decision-making and avoid exacerbating cognitive biases like inattentional blindness, cognitive overload and learned carelessness.  Plus there are well-developed protocols and programs to understand and mitigate risks arising from the interaction between pilots, aviation systems and other crew e.g. Line Operations Safety Audit (LOSA), Threat and Error Management (TEM) and Cockpit Task Management (CTM).

The secret sauce, though: lawyers and your risk advisors working hand in glove, applying inter-disciplinary insights.  (Guess what: at Linklaters, we have both!)

Next, a word on pre-trade blocks: the regulators are more prescriptive here than in their previous guidance.  Their expectations:

• A wave (basket-level) notional hard block.
• A stock-level notional hard block, appropriately calibrated.
• An Average Daily Volume (ADV) hard block.
• A price tolerance hard block.

Finally, the regulators expect firms to reduce reliance on manual processes and workarounds e.g. End-User Computing (EUC - mostly spreadsheets) for key processes like trade pricing, trade booking and rebalances.

(2) Algorithmic trading systems: rule recalibration

Here, the system had a "price move on arrival" control which had been set less sensitively during pandemic-related volatility and not recalibrated since.  A simple lesson learned, but remember all the key ingredients: (i) the control needs to be monitored; (ii) and recalibrated to current market conditions; and (iii) there needs to be assurance that (i) and (ii) are performed.

(By the way, in passing the PRA - addressing an unrelated trading incident - said that algorithmic trading systems should perform notional checks on prospective orders against the relevant exchanges' notional limits, so orders can be split accordingly.)

(3) Testing, and real-time monitoring

Don't over-filter alerts that your manual monitoring teams receive.  Ensure adequate monitoring cover during scheduled leave.  Monitoring teams should escalate urgent issues promptly and follow up rapidly and proactively.  Overarching this, you need governance structures to provide oversight and assurance. And an adequate testing programme.

Of course, much of this covers familiar ground if you've read existing rules and guidance e.g. the PRA's Algorithmic Trading Rules and Supervisory Statement 05/18, requirements in MiFID II and MAR, and the FCA's February 2018 paper.

But some of it is new or more elaborated - time to pay attention:

• When testing algorithms, don't just test at a system-by-system level.  Instead, test trading "flow" across multiple systems - from order capture through to booking.  This can expose issues in data flow across systems and identify gaps in the control environment.  During such testing it's possible e.g. to manually override a control so as to test the fault tolerance of the entire data flow.  (I'm getting aviation vibes again …)
• Ensure that the first line does not relax limits and blocks without second line authorisation.  Awareness-raising through training and testing is suggested.  (Ideally: permission your systems to eliminate the risk entirely.)
• Within systems used by monitoring teams, related orders should be linked, listed together or identified as related, to mitigate the risk of a team member releasing some orders but not others with consequential impact on execution and hedging.

PRA vs FCA: a final word

The PRA and FCA's final notices are strikingly different. The FCA focuses on the 2 May 2022 trading incident, with associated controls consequences, breaching Principles 2 and 3 and MAR.  The PRA focuses on controls issues, offering lessons learned and guidance illustrated by a series of trading incidents including on 2 May 2022, finding breaches of Fundamental Rules 2, 5 and 6 the PRA's Algorithmic Trading rules. 

It looks like the PRA had the lions' share of the pre-enforcement supervisory engagement with the firm.  It collected 54% of the total £61.6m fine.  Of course, its old penalty policy applied.  Could it have collected more if its new policy (i.e. its Step 2 Penalty Matrix) applied?  Perhaps. Under the Penalty Matrix, assuming Seriousness Level 2, Step 2 would have been £75-125m.  In this case the PRA's Step 2 was &60.5m.

Appropriately, each regulator gave a substantial (albeit different) mitigation adjustment for the fine issued by the other.