← Case Studies SIEF ALSHEYAB / CASE STUDY Resume ↗
Fintech Risk · Full-Stack Engineering · Production

Payments Fraud Detection Engine

A Ruby on Rails-based fraud detection system designed to flag high-risk account activations using stolen payment cards across a global fintech platform. Deployed at scale across 100+ countries, handling 15–25 dispute cases daily alongside automated risk decisioning.

45%Reduction in High-Risk Activations
100+Countries Covered
5PSPs Integrated
15–25Disputes Resolved Daily

Problem

A proprietary trading platform serving retail traders across 100+ countries was experiencing a significant volume of fraudulent account activations using stolen payment cards. Fraudsters would activate accounts, receive funded access, extract value, and chargeback — creating both financial loss and PSP chargeback ratio risk.

Existing controls were manual and reactive: disputes were identified only after the fact, creating lag between fraud event and account suspension. No automated risk scoring existed at the point of activation.

Solution

Designed and built a multi-signal fraud detection engine integrated into the account activation flow. The system evaluates each new activation request in real time, collecting and scoring signals from multiple independent sources, computing a composite risk score, and routing the account to an appropriate action — approve, flag for review, or block.

The system is designed to be invisible to legitimate users: low-risk activations proceed without friction. High-risk activations are held for manual review or automatically blocked before any platform access or funding is granted.

My Role

Architecture

Activation HookDetection runs at the moment a new account submits an activation request. The hook is non-blocking for low-risk accounts and holds high-risk ones for review before any access is granted.
Signal CollectionFour independent signal categories are collected: payment card metadata (BIN analysis, issuer geography), device fingerprint, behavioural patterns (time-on-page, input velocity, interaction model), and cross-account correlation (card reuse, IP clustering).
Scoring EngineEach signal contributes a sub-score. A weighted composite score (0.0–1.0) is computed. Score bands: Low / Medium / High / Block. Weights are configurable without code changes.
Action RoutingScores below threshold: auto-approve. Scores in review band: queue for manual review with full signal audit. Scores above block threshold: immediate rejection with logging.
Background JobsSidekiq handles async signal enrichment (IP intelligence lookups, PSP metadata fetches) without blocking the activation response. Results are appended to the decision record post-hoc for audit trail.
Audit LogEvery scoring decision is persisted: input signals, sub-scores, composite score, threshold applied, action taken, and timestamp. Enables compliance review, model tuning, and retroactive fraud analysis.

Tech Stack

Ruby on RailsPostgreSQLRedis SidekiqPSP REST APIsIP Intelligence APIs Browser FingerprintingBackground JobsAudit Logging

Business Impact

Security & Privacy

No real payment card data, user PII, or PSP credentials are exposed in this case study. Signal descriptions are intentionally generalised. Proprietary scoring weights, threshold values, and fraud rule logic are excluded from public disclosure.

The system was designed with audit-first principles: every decision is logged with its full signal context, enabling compliance review without requiring access to production systems.

Source Code & Constraints

Source code is private due to commercial and security constraints. Exposing the detection logic, signal weights, or threshold configuration would reduce system effectiveness. This case study exposes architecture, technology choices, role scope, and business impact only.

What I Would Improve Next