A European fintech with twelve million customers received a GDPR audit notice from their national data protection authority. The audit focused on the company’s machine learning pipeline, which powered credit scoring, fraud detection, and customer segmentation. The data protection authority’s concern was specific: the company’s ML training pipeline was ingesting and retaining personal data that was not necessary for the stated purpose of the models.

GDPR’s data minimization principle requires that personal data collected for a specific purpose be limited to what is necessary for that purpose. The audit found that the company’s feature engineering pipeline was extracting and storing over 200 features per customer, including features that had no demonstrated relationship to model performance. Transaction timestamps, device fingerprints, browsing session metadata, and geolocation history were all being ingested into the training data store. Some of these features had been included because an early experiment showed marginal accuracy improvement. Others had been included because “we might need them later.”

The data protection authority issued a preliminary finding that the company was in violation of the data minimization principle for approximately sixty percent of the features in their training pipeline. The company had ninety days to demonstrate compliance or face penalties.

The problem was not the models

The credit scoring model used thirty-one features. The fraud detection model used forty-seven features. The customer segmentation model used twenty-three features. Combined, the three production models used approximately 100 unique features. But the training data store contained over 200 features per customer, because the feature engineering pipeline was shared across all models and had been designed to extract every available feature “just in case.”

The pipeline was built as a single extraction job that pulled data from the transaction database, the CRM, the web analytics platform, and the device fingerprinting service. The extraction job wrote all features to a centralized training data store. Each model’s training job read from this store and selected its relevant features. The unused features remained in the store, accessible to any future model that might want them.

This design violated GDPR’s purpose limitation principle, which requires that data collected for one purpose not be repurposed for another without explicit consent. The company had consent to use transaction data for credit scoring. It did not have consent to retain browsing session metadata in a training data store that was accessible to the customer segmentation model. The centralized store made this repurposing trivially easy, which was the point of the design — and the source of the compliance failure.

The rebuild: purpose-bound feature pipelines

We redesigned the ML pipeline to enforce purpose limitation at the infrastructure level. Each model had its own feature pipeline that extracted only the features necessary for that model’s stated purpose. The pipelines were isolated — a feature pipeline for credit scoring could not access data that was consented only for fraud detection.

The consent registry was the gate. Every feature extraction was checked against the consent registry to verify that the customer had consented to the use of that data for the specific purpose of the model being trained. If a customer had consented to transaction data being used for credit scoring but not for customer segmentation, the segmentation feature pipeline could not extract transaction features for that customer.

The data minimization audit was the enforcement mechanism. Every feature in every pipeline was required to have a documented justification: why this feature was necessary for the model’s purpose, what evidence supported its inclusion, and what impact its removal would have on model performance. Features without a documented justification were flagged and excluded.

The feature justification process

Every feature had to pass a three-part test. First, necessity: was the feature required for the model to achieve its stated performance target? A feature that improved accuracy by 0.1 percent was not necessary if the model already met its target without it. Second, proportionality: was the feature the least intrusive way to capture the relevant signal? If a feature derived from browsing session metadata could be replaced by a feature derived from transaction history with similar accuracy, the less intrusive alternative was required. Third, consent coverage: did the customer’s consent explicitly cover the use of this data for this purpose?

The justification process eliminated 104 of the 200 features. Some were eliminated because they had no demonstrated impact on model performance. Some were eliminated because a less intrusive alternative existed. Some were eliminated because the consent basis did not cover the model’s purpose.

The remaining ninety-six features were organized into purpose-bound feature sets. Each set was associated with a specific model and a specific consent basis. The feature pipeline enforced the boundary: a feature set for credit scoring could not be accessed by the segmentation pipeline, even though both pipelines drew from the same source data.

What we gave up

Model accuracy dropped slightly. The credit scoring model’s AUC decreased from 0.83 to 0.81 after removing features that lacked sufficient consent coverage. The fraud detection model’s recall decreased by two percentage points. The segmentation model was unaffected because its feature set had the broadest consent basis.

The team accepted the accuracy trade-off after calculating the regulatory cost. A GDPR penalty for the original pipeline could reach four percent of annual revenue. For a fintech with $200 million in revenue, that was $8 million. The accuracy loss translated to an estimated $400,000 in annual credit losses. The compliance risk was twenty times the accuracy cost.

The second trade-off was pipeline complexity. Instead of one shared feature extraction pipeline, the team maintained three separate pipelines. Schema changes in source systems required updates to each pipeline independently. Feature development slowed because every new feature required a consent check and a justification document before it could be added to any pipeline.

The third trade-off was model experimentation velocity. Under the old design, a data scientist could experiment with any feature in the centralized store. Under the new design, a data scientist could only experiment with features that were in their model’s purpose-bound feature set. Exploring a feature from another model’s set required a consent review and a justification process. This slowed experimentation but ensured that experiments did not violate consent boundaries.

Results

The company passed the GDPR audit on re-examination. The data protection authority’s report noted that the purpose-bound pipeline architecture was “a robust implementation of data minimization by design” and cited it as a positive example in their annual guidance publication.

The operational overhead of maintaining three separate pipelines was approximately twenty hours per month — higher than the shared pipeline but lower than the team had feared, because the automation around consent checking and feature justification reduced the manual work.

The decision heuristic

If your ML training pipeline extracts more features than your production models use, you have a data minimization problem. The fix is not to delete the unused features after training. The fix is to never extract them in the first place. Build purpose-bound feature pipelines that extract only what each model needs, gated by a consent registry that enforces the boundary between what you have consent to use and what you do not. The pipeline architecture is your compliance evidence. If the pipeline cannot extract a feature, the feature cannot end up in a training set, and the compliance question answers itself.