Case Study 02: Cornerstone's API Integration Program — Connecting 12 Compliance Systems

Chapter 28 — RegTech APIs, Open Finance, and Interoperability

Background

Cornerstone Financial Group is a fictional mid-sized UK financial institution offering retail banking, wealth management, and commercial lending services. Cornerstone has approximately £18 billion in assets and 340,000 retail customers. It is regulated by both the PRA (prudential) and the FCA (conduct), and holds several subsidiary authorizations for its wealth management and payment services activities.

Over the course of twelve years of acquisition and organic growth, Cornerstone has accumulated twelve distinct compliance point-solutions: a customer onboarding and KYC platform (acquired with a retail bank purchase in 2019), a transaction monitoring system for AML (implemented in 2015, upgraded in 2021), a sanctions screening engine (vendor-hosted, integration by flat file), an adverse media monitoring tool (added in 2022), a trade surveillance platform for the wealth management subsidiary, a regulatory reporting system used for CASS client money reporting, a COREP/FINREP regulatory capital reporting tool, a model risk management platform, a conduct monitoring system (communications surveillance for the wealth management advisers), a case management system for SAR and complaint management, a GDPR privacy management platform, and a third-party risk management system tracking vendor relationships.

None of these twelve systems were acquired with integration in mind. They communicate, where they communicate at all, through a combination of manual data exports, scheduled flat-file transfers, and ad hoc scripts maintained by individual team members. The AML monitoring system exports a daily CSV of open alerts; a compliance analyst imports this into the case management system every morning. The KYC platform exports a weekly data dump; an IT team member runs a Python script to reconcile it with the sanctions screening engine. The GDPR platform has no connection to the KYC platform, meaning data subject access requests must be handled by manually querying five separate systems.

In January 2025, Cornerstone's newly hired Chief Technology Officer proposed an API-first integration strategy. The proposal was straightforward: rather than continuing to maintain bespoke point-to-point connections (or failing to maintain them at all), Cornerstone would build an API integration layer — an API gateway and integration platform — through which all twelve compliance systems would communicate. Data would flow through APIs rather than flat files. Events in one system would trigger workflows in others in near-real time. The integration platform would maintain a complete log of all inter-system data flows.

The proposal landed on the desk of Cornerstone's Chief Compliance Officer, who passed it to the compliance architecture team with one question: "How do we govern this?"

The Compliance Governance Challenge

The CTO's proposal identified 47 distinct data exchange flows that would need to be implemented as API connections across the twelve systems. Some of these flows are simple: the AML system sends a new alert object to the case management system when a suspicious transaction is flagged. Others are more complex: the KYC platform must query the sanctions screening engine in real time during customer onboarding, receive a risk score, and write the result to both the customer's KYC record and the customer risk rating platform, all within the time window of the onboarding journey.

The compliance team identified four governance challenges that the API integration program must address before the CTO's plan could be approved.

Challenge 1: What Data Flows Through Each API, and Is the Flow Authorized?

For each of the 47 proposed API connections, the compliance team needed to identify: what personal data flows through this connection? Is the data transfer permitted under the contracts with the relevant software vendors (which typically impose data use restrictions)? Is there a legitimate processing basis under GDPR for the data sharing? Is the data minimized to what is necessary for the receiving system's function?

Several of the proposed connections raised immediate questions. The proposed integration between the communications surveillance system (which captures and analyses wealth management adviser communications for conduct monitoring) and the AML case management system would create a data flow of potentially highly sensitive customer communication data into the AML team's view. The compliance team questioned whether AML staff had a need to see raw communication content, or whether the conduct monitoring system should only export anonymized alert metadata. The proposed connection between the model risk management platform and the regulatory reporting system would route model output data through the API layer — but the model risk platform contained documentation of model limitations that might be sensitive if disclosed outside Cornerstone.

Challenge 2: Are Any of These API Connections "Outsourcing" Under EBA Guidelines?

The EBA Guidelines on Outsourcing (EBA/GL/2019/02) and the related EBA Guidelines on ICT and Security Risk Management require firms to assess whether arrangements involving third parties (or, in the case of group entities, intra-group arrangements) constitute "outsourcing" — material reliance on a third party for functions the firm could conduct itself. If an arrangement constitutes outsourcing, it triggers a substantial compliance framework: written outsourcing agreements, exit strategies, access rights for the firm and its regulators, and notification to the FCA.

Most of Cornerstone's twelve compliance systems are hosted by third-party vendors. When Cornerstone's AML monitoring system calls the vendor-hosted sanctions screening engine's API to check a customer's name in real time, is Cornerstone outsourcing its sanctions screening function to the vendor? The answer is likely yes — the FCA and PRA's outsourcing frameworks would treat real-time reliance on a vendor-hosted screening engine as a material outsourcing of the sanctions screening function. This does not make the arrangement impermissible, but it means Cornerstone's outsourcing register, outsourcing agreements, and concentration risk assessments must reflect the arrangement correctly.

