Fraud Detection That Starts From the Regulator's Checklist

Most fraud demos open with a model and a leaderboard score. When I built MuleShield AI for the Bank of India CyberShield 2026 hackathon, I wanted the repository to open with a different question: what would a bank's compliance team need to see before it could use this at all?

MuleShield detects mule accounts, the accounts used to move stolen money. The core is an ensemble of XGBoost and LightGBM, with SHAP values attached to each score so an analyst can see why an account was flagged. Around it sit the pieces a bank workflow needs: an ingestion service, a feature store, model serving, a decision engine, case management and a React dashboard for analysts. The services run on FastAPI with async PostgreSQL and Redis, and the whole stack starts with one Docker Compose command.

The checklist is in the repo

The repository carries an audit report dated June 15, 2026, written by Mynd Labs quality assurance. It is organised as a compliance matrix. Against the RBI MuleHunter.AI framework it lists velocity features such as transaction counts over one hour, 24 hours and seven days, counterparty diversity, a credit to debit ratio with an 8 to 1 threshold, a new account flag, and night and weekend ratios. It also names two rules, one for structuring and one for rounding patterns that point to layering.

Scores you can explain, cases you can track

The decision engine blends the two signals, 60 percent from the model and 40 percent from rules, and the report lists four severity levels with automatic blocking at the top. Flagged accounts move into a case workflow with assignment. The audit log is written through a PostgreSQL trigger, so entries are not edited after the fact.

Reports and privacy

For reporting, the matrix covers the FIU-IND suspicious transaction report format. Report identifiers follow the pattern STR-BOI-YYYYMMDD-XXXXXXXX, and the PDF is generated with ReportLab. On privacy, account identifiers are tokenized with SHA-256, personal data is encrypted with AES-256 through Fernet with a PBKDF2 key derivation at 480,000 iterations, and access control has four roles. The same matrix maps these to PMLA 2002 and the DPDP Act 2023. It is how the project checks itself against those rules.

I think this is the right order for fraud tooling. A model that scores well but cannot produce a report, an explanation or an audit trail is a demo. A system that starts from the obligations and then fits a model into them is closer to something a bank could review. The code is public at github.com/yethikrishna/muleshield-ai.