Market Risk and Operational Risk

Visual overview

Market Risk and Operational Risk at a glance — VaR, stress testing, system failures, fraud.

Price Risk, Process Failure, and the Controls That Keep a Bank Functioning

Market risk and operational risk are fundamentally different risk categories, but both can create losses large enough to threaten a bank.

Market risk arises from adverse movement in market variables such as interest rates, foreign exchange rates, equity prices, commodity prices, credit spreads, and volatility. The bank can take some of this risk intentionally—for example, by making markets or holding securities—and can also acquire it indirectly through customer products and balance-sheet positions.

Operational risk arises from inadequate or failed internal processes, people, systems, or external events. It includes fraud, technology outages, processing mistakes, cyber incidents, model implementation failures, physical disruption, vendor failure, and many other events. Basel's definition excludes strategic and reputational risk from the formal operational-risk definition, although operational incidents can obviously create strategic and reputational consequences.

The two categories interact. A trading system defect can create an unintended market position. A market shock can generate huge collateral calls and strain operations. A data error can cause the bank to hedge the wrong amount. Good risk management therefore separates the categories for measurement while connecting them in scenarios and incident analysis.

1. Market Risk Begins With Position

A bank has market risk when the value or cash flow of an asset, liability, or off-balance-sheet position changes as market variables move.

Examples include:

• a bond portfolio losing value when interest rates rise;
• an open USD position losing value when the dollar falls against the bank's reporting currency;
• an equity trading book declining with the stock market;
• an option changing value when volatility rises;
• a commodity derivative moving with oil or metal prices;
• a corporate bond losing value as credit spreads widen.

The bank must first know what positions it has before it can measure the risk.

Position data, market data, product models, and legal entity all matter.

2. Trading Book and Banking Book Need Different Views

Market risk is most visible in a trading book, where positions are actively managed and revalued frequently.

The banking book can also contain significant market sensitivity, especially interest-rate risk in loans, deposits, and investment securities.

A bank should not assume that “not held for trading” means “not exposed to market movement.” A long fixed-rate mortgage can have substantial economic value sensitivity even if the customer never sees a daily market price.

Regulatory market-risk capital and interest-rate risk in the banking book are governed under different frameworks, but treasury and senior management need a joined economic view.

3. Value at Risk Is a Quantile, Not a Maximum Loss

Value at Risk, or VaR, estimates a loss threshold associated with a specified confidence level and holding period under a defined model.

If a portfolio has a one-day 99% VaR of ₹10 crore, the model is saying that under its assumptions, about 99% of modeled one-day outcomes are no worse than a ₹10 crore loss. It does not say ₹10 crore is the maximum possible loss.

The remaining tail can contain much larger losses.

This limitation is one reason modern regulatory market-risk frameworks supplement or replace VaR in important areas with expected shortfall and additional measures.

4. Expected Shortfall Looks Into the Tail

Expected shortfall estimates the average loss in the tail beyond a chosen confidence threshold under the model.

Where VaR asks roughly “where does the tail begin?”, expected shortfall asks “how bad are losses once we are in that tail?”

The Basel market-risk framework uses expected shortfall within the internal-models approach, together with other components such as default-risk and non-modellable-risk-factor treatment.

Expected shortfall is still a model. It depends on data, liquidity horizons, correlations, stress calibration, and the quality of the positions and market inputs.

No single risk number replaces scenario analysis.

5. Sensitivities Explain What Drives the Risk

Traders and risk managers use sensitivities to understand how positions respond to small market movements.

For interest-rate instruments, sensitivities can show value change for movements in rates or curve points.

For options, common Greeks include:

• delta — sensitivity to the underlying price;
• gamma — change in delta as the underlying moves;
• vega — sensitivity to volatility;
• theta — effect of time decay;
• rho — sensitivity to interest rates.

A portfolio can have low net delta while holding large gamma or vega risk.

This is why notional value alone is a poor measure of derivative market risk.

6. Yield-Curve Risk Is More Than One Interest Rate

Interest rates at different maturities can move differently.

The whole curve can shift upward. Short rates can rise while long rates fall. One maturity bucket can move independently.

A bank that hedges only one average duration can retain curve risk.

Risk systems therefore measure sensitivities across multiple maturities and scenarios.

Basis risk also matters when two related rates do not move together. A loan priced from one benchmark and a hedge based on another can leave residual risk.

7. Foreign-Exchange Risk Needs Currency-Level Limits

A bank can acquire FX risk through customer trades, foreign-currency loans, deposits, securities, subsidiaries, and derivatives.

Risk should be measured by individual currency and aggregate portfolio, considering correlations and legal entity.

A customer desk may quote a foreign-exchange transaction and immediately hedge it, leaving little market risk but still creating settlement and counterparty risk.

The system should distinguish these risks rather than assuming one hedge makes the transaction “risk free.”

8. Credit Spread Risk Is Not the Same as Default Risk

A corporate bond can lose market value even when the issuer does not default.

