We spend a lot of time talking about how new technology will transform surveillance, but unless surveillance processes capture all regulated activity, technology is not a whole lot of use. Obviously banks are always looking at coverage, in the sense of ‘the right people to include in surveillance programmes’, either with a view to increasing the number of people surveilled beyond regulatory minima to get a better handle on abuse, others taking the opposite approach to minimise costs.
But it’s becoming clear that banks may be missing more fundamental coverage problems. Regulators have previously noted issues with surveillance of the comms channels embedded in newer trading venues, but they have also now realised that the rapid evolution of those venues doesn’t just mean banks are not noticing new functionality within venues. It also means they – or at least their surveillance teams – may not be noticing they use some venues at all.
This can happen because the business does not tell surveillance about a new venue – which is an issue of venue onboarding; it may be that a venue creates a new comms channel that it does not tell the bank’s venue manager about – this is an issue for better two-way venue relationship management; it may be that a single entity, like a broker, is treated as a single venue when in fact it is multi-channel. And in general, it may be that the business does not understand the implications of a channel that it thinks of as a way just to agree a ticket or swap basic data, while in fact it can still be used to communicate other, potentially abusive, information.
What all of this reveals is a need to reassess the whole topic of venue assessment, onboarding and ongoing management. The start is to go back to the business with a revised definition of ‘venue’ from the surveillance perspective and to catalogue every single channel through which regulated information may flow. From there, surveillance needs to decide on the surveillance criteria for each channel as normal.
This is by no means all the banks’ fault. Venues and trading platforms are part of the problem. Far too often they introduce new comms functionality without informing their customers, or with an email that disappears into parts of banks unconnected to surveillance. They also routinely change the way their data feeds are configured, again without properly communicating the changes to the right parts of their bank users.
As one surveillance head complains, ”What you find is a venue just over a weekend changes the order of the fields in our data feed which then causes chaos in the surveillance data and related alerts. We then eventually contact them and they say, ‘Oh, sorry, we made a change to our data formatting.’”
So, as well as ensuring that venue usage is tracked and monitored, banks ideally need to build dashboards that cover those venues and ensure that what comes from each venue is what is expected. If a data feed changes or goes down, the dashboard flags it and automatically generates emails to the venue owner – the person in each business responsible for the relationship with that venue.
Incorporating dozens of unsurveilled venues (or channels, or risk types) into existing surveillance processes, and testing and documenting all exclusions, is the beginning. But it creates a new problem. Most surveillance teams are overstretched with their current workloads. Adding these previously unsurveilled datasets means adding resources or rethinking the process.
In some cases that may mean a redesign of surveillance processes to remove unnecessary checks, to de-duplicate surveillance checks if they are carried out in both 1st and 2nd lines (and to rethink that 1st /2nd line relationship), and to apply much more stringent materiality tests to particular pieces of surveillance.
In other words, regulatory attention on venues – as well as broader cost pressures – are forcing banks to take a truly risk-based approach to surveillance, which means, finally, starting to turn off surveillance processes that deliver too little material risk mitigation. It will be interesting to see how this collision of resourcing with ‘kitchen sink’ approaches based on fear of the regulators asking ‘why didn’t you do X’ will play out.
And there is a final twist to this reassessment of coverage in all its forms. Many surveillance processes incorporate exclusions to that process. For example, surveillance might have excluded a particular algo/venue combination from being surveilled because it is a hedging algorithm that has been through the algo committee and approved as not being designed to do anything except hedge.
The problem comes when these exclusions are not documented. At that point an exclusion becomes another coverage gap.
Since an exclusion creates an unsurveilled parameter or process, undocumented exclusions need to be reversed and then re-evaluated and documented if they are to be turned back on. Some may be simple, such as default settings in pieces of surveillance technology of a kind the regulators have been warning about for some time. But others can be much more complex and reflect years-old judgements from long-departed surveillance staff.
As banks wrestle with the economics of surveillance, and revisit the basic question of who they should bring into the scope of surveillance, venues and exclusions add to the complexity of the coverage question. Watch this space.