Background
A payments company’s existing rules-based fraud system was missing new fraud patterns while generating too many false declines on legitimate transactions. Fraudulent transactions represented less than 0.1% of volume, and patterns shifted every time fraudsters adapted to detection.
The Challenge
The team needed a model that could detect rare, evolving fraud patterns in near real time without materially increasing false declines — a combination existing published fraud-detection approaches did not reliably achieve at this transaction volume and class imbalance.
Technological Uncertainty
It was not known whether any modeling approach could maintain detection accuracy as fraud patterns drifted, without requiring constant manual retraining, or whether the extreme class imbalance would make reliable detection technically infeasible at production latency requirements.
Experimental Development
The team tested multiple resampling strategies, ensemble architectures, and online-learning approaches, systematically measuring detection rate, false-positive rate, and inference latency for each configuration against held-out adversarial test sets.
What Failed?
An initial ensemble approach achieved strong offline accuracy but failed under production latency constraints, and a synthetic oversampling technique improved detection but introduced unacceptable false-positive rates on legitimate high-value transactions.
Technological Advancement
The team developed a hybrid architecture combining a lightweight real-time scoring model with a slower-updating pattern-drift detector, generating new understanding of how to balance detection accuracy, latency, and adaptability at this specific transaction profile.
Potentially Relevant SR&ED Activities
- Systematic testing of resampling and ensemble strategies against imbalanced fraud data
- Architecture experiments to meet real-time latency constraints
- Development of a drift-detection mechanism to identify when retraining was required
What Would Generally Not Qualify
Routine retraining of the finalized model on new transaction data using the established pipeline, once built, would not itself qualify as ongoing eligible work.
Documentation
Experiment logs comparing model configurations, latency benchmarks, false-positive/false-negative tracking across iterations, and technical design discussions of the drift-detection approach would support this claim.




