Lloyds Banking Group API Race Condition Exposes 447,936 Customers' NI Numbers, Account Data in 4-Hour Mobile App Failure

• .What: Software defect in an overnight API update broke transaction data isolation across Lloyds, Halifax, and Bank of Scotland mobile apps for 4 hours and 40 minutes (03:28 - 08:08 GMT).
• .Who: Lloyds Banking Group plc (LSE: LLOY) - UK's largest retail bank and largest mortgage lender. 447,936 customers affected; 114,182 viewed other customers' detailed financial data. Non-LBG customers also affected where payments crossed institutional boundaries.
• .How: Race condition in redesigned API code. When two customers requested transaction data simultaneously - within fractions of a second - the API returned the wrong customer's records. The update was intended to reduce daily API calls from approximately 40 million to 10 million.
• .Data: Transaction amounts, transaction dates, payee names, sort codes, account numbers, National Insurance numbers, and payment reference text fields.
• .Actor: N/A - this was a software engineering failure, not a cyberattack. No threat actor, no exploitation, no malware.
• .Impact: GBP 139,000 in goodwill payments to 3,625 customers (average GBP 38 each). FCA and ICO investigations active. Treasury Committee demanding follow-up reports at one month and six months. Share price declined approximately 1.4% following disclosure.

On the night of March 11-12, 2026, Lloyds Banking Group deployed a software update to the application programming interface (API) serving transaction data to its mobile banking apps - Lloyds, Halifax, and Bank of Scotland.

The update was a performance optimization intended to reduce the volume of daily API calls from approximately 40 million to 10 million. The change was pushed overnight, following standard deployment practices for system updates outside peak hours.

The update introduced a defect in the API code that broke isolation between customer sessions.

Beginning at 03:28 GMT on March 12, when a customer requested to view their current account transactions, their transaction data was potentially visible to another customer who was simultaneously - within small fractions of a second - requesting access to their own transactions.

The defect created a race condition: the API failed to maintain proper session boundaries under concurrent access, serving one customer's data to another.

Between 03:28 and 08:08 GMT - a window of 4 hours and 40 minutes - up to 447,936 customers either saw other people's transactions in their app or had their own transactions displayed to other customers.

Users who viewed their transaction lists could see transaction amounts, dates, and payee names.

Of those 447,936 customers, 114,182 clicked into individual transactions - drilling into the detail view - where they were shown additional sensitive information: sort codes, account numbers, National Insurance numbers, and any text entered in payment reference fields.

In some cases, data visible included information belonging to individuals who are not Lloyds Banking Group customers at all - specifically where a Lloyds customer had made a payment to an account holder at another bank, exposing the recipient's details.

Lloyds identified the defect and deployed a fix by 08:08 GMT. The bank self-reported to the Financial Conduct Authority on the morning of March 12 and notified the Information Commissioner's Office within the required 72-hour window under Article 33 of UK GDPR. No customer was able to carry out unauthorized actions, transfer money, or access another person's account.

Customer balances remained unchanged throughout the incident. The risk of financial fraud has been assessed as very low by the bank.

On March 17, Treasury Committee Chair Dame Meg Hillier wrote to Lloyds CEO Charlie Nunn, describing the incident as "an alarming breach of data confidentiality" and requesting a detailed account of the incident, the number of affected customers, the specific data exposed, the compensation provided, and whether the bank would proactively contact customers who may not yet know their data was shared.

On March 27, the Treasury Committee published Lloyds' response letter, confirming the full scale for the first time: 447,936 customers affected, 114,182 who viewed detailed data, and GBP 139,000 paid to 3,625 customers who had complained.

The Committee has demanded follow-up updates in one month and six months.

There was no threat actor. This was a software engineering failure during a routine system update. No external attacker exploited a vulnerability. No credentials were stolen. No malware was involved.

The data exposure was caused entirely by a race condition in Lloyds' own API code that broke session isolation between concurrent user requests.

The 114,182 customers who viewed other people's detailed data did so inadvertently through normal use of their banking app - they did not seek out or attempt to access other accounts.

