Operational Risk | How a Healthy Balance Sheet Can Still Suffer an Operational Failure

The balance sheet is only one half of a bank

Banking is often explained through assets, liabilities, capital and liquidity. That is necessary but incomplete. A bank is also an operating machine that has to identify customers, authenticate instructions, move payments, post ledger entries, value positions, reconcile accounts, protect data, manage collateral, report to regulators and recover from disruption.

If those processes fail, the bank can lose money or stop serving customers even while the financial structure remains sound.

financial capacity answers whether the bank can bear the obligation; operational capacity answers whether the bank can actually perform it.

People can create operational risk

Human beings approve, investigate, reconcile, code, trade, supervise and override. A mistake can create operational loss. So can misconduct, fatigue, weak training, poor incentives or deliberate fraud.

• a payment operator enters the wrong beneficiary;
• a manager approves beyond delegated authority;
• a trader hides losses;
• a developer deploys faulty code;
• a relationship manager bypasses customer checks to meet a target;
• an employee leaks confidential information.

The answer is not “remove people.” Automation simply moves some operational risk into software design, data, access and model governance.

Processes can fail even when every person is competent

A process can contain a structural weakness. Two teams may assume the other performs a control. A transaction may require manual re-keying. A reconciliation may run only once a week. An exception queue may grow faster than staff can review it.

In such cases, individual effort cannot fully compensate for poor process design.

good people inside a bad process can still produce bad banking.

Systems can turn one mistake into a million mistakes

Technology gives banking scale. It also gives failure scale.

A software defect in one manual calculation affects one case. The same defect inside a core banking engine can miscalculate thousands or millions of accounts. A bad data mapping can propagate through risk, finance and regulatory reporting at once.

Automation reduces some human errors while increasing dependence on testing, access control, change management, data quality and recovery.

External events can break a bank without entering the balance sheet first

Operational risk also comes from outside the institution: natural disasters, power failures, telecommunications outages, pandemics, cyberattacks, civil disruption or the failure of a critical third party.

The bank may have done nothing financially reckless. It still needs to keep critical operations within its tolerance for disruption.

The Basel Committee’s current Operational Resilience guidance emphasises governance, operational risk management, business continuity, mapping interconnections, third-party dependencies, incident management and resilient ICT.

Operational risk is not the same as operational resilience

Concept	Main question
Operational risk management	What can fail, how likely or severe could it be, and how should the bank prevent or control it?
Operational resilience	If disruption happens anyway, can the bank continue or recover critical operations within tolerable limits?

Prevention matters. Resilience begins where prevention admits that not every hazard can be stopped.

A healthy balance sheet can still create customer harm during an outage

Imagine a solvent bank whose mobile and online channels fail on salary day. Customers cannot see balances or make transfers. Businesses cannot run payroll. Merchants cannot reconcile receipts.

The bank may suffer little immediate credit loss. The social and operational impact can still be severe.

Banking is therefore a critical service as well as a financial contract.

The first control is ownership

Operational risk becomes difficult to manage when everybody is involved but nobody owns the process. A bank should know which business owner is responsible for the service, which risk function challenges the controls and which technology or operations teams maintain the underlying components.

Clear ownership lets the institution answer three questions quickly: who decides, who executes and who independently checks?

Segregation of duties breaks dangerous concentration

One person should not normally be able to initiate, approve, settle and reconcile the same sensitive banking transaction without independent control.

Separating roles reduces both accidental error and deliberate abuse. Article 54 owns this mechanism in depth: Segregation of Duties.

Reconciliation is how the bank asks whether two records still describe the same event

A payment engine can say one thing while the general ledger says another. A trading system can book a position that the custodian does not show. A customer account can reflect a transaction that settlement never completed.

Reconciliation compares independent records and sends differences to an exception process.

Read Bank Reconciliation.

Operational loss can become credit, liquidity and capital loss

Risk categories are not sealed boxes.

• a cyberattack can trigger fraud losses;
• fraud losses reduce earnings and capital;
• an outage can damage confidence and accelerate deposit withdrawals;
• withdrawals consume liquidity;
• forced asset sales can crystallise market losses;
• a data error can produce bad credit decisions and later defaults.

