A model score is only the start of the decision.
Built for Razorpay AI Buildathon 2026, this public project turns transaction scoring into a complete decision workflow. A supervised detector and an anomaly verifier feed a three-way policy: allow, block, or escalate. A FastAPI service exposes the decisions and explanations to a Next.js operations console.
A high aggregate accuracy can hide expensive missed fraud in an imbalanced dataset. Minimizing modeled loss alone can also flag more transactions than a review team could process. The useful engineering problem is choosing an operating point with explicit assumptions and a practical capacity constraint.
My published project connects feature engineering, model evaluation, an API decision pipeline, and an operations interface. The repository includes the evaluation method, source code, and recorded results. This case covers the integrated prototype; the numbers below are offline measurements from that implementation.
The detector minimizes modeled transaction loss with a default 15% flag-rate budget, chosen on validation data. Without the capacity constraint, the documented optimum flagged over half the validation traffic. This trades some modeled savings for a queue that has an explicit operating limit.
Training uses the earliest 70% of transactions and testing uses the latest 30%. Threshold selection stays within the training period’s validation slice. The design limits information leakage from future transactions and keeps the test set out of policy tuning.
XGBoost learns labeled fraud patterns; Isolation Forest measures unusual structure without fraud labels. Automated allow/block decisions require agreement. Disagreement produces a review action, making the verifier part of the policy rather than an extra score beside the detector.
The interface displays SHAP feature contributions and pipeline timings from the API. Decisions are recorded in a SHA-256 hash chain that can be checked for alteration. That makes individual actions inspectable while keeping the audit mechanism’s storage limits explicit.
Apply the same fitted feature transformation used for training before scoring an incoming transaction.
An illustrative view of the documented workflow. Positions and signals are conceptual.
Apply the same fitted feature transformation used for training before scoring an incoming transaction.
Calculate the supervised detector score and the anomaly verifier’s assessment.
Use the selected thresholds and agreement rule to allow, block, or hold the transaction for review.
Return the action, feature-level explanation, measured stage timings, and audit reference to the operations interface.
Inspect image
Inspect imageLower modeled detector loss vs. naive baseline
Transactions in the temporal holdout
Holdout traffic routed to review
Repository evaluation on IEEE-CIS data. The 40.6% comparison is for the capacity-capped detector against a rule that flags amounts above the training set’s 95th percentile. It uses full transaction value for missed fraud and an assumed ₹150 cost per false decline. The review share describes the separate three-way agreement policy. These are offline modeled results, not production savings.
The cost model uses a flat false-decline assumption and converts source USD amounts at a fixed ₹85 rate. Scores are not calibrated probabilities, review accounting assumes correct human decisions, and 14.4% of traffic still represents a substantial queue. A documented stress test found 2.43% of block/allow decisions changed after a 1% amount perturbation. Scheduled drift handling and adversarial evaluation are absent; the hash chain can be rewritten by someone controlling the entire log.
