Sponsored webinar: MetricStream

The Panel
Gaurav Kapoor, Chief Operating Officer, MetricStream
Lisa White, Audit Director of Corporate, Retail and Wealth Businesses, RBS Group
Matt Ahart, Senior Vice-president and Business Unit Risk Manager of Global Capital Markets, Union Bank

Listen to the full webinar proceedings

Governance, risk and compliance (GRC) systems are growing in popularity, with 62% of banks saying they have a system in place or being installed, or plan to buy one in the next 12 months, according to the Operational Risk & Regulation compliance software rankings survey (see page 26). But this decision is not the end of the process. Installation can be lengthy and costly, and operational risk managers need to be aware of what can go wrong and how support can be lost.

What are the key points to keep in mind during a GRC implementation?
Lisa White, RBS Group: The first thing is to be realistic about what you can achieve within the timescale. Don’t set out to do everything all at once. You need to be very clear about your stakeholders’ expectations and the benefits you can get. If a system will deliver 80% of what you are looking for, you should aim to deliver that as soon as possible to gain buy-in from your stakeholders, rather than trying to deliver everything in one go.

The key thing is gaining buy-in from your stakeholders – the value that will be added to the business needs to be clear. This will include people at the top of the business and those who will use it on a daily basis, including other functions within risk, control, compliance and the IT department. It is likely the system will need to be integrated with a number of legacy systems and, if it is an IT platform you’re implementing, you need to ensure the stakeholders are aware of what is coming and what they have bought into. The other thing I would note is that people within risk don’t always go through the risk process themselves when they are developing a project like this, so you need to ensure you have appropriate governance and an appropriate risk framework to manage the project. You also need to ensure you are still delivering something that meets the needs of the business, particularly in the current environment in which things are changing on a daily basis.

Matt Ahart, Union Bank: Operational risk management is not just key to stakeholders, but it will lead the decision on what to implement and how to implement it. But the other side of that is the business lines may not be driving the reporting, but they will be doing the work to maintain a lot of the information, whether it be loss data or risk control self-assessments (RCSAs) in the system, so you need to make sure they are engaged. 

Gaurav Kapoor, MetricStream: We have worked with a range of banks – from the global top 10 banks to smaller Tier 2 and Tier 3 banks. In our experience, the challenges vary among these banks. For larger banks, one of the key challenges is to collaborate to create a common risk and governance framework with a common taxonomy. This is extremely important because the different groups – the operational risk group, the audit group, the regulatory compliance group, the policy group, and the legal group – are driven by their own priorities. But, their ultimate objective is to have a common framework and a clear understanding of what needs to be managed for the financial institution.

It is easier for smaller banks because the scope of their challenges is smaller in size and scale. Different stakeholders can be quickly brought together – be it the chief of the audit group, the risk group, the compliance group or the policy group – to form an understanding. But the most critical thing, irrespective of the size of the bank, is to make sure that you get as close to a common taxonomy as possible.

On the other hand, it is equally important to not try to get everything standardised. The word to keep in mind is ‘federation’, meaning that you allow different functions and groups to operate in the way they have been operating, and yet introduce some kind of standardisation so that, at some level, common information and collaboration exists between the different groups.

All of those stakeholders will tend to have their own languages and their own way of doing things. Is this a challenge?
White: It is definitely the biggest challenge. You need to start off by defining a common risk language. If everyone is describing a certain kind of risk, regulation or control in a different way, it is just not going to work. You have to at least partly define this common language before you start putting an IT system in place. In my view, an IT system is not the best mechanism to drive behaviour and common language – you have to start that journey before putting the system in, which will speed up the process of embedding.

Ahart: If you start with the system too soon, you can have a false start and end up with a system that looks good but is not necessarily going to meet all your needs properly. That can happen, I’ve seen it. It’s a tough balance because we are all under a lot of pressure to implement a robust system that will produce the reporting that our boards, risk committees and regulators want to see. But, at the same time, everyone must understand how they are going to use the system.

Why should an organisation use an integrated GRC system rather than existing point solutions?
Kapoor: You can carry on with point solutions for different organisational silos only if you have an exceptionally strong integration story in place. At the end of the day, the information has to be integrated at an enterprise level to see real benefits. The single biggest benefit we have seen in a lot of banks is demand rationalisation. A single taxonomy allows you to treat different risks, controls and processes in such a way that you don’t have to duplicate efforts within the organisation. If you look at a simple control like password sharing, it might apply to an operational risk programme, a Sarbanes-Oxley programme or a Basel framework. If you can get one integrated platform in place, you would be able to efficiently manage one control across multiple areas of regulatory or operational risk and legal compliance. That would help you rationalise the work you are doing. One of the banks we are helping has been able to reduce more than 25,000 controls to 4,000 over time.

