A fraud model cannot act on a raw transaction log alone, and a market-direction model gains little from raw closing prices without context. Feature engineering turns available data into variables that express a useful financial signal. The goal is not to create more columns indiscriminately: domain knowledge should connect each feature to a plausible behavior, risk, or economic relationship. section 1.4.1 section 10.4
Start with the decision the model must support, then construct and check the relevant signals:
- For credit assessment, prepare borrower and economic data with attention to quality, security, and regulatory obligations; consumer-spending seasonality is one possible derived pattern. section 1.4.1
- For fraud detection, derive short-window action counts, deviations from a customer's usual behavior, links between accounts and devices, and session or device trust scores. Deliver time-sensitive features through real-time or near-real-time pipelines. section 7.4.2
- For market prediction, define the target alongside economically meaningful predictors. Test whether a signal still holds when relationships change, rather than assuming a historical correlation is permanent. section 10.4 section 10.4.3
- For news analysis, convert unstructured text into searchable mathematical vectors so qualitative information can be compared and retrieved alongside quantitative signals. section 11.3
A market signal instead of a larger model
To predict tomorrow's SPY direction, a rolling 30-day volatility spread between high-yield corporate bonds and Treasuries gives a simple logistic-regression model an interpretable input. A volume ratio can separately help distinguish a convincing move from a low-volume price change. Neither feature is guaranteed to remain useful: market relationships can reverse under stress. section 10.4 section 10.4.3
Figure 7.7 A conceptual illustration of the data assets layer for fraud detection. This diagram doesn't represent a fixed architecture or specific tech stack, but rather emphasizes the importance of organizing diverse internal and external data sources—such as transactions, behavioral logs, device fingerprints, and risk signals—into a coherent asset layer. Real-world implementations vary significantly across fintech, traditional banking, and e-commerce platforms, but the foundational goal remains the same: to make rich, timely, and relational data readily available for downstream fraud detection models and logic.
The conceptual fraud data-asset diagram shows why feature construction depends on bringing transaction, behavior, device, and other risk data together before downstream detection logic uses it; it is not a prescribed architecture. section 7.4.2
Operational value depends on more than model accuracy. Fraud features must arrive quickly enough to support decisions in progress, while data handling must respect privacy and other applicable controls. Monitor whether the patterns behind a feature still hold; a once-useful market relationship can become a risk when conditions change. section 7.4.2 section 1.4.1 section 10.4.3
