Banks run two disconnected monitoring worlds: fraud teams watch transactions, SOC teams watch infrastructure. Neither sees the other. Sentinel is a correlation and risk-scoring layer that fuses both - plus a third quantum (HNDL) lane - into one explainable composite risk score, and closes the loop with a breach-proof self-history verification flow that auto-tunes away false positives.
This prototype demonstrates all six expected outcomes of the problem statement.
Just double-click index.html - it opens in any browser. No server, no
internet, no install. Everything (synthetic data, scoring engine, dashboards,
verification portal) runs in the page.
Pure standard library - no pip install needed.
cd engine
python data_generator.py # creates transactions.csv (~1.5 yrs of history)
python sentinel_engine.py # learns baselines, scores every txn, prints metrics
# + a live false-positive learning-loop demonstration
python quantum_risk.py # scans the crypto estate, writes a CycloneDX CBOM,
# scores PQC readiness, runs Mosca's inequality (HNDL)
python graph_analytics.py # builds the account↔device↔counterparty graph,
# detects the mule ring, prints the graph features
python metrics.py # BEFORE/AFTER benchmark: legacy baseline vs fusion -
# precision, recall, FP-rate, alert-to-case, latency
python shap_explain.py # exact Shapley reason codes (dependency-free SHAP)
python governance.py # tamper-evident audit log + drift (PSI) + fairness
python federated.py # privacy-preserving cross-bank consortium (hashed mule IDs)
python streaming.py # real-time pipeline (Kafka→consumer→Redis→scorer) + STR draft
python str_draft.py # standalone FIU-IND STR auto-draft sampleEvery transaction gets an additive, explainable risk score (0–100):
| Lane | Signals | Example points |
|---|---|---|
| ① Behavioural (money) | amount σ-deviation, off-pattern hour, new beneficiary, new geo, velocity spike | +8 … +35 |
| ② Cyber telemetry (SOC) | failed-login spike, device change, SIM-swap, impossible travel, IOC beneficiary | +20 … +40 |
| ③ Quantum / HNDL | TLS downgrade, non-PQC cipher, bulk encrypted exfil | +10 … +25 |
| ④ Graph / network | shared-device degree, mule-collector fan-in, pass-through velocity | +15 … +25 |
Correlation bonus (+20): when the money-lane and the cyber/quantum-lane both fire in the same session, the intersection is scored above the naïve sum and a named attack pattern is emitted (Account-Takeover, Mule/IOC, Credential-Stuffing, HNDL-staging). This is the thing legacy single-lane systems cannot do.
Graph escalation: the graph lane can hold a transaction on its own - a mule whose personal behaviour looks perfectly ordinary is still caught because the network around it (shared device → collector → cash-out) is a ring. Per-user baselines are structurally blind to this; the graph is not.
User category (Normal / Business / Merchant) is a sensitivity prior, not a static threshold - a merchant's high frequency is normal; the same pattern on a salaried account is not.
Decision: score ≥ 70 → HOLD · 45–69 → STEP-UP · < 45 → ALLOW (named critical patterns escalate to HOLD from 60).
- A HOLD routes the user to the Secure Verification Portal.
- Instead of Aadhaar / PAN / DOB / pet-name (all breachable), we ask a dynamic self-history challenge: "Which of these did you NOT do?" - pulled fresh from the user's own history, so an attacker cannot pre-harvest it.
- Pass → the hold was a false positive → the engine learns the beneficiary, widens that user's baseline, and dampens the dominant factor, so similar activity won't be re-flagged. The false-positive-rate KPI updates live.
- Fail → confirmed threat → account frozen, case opened, IOC shared.
This exact loop runs in both halves of the prototype: interactively in the
browser (applyFalsePositive) and headlessly in the Python engine
(mark_false_positive) - run python sentinel_engine.py to watch a held
transaction drop from 77 (HOLD) to 12 (ALLOW) after learning, while a
real takeover on the same user still holds at 100.
quantum_risk.py is a real quantum-risk engine, not a stub:
- Models a bank's cryptographic estate - 12 systems (core banking, UPI/IMPS gateway, SWIFT, ATM, HSM, data warehouse, …) and the 28 cryptographic assets they use.
- Emits a CycloneDX 1.6 CBOM (
bank_estate_cbom.json) - the exact Cryptographic Bill of Materials artifact IBM's CBOMkit / OWASP CycloneDX produce, and the artifact the RBI Q-SAFE committee (25 May 2026) now asks Indian banks to build. - Scores PQC readiness two ways - raw coverage (43%) and the sharper quantum-vulnerable-remediation rate (12%) that a bank actually cares about (raw coverage is flattering because AES-256/SHA-256 were never the quantum problem; only asymmetric crypto is).
- Runs Mosca's inequality -
shelf_life + migration_time > time_to_Q_day→ flags every long-retention data class (PII, KYC, transaction records, contracts) as already exposed to Harvest-Now-Decrypt-Later. - Maps each finding to its NIST replacement (RSA/ECDH → ML-KEM, FIPS 203; ECDSA/RSA-sign → ML-DSA, FIPS 204) and to the RBI Q-SAFE phase (M1 discovery / M2 hybrid / M3 full PQC).
In the browser demo, the Quantum Risk Monitor panel shows these numbers live, with an interactive Q-Day slider (2028–2035) that recomputes HNDL exposure.
Honest scope: this is cryptographic-posture monitoring (what crypto you run and how exposed it is), not literal quantum-attack detection. Q-Day (~2030) is a contested estimate and is labelled as such.
graph_analytics.py builds a graph of accounts ↔ devices ↔ counterparties over
a synthetic ledger with a planted fraud ring, and computes three cheap features:
- shared-device degree - one device fingerprint reused across many accounts
- fan-in / fan-out - money funnelling into a collector / spraying out
- pass-through velocity - money in, then straight out again (classic mule)
It detects the ring (3 mules on one device → a collector with fan-in 5 and ~100%
pass-through → an overseas cash-out) and exposes graph_bonus(), which feeds the
correlation score. Uses NetworkX when installed (production), with a pure-stdlib
fallback so it always runs. In the browser demo, the Fraud Ring Monitor panel
visualises the network live when you click ◉ Fraud Ring.
Why it matters: a mule transfer can look individually ordinary, so a per-user baseline passes it. The graph lane holds it anyway - the differentiator that separates enterprise-grade detection from a single-account scorer.
metrics.py scores a balanced, labelled eval set under two configurations -
a legacy baseline (behavioural lane only, what most rule engines do) and the
full four-lane fusion - and reports the before/after (representative run on
synthetic data):
| Metric | Legacy baseline | Sentinel (fusion) |
|---|---|---|
| Precision | 55% | 84% |
| Recall (detection) | 71% | 100% |
| False-positive rate | 42% | 14% |
| Alert-to-case ratio | 1.82 : 1 | 1.20 : 1 |
| p95 scoring latency | - | ~0.01 ms (p99 < 200 ms by ~5000×) |
Why fusion wins: the baseline flags legitimate big purchases (false alarms) and misses stealth mules whose behaviour looks normal - Sentinel fixes both: ~66% fewer false positives and +29 points of recall in one pass. The false-positive learning loop and graph lane give further lift on top of this. (Numbers are on synthetic data - they prove the mechanism, not a production SLA.)
The browser demo shows live precision / recall / FP-rate and a real in-browser p95 latency in the "Live Detection Metrics" panel.
Enterprise-grade AI needs governance, not just a model. Sentinel ships all four pieces a regulator asks for:
- SHAP reason codes (
shap_explain.py) - computes exact Shapley values over the scoring function, with zero external dependencies. Because the correlation bonus is a real interaction, Shapley fairly distributes it across the factors that earned it; the values sum exactly to the score (verified). - Model card (
MODEL_CARD.md) - one page: details, intended use, metrics, training data, limitations, and governance, in the Google Model Cards format. - Append-only audit log (
governance.py) - every decision is committed in a hash-chained, tamper-evident record. Altering any past entry breaks the chain and is detected - maps to EU AI Act Article 12 logging and WORM. - Drift + fairness (
governance.py) - PSI drift monitoring (retrain when0.2) and false-positive-rate parity across cohorts (4/5ths adverse-impact rule).
The browser's Model Governance panel shows the live hash-chained audit log (with an integrity badge), a live PSI drift tile, and a live fairness parity tile; every held transaction also shows its top Shapley reason codes.
- Federated consortium (
federated.py) - the biggest structural advantage in fraud detection is the data network: a mule flagged at one bank is relevant to all. Sentinel shares only salted one-way hashes of mule identifiers to a central registry - never raw accounts, devices, or customer data - so a mule flagged at HDFC is caught on first contact at another bank. DPDP-compliant, and aligned with RBI's proposed Digital Payments Intelligence Platform. The browser's Cross-Bank Consortium tile shows the hashed registry and live hits. - Streaming pipeline (
streaming.py) - the production reference architecture (Kafka → consumer → Redis feature store → scorer → decision), implemented with in-memory stand-ins that mirror the real components 1:1 (comments show the exact Kafka/Redis calls). Measures in-pipeline latency (sub-millisecond). - STR auto-draft (
str_draft.py) - a held mule/laundering transaction auto-drafts an FIU-IND Suspicious Transaction Report (PMLA) pre-filled with the transaction, grounds for suspicion, and ranked reason codes. Draft only - a human analyst must review before filing. In the browser, click 📄 Draft STR on any held card.
| Expected outcome | Where to see it |
|---|---|
| Correlates cyber telemetry with transactional behaviour | Correlation bonus + 3-lane score |
| Detects cyber threats proactively | Cyber lane (login/device/SIM signals) |
| Identifies fraud patterns | Named patterns + graph-based mule/ring detection |
| Detects quantum-related attack indicators | Quantum Risk Monitor panel (HNDL) |
| Reduces false positives | Fusion (−66% vs baseline) + verification → auto-adjust loop |
| Explainable AI-driven threat intelligence | Factor breakdown + exact Shapley reason codes + audit log |
sentinel/
├─ index.html # the self-contained live demo
├─ README.md # this file
└─ engine/
├─ data_generator.py # synthetic 1.5-yr history + correlated telemetry
├─ sentinel_engine.py # baseline learning + correlation scoring + FP learning loop + metrics
├─ quantum_risk.py # CBOM generation + PQC-readiness + Mosca/HNDL + NIST/RBI mapping
├─ graph_analytics.py # NetworkX graph + mule-ring detection + graph_bonus()
├─ metrics.py # before/after benchmark: baseline vs fusion + latency
├─ shap_explain.py # exact Shapley reason codes (no external library)
├─ governance.py # hash-chained audit log + PSI drift + FP-parity fairness
├─ federated.py # privacy-preserving cross-bank consortium (hashed indicators)
├─ streaming.py # real-time reference pipeline (Kafka→consumer→Redis→scorer)
├─ str_draft.py # FIU-IND Suspicious Transaction Report auto-draft (PMLA)
└─ bank_estate_cbom.json # generated CycloneDX 1.6 CBOM (28 cryptographic assets)
MODEL_CARD.md # model card (details, use, metrics, governance)