If investors demand a higher yield for the same issuer, the credit spread widens and the bond price falls.

This is market risk in a traded position.

Credit risk asks about default and recovery. Spread risk asks how market valuation changes as required compensation for credit risk changes.

The two are related but not identical.

9. Liquidity Risk Amplifies Market Risk

A model based on normal market prices assumes positions can be exited or hedged at reasonable cost.

During stress, bid-ask spreads widen, market depth falls, and large positions can move the market when sold.

The bank can therefore suffer more than a simple mark-to-market shock because it cannot liquidate positions quickly.

Market-risk frameworks use liquidity horizons and stress concepts to address this problem, but banks also need practical exit analysis for concentrated positions.

A price displayed on a screen is not guaranteed execution liquidity.

10. Stress Testing Complements Statistical Models

Stress testing asks how the portfolio behaves under large, adverse market movements.

Scenarios can replay historical events or construct plausible combinations such as:

• rates rise sharply;
• yield curve inverts;
• equity markets fall;
• credit spreads widen;
• volatility jumps;
• local currency depreciates;
• commodity prices collapse;
• market liquidity disappears.

The goal is to understand losses, margin calls, liquidity needs, and concentrations outside normal model experience.

Stress testing is especially useful for risks not well captured by recent historical data.

11. Reverse Stress Testing

Reverse stress testing begins with an unacceptable outcome and asks what market movements could produce it.

For a trading desk, the outcome might be breach of loss capacity or capital limit.

For a bank, it can be a combination of market loss and collateral calls that threatens liquidity.

The technique helps identify hidden concentrations and nonlinear positions.

A portfolio can look diversified until one scenario makes several supposedly independent risks move together.

12. Market Risk Limits Need Layers

A bank can use several types of market-risk limits:

• position limits;
• sensitivity limits;
• VaR or expected-shortfall limits;
• stress-loss limits;
• stop-loss limits;
• concentration limits;
• option Greek limits;
• tenor or maturity limits;
• issuer or product limits.

No single measure captures every risk.

Limit breaches should have clear ownership, escalation, and remediation.

Repeated temporary limit increases can indicate that the risk appetite has become weaker than the formal policy.

13. Independent Price Verification

Trading desks value positions every day, but the revenue-generating desk should not be the sole authority for official valuations.

Product-control or valuation functions independently compare trader marks with market data, models, broker quotes, and valuation adjustments.

Illiquid instruments require stronger governance because prices depend more heavily on models and unobservable inputs.

A valuation disagreement affects P&L, capital, risk, collateral, and trader compensation.

Independence reduces the incentive to overstate profits or hide losses.

14. P&L Attribution Helps Detect Model Problems

Daily profit and loss should be explainable by known market movements, new trades, carry, fees, and valuation changes.

If the risk model predicts a certain sensitivity but actual P&L behaves very differently, the position data, model, or market mapping may be wrong.

P&L attribution is therefore more than reporting. It tests whether the risk representation matches the economic position.

Unexplained P&L deserves investigation.

15. Operational Risk Is Embedded Everywhere

Operational risk exists in every banking activity.

A loan can be underwritten correctly but booked with the wrong interest rate.

A payment can be legitimate but sent twice.

A trader can execute an authorized deal that fails settlement because static data is wrong.

A bank can hold enough liquidity but lose access to its treasury system during a cyber incident.

Operational risk is the risk that the machinery implementing banking fails.

16. Operational Risk Is Not Only Technology Risk

Technology is important, but operational risk also includes:

• human error;
• process design;
• internal fraud;
• external fraud;
• legal documentation mistakes;
• physical events;
• third-party failure;
• data quality;
• change management;
• customer-treatment failures;
• model implementation;
• transaction processing.

An institution can have excellent cybersecurity and still suffer major operational losses from manual process or conduct failures.

17. Basel Operational Risk Uses a Standardised Approach

Basel's post-crisis reforms replaced the previous menu of basic, standardized, and advanced measurement approaches for operational-risk capital with a standardized approach based on a business indicator and, subject to jurisdictional implementation choices and framework details, an internal loss component mechanism.

The precise regulatory calculation should always be taken from the current Basel Framework and local supervisory implementation.

The important management lesson is that regulatory capital is not the same as operational-risk management. A bank still needs controls, incidents, scenarios, risk assessments, and resilience even if capital is calculated through a standardized formula.

18. Loss Event Data Creates Institutional Memory

Banks record operational incidents and financial losses in a structured loss database.

Useful fields include:

• date discovered;
• date occurred;
• business line;
• event type;
• gross loss;
• recovery;
• cause;
• control failure;
• customer impact;
• regulatory impact;
• remediation;
• linked incidents.

The purpose is not only capital calculation. Loss data shows recurring weaknesses.

Ten small reconciliation errors can reveal a process defect before one large error occurs.

19. Near Misses Matter

A near miss is an event that could have caused loss but was caught before financial impact.

For example, a payment operator detects an extra zero before releasing a high-value transfer.

No loss occurred, but the control environment still learned something important.

