Why Australia’s banks need a new standard of observability for their systems and their AI

Why Australia’s banks need a new standard of observability for their systems and their AI

By Paul Davis (pictured), Area Vice President Sales, APAC at ClickHouse

 

As AI-generated fraud hits one of Australia’s largest banks, the ability to observe, trace, and audit what’s happening across systems and AI models is becoming the new baseline for operational resilience.

In late February, one of the big four banks revealed it had reported itself to police and ASIC over approximately $1 billion in suspected fraudulent home loans, some obtained using AI-generated documents, including forged income statements. The investigation, triggered by whistleblowers, has since expanded: where one of the other big four banks faced a similar $150 million fraud, while the other two have contacted NSW Police about loan-related issues of their own.

The scale is striking, but the mechanism is what matters. AI didn’t just help criminals commit fraud faster. It made it harder to distinguish fraud from legitimate activity. Forged documents looked authentic. Application volumes appeared normal. The signals were there, but the systems watching for them weren’t built to catch AI-quality forgeries at speed.

This is the new reality for Australia’s banks. AI is simultaneously the tool criminals use to attack institutions, and the tool institutions deploy to defend themselves, for fraud detection, loan decisioning, customer interactions, and, increasingly, for operational decision-making. The gap between deploying AI and being able to observe, trace, and audit what it is doing is where the risk lies.

Australia’s prudential regulator has been clear about the direction of travel. Resilience isn’t just about surviving outages. It’s about demonstrating to regulators, boards, and customers that you understand what’s happening within your own systems. That includes AI systems. CPS 230 has codified operational resilience as a regulatory expectation.

Underpinning all of it is observability.

 

What observability means in banking today, and where it falls short

Most Australian banks already invest in some form of operational monitoring. System uptime dashboards, transaction throughput alerts, and basic log aggregation. The fundamentals are largely in place for known failure modes.

The problem is what they can’t see.

Modern banking infrastructure is layered and interconnected: core banking systems, cloud providers, payment rails, fintech integrations, mobile apps, and now AI models that make or inform decisions at multiple points in the chain. The number of components involved in end-to-end transaction execution has increased significantly in recent years as fintech solutions have been integrated alongside core systems. The dependencies and interdependencies may not be fully understood until something goes wrong.

When an outage hits or a fraud pattern emerges, the ability to quickly trace the root cause across this entire stack, ideally before customers feel the impact, is what separates institutions that meet modern resilience standards from those that don’t. Some banks no longer have windows for planned maintenance downtime. Unplanned outages with customer-facing impacts are even less tolerable.

This is what leading banks describe as the challenge of “unknown unknowns”: emergent, unpredictable failure modes they didn’t anticipate and therefore couldn’t monitor preemptively.

 

The cost problem nobody talks about

Here’s the uncomfortable truth: most banks know their observability tooling isn’t good enough. They also know they’re overpaying for what they have.

Enterprise observability platforms built a decade ago charge per gigabyte ingested, with retention windows that force teams to choose between cost and visibility. It’s common to see institutions capping log retention at 14 days, not because 14 days is sufficient, but because storing more is economically unjustifiable on current tooling. That means when an incident occurs, and the root cause lies in data older than two weeks, it’s gone.

This isn’t a technology limitation. It’s an economics problem. And it’s one that matters to regulators: CPS 230 expects institutions to maintain operational resilience over sustained periods, not just the last fortnight.

The economics shift when the underlying database is built for analytical workloads at scale. Columnar storage, high compression ratios, and efficient query execution change the cost-per-TB equation dramatically.

Institutions like Deutsche Bank and Capital One have adopted ClickHouse for exactly this reason. Capital One reported an 80% improvement in query response times while cutting infrastructure costs by 50%. SEON’s fraud prevention and AML platform achieved 80% faster processing after moving to ClickHouse. ProcessOut cut payment analytics costs by two-thirds while bringing transaction latency down from minutes to seconds. Opensee uses it to power risk analytics across global Tier 1 banks

The point isn’t to replace existing platforms. It’s to add an engine underneath them that makes retention affordable, queries fast, and cost predictable, so that when the next incident happens, or the next regulator asks a question, the data is there.

 

The second observability gap: your AI systems

The highlighted case exposed something that extends well beyond one bank’s loan book. As institutions deploy AI for fraud detection, credit decisioning, and document verification, a new category of observability becomes essential: the ability to trace what an AI system did, why it did it, and what data informed the decision. This is not about server uptime or query latency. It’s about being able to answer the question a regulator, auditor, or board member will inevitably ask: “Show me the trail.” Today, most AI deployments in financial services operate without that traceability. Models are called, responses are returned, decisions are made, but the chain of reasoning, the prompts used, and the confidence levels aren’t captured in a way that’s auditable after the fact. This is the “shadow AI” problem that’s keeping chief data officers awake.

Langfuse, an open-source LLM observability platform now part of ClickHouse, addresses this directly. It captures the full lifecycle of every AI interaction: prompts, responses, tool calls, retrieval steps, latency, cost, and the relationships between them. This creates the audit trail that compliance teams need. Built on ClickHouse as its core data store, it’s designed to handle the high-throughput ingestion and fast analytical queries generated by production AI workloads.

For banks, this means two things. First, it provides the governance infrastructure that enables compliance teams to say “yes” to AI deployments rather than indefinitely blocking them. Second, it creates the foundation for catching the kinds of anomalies that human reviewers would miss, the same kinds of patterns that the bank’s whistleblowers in this example.

The institutions that get this right won’t just be meeting regulatory expectations. They’ll be the ones who can deploy AI confidently, knowing they can explain every decision the system makes.

 

Where improved data can take resilience

Observability, in this context, means the ability to see what is happening across every layer of a bank’s technology stack in enough detail to diagnose problems that weren’t anticipated in advance. During an outage, that means pinpointing the root cause quickly, ideally before customers feel the impact. In some banks, engineering teams are no longer afforded downtime, even for planned maintenance. Unplanned outages are even less tolerable.

This has become harder as banking infrastructure has grown more complex. Fintech solutions bolted onto core systems, cloud providers, payment rails, and mobile apps: the dependencies and interdependencies involved in end-to-end transaction execution may not be fully understood until something breaks. Leading banks describe this as the challenge of debugging “unknown unknowns,” emergent failure modes they couldn’t pre-emptively monitor because they didn’t know to look for them. Meeting that challenge is fundamentally an analytics problem, which makes the underlying database the critical architectural decision.

 

Where this leaves Australian banks

The highlighted case will accelerate a shift that was already underway. Regulators will ask harder questions. Boards will demand more visibility. And the institutions that can demonstrate, not just claim, that they understand what’s happening across their systems, including their AI systems, will be the ones that earn continued trust.

That requires two things most banks don’t yet have in place. First, operational observability that covers the full stack at a cost that allows months or years of retention, not days. Second, AI observability that gives compliance and risk teams a complete, auditable trail of every model interaction.

The technology exists. The question is whether institutions will treat observability as the strategic infrastructure investment it is, or continue treating it as a cost line to be minimised, until the next billion-dollar incident forces the conversation.