Case Study 01: The Expired Consent That Triggered a GDPR Complaint

Chapter 28 — RegTech APIs, Open Finance, and Interoperability

Background

Bloom Bank is a fictional UK challenger bank, licensed by the PRA and regulated by the FCA, with approximately 800,000 active current account customers. Like all UK banks with more than 70,000 active customers, Bloom is subject to the Open Banking Implementation Entity's standards and must provide a compliant Open Banking API.

In April 2024, Bloom entered into a partnership with Pennify, a regulated fintech authorized by the FCA as an Account Information Service Provider (AISP). Pennify's app helps users build a monthly spending budget by aggregating their transaction data from multiple bank accounts into a single dashboard. The partnership was commercially attractive: Bloom customers would see Pennify recommended in the Bloom app, and Pennify would benefit from direct promotion to Bloom's customer base.

The integration was technically straightforward. Pennify registered with Bloom's API sandbox in February 2024, completed integration testing in March, and went live with Bloom customers on April 15, 2024. By the end of April, 12,400 Bloom customers had connected their accounts to Pennify.

The Incident

On June 3, 2024, a Bloom customer — call her Ms. Archer — used the Bloom mobile app to review her connected third-party services. She saw Pennify listed as having active access to her account data. She did not recognize the connection and was not using Pennify actively. She clicked "Revoke" and confirmed that she wanted to end Pennify's access to her Bloom account data.

The revocation was processed by Bloom's consent management system at 14:37 on June 3. The consent object was updated to status REVOKED. From that moment, Bloom's API was configured to return HTTP 403 for any request from Pennify referencing Ms. Archer's consent ID.

What Bloom did not know — and could not know without monitoring for it — was that Pennify had a bug in its consent state management system. When Bloom's API returned HTTP 403 to Pennify's requests, Pennify's system categorized the response as a temporary API error rather than a permanent authorization failure. The system continued retrying the failed call every six hours, indefinitely, rather than recognizing the 403 as a signal to stop.

For six weeks — between June 3 and July 16 — Pennify's system made 168 API calls to Bloom's Open Banking endpoint referencing Ms. Archer's revoked consent. Bloom's API correctly refused all 168 requests. No customer data was returned. But Ms. Archer did not know that. She had been told in the Bloom app that she had revoked access and assumed the connection was terminated.

On July 17, 2024, Ms. Archer discovered Pennify on her phone — she had apparently downloaded and briefly used the app in March before forgetting about it. She noticed that the app still showed her account data. Alarmed, she called Bloom's customer service line, then filed a formal complaint with Bloom, and then lodged a complaint with the ICO (Information Commissioner's Office) alleging that Bloom had continued sharing her financial data with Pennify after she revoked consent.

What Actually Happened vs. What Ms. Archer Believed

The factual situation is somewhat more nuanced than Ms. Archer's complaint suggests. Bloom's API had correctly refused all 168 post-revocation requests from Pennify — no data left Bloom after June 3. The data Ms. Archer saw in the Pennify app was cached data that Pennify had obtained before the revocation. However, the persistence of that data in the Pennify app, combined with Pennify's continued attempt to contact Bloom's API, created a reasonable belief on Ms. Archer's part that data sharing was ongoing.

The GDPR issue is therefore multi-layered. From Bloom's perspective, the question is whether it fulfilled its data controller obligations when it processed the consent revocation. From Pennify's perspective, the question is whether its continued attempts to access data after a 403 response, and its continued display of cached data in the app, constitutes a GDPR violation — most likely a failure to act on the withdrawal of consent (Article 7(3)) and a possible unauthorized processing of personal data.

Liability Allocation: Bloom or Pennify?

Under PSD2 and the UK Open Banking framework, the liability analysis distinguishes clearly between the ASPSP's technical obligations and the AISP's consent management obligations.

Bloom, as the ASPSP, is obligated to enforce consent at the API gateway. On this measure, Bloom performed correctly: it implemented the revocation promptly, updated the consent status, and refused all subsequent unauthorized requests. Bloom's API returned the correct response code (403) to every post-revocation call. If the ICO investigation focuses on Bloom's API-level conduct, Bloom is in a defensible position.

