Agent Fraud, an API Outage and a Cloud Provider Abroad
A branchless bank in Pakistan serves 4.2 million wallets. 62% of transaction volume flows through one mobile network operator's API; the contract has no service credits, a 12-month termination notice and no audit rights. In March the API failed for nine hours on salary day, and reconciliation breaks of PKR 310m were cleared manually over four days. Separately, an investigation found that 37 agents had opened accounts using expired or borrowed CNICs and had withdrawn PKR 84m through mule wallets. The fraud was detected by a customer complaint, not by monitoring, and the near-miss log has no entry. Core banking runs on a cloud provider with primary data in Singapore and no tested exit plan. The board asks why operational risk capital anticipated none of this; the internal loss data set has 40 losses, all under PKR 5m.
1. Classify these events under Basel event types and explain why classification affects capital and control ownership.
Read the worked answer
The API outage is business disruption and system failures - a technology failure at a third party that becomes the bank's failure to customers. The agent fraud is external fraud: agents are third parties, even though the CNIC failures also engage execution, delivery and process management in onboarding and monitoring. The reconciliation breaks are execution, delivery and process management, with a possible internal fraud element if staff suppressed them. The cloud arrangement raises outsourcing and data-residency risk that maps to business disruption and to regulatory obligations.
Classification matters for three reasons. First, it determines which control owner is accountable - IT and vendor management for the outage, branchless banking and compliance for agent oversight, operations for reconciliation, and the outsourcing committee for the cloud. Second, it drives loss-data pooling and scenario selection: if agent fraud is coded as a process error, the frequency and severity of external fraud are understated and the capital estimate misses the tail. Third, insurance and regulatory reporting map to event types.
The data set itself is the finding. Forty losses all below PKR 5m against an PKR 84m fraud and a PKR 310m reconciliation event means the threshold or the capture process is wrong. A loss data threshold set too high, or a culture that routes large events to 'operational incident' rather than loss, will systematically understate capital.
2. Is 62% API concentration acceptable? Frame the decision for the board.
Read the worked answer
The board cannot answer without a scenario, and the contract makes the scenario worse. With no service credits, no audit rights and 12 months to exit, the bank has almost no contractual leverage and cannot switch quickly. Concentration of 62% of transaction volume in one operator is a single point of failure for customer access, settlement and reputation.
Quantify: a nine-hour outage on salary day already occurred; model a 72-hour outage. Estimate failed transactions, customer compensation, regulatory attention, agent liquidity stress and the manual reconciliation cost, then compare with the cost of mitigation. Assess substitutability - can customers use USSD, the app, or another network? Is there dual routing? Is the manual fallback tested?
Options: renegotiate the contract for SLAs, penalties, audit rights and a shorter exit; build dual connectivity or a second operator; invest in an in-house channel; and set a board-approved concentration limit with a remediation date. Where the risk is accepted, capital and a tested business continuity plan must follow. The decision should be minuted as a risk acceptance with an owner and a date, not left as an IT issue. The outsourcing and cloud arrangements should be assessed against SBP outsourcing expectations, including data localisation and exit plans.
3. Design a scenario-based operational risk estimate for the outage and the mule-account fraud, and explain how you would validate it.
Read the worked answer
Run separate workshops with technology, operations, fraud, compliance and business. For each scenario define a frequency distribution, a severity distribution and a dependency structure.
Outage: frequency about once every two years for a material event; severity built from direct loss (failed settlements, compensation), recovery costs (manual clearing, overtime), regulatory cost and lost revenue. Model a 72-hour salary-day tail, not just the nine hours observed.
Fraud: frequency of agent-network fraud - say two events per year at current control levels - and severity from the PKR 84m observed loss scaled for a larger agent cohort, plus remediation, refunds and regulatory penalty. Correlate the two scenarios weakly; a long outage may increase fraud because monitoring is degraded.
Combine internal data (40 losses), external consortium data and the scenarios; fit a heavy-tailed severity distribution; simulate to the 99.9% percentile and compare with the standardised or internal-model capital. Validate through independent model review, sensitivity to frequency and severity assumptions, back-testing against actual losses, and challenge at the risk committee. Set KRIs - API availability, reconciliation ageing, agent CNIC exception rate, near-miss reporting - so the estimate is connected to live control performance.