Risk management for agile and ecosystems

Guest author Richard Davies follows up his blog on leading agile at scale, with a deeper dive into principles of risk management in agile and for ecosystem development

From my travels with the China tech giants, one of the aspects that struck me was the profound focus on executing at pace while ensuring risk management is central and robust. Sustainability needs to be designed into a business model from the start, and in finance risk management is critical to sustainability.

In this context, a couple of weeks ago I published some thoughts on scaled agile leadership, and alluded to the importance of how risk management and governance processes are adapted for new ways of working. Arguably this is the hardest aspect of scaled agile in finance.

I also posted a video by David Marquet on applying agile to a 200 man nuclear submarine crew – which must equally be considered a highly regulated environment so it is possible! The video is definitely worth a watch…

Risk management under agile - in a nutshell

In its briefest form, risk management under scaled agile means the agile proposition and product owners in the squads need to have a strong grasp of assessing and owning potential risks their work will create, with specialist risk experts available to work with the agile teams wherever needed.

The agile team should be supported by their first line senior management on risk identification and mitigation, with the second line providing oversight of the activity in the first line, including adherence to agreed policies and regulatory requirements. It’s probably fair to say that the clarity of roles and responsibilities between first line (hands-on risk management) and second line (risk oversight) can be a work in progress in many banks, which is key to get right if you are to operate effectively under agile.

Keep only the most major decisions for senior management

As with the launch of a weapon on the sub, there will be critical decisions that must be made by senior management – but the majority of decisions need to be delegated to the squad to work through within a best practice risk framework. This will also require strong training for the agile proposition owner, as it’ll be rare to find people with the full combination of customer design, technology, and risk skills fully honed.

Continuous Learning

Agile encourages continuous learning and this is certainly something that will be required in regard of risk management. For example, during the course of initial use of agile, it is likely that a number of areas of potential bottleneck and last minute discoveries of required approval steps will occur, as everyone is new to the way of working. It’s key that these are captured in sprint retrospectives and briefly documented and honed into best practice for the scale agile organisation. For example, to engage a specific area of risk expertise earlier, or re-looking at the governance forums that are in place and any duplication (or increased delegation needed) where a project needed to navigate a multiplicity of forums. Risk management should by nature err on the side of caution, and iteratively moving towards improving velocity is important – and the mindset of the leadership to underpin this is critical.

Avoiding bottlenecks through early and ongoing expert input

The concept of flow and visualisation of this (e.g. Kanban) is at the heart of the practice of agile, so as not to create bottlenecks in any one area. Therefore the input of relevant specialist risk functions from the start of the work is important – and where a particular risk is a critical component (e.g. financial crime in an on-boarding journey) there should be dedicated resource providing input day by day with the squad.

If a risk area is touched but not at the core, then the ability to have appropriate expert input and/or approval (as required and being clear on which is needed) facilitated by appropriate workflow management will be important so as not to reach bottlenecks at the back end of a new feature. Essentially a backlog of risk stories can be created to accompany the primary user story backlog in a sprint. The target should be to have risk embedded into the ways of working and the definition of done (certainly at a feature / epic level). Clearly having the required specialist risk resources available to handle this is key, and will likely mean having specialist risk resources that work across a few agile teams focused within a particular domain ( or “tribe”, in Spotify’s terminology).

Visualisation is valuable

Visualising the risk register can also be a very helpful technique as typically this is buried in an internal system or spreadsheet. Having the key risks on the wall next to the backlog helps keep these in focus for solving contextually rather than when a particular governance point is hit (which often leads to rework). This very much applies at the portfolio level also, where a wall showing a portfolio backlog of epics, 1-2 quarter ahead portfolio roadmap, dependencies and the key risks and planned mitigants, can be essential in underpinning scrum discussions and providing strong visibility back to the accountable Senior Manager (in the UK regulatory regime).

This doesn’t negate the need for standing governance forums – which are important to provide meta-risk management, in terms of monitoring against aggregate risk appetite and approval for major decisions or policies with wide application. However, the strong aim should be to avoid the multiplication of governance events that often occurs as each functional area has its own forum. In general, the guiding principle should be that the decisions for a specific project should lie with manager for that project, unless there are wider implications from what is being done.