However, the ICO may take a broader view of Bloom's obligations as an ASPSP with a contractual and regulatory relationship with Pennify. The question the ICO may ask is: did Bloom have adequate monitoring to detect that a registered TPP was persistently calling its API with a revoked consent? Bloom's access logs contain 168 denied requests from Pennify referencing Ms. Archer's revoked consent over six weeks. If Bloom's monitoring had detected this pattern within days of the revocation, it could have contacted Pennify to investigate the bug, potentially prompting faster remediation of the Pennify-side issue and providing Ms. Archer with a clearer explanation.

Pennify's liability exposure is more direct. Under GDPR, a data controller who receives a withdrawal of consent must cease processing as soon as reasonably practicable. The mechanism by which Ms. Archer revoked consent (through the Bloom app) was the mechanism specified for Open Banking consent management. Pennify's failure to correctly handle the 403 response — the signal from Bloom's API that authorization had been withdrawn — means its system continued to treat Ms. Archer's data as available for processing even after authorization was revoked. The continued display of cached data in the app, without any indication that the connection had been terminated, compounded the issue from a transparency perspective.

What Contractual Provisions Should Have Been in Place

The Bloom-Pennify partnership agreement — the contract governing their Open Banking relationship — should have included several provisions that would have clarified both liability and remediation obligations.

First, a data access agreement specifying that Pennify must implement prompt and accurate consent state management, treating a 403 response from Bloom's API as a definitive revocation signal (not a temporary error) and immediately ceasing use of any cached data related to a revoked consent. Second, a data retention clause specifying that Pennify must delete customer data within a defined period (typically 24 to 72 hours) of consent revocation — preventing the indefinite retention and display of cached data. Third, an incident notification obligation requiring Pennify to notify Bloom within 24 hours of detecting any system behavior that may constitute unauthorized data access or retention. Fourth, an audit right allowing Bloom to request evidence of Pennify's consent state management and data deletion practices. Fifth, a remediation timeline requiring Pennify to fix identified consent management bugs within a specified number of business days.

None of these provisions prevented a technical bug — but they would have provided Bloom with contractual grounds to demand rapid remediation when the pattern was detected, and would have clarified to the ICO that Bloom had taken reasonable steps to govern Pennify's data handling practices.

How Bloom Should Have Detected the Issue Earlier

Bloom's API audit log contained the evidence of the post-revocation access attempts from the moment they began. The compliance monitoring failure was not in the logging — it was in the alerting. Bloom did not have an automated alert configured for the pattern: "persistent 403 responses to a specific TPP for a specific consent that is in REVOKED status." This is an operationally straightforward alert to implement: any TPP making more than five requests referencing a revoked consent should trigger an automated alert to the compliance team for investigation.

The monitoring gap that allowed 168 denied requests to accumulate over six weeks without triggering a review is a compliance operations failure, even though the data protection outcome (no data actually served) was sound.

Resolution

After investigation, the ICO found that Bloom's handling of the consent revocation was technically compliant — no data had been shared after revocation — but issued an informal recommendation that Bloom implement automated monitoring for persistent post-revocation API access attempts by registered TPPs.

Pennify received a formal reprimand from the ICO for its failure to process the consent withdrawal correctly, and was required to demonstrate remediation of its consent state management system. Pennify also issued an apology to affected customers and deleted all cached data for revoked consents.

Bloom updated its TPP partnership agreement template to include the contractual provisions described above, and deployed the automated monitoring alert described.

Discussion Questions

1. Bloom's API correctly refused all 168 post-revocation requests. Does this mean Bloom has no compliance exposure in the ICO investigation? Justify your answer with reference to Bloom's obligations as an ASPSP and as a data controller.

2. Pennify's bug caused its system to interpret HTTP 403 responses as temporary errors rather than authorization failures. From a GDPR perspective, what specific provisions did Pennify likely breach through this behavior, and why?

3. Design a monitoring alert system for Bloom's Open Banking API that would detect problematic post-revocation access patterns within 24 hours. What thresholds would you set, and what would the alert workflow look like?

4. Draft the three most important data governance provisions you would include in a TPP partnership agreement to prevent the scenario described in this case study. For each provision, explain the compliance risk it mitigates.

5. Ms. Archer saw that her data was still visible in the Pennify app after she revoked consent in the Bloom app. How should Pennify have designed its app to communicate consent status to customers in real time? What GDPR principles underpin your answer?