Fraud teams rarely run short of alerts. They run short of time. The slow, expensive part is turning a raw alert into a decision someone can defend. That’s the problem behind one of the reference builds in our founder’s public portfolio, a fraud-detection pipeline for a fictional bank. It runs fully offline on synthetic data, it isn’t client work, and nothing in it is deployed. Its value is in what it reveals when you measure it honestly.<\/p>\n
The build follows one path from start to finish: a seeded stream of transactions, a risk score for every transaction with plain-language reasons, detectors for known fraud patterns, cases that cite their evidence, and a review queue where a human analyst records the verdict. Every step is written to a tamper-evident log. The demo run covers 1,687 synthetic transactions across 12 accounts, with four fraud patterns injected on purpose: card testing, account takeover, money mule and merchant collusion.<\/p>\n
1. One layer of detection wasn’t enough.<\/strong> Card testing means a fraudster fires lots of tiny charges to check whether a stolen card works. Each of those probes looks harmless by itself. In this build, a single probe scores at most 50.5, just under the flag threshold of 55, so the per-transaction scorer flagged zero of them. The pattern detector, which looks at a window of activity (10 or more sub-$5 online charges in 30 minutes), caught it. If you’d only had the scoring layer, the attack would have slipped straight through.<\/p>\n 2. A perfect score didn’t prove much.<\/strong> On the seeded demo, all 4 injected patterns were detected, with 0 false positives on the 8 clean accounts. That looks great on a slide. The repo’s own evaluation pushes back on it. Four of the patterns have only one positive account each, so a precision of 1.00 still carries a 95% confidence range of roughly 0.21 to 1.00. The mule-ring pattern, with four positive accounts, narrows that to about 0.51 to 1.00. Same perfect score, very different strength of evidence. And because the repo injected these patterns itself, it treats the result as a correctness check, never as a real-world detection rate.<\/p>\n 3. The cheapest case was a warning sign.<\/strong> The analyst worklist ranks cases by severity and exposure. The card-testing case carried just $30.43 of exposure, while the account takeover case carried $7,333.68. Even so, card testing was rated high severity, because those small probes usually come right before bigger losses. Ranking by dollar amount alone would have buried it.<\/p>\n 4. Retuning stayed in human hands.<\/strong> Thresholds go stale as fraud changes. The build lets analyst verdicts propose<\/em> a change only after at least 5 verdicts on a pattern with precision below 0.5. Even then, nothing moves until a named person approves one single change, using a token that can only be used once and expires after an hour. Every change is logged with the old value, the new value and the approver.<\/p>\n Most fraud tools get sold on a detection rate. This build shows why that number needs context: how many positive examples sit behind it, whether those examples were self-made, and which layer actually did the catching. It also shows that automation and accountability can live together. The system opens cases and suggests changes, and people make the calls that change what counts as fraud.<\/p>\n Reference build:<\/strong> AventureCloud fraud-detection agents, built on synthetic, fictional data only.<\/p>\n Want your fraud, risk or operations team to build AI like this, where your domain experts decide how it should behave? Write to trainings@aventurecloud.net<\/strong> about our Agentic AI trainings, or partnerships@aventurecloud.net<\/strong> to bring trained AI engineers into your implementation.<\/p>\n Hashtags:<\/strong> #FraudDetection #AgenticAI #ResponsibleAI<\/p>\n LinkedIn teaser:<\/strong> What a reference fraud-detection build on synthetic bank data shows about layered detection, honest metrics and keeping analysts in charge of thresholds.<\/p>\n","protected":false},"author":19,"featured_media":8130,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[],"class_list":["post-8094","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-research"],"yoast_head":"\nWhy it matters for a business<\/h2>\n
Takeaways<\/h2>\n
\n
\n
\n
\nOur fraud reference build caught 4 of 4 injected patterns with zero false positives, and that’s exactly why we didn’t trust the number yet.
\nHere’s what layered detection, confidence ranges and human-approved thresholds taught us.<\/p>\n","protected":false},"excerpt":{"rendered":"