A Risk Register Is Not a List. It’s a Budget.
A risk register built on three-role ownership and money against every risk.
Three People Pointing at the Same Risk
The risk workshop had been scheduled for 21 April, three days away. Priya Raman dropped by the PMO room on 18 April with a question that changed what that workshop needed to cover.
The program manager called Volkov and Okonkwo into the room for fifteen minutes that afternoon. The conversation was not hostile. It was three people watching a risk they could each see, each pointing at a different person to own it.
Volkov (Platform Integrator). “This is an operator problem. My integration scope is Atlas Bank to mobile network boundary. What happens inside the operator is outside my contract.”
Okonkwo (Compliance). “The central bank directive makes Atlas Bank accountable for customer experience across every channel the bank offers. If USSD fails because an operator’s SMSC is down, the compliance position is that we should have had a fallback. This is a regulatory exposure, not an operational one.”
Raman (Technical Lead). “I can instrument it and alert on degradation. I cannot fix it. The response has to involve commercial pressure on the operators, compensation to affected customers, or both. Those are not technical levers.”
Three legitimate positions. Three correct answers to a question about a different aspect of the same risk. No single one of them added up to ownership.
The program manager recognised the pattern. On a single-domain risk, one owner is right. On a cross-function risk where consequence, technical response, and business impact sit in three different places, one owner is a fiction that fails at the first incident. The register needed a different ownership model for this class of risk.
Three-Role Ownership. Money Against Every Risk.
Two design choices shaped the Risk Register for the rest of the program. Both emerged from the 18 April workshop preparation, not from a framework the PM brought in from outside.
Owner. The function whose mandate carries the ultimate consequence if the risk materialises. For R06 (SMSC dependency), the owner is Okonkwo, because regulatory consequence is hers.
Mitigation Lead. The function that executes the technical response. For R06, Volkov, because monitoring, alerting, and operator liaison sit in his integrator team.
Business Contact. The function that carries the customer-facing impact. For R06, Osei (Head of Retail), because customer experience is his P&L consequence.
Every risk on the register carries at minimum an owner. Risks tagged as cross-function carry all three roles. Same-function risks carry only an owner, and the other two fields say “owner also”.
The program's $2.13M contingency was already mortgaged against known risks in principle (noted in the Business Case, Post 01). Making the allocation explicit meant putting a dollar figure against each risk in the register, summing to a total allocated number with a named unallocated reserve. After the workshop, $1.60M was allocated across eleven named risks, leaving $530K as unallocated reserve for risks not yet identified.
The discipline this enforces is that risk response costs money whether the risk materialises or not. Preventive work (monitoring, fallback designs, insurance) consumes contingency. Response work, if the risk fires, consumes the allocation or signals that the allocation was wrong. Either way, the register becomes a financial instrument, not just a list.
The R04 National ID SLA risk, placed on the roadmap (Post 05) as a placeholder, got its first detailed design at the same workshop. Volkov's initial proposal was a fully asynchronous KYC pipeline: account opening would create a provisional record, the national ID verification would happen in the background, the account would activate when verification completed. Clean, decoupled, reduced dependency on peak-time SLA.
Okonkwo rejected it in forty seconds.
The central bank directive requires real-time identity verification at account opening. Async is permitted for subsequent authentication events (session re-verification, elevated transaction authorization) but not for the initial account creation. Volkov’s design would have been technically clean and regulatorily illegal. Okonkwo’s veto on regulatory certification (Post 04) meant this was not a design the program could ship.
The redesign landed as async-with-real-time-failover: a 15-minute pending-verification queue with real-time fallback via a backup integration path if the queue exceeded threshold. Accounts in the pending queue remained in provisional state with Tier-1 transaction limits (small daily cap, specific merchant category blocks) until full verification resolved. The design was more complex than pure async, more expensive to operate, and compliant.
Both decisions (three-role ownership for cross-function risks, contingency as a first-class field) went into the Risk Register template. The workshop on 21 April produced the first populated version.
Identifying Risks the PM Might Miss
The prompt below uses TREF: Topic, Role, Examples, Format. The Examples dimension is what makes TREF suited to risk identification. Risk registers fail not on the risks the PM thought of, but on the risks the PM did not. Feeding the AI representative risk categories from comparable programs (regulated fintech, multi-market platforms, legacy core integrations) gives it enough prior to surface common patterns the PM might not have seen. Framework complexity matching task complexity: risk identification needs priors more than it needs structure, so Examples earns its place.
Draft Risk List, Extract
The AI output produced thirteen risks. Seven are shown below to cover the span of the register. Three flagged items are shown in full, including the one the PM escalated from Medium to High after the workshop.
| ID | Risk | Likelihood | Impact | Owner | Cross-fn? |
|---|---|---|---|---|---|
| R01 | Central bank regulatory requirements change mid-build | High | High | Compliance | No |
| R02 | Prime vendor under-delivers at milestone | Medium | High | PM | Yes |
| R04 | National ID SLA degrades at peak | Medium | High | Compliance | Yes |
| R06 | SMSC operator dependency, USSD availability | High | Medium | Operations | Yes |
| R07 | Legacy core query performance under load | Medium | High | CTO | Yes |
| R09 | Third-party audit findings late in UAT | Medium | Medium | Compliance | No |
| R10 | FX exposure on USD vendor contracts | Low | Medium | CFO | No |
R06 impact scoring. Scored Medium based on availability-impact logic (USSD outage affects feature-phone users only). However, if central bank views customer experience holistically across channels, impact could be High because regulatory consequences follow any material customer-facing outage regardless of channel. Recommend PM review with Compliance before finalising.
R04 response strategy. No fallback design specified in the source inputs. Pure async KYC is the obvious technical fallback but may not be regulatorily permissible at account-opening stage. Recommend verifying with Compliance before documenting response.
Possibly missing. The current list does not include a risk for cross-border data residency if the program’s failover architecture routes traffic across market boundaries. If the program has any cross-market DR or failover path, this is a risk category not covered by the thirteen risks above.
Risk Register v1.0, Extract
Extract of the published Risk Register v1.0, 23 April 2025. Six risks shown from a register of eleven. The summary bar at top shows contingency allocation across the full register.
| ID | Risk | Exposure | Roles | Response Strategy | Contingency |
|---|---|---|---|---|---|
| R01 |
Regulatory requirements change mid-build
Central bank directive on digital financial inclusion still evolving; implementation rules Q2 2025.
|
High |
Owner Okonkwo Single-function
|
Continuous engagement via monthly compliance working group; 48hr monitoring of regulator publications; escalate any material change to steering within 5 business days. | $280,000 |
| R04 |
National ID SLA degrades at peak
Published SLA 4s p95; comparable programs observe 6–8s at peak. Real-time KYC required for account open.
|
High |
Owner Okonkwo Mitigation Volkov Business Osei |
Async-with-real-time-failover. 15-min pending-verification queue; real-time fallback via backup integration path if queue threshold exceeded. Provisional accounts retain Tier-1 transaction limits until full KYC resolves. Design doc R04-D1. | $220,000 |
| R06 |
SMSC operator dependency, USSD availability
Three mobile operators, no SLAs at platform volumes. Central bank views customer experience holistically.
|
High |
Owner Okonkwo Mitigation Volkov Business Osei |
Instrument all three SMSC paths; alert on degradation at 2-min threshold. Quarterly operator-level SLA negotiation; customer compensation framework pre-approved by Retail; incident comms ready-to-dispatch. | $120,000 |
| R07 |
Legacy core query performance under load
Core never queried at platform volumes. Profiling (Post 05) baselined; load behaviour still emerging.
|
Medium |
Owner Alemu Mitigation Raman Business Owner also |
Progressive load testing in Phase 2; caching layer design if query latency exceeds baseline +20% under load; standby core capacity sized in Scale Plan. | $340,000 |
| R08 |
Vendor under-delivers at milestone
$5.68M integrator contract; milestone-based. Critical-path exposure across M3a, M3b, M3x; penalty clause in contract rarely recovers actual cost.
|
Medium |
Owner PM
Single-function
|
Milestone pre-reviews at T-10 working days; penalty clause enforcement; re-baselining via Change Control (not charter amendment). Allocation covers re-baselining and schedule buffer, not penalty income. | $400,000 |
| R10 |
FX exposure on USD vendor contracts
Integrator and audit firm paid in USD; program P&L in local currency. Three-market bloc includes two currencies with historical 8–12% annual volatility.
|
Low |
Owner CFO
Single-function
|
Forward hedging on USD liabilities above $500K committed value; quarterly FX review with Treasury; re-pricing trigger at ±15% currency movement against baseline. | $0 (hedged) |
| R11 |
Cross-border data residency breach via failover
Added post-AI review. Any DR or failover path across market boundaries breaches local PII rules.
|
High |
Owner Okonkwo Mitigation Alemu Business Benali |
In-market DR only; no cross-border failover paths for customer PII. Architecture review at Scale Plan sign-off to confirm. Data protection impact assessment per market before production. | $240,000 |
- Introduced three-role ownership for cross-function risks. AI produced single owners. PM separated Owner (consequence), Mitigation Lead (technical response), and Business Contact (customer impact) for R04, R06, R07, R11. Single-function risks kept single owners.
- Added contingency allocation against every risk. AI produced exposure scoring but no dollar figures. PM added a contingency field to the template and assigned allocations summing to $1.60M against eleven risks, leaving $530K unallocated reserve. The Risk Register became a financial instrument, not just an inventory.
- Elevated R06 from Medium to High impact, and reassigned ownership from Operations to Compliance. AI flagged the impact score as a review item and initially assigned Operations as owner. Both were corrected after Okonkwo’s regulatory-consequence argument: the central bank takes a holistic customer-experience view, so a USSD outage is a compliance exposure regardless of which function fields the incident. High impact, Okonkwo as Owner, Volkov as Mitigation Lead, Osei as Business Contact.
- Added R11, cross-border data residency via failover path. AI’s flagged potentially-missing item was correct. Raman surfaced the same concern in review: the Hazelcast distributed grid and any DR architecture must stay in-market. New risk, High exposure, $240K allocation.
- Rejected Volkov’s pure async KYC design for R04. Technical elegance does not override regulatory reality. Redesigned as async-with-real-time-failover. Design doc R04-D1 referenced in the register.
Mobile Operator B had a regional SMSC outage that lasted 94 minutes on 14 December 2025, between 18:00 and 19:34 local time. Falcon’s USSD channel for customers on Operator B was unavailable during the window. Because R06 had three-role ownership pre-wired, the response ran on established pathways rather than ad-hoc escalation. Volkov’s monitoring triggered within two minutes; Okonkwo notified the central bank within thirty minutes as the directive required; Osei dispatched pre-approved customer compensation within six hours. Total cost to the program: $87,000 drawn from R06’s $120,000 allocation. The risk register had predicted its own cost. The allocation held.
A fictional case study for teaching purposes. Atlas Bank, Project Falcon and all named individuals are invented. Technologies are industry-standard and publicly available.