If the bank records only realized financial losses, it ignores evidence about controls that almost failed.

Near-miss reporting should therefore be encouraged rather than punished.

20. Risk and Control Self Assessment

A Risk and Control Self Assessment, or RCSA, helps a business identify its processes, inherent risks, controls, control effectiveness, and residual risk.

The first line owns this exercise because the business understands how the process works.

The second line provides framework, challenge, and consistency.

The value comes from specificity. “System failure risk—control: monitoring” is too vague.

A strong assessment states what can fail, why, what control prevents or detects it, who operates the control, how often, and what evidence proves it occurred.

21. Key Risk Indicators

KRIs provide early warning that operational risk is increasing.

Examples include:

• payment queue age;
• failed batch count;
• manual adjustments;
• high-severity incidents;
• overdue audit issues;
• staff turnover in critical teams;
• privileged-access exceptions;
• unresolved reconciliation items;
• vendor SLA breaches;
• cyber vulnerabilities past due;
• model overrides;
• complaint spikes.

A KRI should have thresholds and actions. A dashboard that stays red for months without consequence is not risk management.

22. Control Design and Control Operation Are Different

A control can be well designed but not performed.

For example, policy requires a second person to approve manual payments. The system supports maker-checker, but staff share credentials and effectively bypass the control.

Conversely, staff can perform a manual workaround that works today but is poorly designed and not sustainable.

Control testing therefore asks both:

• Is the control appropriate for the risk?
• Is it actually operating as intended?

23. Segregation of Duties

Segregation prevents one person from initiating, approving, and concealing a sensitive action.

Examples include:

• payment maker versus checker;
• trader versus valuation control;
• developer versus production deployment;
• loan originator versus credit approver;
• cash custodian versus reconciler;
• vendor creator versus invoice approver.

Small teams can struggle with segregation, but compensating controls are needed rather than ignoring the conflict.

Access design should reflect legal and operational responsibility.

24. Internal Fraud

Internal fraud can include unauthorized trading, theft, false accounting, loan manipulation, collusion, expense fraud, or abuse of privileged access.

Controls include:

• segregation;
• mandatory leave;
• transaction limits;
• independent confirmation;
• access monitoring;
• surveillance;
• reconciliations;
• whistleblowing;
• conflict disclosures;
• periodic rotation for sensitive roles.

Fraud risk increases when one employee controls an end-to-end process without independent evidence.

25. External Fraud

External fraud includes account takeover, payment scams, card fraud, cyber theft, document forgery, lending fraud, and physical robbery.

The bank needs layered controls because criminals adapt quickly.

Identity verification, behavioral monitoring, transaction limits, device security, customer education, network intelligence, and post-event recovery all contribute.

Fraud loss should be analyzed separately from credit or processing error because the remediation differs.

26. Cyber Risk Is Operational Risk With Systemic Reach

A cyber event can steal data, corrupt records, block services, or manipulate transactions.

Critical controls include:

• identity and access management;
• network segmentation;
• vulnerability management;
• secure development;
• endpoint protection;
• encryption;
• key and secrets management;
• privileged-access control;
• monitoring;
• backup integrity;
• incident response.

The bank should plan not only how to keep attackers out but how to operate and recover if an attacker gets in.

27. Data Integrity Can Be More Important Than Availability

A system outage is visible. Corrupted financial data can be more dangerous because the bank continues operating on false information.

If a ledger balance is wrong, treasury, risk, accounting, and customer channels can all make incorrect decisions.

Operational resilience therefore protects confidentiality, integrity, and availability.

Recovery should validate data state, not merely restart servers.

28. Change Risk Is One of the Largest Operational Risks

Banks change software, products, rules, mappings, rates, infrastructure, and vendors continuously.

A small change can affect millions of transactions.

Strong change management includes:

• requirements;
• impact analysis;
• code/configuration control;
• testing;
• segregation;
• deployment approval;
• rollback;
• monitoring;
• post-release review.

Emergency changes need faster governance, not no governance.

29. Configuration Is Code-Like Risk

Interest rates, limits, GL mappings, holiday calendars, payment routes, sanctions lists, product rules, and fee tables can be configuration rather than application code.

A wrong configuration can create just as much loss as a programming defect.

Configuration changes should have versioning, maker-checker, testing, effective dates, and audit history.

“Only a parameter change” is not a risk assessment.

30. Third-Party Risk

Banks rely on cloud providers, processors, software vendors, data suppliers, call centers, card processors, cash logistics, and many other third parties.

Outsourcing the activity does not necessarily outsource accountability.

The bank should assess:

• financial strength;
• security;
• resilience;
• subcontractors;
• data location;
• regulatory access;
• service levels;
• incident response;
• exit capability.

Concentration to one critical provider can become a systemic dependency.

31. Model Risk Can Become Operational Loss

A market-risk model can be theoretically sound but implemented incorrectly in production.

A pricing library can use the wrong curve. A credit model can receive a field in the wrong unit. A risk engine can omit one portfolio after a system migration.

