Project Overview
Introduction
In Q2 of 2017, I began work on conceptual designs for a new Enigma solution - a platform for use by banks to intelligently identify suspicious employee trading patterns. As Enigma’s offerings evolved, a huge market for their data products was identified in the financial services sector, and these designs represent some of Enigma’s efforts in the space.
To comply with my non-disclosure agreement, I have omitted and changed confidential information in this project. The designs presented here may differ slightly from the original, and do not necessarily reflect the views of Enigma.
My Role
I was tasked with conceptualizing Enigma’s main capabilities in the financial services space. As these designs were only a concept, they haven’t yet been implemented. I worked alongside a member of the commercial team and the engineering team to create these designs over the period of about three weeks. At the time of writing this, the back-end functionality outlined in the designs is being implemented, and front-end development is in the roadmap.
Project Background
The Problem
Since the financial crisis of 2007-08, banks and financial institutions have come under increased scrutiny and regulation. The burden of responsibility for banks to know who their customers are falls entirely on the banks themselves. A bank cannot claim to have had no knowledge of a customer or client’s activity, since the banks are legally required to investigate such activity themselves.
This process of verifying the identity and legality of clients and client activity is known as know your customer (KYC). Similar to the requirements banks face over verifying the identity of their clients, regulations also require that they do the same for their internal employees. Investment banks must identify illegal trading patterns such as front-running, insider trading, or market manipulation. If the bank fails to monitor these activities, it could face fines of hundreds of millions of dollars.
Because of the high risk of receiving hefty fines, banks employ hundreds of investigators to monitor trades and spot suspicious patterns. Currently, this process requires a significant amount of manual effort that could better be automated.
The Solution
Dashboard View/Home
The first part of the product is a dashboard that provides a broad overview of the entire organization over time. Banks currently have software which automatically generates alerts when certain pre-programmed criteria are met. Over 90% of these alerts do not actually correspond to real-life criminal activity, but nonetheless, they must all be investigated.
This page contains a graphical overview of all of the alerts that are generated, closed, or escalated within a given time-frame. Below, this information is broken down based on each investigator at the company.
Anomalies View
Anomalies are any suspicious activity that occurs during the investigation phase of the process. For example, an individual investigator could close an alert for insider trading in an unusually short amount of time. Because this type of alert normally takes a certain amount of time to close, an anomaly is recorded.
This view provides a sortable, filterable list of all anomalies that are recorded, as well as the investigator associated with the anomaly.
Intelligent Grouping and Prioritization
Algorithms build an intelligence layer around alerts to prioritize them by risk. A risk score is generated, which assigns a score out of 10 to signify the risk of each alert. Alerts are grouped via suggested groupings, which automatically assign similar types of alerts to different investigators based on experience.
Risk Metrics
In order to help identify high-risk traders, this view provides an overview of each trading division within the company. Each card represents a different trading floor, with the total number of alerts generated represented by a graph, and the top 3 riskiest traders identified.
An individual snapshot is also provided of each individual trader. An overview graph presents all alerts triggered as a result of an individual’s trades, and below, those alerts are further broken down by trade type and by product.
Performance Optimization
Because of the sheer number of alerts generated on a daily basis by a bank’s internal software, a significant amount of human manpower is devoted to investigating alerts that are actually false positives.
To optimize performance, this page gives an overview of the proportion of false positives to actual alerts over time in order to identify trends. By tagging alerts as false positives from the beginning, the burden placed on the investigators is lessened, allowing them to focus their efforts on investigating true alerts rather than determining whether something is an alert in the first place.
Next Steps
As of June of 2017, back-end work has begun on this product. Because these designs haven’t yet been implemented on the front-end some aspects of the design may change. The designs presented here were completed during a very short time-frame, and therefore I didn’t get the chance to do detailed user research into the specific customer segment that’s being targeted.
The immediate next steps design-wise are to get feedback from our customers and users, and change the designs accordingly.