The other thing that I would highlight is risk intelligence – an integrated GRC system allows you to bring all the risk data together, distinguish between what is noise and what is real, and start to correlate those risks.

Risk intelligence has become one of the core inputs in business decision-making. Organisations are using risk intelligence to make risk-aware business decisions and streamline their business strategies to improve business performance and build a sustainable competitive advantage.

And what are the main pitfalls to avoid?
Ahart: Trying to do too much, too soon can be a problem. You are implementing a new IT system and so all the challenges associated with an IT implementation are present.

Another concern is the extent to which people are messaging before they are being told to use the system. Even if it is a great system, if you don’t do the messaging then that can lead to a lot of frustration. It’s important to start with a limited number of users and stakeholders. You’ll probably find there are some quirks in the system that you can work on before you get everyone involved.

White: Try not to hard code; try to create some flexibility in the system. Don’t try to deliver more than your stakeholders need, and take into account the different languages and IT platforms across the different jurisdictions to which you are delivering.

Kapoor: The single largest pitfall in a lot of our deployments is not having the right level of executive buy-in. It is important for one or two individuals to have veto power. If there is a conflict between different jurisdictions or different stakeholders, someone needs to take the veto call, and that needs to be established in advance.

The other key thing is that smaller successes are very critical, especially in large deployments. One company we are working with on an integrated GRC platform established an issue-tracking system in the first two or three months that aggregated different kinds of issues – be it legal dilemmas, audit failures, control failures or risk incidents. Once they understood the issues, it was much easier to put the RCSA and audit programme in place. Smaller successes help maintain a high motivation level and justify investments – a crucial parameter in today’s scenario of limited organisational resources.

White: You tend to find builders are great at building other people’s houses but not great at keeping their own houses in order. It is the same with risk professionals: they are very good at advising other people how to manage risk in the organisation but, when they are running their own project – in this case it is likely to be the operational risk function with internal audit or compliance – they need to apply the same practices and assess the standard risks they would with any IT project.

What effect is regulatory change having on the GRC decision process?
Kapoor: I usually break down regulatory reform into three elements:

1. Creating regulatory awareness: A lot of financial institutions are still not aware of what they need to comply with or what their regulatory exposure is because of the diversity of their business lines and operating geographies. Your first goal should be to become fully aware of regulatory reforms.

2. Mapping your regulatory requirements to your core business processes: When change happens, you should be able to judge how it impacts your core business and how you can deal with it.

3. Improving your management of regulatory relationships: This is an element that we sometimes tend to ignore. It’s important to create an ecosystem of regulators, external auditors and law firms so that information flows seamlessly among them.

Ahart: Basel II is absolutely driving the GRC decision process. It is almost an imperative from a risk management perspective because you need that embedded risk culture throughout your organisation. The other changes are not driving GRC very much at all because Dodd-Frank is still very much up in the air, most of the rules haven’t been finalised and nobody really knows how to handle them. Handling regulatory change through a GRC system is not necessarily the best way to go – first, because the regulatory change and reform is frequently driven by the compliance function, and the compliance area is typically not as involved in GRC as operational risk and audit; and second, because regulatory change can take a variety of forms and they don’t necessarily fit neatly into the way the existing processes are done. 

There is a lot of uncertainty about the exact content and also the timing of regulatory changes. What kind of effect is this having on GRC implementation?
White: There is only so much preparation a business can do when the rules are in draft phase and you don’t know if there will be any significant changes before implementation.

Ahart: That is important in this environment. In the US, we are being hit with Dodd-Frank and the Volcker rule, and these have what seem to be pretty severe requirements, but no-one knows what they are. Somebody has to decide whether to assume the proposed rule will be finalised and do a lot of work for something that may not be the ultimate solution, or to assume there’s no time to do anything and the regulators will give them more time.

Who would make that decision and how?
Ahart: In practice, it would probably be the executives that are sponsoring the project management organisation for regulatory reform. They are informed by the more junior personnel who are reading the regulations and the missives that come out of the regulator every day or two, trying to read the tea leaves and figure out what to do. You probably have an informed working group – we have working groups focused on the details of the regulations and trying to predict where they are going, what is going to happen, what we need to do and what we should wait for. And that has to escalate. We escalate through a committee structure and then we informally reach out to people who aren’t on the committee or missives meetings. They may then ask for periodic informal or non-fixed time briefings to senior management, whether it be the executive committee or the chief risk officer.

