When is it Time for Real-Time?

The challenges in super and wealth are familiar: customers demand immediacy, regulators are tightening reporting obligations, and tech-savvy competitors are raising the bar. We need to be quick, we need to have visibility of our operations and we need to provide excellent customer experiences. Technology and data can help to get us there. And in deciding how, increasingly we find ourselves asking, how fast is fast enough? How responsive do our systems need to be? Is it, in fact, time for real-time? 

Understanding “Real-Time”

In engineering disciplines, “real-time” has a formal definition, referring to systems where correctness depends not only on the result of computation, but also how quickly the results are produced. Within the financial services context, the term is often used more loosely:

• • To describe prompt responsiveness,
  • To convey a desire for more up-to-date data,
  • To differentiate from a ‘batched’ process.

This ambiguity can lead to confusion, as project requirements may originate from stakeholders with varying interpretations of what “real-time” entails. Without clarifying the intent behind the term, there is a risk of solution misaligned to the true need of the users. There are certainly cases where a true real-time system is needed, but it should be a justified choice. Real-time systems are more complex than systems without such a constraint. This complexity often brings with it additional costs to implement, integrate, monitor and maintain. We should be looking to avoid the burden of this complexity unless the functionality provided justifies it.

Determining the necessity of real-time

Leaders often pursue real-time solutions out of fear of missing out or the assumption that modern technology must be adopted. Instead of accepting “real-time” as a requirement or succumbing to FOMO, it’s important that decision makers probe for the underlying functional need. A request for real-time might actually be one of the following:

• • “Immediate feedback”: “When I click save, show me it worked” (user confidence, not speed)
  • “Current data”: “Show me today’s market prices, not yesterday’s” (data freshness, not real-time streams)
  • “Fast response”: “Don’t make me wait 30 seconds for a simple query” (performance expectation, not real-time processing)
  • “Live updates”: “Tell me when something important changes” (notification requirement)
  • “Distributed consistency”: “I expect data is consistent across different services” (e.g. changing a policy via the mobile app is reflected promptly on the web portal)

By understanding the actual functional requirement, you may reveal that there is a far simpler or cheaper alternative that provides the functionality required. Delivering value without the complexity of a real-time system.

Making the Business Case

Even with clear requirements, real-time architecture should be approached cautiously. As these systems are often costly and complex, investment should be justified by measurable business value, not driven by prevailing technology trends. There are a few assessments organisations must step through before jumping to real-time solutions architecture:

1. 1. Assess the business impact of processing delays. If even brief latency results in financial loss, regulatory failure, or unacceptable risk, then real-time capabilities may be justified.
   2. Consider whether delays can be tolerated or mitigated through other means, a less complex and more cost-effective approach may be sufficient.
   3. Consider whether the organisation has the technical capability and operational maturity to support a real-time system. These systems often require sustained investment in monitoring, testing, and maintenance, and the consequences of failure may be more difficult to isolate or remediate.

There are clear domains where real-time systems are essential — such as fraud detection, low-latency trading, or control systems — but many initiatives fall into a grey area. The decision should be guided by a balance of value, cost, and risk. If the benefits derived from real-time capabilities are both material and unachievable through other means, then the additional complexity may be warranted. If not, alternative approaches should be considered.

When Real-Time is the only option

While real-time systems are complex and costly, there are scenarios in which they are essential. These are cases where delays directly translate into financial loss, regulatory penalties, or systemic risk, and no workaround can substitute for immediate response. For example:

1. 1. Trading: In high-frequency trading, outcomes depend on actions taken within microseconds. Milliseconds can mean millions in trading — delays are unacceptable. · Fraud Prevention: In banking, transaction fraud must be stopped before authorisation. Once approved, the damage is done. Real-time screening — often within 50–200ms — is required to prevent losses.
   2. Regulatory Monitoring: Some compliance events require near-immediate monitoring, with deadlines for reporting increasingly shifting from 24 hours to real time. Penalties for delays can be severe.
   3. Instant Payments: With systems like NPP (New Payments Platform) and PayID, payment finality is expected within seconds. Delays are not tolerated by consumers or business partners, and there is no partial success mode — payments must clear or fail immediately.

Real-time systems become essential when delays cause measurable harm. This includes situations where losses grow with time, there are fixed external deadlines, failures cannot be recovered from, or delays damage competitiveness or reputation. In these cases, the investment is justified.

A gentle start: Hybrid Architecture

Another approach could be a hybrid architecture. Most organisations don’t need to choose between “all real-time” or “all batch.” Few organisations need all their systems to be fully real-time. Hybrid architectures offer real-time where it matters, while retaining batch systems for the rest — at far lower cost than a full re-architecture.

Intelligent avoidance: Functionality Without Real-Time Complexity

Many perceived “real-time” requirements are actually user experience challenges disguised as technical ones. Before rebuilding your architecture, consider these proven patterns that deliver responsive experiences without the complexity overhead.

Optimistic Updates for Perceived Performance

The Problem: Policy amendments take 15 seconds due to backend checks. Users may perceive the delay as a failure.

The Solution: Use optimistic updates — immediately reflect the change in the interface with a message confirming receipt. Once validated, display “Policy updated successfully.”

Progressive Enhancement Strategies

The Problem: Insurance quote calculations take 30–45 seconds, leading users to abandon the process.

The Solution: Break the process into visible stages with immediate feedback:

1. “Analysing your profile…” (instant).

2. “Calculating risk factors…” (5-10 seconds).

3. “Comparing provider options…” (15-20 seconds).

4. “Finalising your personalised quote…” (final 10 seconds).

Intelligent Caching and Pre-fetching

The Problem: Real-time investment data is slow to fetch but not always needed.

The Solution: Implement tiered freshness strategies:

• • Immediate: Show last cached value (instant load)
  • Background refresh: Update value if cache is > 5 minutes old
  • On-demand: “Refresh now” button for users who need current data
  • Predictive: Pre-fetch data for high-engagement users

Conclusion: Strategic Timing for Real-Time Investment

The question isn’t whether your organisation will eventually adopt real-time capabilities — it’s when and how to do it strategically. Success comes from carefully evaluating business requirements and choosing appropriate technical solutions, whether that’s real-time systems for genuine timing-critical needs or alternative approaches that deliver equivalent business value more efficiently.

The time for real-time isn’t “now” for everyone — but it’s time to seriously evaluate when it will be right for your organisation.

When is it time for Real-Time? is part of The Quarterly – Q4 FY25

Key Contributor:

This article was also strengthened by a wider group of Novigi specialists, whose withering years of toil and rich experience added depth and clarity to the perspectives shared.

For more information about anything you’ve read here, or if you have a more general inquiry, please contact us.