Butterfly
Risk appetite in practice.
When a limit is crossed, who acts?
A system I proposed and built to connect source data, written risk requirements and the reporting that follows a breach.
Explore the walkthroughRisk metrics were entered manually into Google Sheets. I noticed that updates arrived late and sometimes contained data-entry errors, which made the shared view harder to rely on.
As a risk owner, I proposed Butterfly and built it myself. I interviewed developers and other risk owners to trace how they sourced and calculated the numbers, designed the tables and aggregation logic, and helped other teams prepare source tables where needed.
- Inputs and aggregation
- Source dataTraced the data and built the tables and calculations
- Measurable requirements
- Policy to limitsTurned written requirements into monitoring rules
- Board breach reporting
- Within a dayWith a remediation plan
My contribution / Proposed and built by me
My role in the data and the decisions.
01
Identify the problem
Spotted delayed updates and manual-entry errors in the existing Google Sheets process, then proposed a system that could consume the source data.
02
Trace and prepare the data
Interviewed developers and risk owners about their inputs and calculations. Designed the data tables and aggregation logic, and helped teams make source tables available.
03
Make policy measurable
Translated written risk requirements into metric definitions, warning thresholds and breach limits, then implemented the monitoring logic.
04
Build and share the system
Worked as the sole builder. Started with Risk Control, then demonstrated Butterfly to the Board and shared it with broader stakeholders.
Visibility and accountability
Risk Control was the initial audience. We later demonstrated the system to the Board and shared it with other stakeholders to make risk exposure more visible.
A breach of the applicable limit requires reporting to the Board within a day, together with a remediation plan. The interactive example below illustrates that reporting window.
01 / The approach
How the source data becomes a risk decision.
The risk documents described requirements in paragraphs. I translated them into metric definitions, warning thresholds and breach limits that the system could measure and monitor.
- 01
Consume the source
Trace the inputs and aggregate the metrics from source tables.
- 02
Apply the requirements
Compare the metrics with the applicable warning thresholds and breach limits.
- 03
Report a breach
Report to the Board within a day, with a remediation plan.
- 04
Follow through
Track continuing breaches and the actions they require.
02 / Explore in practice
Explore the risk appetite system.
Select a risk domain. Inspect its trend, the limit restatement and the escalation protocol where a breach occurs.
The workflow reflects the system I built. Metrics, scenarios and supporting examples in this walkthrough are illustrative and contain no employer source data.
EW is the early-warning line and BL is the breach line. Both are set by the Board and change when they restate appetite — alerts follow the live limit, not last year's. The same rails work for a component or supplier threshold: cross the line, notify the owner, attach the action. Illustrative metrics · not employer internal data.
Capital Risk
Own-funds utilization against the current Board-approved RAS. After the Dec Board, EW/BL were tightened from January — alerts fire on the restated limits, not last year’s.
Board limit update. Year-end RAS restated. Capital EW 75%→70% and BL 90%→85% from January. April 86% is a breach against the new limit — it would have sat inside the prior-year BL.
Board protocol · report within a day
BL crossed in Apr — Board notified
In this illustrative case, Capital Risk crossed the applicable Breach Limit (85%, in force from Jan). The Board notice and remediation plan were filed within a day of observing the breach. The pack uses the current limit.
- First seen
- 3 Apr, 18:12 CET
- Board pack
- Notice + mitigation plan
Illustrative Board reporting timeline
Hour 0 / 24
Hour 0 — Breach detected
A breach of the applicable limit is observed. The illustrative reporting window is 24 hours.
Mitigation plan filed with the Board
- 1Pause incremental origination in elevated-PD and high-utilisation cohorts.
- 2Lift the capital buffer and tilt away from RWA-intensive products until utilization is back under the restated EW (70%).
- 3Stand up a weekly Risk Committee readout; keep the Board pack open until two consecutive periods sit under the current EW.
Continuous breach · trend follow-up
Over BL for 3 consecutive periods
Apr 86% → May 88% → Jun 87% vs restated BL 85%
Still over the Jan BL. May deteriorated; June recovered one point — not enough to close. Stay on trend monitoring and Board follow-up against the current RAS.