The targets of this article are financial institutions that build or buy risk platforms to cover the investment & contract lifecycle. Given the relative ease of software development today, this article provides some simple, proven tips that will transform most risk systems. The purpose is to avoid seeing risk only through the lens of limit breaches and latent background monitoring. Instead, risk systems (and their data) are integral to a firm’s activities. This article is a teaser, that assumes some prior knowledge of risk management (see previous articles for more details).
All businesses are subject to constraints. In terms of Risk Management, these come in the forms of regulatory constraints, treasury funding constraints, and constraints from firm-wide risk departments (and policies). For the Buyside, it could come in the form of investment conditions and parameters. These typically translate into hard limits (such as $ exposures). Businesses can sometimes react impulsively to the growing number of these constraints. Negative responses could include going through states of denial, and under or over estimation of the requirements. As a result, Risk Systems are developed over time in a rather reactionary way, responding to poorly written points of audit, or an over-simplistic interpretation of the next slew of rules & regs. If the responsibility and ownership of these systems isn’t defined, then the firm gambles on suboptimal systems and the increased possibility of a meltdown. For example, the firm may have a rudimentary set of risk controls, but perhaps this comes at the cost of team capacity issues. These risk teams can be overwhelmed due to the noise of false-positive limit breach alerts. Alternatively, technology teams may be preoccupied fixing the defects of these hastily deployed risk systems, or tacking on features to address original design flaws. Here are three simple tips to optimise your risk systems and help avoid these problems.
Tip 1 – understand the intrinsic purpose of your risk system. Capture the current and likely prospective set of requirements. Who will use the system? For example, is it for the business to understand the client or investor activity and trends? Or is it purely for a control function to manage stricter limits within a basic business risk appetite? And will it be used for 2nd and 3rd line functions to use the system’s output as evidence of compliance with rules and regs? Most systems outgrow their intended use – so it’s important to capture and efficiently document the intended or current use. This helps inform the decisions when to upgrade, and when to replace systems. It’s also important to represent the system not in isolation, but in terms of its technical handoffs (to other systems – inputs and outputs) as well as the operational handoffs (how the users of the system interact with other teams). In short – understand your risk system’s place and function within the broader technology and organisation structure, then try to predict it’s desired role.
Tip 2 – get your hands dirty with data. Data is king, and it is also simpler than you probably imagine. Most of the complexity of risk data is through human misunderstanding of what it is and how to optimally capture or produce and store it. Data should be broken down into components, objects, attributes and relationships. Question the quality of the data (including the data completeness, and the degree of normalisation). Golden sources are always worth identifying (even if it’s to know that they do not exist). Question the authors or publishers of the input and reference data, and challenge all assumptions. In short – build a strawman of the data, and assume it’s not going to look pretty.
Tip 3 – consider what risk management workflows exist or are desired. Workflows are often politically sensitive as they have expectations on teams (i.e. they need to respond to events and there may be SLAs). It is helpful to see risk not purely as a single event (such as a risk limit breach) but as a series of events (such as in the run up to and the aftermath of a breach). Workflows require flexibility, as organisations and roles change organically. It is also often an iterative process in discovering what is the optimal workflow. Provision of supporting data and metrics (alongside workflow tools) supports better quality decision making. In short – it’s important to see risk as a series of events, and look for flexible workflow tools to aid the decision makers.
Ultimately, it’s easy to see risk systems (and their risk data) as a bolt on, or peripheral to a business. However, making that mistake, and being purely reactive to regulatory, funding or firm wide risk restraints will typically result in poorly designed risk systems. It also reduces the effectiveness of your business and risk function. The three tips to improve the design of your risk systems include, knowing the intrinsic purpose of the risk system (and how it fits within your firm), getting your hands dirty understanding the rough data model, and finally considering how to use the risk system through workflows and team interactions.
More information and formal selection review is available upon request.
Norton Edge provides Subject Matter Expertise, helping you understand limits management, risk alerting, scenario and stress testing. This overlaps with surveillance and regulatory reporting expertise.
Our experience is cross asset class, and a broad range of firms from small family office and proprietary trading companies, to large buy or sell side institutionals integrating or developing new electronic and risk platforms. Norton Edge provides guidance straight from the designers-in-chief and business owners of Risk Platforms and broader Risk Systems.