When R&D and I set out to build an in-house fraud analytics platform, we had something most fraud teams would envy: a rich, proprietary dataset to train on. The platform sits in a niche corner of fintech, corporate social responsibility (CSR), where every transaction involves three parties, not two: a corporate client, an employee donor, and a nonprofit. We figured that uniqueness would be our advantage — it also turned out to be our first blind spot.
In early testing, the model returned a flood of false positives, almost all tied to transaction volume. At first glance, the pattern looked like exactly what a fraud model should catch: sudden spikes in giving. But when I manually reviewed the flagged cases, a clearer picture emerged: the model was applying the same volume-based criteria to every donor, regardless of who that donor actually was.
The problem was the ecosystem itself. A corporate client funding an annual giving campaign, and an individual employee donating to a local food bank, are not the same kind of "donor," but the model didn't know that yet. Corporate clients move significantly more capital than individual donors, often in large, infrequent batches tied to grant cycles or company-wide campaigns. Measured against the same threshold as an employee's personal giving, that completely normal corporate activity looked like a red flag.
It was a useful reminder that a model is only as good as its understanding of context, and that "transaction volume" means something different depending on who's transacting.
Once the pattern was clear, I worked through the flagged cases, manually validating and labeling the false positives. That labeled data became the foundation for a feedback loop back into the model, retraining it to distinguish between corporate-scale and individual-scale giving rather than applying one standard across both. It was a fairly simple fix in hindsight, but it only became obvious after sitting with the data and asking why the model was wrong, not just that it was wrong.
Once the core volume issue was resolved, we layered in detectors built specifically for risks that exist almost nowhere outside the CSR space:
The biggest takeaway from this project wasn't technical. It was about whose perspective gets built into a model in the first place. A fraud model trained on transaction data alone will find patterns, but it won't know which patterns matter without someone who understands the ecosystem translating that nuance into the model's logic. The false-positive spike wasn't a data problem; it was a missing-context problem, and closing that gap meant treating the model as a partner that needed ongoing investigator insight, not a system to be plugged in and left alone.
That's also why the human-in-the-loop feedback process became as important as the model itself, not a stopgap until the model got "good enough," but a permanent part of how we kept the model accurate as the platform's three-sided ecosystem kept evolving.