These are operational failures with model consequences.

Model validation, implementation testing, reconciliation, and change control should therefore connect model-risk and operational-risk frameworks.

32. Operational Resilience Focuses on Important Business Services

Modern resilience practice increasingly asks whether the bank can continue delivering critical customer and market services through disruption.

A service such as “make a retail payment” can depend on channel, authentication, core ledger, fraud, payment hub, network, settlement, and notification systems.

Testing only one application's recovery does not prove the business service is resilient.

Banks should identify dependencies end to end and test severe but plausible scenarios.

33. What Excellent Market and Operational Risk Management Looks Like

A world-class bank knows exactly which market variables drive its positions and which processes can fail while managing them. Market risk is measured with sensitivities, statistical models, limits, stress tests, liquidity analysis, and independent valuation. Operational risk is managed through clear process ownership, controls, incidents, KRIs, scenario analysis, resilience, access governance, and learning from losses and near misses.

The deepest lesson is that market risk asks “What happens if prices move?” while operational risk asks “What happens if our machinery fails?”. A resilient bank asks both questions together, because in a real crisis prices can move violently at the same moment systems, people, vendors, and processes are under their greatest pressure.

34. Joined Risk Events Need Joined Escalation

A severe market move can increase trading losses, collateral calls, customer activity, system load, manual adjustments, and operational pressure at the same time. Crisis governance should therefore avoid routing each symptom into a separate silo with no common view. Treasury, market risk, operations, technology, finance, collateral management, and senior management need shared event thresholds and consistent positions.

The strongest control is not a larger number of dashboards but a reliable chain from exposure to decision. The bank should know which market movement caused which valuation change, which operational dependency is under strain, which limits have been consumed, what customer or settlement obligations are approaching, and who has authority to act. That joined view is what turns separate risk disciplines into institutional resilience.

Deep Dive: Market and Operational Risk in the Daily Life of a Bank

Market risk and operational risk become most useful when translated from risk taxonomy into daily banking decisions. A trading desk needs to know how much money it can lose if rates or FX move. Treasury needs to know whether a hedge protects economic value but creates collateral outflow. Operations needs to know whether the trade that exists in the front-office system also exists correctly in confirmation, settlement, accounting, and risk systems. Technology needs to know whether a release can accidentally change market positions or transaction state. Senior management needs one joined view that shows whether the institution is taking the intended risks and whether the machinery controlling those risks is working.

The difference can be summarized simply:

• market risk is often the risk in a position the bank knowingly holds;
• operational risk is often the risk that the bank's people, processes, systems, data, or external dependencies fail to execute the intended business correctly.

A rogue trade illustrates both. The market movement creates the financial loss, but the failure to detect an unauthorized position is operational risk. A well-governed bank analyses both causes.

Position completeness is the first market-risk control

A perfect risk model produces the wrong answer if one portfolio is missing.

Before calculating VaR, expected shortfall, sensitivities, or stress loss, the bank should prove that the risk system received the complete population of positions.

Controls can compare:

• front-office trade count;
• risk-system trade count;
• notional totals;
• market value;
• product type;
• legal entity;
• trading desk;
• currency.

Any breaks should be investigated before risk numbers are trusted.

A common migration failure occurs when a new product is booked successfully in the front office but the risk feed does not recognize its product code. Revenue appears while risk is understated.

Market data is part of the risk position

A bond can be booked correctly and still be valued incorrectly if the wrong yield curve or spread is applied.

Risk systems rely on market data such as:

• interest-rate curves;
• FX spot and forward rates;
• equity prices;
• commodity prices;
• implied volatilities;
• credit spreads;
• correlations;
• dividend assumptions;
• fixings.

Market data needs source governance, timestamp, stale-price checks, exception handling, and version history.

If one curve fails to update, the portfolio can appear stable precisely because the market shock was never loaded.

Stale market data should create a visible exception

A risk engine should not quietly reuse yesterday's price and report today's risk as normal.

Staleness controls can flag when a price, curve, or volatility surface did not update within the expected window.

The bank then decides whether to obtain an alternate source, apply a conservative valuation, or restrict activity.

The more illiquid the instrument, the harder this becomes because no reliable daily traded price may exist.

The control objective is transparency: management should know where valuation relies on stale or judgmental inputs.

Independent valuation protects P&L integrity

A trader can legitimately have the strongest knowledge of a complex position, but the trader also has an incentive connected to reported performance.

Independent valuation control separates business execution from official price verification.

The process can compare desk marks with external prices, independent models, broker quotations, or valuation reserves.

Material differences should be explained and approved.

This protects financial statements, compensation, regulatory capital, and risk measures from one-sided valuation optimism.

Valuation adjustments make model price more realistic

A theoretical model value may need adjustments for factors such as funding, credit, bid-ask cost, model uncertainty, close-out cost, or other risks according to the product and accounting framework.

These adjustments should be governed and independently reviewed.

