Case Study 39.1: Maya and the FCA's Direct Data Request — When SupTech Arrived at Verdant

Background

It arrived as a letter, which Maya found slightly incongruous given the subject matter.

The FCA's correspondence, received in the second week of January, was formally worded in the way that all FCA correspondence was formally worded — the careful, measured language of a regulator communicating with a supervised firm. But the content was unlike anything Maya had received in eighteen months as CCO of Verdant Bank. The FCA was inviting Verdant to participate in a supervisory technology pilot program. Five UK challenger banks had been selected. The pilot would involve the FCA establishing API-based direct access to a defined subset of Verdant's transaction monitoring data. The implementation window was 90 days.

Verdant Bank was three years old. It had 310,000 customers, a FCA banking licence obtained eighteen months before Maya's arrival, and a compliance program that Maya had spent her first year building from what she diplomatically described to the board as "near-scratch." The bank's technology was modern — a cloud-native core banking system, a purpose-built mobile app, and an AML platform that had been deployed fourteen months earlier. The compliance team had grown from three people when Maya joined to eleven.

The FCA letter was an opportunity, a regulatory relationship investment, and a technical challenge simultaneously. Maya called her technology director before she had finished reading it.

"We're going to participate," she said. "But I need to know what we're actually agreeing to before I confirm that."

The Questions Maya Needed to Answer

The first two weeks after the letter arrived were a structured investigation. Maya was clear about what she needed to understand before the 90-day clock started.

What data would the FCA access? The letter described "transaction monitoring alert data and underlying transaction records for the period under review." This was broad. Maya needed to understand exactly what fields were in scope, what the retention architecture looked like, and whether there were data categories within "transaction monitoring alert data" that raised customer protection concerns beyond the scope that the FCA's legal basis would cover.

What was the legal basis? The FCA's powers under the Financial Services and Markets Act 2000 include broad information-gathering powers under Section 165. The pilot operated under these powers. But the nature of API-based direct access — as opposed to a specific information request with a defined scope — raised questions about whether the ongoing access contemplated by the pilot fell within the same legal framework as a one-time request. Maya engaged Verdant's external legal counsel on this question.

Did this constitute a regulatory visit? Under FSMA and FCA rules, regulated firms have specific rights and obligations in relation to supervisory visits. Whether an API-based data connection constituted a "visit" in the relevant legal sense — and whether Verdant had corresponding rights to limit scope, request advance notice, or challenge specific queries — was a question Maya wanted answered before implementation.

What were the customer data protection implications? Verdant's customers had not consented to their transaction data being accessed by the FCA via a direct API connection. Under GDPR and the UK's Data Protection Act 2018, processing of personal data requires a lawful basis. For regulatory compliance purposes, the lawful basis is typically legitimate interest or legal obligation. But the ongoing, direct nature of API access — as opposed to a defined data transfer for a specific purpose — raised questions about data minimization, purpose limitation, and whether customers should be informed.

What did the architecture actually support? Maya's most important early discovery was that this question had no clean answer.

What the Architecture Revealed

The 90-day implementation window was not generous. Maya asked her technology director to conduct a rapid assessment of what the FCA's proposed API access would actually require from Verdant's systems.

The results, delivered at the end of week two, were not what Maya had expected. Verdant's core banking system was modern and well-documented. Its transaction data was cleanly structured and accessible. The AML platform's alert data was less clean.

The AML platform had been configured in a hurry — deployed quickly ahead of a critical FCA supervisory visit fourteen months earlier. The alert data was stored in a proprietary format optimized for the platform's own reporting functions. It was not structured in a way that could be easily exposed via a standardized API without a significant translation layer. The customer reference data that linked alert records to customer profiles was stored in a separate system with its own data model. Joining the two datasets — which any meaningful API exposure of alert data would require — needed a process that did not yet exist.

"We thought we had clean data," Maya said, in the debrief with her technology director and her head of AML. "We have clean data in each system. We have a mess at the joins."

This was a critical discovery, for reasons that went beyond the pilot. If the FCA were to query Verdant's transaction monitoring data in near-real time, the gaps in data architecture would not be isolated problems managed in a report preparation process. They would be visible supervisory findings. The pilot had revealed a data governance vulnerability that the reporting cycle had previously concealed.

The decision tree that followed was uncomfortable but necessary. Maya had three options:

Option 1: Decline to participate. Declining was within Verdant's rights. The pilot was described as voluntary. But declining a regulatory collaboration request, as Maya explained to the CEO and CFO, was itself a regulatory signal. The FCA had selected five challenger banks. Being the one that declined would not be a neutral choice.

Option 2: Participate and manage the gap. Proceed with the pilot using the best API access the current architecture supported, acknowledging to the FCA the known limitations and presenting a remediation plan. This was transparent and manageable, but it required a difficult conversation with the regulator about data architecture weaknesses that Maya would have preferred to remediate before they were visible.

