Turn failed payments into measurable recovery opportunities.

RecoverX is an AI-powered revenue recovery system designed to identify failed payments, estimate recovery potential, determine the root cause, recommend the next best recovery action, enforce safety policies, and measure recovered revenue.

The system combines risk scoring, AI-agent decision logic, deterministic policy enforcement, payment simulation, human approval, prioritization, and audit logging into a single end-to-end workflow.

Payment failures do not always mean permanent revenue loss.

Transactions can fail because of:

• Bank timeouts
• Network errors
• Insufficient funds
• Expired payment methods
• Payment limits
• Authentication failures
• Suspected fraud

Different failure reasons require different recovery strategies.

RecoverX analyzes each failed transaction and determines:

1. How likely is this payment to be recovered?
2. How much revenue is potentially recoverable?
3. Why did the payment fail?
4. What recovery action should be attempted?
5. Is the action allowed by the safety policies?
6. Does the recovery require human approval?
7. How much revenue was actually recovered?

Identifies failed transactions and calculates the amount of revenue currently at risk.

Estimates the probability that a failed transaction can be successfully recovered using:

• Failure reason
• Customer payment history
• Payment success rate
• Engagement score
• Previous attempts

Calculates the expected monetary recovery opportunity:

Expected Recoverable Revenue
= Transaction Amount × Recovery Probability

Classifies payment failures into meaningful causes such as:

BANK_TIMEOUT
        ↓
TEMPORARY_BANK_FAILURE

CARD_EXPIRED
        ↓
EXPIRED_PAYMENT_METHOD

FRAUD_SUSPECTED
        ↓
POTENTIAL_FRAUD

Selects an appropriate recovery strategy based on the failure reason and recovery probability.

Supported strategies include:

• Delayed Retry
• Payment Link
• Reminder
• Payment Method Update
• Human Escalation

The AI recommendation must pass through deterministic safety rules before execution.

Policies include:

• Maximum retry limits
• Maximum customer contact limits
• Fraud protection
• High-value transaction approval
• Controlled execution

High-value transactions are not automatically executed.

Instead:

High-Value Transaction
        ↓
Human Approval Request
        ↓
PENDING
        ↓
APPROVE / REJECT
        ↓
Recovery Execution

RecoverX currently uses a payment simulator to safely demonstrate recovery execution without moving real customer money.

This makes the project suitable for testing and demonstrations.

Recovery opportunities are ranked using:

• Expected recoverable revenue
• Risk score
• Customer friction

This allows the system to identify the most valuable recovery opportunity first.

Important system decisions and outcomes are recorded in an audit log.

The audit trail includes:

• Timestamp
• Transaction ID
• Recovery strategy
• Recovery probability
• Expected revenue
• Risk score
• Policy decision
• Human approval request
• Recovery result

                 ┌──────────────────────┐
                 │   Transaction Data   │
                 │   Customer Data      │
                 └──────────┬───────────┘
                            │
                            ▼
                 ┌──────────────────────┐
                 │     Risk Engine      │
                 │ Recovery Probability │
                 │ Expected Revenue      │
                 │ Risk Score            │
                 └──────────┬───────────┘
                            │
                            ▼
                 ┌──────────────────────┐
                 │   Root Cause Agent   │
                 │ Failure Classification│
                 └──────────┬───────────┘
                            │
                            ▼
                 ┌──────────────────────┐
                 │ Recovery Strategy    │
                 │       Agent          │
                 └──────────┬───────────┘
                            │
                            ▼
                 ┌──────────────────────┐
                 │    Policy Engine     │
                 │  Safety & Guardrails │
                 └──────────┬───────────┘
                            │
                  ┌─────────┴─────────┐
                  │                   │
                  ▼                   ▼
           ┌──────────────┐    ┌───────────────┐
           │ Auto Recovery│    │Human Approval │
           └──────┬───────┘    └───────┬───────┘
                  │                    │
                  └─────────┬──────────┘
                            ▼
                 ┌──────────────────────┐
                 │  Payment Simulator   │
                 └──────────┬───────────┘
                            │
                            ▼
                 ┌──────────────────────┐
                 │ Recovery Outcome     │
                 │ Recovered / Failed   │
                 └──────────┬───────────┘
                            │
                            ▼
                 ┌──────────────────────┐
                 │     Audit Logger     │
                 └──────────────────────┘

RecoverX/
│
├── backend/
│   ├── __init__.py
│   ├── main.py
│   ├── database.py
│   ├── models.py
│   ├── risk_engine.py
│   ├── agents.py
│   ├── policy_engine.py
│   ├── recovery_engine.py
│   ├── simulator.py
│   ├── friction.py
│   ├── prioritization.py
│   ├── audit.py
│   └── approval.py
│
├── data/
│   ├── transactions.csv
│   ├── customers.csv
│   └── audit_log.jsonl
│
├── frontend/
│   └── app.py
│
├── generate_data.py
├── run_demo.py
├── test_approval.py
├── requirements.txt
├── .gitignore
└── README.md

RecoverX follows the workflow:

Detect
  ↓
Predict
  ↓
Diagnose
  ↓
Recommend
  ↓
Validate
  ↓
Human Approval (if required)
  ↓
Execute
  ↓
Measure
  ↓
Audit

The system starts with a base probability and adjusts it based on transaction and customer characteristics.

Factors include:

• Failure reason
• Customer success rate
• Engagement score
• Previous attempts

The probability is bounded between:

0.02 and 0.98

RecoverX combines recovery probability and transaction value to calculate a risk score.

The score helps prioritize valuable recovery opportunities.

Recovery opportunities are ranked using:

Priority Score
=
(Expected Recoverable Revenue × Risk Score)
÷ Customer Friction

This helps the system balance:

Revenue Opportunity + Recovery Probability + Customer Experience

RecoverX follows a bounded automation approach.

FRAUD_SUSPECTED
       ↓
NO AUTOMATIC RETRY

The system prevents unlimited retry attempts.

The system limits repeated customer messages.

Transactions above the configured threshold require human approval.

Amount > ₹50,000
        ↓
HUMAN_APPROVAL

This ensures that the AI system does not have unrestricted execution authority.

For high-value transactions:

Transaction
     ↓
Policy Engine
     ↓
HUMAN_APPROVAL
     ↓
Approval Request Created
     ↓
PENDING
     ↓
 ┌───────────────┐
 │               │
 ▼               ▼
APPROVE        REJECT
 │               │
 ▼               ▼
Execute         Stop
 │
 ▼
Recovery Result

RecoverX maintains an audit trail using JSON Lines.

Example events include:

RECOVERY_DECISION
HUMAN_APPROVAL_REQUESTED
RECOVERY_RESULT
APPROVED_RECOVERY_RESULT

This provides traceability for recovery decisions and outcomes.

The Streamlit dashboard provides an operational view of the recovery system.

The dashboard includes:

• Revenue at Risk
• Expected Recoverable Revenue
• Recovery Rate
• Transaction Count

Provides transaction-level information including:

• Transaction ID
• Customer
• Amount
• Failure Reason
• Recovery Probability
• Expected Recoverable Revenue
• Risk Score
• Friction
• Recommended Strategy

Highlights the highest-priority recovery opportunity.

The operator can immediately see:

• Customer
• Revenue at Risk
• Expected Recovery
• Priority Score
• Recovery Probability
• Friction
• Risk Score
• Recommended Action

RecoverX currently uses simulated payment execution.

No real customer money is moved.

This allows the complete recovery workflow to be demonstrated safely:

Failed Payment
      ↓
AI Analysis
      ↓
Recovery Recommendation
      ↓
Policy Validation
      ↓
Simulated Recovery
      ↓
Recovered Revenue

git clone <(https://github.com/NipurnCoder/RecoverX)>
cd RecoverX

python -m venv venv

Activate it:

venv\Scripts\activate

pip install -r requirements.txt

If the dataset is not already available:

python generate_data.py

This generates:

data/transactions.csv
data/customers.csv

Start the FastAPI server:

python -m uvicorn backend.main:app --reload

The API will be available locally at:

http://127.0.0.1:8000

API documentation:

http://127.0.0.1:8000/docs

Open another terminal with the virtual environment activated.

Run:

streamlit run frontend/app.py

The dashboard will open at:

http://localhost:8501

The recovery API can be tested using:

POST /recover/{transaction_id}

For example:

POST /recover/TXN001

The system will:

1. Load the transaction
2. Find the customer
3. Calculate recovery probability
4. Calculate expected recoverable revenue
5. Identify the root cause
6. Select a recovery strategy
7. Evaluate policy
8. Execute allowed recovery
9. Record the result
10. Write an audit event

The project includes a controlled high-value test.

Run:

python test_approval.py

This creates a temporary high-value transaction in memory.

It does not modify the original transaction dataset.

The transaction is passed through the policy engine and generates:

HUMAN_APPROVAL

with:

PENDING

approval status.

RecoverX follows several important design principles:

The AI-style agents recommend recovery actions, but the Policy Engine determines whether the action is permitted.

The system has limits on retries and customer communication.

High-value recovery actions require human approval.

Suspected fraud is not automatically retried.

The system measures actual recovered revenue rather than only generating recommendations.

Important decisions and outcomes are recorded in the audit log.

RecoverX can help businesses:

• Reduce revenue leakage
• Prioritize valuable failed payments
• Automate low-risk recovery actions
• Reduce unnecessary customer friction
• Prevent unsafe automated retries
• Improve recovery operations
• Measure actual recovered revenue
• Maintain an auditable recovery process

The current project uses a payment simulator for safe demonstration.

Future versions could integrate:

• Razorpay Test Mode
• Real payment webhooks
• Production payment events
• Real-time recovery monitoring
• More advanced ML models
• LLM-based root-cause reasoning
• A/B testing of recovery strategies
• Recovery campaign optimization
• Merchant-specific policies
• Real-time revenue recovery analytics

The architecture is designed so that the simulator can eventually be replaced with a controlled payment-gateway integration.

The objective of RecoverX is not simply to predict failed payments.

It is to build a complete recovery decision system that can:

Find revenue at risk
        ↓
Understand why it is at risk
        ↓
Estimate recovery potential
        ↓
Choose the best intervention
        ↓
Apply safety policies
        ↓
Execute safely
        ↓
Measure recovered revenue
        ↓
Create an audit trail

RecoverX doesn't just ask, "What went wrong?"

It asks, "What can we recover, what is the safest way to recover it, and how much revenue did we actually win back?"

NIPURN

AI / Machine Learning Project — Revenue Recovery

This project is developed for educational and internship demonstration purposes.