The following data types were exposed to other customers during the 4-hour-40-minute window:

• .Transaction amounts and dates - visible to all 447,936 affected customers who viewed their transaction lists
• .Payee names - the names of individuals and organizations customers had transacted with
• .Sort codes - the six-digit bank branch identifiers, visible to the 114,182 who clicked into transaction details
• .Account numbers - the eight-digit current account numbers of other customers
• .National Insurance numbers - where these appeared in transaction data or payment references. NI numbers are the UK's permanent national identity number, issued at age 16 and used for tax (HMRC), benefits (DWP), pensions, NHS records, and increasingly for private-sector identity verification. Unlike passwords or payment card numbers, National Insurance numbers cannot be changed or reissued. Exposure is permanent
• .Payment reference fields - free-text fields where customers and organizations enter reference information alongside transactions, which can contain employer names, invoice numbers, personal identifiers, and other sensitive context
• .Data of non-LBG customers - where a Lloyds Banking Group customer had transacted with an account holder at another bank, the recipient's details (name, sort code, account number) were also visible to unauthorized viewers

The combination of account numbers, sort codes, and National Insurance numbers provides a near-complete identity package for social engineering, phishing, and identity fraud.

An attacker possessing these three data points can pass many common identity verification checks used by UK banks, utilities, and government services.

1. Race condition in API session handling. The core defect was in the API code that serves transaction data to the mobile apps. The redesigned API failed to properly isolate concurrent user sessions.

When two users requested transaction data within fractions of a second, the API returned the wrong customer's records. This is a fundamental concurrency control failure - the type of bug that is caught by proper load testing, concurrency testing, and staged rollout practices.

The API was handling tens of millions of daily requests; concurrent access at sub-second intervals was not an edge case but an inevitability.

2. Performance optimization prioritized over data isolation. The update's purpose was to reduce daily API calls from approximately 40 million to 10 million - a 75% reduction.

This optimization likely involved changes to caching, request batching, or response aggregation that introduced the session isolation failure. When engineering teams optimize for performance, they must verify that isolation boundaries survive the optimization.

In this case, the performance gain was achieved at the cost of data segregation between customers.

3. Insufficient pre-deployment testing for concurrent access.

A race condition that manifests when two users access the same API endpoint within fractions of a second should be detected by standard concurrent load testing - sending thousands of simultaneous requests and verifying that each response contains the correct user's data.

Either this testing was not performed, the test scenarios did not verify response data correctness (only response status codes and latency), or the testing environment did not replicate production traffic patterns at sufficient scale.

4. No canary or staged deployment. The defect affected all three bank brands' mobile apps simultaneously from the moment of deployment.

A canary release - deploying to a small percentage of users first and monitoring for anomalies before expanding - would have limited the exposure to a fraction of the 447,936 affected.

If 1% of users received the update first and the race condition was detected through data integrity monitoring, the exposure could have been contained to approximately 4,500 customers rather than 448,000.

5. No real-time data integrity monitoring. The defect was active for 4 hours and 40 minutes before it was identified and fixed. During that window, the API was serving one customer's data to another on every concurrent request collision.

Automated monitoring that validates whether API responses contain the correct user's data - a basic assertion check on user_id in the response payload matching the authenticated session - would have flagged the anomaly within minutes of deployment, not hours.

6. National Insurance numbers present in transaction data streams. NI numbers appeared in transaction detail views, likely embedded in payment reference fields or associated with transaction metadata.

Financial institutions should treat NI numbers as high-sensitivity data that is masked or excluded from standard transaction display APIs.

The fact that raw NI numbers were served through the same API endpoint as routine transaction data - without additional access controls, masking, or a separate authenticated retrieval path - meant that the race condition exposed the most sensitive identifier in the dataset.

No threat actor IOCs - incident was an engineering failure (software defect / API race condition).

Incident Classification:

• .Software defect in API performance optimization breaking transaction data isolation
• .No external attacker, no exploitation, no malware

Technical Details:

• .Affected: Lloyds, Halifax, Bank of Scotland mobile banking apps
• .Exposure window: 03:28-08:08 GMT March 12, 2026 (4 hours 40 minutes)
• .447,936 customers affected, 114,182 viewed other customers' data

United Kingdom:

• .UK GDPR (retained EU law) Article 5(1)(f) - The integrity and confidentiality principle requires that personal data is processed in a manner ensuring appropriate security. Serving one customer's National Insurance number, account number, and transaction history to another customer through a software defect is a prima facie violation. The data was not accessed by an external attacker - it was exposed to other customers by the bank's own systems.
• .UK GDPR Article 32 - Security of processing. The controller must implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. A race condition in an API serving financial data to 21.5 million mobile app users - deployed without adequate concurrency testing - fails the Article 32 standard. The ICO will assess whether Lloyds' testing, deployment, and monitoring practices were commensurate with the sensitivity of the data processed.
• .UK GDPR Article 33 - Notification to the supervisory authority within 72 hours. Lloyds notified the ICO within the 72-hour window. This obligation appears to have been met.
• .UK GDPR Article 34 - Communication to the data subject. Where a breach is likely to result in a high risk to the rights and freedoms of individuals, the controller must communicate the breach to affected data subjects without undue delay. Exposure of National Insurance numbers - a permanent, irrevocable identifier - constitutes high risk. Lloyds has paid goodwill compensation to 3,625 customers who complained, but 447,936 were affected. Whether Lloyds proactively notified all affected customers or waited for complaints is a key question for the ICO investigation.
• .DPA 2018 Section 170 - Knowingly or recklessly obtaining personal data without the consent of the controller. While this section targets individuals rather than the bank itself, the exposure created a situation where 114,182 customers inadvertently obtained other people's personal data through no action of their own - raising novel questions about data controller liability when the controller's systems force data exposure on third parties.
• .ICO fines - Up to GBP 17.5 million or 4% of annual global turnover, whichever is higher. Lloyds Banking Group's FY2025 total income was GBP 19.4 billion. Four percent of global turnover equals approximately GBP 776 million as the theoretical maximum. Realistic fine exposure, based on ICO enforcement patterns and the TSB precedent, is estimated at GBP 10-50 million.
• .FCA - The Financial Conduct Authority is "actively engaging" with Lloyds. The FCA's operational resilience framework (PS21/3) - fully effective since March 31, 2025 - requires firms to identify important business services, set impact tolerances, and ensure they can remain within those tolerances during disruption. Mobile banking serving 21.5 million users is unambiguously an important business service. A 4-hour-40-minute data exposure affecting 448,000 customers exceeds any reasonable impact tolerance. The FCA and PRA jointly fined TSB GBP 48.65 million (FCA GBP 29.75M, PRA GBP 18.9M) for the 2018 IT migration failure that disrupted services for 5.2 million customers - establishing the enforcement benchmark for UK banking IT failures.
• .FCA Senior Managers and Certification Regime (SM&CR) - Senior managers responsible for IT, operations, and data protection may face individual accountability assessments. The SM&CR requires that senior managers take reasonable steps to prevent regulatory breaches in their areas of responsibility.
• .Consumer Duty (FCA PS22/9) - The FCA's Consumer Duty, effective since July 2023, requires firms to deliver good outcomes for retail customers. Exposing customers' National Insurance numbers and account details to strangers is not a good outcome. The Duty's cross-cutting rules require firms to act in good faith, avoid foreseeable harm, and enable and support customers' financial objectives. The GBP 38 average goodwill payment to those who complained - while 444,311 affected customers received nothing - may itself raise Consumer Duty questions.

European Union:

• .GDPR - Lloyds Banking Group operates across the EU through its subsidiary brands. If EU-resident customers were among the 447,936 affected, GDPR Articles 5(1)(f), 32, 33, and 34 apply. Fines up to EUR 20 million or 4% of annual global turnover.

1. The precise technical nature of the race condition has not been fully disclosed.