A bank should avoid the temptation to use a “perfect mid-market model price” for P&L while ignoring the real cost of exiting a large or illiquid position.

Valuation and liquidity are linked.

Sensitivity ladders show where curve risk sits

Instead of reporting one duration number for an interest-rate portfolio, risk teams can show sensitivity across maturity buckets.

For example, the bank can estimate value change for a small rate move at 1-year, 2-year, 5-year, 10-year, and 30-year points.

This reveals curve concentration.

A portfolio can be close to duration-neutral overall while holding a large long 2-year position and short 10-year position. A twist in the curve can then generate loss even though a parallel shift appears hedged.

Risk limits can be set by tenor to control this.

Basis risk survives apparent hedges

Suppose a bank receives a floating rate on loans based on one reference rate but hedges with swaps linked to another.

The two rates usually move together, but not perfectly.

The difference can widen during stress, causing residual P&L.

Basis risk also occurs between onshore and offshore FX rates, different commodity grades, cash bonds and credit derivatives, or similar but non-identical instruments.

Hedge effectiveness should therefore be measured empirically, not assumed from product labels.

Volatility is a market variable in its own right

Option values can change significantly even when the underlying price is unchanged because expected volatility changes.

A bank selling options can therefore lose money when volatility rises.

Vega measures sensitivity to this change, while gamma captures how delta changes as the underlying moves.

Stress tests should include volatility shocks and nonlinear behavior.

A portfolio with small day-to-day VaR can contain significant tail option risk if the model relies on calm historical volatility.

Correlation breaks are crisis risk

Diversification benefits depend on positions not moving together perfectly.

During stress, correlations can change sharply. Assets that normally offset each other can decline simultaneously.

A portfolio that appears diversified under historical correlation estimates can therefore suffer concentrated loss in crisis.

Stress testing should include correlation breakdown rather than simply scaling recent volatility.

This is one reason scenario analysis remains necessary even with sophisticated statistical models.

VaR backtesting compares model prediction with actual outcomes

Banks using VaR or related internal risk measures can compare daily realized or hypothetical P&L with prior risk forecasts.

If losses exceed the VaR threshold more often than expected, the model may underestimate risk.

Backtesting exceptions should be investigated for cause:

• unusual market event;
• missing position;
• bad market data;
• model limitation;
• intraday trading;
• valuation adjustment;
• operational error.

The exercise is not simply counting exceptions. It tests whether the model represents the actual book.

Expected shortfall is not immune to model risk

Expected shortfall improves tail sensitivity relative to VaR, but it still requires choices about scenario distribution, historical window, liquidity horizon, risk-factor modellability, and aggregation.

A sophisticated number can create false confidence if users do not understand assumptions.

Senior management should therefore receive explanatory risk information alongside the aggregate metric: key drivers, stressed scenarios, concentrations, and model limitations.

Risk numbers should support judgment, not replace it.

Stress scenarios should be coherent narratives

A weak stress test shocks every variable independently by an arbitrary percentage.

A stronger stress scenario tells an economic story.

For example:

• inflation surprises upward;
• central banks raise rates;
• yield curves reprice;
• equities fall;
• credit spreads widen;
• emerging-market currencies weaken;
• volatility rises;
• liquidity deteriorates.

The relationships among shocks should be economically plausible, while still severe.

Scenario governance should challenge both severity and internal consistency.

Historical scenarios must be scaled thoughtfully

Replaying 2008, 2020, or another crisis can be useful, but today's portfolio and market structure differ.

A historical price move can be applied to current positions, but risk managers should ask whether new products, regulations, liquidity conditions, and monetary regimes require additional hypothetical shocks.

History is evidence, not a complete library of future crises.

Reverse stress testing helps fill the gap by asking which unobserved scenario could break today's portfolio.

Liquidity-adjusted market risk is operationally important

A position's market value can decline further if the bank must exit quickly.

Risk should consider:

• normal daily trading volume;
• position size relative to market depth;
• bid-ask spread;
• number of days needed to liquidate;
• market concentration;
• collateral or financing dependency.

A small position in a liquid government bond and a large position in a bespoke structured note can have similar mark-to-market sensitivity but radically different exit risk.

This affects both stress loss and contingency planning.

Market-risk limits should be linked to authority

A desk needs clear limits and clear escalation when limits are breached.

The risk system should know:

• approved limit;
• current utilization;
• intraday and end-of-day breach;
• temporary limit increase;
• approving authority;
• expiry of temporary approval;
• remediation plan.

A temporary increase that never expires becomes an undocumented change to risk appetite.

Electronic limit workflow and audit history make governance stronger.

Stop-loss is not a substitute for risk measurement

A stop-loss limit can require escalation after cumulative trading loss exceeds a threshold.

It is useful because actual P&L can reveal model errors or unexpected market conditions.

But a stop-loss reacts after loss occurs. It should complement position, sensitivity, stress, and statistical limits rather than replace them.

A desk can remain within VaR while losing repeatedly because the market moves against its strategy each day.

P&L and risk need to be monitored together.

