Fraud Detection AI/ML Demo

FRM Demo
AI/ML-Based Fraud Risk Management (FRM) – Detailed Requirements Document

1. Detailed Use Cases
Below are the expanded fraud scenarios the system must be able to detect and act on:

1.1 Geographical Impossibility
• Scenario: Same card used in India, then within 5 minutes in the US.
• Logic: Compare transaction timestamp, geolocation, and physical distance. If travel time is infeasible, mark high risk.
• System Requirement:
○ Geolocation lookup for each transaction (POS, ATM, online).
○ Compute "travel feasibility score".
○ Threshold flagging (e.g., >500 km in <30 min = impossible).

1.2 Multiple Transactions from Same IP Range
• Scenario: Large volume of transactions initiated from a single IP/subnet in a short span.
• Logic: Check velocity of requests from IP. Compare against customer’s normal usage.
• System Requirement:
○ Track per-IP velocity counters.
○ Correlate transactions across multiple accounts.
○ Flag anomalies (botnet or attack).

1.3 Unusual Transaction Amount/Pattern
• Scenario: A customer who spends ~$100/day suddenly initiates a $10,000 transfer.
• Logic: Compare against historical behavior profile (avg spend, transaction frequency).
• System Requirement:
○ Build dynamic spending profile per customer.
○ Calculate deviations (Z-score, percentile thresholds).
○ Flag if deviation > configured threshold.

1.4 Device & Location Mismatch
• Scenario: Login from a new device in Russia, while customer is actively logged in from India.
• Logic: Correlate active session devices and geolocations.
• System Requirement:
○ Maintain device fingerprint DB.
○ Detect simultaneous logins from far-apart geos.
○ Apply step-up authentication (OTP/biometric).

1.5 Velocity Checks (Rapid-Fire Transactions)
• Scenario: 10 transactions within 1 minute from same card.
• Logic: Detect abnormal burst patterns.
• System Requirement:
○ Sliding window counters per card/account.
○ Thresholds by transaction type (ATM vs e-commerce).
○ Auto-block after X attempts.

1.6 Merchant Category Anomaly
• Scenario: Card typically used at grocery stores; suddenly used at a gambling site.
• Logic: Compare merchant category codes (MCC) against customer’s historical MCC profile.
• System Requirement:
○ Maintain merchant category usage profile.
○ Flag anomalies outside historical spend type.

1.7 Account Takeover Indicators
• Scenario: Password reset → login from new device → high-value transfer.
• Logic: Correlate sequence of events within suspicious timeframe.
• System Requirement:
○ Event correlation engine linking login, password reset, transaction.
○ Alert on “high-risk chain of events.”

1.8 Synthetic Identity or Mule Accounts
• Scenario: Many accounts linked to same phone/email doing repeated inward/outward transfers.
• Logic: Network graph analysis on linked accounts.
• System Requirement:
○ Maintain KYC linkage graph (phone, email, address, IP).
○ Detect circular/mule activity patterns.

1.9 Time-of-Day / Behavior Anomaly
• Scenario: User never transacts at night; sudden midnight high-value UPI payment.
• System Requirement:
○ Build transaction time distribution profile.
○ Flag out-of-pattern timings.

1.10 Suspicious Payment Routing
• Scenario: Multiple small-value transfers split just below reporting limit (structuring/smurfing).
• System Requirement:
○ Detect cumulative transfers > threshold within timeframe.
○ Rule: “If 5+ payments within 30 min, summing > $10,000 → flag.”

1.11 Fraudulent IP/Device Reputation
• Scenario: Transaction initiated from IP flagged in external blacklist (TOR, proxy, fraud DB).
• System Requirement:
○ Integrate IP/device reputation feeds.
○ Auto-block high-risk sources.


2. Functional Requirements (FR)
Each use case maps to system functionality.
2.1 Transaction Data Capture
• Capture transaction data in real time from CBS, card switches, UPI gateways, and payment APIs.
• Data attributes: amount, time, location, merchant ID, device ID, IP, channel (ATM, POS, e-commerce).
2.2 AI/ML Fraud Scoring
• Generate fraud risk score (0–100) for each transaction.
• Combine features:
○ Customer profile (spend, timing, geography).
○ Transaction velocity.
○ Device/IP fingerprint.
○ External reputation feeds.
2.3 Business Rules Engine
• Configurable rules for quick deployment without code changes.
• Examples:
○ Rule: “Geo distance > 1000 km within 15 min → score +50.”
○ Rule: “>5 failed OTP attempts in 10 min → auto-block.”
2.4 Event Correlation Engine
• Correlate related events (login → password reset → transfer).
• Detect suspicious sequences within rolling time windows.
2.5 Case Management
• Create fraud case automatically if score > threshold.
• Analyst dashboard with:
○ Transaction details.
○ Customer history.
○ Linked entities (devices, IPs, accounts).
2.6 Customer Communication
• Automated alerts for suspicious activity (SMS, push, email).
• Confirm/Deny mechanism for high-risk flagged transactions.
2.7 Integration
• Inbound: CBS, payment gateways, card switches, device tracking systems.
• Outbound: Notification systems, regulatory reporting modules, external fraud feeds.
2.8 Reporting & Compliance
• Standard fraud metrics dashboard.
• Compliance reporting for regulators (RBI suspicious transaction reports, PCI audits).

3. Non-Functional Requirements (NFR)
3.1 Performance
• Decision latency: <200ms per transaction.
• Throughput: ≥ 10M transactions/hour.
3.2 Scalability
• Horizontally scalable (microservices + Kafka/streaming pipelines).
3.3 Availability & Reliability
• Uptime: 99.99%.
• HA/DR setup with auto-failover.
3.4 Security
• Data encryption (AES-256 at rest, TLS 1.3 in transit).
• RBAC and 2FA for system access.
• PCI-DSS and GDPR compliance.
3.5 Explainability
• Fraud model must provide reasons (“geo-location anomaly, IP flagged”) → required for analyst review & audit.
3.6 Maintainability
• Rule engine UI for non-technical staff.
• Retrain ML models periodically with fresh fraud data.
3.7 Monitoring
• System health monitoring (latency, error rate).
• Fraud detection KPIs (Fraud detection rate, False Positive Rate).

4. Data Requirements
• Historical fraud-labeled transaction dataset.
• Streaming transaction data feeds.
• Customer KYC & behavior profiles.
• Device fingerprint repository.
• Blacklists (IP, device, card BINs).

5. Deliverables
1. Real-time fraud detection engine (AI + Rules).
2. Business rules management UI.
3. Case management dashboard.
4. Customer alerting & confirm/deny workflow.
5. Fraud detection reports & compliance reports.
6. API layer for integration.

6. Success Metrics
• Fraud Detection Rate ≥ 95%.
• False Positive Rate ≤ 2%.
• Transaction decision time <200ms.
• Regulatory compliance coverage = 100%.

On successful completion of this demo project, I'll provide an opportunity to work on full project with higher pay.