Risk management decisions are more and more based on very complex software applications which have to be properly installed, configured and integrated into the financial institution IT platform. For sure you need people specialized in the financial products which risks you need to asset, they have to be people with strong financial and econometrics skills but never forget someone from the computer science engineering which will help your team in all tasks related to technical issues their decisions and analysis are based on.
The people in key risk management and control positions, should have a proper and clear definition of their roles and responsibilities supported by appropriate empowerment that would help them to faithfully carry out their roles and responsibilities to provide assurance to the Board, senior management, regulators and external stakeholders. If risk management responsibilities are distributed, the key personnel needs to know his/her risk management accountabilities and responsibilities.
it really depends what types of risk management department you will be responsible for. many of the market or investment risk teams use sophisticated models to analyse the risk in different financial assets – here clearly you need people that can efficiently instal and run this type of analysis, although the bit that I find can sometimes be overlooked is then making sure that this information is embedded (or fed back) into future decisions that are made – i.e. Risk teams should be “Managing the Risk” (not just measuring it).
A key area is of course to start the data and flow of such. Wrapped around this is the IT framework.
The database and IT to an extent need to be clients of the Risk Department and be proactive and responsive. There needs to be a strong and formal relationship. Someone in the risk department who has coding skills is always useful.
The choice of Risk Application is vital, internal build (a major decision with some failure risk) or to go for a third party Risk Application. The best risk application in theory is not always the most suitable; it depends on the company, what are the current and to be asset classes, products, reporting needs and so on.
Also to keep in mind how the risk numbers will interact with the performance numbers, especially when you move to decomposition and attribution. Reporting of risk is critical at the various levels throughout the company. A full library of documents, procedures, testing is very important not least from an Audit perspective . The head of risk needs to be credible and be have a good client facing approach
I see the department as having to main themes, Risk Control, respecting limits that are set by BoD, prospectus, internal etc and Risk Integration throughout the company especially within Investments if appropriate so risk can actually serve to add value and increase the alpha
The risk measures used are important. No one risk measure is perfect rather it’s a balance between having good transparency of the risk without having too many measures.
The path to take is first to measure the risk, then to monitor, Reporting of risk, attribution of the risk and finally to budget the risk.
I agree the Risk department needs to be independent and must ensure that BoD reporting is accurate and clear to the Board exactly what they are signing off on
Think about deciding what Risk function should consist of:
1) Different sub verticals – Financial Risk, Operational Risk, Business Continuity, Information Risk, Regulatory Risk (Compliance), Credit/Market Risk (if applicable), Internal Audit can be separate or part of a larger Risk function
2) Establish roles and responsibilities, accountability for each of these sub verticals
3) Decide on key risk policies for example – Information Security policy, Business Continuity policy and other sub policies
4) Chief Risk Officer as a few of them have already pointed above
5) Establishing a small team of specialists for liaising with regulators – this should be a part of Compliance vertical
These are some of the key points to be taken care of, however there are so many other things that one has to take care of when setting up a Risk function like management buy in and cost structure within the organisation.
To create a department Risk so I see the following structure:
– Sub department financial operation Risk
– Sub department opportunities
– Sub department previsions Risk
– Sub department IT Risk
– (N) agents
– Choose systems/equipments for each kind of risk .
Risk Assurance – Role is to provide specialist assurance over specific risks on an ‘ad hoc’ basis – e.g. linked to new product roles, big financial transactions etc.
ii) Risk Oversight – Ongoing monitoring of the BAU management processes.
iii) Risk Management – The function responsible for implementing any key recommendations arising from the Risk Monitoring, e.g. if the CRO decides it is necessary to hedge a particular risk and the First Line of defence does not have the capability to achieve this.
There are numerous functions within most financial instiutions which provide ‘assurance’ in one way or another. These might include Risk, Compliance, Internal Audit, External Audit, etc.
Ideally, each key risk area in the company should be ‘owned’ by a single assurance function, otherwise there is the risk of placing too much ‘assurance burden’ on the business / duplicating work / focusing on the wrong things due to a lack of a joined up approach. Create an assurance map to help this process.
Clear policies should be set so that members of the function know the expectation in terms of the responsibilities, documentation, sign off and escalation processes etc. Adherence to these policies should be subjected to a robust third party review process on a regular basis.
Don’t rely on management information for ongoing monitoring purposes, as this may lead to the Risk team having the same bias as management. Instead build independent MI gathering processes for the Risk function, to increase the robustness of the challenge provided.
There is a tendency in some organisations to blame the Risk Function when things go wrong. This can lead to the Risk Director / Risk Function being used as a ‘fall guy’ while other more fundamental problems in the First Line of defence fail to be addressed. I am not sure how to address this one, but the Function Holder needs to be aware of the potential problem.