Building a Data Flywheel in Financial Services: The Compounding Mechanism Most Firms Are Missing

There is a concept that separates AI initiatives that compound from AI initiatives that plateau, and most financial services firms have not built it. The concept is the data flywheel: a closed loop where the AI system's own operation generates the data that makes it better, which generates better outcomes, which generates more data, which makes it better still.

The data flywheel is not a new idea. It is the mechanism behind every technology company that has built a structural moat around its AI capabilities: the more users interact with the system, the better the system gets, the more users interact. But in financial services, where the data is rich, the decisions are consequential, and the regulatory bar is high, almost no firm has built a working flywheel. They have built AI tools that operate on static training data and do not learn from their own production outcomes.

This is the single most important reason why most AI pilots do not compound.

What a data flywheel actually looks like

A data flywheel has four components operating as a continuous loop:

1. The AI system makes decisions in production. Not in a sandbox, not in a pilot environment, but in the live operational workflow. The system processes real cases, real data, and real edge cases.

2. The outcomes of those decisions are captured as structured data. When a fraud alert is investigated and resolved as either "genuine fraud" or "false positive," that label comes back to the system as structured training signal. When an underwriter overrides a model recommendation, the override reason is captured in a structured field, not buried in a free-text note.

3. The model is retrained or fine-tuned on the new data. The system incorporates the production outcomes into its next iteration. This can happen continuously (online learning), periodically (quarterly retraining), or on a trigger basis (when drift is detected). The mechanism matters less than the fact that it exists at all.

4. The retrained model produces better outcomes, which generate more data. Better fraud detection catches more fraud, which generates more labelled outcomes, which makes the next iteration better still. Better underwriting produces more accurate risk pricing, which attracts better risks, which produces more data on what good risk looks like.

The key insight is that the flywheel is not a technology feature. It is an operating model feature. It requires the workflow to be designed for feedback capture, the data layer to be designed for structured outcome recording, and the governance machinery to allow continuous retraining under PRA SS1/23 model risk expectations.

Where the flywheel works best in financial services

Not every AI use case supports a flywheel. The flywheel works where three conditions are true:

1. Labelled outcomes come back relatively fast. Fraud (fraud/not-fraud comes back in days), transaction monitoring (SAR/not-SAR comes back in weeks), credit decisioning (default/no-default comes back in months). Claims (settled/disputed comes back in weeks to months). The faster the label returns, the faster the flywheel spins.

2. Data volume is high enough to support retraining. A use case that processes 10 cases per month will not generate enough signal for meaningful retraining. A use case that processes 10,000 cases per day will.

3. The model's performance directly affects the quality of the next round of data. Better fraud detection catches more fraud, which produces more labelled fraud cases, which makes detection better. This positive feedback loop is the compounding mechanism.

In financial services, the value streams that best support a flywheel are:

• Fraud detection: Labelled outcomes return in days. Volume is high. The feedback loop is direct.
• Transaction monitoring and AML: Alert dispositions return in weeks. Volume is very high. The false positive rate is the metric that improves.
• Claims triage: Settlement outcomes return in weeks to months. Volume is high in P&C. The combined ratio improves.
• KYC and customer due diligence: Case outcomes return in days to weeks. Volume scales with onboarding.
• Credit decisioning: Default outcomes take longer (months to years), but the volume is large enough to support periodic retraining.

For a more detailed sector-by-sector breakdown, see the AI Enablement Financial Services Playbook.

Why most firms have not built one

The flywheel requires four structural capabilities that most financial services firms do not have:

1. The workflow is not designed for structured feedback capture

In most firms, when an analyst resolves a fraud alert as "false positive," that disposition is recorded in a case management system as a status change. The reason for the disposition, the evidence the analyst considered, and the confidence level of the decision are either not captured at all or captured in free-text notes that the model cannot consume.

The fix: redesign the workflow so that every human decision at a model override point is captured in structured fields that feed directly back to the training pipeline. This is what we mean by decision rights in an AI-native operating model.

2. The data layer is built for reports, not for action

Most enterprise data infrastructure in financial services is optimised for regulatory reporting, not for real-time model retraining. The data is batch-processed, aggregated, and stored in formats that are useful for the quarterly report but useless for feeding a continuous learning system. The action-data layer is a fundamentally different architecture, and rebuilding it is the hardest, most unglamorous, and most consequential part of the AI enablement work.

3. Model risk governance does not allow continuous retraining

Under PRA SS1/23, every model change requires validation. If the validation process takes three months, the flywheel cannot spin faster than quarterly. The fix is not to weaken validation but to embed governance into the workflow so that validation evidence is captured as a by-product of the retraining process, compressing the cycle without weakening the supervisory posture.

4. The operating model does not have the roles for it

A working flywheel requires someone to curate feedback quality, someone to monitor model performance, someone to manage the retraining pipeline, and someone to validate each iteration. These are not traditional roles in most financial services operating models. The talent shift required to support a flywheel is one of the five enablement pillars in every AI Enablement engagement.

How to build one

The practical path to a working flywheel follows the five-pillar AI enablement structure:

1. Pick one value stream where the flywheel conditions are met (fast labels, high volume, direct feedback loop). Fraud and transaction monitoring are the most common starting points in banking. Claims triage is the most common in insurance.

2. Redesign the workflow so that every human decision at a model interaction point is captured in structured fields. This is BPMN 2.0 workflow redesign with explicit feedback capture nodes.

3. Rebuild the data layer so that production outcomes flow back to the training pipeline in near-real-time. This is the action-data layer architecture.

4. Design the governance machinery so that model retraining and validation can happen on a cadence that allows the flywheel to spin. Quarterly at minimum; monthly or continuous if the use case supports it.

5. Create the roles to operate the flywheel: feedback curators, model performance monitors, retraining pipeline operators, and embedded second-line validation specialists.

The AI Enablement Maturity Diagnostic assesses each of these five capabilities and produces a per-pillar breakdown that identifies where your binding constraint sits.

The compounding advantage

The reason the data flywheel matters is not the first-year improvement. First-year improvements from a flywheel are modest (5-15% better than baseline, depending on the use case). The reason is the compounding curve: a model that learns continuously from your specific data, your specific customer base, and your specific operational patterns will be substantially better than any off-the-shelf vendor product two years from now.

This is the structural moat. A competitor who starts the flywheel work 18 months after you will be 18 months behind on a compounding curve, and the gap will widen every quarter. That is why the firms that start this work now will have an advantage that is genuinely difficult to close.

For supporting depth on the structural argument, see McKinsey's research on AI compounding and the Bank of England's perspective on AI in financial services.