By Chris DeBrusk, Managing Director and Specialist in Risk and Compliance, Rule Financial
In recent years many investment banks have suffered significant losses due to unauthorised and poorly monitored trader activity. High-profile instances such as the USD $6 Billion London ‘Whale’ loss at JP Morgan and the multi-billion dollar fallout from the Libor rigging scandal have highlighted the need for a much more sophisticated approach to risk and control within the front office. The implication is that the policies created by Compliance departments are not sufficient to either prevent a bank from incurring excessive losses, or protect the markets from manipulation by rogue traders.
Compliance departments have historically taken responsibility for defining, deploying and monitoring the surveillance processes that watch and then raise the alarm on transaction activity, and significant investment has been made in exception-based solutions to help manage the workload. There are now an emerging set of responsibilities owned by front office supervisors so that they may better understand what their traders are up to, and make sure each trader is following both external regulations and internal bank policies. However, the rudimentary and inconsistent level of automation across the industry means that supervisors must undertake a manually intensive process, and whilst it does meet the regulatory criteria, it remains highly inefficient.
In the current and problematic report-based approach, the sheer quantity of information which must be processed almost guarantees that mistakes will be made, regardless of how diligent the supervisor is. An alternative, exception-based model allows the bank to map the steps that a supervisor takes in manually evaluating transactions, holdings and risk data, to find issues in a ‘defined scenario’. A surveillance system can then extract exceptions that are out of the ordinary and worthy of further investigation, thus automating the manual process. There are numerous software vendors who claim that they can provide a set of scenarios ‘out-of-the-box’ (e.g. cancel correct monitoring) that will meet regulatory requirements. In reality though the only way to effectively construct a surveillance scenario that is appropriate for a bank’s unique business is to spend time detailing it on a whiteboard with a cross functional team of business and IT participants. The data and logic that defines the scenario is then captured as a requirements specification.
WANT TO BUILD A FINANCIAL EMPIRE?
Subscribe to the Global Banking & Finance Review Newsletter for FREE Get Access to Exclusive Reports to Save Time & Money
By using this form you agree with the storage and handling of your data by this website. We Will Not Spam, Rent, or Sell Your Information.
Another key challenge for banks is the need to integrate what are typically very disparate processes; certainly a centralised case management and workflow system could provide the answer. A sophisticated case management solution can support multiple roles within the end-to-end process, all of which are critical in being able to demonstrate to a regulator that a strong control environment exists within the bank. Best practice would see a central case manager unify all reports and then run a tightly defined workflow to triage, analyse and either close or escalate potentially material events. These could then become full-blown cases (with supporting information) that can be worked via a formal workflow that stretches across the front office, Compliance, operations, risk and audit (as appropriate). Moreover, integrating the case manager into the overall loss escalation process ensures that there is a full audit trail from alert to investigation, then through regulatory reporting, potential loss accrual, and in relevant scenarios to fines and payments.
It is one thing to build a functional monitoring system but significant effort must be made to design interfaces that are intuitive, minimise mistakes, support business goals and are easy to use, much like those enjoyed by heads of trading desks. Currently, supervisory solutions are patched together from multiple systems, lacking a cohesive user experience and frustrating those who try to navigate them. When building such tools for supervisors, focus should be on only giving them the information they need to perform their supervisory tasks and to deliver it via a user interface that minimises the time it takes to review the information, identify potential issues and action those issues. This all requires a focused effort by user experience specialists and business analysts to create a solution that meets the regulatory need, whilst putting a smile on a supervisor’s face (or at least avoiding a frown).
Technology should not take all of the blame for the current situation; a cultural shift from incident identification to incident avoidance is also required. Rather than highlighting and correcting issues and breaches after they have occurred, supervisors should be able to familiarise themselves with the normal metrics that the bank is producing so that irregularities can be spotted before they escalate into full-scale losses. When a trader makes an oversized bet that goes against them, a very small number of people will try to hide their losses until they can ‘make them back’, rather than being honest with their supervisor. However, if a trader hides an unrealised loss and does not get caught, they begin to think they can get away with it, and the sense that what they are doing is wrong becomes muted. If this goes undetected, it could signal the beginning of a downward spiral which has the potential for a multi-billion dollar loss as its conclusion.
For anyone working on an IT solution within a large investment bank, the difficulties of sourcing high quality transaction and reference data to supply surveillance or reporting systems soon becomes apparent. Of course the reality is that there will always be challenges in obtaining solid data, but in order to transition from report-based to exception-based supervision, either the data needs to be clean or the surveillance scenarios need to be designed to handle less than perfect data. The complex data situation in the majority of banks suggest that the only viable approach is to ensure that surveillance scenarios are able to deal with defects in the transaction or reference data while still producing high quality alerts or metrics. Such data integrity is also the Achilles heel of nearly all of the off-the-shelf surveillance systems, which often generate huge numbers of ‘false-positives’.
There is no easy answer to the mounting risk and control challenges faced by front office supervisors, however, a few simple steps as outlined above could make a considerable difference. Implementing a centralised case management system, enhancing user experience design, and moving from a report-based to an exception-based approach would not be a bad place to start.