Lloyds described a "software defect in the design of the code used to update the API" but has not published a root cause analysis identifying whether the failure was in caching, session management, database connection pooling, response serialization, or another component.

The description of concurrent requests returning wrong data within "fractions of a second" is consistent with several potential root causes, each with different implications for remediation completeness.

2. The 447,936 figure represents customers who "may have had their data exposed" - the exact number whose data was definitively served to another customer has not been confirmed.

Lloyds has not clarified whether this is a worst-case estimate based on all concurrent sessions during the window, or a confirmed count from server-side log analysis.

3. How many of the 114,182 who clicked into detailed transactions actually saw National Insurance numbers versus other sensitive fields has not been disclosed.

NI numbers appear in some but not all transaction detail views, depending on whether the payment reference or associated metadata contained them.

4. Whether Lloyds has proactively notified all 447,936 affected customers - or only the 3,625 who complained and received goodwill payments - has not been confirmed.

5. Whether the "individuals who are not Lloyds Banking Group customers" whose data was also visible have been identified and notified is unknown. These are customers of other banks whose details appeared in Lloyds transaction records.

6. The ICO and FCA investigation outcomes are pending. No enforcement decisions have been announced. The FCA confirmed it is "actively engaging" and the ICO has "made enquiries," but formal investigation conclusions may take 12-24 months based on typical regulatory timelines.

1. Implement automated data integrity assertions on API responses. Every API response serving customer-specific data should include an automated check that the user_id in the response payload matches the authenticated session making the request.

This is a trivial assertion that can be implemented as middleware and would have detected the race condition within seconds of the first incorrect response. When the assertion fails, the API should return an error rather than serving wrong data. Cost: minimal.

Impact: would have prevented the entire incident.

2. Deploy via canary release with data correctness monitoring. The API update should have been released to 1% of users first (approximately 215,000 sessions), with automated monitoring comparing a sample of API responses against expected user identifiers.

If any response serves data belonging to the wrong user, the canary is killed and the deployment rolls back automatically. A 1% canary would have limited exposure to approximately 4,500 customers instead of 447,936.

3. Conduct concurrent load testing with response data validation.

Pre-deployment testing must include sending thousands of simultaneous API requests from different authenticated sessions and verifying that every response contains the correct user's data - not just that the response returned a 200 status code within acceptable latency.

Testing for race conditions requires specifically testing the concurrent access pattern that triggered the failure: two different users hitting the same endpoint within sub-millisecond intervals.

4. Mask or segregate National Insurance numbers from standard transaction APIs. NI numbers should not be served through the same API endpoint and at the same access level as routine transaction data.

Implement data classification tiers: routine transaction data (amounts, dates, payee names) at standard access level; sensitive identifiers (NI numbers, full account numbers) behind additional authentication, rate limiting, and masking (displaying only partial values).

If NI numbers appeared in free-text payment reference fields, implement automated PII detection and redaction on transaction reference data before serving it through the API.

5. Implement session isolation verification as a continuous control. Deploy runtime application self-protection (RASP) or API gateway controls that continuously verify session isolation boundaries.

These controls should monitor for any instance where data associated with one customer session is served to a different session, triggering immediate alerts and circuit breakers.

6. Establish a proactive notification framework for data exposure incidents. When a data exposure is confirmed, notify all affected individuals - not just those who complain.

Paying GBP 139,000 to 3,625 complainants while 444,311 affected customers receive no communication creates both regulatory risk under UK GDPR Article 34 and reputational risk when the full scope is disclosed by Parliament.

UK Parliament Treasury Committee, The Register, TechRadar, Computing.co.uk, Hackread, Cyber Magazine, SecurityWeek, Cybernews, Computer Weekly, Infosecurity Magazine, MoneySavingExpert, FinTech Magazine, Retail Banker International, Scottish Financial News, Scottish Legal News, Signature Litigation, GB News, Bloomberg, Lloyds Banking Group 2025 Annual Results, FCA (Operational Resilience, SM&CR, Consumer Duty, TSB Final Notice), ICO, Simply Wall St, Dataproof, WebProNews