So, here we go, first question. What is Risk? Risk can be defined as the uncertainty that might trigger loss or adverse fluctuations in profitability. Risk comes in different categories including: credit, market, operational and liquidity.

A foreign exchange deal, for example is a form of market risk. Let’s say I own a company Cheapest Gems Ltd. which buys Gems from Sri Lanka. I buy gems in Sri Lankan rupee (LKR) and although I have enough stock, I know that I will be buying stock in 3 months time. Given that I am unsure on the stability of the country and its currency I decide to enter into a Forward Foreign Exchange (FX) deal with a bank, called Java Bank.

The rate today for GBP to LKR is 182.371 to the pound (£). I would like to buy £1000 worth of Sri Lankan rupees. The bank agrees to enter into this forward foreign exchange deal thereby agreeing to sell the amount in Sri Lankan rupees in 3 months time. The bank agrees at a rate of LKR 184 to the pound (£) to factor the risk. This is the cost (1.629/182.371 = 0.89%) Cheap Gems Ltd. will pay for risk protection. At this point the bank has an FX exposure as it has committed to selling the currency to the client.

• LRK weakens implies that the bank will lose on this transaction
• LRK strengthens implies that the bank will gain on this transaction

Banks have to take risks, in fact the basic model of a bank is based on risk. The simplest form of banking can be defined as accepting deposits and issue loans to derive a profit from the difference in the interest rates paid and charged, respectively. So banks take risks by lending money to people, which might default in the long run, but in turn make a profit for the risk imposed upon them.

The key is to manage risk effectively. Poor managed risk can result into financial losses thereby endangering the safety of a bank.  This has a direct affect not only on the bank itself, but also on the country in which the banks operate or even the global financial system. We all know a perfect example of this, right? Yeah you got it, the collapse of Lehman Brothers in 2008.

As mentioned earlier the banks profit is based on their risk taking and hence rather then eliminating risk they need to manage it! In fact when you think about it, banks are very similar to insurance companies, i.e. they take calculated risks to make a return from them.

So the next question that comes to mind is, how do we manage risk? A bank has a number of options that it can use to manage risk, it can:

• Avoid Risk: In certain cases a bank can decide to avoid the risk altogether. A good example would be when a bank refuses to grant a loan to a customer that, most likely, will not be able to repay the loan. It is important to note that avoiding risk also means loosing out on profits.
• Mitigate Risk: Mitigation involves taking actions to minimize the risk. A good example of this is pledging collateral to offset exposure on credit risk.
• Transfer Risk: Banks can also decide transfer risk to a third party by using insurance companies, syndicates (in case of loans) or by hedging, i.e. by taking offsetting positions in derivatives (futures, options, swaps, etc) to eliminate some of the variables that create risk.
• Accept Risk: In many cases the risk level is acceptable for the bank and hence no action is required. Banks normally define what is acceptable via thresholds. For example the LTV (Loan-To-Value) thresholds are normally defined for loans. If the LTV ratio is above 97% then the loan is accepted.

So back to the types of risk! You might notice that in the above examples there are many references to credit risk examples. Although this is the type of risk I am mostly familiar with, and possibly the most important risk of all, there are others as mentioned in the beginning of this Blog.

• Credit Risk can be defined as ‘the possibility that a party will fail to meet its obligations in accordance with agreed terms’. It is generally regarded as the most significant risk faced by banks and the one against which they hold the most regulatory capital. For this reason, it is also the risk to which financial regulators pay the closest attention.
• Market Risk can be defined as the risk of movements in the market prices and the affect that they have on the bank’s balance sheet. Movements of exchange rates, interest rates, commodity prices, stock indexes, etc.
• Operational Risk the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events. This includes legal risk. Some examples include fraud, workplace safety, damage to physical assets, business disruptions, systems failure, etc.
• Liquidity Risk is the risk that a given security or asset cannot be traded quickly enough in the market to prevent a loss (or make the required profit).

At this point I think that we have the basic knowledge to learn about the components of an effective risk management framework. Risk management in banking is about maximizing risk return trade-off. The framework should extend to to all risk types discussed above and should incorporate tools to 1) identify; 2) measure & assess; 3) monitor; 4) control & mitigate.

So what are the components of an effective risk management framework? Risk management in banking is about maximizing risk return trade-off. Risk culture should be embedded within the heart of the banks values. This can only happen if a sound risk aware culture is pushed down the company hierarchy from senior level management.

The framework should ideally extend to all risk types discussed above and should incorporate tools, processes and techniques to undertake the following:

1) Risk Identification: This is the first step of the process where the risk analysts try to identify the main risks involved and how these risks could affect the bank. Risks are events that, when triggered, cause problems. Effective risk management should consider both internal (based on the nature of the bank’s activities) and external risk factors (such as changes in the industry, unforeseen events and advances in technology). This is where the risks are classified into the different types, i.e. credit, market, operational and liquidity. Some risk types can be easier to identify than others, example Credit Risk.

2) Risk Measurement & Assessment: Next step is to identify the vulnerability on these risks. Risk can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure, example the probability of an unlikely event occurring. Therefore, in the assessment process it is critical to make the best educated guesses possible. This will allow for prioritization and hence for effective implementation of the risk management plan.

