Case Study

Choosing Feature Engineering for a Fraud Model with Very Little Data

Case context: A fintech startup is building a fraud detection model for card transactions. It has only 180 labeled transactions, so the team is deciding between a fully end-to-end model and a model that includes hand-crafted features such as amount buckets, transaction frequency over the last day, and merchant category flags.

Question: Based on the principle that extra human-designed components can reduce the amount of data a system needs, which approach should the team choose, and why do those features help?

Sample answer: The team should include the hand-crafted features because the dataset is too small to rely only on a fully end-to-end approach. Amount buckets and transaction-frequency features reduce the learning burden by turning raw transactions into simpler, more informative signals. Merchant category flags also inject domain knowledge that helps the model focus on patterns that matter for fraud, rather than trying to discover every useful pattern from just 180 examples. In a low-data setting, these features effectively supplement what the model can learn on its own.

Key points:

  • Prefer hand-crafted features because the labeled data is very limited
  • Amount buckets and frequency features simplify the learning problem
  • Merchant category flags add useful domain knowledge
  • Hand-designed inputs help compensate for the small dataset

Rubric: The learner must identify that hand-engineered components are appropriate because of the low-data constraint. They must explain that the features reduce complexity and inject useful prior knowledge, which helps the model learn from a small sample.

0

1

Updated 2026-08-12

Contributors are:

Who are from:

Tags

Machine Learning

Deep Learning

Supervised Learning

Dive into Deep Learning @ D2L

Data Science

Machine Learning Strategy

Machine Learning Yearning @ DeepLearning.AI