The Role of Observability in Financial Services

6 Oct 2025

First seen in FTAdviser

I have noticed that the term ‘observability’ has come up in quite a few conversations recently. This has been in the context of various customer teams either striving to prepare for new regulatory demands, such as tailored support and the pensions dashboards, or looking to strengthen their internal systems after labouring to spot emerging issues quickly enough.

The common thread is that everyone’s systems are becoming more complicated to manage, and the stakes are only getting higher for advice businesses. This complexity isn’t just technical; it spans operations, governance and even customer communications, making it harder to pinpoint and resolve root causes quickly.

Some firms are examining how they’re going to be able to prove they meet the uptime and error tracking requirements that are now paramount in their obligations to both clients and regulators. Others are concerned about how they respond to the escalating incidence of cyber-attacks, not merely by beefing up their preventive activities but also detecting them fast enough to protect themselves from serious financial and reputational damage.

What is Observability?

Fundamentally, observability is the capacity to properly see what your systems are doing at any moment.

This term may be bandied about in the same breath as logging and monitoring, but there’s much more to it. It’s not simply about viewing metrics lighting up on an operations dashboard, or ensuring logs are being gathered and stored. It’s really about being able to understand your systems, to the point where you can pose questions about how something behaved, particularly during an unexpected event, and then quickly obtain a useful and actionable answer.

What this means in practice is that observability is becoming an aptitude that separates those who can adapt to what’s thrown at them, from those who are going to struggle.

For example, you don’t just want to know that your API failed. You want to know why it broke, and what else might be affected. You need to find out if it was a poor deployment in the first place, or the result of a cyber assault, or a queue of commands backed up because of a heavy load elsewhere in the system, or some other identifiable reason.

I like the analogy that observability is the difference between hearing a smoke alarm going off and knowing what’s now on fire.

The importance of observability in financial services

Two factors underlie why observability has become a top priority in the financial sector: client-centred regulation and business risk.

Client-centric financial regulation

On the regulation side of the calculation, new requirements embodied in Consumer Duty make it clear that “best efforts” to operate securely and efficiently are no longer enough. You need to meet standards such as Service Level Agreements, you have to know when something’s not working so you can fix it rapidly, and you must safeguard clients from harm emanating from system problems. Not least, you have to be able to evidence your approach, and your actions should the regulator come calling and ask for this.

What you need is a trusted and reliable way to know the moment something is amiss. This won’t be just because your users report it, but because your systems inform your people in real time. When a problem arises, you need actionable intelligence including audit trails, system traces and uptime/downtime metrics along with a way to connect all these dots so you can see the whole picture. You need to pursue an approach that ultimately verifies that the problem was identified, and managed, and then resolved, within a timeframe that keeps your firm in compliance with the letter and spirit of the regulations. This level of transparency can also reassure internal stakeholders and board members, providing evidence that operational resilience is being actively maintained.

Business risk

In the current climate, when it comes to business risk, the primary focus is on managing cyber threats. It’s somewhat depressing that bad actors increasingly apply human ingenuity to disrupt, defraud and even destroy businesses and livelihoods using technology as a gateway. When you follow the money, the fact that financial services remains one of the most targeted sectors should surprise no one.

The latest cyber attacks are unpleasantly stealthy and often hijack lapses in attention by employees, even those regularly trained in cyber security. Losses suffered can be minor or major in strictly financial terms, but the real cost of resulting business disruption can be difficult to quantify, especially when client data is infiltrated and purloined, and a firm’s reputation is affected by negative publicity and regulatory sanction.

The government’s Cyber Security Breaches Survey 2025, commissioned by the Department for Science, Innovation and Technology and the Home Office, identified that an astonishing 43% of UK businesses, approximately 612,000 companies, reported having experienced a cyber security breach or attack in the past 12 months.

Of those suffering a breach or assault, phishing attacks (tricking individuals into revealing sensitive information) remain the most prevalent and disruptive type of intrusion, experienced by 85% of businesses. The survey also found that organisations had a growing awareness that increasingly sophisticated techniques, such as AI impersonation, were becoming more widespread.

With this in mind, observability is no longer simply about performance. It’s also a critical security issue. Firms need to prioritise cyber hygiene, facilitated by the continuous ability to quickly detect and mitigate unusual behaviour in their systems, or things can go very wrong in minutes. When business and client data is involved, this is more than a technical problem; the firm’s reputation and regulatory status are both on the line.

