A fintech team sees a spike in fraud involving new accounts and needs a response it can explain and test quickly. A rules engine ingests transaction data, checks predefined if-then conditions, and identifies activity that matches suspicious criteria. Rules can come from expert knowledge, historical analysis, or known fraud patterns. They are less adaptive than AI models, but transparent and relatively quick to implement. section 7.4.1
A rule with an operational consequence
If a card makes more than five online payment attempts within an hour and at least three fail authentication, block subsequent transactions from that card for a review period. The conditions define what to detect; the block and review period define what happens after a match. section 7.4.1
Prototype rules before putting them into a production engine:
- Load historical transactions and inspect the available fields and fraud-label distribution. In the sample data, approximately 3.8% of transactions are fraudulent, so the base rate matters when judging how useful a flag will be. section 7.4.1
- Express candidate conditions using available features such as transaction amount, account age, and whether the IP address is domestic. Apply each condition to the data and count flagged transactions, fraudulent flags, and legitimate flags. section 7.4.1
- Check precision—the proportion of flagged transactions that are fraud—rather than treating every flag as a successful detection. Combine conditions when the intended decision requires more than one signal, and define the resulting review action. section 7.4.1
Listing 7.2 Applying and evaluating simple fraud detection rules
def calculate_rule_detection_performance(df, rules_conditions):
"""
Applies a dictionary of rules (as pandas query strings) to a DataFrame
and calculates performance metrics for each rule.
"""
results_list = []
for rule_name, condition_query_str in rules_conditions.items():
# Filter the DataFrame based on the rule's condition
flagged_by_rule_df = df.query(condition_query_str)
num_total_flagged = len(flagged_by_rule_df)
if num_total_flagged > 0:
num_fraud_flagged = flagged_by_rule_df['label'].sum() # Sum of 1s (fraud)
num_legit_flagged = num_total_flagged - num_fraud_flagged
# Detection Rate (Precision): Proportion of flagged transactions that are fraud
detection_rate = num_fraud_flagged / num_total_flagged
else:
num_fraud_flagged = 0
num_legit_flagged = 0
detection_rate = 0.0
results_list.append({
'Rule Name': rule_name,
'Legitimate Transactions Flagged': num_legit_flagged,
'Fraudulent Transactions Flagged': num_fraud_flagged,
'Precision (Fraud/Flagged)': detection_rate
})
return pd.DataFrame(results_list)
# Define our set of expert rules using pandas query syntax
defined_rules = {
'High Value Transaction (>5000)': "transaction_amount > 5000",
'Multiple Recent Payment Methods (>=3)': "recent_7d_payment_methods_count >= 3",
'Frequent Login Failures Recently (>=3)': "num_recent_login_failures >= 3",
'New Account & Large Transaction (>3000, age<=30d)': "(account_age_days <= 30) and (transaction_amount > 3000)",
'International IP & High Value Transaction (>2000)': "(is_domestic_ip == False) and (transaction_amount > 2000)"
}
# Evaluate the rules on our sample data
rule_performance_df = calculate_rule_detection_performance(sample_data.copy(), defined_rules)
print("\nPerformance of Defined Fraud Detection Rules:")
display(rule_performance_df)
The Python listing applies rule conditions as pandas queries and calculates per-rule flag counts and precision. It is a historical-data prototype, not a production rules engine. section 7.4.1
In a real-time fraud system, the rules engine is one component, not the whole payment decision. A transaction can pass through an API gateway and feature store to a serving layer containing a model, rules engine, and other scorers. A decision orchestrator combines their signals into an approve, review, or decline action. Rules can also provide a simpler fallback when a primary AI model repeatedly fails or times out; if that fallback fails too, the system needs a further fail-safe response. Latency, resilience, and validation on live traffic remain deployment concerns. section 8.4.7
