Bank Risk Management, Vector Risk

Can Risk Controls Be Slower Than the Market?

July 10, 2026
By Jabuticaba App

Markets move in minutes, but many institutional risk processes still depend on overnight cycles. This article explores why real-time risk infrastructure is becoming essential for banks, brokers and asset managers that need faster answers across VaR, PFE, xVA, SA-CCR, ISDA SIMM, FRTB, margin and capital impact.

Can Risk Controls Be Slower Than the Market?

On June 17, 2026, U.S. stocks turned sharply lower, the dollar extended gains and Treasury yields moved higher after the Federal Reserve left rates unchanged and signaled that a hike could still be possible later in the year. The point is not that this was a crisis. The point is that markets repriced immediately, while many institutional risk processes still depend on overnight cycles to answer questions the desk needed during the move.

That gap is becoming harder to defend.

For years, end-of-day risk was an acceptable operating rhythm. The market closed, positions were frozen, batches ran, reports were distributed, and tomorrow’s decisions were informed by yesterday’s portfolio. But when rates, credit, FX, equity derivatives and collateral demands can move intraday, a risk answer that arrives after the decision has been made is no longer risk management. It is record-keeping.

The 4:15 report was fast. for its time

There is a useful historical benchmark here: J.P. Morgan’s “4:15 report.” Academic work on real-time VaR describes it as a firm-wide risk aggregation process delivered within roughly 15 minutes after market close, designed to manage overnight exposures and inform next-day trading decisions.

That was a serious achievement. It compressed risk aggregation across a large institution into a post-close window and helped define what “fast” looked like in the previous generation of market risk infrastructure.But the benchmark has moved.

The front office now operates with continuous pricing, electronic execution, algorithmic trading, intraday collateral pressure, more automated market structure and increasingly real-time payment rails. Regulation has also pushed institutions toward more granular, better-controlled and more explainable risk processes. In that context, “after the close” is not the same as “in control.”

The issue is not whether the market risk team understands VaR, PFE, xVA, SA-CCR, ISDA SIMM or FRTB. The issue is whether the architecture lets them calculate, aggregate and explain those metrics at the speed of the balance sheet.

This is a plumbing problem, not a people problem

Most large risk functions are not slow because the people are slow. They are slow because the stack was built for a different operating model.

Risk.net’s 2026 real-time risk coverage makes the point directly: many simulations, scenarios and portfolio sums have historically relied on periodic reporting, with traded-risk reports often produced overnight and other risk reports updated weekly, monthly or quarterly. The same piece identifies cloud computing as a major reason real-time reporting has become more achievable, because it removes the need for firms to build vast server farms of their own.

That matters because market risk is computationally expensive by design. Full revaluation across thousands of scenarios, nonlinear derivatives, counterparty exposure profiles, xVA sensitivities, margin models and capital calculations all consume compute. When those workloads sit on constrained on-prem infrastructure, the institution is forced into trade-offs: fewer scenarios, fewer intraday runs, less granularity, delayed aggregation or manual prioritization.

None of those trade-offs are neutral, they become embedded operating risk and blind spots are structural

A recent Risk.net/3forge white paper frames the problem as one of real-time blind spots. It argues that traditional end-of-day controls were not designed for today’s market speed or for automated, interconnected systems. It also points to several areas where real-time risk has become essential, including pre-trade controls, counterparty exposure, portfolio concentration, intraday risk and enterprise-wide operational threats.

That list maps closely to where legacy architecture tends to break.

A desk wants to know how a trade changes collateral usage, capital requirements and limit consumption before execution. Treasury wants to understand the potential for outsize margin calls during the trading day. Risk wants to aggregate exposures across asset classes and counterparties without waiting for batch completion. Finance wants explainable P&L attribution. Compliance wants controls that can be evidenced, not approximated after the fact.

The common constraint is not the concept of the metric. It is the latency between position change, market move, calculation, aggregation and decision.

Ververica describes the EOD problem in similar terms: most banks compute risk positions at market close, while exposures can accumulate between opens, limit breaches may go undetected for hours and intraday volatility spikes can appear only in the next morning’s report.

For a CRO, that is the wrong kind of surprise and real-time is not just a front-office luxuryThere is a tendency to frame real-time analytics as a trading-desk convenience. That misses the point.

Risk.net’s 2026 Risk Technology Awards coverage quotes Greg Jewell of TS Imagine saying firms increasingly need the ability to monitor in real time and react quickly rather than relying on overnight processes. The same article notes that real-time risk can give desks a wider set of information before execution, including collateral usage, capital requirements and limit consumption.

