TransactAlert — Asynchronous Fraud Alert Service

TransactAlert is a multi-service, event-driven fraud detection system built with Java, Spring Boot, and JMS. It models how a financial institution might decouple transaction ingestion from fraud analysis: a REST API accepts transactions and immediately hands them off to a message broker, freeing downstream fraud logic to run independently, at its own pace, without blocking the API.

The system is composed of four Maven modules, each with a single responsibility, communicating asynchronously through an ActiveMQ Artemis broker.

Financial institutions process high volumes of transactions and cannot afford for fraud analysis to block transaction ingestion. A synchronous design — where the API waits for a full fraud check before responding — creates slow customer-facing responses, tight coupling between unrelated concerns, and poor scalability under load.

TransactAlert addresses this by separating the two concerns entirely: ingestion and fraud analysis run as independent services, connected only by message queues.

                Client Application
                        |
                        v
              transaction-service
              (REST API, Spring Boot)
                        |
                        v
              JMS Producer  →  "fraud.queue"
                        |
                        v
             ActiveMQ Artemis Broker
                        |
                        v
                fraud-service
           (JMS Consumer + Rule Engine)
                        |
             ┌──────────┴──────────┐
             |                     |
      transaction safe     fraud detected
             |                     |
             |         JMS Producer → "fraud.alerts"
             |                     |
             |          notification-service
             |          (JMS Consumer)

common-library is shared across services and defines the message contracts (TransactionEvent, FraudAlertEvent) so every service agrees on the same data shape without duplicating class definitions.

1. Transaction submission

POST /transactions
Content-Type: application/json

{
  "customerId": "C001",
  "amount": 85000,
  "merchant": "Online Store",
  "location": "Cape Town"
}

transaction-service validates the request (Jakarta Bean Validation), generates a transaction reference, publishes a TransactionEvent to the fraud.queue, and returns immediately — without waiting on any fraud check:

{
  "transactionId": "TX-3f21a9...",
  "status": "RECEIVED"
}

2. Fraud analysis

fraud-service consumes each TransactionEvent from fraud.queue and evaluates it against rule-based fraud logic:

• transaction amount exceeds a defined threshold
• merchant matches a known high-risk pattern

Each transaction receives a calculated risk score. Transactions that trip a rule are published to the fraud.alerts queue for downstream handling.

3. Notification

notification-service consumes messages from fraud.alerts and represents the point where a real system would alert a fraud analyst, trigger a case in a case-management tool, or notify the customer.

transact-alert/
├── common-library/          shared event contracts (TransactionEvent, FraudAlertEvent)
├── transaction-service/     REST API — validates & publishes transactions
│   ├── controller/          HTTP layer
│   ├── service/             orchestration logic
│   ├── producer/            JMS producer
│   └── model/                request/response DTOs
├── fraud-service/           JMS consumer — fraud rule evaluation
│   ├── consumer/            JMS listener
│   ├── rules/                fraud rule engine
│   └── producer/            publishes fraud alerts
├── notification-service/    JMS consumer — alert handling
│   └── consumer/            JMS listener
├── infrastructure/          docker-compose.yml — ActiveMQ Artemis broker
└── README.md

# Start the ActiveMQ Artemis broker
cd infrastructure
docker compose up -d

# Build the shared library (required by all services)
cd ../common-library
mvn clean install

# Run each service in its own terminal
cd ../transaction-service && mvn spring-boot:run
cd ../fraud-service        && mvn spring-boot:run
cd ../notification-service && mvn spring-boot:run

• Design and implementation of event-driven, multi-service architecture
• REST API development with Spring Boot, including request validation
• Asynchronous messaging with JMS and ActiveMQ Artemis
• Producer/consumer pattern across independently deployable services
• Shared contract design via a common Maven module
• Rule-based decision logic (fraud rule engine with weighted risk scoring)
• Multi-module Maven project structuring

• Persist transactions, alerts, and rule history in PostgreSQL
• Structured logging and centralized error handling
• Automated test coverage (JUnit, Spring Boot Test)
• Containerize all services with Docker and orchestrate with Kubernetes
• Expand fraud detection with velocity checks, geolocation anomaly detection, and ML-based risk scoring
• GraphQL query layer for fraud analyst tooling

Benit Matumona GitHub: https://github.com/benitmatumona