New product approval should include market and operational risk

A bank launching a new derivative or structured product should not focus only on customer demand and pricing.

The approval process should confirm:

• product valuation model;
• market data;
• risk factors;
• limits;
• accounting treatment;
• confirmation;
• settlement;
• collateral;
• legal documentation;
• tax;
• regulatory treatment;
• system support;
• operations procedures;
• fallback valuation;
• end-of-life events.

If operations cannot settle or risk cannot measure the product, it is not production-ready.

Manual booking is a major control point

Some complex or exceptional transactions can require manual input.

Manual booking creates risk of wrong notional, direction, currency, date, price, counterparty, or product type.

Controls can include trade confirmation, maker-checker, automated reasonableness tests, independent reconciliation, and alerts for unusually large values.

A wrong buy/sell direction can double the intended market exposure instead of hedging it.

Small operational mistakes can create large market risk.

Trade amendments need full downstream propagation

A trader can correct a trade after booking. The amendment must reach risk, valuation, confirmation, settlement, accounting, and reporting systems consistently.

If only the front-office record changes, downstream systems can continue processing the old economics.

Amendments should preserve original and revised states with an audit trail.

Cancellation and rebooking should not erase evidence.

Confirmation controls detect booking differences

Bilateral trades are commonly confirmed with the counterparty.

The confirmation checks economics such as product, notional, price, dates, settlement, and legal terms.

A mismatch can reveal a booking error before settlement.

Unconfirmed trades should be aged and escalated. A large trade that remains unmatched is a risk signal, not an administrative inconvenience.

Electronic confirmation and matching can reduce manual error but still need exception management.

Settlement instructions are high-risk static data

A perfectly priced trade can lose money if settlement goes to the wrong account.

Standing settlement instructions should have controlled source, validation, maker-checker approval, effective dating, and secure change procedures.

Fraudsters can send convincing emails requesting a “new bank account.”

Operations should verify sensitive instruction changes through trusted channels and avoid relying solely on email.

Static-data control is operational-risk management with direct financial consequences.

Reconciliation independently closes market transactions

Trade records should reconcile across front office, risk, accounting, confirmation, settlement, custody, and cash accounts.

Breaks can identify missing trades, duplicate booking, failed settlement, wrong cash amount, or accounting error.

A successful trader P&L does not prove the cash settled correctly.

Independent reconciliation protects against both error and fraud.

Rogue trading exploits control gaps

Rogue traders typically do more than take unauthorized market risk. They exploit operational weaknesses to hide it.

Patterns can include false trades, manipulated valuations, delayed confirmations, fictitious hedges, or unauthorized account access.

Prevention therefore requires layered controls:

• independent limits;
• confirmation;
• valuation;
• P&L control;
• reconciliation;
• segregation;
• access monitoring;
• mandatory leave;
• escalation of unexplained differences.

No one control is sufficient against deliberate concealment.

Operational-risk taxonomy improves root-cause analysis

Banks classify operational events so recurring patterns can be identified.

The taxonomy can distinguish internal fraud, external fraud, employment practices, clients/products/business practices, physical asset damage, business disruption/system failures, and execution/delivery/process management in line with Basel event concepts.

The label should not become a substitute for root cause.

Two events can both be “execution error” while one is caused by poor training and another by an impossible user interface. Remediation should address the actual cause.

Gross loss, net loss, and recovery should be separate

An operational event can produce an initial gross loss and later recoveries from insurance, customers, counterparties, or legal action.

Loss databases should preserve both gross and net amounts.

Otherwise management can underestimate event severity because recoveries happened later.

Insurance can reduce economic loss but does not prove the control environment was acceptable.

Incident severity should include non-financial impact

A technology outage can have little direct accounting loss but affect millions of customers and trigger regulatory reporting.

Severity frameworks should consider:

• financial loss;
• customer count;
• critical service duration;
• data impact;
• regulatory impact;
• legal impact;
• market impact;
• reputational consequence.

One dollar value cannot summarize every operational incident.

Root-cause analysis should go beyond “human error”

If an employee enters the wrong account number, the root cause is rarely just human error.

A better investigation asks:

• Why was manual entry required?
• Was the field validated?
• Did the UI make the error likely?
• Was maker-checker required?
• Did the system compare beneficiary name?
• Were staff overloaded?
• Did procedures conflict?

Human error is an event description, not always a root cause.

Good remediation redesigns the system rather than telling staff to “be more careful.”

Control automation reduces variability but creates dependency

Automating sanctions screening, payment validation, reconciliation, or limit checks improves consistency.

The bank then depends on the automated control remaining available and correctly configured.

Automated controls need:

• ownership;
• monitoring;
• change control;
• fallback;
• evidence;
• periodic testing.

A control that fails silently can be more dangerous than a manual control because staff assume protection still exists.

Key controls deserve stronger testing

Not every control has equal importance.

Controls preventing unauthorized payments, protecting customer balances, ensuring regulatory reporting, managing high-value trading limits, or reconciling settlement can be designated key controls.

