Skip to main content

The anatomy of good design

A convergence of many playbooks

This article is part three of a three-part series written by Deloitte risk leaders, providing insights and practical advice on how organisations can better align the regulatory agenda with broader business goals. You can read part one here, and part two here

Efficiency, cost and lost productivity

Highly regulated industries, including financial services, energy retailers or distributors, and telcos now contend with an ever-increasing set of regulatory obligations. These new regulations, and their required system and process changes, are complex and costly, which means programmes often tail off quickly once the compliance date is met.

As a result, the underlying engineering is never optimised and the regulatory burden continues to increase. This creates inefficiency, additional cost and lost productivity as staff continue with reactive compliance activities.

Whether there is new regulation or you recognise what you do today needs to be more effective and efficient, there are changes you can make to your traditional approach to get a better outcome. 

The missing chapter

Organisations usually possess mature playbooks for implementing business and technology driven change. However, the DNA of recent regulatory failure events tells us that playbooks used for more generic change purposes give limited thought to those projects supporting regulatory outcomes, including:

  • Optimising how regulatory requirements are delivered with confidence to support evidence-based traceability,
  • Considering how future operational change that impacts regulatory posture is addressed to promote continuous compliance, without the need for costly future redesign,
  • Reducing reliance on inefficient and expensive archival reporting techniques by ensuring design includes early warning lead indicators,
  • Providing confidence to internal and external stakeholders that regulatory obligations are being met at all times, not just when a regulatory review happens, and
  • Developing risk operating models that have the characteristics needed to design, implement and support ongoing business as usual regulatory requirements.

Don’t look back and wonder

Reliance on historical reporting can’t be the single safety net for a business that has a significant regulatory dimension.

Not only is historical reporting often not timely enough, the use and maintenance can create unnecessary overhead.

Most playbooks describe the need for a risk and reporting workstream because these are necessary components of good risk management. These workstreams develop the business intelligence to support the testing of operational controls. However, along the life cycle of the programme, it’s not unusual for the following to occur:

  • Time and budget dimensions become challenged, requiring a de-scope of what does not add value to the customer or user experiences,
  • Report design does not relate to the regulatory risks being managed or useability is sub-optimal because the risk operating model has not had sufficient consideration,
  • Reports are designed as “detective” manual controls, which become orphaned over time as there was not sufficient clarity of ownership and purpose, and
  • Time pressures dictate that this workstream becomes a “Day 2” initiative (despite the possibility that a non-compliance event could start incubating on Day 0) and as a result, the governance mechanisms designed to enable a good outcome fall away.

It’s essential that playbooks supporting change with significant regulatory obligations consider all the above. Ensuring demonstration of how obligations are met is included in the design phases of the programme, will help reduce the reliance on look-back reporting and costly, inefficient control testing.

If technology is included in the solution suite, go-to-market and vendor procurement activities must include requirements that support the enforcement of regulation from the outset.

Testing confidence

Testing regimes developed to support technology change typically place minimal priority on demonstrating that the regulatory obligations are being met at a system level. When it is included, it’s likely that the testing regimes are retrospective, and designed to be executed later in the project life cycle, providing little time for re-engineering.

Ensure your playbook provides guidance on how testing protocols which create confidence that obligations are met are included early in the project lifecycle. As with any testing approach, effective business engagement and the necessary governance mechanisms to support approvals need to be agreed from the outset.

And finally – learn from where you have succeeded or otherwise

Complete the necessary Post Implementation Review. Openly examine regulatory failings. Continually refine your playbook.