Engineering project
Fraud-detection prototype with Kafka and Python
Event-driven ML
A transaction score becomes useful when an application knows how to act on it. This prototype separates structured transaction ingestion, model inference, and event routing so those responsibilities can be inspected independently—from a CSV replay source to two downstream result streams.
Project status
Engineering prototype · implemented development components. Software Sushi has source implementations for the producer, inference API, routing consumers, and a separate simulated interface. An end-to-end run, model evaluation, and production deployment have not been verified. The next milestone is a reproducible evaluation, not a production-results claim.
The buyer problem: connect the score to an explicit action
A team evaluating fraud detection needs more than a model output. It needs a contract for the incoming transaction, a consistent feature transformation, a rule for routing the score, and a clear boundary between a signal and a financial action.
A flagged event might become an input to review. A non-flagged event might continue to another system. Neither result, by itself, confirms fraud or proves that a payment has been approved, blocked, or settled. This project explores transaction classification and routing—the application plumbing that surrounds inference.
The implemented stack
- Python producer and consumers serialize transactions and handle the result branches.
- Kafka carries input events and separates flagged from non-flagged output streams.
- FastAPI defines the inference request and response contract.
- Random Forest is the model type the inference service is written to load from a serialized artifact.
- Docker Compose describes the local broker, inference, producer, and consumer services.
A companion React/TypeScript interface generates transactions and status transitions locally. It supports exploring a monitoring experience with simulated data, separately from the backend event path.
The backend event path
- 1 · Replay CSVPython producer
- 2 · PublishKafka input stream
- 3 · Request inferencePython consumer → FastAPI
- 4 · ScoreModel artifact → Random Forest inference → fixed-threshold routing decision
Not flagged → continuation
Transaction + prediction → continuation stream → its consumer.
Flagged → review signal
Transaction + prediction → alert stream → its consumer. A flag is not proof of fraud.
The model artifact and replay data were not verified in the inspected source. These branches do not represent payment authorization or settlement.
Decision one: separate the broker from the model
The Kafka consumer calls an inference service rather than embedding the model directly in event-handling code. Transport responsibilities stay in the producer and consumers; feature preparation and prediction stay behind the API.
This makes the seam between application and model explicit. It also introduces an HTTP dependency: an inference call can time out or fail. The current implementation logs failed scoring calls and returns without a normal prediction result. That behavior is a concrete starting point for a recovery contract, not a completed recovery mechanism.
The engineering tradeoff is useful to surface early. Isolated inference is easier to reason about, but its failure behavior must be designed alongside event processing—not added after the demo.
Decision two: treat classification as a policy input
The API returns a score, a Boolean classification, a risk label, and a model-version field. Its optional known label is used for testing rather than as a prediction feature. Keeping that label out of the inference input helps preserve the distinction between a predicted result and an answer available during evaluation.
The fixed threshold is a prototype choice. In an operational workflow, false positives consume review capacity and may interrupt legitimate activity; false negatives leave suspicious activity unflagged. Selecting an operating point requires representative data, an evaluation method, and an agreed action policy.
The response's confidence field is derived from the score. It is not a calibrated probability that the decision is correct. Routing should therefore express the selected action—such as review or continuation—without promoting a model signal into certainty.
Decision three: use simulation for interface questions
A locally generated transaction feed lets interface work explore scanning behavior, table layout, status changes, and mobile presentation without placing real transaction data in a demonstration.
It answers presentation questions, not model-quality questions. The prototype's interface uses generated events and local status transitions; its connection to backend events remains a separate integration task. An evaluation of inference needs the backend, approved inputs, and reproducible results rather than a convincing animation.
Remaining work: make evaluation reproducible
The model artifact and replay CSV required by the implementation were not present in the inspected source; their availability and provenance have not been verified. The first step is to establish approved artifacts and data, a consistent feature contract, and a reproducible end-to-end run. That creates a foundation for leakage-safe evaluation, threshold selection, and calibration assessment.
The next qualification work should cover scoring failures, retries or dead-letter handling, duplicate events, replay behavior, secure transport, access controls, and operational monitoring. The interface also needs to be connected and tested against backend events. A documented review or downstream action policy should define what each branch is allowed to trigger.
Latency, throughput, detection quality, and business impact would need their own measurements. This project currently supports an engineering discussion about the implementation and its seams, not a measured fraud-prevention outcome.
Technical lessons
- A model API is a contract. Feature preparation and response meaning need to be consistent across producers, consumers, and evaluation.
- A routing branch is not ground truth. Scores inform actions; action labels should preserve uncertainty.
- A demo and an evaluation answer different questions. Simulation can improve an interface while a reproducible run establishes what the backend actually does.
For teams considering custom machine learning development, the useful next milestone is a tested operational contract alongside model evaluation. Our AI/ML consulting work can help define the decision and evidence before expanding the system.
Define a testable transaction workflow
Start with the transaction source, the decision to support, and the action a downstream system may take. Discuss your transaction workflow.
