Fraud detection support - repeated submission of help requests

[RaoBhethanabotla]

A malicious user may submit too many help requests in our system in a short span to flood our system. To avoid this scenario, we will look at the number of requests a given user has submitted in a given window of time, say in the past 30 min. If he/she submits a request within that window, we will NOT allow this user to submit another request. We will reject this request asking user to submit a request after this period.

[shubhamnarkhede]

High-Level Requirements Document

Version: 1.0

1. Introduction

1.1 Purpose

The purpose of this document is to outline the high-level requirements for the Fraud Detection Microservice. This microservice will analyze incoming requests to detect if users are sending requests from multiple locations or making multiple requests in a short time and flag potential fraud or spam.

1.2 Scope This microservice will be a Django-based application, integrated into the existing product. It will serve as an intermediary layer before request handling, providing fraud or spam alerts for each request.

2. Functional Requirements

2.1 Data Integration

• PostgreSQL: Fetch historical request data, including user ID, request timestamps, and IP addresses.
• S3: Retrieve additional relevant data for fraud detection if necessary.
• Data Synchronization: Ensure data is regularly updated and synchronized between PostgreSQL and S3.

2.2 Feature Engineering

• Extract and analyze features such as:
  • Frequency of requests per user.
  • Geographical locations from which requests are made.
  • Time intervals between requests.

2.3 Detection Logic

• Implement logic to:
  • Identify users sending requests from multiple IP addresses or locations.
  • Detect users making multiple requests in a short period.

2.4 Authentication and Authorization

• Ensure secure access to the microservice with appropriate authentication and authorization mechanisms.

2.6 Logging and Monitoring

• Implement logging for all incoming requests and fraud detection results.
• Set up monitoring to track the performance and accuracy of the detection logic.

2.7 Continuous Learning

• Implement a mechanism to update the detection logic based on new patterns or data.

3. Non-Functional Requirements

3.1 Performance

• The microservice should be able to handle high request volumes with minimal latency.

3.2 Scalability

• The system should be designed to scale horizontally to handle increased load.

3.3 Reliability

• Ensure high availability and fault tolerance.
• Implement retry mechanisms for data fetching and detection failures.

3.4 Security

• Ensure data privacy and protection.
• Implement measures to prevent unauthorized access and data breaches.

3.5 Compliance

• Ensure the microservice complies with relevant data protection regulations and industry standards.