Operational risk often acts as the first broken link in a multi-risk chain.

Internal fraud is operational risk with intent

Some operational failures are not mistakes. An employee may override limits, create false records, divert payments, manipulate valuations or collude with an external party.

Internal fraud therefore tests access design, segregation, surveillance, whistleblowing, audit and culture. Article 55 owns that threat model.

Third-party dependency can concentrate hidden operational risk

A bank may outsource cloud hosting, software, telecommunications, payment processing or specialist services. Outsourcing the activity does not outsource accountability for the banking service.

If many banks depend on the same provider, one vendor failure can become a system-wide concentration.

The Basel Committee’s consolidated operational-risk and resilience module now includes a dedicated third-party-risk chapter, reflecting how important these dependencies have become.

Change is one of the most dangerous normal states

New software, new products, mergers, migrations and regulatory changes alter established processes. During transition, controls can be incomplete and staff can misunderstand the new operating state.

Good change management therefore asks what can break before launch, during cutover and after implementation. Rollback plans, testing, approvals and post-implementation review matter because the bank is changing the machine while the machine is still running.

A worked miniature

A bank deploys an update to its payment platform. The software mistakenly duplicates a subset of outbound payment messages. Customer accounts are debited once, but counterparties receive duplicate settlement instructions.

The incident creates several operational questions at once: can the bank stop new duplicates, identify affected transactions, reconcile settlement, recover erroneous payments, communicate with customers and determine why testing failed?

Capital may be strong. The problem is still real because ledger integrity and payment finality have diverged.

Key risk indicators are useful only if they lead to action

Banks can monitor system downtime, unresolved exceptions, failed transactions, staff turnover, access violations, fraud attempts, vendor incidents and recovery times.

A dashboard is not a control by itself. The bank needs thresholds, escalation and owners who can act when indicators move beyond tolerance.

Incident management is where governance meets the clock

During a major incident, the bank needs to know who commands the response, which service has priority, which systems can be isolated, when regulators and customers must be informed, and what evidence must be preserved.

Confusion in the first hour can increase damage faster than the original technical fault.

Business continuity begins with critical operations, not buildings

A backup office is useful only if it helps the bank continue the services that matter. Modern continuity planning therefore starts with critical operations, their dependencies and the maximum disruption the institution can tolerate.

Article 56 completes this batch with Business Continuity | How Banks Keep Critical Services Running During Disruption.

Operational risk has a capital consequence

Operational losses reduce profit and can reduce retained earnings. Prudential frameworks also impose operational-risk capital requirements because severe events can occur even when credit and market positions appear sound.

Capital absorbs the financial consequence. It cannot restore a failed payment engine or corrupted dataset. The bank still needs operational repair.

The deepest control is whether the bank can reconstruct truth

After an operational failure, the institution must be able to answer what happened, which records are authoritative, which customers were affected, what money moved and what remains unresolved.

Audit trails, immutable logs, independent records and reconciliations turn a chaotic event back into an evidence problem the bank can solve.

Four misconceptions to remove

Misconception	Better model
“Operational risk is mainly IT risk.”	People, processes, systems and external events all belong to the operational-risk map.
“A well-capitalised bank can absorb any operational problem.”	Capital absorbs financial loss; it cannot by itself restore a critical operation.
“Automation removes human error.”	It often converts repeated human tasks into concentrated design, data and system risk.
“Business continuity means having a backup office.”	Continuity is about delivering critical operations through disruption, wherever and however that is achieved.

A mastery test

1. Why can a financially healthy bank still fail operationally?
2. How is operational risk different from operational resilience?
3. Why does automation sometimes increase concentration risk?
4. How can an operational incident become a liquidity or capital problem?
5. Why is the ability to reconstruct the event from reliable records a core control?

If those answers connect, operational risk becomes visible as the banking system’s execution layer: the promises can be financially sound and still fail if the institution cannot perform them correctly, continuously and provably.

---