Option 3: Remediate first, then implement. Request a 30-day extension on the implementation timeline to build the translation layer and resolve the data join problem, then implement a cleaner API connection. This would demonstrate capability while addressing the gap, but the 30-day extension request would itself require explaining why the extension was needed.

Maya chose a version of Option 2 combined with Option 3: she requested a 45-day preliminary phase focused on architecture assessment and remediation, with full API implementation in the remaining 45 days. In the request, she was explicit about what the assessment had found.

"I told them what we found," she said later. "It was tempting to ask for the extension without explaining why. But if we're building a regulatory relationship based on what the FCA will eventually see for themselves, honesty about our data architecture is a better investment than a temporary shield."

Implementation: The 45+45 Split

The preliminary phase was the harder work. The technology team built a dedicated data integration layer — an API gateway that joined transaction records to alert data using customer reference IDs, applied data minimization logic to limit the fields exposed to those within the FCA's stated scope, and produced a standardized output conforming to the common data schema the FCA had provided to all five pilot participants.

The data protection workstream ran in parallel. Verdant's Data Protection Officer assessed the lawful basis for the data processing and concluded that regulatory compliance under FSMA Section 165 provided the necessary legal basis. She recommended — and Maya agreed — that Verdant should update its privacy notice to acknowledge that transaction data may be processed for regulatory supervisory purposes. This was a modest disclosure addition that addressed the transparency dimension without implying that customer consent was required for regulatory compliance processing.

Legal counsel's assessment of the "regulatory visit" question produced a nuanced answer: ongoing API access was sufficiently different from a physical visit that the specific procedural rights attending supervisory visits did not directly apply. However, Verdant retained the right to raise scope concerns and to seek clarification of any FCA query that appeared to exceed the defined scope of the pilot. Maya established a process for monitoring FCA queries and escalating any that appeared outside scope — a process that, in the event, was never triggered.

Implementation completed on day 87 — three days ahead of the 90-day deadline. The API connection was stable. The data quality, in the remediated architecture, was materially better than it had been at the start of the process.

What the Pilot Revealed

Six months after the pilot concluded, Maya presented findings to Verdant's Risk Committee.

The FCA's direct data access had generated one supervisory inquiry during the pilot — a question about an alert category that showed a lower investigation completion rate than the FCA's analysis suggested was typical. Maya's team investigated and found that the issue was a workflow configuration problem in the AML platform, not a substantive compliance failure. The configuration was corrected.

"That's the honest outcome," Maya told the Risk Committee. "The FCA found something that we hadn't found ourselves. Because they were looking at our data in a way that we weren't. That is, from a certain angle, the point of SupTech."

More significantly, the pilot had exposed something that Maya regarded as the most important finding: Verdant had been managing compliance reporting as a periodic exercise, with data quality assurance concentrated around reporting deadlines. The direct data access model required continuous data quality assurance. The processes that governed data quality between reporting periods were not adequate for a supervisory environment where the regulator's view was always current.

The architectural remediation done during the implementation phase — the data integration layer, the standardized API gateway, the improved join logic — had cost more than budgeted but produced a data architecture materially better than the one Verdant had operated before the pilot. That improvement benefited internal analytics and operational reporting, not just regulatory compliance.

Maya's summary to the Risk Committee:

"SupTech arrived at Verdant, and we were more ready than we thought in some ways and less ready than we thought in others. The technology readiness was the smaller gap. The data governance readiness — the question of whether our data would stand up to a view we didn't control — was the real test. We passed it. But not as comfortably as I would have liked."

She paused.

"The lesson for next time — and there will be a next time, because direct data access is where the FCA is heading — is to ask that question now, not when the letter arrives. What would the FCA see if they looked at our data today? If you know the answer, you're ready. If you don't, you have work to do."

Discussion Questions

The chapter argues that SupTech direct data access changes the nature of compliance from a periodic reporting exercise to a continuous state. How does Verdant's experience in this case study illustrate that argument? What specific operational changes would a compliance program need to make to shift from periodic to continuous compliance?
Maya chose to be transparent with the FCA about Verdant's data architecture gaps when requesting the implementation extension. What were the risks of that transparency? What would have been the risks of the alternative — requesting the extension without disclosing why?
The data architecture remediation done for the pilot produced improvements that benefited internal operations as well as regulatory compliance. What does this suggest about how institutions should frame the cost-benefit calculation for data governance investment?
The FCA's supervisory inquiry identified a workflow configuration issue that Verdant had not found internally. What does this imply about the relative value of internal compliance monitoring vs. external regulatory scrutiny? Should compliance professionals view SupTech-driven regulatory visibility as a threat or a quality control mechanism?

Case Study 39.1 complete.