An AI-powered payment intelligence system that combines real-time transaction risk scoring with intelligent revenue recovery. The system first evaluates the transaction for fraud risk and generates a risk score. If the transaction fails, the system identifies the failure reason and decides whether recovery is worth pursuing and which action makes the most financial sense. Instead of blindly retrying every failed transaction, the Recovery Agent uses an expected-value calculation to choose the best action. The whole process is controlled by compliance and stopping rules, with a tamper-evident audit trail that records important decisions.
https://ai-risk-manager-recovery-agent-3tucanb6m3tyzxqv8vb2kd.streamlit.app/
Merchants lose revenue in two connected ways:
Risk: Fraudulent or suspicious transactions can cause financial losses, chargebacks, and operational risk or legitimate customers getting wrongly blocked. Revenue Loss: Legitimate failed transactions that are never followed up on can also result in lost revenue if they are not recovered effectively.
These two problems are closely connected in the payment flow. This project brings them together in a single workflow: the transaction is first evaluated for risk, and if it fails, the system then determines whether recovery is worthwhile and which action should be taken.
Assess risk → Process transaction → Diagnose failure → Estimate recovery value → Select action → Execute → Audit
The system contains two connected AI components:
- Risk Manager Analyzes transaction and customer-related information to generate a risk score before the transaction completes. It considers:
Transaction amount Payment method IP risk score Device type Transaction velocity Merchant category Customer transaction history Customer success rate Time-based transaction patterns
The model converts these signals into a risk score, a risk band, and a decision:
Risk Score: 0.9235 Risk Band: HIGH Decision: BLOCK
- Recovery Agent If a transaction fails, the Recovery Agent diagnoses the root cause (insufficient funds, OTP mismatch, bank downtime, card expired, network issue, or fraud-flagged).
It then evaluates every possible recovery action — retry, SMS nudge, WhatsApp nudge, alternate payment method, or human escalation — using an EV calculator:
Expected Value = P(success) x amount - cost
The action with the highest expected value is selected.
-
Stopping Rules Hard limits enforced on every decision: never pursue a customer who opted out, never auto-pursue a high-risk or fraud-flagged transaction, never exceed the retry limit, never act on negative expected value.
-
Audit Trail Every decision is logged to a hash-chained audit trail. If a previous entry is modified, chain verification detects the tampering.
The predicted risk score is converted into a decision band.
Risk Score < 0.30 --> LOW
0.30 ≤ Risk Score < 0.60 --> MEDIUM
Risk Score ≥ 0.60 --> HIGH
The Risk Manager and Recovery Agent are not independent systems. The risk score generated before the transaction is reused during recovery.For example: Failed + Low Risk ↓ Aggressive recovery may be appropriate
Failed + High Risk ↓ Avoid aggressive automated recovery ↓ Escalate / Stop
This prevents the recovery system from trying to recover transactions that may themselves be suspicious.
flowchart TD
A[Customer attempts payment] --> B[Risk Manager calculates risk score]
B --> C[Risk = LOW]
C --> D[Payment fails]
D --> E[Reason: Network Issue]
E --> F[Recovery Agent evaluates candidate actions]
F --> G[Retry<br/>EV = ₹X]
F --> H[Switch Method<br/>EV = ₹Y]
F --> I[Escalate<br/>EV = ₹Z]
G --> J[Highest EV action selected]
H --> J
I --> J
J --> K[Action executed]
K --> L[Result recorded]
L --> M[Audit entry added to hash chain]
| Metric | Baseline (Logistic Regression) | Main Model (XGBoost) |
|---|---|---|
| Precision | 0.291 | 0.313 |
| Recall | 0.613 | 0.505 |
| F1 Score | 0.394 | 0.387 |
| PR-AUC | 0.437 | 0.415 |
Confusion matrix (XGBoost): 1404 true negatives, 103 false positives, 46 false negatives, 47 true positives.
XGBoost trades some recall for meaningfully fewer false positives than the baseline — fewer legitimate customers wrongly blocked, at a small cost in fraud caught. Both numbers are reported honestly rather than optimizing for one flattering metric, since fraud detection on a ~5% base rate makes plain accuracy meaningless.
| Metric | Naive Baseline | Smart Agent |
|---|---|---|
| Strategy | Blind retry | EV-optimized + risk-aware |
| Net value recovered | ₹736,761 | ₹1,268,528 |
+72.2% improvement (Rs.531,767) over a naive blind-retry approach.
Of 354 failed transactions in the test batch, the agent pursued 146 and correctly declined to pursue 208 (fraud-flagged, opted-out, high-risk, or negative expected value) — the naive baseline would have blindly attempted all of them.
Audit trail: 501 decisions logged, hash chain verified intact end to end.
Compliance cross-check: of all transactions the risk model scored as high-risk, 100% were withheld from automatic recovery pursuit and correctly escalated instead of blindly retried — the concrete proof that the risk score and recovery decision are genuinely linked, not two separate systems.
ai-risk-manager-and-recovery-agent/
├── app.py Streamlit dashboard
├── requirements.txt
├── data/
│ ├── generate_data.py synthetic transaction dataset + recovery simulator
│ ├── train.csv
│ └── holdout_test.csv
├── risk_manager/
│ ├── feature_engineering.py
│ ├── train.py trains baseline (Logistic Regression) + main model (XGBoost)
│ ├── evaluate.py precision/recall/PR-AUC/false-positive-cost on holdout
│ ├── predict.py scores a single transaction or batch
│ └── model.pkl
├── recovery_agent/
│ ├── diagnose.py root cause diagnosis
│ ├── policy.py EV calculator and action selection
│ ├── stopping_rules.py compliance and safety limits
│ ├── execute.py batch run on holdout, naive baseline comparison
│ └── audit_log.py hash-chained decision trail
├── results/ final metrics, batch recovery report
│ ├── holdout_metrics.json
│ ├── batch_recovery_report.json
│ └── audit_trail.jsonl
└── tests/
├── test_stopping_rules.py
└── test_policy_ev.py
python -m venv venv
venv\Scripts\activate # Windows
source venv/bin/activate # Mac/Linux
pip install -r requirements.txt
cd data && python generate_data.py && cd ..
cd risk_manager && python train.py && python evaluate.py && cd ..
cd recovery_agent && python execute.py && cd ..
python -m pytest tests/ -v
streamlit run app.pyPython, XGBoost, scikit-learn, pandas, Streamlit, Hash-based audit logging.
All data is synthetically generated (data/generate_data.py).
true_recovery_probability in the dataset is a hidden ground-truth value used only to simulate realistic outcomes in execute.py — it is never used as a model input.
Soumya Rai
B.Tech — Data Science
This project was developed as an AI-driven payment risk and revenue recovery system combining machine learning, decision intelligence, and auditable automation.