SentinelFi

The engineering problem

A fraud system can miss harmful activity or block a legitimate user. A useful design therefore needs more than a score: stable event contracts, bounded synchronous checks, asynchronous enrichment, replay-safe consumers, versioned policies, authorization, and an operator path for held decisions.

The pipeline slice

1. The API records a pending action and an outbox event in one transaction.
2. A relay publishes a versioned event with a stable event ID.
3. Consumers enrich the event and record named risk signals.
4. A versioned policy maps signals and score to allow, challenge, review, or deny.
5. An operator can review a held action and record an override reason.
6. Replaying the original event must not repeat a completed side effect.

Evidence in the guide

Designing a fraud detection event pipeline in Node.js includes an event contract, transactional outbox, processed-event constraint, versioned signals, decision bands, audit record, missing-data states, monitoring plan, and uncomfortable-path test list.

What remains project work

Example rule weights and decision bands are illustrative and must not be treated as real fraud policy. A credible next step is to implement the complete slice, publish duplicate-delivery and failure-path tests, and document measurements from a named local test environment. The site will not claim fraud-detection accuracy or production scale without that evidence.

Code and author

See Aarav Chandel's GitHub profile for currently public repositories and project work.