3) Risk Monitoring: This step should never be underestimated as some of the worst financial disasters occurred because of poor implementation of risk monitoring processes. Once again the approach to risk monitoring differs for the different types of risk but it is normally implemented by setting thresholds on the banks system which trigger notifications to senior management if the risk measure exceeds the predefined threshold. For example, in case of liquidity risks the banks limits in place to ensure for adequate liquidity. Such limits would normally be set or reviewed by external regulatory bodies such as the FSA. The frequency of monitoring should reflect the frequency and nature of changes of the risks involved. For example, in the case of active trading portfolios, banks need to monitor the market risk on a daily basis. Monitoring, therefore, should be an integrated part of a bank’s activities.

4) Risk Control & Mitigation: Ok, so we have a great risk management system implemented using the latest technologies. It can measure, asses and monitor risk arising from different transactions occurring across the bank. So what happens when the system (or framework) identifies that the bank has exceeded the threshold for risk in a particular are?

• Do Nothing: There are many cases where the risk is acceptable to the bank. Given that banks are there to take risks, some risks identified by the risk management framework could be deemed as acceptable. Different thresholds can be set to notify risk in a particular manner. For example a risky transaction could be blocked a certain threshold is exceeded. On the other hand if the transaction is not so risky then a warning could be triggered indicating that there is a risk which is acceptable. Take a loan for example if the loan is deemed to be risky the bank might accept the loan anyway but decide to increase the interest rate to counterbalance the risk. Note that in this case there was no reaction as the risk is still the same, i.e. the bank has simply increased the profit made because of the increased risk for the transaction.
• React: If risks are considered to be un-acceptable then it may be possible to change something in order to reduce or eliminate the risks. For example the bank might decide to reduce the loan approval rate by increasing its LTV (loan-to-value) ratio if it has identified a number of problems on its loan portfolio. Another example for a single transaction would be securitization in case of loans which are not approved.
• Hedge: Hedging can be defined as taking an action such that an opposite position is created to the risk position being held. This is in an attempt to offset exposure to price fluctuations in some opposite position in another market with the goal of minimizing one’s exposure to unwanted risk. Derivatives are normally use as a hedging tool by most banks.

This is it for this Blog. I hoped you have found it interesting I am sure that there will be more topics to follow related to the area of risk management. This article will serve as starting point to more technical discussions related to risk management computer systems. On a final note I would like to conclude with a phrase by Hector Sants, CEO of the Financial Services Authority (FSA), ‘Never take risks you don’t understand’.

Well, for starters adapting to change is always problematic. We have invested significantly in learning why traditional methodologies have to be used in medium to large scale software development. I recall many different flavors of software engineering courses I did throughout my years at university. Lets face it it’s quite de-motivating  when you realise that principles we are all accustomed to as Engineers are fading away. Luckily I never was 100% convinced about these methodologies in the first place, maybe because they seemed too rigid, so this should make it easier for me to embrace these new methods.

I understand that large companies have invested heavily in developing their own adaptation of one of the many traditional SDLC methodologies available. I guess the key point I guess is lessons learnt and that is what we need to hold on to. Why were we forced to invest so much research in this so called ‘Science’ of software engineering? I think the bottom line is that changes to requirements are very costly and they can be a nightmare to a software company. However requirements are bound to change in most business areas and hence we need to learn how to adapt to change rather then ‘dreaming’ that we will get the requirements right the first time round.

Project managers seem to feel uncertain if they do not have the basis on which to commit to a delivery date and this obviously stands to reason as they are pressure by higher level management and clients to commit to dates. They seem to think that the methodology does not involve planning and accurate estimates which is wrong. One drawback which I do see is that the methodology seems to be more oriented towards co-located teams. This seems to be a disadvantage when it comes to large multinationals which have projects spanning continents. Ideally we should have smaller projects running in a single location however the reality is that in large companies, the domain and/or technical knowledge could be spread.

So what about the techies? My perception is that technologists like the idea of Agile. It seems to put them ‘back to basics’ where they spend time doing what they like rather than writing lengthy documentation to describe something which doesn’t even exist and that is more likely to change. Most developers (including myself) find it un-motivating if they are not creating working artifacts and prefer hands on development. There are obviously exceptions when thought and minimal design has to be done prior to coding however in many cases the solution to a problem can be trivial and a developer’s preferred method of expression would be the actual implementation.

It is important to remember that Agile does not say that we should never produce documentation. It rather says that only useable and valuable documentation should be produced.   Some other myths about Agile include that is does not allow you plan upfront and lack of engineering principle.

Personally I believe that this is the most natural way of building software. Customer collaboration, i.e. feedback from the end client is always essential in ensuring the success story of any delivery. Agile development is also a culture which fits best individuals which are motivated team players. It promotes individuals and interactions rather then processes and tools.

On a final note I have to say that this Blog was slightly negative it terms of highlighting the lack of popularity for Agile methodologies. The reality is that increasingly it is becoming a de-facto standard for many small to medium organizations. I think the problem lies in the larger organizations which tend to be more bureaucratic and reluctant to change their mindset on adopting newer methodologies and technologies.