White: Fundamentally it should be done with advice from compliance and risk, but it should be the business-making decisions about how to interpret regulation and apply it. What I have seen in some cases is that you have risk and compliance running the integration on the project without recognising that decision-making power needs to rest with the business.

Kapoor: There are actually multiple stakeholders. Some banks work with the regulators to identify what really matters and what doesn’t. You also have external consultants and law firms – they have vantage point visibility from working with a number of banks or companies on the same issue at the same time.

You also have the legal and compliance group. Collaboration with them is critical. The business cannot ignore some of the insights and mandates coming from legal and compliance.

Banks and other financial institutions are finding that more difficultly modelled risks like reputational risk are becoming increasingly important. How do these risks tie into a GRC system?
White: Systems need to cope with changing hard facts and with reputational issues. We have seen products that were sold to customers that, even though they met the rules of the area in which they were sold, were deemed no longer acceptable by the public, press or the government. The goalposts have moved and you need to understand very quickly how you are going to respond, because you can guarantee your regulators will be on the phone the next day asking the same questions.

Ahart: I find myself dealing with the same issues – the conundrum I am constantly battling with is deciding what actual human resources we need. More and more, I look to hiring attorneys to do operational risk management because there is so much legal stuff going on out there. However, if you are hiring attorneys, there are other things with which they may not be as competent.

Kapoor: Reputational risk is a combination of things. It is about how you see the future and what could impact the reputation of the company. It has a lot to do with simple tactical and operational metrics. We are seeing a lot of unstructured information that needs to roll into operational metrics. Traditionally, it was all about structured data such as operational losses or financial losses, but today we are starting to find unstructured information flowing in as well. In a social world, information has more than one distribution route. It therefore increases the complexity of what is visible both inside and outside your organisation. A GRC system allows you to aggregate this gargantuan volume of information more easily into organisational processes, thus providing a consolidated view for the executive management.

Ahart: This highlights the need to tie in governance structure with the way you use your systems. If it is an emerging risk or a reputational risk, it won’t necessarily fit into the neat bucket that you have right now. You can make reports but they then have to feed up to a committee that can make decisions. People have figured out you can go about it that way with any emerging risk – it may not be regarded as significant in every area, and it may not get escalated the first time, but it is likely to be escalated if the theme starts to be repeated.

White: The other thing is you need a team supporting this kind of model that has the intellect and the skills to interpret data. It must understand that it is receiving information about risks that could actually bring the company down, and so doesn’t just aggregate it at a local level or aggregate other risks without understanding it. So it comes back to your personnel and how good they are.

Is a single risk scoring system necessary? Some lines will have specific models that vary from others.
Kapoor: It is absolutely not necessary to standardise the risk scoring across the enterprise. At some level, you still need to analyse the overall scores. So, as a best-case scenario, companies should try to create a single standard way of risk scoring. In certain groups, you might have a very qualitative approach, and in others you might have a fairly detailed quantitative approach with a number of factors. The parameters can be completely different as long as they are standardised and aggregated at the highest level so that there is a common taxonomy and understanding when you are assessing the risk exposure at the enterprise-wide level.

Ahart: There is no real solution to this issue because different areas have different ways of scoring risk. There are areas that have Sarbanes-Oxley risk, actual operational risk, long-tailed risks or more regular periodic risks. There has to be a mechanism for the operational risk management function to summarise it in a relatively clear and cohesive way, so you need to have a taxonomy to do that. But the fact is that it’s never going to fit perfectly because the risks that are inherent in one part of your organisation are fundamentally of a different nature from another.

White: An executive who is covering a lot of areas has to be able to say ‘if it’s a high risk in one business area, it’s equivalent to a high risk in another’. There has to be commonality in the definition of risk. My experience is that commonality of scoring, with variances for different business areas to take account of their unique risks, is absolutely essential.

Presumably the caveat is that you have to ensure the executives don't become too dependent on that single score – that they are aware of the limitation and the error bars around it as well.
White: It comes down to commonality of language and understanding stakeholder needs, rather than delivering what you think they need. What do they actually need to help them run the business and aid their decision-making? An essential part of a project like this one is sitting down with your executives and asking what type of information would enable them to make the right decision for the firm.

Kapoor: It depends largely on the size of the organisation. At times, when we are trying to get a risk definition harmonised in an organisation, we find different parts of the organisation are at different stages of maturity on the risk awareness level. For example, in a larger organisation, it is typically a little more challenging to harmonise people on a common language across the spectrum. In a mid-tier bank, it is easier because there are fewer stakeholders, which allows people to actually come together more easily and decide on issues like the taxonomy and information model.

Click here to view the article in PDF format.

Sponsored content