A unified view is vital with modern systems

Most advice businesses are shifting to more dynamic ways of harnessing technology, even indirectly by smaller firms relying on outsourced IT support. Through aspects such as hybrid and multi-cloud environments, Continuous Deployment, and DevOps (integrated and automated software development and IT operations), firms can achieve higher speed and greater flexibility in their operations. On the flip side, it can be harder to trace problems cropping up.

A single team rarely has sight of the whole operational picture now. One team may be managing the infrastructure, another the application logic, a further crew the integrations with third-party suppliers. That’s all fine until something breaks and no one immediately knows where to look for the source.

A well-structured observability setup will give you the capacity to trace a transaction or interaction across all the component parts, from the user clicking on something, to the back end processing an action, to the response coming back. If something is failing along the way, instead of trawling through separate monitoring screens and technical threads, you obtain a unified view accessible by everyone involved in incident response, from tech teams to business leaders. This reduces the time taken to resolve the issue and gives everyone confidence that all issues will be seen and managed. This is particularly key when end clients are or could be affected.

Implementing observability

Making observability work goes far beyond buying a tool. Many organisations already have elements of observability in place, whether it has good logging, useful application performance monitoring, or some dashboards that track load and latency. However, their approach is usually fragmented, because different teams own different pieces of the puzzle, and there’s no cohesive thought-through strategy in place.

To implement observability properly, it’s crucial to think differently about how you structure your data and everyone’s responsibilities. This entails creating shared ownership of uptime, stability and incident response functions, and incorporating this in your development and release processes.

User stories are helpful guides in explaining processes, but these should cover not only what a process is meant to do, and how it is tested, but also what information should be triggered, both when the process works and when it doesn’t.

An excellent observability strategy also includes the recognition that this isn’t just an IT concern. Just like when communicating a system’s downtime, a business-level discussion is often called for. Questions arising may include who needs to be aware of an issue, what counts as ‘critical’, and when do you notify clients. Clearly, these are governance as much as technology concerns.

The success of applying your observability strategy rests on installing components such as operational dashboards that centralise data, so that their high-level information is available to all teams. This ensures there is one view of system status. Additional sub-dashboards will enable different teams to drill down into the detail of what they require. Whether in-house or outsourced, there must be capacity for huge amounts of relevant data to flow seamlessly into logs and metrics around the clock.

With observability and cyber security being two sides of the same coin, it is essential to bring these two business missions together. You can move on from security teams relying heavily on logs, traces and events telemetry to detect intrusions, anomalous behaviour, and data access issues, usually working with different data from the ops team. Instead, your observability data will inform your threat detection, and thereby deliver faster alerts, better correlation, and more actionable insight. If or when something serious does occur, your firm is in a far better position to investigate, contain and report. This kind of proactive alignment fosters a culture where security and reliability are not afterthoughts but central pillars of delivery; unfortunately the modern digital world means that these traditional non-functional design considerations need to be treated as 1st class functional requirements and factored into the core build.

If you are building a Security Operations Centre or aligning to operational resilience frameworks such as the EU’s Digital Operational Resilience Act or the FCA’s guidance in this area, high quality observability will be critical.

Steps to implementing strong observability

Implementing powerful observability doesn’t necessarily entail kicking off a mammoth project. Your firm can start small with the following steps.

• Instrument your critical systems first: deploy good structured logs, metrics, and traces.
• Choose tools that allow centralised visibility, even if it’s just dashboards to start with.
• Clearly define your Service Level Objectives and Service Level Agreements, so you can measure what matters.
• Ensure teams know what data exists and how to use it, filling in their gaps via additional training.
• Plan your incident response with observability in mind: define who sees what and when.
• Automate: business rules and the introduction of AI present opportunities for automated reporting and even intervention.

I am positive that having a clearly defined and repeatable process matters more than sourcing the most elaborate tool. The key is to eliminate scrambling for answers when things go south whilst creating a design platform that provides business critical insight.

Trust in your systems

At the end of the day, observability is about engendering trust, in your systems, your processes, and your ability to deliver when it matters. Whether it’s a client wanting to view their pension pot value or your security team striving to stop an attack, the business goal is identical: visibility and confidence.

It’s easy to put this off when things are going well. But if you make observability a priority, when something breaks – and it inevitably will – you will preserve client satisfaction, regulatory compliance and business continuity and prosperity.

Previous Article

Dunstan Thomas Products Contact Us