A simplified RCSA case study that showcases how the RCSA process works.
A bank engages us to conduct a risk control self-assessment exercise for its front office treasury group. We follow the RCSA process presented below.
RCSA case study – Audience selection for issues identification
Our first step is an offline informal survey of treasury group participants to get a sense of common challenges and issues. Our discussions are on a one on one basis with each team with a clear mandate for identifying current and potential operational issues. The audience we select for our discussions includes members of the following teams:
- Treasury Front office
- Treasury Back office
- Middle office Treasury
- Technology group
- Internal Audit
- Financial Control
- Regulatory Reporting
- Compliance
The core group includes only the first three. However, the additional five groups regularly interact with the treasury team. Which provides a better perspective of interfacing and delivery challenges as internal outsiders.
RCSA example – List of initial challenges.
In our initial discussion with the group identifies a number of operational challenges. We share a small sample of these challenges below:
- Delayed day end processing. At least once a week day end processing for the treasury system experiences delays beyond normal office hours. Consequently, requiring the back office staff to stay behind and close the books. A delayed day end has a follow on effect on the core banking system day end processing because the core banking platform waits for the day end results from the treasury platform before beginning its own processing. To date the group has always been able to complete its day end processing before the 10:30 pm cutoff. However, there have been a few close calls.
- Most common causes of delayed day end processing is either late post market close deal or counterparty trade limit exception.
- A late post market trade is sometimes required when there is an issue with regulatory reserves treasury is responsible for. A shortfall in that reserve requires a covering trade from the market. We generally find out about the shortfall just before day end processing begins but after the entry of all trades for the day in the system. The final reserve requirement cannot be determined till all treasury trades have been entered, approved, committed and settled.
- The same holds true for counterparty limit checks. While traders do an initial counterparty limit check before posting a trade, the actual final limit verification happens as part of the treasury day end process. This happens because the counterparty trade limit management system is external to the treasury platform.
- Treasury day end processing begins generally 30 – 50 minutes after close of markets at 4 pm. The delay happens because while traders maintain an Excel based blotter for their day long activity, tickets and trades are only generated at day end after client facing activities are finished. While the bank only has three traders on the front desk, the trade entry and approval process takes anywhere between 30 – 60 minutes to complete.
- Network and protocol failures. Because of network load on account of day end processing in a number of subsystems, there have been a few instances where system handshakes between subsystems have failed in the past leading to unanticipated delays in the start of the core banking day end processing. Sometimes the failures have occurred at the treasury system end. At other times the failure occurs in the middleware layer connecting the two platforms. All the failures in the past have been addressed quickly by vendor intervention through a support call.
RCSA Example – Identify risks.
Our risk identification exercise yields a number of challenges and associated business risks.
The primary challenge is the risk of delay in day end processing. That risk is linked directly to a number of business related consequences. From central bank non compliance penalty to loss of market good will and damage to customer relationships.
RCSA Case Study – Risks – Next steps.
We now try and link our key risk factors to the appropriate key risk indicators. The objective is to see that if we can identify leading (detective) indicators of risk, which we can possibly use to control the occurrence of the event in question (through the control process). We also need an indicator that we can use to gauge the success of our control process.
We do this for a few of the risk identified above. Some items lead to simplified straight forward Key Risk Indicators. Others require discussion and tweaks with the selected audience as part of the formal RCSA discussion.
RCSA Case Study – Using the Self-Assessment survey.
We create a short self-assessment survey for each of the risk identified above.
For instance for this RSCA case study let’s take Delayed Treasury Day End Processing as a risk. The leading Key Risk Indicator (KRI) for detecting the level of this risk is the percentage of deals awaiting entry, verification, confirmation and settlement. One relevant control measure suggested to track the risk throughout the day is to limit the KRI level to less than 10% by monitoring the measure every hour. This requires a process change. The process change is the control measure.
Rather than wait till day end for deal ticket entry, the bank requires dealers to post all recorded outstanding deals during the hour, before the close of that hour. This ensures that all deals have been entered just before or immediately after market close.
RCSA – The Control Measure and its assessment.
The lagging control measure that determines if our designed leading controls are working is the elapsed time between market close and start of treasury day end processing.
By assigning an individual or team to monitor both KRI and control measures, we can assess if the control function designed by us is working effectively in curtailing the associated risk.
Our original risk control self-assessment survey would query if the risk of delayed treasury day end processing is within acceptable limits and our internal risk appetite. The right answer to that question at inception would be no. Rather than limiting ourselves to just yes and no, we can also grade our answers on our own internal assessment of how high or low this risk is.
During our formal RCSA exercise, we present the discussed approach. If the approach is acceptable, assign two separate controls functions to two separate individuals. Assign an internal treasury control to monitor compliance with the “10% outstanding deals waiting to be entered” KRI. Do this every hour on the hour and non compliance or a breach of the KRI should lead to an immediate correction by the concerned dealer. This enforcement can only happen with the full support and buy in of the treasury head. Without this support from the business, the control measure will only be able to monitor but will not be able to correct errant behavior.
The bank assigns an external treasury control to monitor compliance with the elapsed time from market closure to treasury day end start. This control is also responsible for reporting the results of both control functions to the risk and monitoring group.
Review frequency
Agree on a review frequency to see if the two control functions work and if it reduces the risk threshold for delayed treasury day end processing. The initial review frequency is set for 30 days, when the RCSA questionnaire and survey is circulated to see if any improvements have occurred. If the control processes are successful, the grading should change. If the control processes are unsuccessful, take a decision to investigate the causes for failure, wait for another cycle or redesign the control process.
References:
1. Risk Control Self Assessment – Institute of Operational Risk.
2. Key Risk Indicators and Even Loss – A simplified Example.