Real-time risk: why batch processing is killing your trading desk

Every morning, traders at most global banks sit down to screens showing yesterday's risk. Their P&L is stale. Their Greeks are from the close. Their exposure to counterparty default is based on positions that may have shifted significantly in Asian and European hours. They are, in effect, flying blind for the first hours of each trading day -- and often throughout it.

This is the legacy of batch-based risk computation: overnight jobs that take 4 to 8 hours to reprice a full portfolio, producing a single snapshot that is already outdated by the time markets open. For decades, this was acceptable. It is no longer. The convergence of regulatory mandates, market speed, and competitive pressure is making real-time risk computation not just desirable but essential.

The True Cost of Stale Risk Data

The financial cost of batch risk is not theoretical. It shows up in concrete, measurable ways across the trading business.

Missed hedging opportunities are the most direct cost. When a trader's risk view is 12 hours old, hedging decisions are based on stale exposures. In volatile markets, this means over-hedging positions that have already moved, under-hedging new exposures, and entirely missing intraday risk accumulation. At a large derivatives desk, this can translate to millions of dollars in unnecessary hedging costs or unhedged losses per quarter.

Delayed market response compounds the problem. When risk limits are checked against end-of-day snapshots, intraday breaches go undetected until the next batch run. This creates a window of unmonitored risk exposure that regulators and risk committees are increasingly unwilling to accept.

Capital inefficiency is the hidden cost. Banks that cannot measure risk in real time must hold larger capital buffers to account for uncertainty -- capital that could otherwise be deployed productively. Real-time risk visibility enables tighter, more accurate capital allocation.

FRTB and the Regulatory Imperative

The Fundamental Review of the Trading Book (FRTB) has fundamentally changed the risk computation landscape. Under FRTB's Internal Models Approach (IMA), banks must compute expected shortfall at a much more granular level than previous Value-at-Risk requirements. The regulation demands:

• Desk-level P&L attribution -- the ability to decompose daily P&L into risk factor contributions at the individual desk level
• Non-modellable risk factors (NMRFs) -- separate capital charges for risk factors that lack sufficient market data for reliable modelling
• P&L backtesting at desk level -- daily comparison of predicted and actual P&L for each trading desk, with regulatory consequences for persistent failures

These requirements are fundamentally incompatible with overnight batch architectures. Desk-level P&L attribution requires intraday revaluation. NMRF identification requires continuous market data analysis. Backtesting requires consistent, timestamped risk snapshots throughout the trading day.

Banks that attempt to meet FRTB requirements by running batch jobs more frequently are fighting physics -- each full portfolio revaluation consumes the same compute resources regardless of frequency, and the infrastructure costs scale linearly with the number of daily runs.

Event-Driven Risk Architecture

The alternative to faster batch is fundamentally different architecture: event-driven, incremental risk computation. Instead of repricing the entire portfolio on a schedule, an event-driven system reprices only what has changed, when it changes.

The core architectural principles include:

1. Dependency graph modeling -- representing the entire portfolio as a graph where instruments, market data, curves, and risk factors are nodes with explicit dependencies
2. Reactive propagation -- when a market tick, position change, or curve update arrives, the system identifies which instruments are affected and recomputes only those
3. Incremental computation -- pricing functions that compute the delta from the last known state rather than recalculating from scratch
4. Partition-aware distribution -- distributing computation across nodes based on graph partitions, not arbitrary batches

This architecture can achieve sub-millisecond latency for individual instrument repricing while maintaining full portfolio coverage. The key insight is that in any given moment, only a small fraction of the portfolio is affected by incoming market data -- event-driven systems exploit this sparsity.

Intraday P&L: From Aspiration to Requirement

Real-time risk architecture unlocks a capability that batch systems simply cannot provide: continuous intraday P&L. Rather than waiting for end-of-day settlement to understand profitability, traders and risk managers can see P&L evolve tick by tick throughout the trading day.

Intraday P&L enables:

• Real-time limit monitoring -- risk limits checked against current, not stale, exposures
• Intraday hedging optimization -- hedging decisions based on live risk, not yesterday's positions
• Trader performance attribution -- understanding not just what a trader made, but when and how
• Early warning on adverse moves -- detecting accumulating losses before they breach thresholds

The value is not just operational. Regulators increasingly expect banks to demonstrate intraday risk awareness. Batch-based institutions that cannot produce continuous P&L face growing scrutiny in supervisory reviews.

The Migration Path

Moving from batch to real-time risk is not a big-bang replacement. The most successful migrations follow an incremental approach:

Phase 1: Parallel Running

Deploy the real-time engine alongside the existing batch system. Both systems process the same portfolio, and results are compared daily. This builds confidence in the new system's accuracy without operational risk.

Phase 2: Progressive Instrument Coverage

Start with the most liquid, well-understood instrument types -- typically linear products and vanilla options. Expand to complex derivatives, structured products, and exotic instruments as pricing models are validated.

Phase 3: Regulatory Integration

Once the real-time engine covers the full portfolio with validated accuracy, integrate it into regulatory reporting workflows. This is where the FRTB benefits materialize -- same-day reporting, desk-level attribution, and continuous backtesting.

Phase 4: Front-Office Delivery

The final phase delivers live risk directly to trading desks, replacing the batch-sourced risk views that traders have historically relied on. This is the moment where real-time risk stops being a back-office capability and becomes a competitive trading advantage.

The Competitive Imperative

Banks that have made the transition to real-time risk report consistent benefits: tighter hedging, lower capital requirements, faster regulatory reporting, and reduced infrastructure costs from eliminating redundant batch compute. Banks that have not made the transition are accumulating competitive disadvantage with each passing quarter.

The technology to build real-time risk systems exists today. The architectural patterns are proven. The question for capital markets institutions is not whether to make this transition but how quickly they can execute it -- and whether they build or buy the capability to do so.