The story of Evidence Based Compliance
How do you design financial products that delight customers and keep the Financial Regulator happy? That’s the challenge that our financial services clients are facing. This blog tells how we’ve devised an innovative new process to help them thrive in this tough Regulatory environment.
Evidence Based Compliance is the product methodology we’ve developed over the past four years, even though for three of those we didn’t realise we were doing it! As we’ve worked deeper and deeper in the financial sector we’ve naturally become exposed to the different ways that regulatory risk is managed in organisations. And we’ve developed ways of working with compliance teams and compliance officers to help manage that risk.
Here’s the backstory - the Eureka moments that have shaped cxpartners’ innovative approach to financial product development.
1. Apply good user-centred, iterative, collaborative design practice
Being experienced Experience Design people we know that it’s smart to involve everyone who has a stake in the outcome of a project or knowledge that could contribute to better outcomes as early as possible. But that wasn’t the way most of our clients worked. They often held compliance teams at arm’s length, submitting things for approval late in the process, resulting in disappointment and difficulty all around. So we explored ways to engage the compliance team early and to not over-refine our design solutions until everyone agreed we were on the right track.
We built the first foundation over a two-year programme of work with a major high street bank. We got compliance in the room early and sprinted ahead with sketchy full journeys that were changeable, and we tested them with customers - that way we didn’t waste time, and we didn’t commit to difficult-to-change detail too quickly. We tested for the outcomes that the FCA and compliance and the customer needed to see and we learned to use iterative testing cycles to halt versions that didn’t deliver and back up, before moving off in a different direction. This is good practice in most design, but imperative to designing in regulated environments.
Working with a virtual network operator who wanted to innovate from their core proposition to embrace the opportunities provided by payment regulation PSD2, we discovered that they knew less about PSD2 than we did. So, we needed to be the regulatory experts as well as designers, and we quickly got across the detail of the relevant parts of the regulation. We loved doing this and in doing it we learned that regulation is just another design constraint, shaping the solution space.
“Regulation is just another design constraint, shaping the solution space.”
2. Understand the need for deep regulatory expertise
But understanding the regulation isn’t enough, it's important to embed these design constraints within the design process in a way that makes sense. To achieve this we translated the regulatory material into experience design outcomes (or acceptance criteria) that we could test with real customers.
Doing this helped us get away from vague, ‘to the letter’, legalistic interpretations of the regulations, towards crisp, testable outcomes that reflect the spirit of what the FCA intend. We used these to challenge our designs by testing them with real customers.
3. Create a working set of design principles that embrace the spirit of FCA regulations (as well as the letter)
We found that not only did we now have a set of design principles that became our North Star throughout our design sprint, but that because we had captured the outcomes the FCA wanted, we could also identify where some of their ’to the letter’ guidance was wrong - and importantly we could provide the evidence to support this. In this case, the evidence was that ‘following the letter’ often led to confused uncertain customers, whereas our innovations delivered clarity, and unsurprisingly better commercial outcomes too.
We learned the value of understanding regulatory material on our own terms; bringing it into the heart of the design process as an explicit testable design benchmark and most importantly not losing sight of the spirit that the FCA intended to achieve, rather than focusing overly on the letter.
4. Build in an evidence trail
Working with a household name insurer on IDD we realised that reasonably, the Regulator may need to see evidence that the right process and principles have been followed. So we made sure that the design versions, the cul-de-sacs and the ‘happy path’ were all documented, and that user testing sessions in which we challenged our designs with the FCA’s intended ‘outcome criteria’ were recorded on camera.
Finally, we ensured that the full Design Rationale was recorded. We delivered this to the compliance team as ‘insurance’ should the regulator come asking for evidence that the principles of IDD had been embedded and that customer’s best interests had been put at the heart of design.
Evidence Based Compliance (EBC) was born.
Since then we have been evolving EBC to encompass best practice design principles that appear fundamental and generalisable to specific FS products, that appear to provide better design options than those specified in a given piece of regulation.
EBC design principles
- True collaboration - get compliance and commercial together early
- Put customers at the heart of the process - adopt user-centred design
- Agree testable outcomes that make things better for customers, embracing the spirit, not just the letter, of the regulations.
- See regulation as a helpful design constraint - it’s not a barrier to innovation
- Prove it - build an evidence trail
What comes next?
It’s been quite a ride and we’re not done yet. Next, we’re planning and testing the development of a digital framework so that we and our customers can more readily plan, execute, deliver and capture an EBC project.