It has been amazing to see how firms across the Wealth Management industry have managed to implement remote working so quickly. Whilst there have been undoubtedly challenges, in particular with contact centres given the technological requirements (see our whitepaper on Contact Centres in a Crisis) overall it has been a testament to everyone getting on with it and making the best of this situation.
It has been interesting to see how providers can now accept requests without a wet signature and how firms and people have had to embrace digital ways of working. Will this new way of working remain, once we are out of lockdown? Will firms operating models change for the foreseeable future? And what does this mean for their control environment? Will they need to review their processes in light of what can be done, given these extraordinary circumstances?
Control design is key to any process – controls are there to mitigate risk but can also add cost and inefficiency, so it is a fine balance. There are many examples of where firms expected customers to go through a rigorous and sometimes manual process; which then needed to be checked; to fulfill their request. In some cases, these have had to change or fall away as people are unable to leave their homes. At Simplify Consulting, we understand control design and effectiveness; especially in an operational environment. We have documented our thoughts on what you need to consider when designing and implementing a control…which is relevant in pre, during and post lockdown.
| Principle Name | Principle | What does it mean? |
| Control Efficiency | A control should not add additional effort to a process | Controls should be designed so that they are automated.
Controls should prevent downstream rework Controls should be preventative where possible to reduce process inefficiency. Manual controls should be avoided where repeating the initial process step is designed to evidence the accuracy of the original transaction. |
| Control Positioning | A control should be implemented as early on in the process as is feasibly possible | A control should be triggered at the earliest possible point in the process to prevent downstream failures/rework.
A control should capture and address initial process failings before allowing subsequent steps to be triggered. Controls shouldn’t be implemented post process completion, unless the risk is sufficiently low to justify it and the implication of reversing or correcting the process doesn’t manifest in an additional risk itself. |
| Control Consistency | A control should reflect the risk, the nature of the proposition and the criticality of the process, but be designed in a consistent way | Controls should follow a consistent pattern in terms of how they mitigate risks for similar processes (e.g. payment processes should be protected by adequate controls that are aligned to how the business wishes to manage fraud risk)
Manual controls should be designed agnostic of systems, but be consistent in how they are implemented across propositions. |
| Control Description | A control should be documented in a measurable way so that its effectiveness can be assessed against how it intends to mitigate risk | A control should be ‘SMART’; specific, measurable, achievable, realistic and timely.
A control should have an owner defined (or be delegated down from the process owner). A control should be directly linked to a risk. A control must enable MI to be collated to evidence it is working as intended |
| Risk Appetite Relationship | A control should be designed with reference to the overarching risk appetite as defined by the business | A control must be consistent with the level of risk that the business is willing to accept (e.g. a business-critical process where there is zero appetite for losses should have a robust control implemented that works 100% of the time) |
| Control Completeness | A control should itself not require another control to evidence its effectiveness | Multiple layering of controls (e.g. a control report being produced requiring reconciliation to ensure it is accurate) should be avoided at all costs.
A control must ‘work’ 100% of the time. There should be no scope for error or failure. Controls must be tested regularly to ensure they are fit for purpose |
| Control Application | A control must be applied consistently with the opportunity to circumvent it minimised or eradicated. | Controls should be automatically triggered wherever possible.
Evidence of manual controls not being performed must be identified through MI. A clear audit trail of a control being executed must exist to demonstrate consistency of application. |
| Manual Controls & Human Interaction | Controls creating a dependency upon manual intervention must demonstrate sufficient levels of human capability consistently to maximise effectiveness | Controls requiring human intervention must regularly be reviewed to evidence that those responsible for carrying out the control are fully competent
Any changes to resources (e.g. promotion, demotion, change of role) assigned to executing controls must be considered in the context of the control. There must be a sufficient number of capable resources to execute a control (e.g. avoid single person dependencies) |
| Control Documentation | Evidence of a control in existence must be found in relevant documentation | Process maps must contain reference to the controls that are in place.
User guides and operational procedures must clearly describe the steps required to enact the control. It must be possible to link risk events and operational incidents to controls, to evidence potential failings and propose improvement opportunities. |
| Process Accountability | Controls should be designed to ensure that those performing the process remain accountable for the accuracy of achieving the outcomes expected in the timescales demanded. | Controls that highlight process failures should result in corrections being performed by the originator, not by the resource executing the control.
A process hand-off where elements of a process are performed by different people is not a control in itself. |
| Control Durability | Controls should stand the test of time and be fit for purpose for not only today, but for reasonable and predictable changes in the business environment in the future | At the point at which the control was implemented, it may have been designed to be appropriate to a given volume or criticality. That may have changed and therefore the control should be considered in respect of potential changes in the business environment (e.g. does the control work for 10,000 cases as well as it does for 100?) |
| Control Timeliness | Controls should immediately capture any process failings and flag them without delay. | Preventative controls should be real-time if possible, reducing the risk of delays being incurred as a result of a lag between the control being executed and the results being produced. |
| Control Review | Any time a process changes, the controls should be reviewed to ensure they are still fit for purpose | Controls associated with the previous process design may not be appropriate for the target process; as the risks may be different |
If you want help in discussing, assessing and improving your control environment, get in touch today.
Written by Kate Monserrate, Director at Simplify Consulting
Simplify Consulting. It’s what we do.