API Security in Financial Services: The Cost of Getting It Wrong

Two incidents from early 2026 tell the same story from opposite ends of the financial world. One’s the biggest management consulting company in the world. Their internal AI platform was compromised by an autonomous agent in under 2 hours. The other one is one of the UK's largest retail banks. Their customer data appeared in the wrong accounts on the wrong screens, an event serious enough to trigger a formal parliamentary inquiry.

Neither McKinsey nor Lloyds Bank lacked investment in technology. They were running enterprise API infrastructure, but lacked the intelligence layer that would have caught what their gateways missed.

API security in financial services has moved past the point where perimeter defenses and traffic management are sufficient. The attack surface has changed. The risk profile has changed. What hasn't changed is how most institutions monitor their APIs: at the traffic level, not at the intelligence level.

API security in financial services means having complete, request-level visibility into what data is being exchanged, with whom, and whether that exchange matches what was intended, not just whether traffic is flowing.

The API Attack Surface Financial Institutions Underestimate

Financial institutions run more APIs than most sectors.

Some of them are required by PSD2 or core banking modernization programs. On top of that, financial institutions add their own that deal with AI-powered internal tools (such as McKinsey’s Lilli). The API estate is massive, constantly changing, and almost never under (full) control and visibility.

Treblle's analysis of over one billion API requests per month across its platform found that a substantial share of production APIs carry no authentication at all, and that security misconfiguration accounts for the majority of exploitable API vulnerabilities. Nothing fancy or exotic, just plain old basic security vulnerabilities….that shouldn’t happen in 2026.

In financial services, where a single API response may include account numbers, transaction histories, and PII, a misconfigured endpoint is not a minor deviation from best practice. It's an open data breach waiting to be discovered.

The two cases below show what that discovery looks like in practice.

McKinsey's Lilli: 22 Unauthenticated Endpoints and 46 Million Messages

In late February 2026, the security research group CodeWall set an autonomous AI agent against Lilli, McKinsey's internal AI platform used by tens of thousands of consultants globally. The agent found 22 unauthenticated API endpoints. Within two hours, it had full read and write access.

The database?

• 46.5 million chat messages covering strategy discussions, merger and acquisition planning, and client engagements. All in plaintext.

• 728,000 files, 57,000 user accounts, and 95 system prompts controlling how Lilli responded to its users.

The technical mechanism was SQL injection, one of the oldest vulnerability classes. The JSON keys were concatenated directly into SQL queries. The values themselves were safely parameterized. It was a narrow but consequential mistake: standard automated scanning tools typically check values, not keys, so this would have passed routine security checks.

The writable system prompts are the details that should concern CIOs and security architects most. A traditional breach steals data. An AI platform breach, like Lilli’s case, corrupts the advice that thousands of consultants receive, leaving no trace in application logs.

The consultants get wrong information from their internal (and trusted) tool about strategy, mergers, acquisitions, and client engagements, without even realizing it’s wrong.

McKinsey's security team received CodeWall's disclosure email on March 1. The CISO acknowledged it the next day and immediately patched the unauthenticated endpoints. Shortly after, McKinsey stated publicly that there was no evidence that client data had been accessed by unauthorized parties.

Lloyds Banking Group: When API Misconfiguration Becomes a Parliamentary Matter

On March 12th 2026, Lloyds Banking Group (LBG) experienced an IT incident that caused customer data to appear across multiple subsidiaries in sessions where it should not have been present. Account information reached customers who had no entitlement to it. The incident progressed from press reporting to a formal parliamentary inquiry by the UK Treasury Committee.

Treblle's engineering team, analyzing the publicly available information, identified the API layer as the most probable root cause. The data appearing in the wrong session context affecting multiple subsidiaries simultaneously is consistent with an API response misconfiguration rather than a database or application logic failure. A configuration change, deployed to an API serving multiple downstream services, produces exactly this kind of cross-subsidiary blast radius.