For the internal integrations — where two Cornerstone-owned platforms exchange data — the outsourcing analysis is different. A data flow between Cornerstone's internally-owned KYC platform and Cornerstone's internally-owned case management system is not outsourcing in the regulatory sense, even if both systems happen to run on cloud infrastructure. The compliance team must work through the 47 connections to categorize each as: internal (no outsourcing implications), vendor-to-internal (existing outsourcing relationship, API integration changes scope), or vendor-to-vendor (new or expanded outsourcing relationship requiring full assessment).

Challenge 3: Operational Resilience — What Happens When an API Is Unavailable?

The API integration model concentrates a significant volume of compliance-critical data flows through a single integration platform. If the API gateway itself is unavailable, what happens to the data flows? If the sanctions screening vendor's API is down, can Cornerstone still onboard customers? Under the FCA's operational resilience rules (PS21/3), Cornerstone must map its important business services, identify the technology, people, and processes that support them, and demonstrate that it can continue operating within its impact tolerance even when parts of its infrastructure fail.

The AML flow from alert generation to case creation is an important business service: Cornerstone's ability to detect and report suspicious activity within required timeframes depends on it. If the API connection between the AML monitoring system and the case management system fails, the compliance operations team needs a defined fallback — most likely the manual export-and-import process they currently rely on, now documented as a fallback rather than the primary workflow.

Challenge 4: API Versioning and Change Management

With 47 API connections across twelve vendor and internal systems, versioning discipline is critical. When any one of the twelve vendors updates its API — adding new fields, deprecating old ones, changing authentication mechanisms — every downstream integration that calls that API must be assessed for impact and potentially updated.

Without a formal change management process for APIs, version drift will create silent failures: integrations that continue running but return incorrect or incomplete data because they are calling a deprecated API endpoint that no longer functions correctly. The compliance team proposed requiring all vendors to provide minimum 90 days' notice of breaking API changes, with a defined change management workflow: impact assessment, UAT (user acceptance testing) in a sandbox environment, compliance sign-off, and production deployment.

The Proposed API Governance Framework

After three months of analysis, the Cornerstone compliance architecture team proposed a five-component API governance framework.

The first component is an API Registry — a living document recording all 47 API connections, updated within five business days of any change, covering the counterparties, data types, legal basis, authentication mechanism, version, and operational resilience classification for each connection.

The second component is an API Change Management Policy — all new API connections and material changes to existing ones must undergo compliance review before go-live, assessed against GDPR data flow requirements, outsourcing classification, and operational resilience impact.

The third component is an API Security Standard — defining the minimum authentication (OAuth 2.0 with mTLS for all external connections; internal connections using service-to-service tokens with defined expiry), encryption (TLS 1.3 minimum), and logging (every API call logged with timestamp, caller identity, endpoint, response code, and data volume) requirements across all connections.

The fourth component is an API Monitoring Dashboard — a single view of the health and activity of all 47 connections, with automated alerting for: connection failures lasting more than five minutes, abnormal data volumes suggesting potential data exfiltration, and authentication errors suggesting potential unauthorized access attempts.

The fifth component is an Outsourcing Register Update — reflecting all vendor-hosted system API connections as outsourcing arrangements where the relevant criteria are met, with appropriate outsourcing agreements and exit strategies.

Discussion Questions

1. The CTO's proposal creates 47 new API connections across 12 systems. Walk through the analysis of whether each of the following three connections constitutes "outsourcing" under the EBA Guidelines: - (a) Cornerstone's AML monitoring platform (internally owned) calls the vendor-hosted sanctions screening engine's API in real time. - (b) Cornerstone's KYC platform (internally owned) calls Cornerstone's internally-owned case management system's API. - (c) Cornerstone's internally-owned regulatory reporting system calls a vendor-hosted COREP template generation API.

For each, state whether it is likely to constitute outsourcing and explain why.

2. The proposed integration between the communications surveillance system and the AML case management system would route potentially sensitive customer communication content across the compliance API layer. What GDPR principles should govern the design of this data flow, and what technical measures (data minimization, access controls, retention policies) would you recommend?

3. Cornerstone currently relies on a manual export-and-import process as its effective primary mechanism for moving AML alerts to the case management system. The CTO's proposal makes this an API-automated flow, with the manual process as fallback. From an operational resilience perspective, what requirements should the API integration meet before the FCA's impact tolerance assessment for Cornerstone's financial crime controls would be satisfied?

4. Design an API change management process for Cornerstone that would prevent version drift across the 47 connections. Your process should address: how vendors notify Cornerstone of breaking changes; how Cornerstone assesses impact; how changes are tested before production deployment; and how the API Registry is kept current.

5. The Cornerstone GDPR Privacy Management Platform has no current connection to any other compliance system, meaning data subject access requests must be handled by manually querying five separate systems. Propose an API integration design that would enable the Privacy Platform to automatically aggregate personal data for a given customer ID from the KYC platform, AML system, and case management system in response to a subject access request. What data minimization and access control considerations apply?