Testing frequency and evidence can reflect materiality.

If a key control fails, the bank should assess whether transactions processed during the failure need retrospective review.

Control restoration alone may not resolve the exposure created during the gap.

Access rights can accumulate over time

Employees change roles but retain old entitlements. Contractors remain active after projects finish. Service accounts gain privileges for temporary fixes.

Periodic access review removes unnecessary rights.

Joiner-mover-leaver processes should update access promptly.

Privileged accounts deserve stronger monitoring and authentication.

A former operations user should not retain approval rights after moving to a development team.

Shared credentials destroy accountability

Two employees using one generic account make it impossible to prove who performed a sensitive action.

Banks should eliminate shared user IDs where individual accountability is required and use controlled service accounts only for machine processes.

Emergency or break-glass accounts should be tightly restricted, monitored, and reviewed after use.

Auditability is a control outcome, not merely a logging feature.

Change-management segregation prevents hidden production risk

A developer who can write code, deploy it, and alter production data can conceal errors or fraud.

Strong environments separate development, approval, deployment, and production support according to risk.

Automated pipelines can enforce this separation with code review, tests, signed artifacts, and approval gates.

DevOps does not remove segregation; it implements it differently.

Release monitoring should focus on business outcomes

After a payment release, teams should monitor transaction rejection, latency, duplicate rate, reconciliation breaks, and customer complaints—not only server health.

A release can be technically stable while business processing is wrong.

For trading systems, post-release monitoring can include position count, P&L anomalies, risk sensitivities, and failed confirmations.

Business metrics detect defects that infrastructure dashboards miss.

Data quality needs named ownership

Banks often say “data quality is everyone's responsibility,” which can mean no one owns a defect.

Critical data such as customer identifiers, settlement instructions, ratings, market data, and accounting mappings should have named data owners and source systems.

Quality rules can test completeness, validity, timeliness, uniqueness, and consistency.

When a defect is found downstream, remediation should fix the source rather than rely permanently on manual repair.

Reconciliation breaks are operational-risk indicators

A reconciliation team can spend months clearing the same type of break manually.

Repeated breaks indicate an upstream process defect.

Management should measure break root causes, recurrence, age, and value.

The objective of reconciliation is not to become excellent at manual cleanup. It is to identify and eliminate causes while maintaining independent financial assurance.

Aging matters more than total break count

A large number of same-day timing breaks can be normal. One unexplained break that remains for six months can be more dangerous.

Reconciliation dashboards should therefore show age buckets and ownership.

Suspense and nostro breaks deserve strict escalation because they can represent customer or settlement funds.

Aged differences can also be exploited to hide fraud.

Third-party incidents need bank-level response

If a card processor or cloud provider has an outage, the customer still experiences a bank service failure.

The bank needs incident integration with critical vendors:

• notification requirements;
• severity mapping;
• technical bridge;
• customer impact data;
• recovery estimates;
• regulator communication where required;
• post-incident review.

A contract SLA is not a recovery plan.

The bank should know how to operate when the vendor is unavailable.

Concentration to technology providers is a portfolio risk

Several business units can independently choose the same cloud, identity, payment, or software provider.

At enterprise level, the bank can become highly concentrated without any individual procurement appearing large.

Third-party risk should aggregate dependency across services and legal entities.

A single provider outage can then be tested as a common-cause scenario.

Exit planning is part of vendor risk

The bank should know how it would migrate from a critical provider if service deteriorates, contract ends, or regulation requires change.

Exit plans should consider data export, replacement technology, staff knowledge, parallel run, customer communication, and time required.

“Switch provider” is not a credible contingency if migration normally takes two years.

Critical outsourcing needs realistic exit analysis.

Operational resilience uses impact tolerance

Rather than assuming every incident can be prevented, resilience frameworks ask how long an important service can be disrupted before unacceptable harm occurs and how the bank remains within that tolerance.

For a payment service, the tolerance can depend on customer type, value, regulatory obligation, and market role.

Mapping the end-to-end service identifies dependencies and single points of failure.

Resilience testing then validates whether recovery is achievable under severe but plausible scenarios.

Disaster recovery must preserve financial state

Restoring a database backup is not enough if transactions occurred after the backup.

The bank needs to reconcile restored state with external systems and durable event logs.

A payment replay can create duplicates if the recovery process does not know which instructions were already settled.

Financial recovery therefore needs idempotency, transaction sequencing, journal integrity, and reconciliation—not only server restoration.

Cyber recovery should assume compromise, not simple outage

If ransomware encrypts systems, the bank cannot blindly restore from the latest backup without knowing whether the attacker corrupted data or credentials earlier.

Recovery needs clean-room capability, trusted backups, credential rotation, forensic evidence, and validation of financial records.

The fastest recovery is not always the safest recovery.

Integrity comes before speed when the authoritative ledger may be compromised.

Scenario analysis supports rare operational events

Historical loss data alone cannot predict very rare, high-severity events such as major cyberattack, natural disaster, or widespread payment-system outage.