That is not a dashboard problem. It is a decision-rights problem.

If the trader can price a risk but the control function cannot calculate the capital, margin or exposure impact until hours later, the institution has not achieved real-time risk management. It has achieved real-time trading with delayed risk interpretation.

That gap matters most in exactly the moments when liquidity thins, correlations move, basis relationships break, client flows concentrate or collateral calls become urgent. What “fast enough” looks like now?

“Fast enough” does not mean every calculation must be sub-second in every context. A pre-trade limit check, an intraday PFE refresh, a desk-level VaR run, an xVA sensitivity calculation and an FRTB capital process have different latency tolerances.

But the direction of travel is clear.

A modern risk stack should be able to answer five questions closer to the point of decision;
How much is at risk?
What is the client or counterparty exposure?
What capital cost does this position create?
What margin does it require?
Can we explain what changed?

That requires more than speeding up an old batch. It requires architecture that can support scenario-based valuation, cross-asset aggregation, API-based integration, elastic compute and consistent calculation logic across VaR, FRTB, PFE, xVA, SA-CCR and ISDA SIMM.

Vector Risk is a useful example of this design pattern: the current Jabuticaba landing page positions it as one high-performance engine covering VaR, FRTB, PFE and xVA, with all key risk metrics in one engine, API functionality, compatibility with legacy infrastructure and risk calculations up to 80x faster.

Vector Risk’s own site describes the platform as native cloud SaaS rather than a lift-and-shift of legacy software, covering VaR, FRTB SA & IMA, PFE, xVA, SA-CCR and ISDA SIMM. It also describes vectorization as delivering an 80x speed-up over normal code for scenario-based valuation.

The Microsoft Marketplace listing adds two more relevant infrastructure facts: Vector Risk is hosted on Microsoft Azure, uses Microsoft HPC, and cites an example of 32 billion trade valuations in 22 minutes.

The point is not that every institution should buy the same engine. The point is that the architecture is moving toward cloud-native compute, vectorized calculation, unified metric coverage and API-first integration. That is where the market’s operating model is already heading.

The hard part is aggregation

Most firms do not have one risk problem. They have many risk problems that have accreted over time.

One system owns rates. Another owns credit. A third handles SIMM. xVA lives somewhere else. Counterparty exposure is reconciled separately. P&L explain sits between risk, finance and the desk. Data arrives through different APIs, ETL pipelines and semantic models.

Risk.net’s awards coverage makes this implementation issue explicit. In the case of Citizens, the bank was moving from quarterly data collection and analysis to a world closer to real-time access, testing and reporting. One of the cited challenges was getting siloed data into one place, with information crossing different APIs, coding languages and ETL pipelines.

The front office may ask for intraday risk. The risk team may agree. But unless the plumbing supports position data, market data, counterparty hierarchies, valuation models, limits, collateral terms and capital logic in a consistent calculation environment, the output will still arrive too late or require too much manual interpretation.

Real-time risk is not just faster compute. It is faster compute plus trusted aggregation.

A practical self-assessment

A useful test for a CRO or Head of Market Risk is not “do we have a real-time dashboard?” It is whether the organization can act on risk information before the exposure becomes a post-mortem.
Start with three questions.

1. Which risk metrics are still effectively EOD?

List VaR, stress testing, PFE, xVA, SA-CCR, ISDA SIMM, limit consumption and P&L attribution. For each, identify whether the desk can see the result before execution, intraday, after close or next morning. The timing map will reveal the control gaps.

2.Where do we reconcile instead of calculate?

If teams are moving data across spreadsheets, translating between systems, re-running reports manually or explaining breaks between tools, the institution is paying an operational risk tax. Manual reconciliation is not just inefficient. It changes what risk managers have time to challenge.

3. Can we explain the change, not just print the number?

A faster VaR number is useful. A faster explanation of what drove the change is more valuable. In modern risk governance, P&L attribution, hedging effectiveness and capital impact are part of the same conversation. If those answers live in different systems, the control function is slower than the portfolio.

But, the real question is:

No serious risk leader believes every legacy system can be replaced overnight. Large banks and brokers/dealers have real constraints: model governance, data lineage, cybersecurity, procurement, auditability and regulatory expectations. Those constraints are real.

The relevant question is narrower and more urgent: where does the institution need faster answers first?

For many firms, the answer will be trading-book risk, counterparty exposure, intraday margin and capital-aware pre-trade analytics. That is where market speed, balance-sheet usage and control expectations collide.

Markets will not slow down to match the batch cycle. Risk infrastructure has to move closer to the market. See it with your own portfolio.