Audits must incorporate agile

Finally from a third line (internal audit) perspective, it's important that the audit methodology incorporates agile – so for example there is not an expectation of a heavy up front business / functional requirements document, rather this is expected to be incorporated iteratively in the backlog, and importantly in the definition of done for completed stories.

Turning specifically to agile platform/ecosystem risk

Perhaps the most interesting area to me of the future of agile risk management, is with regard to the ecosystem that will emerge of APIs, platforms and partners. I think this goes well beyond the obvious cyber security elements which has understandably had a lot of debate with the CMA and PSD2 open API regulation/legislation.

Risk management instrumental in success of Open Banking

Outside of security, the topic of risk management has had minimal coverage from what I can see, but I think it will be pivotal over the long term to the success of open banking because:

• History says that banks will be held responsible if things go wrong, because they are highly regulated entities with deep pockets
• Experience from correspondent banking would show there are certainly some key parallels and pitfalls to consider
• Ultimately the core competence of a deposit-taking bank needs to be risk management – its most fundamental duty is to keep safe what people have entrusted to it (gold bullion, securities, cash and data)

Openness is the future

Before going on, I want to say I am very positive on open banking – including playing a significant role in advocating this to the CMA panel back in 2015 – and I believe huge customer benefit can be brought through well constructed ecosystems. Openness should enhance price competition and enable much more targeted customer experiences, and will likely have a very substantial impact on banks’ business models and all banks should be thinking about their strategic position in this.

My point here is that those creating this future in financial services have a duty to be thoughtful about what this new world needs in risk management, and how to accommodate this in the agile development of ecosystems. I.e. how to achieve great outcomes, with strong risk management, at pace.

But let’s bring some scenarios to life

Let’s think about some scenarios to help to illustrate possible risk areas

• Bogus duplicate apps on Google Playstore
  • These can contain malware, and seek to get the user to download these over the app they were actually looking for. Clearly this sort of issue in a banking context would rightly get very short shrift from the regulator, hence apps on a bank marketplace need appropriate vetting, and access to read/write APIs require qualification of the AISP/PISP under CMA and PSD2.
• A P2P lender integrated onto your platform.
  • A company borrows from them, and they get into financial difficulty, and the P2P lender takes highly aggressive workout practices to recover the money for their investors (clearly big banks have been accused of this in the past… see RBS GRG) – does the platform have any liability for the actions of the platform it has quasi ‘recommended’ (as it has vetted them)?
  • Or a number of retail clients invest with the platform, and severe losses are seen in an economic downturn, and the retail clients complain to the FOS that the platform ‘recommended’ the P2P. What duty of suitability is there on the platform that introduces the provider?
• Frictionless finance, with ethics
• • I think the really interesting debate should be in the ‘frictionless’ customer journeys that everyone in banking and fintech now talk about. Services should be as automated and invisible as possible, with data driven predictive recommendations for one click access. On the other hand, there is growing body of debate in tech about how cutting edge design is pre-empting and exploiting human cognition, to create highly addictive experiences, gather huge reams of data, upsell and direct user traffic where the tech firm desires. Maybe it’s just me, but if finance gets near the frictionless state (and to be fair it’s a long way off in general), and with commercial incentives for marketplace firms to refer customers, then this creates significant potential for conduct risks, as you are then combining an area (finance) that is known to have really poor education and understanding, with the most advanced cognitive design techniques. Here ethics and thoughtfulness in design will be paramount to avoid mis-sell scenarios (for a very crude example 15 years ago, see opt out PPI boxes on loan forms…)

Is Legalese the answer?

Now you could try and protect your firm through legalese. Indeed I have seen a company (who shall remain nameless) try and say through their T&Cs, ‘these apps just happen to be on our marketplace, so nothing to do with us if anything goes wrong’. Now for me I think this just doesn’t work. Given providers will have been vetted and are typically paying to receive referrals, it won’t wash. History says regulators will look to the banks in these scenarios to put the customer right if there is an issue, and legalese does not protect from this (that’s not to say the legal terms here don’t need very careful consideration!).

What does good risk management look like for APIs/platforms/partners?

