SR&ED Case Study: AI Fraud Detection

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.

About The Author

Dale Doering

Dale Doering is the owner of SRED Consultants Inc., helping businesses navigate the complexities of Scientific Research and Experimental Development (SR&ED) claims. With a strong understanding of the technical and interpretive requirements of the SR&ED program, Dale works with companies to identify eligible projects, document technological challenges, and clearly demonstrate the systematic experimentation or analysis undertaken to achieve advancement. His approach focuses on translating complex technical work into well-supported SR&ED claims, helping clients maximize eligible opportunities while maintaining a clear understanding of the program’s requirements.

Recent Posts

Frequently Asked Questions

What specific technological uncertainty did this project attempt to resolve?

The core uncertainty was whether a machine learning model could reliably detect rare, rapidly evolving fraud patterns (less than 0.1% of transactions) in near real time without driving up false-decline rates or failing under production latency constraints.

Eligible activities include the systematic testing and evaluation of different resampling strategies, ensemble architectures, online-learning approaches, real-time latency optimization experiments, and the development of the drift-detection mechanism.

An initial ensemble model failed due to high production latency, and synthetic oversampling created unacceptable false-positive rates on high-value legitimate transactions. Demonstrating failures and iterative technical dead-ends provides proof that the work involved systematic experimentation rather than routine engineering.

The team developed a novel hybrid architecture that paired a lightweight real-time scoring model with a slower-updating pattern-drift detector, advancing their technical understanding of how to balance accuracy, low latency, and model adaptability on extreme class-imbalanced transaction data.

Routine, ongoing retraining of the finalized model using the established pipeline does not qualify once the technological uncertainty is resolved. To support the claim for eligible work, the company must retain technical documentation, such as experiment logs, latency benchmarks, iteration tracking, and technical design discussion notes.

Related Post