Scroll Top

A Control Engineer’s view of the Three Lines of Defence (Part 1)

Introduction 

I recently spoke on a panel session at the 1LoD Conference in Hong Kong. The title of the session was ‘The Role of the 1st line within the evolving 3 lines of defence’ and as part of this I was asked what Asia could learn from the experience of implementing the Three Lines of Defence (3LoD) in Europe.  

It is easy to give piecemeal answers to a question like this, and provide an eclectic list of issues like a lack of coordination and duplication between the lines of defence. Useful though these soundbites might be, they do not provide much of a context for thinking about how to design an effective 3LoD framework. In thinking about how to give a more useful answer it struck me that the 3LoD model bears a strong resemblance to the engineering control systems I worked with earlier in my career. As we did not have time to explore this in detail during the panel I thought it would be useful to provide more details in a follow up note.  

In this note we consider a simple ‘control system’ view of the 3LoD and how it helps to provide a context for some of the current challenges of 3LoD implementations.  In a later note we consider how this view can be used to guide the design of a 3LoD model which better fulfils the various objectives. 

What is a control system? 

In engineering terms a control system regulates the behavior of other devices or systems using one or more control loops. These control loops contain the following elements (see figure 1): 

  1. The item or process being controlled e.g. a robot, a chemical plant  
  2. The desired outputs or targets generally referred to as the ‘set-points’  
  3. Sensors to make measurements corresponding to the desired outputs  
  4. A controller which uses the sensor measurements and target to determine the actions  
  5. An actuator to implement the desired actions 

A simple example of a control loop is regulating the temperature of a room with a thermostat and heater. Say we want to hold the temperature of the room at 20°C (set-point).  The thermostat (controller) measures the temperature of the room (sensor) and switches the heater (actuator) on if the actual temperature is below the desired temperature. This is referred to as “closing the loop”. 

Figure 1. A simple control loop

The 3LoD as a control system 

In control engineering parlance, the 3LoD collectively could be thought of as a control system that monitors the actual business risk versus the firm’s risk appetite, and takes appropriate actions (Figure 2).   

Figure 2. 3LoD as a control system

At a more granular level, each of the three lines of defence represents one or more individual control loops, e.g. pay/reward and conduct. Interactions between the different control loops and the lines of defence add to the overall complexity; in control engineering terms this is referred to as a multivariable control system.  

There are a wide range of mathematical methods used to design control systems. While these work well with systems that can be modelled with some degree of accuracy, like robots, clearly organisations, people and their behaviours are less easily modelled. Nevertheless, many of the principles of good control design still apply.  

In fact, I would argue that many of the challenges that are being experienced with existing 3LoD frameworks are a legacy of the somewhat iterative and experimental way in which they have grown up.  This being the case, looking at them through a more ‘scientific’ and less subjective lens may provide insight into where things could be improved. 

Typical challenges of current 3LoD frameworks 

Now that 3LoD frameworks have been running for a number of years a number of challenges are starting to become apparent: 

  • There is a tendency to gather data for the sake of it. This creates a significant and increasing burden on the first line who are often the providers of the data. 
  • Data is disseminated too widely (and high) in the organisation without a clear understanding of why or what action is required. 
  • Inconsistencies regarding the activities which should sit in each line (especially for 1st and 2nd) and therefore how firms resource these effectively.  
  • Consequently, there is overlap between the lines of defence, particularly in relation to the second line and the other two. This leads to confusion, conflict and a lack of trust. 
  • ‘Knee-jerk’ changes to the model and processes create inefficiencies. Checks and balances are ‘bolted onto’ business processes rather than being designed in. Similarly, there is a lack of consideration of the impact of changes in one area on other areas. 
  • Ultimately, there is a lack of measurement of how well various implementations of 3LoD achieve the organisational objectives and how efficiently they do this. 

A control engineer’s view of the challenges 

Figure 3 explodes the simple view shown earlier to illustrate some of the complexity of the practical interactions that take place in typical 3LoD implementations.

Figure 3. 3LoD control loops

At the same time it starts to indicate the areas where challenges can arise: 

  1. While in theory there is a common risk appetite for the firm defined by the Board, in reality different areas may be operating to different de facto appetites especially in areas like operational risk where risk is less easily quantified. Similarly, the perception of the actual level of business risk may also differ, again where it is not readily quantified.  
  2. While there are information flows between the lines of defence, the role a lot of this information plays in closing the loop is not well understood. Instead, there is a tendency towards the ‘data trawling’ mentioned earlier. In engineering control systems, where the cost of additional (redundant) sensors is better understood this typically would not happen. 
  3. In fact, in some cases too many sensor inputs can result in instability as the control system ‘over-reacts’ to the sensor data. Again analogous behaviour can be seen in the practical operation of 3LoD frameworks. To counter this behaviour industrial control systems are ‘detuned’ to reduce their sensitivity to extraneous data. However, this comes at the expense of a generally more sluggish response – a bit like driving with the brake partially on.  
  4. The net result of poorly understood information flows between the lines of defence is that, rather than operate as a truly integrated whole, they tend to operate on the business as three loosely-coupled parallel loops. This has significant implications for both the efficiency and quality of the control over business activities.  

Conclusions 

In the 1LoD panel session I gave a simple if apocryphal illustration of how poor control design can lead to both inefficiency and a poor outcome. For obvious reasons, most houses in Hong Kong have air conditioning but not central heating. In 2016 Hong Kong experienced a rare cold snap (3.1°C) which was the lowest temperature the territory had seen for 57 years. A cautious person might decide to install a heater in their house alongside the air-conditioner. Now we have both working alongside each other. Imagine if the heater was set to maintain the temperature in the room at 20°C and the air-conditioner was set to 16°C. Above 20°C and below 16°C the system would appear to operate efficiently with either the heater or the air-conditioner running but not both. However, once the temperature is in the range 16-20°C both machines are on and working at cross-purposes with the heater trying to increase the temperature and the air-conditioner working to reduce it. Eventually they may settle out at some sort of equilibrium but at a greater (ongoing) energy expenditure and achieving neither machine’s target temperature. Obviously, no sensible person would manage the temperature in a room that way. I leave you to draw the parallels.