Risk management frameworks are typically founded on the principles of:Identify, Evaluate, Mitigate, and Monitor each area of potential risk.

Institutions will already have a risk taxonomy (generally centred around overarching categories of Credit, Market, Operational, and Conduct), and it’s helpful to bring this to life for the agile teams as part of training and guidance, such that risks that are particularly likely to be relevant are highlighted for consideration in ongoing sprints – in my view these would include:

• Information security – Unauthorised access to customer data at bank or provider(s)
• Conduct – e.g. skewed incentives from referrals, ensuring effective disclosure in a low friction digital process, unsuitable recommendation, inappropriate sales push from partner (and associated reputational risks)
• Operational continuity – both partner side customer service outage/disruption (e.g. the well trailed outages seen recently for a number of pre-paid cards), and outages/data errors caused by changes or disruption to your own systems/APIs (e.g. can a legacy mainframe handle the increase in traffic from a widely used API)
• Data privacy – customer understanding of how their data is being used for additional services, and compliant permissioned storage of this data under GDPR
• Financial crime – providers’ services (e.g. overseas payments, mobile payment acceptance) may carry AML/CTF risk, and the received funds will very likely flow back into the platform’s current account (certainly parallels here to correspondent banking)
• Compliance with regulation – providers’ services may have specific regulatory requirements (e.g. CONC for consumer credit activities, or legal services)
• Credit risk – if deploying the bank’s own funds into referrals made to a lending provider, then clearly credit risk robustness is key (and indirectly if clients’ monies are being invested into the provider)

As part of risk management in agile development, the agile proposition (here platform) owner should be identifying specific risks relevant to their work, supported by their senior management, and with oversight from the second line. These risks should be evaluated (e.g. via scenario analysis) for likelihood of occurrence and severity of impact to classify level of risk. Risks defined as very high or high should be mitigated via appropriate controls and processes to reduce the residual level of risk, while low/medium risks maybe risk accepted or mitigated. Risks should be recorded in the risk register and monitored, with quantitative risk appetite measures set against key identified risk areas.

To help maximise velocity while limiting risk, the aim of the proposition owner should be iterative ‘canary releases’ that help manage the ‘blast radius’ of the potential risks by an incremental roll out to the customer base, and allow for ongoing learning about the nature and extent of these risks without the risk of major immediate downside. Here the Senior Management and risk governance forums and policies need to play a key role in setting this risk appetite within which the agile teams should be empowered to operate.

Some common controls to consider

What sort of controls might work in mitigating ecosystem risks? This clearly needs to depend on the nature of the fintech relationship (JV, white label, joint branding, referral…) and the key risks. For sure there are common elements to always consider such as:

• Upfront due diligence and regular review (financial, technical, KYC, etc)
• Clear roles & responsibilities, liability, and legal contract embedding identified risk controls
• Thinking through any potential biases from referral fees / revenue sharing
• Alignment of customer service approach & SLAs (eg how complaints will be handled)
• For operationally material services right to audit, contingency planning, step in rights, etc
• Performance reporting and monitoring, joint risk register

So who owns the risk?

Classically third party relations have run across a mix of functions – e.g. product management, procurement, technical channel management, etc. In my view this needs a dedicated role or team and expertise. Particularly so if this is core to the ongoing business model, then they must be sitting in an appropriate business position and be senior enough to act as first line risk owner (under UK regime this would likely mean reporting to a Senior Manager).

If an API platform is to be central to the business model, I would suggest also a platform risk specialist in the second line would be advisable, given the nature of the risks and how they interact maybe very different to traditional proprietary channel/product risks. The second line needs to provide independent oversight and assurance on the first line’s approach to risk identification and mitigation, adherence to regulatory requirements, as well as report on aggregate risk exposures – practices that are common in areas such as credit risk, but I would suggest are immature at best for a platform environment in both first and second lines.

Closing thoughts

This is an immature area, and one that I have seen very little coverage on in the fintech space. Clearly this is because it’s not sexy… but it is critical for long term sustainability! Hopefully the above stimulates thoughts and discussion on how to rapidly mature it, as it will be a key element over the next few years as scaled agile is used widely in FS, and ecosystems rapidly develop.