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.