A fraud team needs a quick response to a spike in suspicious activity. A rule-based system turns known patterns into explicit if-then decisions: if specified conditions hold, flag, block, or otherwise handle the transaction. The rules can come from expert knowledge, historical analysis, and known fraud patterns. A production rule engine compares incoming transactions with those rules. section 7.4.1
Repeated payment attempts
If a card makes more than five online payment attempts within an hour and at least three fail authentication, block subsequent transactions for a review period. The condition and response are explicit, so an analyst can inspect why the rule fired. section 7.4.1
To test rules before putting them in a production rule engine:
- Load historical transactions and check the dataset size, available fields, and fraud prevalence. In the sample data, about 3.8% of transactions are fraudulent. section 7.4.1
- Express each candidate condition against fields such as transaction amount, account age, or whether an IP address is domestic. Apply it to historical records and count both fraudulent and legitimate transactions flagged. section 7.4.1
- Check precision—the share of flagged transactions that are fraud—rather than treating every flag as a useful detection. A low fraud baseline makes unnecessary flags an important design concern. section 7.4.1
IF (
Rule_HighTxnAmount_Over_10K IS TRUE
AND Rule_IntlIP_HighTxn_Over_2K IS TRUE
) OR (
Rule_NewAcct_Under_30d_HighTxn_Over_5K IS TRUE
)
THEN
FlagTransactionForHighRiskReview
This pseudocode combines two conditions with AND, joins them to an alternative condition with OR, and sends matches to high-risk review. It shows how simple rules can be composed without hiding the decision logic. section 7.4.1
Rules are transparent, relatively quick to implement, and useful when the scenario is well understood. Their limits are equally practical: they consider programmed variables and fixed actions, require manual updates, and can miss unfamiliar combinations of circumstances. In retention outreach, a rule might send a fixed email when a user's 15-day profit and loss falls below −20% and login count exceeds 30; it would not, by itself, account for relevant news, earlier emails, or signs that the user is researching recovery. section 7.4.1 section 14.1.1
