Thank you! Your submission has been received
In the fight against financial fraud, your data is your best weapon. But just like raw metal needs shaping to become a strong tool, raw data needs to be refined to be truly effective. This is where "features" and "feature engineering" come in. They are the building blocks of any good fraud detection system, whether it uses simple rules or complex artificial intelligence. Understanding them helps you spot threats accurately while letting legitimate customers transact smoothly.
Think of a feature as a specific piece of information or a measurable characteristic related to an event you're examining, like a financial transaction. These are the individual details that help you understand what happened.
We can group features into two main types:
Raw Features: These are the basic facts pulled directly from your data sources (like transaction logs or customer databases).
Example: The amount of a transaction, the time it occurred, or the customer's IP address.
Engineered Features (or Derived Features): These are new, smarter pieces of information you create by transforming or combining one or more raw features. The goal is to uncover more complex patterns or insights that aren't obvious from the raw data alone.
Example: Calculating "transaction frequency for a user in the last hour" (combining user ID, transaction timestamps, and a time window) or flagging if the "shipping address country is different from the IP address country" (combining two location features).
There's a golden rule in data analysis: "Garbage In, Garbage Out" (GIGO). This is especially true for fraud detection. The quality of your initial raw features sets the absolute limit for how well your fraud detection system can work, no matter how fancy your analysis or feature engineering gets.
Here's what makes raw features good:
Accuracy: Is the information correct? A wrong transaction amount can throw everything off.
Completeness: Are key details missing? If you don't have an IP address or user ID for many transactions, you're working with blind spots.
Timeliness: Can you get the data fast enough to act, especially for stopping fraud in real-time?
Relevance: Does the data actually help you tell the difference between a normal user and a fraudster? Collecting useless data just adds noise.
While every business is different, a solid set of raw features for fraud detection usually includes information from these areas:
1. About the Transaction Itself:
transaction_id
: A unique code for the transaction.
amount
: The money value involved (a primary target for fraud).
currency
: The type of money (e.g., USD, EUR) – important for risk context.
timestamp
: Exactly when it happened (crucial for spotting unusual timing or rapid activity).
product_type
/service_type
: What was bought or used (fraud often targets specific items).
payment_method
: How it was paid (e.g., credit card, bank transfer – different methods have different risks).
merchant_id
/recipient_id
: Who received the money (helps spot risky sellers or receivers).
2. About the User or Account:
user_id
/account_id
: Who started the transaction.
account_creation_date
: When the account was opened (very new accounts can be riskier).
user_email
/phone_number
: Contact info (can be checked for legitimacy).
account_status
: Is the account verified, new, or suspended?
historical_transaction_count
/value
: Summary of the user's past activity.
3. About the Device and Session:
ip_address
: The internet address of the device used (helps find location, proxy use, or links between fraudsters).
device_id
/fingerprint
: A unique identifier for the user's phone or computer (spots if one device is used for many "different" accounts).
user_agent_string
: Information about the browser or app (can reveal bots or outdated software).
session_id
: Identifier for the user's current interaction.
4. About Location:
ip_geolocation
: Country/city guessed from the IP address (highlights risky areas or impossible travel).
billing_address
: Address linked to the payment.
shipping_address
: Where goods are sent (big differences between IP location, billing, and shipping addresses are red flags).
5. About the Network (More Technical):
ip_asn
: Information about the internet service provider for the IP (can distinguish between home internet and data centers often used by fraudsters).
is_proxy
/is_vpn
: Flags if the user is trying to hide their location.
6. About Timing (Derived from Timestamp):
time_of_day
/day_of_week
: When the transaction happened (fraudsters often operate at specific times).
Relative Measures (Normalization/Standardization):
Concept: Comparing a value to a benchmark.
Examples:
amount_z
: Transaction amount's Z-score relative to the global average amount in a recent period (identifies globally unusual amounts).
amount_z_entity
: Amount's Z-score relative to that specific user's average amount in a recent period (identifies amounts unusual for that user, even if globally normal).
amount / average_daily_spend
: Ratio of current transaction to user's typical daily spend.
Velocity Counts (Aggregations over Time):
Concept: Counting occurrences within specific time windows. Crucial for detecting rapid, automated attacks.
Examples:
entity_transaction_count_1h
: Number of transactions by the user in the last hour.
ip_distinct_users_24h
: Number of unique users seen from the same IP address in the last 24 hours (detects shared IPs, potential botnets).
failed_login_attempts_15m
: Number of failed logins for the user recently.
Categorical Flags & Risk Scoring:
Concept: Creating boolean flags or simple scores based on known risk factors.
Examples:
is_high_risk_country
: Boolean flag if IP geolocation is in a predefined list.
is_new_device_for_user
: Boolean flag if the device fingerprint hasn't been seen for this user before.
address_mismatch
: Flag if billing/shipping/IP locations don't align.
email_domain_risk_score
: Score based on whether the email domain is known disposable or high-risk.
Interaction Features:
Concept: Combining two or more features to capture synergistic effects. Fraud often lies in the combination of factors.
Examples:
Multiplying amount
by entity_transaction_count_1h
(high amount combined with high velocity).
Creating a flag for is_new_user AND is_high_risk_country
.
Calculating the time difference between account_creation_date
and transaction_timestamp
(account age at time of transaction).
Automated systems like Loci Auto-Grapher aim to streamline the feature engineering process, particularly steps 1, 2, 3 & 4 above. Without revealing specific algorithms:
They typically operate on batches of recent data.
They automatically calculate batch-relative statistics (like the mean and standard deviation of amounts within that batch) to derive normalized features (like amount_z
).
They compute entity-specific statistics within the batch (like a user's transaction count or average amount within that specific time window) to create velocity and entity-relative deviation features (like count_24h
, amount_z_entity
).
They incorporate configurable logic, such as checking against lists (HIGH_RISK_LOCATIONS
), to generate boolean flags.
The core mining process then implicitly explores interactions by combining these engineered L1 features into L2 patterns.
The goal is to automatically generate a rich set of potentially predictive engineered features based on the input batch, serving as the direct input for the subsequent pattern mining stage.
Effective feature engineering is paramount for minimizing false positives (legitimate transactions incorrectly flagged as fraud). Here's why:
Specificity: Raw rules are often blunt instruments. A rule like amount > 5000
might catch fraud but will inevitably flag many legitimate large purchases. Engineered features add context. A rule like amount > 5000 AND amount_z_entity > 3.0 AND is_new_device_for_user
is far more specific. It targets transactions that are not only large but also highly unusual for that specific user and involve a new device – a much stronger indicator of potential fraud, less likely to impact legitimate behavior.
Distinguishing Power: Well-engineered features help separate the subtle characteristics of fraudulent behavior from legitimate activity that might appear similar on the surface. Velocity counts, deviation metrics, and interaction features are key here.
Contextual Understanding: Features like amount_z_entity
provide context that raw amount
lacks. A $100 transaction might be normal for one user but highly suspicious for another who usually only spends $5. Feature engineering allows the system to understand this context.
By starting with high-quality raw features and then thoughtfully engineering new ones, you build a much stronger and more insightful fraud detection system.