🎯 Project Aim
The BCBS–IOSCO framework for Regulatory Initial Margin (IM) was introduced to mitigate systemic risk in the global derivatives market following the 2008 financial crisis.
It requires financial institutions and systemically important non-financial entities that engage in uncleared OTC derivatives to bilaterally exchange IM with counterparties.
With the new Initial Margin requirements coming into place, a project was requested to implement a Counterparty Credit Risk monitoring framework specifically for counterparties that have Regulatory Initial Margin requirements, that would allow Credit Officers to view Net Exposures (with IM incorporated), the maximum potential collateral required, the cost of liquidating positions and collateral, a breakdown of sensitivities in addition to the Counterparty VaR, and the P&L impact of eight selected Stress Testing Scenarios on the counterparty portfolio, incorporating the offset from the Regulatory IM.
It requires financial institutions and systemically important non-financial entities that engage in uncleared OTC derivatives to bilaterally exchange IM with counterparties.
With the new Initial Margin requirements coming into place, a project was requested to implement a Counterparty Credit Risk monitoring framework specifically for counterparties that have Regulatory Initial Margin requirements, that would allow Credit Officers to view Net Exposures (with IM incorporated), the maximum potential collateral required, the cost of liquidating positions and collateral, a breakdown of sensitivities in addition to the Counterparty VaR, and the P&L impact of eight selected Stress Testing Scenarios on the counterparty portfolio, incorporating the offset from the Regulatory IM.
👥 Stakeholders
Credit Risk, Credit Risk Reporting
❗Why It’s Important
Before the Regulatory Initial Margin was a requirement, counterparties trading OTC derivatives were calculating Gross PFE, without the benefit of the Reg IM.
The exposures generated for each counterparty were done on a “Risk Site” basis, which means the PFE for Equity, was different from the PFE for Rates.
Implementing a Counterparty Credit Risk framework enabled a summation of the various exposure profiles, then offset by the Regulatory Initial Margin.
By also bringing in various additional attributes, Risk Managers could use the SPIDER module as a “one-stop shop” for all required monitoring for their counterparties.
The exposures generated for each counterparty were done on a “Risk Site” basis, which means the PFE for Equity, was different from the PFE for Rates.
Implementing a Counterparty Credit Risk framework enabled a summation of the various exposure profiles, then offset by the Regulatory Initial Margin.
By also bringing in various additional attributes, Risk Managers could use the SPIDER module as a “one-stop shop” for all required monitoring for their counterparties.
✅ Benefits
Automating these dashboards eliminates the need for manual filtering, SQL queries, or multiple static reports.
Users are able to gain real-time access to updated metrics such as VaR, sensitivities, exposures, stress test results, and limit usage.
Ability to see the Cross-asset Net Exposure (albeit additive, without cross-asset diverisification), inclusive of Regulatory Initial Margin.
Risk teams, desk heads, and senior managers have access to all relevant metrics for counterparties that is both interactive and aligned with the firm’s risk governance framework.
Users are able to gain real-time access to updated metrics such as VaR, sensitivities, exposures, stress test results, and limit usage.
Ability to see the Cross-asset Net Exposure (albeit additive, without cross-asset diverisification), inclusive of Regulatory Initial Margin.
Risk teams, desk heads, and senior managers have access to all relevant metrics for counterparties that is both interactive and aligned with the firm’s risk governance framework.
🛠️ Tools Used
SQL | JIRA | Excel
🧩 My Role
Lead Business Analyst:
- Ongoing collaboration with Credit Risk Management, and Reporting teams, to understand the requirements for implementation
- Creation of Business Requirements, where approved requirements are then documented functionally in JIRA ready for IT implementation
- Perform QA checks on each development step, to check that delivery passes the defined Acceptance Criteria
- Presentation of delivered output, with explanations, to Credit Risk, and Reporting, for approvals, ahead of release
- Documentation of the process for Production Support to inherit the process for ongoing BAU