Fraud teams should combine broad transaction signals with industry specific context, then let model performance and expert review determine how each feature is weighted. Useful features include account age, shipping speed, address relationships, seller history, and distance between IP and billing data. The goal is not rigid rules, but higher fidelity scoring that reflects how legitimate customers actually behave.
How to Frame the Feature Set Around Real Fraud Signals
Feature design for eCommerce fraud should start with the decision the model is trying to improve, then assemble signals that help separate normal customer variation from suspicious behaviour. The strongest sets usually combine transaction, account, device, shipping, and behavioural context, because fraud rarely shows up in only one field. The practical test is whether a feature improves discrimination without overfitting to a narrow pattern.
That means treating features as evidence, not rules. Account tenure, address reuse, fulfilment speed, purchase cadence, device changes, and geo mismatch can all be useful, but only if they are measured consistently and interpreted in context. A feature that looks suspicious in isolation may be ordinary for a high-volume buyer, marketplace seller, or repeat customer.
Fraud teams also need to preserve explainability. If a feature cannot be justified to investigators, disputes teams, or operations, it may still help a model, but it will be harder to trust and tune. The best feature sets are broad enough to capture patterns, yet disciplined enough that analysts can describe why a score moved.
How to Balance Generic Signals with eCommerce-Specific Context
Generic signals help establish baseline risk, while domain-specific features make the model commercially useful. In practice, the first group often includes velocity, account age, payment history, and device consistency. The second group adds seller reputation, shipping method, basket composition, address relationships, IP and billing distance, return behaviour, and category-specific anomalies.
The key design choice is not whether a feature is common, but whether it changes the fraud decision in this environment. For example, shipping speed matters more when expedited fulfilment is a meaningful fraud marker, and address relationships matter more when reshipping or mule behaviour is a known pattern. Strong feature sets reflect the platform’s own customer mix and abuse profile.
It is often useful to compare the feature set with operational reality rather than abstract model theory. If the business sees lots of legitimate cross-border purchases, then raw geo mismatch will need more context. If marketplace or seller fraud is common, then seller history and listing behaviour become core signals, not optional extras.
For teams that want a broader control lens, Why NHI Security Matters Now is useful background on how abuse scales when access patterns, secrets, and trust relationships become the attack surface. For eCommerce fraud programs, the same logic applies to transaction features, the model should focus on relationships that expose abuse paths, not only isolated attributes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 5 — Account Management | Fraud feature sets depend on trustworthy account and relationship signals. |
| Recommendation — Track account age, reuse, and lifecycle changes as core risk features. | ||
| NIST CSF 2.0 | GV.1 — Cybersecurity Policy | Feature selection should follow a defined risk decision policy for the business context. |
| ID.RA — Risk Assessment | Fraud features are chosen to improve risk identification and scoring fidelity. | |
| Recommendation — Define fraud feature criteria around decision objectives and accepted risk tolerance. Assess which signals materially improve detection across your customer and transaction mix. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Sprawl | Transactions can be skewed by abuse patterns tied to overexposed credentials and account misuse. |
| Recommendation — Include relationship and anomaly signals that surface credential-driven abuse patterns. | ||
Practitioner Guidance
What to prioritise: Build features that explain behaviour at three levels, session or device, account or customer, and transaction or fulfilment. If a feature only helps at one layer and adds little to the others, it is usually weaker than it first appears.
What to verify: Check that each feature is available at decision time, stable across channels, and resistant to easy gaming. A feature that leaks post-decision information or changes definition by region will create evaluation noise and weak production performance.
Common mistake: Overweighting obvious fraud indicators such as distance or shipping speed without testing their legitimate-customer false positives. Fraud models fail when teams confuse “unusual” with “bad” and do not tune the feature against real customer segments.
Practitioner takeaway: Good fraud feature design is less about inventing clever variables and more about selecting signals that reflect how customers, sellers, and fulfilment flows actually behave in your environment.
Related resources from NHI Mgmt Group
- How should fraud teams operationalise identity and network intelligence in ecommerce risk decisions?
- Who should own risk-scoring decisions across fraud and compliance teams?
- How do teams know whether machine traffic is becoming a fraud risk?
- How should ecommerce teams handle fraud risk during seasonal traffic spikes?
