FraudShield
Live portfolio applicationA live rules-based e-commerce risk prototype showing transaction-level risk factors.
Problem & approach
Problem
Transaction risk needs an explanation that people can inspect.
Approach
Use transparent online rules and transaction-level factors; evaluate the separate offline training experiment independently.
Evidence
Try the live risk engine and inspect the repository; a live demo is not evidence of production business outcomes.
Product decision review
Who it serves
Reviewers exploring how transaction attributes can produce an inspectable fraud-risk signal.
The decision this design supports
Keep the deployed scoring path transparent: the Worker applies deterministic rules and returns contributing factors. The offline training experiment is a separate path, so the demo can explain its current behavior without implying it serves a trained model.
Implemented workflow
- Enter amount, account age, transaction activity, location, time, and failed-attempt features.
- Validate field ranges before scoring, including hours from 0 to 23.
- Inspect the returned heuristic score and the factors contributing to it.
- Change one input at a time to see which rules are activated and how the explanation changes.
Design tradeoff
Rules are easy to inspect and deploy without model infrastructure, but fixed thresholds can miss patterns and overflag unusual legitimate behavior. A trained model would need representative labels, evaluation, calibration, and monitoring before replacing this path.
What to measure
The demo shows a heuristic score, not a calibrated fraud probability. With representative labeled data, useful evaluation would compare recall, false-positive rate, review volume, and cost at different thresholds. No accuracy or business-loss reduction is claimed here.
Current scope
This is a rules prototype, not an automated payment approval system. Velocity fields come from the caller; the Worker does not maintain cross-transaction history.
Next evaluation
Build labeled scenario coverage, examine threshold sensitivity, and evaluate the offline model separately before considering online integration.
Inspect the implementation
Release history
GitHub releases are tagged versions. Implementation code and commits can exist without a published release.