Anti-Fraud System

JetBrains Academy. Project: Anti-Fraud System.

About

A RESTfull web service with using SpringBoot and the basics of user authentication and authorization.

This project demonstrates (in a simplified form) the principles of anti-fraud systems in the financial sector. It needs to work on a system with an expanded role model, a set of REST endpoints responsible for interacting with users, and an internal transaction validation logic based on a set of heuristic rules.

The role model for system:

	Anonymous	MERCHANT	ADMINISTRATOR	SUPPORT
POST /api/auth/user	+	+	+	+
DELETE /api/auth/user	-	-	+	-
GET /api/auth/list	-	-	+	+
POST /api/antifraud/transaction	-	+	-	-
PUT /api/auth/access	-	-	+	-
PUT /api/auth/role	-	-	+	-
POST, DELETE, GET api/antifraud/suspicious-ip	-	-	-	+
POST, DELETE, GET api/antifraud/stolencard	-	-	-	+
GET /api/antifraud/history	-	-	-	+
PUT /api/antifraud/transaction	-	-	-	+

ADMINISTRATOR is the user who has registered first, all other users
should receive the MERCHANT roles. All users added after ADMINISTRATOR
must be locked by default and unlocked later by ADMINISTRATOR.
The SUPPORT role should be assigned by ADMINISTRATOR to one of
the users later.

Validation:

• In the system IP addresses will check for compliance with IPv4.
  Any address following this format consists of four series of numbers
  from 0 to 255 separated by dots.

• Card numbers must be checked according to the Luhn algorithm.

Correlation to fraud detection rules:

• The transaction event correlate with the world region and the transaction date.
  The table for world region codes:

Code	Description
EAP	East Asia and Pacific
ECA	Europe and Central Asia
HIC	High-Income countries
LAC	Latin America and the Caribbean
MENA	The Middle East and North Africa
SA	South Asia
SSA	Sub-Saharan Africa

A transaction containing a card number is PROHIBITED if:

1. There are transactions from more than 2 regions of the world other than the region
   of the transaction that is being verified in the last hour in the transaction history;

2. There are transactions from more than 2 unique IP addresses other than the IP of the
   transaction that is being verified in the last hour in the transaction history.

A transaction containing a card number is sent for MANUAL_PROCESSING if:

1. There are transactions from 2 regions of the world other than the region of the transaction
   that is being verified in the last hour in the transaction history;

2. There are transactions from 2 unique IP addresses other than the IP of the transaction
   that is being verified in the last hour in the transaction history.

Adaptation mechanisms: feedback

Feedback carried out manually by a SUPPORT specialist for completed transactions. Based on the feedback
results, we will change the limits of fraud detection algorithms following the special rules.

Transaction Feedback → Transaction Validity ↓	ALLOWED	MANUAL_PROCESSING	PROHIBITED
ALLOWED	Exception	↓ max ALLOWED	↓ max ALLOWED ↓ max MANUAL
MANUAL_PROCESSING	↑ max ALLOWED	Exception	↓ max MANUAL
PROHIBITED	↑ max ALLOWED ↑ max MANUAL	↑ max MANUAL	Exception

Technologies

• Authentication
• Authorization
• Getting data from REST, posting and deleting data via REST

Frameworks & libraries:

• Spring Boot
• Spring Security
• Spring Data JPA
• Lombok
• Swagger 3.0

Database:

• PostgreSQL

Build Tool:

• Gradle

Containerization platform:

• Docker

API

Documentation in .yaml format