LBG was running Google Apigee as its API gateway at the time of the incident. Apigee is a well-regarded infrastructure that is in place and operational on March 12th. But it’s not designed to catch this. It did not surface the issue, did not alert the engineering team, and could not answer the questions the Treasury Committee subsequently asked: how many customers were affected, what data became visible to whom, and whether any of those customers subsequently became victims of financial crime. Apigee did 0/6 on those questions because they’re a gateway.

A gateway cannot answer those questions because a gateway is not designed to. It routes and manages traffic. Correlating a specific response payload with a specific authenticated customer, timestamping that correlation, and making it queryable weeks later, that requires a different layer entirely.

It’s like comparing a spoon and a fork. Sure, they’re both utensils and used for food, but try eating a soup with a fork and see what happens.

That gap between infrastructure and intelligence is what Treblle addresses. With request and response payload capture across 40+ data points per transaction, Treblle can answer the Treasury Committee's exact questions in minutes: filter all requests within the affected window, identify every customer who received a response containing data that wasn't theirs, and produce an exportable audit record showing what each customer saw and when. Without that record, the investigation is reconstruction from inference. With it, it's a query.

A Gateway Moves Traffic. It Doesn't Understand It.

The comparison between infrastructure and intelligence is worth making precisely because organizations often treat their API gateway as their API security layer. The gateway enforces rate limiting, handles authentication tokens at the perimeter, and routes requests to the right service. What it cannot do is understand the semantic content of what's being returned, detect when a response pattern shifts in ways that shouldn't be possible given the requesting user's context, or tell you — six weeks later, with a regulator on the phone — exactly which customers received which data.

This is not a criticism of gateway tooling. Apigee, Kong, AWS API Gateway; these do what they are designed to do. The problem is when organizations treat traffic management as equivalent to API intelligence, and discover the gap only when a parliamentary committee or a security researcher points it out.

It’s not just these two. There was another major API breach in Odido, in the Netherlands. Hackers from the ShinyHunters group utilized a "multi-stage" social engineering attack to gain unauthorized access to a Salesforce customer contact system. Reports indicate that the attackers exploited public-facing application vulnerabilities and misused valid credentials to covertly "scrape" the database for approximately 48 hours.

Security architects building API governance programs in financial services need to account for three distinct capabilities:

• traffic control (the gateway layer),

• threat detection and response (which requires payload-level analysis, not just header inspection), and

• audit and forensics (which requires a complete, queryable history of every request tied to the authenticated customer who made it).

Most organizations have the first. Few have all three.

What API Security in Financial Services Actually Requires

The McKinsey and Lloyd incidents are instructive because they represent different failure modes stemming from the same underlying gap. McKinsey's exposure came from unauthenticated endpoints that should have been authenticated — a governance and visibility problem that continuous scanning would have surfaced before CodeWall's agent did. Lloyds' exposure came from a misconfiguration that changed response behavior in ways no alert was configured to catch — a detection problem requiring anomaly identification at the response payload level.

Both are solvable with the same capability: request-level intelligence that captures what each API call returns, ties it to the authenticated user who made it, and monitors for deviations from expected patterns in real time.

Treblle captures 40+ data points per API request, runs every request against more than 20 security threat categories, and flags anomalies with alerts to the responsible technical owner. For organizations operating under DORA, PSD2, or FCA oversight, Treblle also provides the governance layer: security scoring, compliance posture, and the audit trail that regulators require and that post-incident investigations depend on.

The question for CIOs, compliance officers, and solution architects is not whether their gateway is enterprise-grade. It almost certainly is. The question is what happens in the space between the gateway processing a request and the regulator asking what that request returned.

If you want to know what your API estate is actually returning in production, Treblle surfaces that picture without requiring changes to your existing gateway infrastructure. It connects directly alongside tools like Apigee and captures the intelligence layer your gateway wasn't built to provide.

Frequently Asked Questions