Banks use scenario analysis to estimate possible impact and identify control gaps.

A scenario should describe causes, affected services, duration, customer impact, financial loss, recovery assumptions, and management response.

The goal is not to produce a precise probability for an unprecedented event. It is to prepare the institution for plausible severe outcomes.

Insurance is a risk mitigant, not a control

Cyber insurance, crime insurance, property insurance, and other policies can offset financial loss.

Insurance does not prevent the event and may contain exclusions, deductibles, limits, or delayed recovery.

The bank should understand coverage and claims evidence before relying on it in risk assessment.

A weak control should not be accepted simply because the bank is insured.

Conduct events are operationally expensive

Mis-selling, unfair customer treatment, benchmark manipulation, or inappropriate product design can create fines, remediation, litigation, and reputational damage.

The root cause can include incentive design, sales targets, poor product governance, weak training, or ineffective complaint monitoring.

Operational-risk frameworks should connect conduct incidents to business-process remediation rather than treating fines as one-time expenses.

Customer complaints can be an early-warning indicator of future large losses.

Culture determines whether controls are used

Policies cannot prevent loss if staff believe commercial targets matter more than rules.

Risk culture appears in daily behavior:

• Are bad news and near misses reported?
• Can risk functions challenge senior revenue producers?
• Are limit breaches treated seriously?
• Do managers reward employees who stop a risky transaction?
• Are audit issues closed honestly?

Culture is difficult to quantify but visible in override and incident patterns.

A healthy culture makes controls credible.

Three lines clarify accountability

The first line owns the risk created by its business and operates controls.

The second line sets frameworks, provides independent challenge, and monitors adherence.

The third line—internal audit—provides independent assurance over governance and control effectiveness.

The model should not become an excuse for the business to say “risk owns the risk.”

The first line remains responsible for safe operation.

Likewise, second-line challenge should be independent without becoming detached from how the business actually works.

Board reporting should focus on decision-relevant risk

Senior committees do not need thousands of raw metrics.

They need to understand:

• largest market concentrations;
• stress losses;
• key limit breaches;
• material operational incidents;
• control failures;
• resilience weaknesses;
• third-party concentration;
• overdue remediation;
• emerging risks.

Reports should show trend and consequence, not only current status.

A KRI that deteriorated for six months is more informative than one red/amber/green snapshot.

Market and operational risk should meet in stress testing

Imagine a sudden 300-basis-point rate shock.

Market risk estimates a large decline in bond and derivative values. The move also generates collateral calls. Trading volumes spike. Market-data feeds become stressed. A critical vendor has latency. Operations receives thousands of margin and settlement events above normal volume.

The scenario now includes market loss, liquidity need, system capacity, staffing, and third-party performance.

This is closer to a real crisis than a market-risk model operating alone.

A trading-system defect scenario

A software release changes the sign convention for one interest-rate product. New trades that should reduce duration instead increase it.

Front-office users believe they are hedged. The risk feed receives the same incorrect sign, so the desk and risk system agree.

Independent P&L attribution later shows losses inconsistent with observed market moves. Investigation finds the shared mapping defect.

The event demonstrates a common-control risk: two systems were not independent because both used the same transformation.

A robust architecture uses independent reconciliations and test scenarios to detect such errors earlier.

A settlement-instruction fraud scenario

A fraudster compromises a supplier's email and sends new bank details before a large securities settlement payment.

Operations updates the standing instruction based on the email alone. The payment goes to the criminal account.

The market trade itself was legitimate and correctly priced. The loss is operational.

Strong controls would require verified static-data change, independent callback or trusted-source confirmation, maker-checker, and alerting for high-value first payment to a new destination.

A cloud outage scenario

A bank's mobile application and fraud service depend on one cloud region. The region fails.

Core ledger remains available on another platform, but customers cannot authenticate or initiate payments because the fraud dependency is unavailable.

The bank must decide whether to fail closed, activate a secondary region, or use a predefined degraded-control mode.

This is why resilience maps dependencies by business service, not by whether the core banking system itself is running.

A rogue-trader scenario

A trader exceeds authorized limits and creates false hedging entries to hide the exposure. The front office sees offsetting positions, but independent confirmations never arrive for the fictitious hedge.

If confirmation breaks are aged and escalated, the scheme is discovered early.

If operations treats unmatched confirmations as routine backlog, the trader can continue increasing risk.

The control failure is operational; the eventual loss arrives through market movement.

What world-class integration looks like

A world-class bank does not have a market-risk team that produces elegant numbers while operations cannot explain the positions, or an operational-risk team that records incidents without understanding their financial consequences. The two disciplines share position data, incident evidence, stress scenarios, model governance, and senior escalation.

Market risk answers how exposed the bank is to changing prices. Operational risk answers whether the bank can reliably execute and control the activities that create those positions. When both are managed well, the bank knows not only what risk it intended to take, but also whether the institution actually holds exactly that risk—and no hidden risk created by errors, fraud, systems, or third parties.