Case Study 40.1: The Integration Failure That a Regulator Found First

The Situation

Organization: Cornerstone Financial Group (fictional composite institution) Function: Financial Crime Compliance — cross-domain Challenge: An FCA skilled person review (Section 166) identified an integration failure between Cornerstone's AML monitoring and sanctions screening systems that Cornerstone's own compliance program had not identified Timeline: Q2–Q4 2024 Characters: Priya Nair (engaged as expert consultant for the skilled person review); Rafael Torres (Cornerstone's Head of Compliance Technology, involved in the remediation)

Background

Cornerstone Financial Group had invested significantly in its compliance technology program over the preceding three years. Its AML transaction monitoring system had been upgraded in 2022. Its sanctions screening system — a different vendor — had been upgraded in 2023. Both systems were performing well individually: the AML system's false positive rate had fallen from 41% to 24%; the sanctions screening system was generating clean results with a manageable volume of potential matches.

The two systems were, however, independent. They shared no data model. They maintained separate customer records. They generated alerts into separate queues managed by separate teams.

What the FCA Found

The skilled person review was triggered by a specific complaint: a customer who had been subject to a sanctions screening match, investigated by the sanctions team, and cleared as a false positive — and who had simultaneously been the subject of an escalated AML case that resulted in a SAR filing.

The FCA examiner's question was simple: did anyone at Cornerstone know both things were happening simultaneously? And if so, did the sanctions team's investigation take account of the open AML case? And did the AML case handler know that sanctions had already investigated this customer and cleared them?

The answer to all three questions was no.

The AML team and the sanctions team had each done thorough work — independently. The AML case file was complete and the SAR was appropriately filed. The sanctions investigation file was complete and the false positive determination was well-documented. But neither team had known about the other's investigation.

The FCA's finding: Cornerstone lacked an integrated view of customer compliance risk. The two systems did not share customer data or alert history. There was no cross-domain alert correlation. A customer could be simultaneously under investigation for sanctions concerns and for suspicious activity, with neither investigation team aware of the other's work.

More specifically, the FCA found that the sanctions team's false-positive determination — made without knowledge of the concurrent AML case — might have been different if they had seen the full customer risk picture. The determination was not necessarily wrong. But it could not be shown to have been made with full information.

What Rafael Found in the System Architecture

Rafael conducted the technical review for the remediation program. He found three specific integration failures:

Failure 1: Separate customer records. The AML system maintained its own customer risk data, populated from the KYC system at onboarding. The sanctions system maintained its own separate customer record, also populated from the KYC system at onboarding. When the KYC system updated a customer's risk classification — which it had done in this case, upgrading the customer from Medium to High risk — the update propagated to the AML system but not to the sanctions system. The sanctions team was investigating a customer whose risk tier they believed was Medium; the AML team was investigating the same customer correctly classified as High.

Failure 2: No shared alert registry. Each system generated alerts into its own queue. There was no mechanism by which the opening of an AML case could surface as a flag in the sanctions screening workflow, or vice versa. The two teams operated in compliance silos with no common data infrastructure.

Failure 3: Management information was domain-specific. The Head of Financial Crime received AML metrics. The Head of Sanctions received sanctions metrics. The CCO received both separately. No one received a combined view that would have surfaced the simultaneous investigation pattern.

The Remediation Program

Priya structured the remediation in three phases, based on risk priority:

Phase 1 (Immediate, 30 days): Establish a manual cross-referencing procedure. Every new escalated AML case and every new confirmed potential sanctions match to check the other system manually before progressing the investigation. This was a workaround — imperfect but immediate.

Phase 2 (90 days): Implement a unified alert registry. A new data layer was built that received alert notifications from both systems, identified common customer identifiers across both systems, and surfaced cross-domain alerts in both teams' workflows. This required a mapping exercise to reconcile the two systems' inconsistent customer identification schemes (the AML system used an internal customer ID; the sanctions system used a passport number).

Phase 3 (6 months): Implement a common customer master record that serves as the authoritative source for both systems. Customer risk data — including risk tier, sanctions status, AML alert history — to be updated in the master record and propagated to both systems via an API integration. The two-update-at-onboarding model was retired.

The FCA accepted the remediation plan and monitored its implementation. No enforcement action was taken. The skilled person's final report noted that Cornerstone's response to the finding had been "thorough and appropriately urgent."

The Governance Lesson

Rafael summarized the governance lesson in the post-remediation review: "We thought about our compliance systems as a set of capable tools and asked: is each one performing? We never asked: are they performing as a coherent program? The distinction sounds academic. The FCA exam shows it isn't."

The two systems had been evaluated, validated, and governed separately. Each had passed its individual validation. Each had adequate ongoing monitoring. Neither had failed on its own terms.

The failure was in the space between them — the data that didn't flow, the alerts that were never correlated, the customer view that was never unified. That space was invisible to any system-level governance process because it was the space between systems.

Discussion Questions

1. The FCA found the integration failure through a specific case — a customer who triggered investigations in two systems simultaneously. What monitoring or governance process within Cornerstone might have identified this failure before the FCA found it? Design a specific quarterly cross-domain review that would have surfaced the pattern.

2. The two systems maintained separate customer records because they had been procured separately and implemented by different teams. Is this a technology failure, a governance failure, or a procurement failure? What processes should have been in place to prevent independent customer record proliferation across compliance systems?

3. The sanctions team's false-positive determination was made without knowledge of the concurrent AML case. The FCA noted that the determination might have been different with full information. How should compliance programs design workflows that ensure cross-domain context is available at the point of making significant compliance decisions?

4. Phase 1 of the remediation was a manual cross-referencing procedure — "imperfect but immediate." Priya chose this over a longer-timeline technical solution because of the regulatory risk of the gap continuing. When is a manual workaround the appropriate first response to a compliance gap? What are the risks of relying on manual procedures during technical remediation programs?

5. The post-remediation review found that the failure was "in the space between systems." How should a compliance technology governance framework explicitly address the spaces between systems — the data flows, the integration points, the combined workflows — rather than treating each system as a discrete governance object?