Alacer: Real-Time Fraud Detection with Explainability

Client: Alacer (Velocity FinCrime Solution Suite)
Period: 2021
Stack: Isolation Forest, SHAP, Redis, Python, Unsupervised Learning

The problem

Alacer was building Velocity, a financial-crime solution suite that needed real-time fraud scoring on every incoming transaction. The constraints made the problem hard.

First, the fraud labels were thin. A supervised classifier needs millions of labeled "is this fraud" examples and Velocity did not have them. Even the labels we did have were biased toward fraud patterns that prior rules-based systems had already caught, which means the model would re-learn what we already knew instead of finding new fraud.

Second, every flagged transaction had to be explainable. A regulator asking "why did your system block this customer's payment" is not satisfied with "the neural network said so". The decision rationale has to be auditable per transaction.

Third, latency. Transaction scoring had to run inside the payment authorization path, sub-second p95, no exceptions. That ruled out batch scoring, slow feature joins, and most cloud inference patterns.

What I built

Isolation Forest as the core detector. Isolation Forest is an unsupervised anomaly detector that learns the shape of "normal" transactions and scores how easily a new transaction can be isolated from the population. Anomalies require fewer splits to isolate, which gives you a numeric anomaly score per record without ever needing fraud labels. This was the right primitive for a thin-label regime: it surfaces patterns the rules-based system had not seen, without overfitting to the labels you do have.

SHAP for per-decision explainability. Every scored transaction got a SHAP attribution map that told the analyst which features pushed the score up and by how much. "This transaction was flagged because the amount is 7x the customer's 90-day median, and the merchant category is unusual for this account." SHAP made the system auditable in a way that pure model output never can be.

Redis as the real-time feature store. Sub-second scoring meant features had to be looked up in microseconds, not seconds. We pre-computed customer-level features (rolling averages, recency, velocity counts) and kept them in Redis with TTL-based expiry. The model service hit Redis with the customer id, got back the feature vector, scored, and returned, all inside the latency budget.

A small, fast model deployment. No GPUs, no inference servers. The Isolation Forest model was small enough to load once into the Python service and serve scoring requests directly from memory. Less moving parts means less to go wrong in production.

The engineering work that made it ship

The boring but important part was feature engineering. Customer velocity counts, merchant category Z-scores against the customer's own history, time-of-day adjusted amounts, and device fingerprint stability. None of this is glamorous. All of it is what made the anomaly score actually correlate with fraud rather than just "weird-but-fine" transactions.

Threshold tuning was another non-trivial step. The anomaly score is a continuous value but the system has to make a binary decision: block or allow. We tuned the threshold against historical data to balance false positives (which annoy real customers) against false negatives (which let fraud through). Different transaction classes got different thresholds.

The outcome

Metric	Result
Inference latency	sub-second p95
Per-decision explainability	SHAP map for every flagged transaction
Feature lookup latency	microseconds (Redis-backed)
Labels required	none (unsupervised)
Deployment footprint	small Python service, no GPU

The system shipped as part of Velocity's FinCrime offering and ran in production scoring real customer transactions.

What this case is proof of

Production AI is not always about LLMs. Sometimes the right move is an unsupervised classical model with strong explainability and a fast feature path. This case shows the same engineering instinct that makes the larger LLM builds work: pick the simplest model that actually solves the problem, invest heavily in the data and features around it, and make sure the system is auditable and operable in production.

If you have a fraud, anomaly, or risk-scoring problem where labels are thin and explainability matters, this pattern is what I would design for you.