A referral program paid out on the referral event itself, not on whether the trade behind it was real. The reward economics were already decided. The safeguard against fraud wasn't.
IMPACT
Newton's team can now cap and hold a flagged referrer's payouts for review, without touching the new sign-up on the other end of the link, a flag that used to change nothing.
One account was flagged four separate times over several weeks and, under the old system, kept collecting referral payouts through all four. Under the threshold logic now in place, that same repeated-flag pattern is what triggers the cap. The link stays live and everything already earned stays paid; only what hasn't been paid yet gets held.
THE PROBLEM
A flat $25-for-everyone reward paid referrers whether or not their referee ever traded in good faith, and crediting rates had fallen to an all-time low.
A distinct "withdraw-only" pattern had emerged: sign up on a code, trade the bare minimum, claim the bonus, and withdraw immediately, leaving referrers credited for referees who never became real users. It wasn't always one opportunist working alone, either. Referral chains showed up branching three and four generations deep, referrer to referee to referee to referee, the same fork count repeating at every level. Organic word-of-mouth doesn't branch this evenly; it was the uniformity, not any single account, that gave the pattern away. It wasn't hard to run, either: a brand-new sign-up got their own referral code the moment they joined, before ever placing a trade.
Alongside this, product was already restructuring the reward: lowering the flat baseline from $25 to $20, while introducing payouts up to $100 for referrers with real trading history. That was economics, not fraud prevention, but it set up the question I had to answer, the higher tiers were meant to reward genuine traders, and nothing stopped the same farming behavior from simply moving up to chase them.
Organic word-of-mouth doesn't branch this evenly.
Referrer to referee to referee to referee, the same fork count repeating at every generation. It's the uniformity that stands out, not any single account, every branch forking exactly the same way as the one before it.
INSIGHT
The referrer claiming the reward is the bad actor, not the new sign-up receiving it. So the fix had to restrict the referrer, never the referee.
The incentive to abuse the mechanic sits entirely on one side of it. The referrer gets paid the moment a referral is credited, no further effort required, while the referee's own reward is gated behind actually trading $100 within 90 days. A fabricated referral doesn't get the referee anything extra. They still have to sign up and use the product for real to collect.
Whoever can get paid without doing the work is whoever has a reason to cheat.
The initial instinct was to lock things down wholesale: cap daily payouts, throttle the payout queue, block flagged codes outright. However, all of it restricted the referee for behaviour that was the referrer's misdoing. So once the target was corrected, the design got simpler, not more complex.
HOW IT WORKED
Two decisions, working in tandem: a soft cap with manual review on the referrer's account, and a $100 trade requirement before any new user, flagged or not, to unlock their own referral code.
Once a referrer's payouts cross an internal threshold, rewards are quietly deferred, not denied. The account keeps its link and everything already earned, and a cleared review gets the deferred rewards credited back. The only thing the user sees is a neutral note: "Not eligible for additional rewards at this time." Succeeding completed referrals keep climbing as new sign-ups come in, it's only the reward total that stops moving. Nothing hidden, nothing needs to be.
Every new sign-up with a code already had to trade $100 within 90 days for their own welcome bonus, so I extended that same threshold to sign ups with no code to unlock referral-code access. Nobody can refer anyone until they've actually used the product. It isn't a hurdle aimed at them, it's proof they've formed a real opinion of Newton first.
The same discipline shaped the UI, and fraud and compliance point the same direction here. A progress bar would have framed trading as something done to earn a reward, and shown a bad actor exactly how much volume unlocks the top payout, so I designed it out instead. Tier changes surface passively: a dismissible card states the tier and reward, nothing more, no urgency, no unlock animation, with the bonus reasoning sitting behind a tap rather than broadcast upfront. It reads as acknowledgment, not incentive, which is also what clears compliance, anything that reads as trade more, get rewarded is exactly what's prohibited. Each tier upgrade is stated as fact, never chased as a goal: the card names the new multiplier and offers a dismiss, nothing to fill up, nothing to unlock. The referral page carries that same restraint into the live product: a code, a reward, an activity feed, and nothing urging anyone toward the next tier.
Three tier upgrades, stated as fact, never chased as a goal.
Each card names the new multiplier and offers a dismiss, nothing to fill up, nothing to unlock. The referral page carries the same restraint into the live product: a code, a reward, an activity feed, and nothing urging anyone toward the next tier.
THE OUTCOME
Flagging used to be the end of the story. Now it's the start of one: a flagged account gets its payouts held, investigated, then restored or left capped.
Multiple accounts have already hit the threshold and been automatically capped. Under the old system, a flag changed nothing, payouts kept flowing regardless of how many times an account was flagged. Under the new logic, the same repeated-flag pattern is what triggers the cap, with everything already paid staying paid and only what hadn't been paid yet held. The mechanism is working end to end, on real accounts, exactly as designed.
REFLECTION
Fraud prevention in a regulated product isn't about closing every loophole. It's about precision: hold the party actually responsible, and never let protection look like an accusation.
This looked like a reward-economics problem. It was actually an accountability problem.
Nobody handed me a spec for the safeguard, just an open question: how do you protect against bad actors. Whether the new sign-up on the other end of the link deserved protecting too wasn't even part of that question yet, that was mine to decide. Across my work, that's the pattern that keeps showing up: I go looking for the failure mode nobody's defined yet.