Real-Time Transaction Fraud Detection

Project overview

We built a real-time fraud detection system for a digital payments company that processes card payments, wallet transfers and merchant settlements. Every transaction is scored while the payment is still in flight, so the platform can approve it, ask the customer for extra verification or hold it for review.

The engagement covered data analysis, feature design, model training, the Kafka streaming pipeline, a rules engine, the analyst case management app and integration with the payment authorisation flow. It is part of our fintech app development work and our broader projects for the fintech industry.

The client and the challenge

The client relied on a set of static rules written over several years, such as velocity limits and country blocks. Fraudsters learned to stay just under the thresholds, while legitimate customers who travelled or made unusual purchases were declined, causing complaints and abandoned payments. Analysts worked from spreadsheets exported the next morning, long after the money had moved.

The client wanted scoring inside the authorisation window, models that adapted to new patterns, explanations analysts and auditors could understand, and a way to keep useful rules alongside the machine learning rather than throwing them away. Customer data had to stay protected throughout, with tokenised card details and audit trails for every decision.

Solution architecture & delivery

Payment events are published to Kafka the moment authorisation starts. A stream processor written in Python maintains rolling behavioural features for each customer, card, device and merchant: spending pattern versus the customer's own history, how many cards a device has used recently, distance from usual locations, time since the account's last credential change, and merchant category risk. Features are held in a fast key-value store so scoring never waits on the main database.

The scoring service combines these features with the transaction itself and runs an XGBoost model trained on labelled historical transactions, where labels come from confirmed chargebacks and analyst decisions. Because fraud is rare, we used class weighting and evaluated on time-based splits so the model was always tested on a period after its training data. Each score is returned with its strongest contributing factors, calculated per transaction, so an analyst sees why a payment was flagged.

A rules layer sits beside the model. Hard rules such as sanctions hits still block outright, while risk bands decide the action: approve, step-up verification through a one-time passcode, or hold. Thresholds are configurable by product and merchant type in a rules console, with every change versioned and requiring a second approver. If the scoring service is ever unavailable, authorisation falls back to the rules alone rather than blocking payments, and the missed events are scored afterwards from the stream.

Held and flagged payments open cases in the analyst app, grouped when they share a device, card or beneficiary so rings are visible. Analyst decisions flow back as labels, and weekly monitoring tracks score distributions for drift before the model is retrained. The event-driven design follows ideas from our AWS architecture for high-traffic platforms.

Key features we built

• In-stream scoring of every payment before authorisation completes
• Rolling behavioural features per customer, card, device and merchant
• Per-transaction explanations of the main risk factors
• Approve, step-up verification or hold actions by risk band
• Versioned rules console with dual approval for changes
• Case management that links transactions sharing devices or beneficiaries
• Analyst decisions fed back as training labels
• Drift monitoring and scheduled model retraining

How we delivered it

1. Discovery. Sessions with the risk, compliance and payments teams to map authorisation flows, existing rules, chargeback data and regulatory reporting needs.
2. Data and modelling. Building a labelled history from chargebacks and past investigations, then iterating on features and models with time-based validation.
3. Build. Two-week sprints for the Kafka pipeline, feature store, scoring service, rules console and case app, with load tests against replayed traffic.
4. Shadow mode. The model scored live traffic without affecting payments, so its alerts could be compared with the legacy rules before any action was enabled.
5. Go-live and support. Gradual enablement of step-up and hold actions by product line, followed by retraining, monitoring and threshold tuning under a support agreement.

Technology choices

• Python — used for feature engineering, model training, the stream processors and the scoring service, keeping training and serving logic in one language.
• Kafka — a durable event stream that decouples payment authorisation from scoring and lets features, case creation and monitoring consume the same events independently.
• XGBoost — fast, accurate on tabular transaction features, quick to score inside the authorisation window and compatible with per-transaction explanation methods.

Outcomes

• Risky payments are challenged or held before funds move rather than investigated the next day
• Legitimate customers with unusual but genuine activity face step-up verification instead of an outright decline
• Analysts review explained, linked cases in place of spreadsheet exports
• Rule changes are versioned, dual-approved and auditable
• The model adapts to new fraud patterns through regular retraining on analyst decisions

FAQ