mbfinotti/partnerships-skillsチェック済み
SKILL DETAIL
referral-abuse-guardrails
mbfinotti/partnerships-skills/referral-abuse-guardrails
Define the operational guardrails that stop end customers from gaming a refer-a-friend program - reward caps, velocity limits and cooldowns, reward-hold windows tied to the refund window, eligibility rules, identity-verification gates, a published enforcement ladder, and abuse-monitoring signals. Produces a guardrail spec for B2C and B2B SaaS referral program managers. Use whenever the user mentions referral abuse, self-referral, fake accounts claiming referral rewards, referral rings, or a referral code leaking to coupon forums, even if they never say abuse. Do NOT use for professional-affiliate traffic fraud - use mbfinotti/partnerships-skills@affiliate-fraud-detection instead.
インストール · 496出典を見る
Installation
npx skills add https://github.com/mbfinotti/partnerships-skills --skill referral-abuse-guardrails
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "referral-abuse-guardrails",
"evals": [
{
"id": 1,
"prompt": "We run Hearthbox, a meal-kit subscription. Our refer-a-friend gives $30 credit to both sides and the referrer's $30 lands the moment the friend creates an account. Lifetime cap is 25 rewards per referrer and that's the only limit we have. Last month one guy made 41 accounts with plus-addressed variants of his own Gmail and pulled $1,230 out of us before anyone noticed. We have a 60-day satisfaction guarantee, so customers can refund any box within 60 days. We're relaunching in November and I need the guardrails written. We collect a card at checkout for the first box.",
"expected_output": "A guardrail spec that sets the hold from the 60-day refund window rather than a round number, moves the qualifying event off bare account creation, pairs the existing lifetime cap with a velocity limit and cooldown, and adds a program budget ceiling - without resizing the $30/$30 reward.",
"files": [],
"expectations": [
"Sets the reward hold to at least 60 days plus processing time, matching the stated refund window.",
"States that hold length is derived from the refund or chargeback window rather than chosen as a round number.",
"Recommends moving the qualifying event off account creation onto a paid, delivered, or usage-verified milestone.",
"States that no control below the qualifying event holds while the event is free to fake.",
"Pairs the 25-reward lifetime cap with a per-window velocity limit.",
"Specifies a cooldown after a flagged burst rather than an immediate ban.",
"Adds a program-level budget ceiling expressed as a monthly reward count or currency value.",
"States that a budget ceiling converts a worst-case incident from unbounded to bounded.",
"Notes that caps are usually an economic decision rather than an anti-fraud control.",
"Flags the US reward-reporting threshold of $600, rising to $2,000 for tax year 2026, against the cap's annual value.",
"Shows the reward in a visible pending state during the hold rather than leaving a silent gap.",
"Tags each numeric threshold with its provenance: published terms, illustrative default, or derived from Hearthbox's own data.",
"Records the $30/$30 reward values as given and does not resize them."
]
},
{
"id": 2,
"prompt": "Quick sanity check on our referral anti-abuse rollout at Tideglass - B2C photo-editing app, $60 annual plan, $20 referral credit each side. Twelve weeks ago we turned on a velocity flag, a 45-day hold, and a tighter new-customer rule. Since then: reward payouts down 38%, referral volume down 46%, and average 90-day revenue per referred signup went from $54 to $71. Our head of growth reads that as proof the rules are working and wants to tighten the velocity flag again next sprint. Sign off or push back?",
"expected_output": "A push-back that rejects the per-signup average as the test, restates the comparison on cohort value per 1,000 exposed referrers, gives the leakage and friction formulas with the asymmetry, and calls for a holdout rather than another tightening pass.",
"files": [],
"expectations": [
"Declines to treat the rise in per-signup 90-day revenue from $54 to $71 as evidence the rules are working.",
"States that per-signup value is non-decreasing in strictness because tightening removes marginal signups.",
"Requires the comparison to be made on 90-day cohort value per 1,000 exposed referrers rather than a per-signup average.",
"Identifies a rising per-signup average alongside falling volume as the signature of over-tightening.",
"Requires a holdout cell run under looser rules to calibrate against.",
"States the leakage formula as invalid rewards paid multiplied by reward cost.",
"States the friction formula as rewards wrongly withheld multiplied by reward cost plus support cost plus probability of churn times LTV.",
"States that friction carries an LTV multiplier that leakage does not, so a one-for-one error-rate trade is not break-even.",
"Recommends loosening rather than tightening where the evidence is ambiguous.",
"Lists all three pass conditions: total cohort value per 1,000 exposed referrers, referred-versus-organic quality, and net of the leakage/friction computation.",
"Does not cite an industry or published false-positive benchmark for referral programs."
]
},
{
"id": 3,
"prompt": "I run growth at Pulsewell, a fitness app. $10 credit each side on refer-a-friend, roughly 4,000 referred signups a month. Our head of risk circulated a deck saying referral fraud is 21% of all ecommerce fraud, and that false declines cost merchants $443B a year against $48B in actual fraud. He has budget approved for full ID document capture plus a liveness selfie on every referred signup, live in Q4. Write up the verification plan.",
"expected_output": "A verification plan that refuses both circulated statistics, rejects document and liveness verification at a $10 reward value, stops the ladder at email opt-in plus disposable-domain blocking, and deletes the KYC rung from the spec with the deletion recorded.",
"files": [],
"expectations": [
"Refuses the 21% figure and identifies it as circular vendor citation.",
"Refuses the $443B versus $48B figures as unverifiable precision.",
"Substitutes the mechanism - a wrongly withheld reward costs the reward plus support cost plus churned LTV - for those figures.",
"Rejects full ID document capture and liveness verification for a $10 reward.",
"Stops the verification ladder at email double opt-in and disposable-domain blocking.",
"Notes the payment instrument collected at subscription is the strongest available gate and arrives at no extra friction.",
"Cites sign-up abandonment evidence against document upload, naming it the single largest drop at roughly 15-30%.",
"States that KYC belongs to regulated programs and is never justified as a fraud control on its own.",
"Deletes the KYC rung from the spec outright rather than listing it as a rejected or lowest-ranked option.",
"Records the deletion as a single clause on the Verification line of the spec.",
"Names what does transfer from regulated programs: eligibility memory, payment-instrument-as-identity, staged payout, and clawback tied to account-open duration."
]
},
{
"id": 4,
"prompt": "Need a decision today. Marguerite V. is our number one referrer at Ferncrest, home fitness equipment, $45 referral credit each side. 61 successful referrals in four months, $2,745 paid out. Our fraud vendor's cluster model scores her network high risk and 19 of her 61 referees signed up from the same IP address. Legal has drafted the ban and the clawback letter. One thing the data team flagged: her referees' 90-day retention is 74% against 51% for organic, and their refund rate is 3.1% against our 5.8% organic baseline. Do we send the letter?",
"expected_output": "A recommendation not to ban or claw back, refusing enforcement on graph shape and IP clustering, naming the enthusiastic-advocate false-positive mode, and using her cohort quality figures as disconfirming evidence.",
"files": [],
"expectations": [
"Recommends against the ban and against the clawback.",
"Refuses to enforce on graph or cluster shape alone.",
"Names the enthusiastic-advocate false-positive mode, in which a high-volume legitimate referrer is structurally identical to a small ring.",
"States that IP or subnet clustering is the weakest classic signal, because offices, venues, households, and carrier-grade NAT share addresses.",
"Notes that referral platform documentation recommends against enabling same-IP checks.",
"Requires corroboration before any enforcement, naming reward-splitting, refund clustering, or cohort collapse.",
"Uses the 74% versus 51% retention and 3.1% versus 5.8% refund figures as evidence against the ring hypothesis.",
"Checks payment-instrument reuse as the deterministic first check.",
"Classifies clawback and account action as top rungs of the enforcement ladder, disproportionate to the evidence here.",
"States that proportionality overrides any efficiency ranking when choosing a rung for an individual case.",
"Names the word-of-mouth cost of banning the program's strongest advocate."
]
},
{
"id": 5,
"prompt": "B2B question. Northgate Analytics, we sell workspace seats, $750 account credit per referred workspace that converts to a paid annual plan. Kestrel Digital, an agency customer of ours, has referred six workspaces in eleven weeks. All six used real work email addresses on six different company domains, no free-mail addresses anywhere. Four of those domains were registered in the last 90 days. Two of the six were already running a trial with us before Kestrel's referral link was clicked. $4,500 is sitting in the payout queue. Set up the guardrails and the review process.",
"expected_output": "A B2B guardrail spec built on domain-overlap checking rather than the work-email requirement, a pipeline check applied to the two pre-trial referees, pre-payout human review, and company-account credit routing.",
"files": [],
"expectations": [
"States that a work-email requirement alone is weak because a shell company has a real domain.",
"Makes domain-overlap comparison between referrer and referee the primary check, covering admin contacts, billing entity, and payment instrument.",
"Adds a pipeline check rejecting referrals of accounts already in the pipeline or in trial before the referral timestamp.",
"Applies that pipeline rule to the two referees already trialing and characterises them as routing rather than referring.",
"Flags the four domains registered within 90 days as an observable tell of shell-entity referral.",
"Makes pre-payout human review of every reward the default in B2B.",
"Justifies that review by per-item review cost sitting below the $750 reward value.",
"Routes the reward to company-account credit by default rather than to an individual employee.",
"Frames individual payment as a procurement or gift-policy exposure before it is a fraud problem.",
"Notes that in regulated sectors referral payments can be unlawful and routes that question to counsel.",
"States that caps, budget ceilings, hold windows, and eligibility memory work identically in B2B and B2C."
]
},
{
"id": 6,
"prompt": "Our refer-a-friend at Lumenreach - SaaS, $240/year plan, $50 referral credit - has never had a cap. Published terms say nothing about limits, eligibility, or denial. Finance has now decided on 10 rewards per referrer per year. They want it effective Monday, applied to everyone including rewards people already earned this quarter, and they want us to deny the 430 rewards currently pending under a new rule about accounts with insufficient usage that also isn't in the terms. Draft the policy.",
"expected_output": "A policy that refuses retroactive application, grandfathers the earned and pending rewards, sequences publication before enforcement, and carries a terms-status mapping marking unpublished rules as unenforceable.",
"files": [],
"expectations": [
"States that a rule not published before a referral was made is not enforceable against that referral.",
"Refuses to apply the new 10-per-year cap to rewards already earned.",
"Recommends grandfathering the 430 pending rewards rather than denying them under the unpublished usage rule.",
"Sequences publication of the rules before any enforcement.",
"Cites the promotional-rules requirement to award advertised rewards as described and to withhold only on criteria set out beforehand.",
"Notes the roughly 30-day expected award timing under those promotional rules.",
"Notes that denying a promised reward on unstated conditions is an ordinary deception case under US doctrine.",
"Notes that a blanket sole-discretion clause is weaker than it is drafted to look.",
"Keeps the legal material as design constraints and routes the actual legal questions to counsel.",
"Routes the terms clause drafting to mbfinotti/partnerships-skills@affiliate-program-terms.",
"Includes a Terms status line mapping each rule to where it is published and marking unpublished rules as not yet enforceable."
]
},
{
"id": 7,
"prompt": "Ashbrook Pet Supply. We built a referral abuse detector in-house six months ago and it auto-denies. The customer just never sees the credit appear - no email, no message, nothing on the account page. 1,100 denials last quarter and support has 340 open tickets about missing referral credit. When a case looks bad we suspend the account indefinitely pending investigation, which in practice means until someone gets to it. Our terms say we may withhold rewards at our sole discretion. Write the enforcement policy.",
"expected_output": "An enforcement policy built around published reason strings, a working appeal path with a stated SLA and human review, time-bounded investigations, and the published ladder rungs in order.",
"files": [],
"expectations": [
"Requires a specific reason string on every reward denial.",
"Requires each reason string to name the published rule violated rather than an internal signal such as a device match.",
"Keeps internal evidence logged separately from the customer-facing reason.",
"Requires a working appeal path published inside the denial message itself.",
"States that the reason string and appeal path are built before the detection rules go live.",
"Sets a stated appeal response SLA and labels it self-set rather than an industry or regulatory standard.",
"Requires a human to review every appeal.",
"Rejects indefinite suspension and bounds every investigation in time.",
"States that the appeals-upheld rate is the program's measured false-positive rate.",
"Feeds the appeals-upheld rate into the friction side of the leakage/friction computation.",
"Instructs upholding generously on ambiguity because the friction term carries the LTV multiplier.",
"Lists the published ladder rungs in order: withhold pre-payout, link pause or cooldown, program removal, clawback, account action."
]
},
{
"id": 8,
"prompt": "Vendor call tomorrow. Riverbend Coffee Club, DTC subscription, card charged at signup, $40 referral credit each side, about 9,000 referrals a month. The vendor wants $4,000 a month for device fingerprinting plus their cookie-based self-referral matcher, and says those two catch most referral fraud. We already have full billing data, signup metadata, and refund records in our warehouse. What do we actually instrument, and do we buy this?",
"expected_output": "A signal plan leading with payment-instrument reuse and cohort quality, declining cookie-based linkage and treating fingerprinting as degrading, with a recommendation against the purchase.",
"files": [],
"expectations": [
"Puts payment-instrument reuse first as the strongest deterministic signal available and already held.",
"Places downstream cohort quality alongside payment-instrument reuse at the top of the efficiency ordering.",
"Explains the tie: both already sit in billing data, neither degrades when a browser or device changes, and each catches what the other cannot.",
"States that cohort quality is the only signal that detects a ring of real people.",
"Declines to build on cookie-based linkage, citing third-party cookie blocking and the retirement of the replacement attribution APIs.",
"Recommends server-side attribution off billing webhooks instead of browser state.",
"Treats device and browser fingerprinting as degrading and overstated in strength.",
"Notes the fingerprinting compliance overlay, including the UK regulator position on fair choices and consent, and routes it to counsel.",
"Orders the remaining signals as velocity, then email similarity, then graph, then fingerprint.",
"Names graph or network signals as what this ordering starves, and states the condition that promotes them.",
"Recommends against the $4,000-a-month purchase, or defers it, in favour of signals the program already holds."
]
},
{
"id": 9,
"prompt": "Straightforward one: what are the industry-standard velocity thresholds for referral abuse? I need a number for referrals per referrer per week that counts as normal, plus the standard flag rate a healthy program should see. We're Candlewick Home, DTC candles, $20 referral credit, and we have three years of referral event history sitting in our warehouse. Board deck is Thursday.",
"expected_output": "A refusal to supply an industry-standard number, replaced by a derivation from Candlewick's own referrer distribution, with the background multi-accounting rate used only as a sanity anchor.",
"files": [],
"expectations": [
"States that no referral-specific public numeric velocity threshold exists.",
"Refuses to supply an industry-standard velocity number presented as sourced fact.",
"Derives the threshold from Candlewick's own legitimate-referrer distribution, naming a p95 to p99 band of weekly referral claims.",
"Notes that three years of history removes any need for an illustrative placeholder threshold.",
"Labels any adjacent-domain convention, such as batch account-registration limits, as adjacent rather than referral-specific.",
"Gives the 1-2.5% multi-accounting background rate only as a sanity anchor and states its scope limitation.",
"States that a 20% flag rate means the rules are wrong rather than the users.",
"Refuses to treat any background or flag rate as a target.",
"Tags each threshold in the deliverable with its provenance.",
"Schedules a review cycle to re-derive thresholds from fresh data.",
"Pairs the velocity limit with a cooldown rather than an immediate ban."
]
},
{
"id": 10,
"prompt": "Mess at Sundial Skincare. Our referral code SAVE20FRIEND is now listed on three coupon aggregator sites. Referral redemptions tripled month over month but share events from actual referrers are flat, and one code converted in 14 countries we don't even ship to profitably. Our analytics lead also says a cashback browser extension is overwriting the referral attribution on a chunk of these. Marketing's proposed fix is adding a prefilled invite that mass-texts a customer's whole contact list from inside the app, so real friends outnumber strangers. Also there's no monthly ceiling on referral spend. Thoughts?",
"expected_output": "A response naming the leakage tells, recommending sharing restrictions plus code rotation and a budget ceiling, rejecting the mass-text invite on share-flow exposure grounds, and separating the extension issue as attribution integrity.",
"files": [],
"expectations": [
"Identifies volume spiking without matching referrer share activity as an observable tell of code leakage.",
"Identifies one code converting across unrelated geographies as a second tell.",
"Identifies the code being indexed on public coupon pages as a third tell.",
"Recommends published sharing restrictions combined with code rotation.",
"Rejects the prefilled mass-texting invite outright.",
"Cites the $9M referral-program settlement as arising from the share mechanism rather than from fraud.",
"Names anti-spam or messaging-consent law as the exposure on the share flow.",
"Requires referee consent to be respected in the share flow.",
"States that the operator's power to cap rewards, revoke credits, and dictate sharing creates responsibility for referrer conduct.",
"Requires actually monitoring the published sharing rules, since retaining the ability to enforce makes non-enforcement the operator's problem.",
"Adds an endorsement-disclosure requirement for referred-and-rewarded customers into the sharing rules.",
"Separates the cashback browser extension as an attribution-integrity problem rather than a customer-enforcement one.",
"Sets a program-level monthly budget ceiling to bound the spend incident."
]
},
{
"id": 11,
"prompt": "We've done everything. Vireo Learning, consumer subscription, $35 referral credit each side. Over two quarters we added a 12-per-year cap, a 45-day hold, phone/SMS verification on every referred signup, and disposable-domain blocking. Abuse flags are down. But referred users still churn at 2.4x organic and refund at 3x organic, and 90-day revenue per referred account is under half of organic. Board wants another tightening pass next sprint - stricter velocity, maybe document verification. What do we tighten?",
"expected_output": "A refusal to tighten further, diagnosing the reward structure rather than the guardrails as the defect, and routing the work to the referral incentive design skill.",
"files": [],
"expectations": [
"Recommends against a further tightening pass.",
"States that a referred cohort losing to organic means the program is buying signups rather than acquiring customers.",
"Identifies the defect as the reward structure, not the guardrails.",
"Routes the work to mbfinotti/partnerships-skills@referral-incentive-design using that reference format.",
"States the scope boundary that this work protects the existing reward structure and never redesigns it.",
"Names a rising refund rate on the qualifying event as the signal that the event is too cheap.",
"Questions whether phone/SMS verification earns its friction and its messaging-consent cost at a $35 reward.",
"Declines to add document verification as the answer.",
"States that the goal is making abuse unprofitable rather than catching everything.",
"Recommends a referred-versus-organic cohort dashboard broken out by referrer decile as the diagnostic.",
"Does not claim that tighter guardrails will improve cohort quality."
]
},
{
"id": 12,
"prompt": "Launching give-15-get-15 on Thorne Budget, a personal finance app, in six weeks - it's tied to a funding announcement so the date won't move. Resourcing: one backend engineer at roughly half time, no trust-and-safety function, no fraud analyst, nobody to sit in a review queue. We want something that keeps holding as we grow, not a patch we redo every quarter. A card is required before the first paid month, so we have a payment instrument on every paying account. Write me the guardrails.",
"expected_output": "A guardrail spec that deletes manual review outright on the stated effort ceiling, promotes payment-instrument verification because the card is already collected, ships caps/hold/eligibility for the fixed date, and schedules event redesign for the next cycle.",
"files": [],
"expectations": [
"Deletes manual review from the spec outright rather than ranking it last.",
"Records which controls were deleted and why, tied to the stated effort ceiling.",
"Moves payment-instrument verification up sharply because a card is collected before the qualifying event.",
"Names caps, hold, and published eligibility as the first-pass default set.",
"Schedules qualifying-event redesign for the next cycle rather than dropping it, because of the fixed six-week date.",
"Promotes eligibility memory and qualifying-event design on the stated compounding mandate.",
"States which stated constraint moved which control in the ordering.",
"States that the control ordering is a default rather than a law.",
"Rejects a detection-tooling-first sequencing.",
"Includes a cross-referrer cooldown making a referee ineligible if referred by anyone within a prior window.",
"Defines new customer beyond an email match, using payment instrument, delivery address, or account cluster.",
"States that email alone is trivially rotated."
]
}
],
"trigger_queries": [
{ "query": "Someone farmed 40 plus-addressed email accounts on our refer-a-friend program - write the guardrails before we relaunch", "should_trigger": true },
{ "query": "How do we stop self-referral in our refer-a-friend program?", "should_trigger": true },
{ "query": "We need caps and a hold window for our customer referral rewards", "should_trigger": true },
{ "query": "Design velocity limits and cooldowns for our referral program", "should_trigger": true },
{ "query": "People are posting our referral code on coupon forums and strangers are redeeming it", "should_trigger": true },
{ "query": "Our referral code leaked to a deal forum, what do we do", "should_trigger": true },
{ "query": "Set up the abuse guardrails and review process for our B2B referral credits", "should_trigger": true },
{ "query": "Finance thinks an agency is referring its own shell accounts for our $500 referral credit", "should_trigger": true },
{ "query": "give-10-get-10 launches next month, make sure it can't be gamed on day one", "should_trigger": true },
{ "query": "What should our reward hold window be before we pay out a referral bonus?", "should_trigger": true },
{ "query": "We pay the referral reward the day the friend signs up and people are abusing it", "should_trigger": true },
{ "query": "Write an enforcement ladder for denied referral rewards", "should_trigger": true },
{ "query": "We silently remove suspicious referral rewards and support is drowning in tickets", "should_trigger": true },
{ "query": "How long should we hold a refer-a-friend credit before releasing it?", "should_trigger": true },
{ "query": "Referral signups tripled this quarter but none of them stick around", "should_trigger": true },
{ "query": "Our top referrer might be running a ring, should we ban her?", "should_trigger": true },
{ "query": "Is it safe to ban a customer whose referrals all come from one IP address?", "should_trigger": true },
{ "query": "What eligibility rules stop the same friend being referred over and over?", "should_trigger": true },
{ "query": "Define what counts as a new customer for our refer-a-friend program", "should_trigger": true },
{ "query": "Do we need ID verification on referred signups?", "should_trigger": true },
{ "query": "Should we require phone verification for people who claim a referral reward?", "should_trigger": true },
{ "query": "Our refer-a-friend program has no cap and spend went wild last month", "should_trigger": true },
{ "query": "We need a monthly budget ceiling on referral rewards", "should_trigger": true },
{ "query": "Customers are ordering, claiming the referral credit, then refunding the order", "should_trigger": true },
{ "query": "Referred first orders refund at four times our normal rate", "should_trigger": true },
{ "query": "How do we detect duplicate accounts claiming referral bonuses?", "should_trigger": true },
{ "query": "Write the monitoring signals for our customer referral program", "should_trigger": true },
{ "query": "Which fraud signals actually work for refer-a-friend?", "should_trigger": true },
{ "query": "A vendor is selling us device fingerprinting for referral fraud - worth it?", "should_trigger": true },
{ "query": "Can we use IP matching to catch referral cheating?", "should_trigger": true },
{ "query": "Our referral program terms have no anti-abuse clauses at all", "should_trigger": true },
{ "query": "Legal wants to apply a new referral cap to rewards people already earned", "should_trigger": true },
{ "query": "Can we deny referral rewards under a rule we never published?", "should_trigger": true },
{ "query": "Build the appeal process for rejected referral rewards", "should_trigger": true },
{ "query": "What reason should we give someone when we refuse their referral bonus?", "should_trigger": true },
{ "query": "How do we tell an enthusiastic advocate apart from a referral ring?", "should_trigger": true },
{ "query": "Draft the guardrail spec for our meal-kit refer-a-friend program", "should_trigger": true },
{ "query": "Our referral program is being farmed and I need it locked down this sprint", "should_trigger": true },
{ "query": "How tight should our refer-a-friend rules be before we start losing real referrals?", "should_trigger": true },
{ "query": "We tightened referral rules and volume fell off a cliff - did we go too far?", "should_trigger": true },
{ "query": "How do I measure whether our anti-abuse rules on referrals cost more than they save?", "should_trigger": true },
{ "query": "Set up a holdout cell to test our referral fraud rules", "should_trigger": true },
{ "query": "Is referred cohort quality a good way to catch fake referrals?", "should_trigger": true },
{ "query": "Our work-email requirement isn't stopping fake company referrals", "should_trigger": true },
{ "query": "Should we pay the referral bonus to the employee or to their company?", "should_trigger": true },
{ "query": "A customer referred a deal that was already in our pipeline - do they get paid?", "should_trigger": true },
{ "query": "Do we need manual review on every referral payout?", "should_trigger": true },
{ "query": "What's the right qualifying event for a referral reward so it's hard to fake?", "should_trigger": true },
{ "query": "Move our referral trigger later so people can't fake it", "should_trigger": true },
{ "query": "Our refer-a-friend rewards fire on signup and bots are eating the budget", "should_trigger": true },
{ "query": "Referral credits are being stacked with our other discount codes", "should_trigger": true },
{ "query": "Can we claw back a referral reward we already paid out?", "should_trigger": true },
{ "query": "Should we revoke the friend's discount too when we catch a self-referral?", "should_trigger": true },
{ "query": "We suspend accounts indefinitely when we suspect referral abuse", "should_trigger": true },
{ "query": "What flag rate should we expect from our referral abuse rules?", "should_trigger": true },
{ "query": "Our referral rules flag 20% of claims - is that normal?", "should_trigger": true },
{ "query": "Someone is cycling accounts to reclaim our welcome referral credit", "should_trigger": true },
{ "query": "A cashback extension is claiming credit for our referrals", "should_trigger": true },
{ "query": "Guardrails for a fitness app refer-a-friend before launch", "should_trigger": true },
{ "query": "The friend-gets-friend promo in our app is getting exploited, help me lock it down", "should_trigger": true },
{ "query": "People are gaming our invite-a-friend credit and I need rules that hold as we scale", "should_trigger": true },
{ "query": "We want to keep our invite rewards generous without getting drained by cheats", "should_trigger": true },
{ "query": "Our customer invite program pays too fast and we can't recover money when orders reverse", "should_trigger": true },
{ "query": "Design the commission rate and payout tiers for our affiliate program", "should_trigger": false },
{ "query": "Should we pay affiliates revenue share or a flat CPA?", "should_trigger": false },
{ "query": "Our affiliates are cookie stuffing - build the detection rules", "should_trigger": false },
{ "query": "Set up traffic-quality baselines to catch fake leads from affiliates", "should_trigger": false },
{ "query": "One of our affiliates is generating fake form fills - what's the investigation path?", "should_trigger": false },
{ "query": "How much should we pay a customer for referring a friend - cash or credit?", "should_trigger": false },
{ "query": "Should our refer-a-friend program be one-sided or double-sided?", "should_trigger": false },
{ "query": "How big should the referral reward be against our LTV and gross margin?", "should_trigger": false },
{ "query": "Design a tiered reward ladder for our refer-a-friend program", "should_trigger": false },
{ "query": "Draft the affiliate program agreement clauses", "should_trigger": false },
{ "query": "Write the prohibited tactics section of our affiliate terms", "should_trigger": false },
{ "query": "Audit this month's affiliate commission payout run before we disburse", "should_trigger": false },
{ "query": "Check whether this creator's caption meets FTC disclosure rules", "should_trigger": false },
{ "query": "Does this TikTok script need an #ad label?", "should_trigger": false },
{ "query": "Design the onboarding sequence for newly approved affiliates", "should_trigger": false },
{ "query": "What metrics belong on our affiliate performance dashboard?", "should_trigger": false },
{ "query": "Write recruitment emails to sign up new affiliates", "should_trigger": false },
{ "query": "Rank these five strategic alliance candidates by expected value", "should_trigger": false },
{ "query": "Write our deal registration policy for channel partners", "should_trigger": false },
{ "query": "How do we split credit between partner-sourced and partner-influenced deals?", "should_trigger": false },
{ "query": "Write the rules of engagement between direct sales and our resellers", "should_trigger": false },
{ "query": "Design the tier structure for our reseller program", "should_trigger": false },
{ "query": "Model the unit economics of this one reseller relationship", "should_trigger": false },
{ "query": "Map our full partner ecosystem across resellers, ISVs and MSPs", "should_trigger": false },
{ "query": "Which partner category should we add next and in what order?", "should_trigger": false },
{ "query": "Sequence the certification tracks for our partner enablement program", "should_trigger": false },
{ "query": "Which cloud marketplaces should we list on?", "should_trigger": false },
{ "query": "Build the per-partner scorecard and QBR structure", "should_trigger": false },
{ "query": "Design our whole B2B channel program from scratch", "should_trigger": false },
{ "query": "Plan the joint go-to-market motion with our new integration partner", "should_trigger": false },
{ "query": "Draft the campaign brief for the influencer we just signed", "should_trigger": false },
{ "query": "Define sourcing criteria to shortlist creators for our campaign", "should_trigger": false },
{ "query": "Set the KPIs and attribution plan for our influencer campaign", "should_trigger": false },
{ "query": "Prepare me to negotiate usage rights and exclusivity with a creator", "should_trigger": false },
{ "query": "Write the first-touch pitch to this YouTuber", "should_trigger": false },
{ "query": "I'm interviewing for a channel manager role - how do I prep?", "should_trigger": false },
{ "query": "Write the job description and interview loop for a partner manager", "should_trigger": false },
{ "query": "I'm starting partnerships work and don't know which playbook applies", "should_trigger": false },
{ "query": "Design our employee referral bonus program for recruiting engineers", "should_trigger": false },
{ "query": "How much should we pay employees for referring candidates we hire?", "should_trigger": false },
{ "query": "Build our loyalty points program tiers", "should_trigger": false },
{ "query": "Stop coupon code abuse at checkout on our ecommerce store", "should_trigger": false },
{ "query": "Generate unique single-use discount codes for our email campaign", "should_trigger": false },
{ "query": "Credit card chargebacks are spiking - build the dispute process", "should_trigger": false },
{ "query": "Detect account takeover attempts on our login endpoint", "should_trigger": false },
{ "query": "Write bot detection rules for our signup form", "should_trigger": false },
{ "query": "Set up rate limiting on our public API", "should_trigger": false },
{ "query": "Build our KYC and AML onboarding flow for a regulated crypto product", "should_trigger": false },
{ "query": "Our returns policy is being abused - tighten the refund rules", "should_trigger": false },
{ "query": "Why did referral traffic drop in Google Analytics last month?", "should_trigger": false },
{ "query": "Build backlinks from more referring domains to improve our rankings", "should_trigger": false },
{ "query": "Set up a patient referral management workflow for our clinic", "should_trigger": false },
{ "query": "Write the content moderation policy for our community forum", "should_trigger": false },
{ "query": "Design the appeals process for banned users on our marketplace", "should_trigger": false },
{ "query": "Draft our anti-money-laundering transaction monitoring thresholds", "should_trigger": false },
{ "query": "Score lead quality coming from our paid search campaigns", "should_trigger": false },
{ "query": "Our SDRs are sandbagging pipeline - fix the forecasting rules", "should_trigger": false },
{ "query": "Build a churn prediction model from our subscription data", "should_trigger": false },
{ "query": "Write the privacy policy section covering device identifiers", "should_trigger": false },
{ "query": "Get cookie consent right under GDPR on our marketing site", "should_trigger": false },
{ "query": "Audit our Google Ads account for click fraud", "should_trigger": false },
{ "query": "Decide whether to run a referral program at all versus more paid acquisition", "should_trigger": false },
{ "query": "Write the FAQ copy explaining how our refer-a-friend program works to customers", "should_trigger": false }
]
}
references/abuse-patterns.md›
# Consumer Referral Abuse Patterns
Defensive taxonomy: each pattern is described only to the depth needed to recognize and block it. The useful split is not by technique but by two axes - is one person or several behind it, and is the referred party real? That distinction determines which controls can possibly work.
Provenance tags:
- `[published terms]` - the program's own published rules.
- `[academic]` - peer-reviewed or peer-reviewed-track work.
- `[vendor claim]` - published by a party selling the remedy.
- `[verified incident]` - regulator/court filing or multiple independent press reports.
- `[unverified]` - widely circulated but unconfirmed; do not cite as fact.
## One person, both sides
**Self-referral.** The referrer controls the referee account: the only category where deterministic linkage checks work well (shared payment instrument, shared device, matching cookie identifier, near-identical email). Major referral platforms ship dedicated self-referral checks (cookie, IP+user-agent, similar-email) as a default product surface [vendor docs, published]. Observable tell: referrer and referee share a scarce identifier.
**Duplicate and synthetic account farming.** One main account plus several fabricated referee accounts, often deleted and recreated with modified credentials to repeat the cycle ("account cycling") [vendor claim]. Observable tells: referred accounts with no digital footprint, claim-then-dormant behavior, deletion/recreation cycles, disposable or sequential email patterns. This is the slice OWASP OAT-019 (Account Creation) actually covers.
## Several real people
**Referral rings and collusion.** The most underrated category, because every account is a real human on a real device - no device, IP, or identity check catches it. Best-documented case: drivers and riders in Uber's China operation matched on public forums, ran fake rides, and split the incentive [verified incident, contemporaneous press and book reporting].
Observable tells are cluster-level only: dense referral graphs among accounts with no organic relationship, synchronized claim timing, and downstream cohort collapse (referred accounts that never retain or transact). Warning: a genuinely enthusiastic advocate looks structurally identical to a small ring in graph data [academic - see detection signals]; require corroboration before enforcement.
**Repeatable incentive farming and return abuse.** Referee purchases to trigger the reward, then refunds; or an uncapped program invites the same pair to repeat [vendor claim]. Observable tell: refund rate on referred first orders far above organic. This pattern is the clearest argument for a hold window tied to the refund window rather than a round number.
## Leakage and stacking
**Code and link leakage.** A referral code escapes its intended audience onto coupon sites, deal forums, and code-swap communities; strangers - not friends - apply it [vendor claim]. Observable tells: referral volume spiking without matching referrer share activity, one code converting across unrelated geographies, the code indexed on public coupon pages. Mitigation is contractual (published sharing restrictions) plus code rotation; some programs ban coupon-site posting explicitly in terms [published terms].
**Cashback and coupon browser extensions.** A distinct problem: the attribution is rewritten by an intermediary, not gamed by your customer. Litigation over extension-based attribution rewriting exists [verified as to the litigation existing; allegations unproven]. Treat as an attribution-integrity issue, not a customer-enforcement issue.
**Reward stacking.** Referral credit combined with other promotions past the intended discount. Standard mitigation is a published exclusivity clause - "may not be used in conjunction with any other promotional offer" [published terms].
## Gaming the qualifying event
The single most important structural insight: promotion abuse at scale is a group activity in which ordinary customers conduct legitimate transactions with fraudulent behavior intertwined [academic, production-deployed system at a major delivery platform]. If the qualifying event is cheap and reversible, everything downstream - caps, detection, review - is a losing game. Fix the event first (see guardrail mechanics).
## B2B-specific patterns
- **Shell-entity self-referral.** A customer refers a "new company" they control. The shell has a real domain and a real work email, which is why a work-email check alone is weak. Observable tells: referrer-referee domain overlap in billing/admin contacts, freshly registered referee domain, shared billing entity or payment instrument.
- **Routing a deal that would have closed anyway.** An employee or agency inserts a referral link into an inbound deal. Observable tell: referee was already in the pipeline or trialing before the referral timestamp.
- **Referrer-buyer collusion.** An individual at the referring or referred company splits the reward with the counterpart [vendor claim as pattern; consistent with the loss shape]. This is a procurement/gift-policy and, in regulated sectors, anti-kickback problem before it is a fraud problem - company-account credit by default is the structural fix.
## Documented incidents (calibration, not fear)
| Incident | Reported figure | Lesson | Status |
| -------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Organized ring vs US delivery/ride platforms | $194,800 in referral payouts across 487 accounts (~$400/account) | The only clean per-account referral-loss figure on record; identity re-verification was the response | [verified incident, DOJ-linked reporting] |
| Uber China incentive collusion | "Millions" lost; a widely repeated 30,000-fake-rides/day figure | Rings of real people defeat device checks; device-persistence countermeasures failed | Losses [verified incident]; the 30,000/day figure [unverified - traced to an investor in a rival] |
| Robinhood refer-a-friend settlement | $9M settlement, ~827,000 consumers | The largest documented referral-program loss came from the sharing mechanism (unsolicited texts), not from fraud - guardrail the share flow too | [verified incident] |
Do not use the "referral fraud = 21% of ecommerce fraud" statistic anywhere: it is circular vendor citation [unverified].
references/detection-signals.md›
# Detection Signals
Honest strength ratings, with direction of travel. Weight durable signals over degrading ones; run the two-tier shape (cheap deterministic checks auto-applied, expensive corroborative review before any enforcement) as a mental model borrowed from ad-measurement standards - never as a compliance claim.
Provenance tags:
- `[academic]` - peer-reviewed work.
- `[vendor claim]` - published by a party selling the remedy.
- `[vendor docs]` - a platform's published product documentation.
- `[regulator]` - a regulator's published position.
- `[verified]` - multiple independent reports.
- `[derive from own data]` - program-specific; compute the baseline from the program's own history rather than copying a number.
## Signal catalogue
Rank the signals before instrumenting any of them:
- efficiency: `payment-reuse == cohort-quality > velocity > email-similarity > graph > fingerprint`
- value: `cohort-quality > graph > payment-reuse > velocity > email-similarity > fingerprint`
- effort: `graph > fingerprint > cohort-quality > payment-reuse == velocity == email-similarity`
- compliance cost: `fingerprint > graph > cohort-quality == email-similarity > payment-reuse == velocity`
- Payment-reuse and cohort-quality tie on efficiency because both already sit in billing data the program keeps anyway, neither degrades when a browser or device changes, and each catches precisely what the other cannot: payment reuse settles the one-person case deterministically, cohort quality is the only thing that sees a ring of real people. Neither substitutes for the other.
- Payment-reuse, velocity and email-similarity tie on effort: each is a single query over data already stored, shipped in an afternoon, reversible by deleting the query.
- Cohort-quality and email-similarity tie on compliance cost: both profile customers across accounts without collecting anything new.
Cookie linkage and IP/subnet clustering are excluded from these lines rather than ranked last. Their value is already at the floor, so ordering them would be false precision - they stay in the table below only because vendors still sell them and a defender needs the reason to refuse.
This order starves graph/network signals: the only thing that sees rings, and last but one on efficiency because a cluster model plus its corroboration workflow is a standing job with real profiling exposure. Promote it when a ring is already confirmed, or when per-referral reward value makes one cluster incident material on its own.
Re-rank on what exists: a program with a trust-and-safety function already running graph analysis pays no marginal effort, which moves it straight to the top. The ordering is a default, not a law - it shifts with context and with who executes it.
| Signal | Strength | Direction | Notes |
| ----------------------------------------------------------------- | ------------------------------------------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Payment-instrument reuse | Strongest deterministic signal available to a non-regulated program | Stable | Scarce, costly to rotate, and already held if the program charges money. Check it first. |
| Downstream cohort quality | Strongest overall; the one signal nobody can game | Stable | See below - it detects rings and farming that every identity check misses. |
| Timing/velocity bursts | Moderate | Stable | Cheap tier-1 flag; thresholds must come from the program's own data, never a copied number [derive from own data]. |
| Email similarity / plus-addressing | Moderate vs low-effort abuse | Stable | Cheap; useless against rings. False-positive class: family members on a shared domain with similar names [vendor docs]. |
| Graph/network signals | High for rings - the only signal that sees them | Improving (academic) | Group-detection systems find fraud clusters that per-account checks miss [academic, production-deployed]. Known false-positive mode: legitimate high-volume actors - the enthusiastic advocate looks structurally identical to a small ring [academic]. Never enforce on graph shape alone; require corroboration (reward-splitting behavior, refund clustering, cohort collapse). |
| Device/browser fingerprint reuse | High but overstated | Degrading | A device-intelligence vendor itself states fingerprinting utility has "significantly degraded" over the last decade [vendor claim]; one browser deliberately reduces entropy; browser tampering measured at 4.4% of desktop identifications and ~1 in 5 events involving a VPN, from a 23.4B-event denominator [vendor claim]. Legal overlay: the UK regulator holds that deploying fingerprinting requires fair choices and possibly consent even outside advertising [regulator] - route to counsel. |
| Cookie-based self-referral linkage _(unranked - do not build on)_ | Low and falling | Degrading | Third-party cookies are blocked by default in two major browsers; the third's deprecation was reversed (2024) but its replacement attribution APIs were retired (2025) [verified]. Durable answer: server-side attribution off billing webhooks, not browser state. |
| IP / subnet clustering _(unranked - do not build on)_ | Weakest classic signal | Degraded | A referral platform explicitly recommends against enabling its own same-IP check (offices and buildings share static IPs) [vendor docs]; carrier-grade NAT pools mobile users; households share an IP by construction - and household referrals are often exactly what the program wants to allow. Use only combined with user-agent or as ring corroboration. |
## Downstream cohort quality - the operational test
Academic baseline: a ~10,000-customer, ~3-year bank study found referred customers retain better and are worth at least 16% more than comparable non-referred customers [academic, peer-reviewed]. A related summary puts the profitability gap at 25% over 33 months - the two figures measure different quantities, so never present them as competing estimates of the same thing. Old and single-industry: treat as directional.
The test to build into every spec: **if the referred cohort does not beat organic on retention, refund rate, and 90-day revenue, the program is buying signups, not acquiring customers.** Volume metrics can make fake referrals look like a working growth loop; cohort quality cannot be gamed, because gaming it requires the referred accounts to become genuinely valuable customers - at which point the program won.
Dashboard: referred vs organic, by referrer decile, on retention / refund rate / 90-day revenue. A single referrer whose cohort collapses is a cheaper ring detector than any graph model.
## Calibration baseline
Expected multi-accounting background rate: 1-2.5% of devices access 3 or more accounts, many over 50 [vendor claim, explicitly scoped to one region's food-delivery market]. Use as an expected-flag-rate anchor to sanity-check rule output - a flag rate of 20% means the rules are wrong, not the users - never as a target.
## What not to rely on
- Any vendor-published detection-accuracy percentage without a stated denominator.
- The "$443B false declines" figure - unverifiable precision; cite the mechanism (a wrongly withheld reward costs reward + support + churned LTV) instead.
- A referral-specific false-positive benchmark: none is published anywhere. Anyone quoting one is extrapolating from payments data. Calibrate with the holdout cell in the Pass Threshold instead.
references/enforcement-and-compliance.md›
# Enforcement Ladder and Compliance Constraints
Enforcement principles borrowed from trust-and-safety practice: proportionality, consistency, transparency [professional-association curriculum, not a ratified standard]. The legal material below is a set of design constraints, not legal advice - route every actual legal question to counsel.
Provenance tags:
- `[published terms]` - a program's own published rules.
- `[regulator]` / `[regulator code]` / `[regulator circular]` / `[regulator rulings]` / `[statute]` - a regulator's or legislature's own text.
- `[verified incident]` - court filing or multiple independent reports.
- `[vendor claim]` - published by a party selling the remedy.
## Build order: appeal path before detector
Every reward denial needs a specific reason string and a working appeal path, built _before_ the detection rules go live. A rejected reward with a stated reason and an appeal is defensible in every regime below; a silently missing reward is not, and it also generates the support tickets and churn that make friction cost exceed leakage.
Reason strings name the published rule violated ("per our terms, referred accounts must be new customers; this account had a prior order"), never internal signals ("device match"). Log the internal evidence separately.
## The published ladder
Each rung must appear in the published terms before it is used. Language observed in published programs [published terms]:
- efficiency: `withhold > link pause > program removal > clawback > account action`
- compliance cost: `account action > clawback > program removal > link pause == withhold`
Effort tracks compliance cost rung for rung here, so it gets no separate line: the rungs that draw a regulator are the same ones that generate disputes, appeals and investigation hours. Link pause and withhold tie on compliance cost because both are reversible, pre-money, and defensible on a published rule alone. Withhold leads on efficiency because it stops leakage before money moves, while clawback tries to recover money already gone and mostly buys support load instead.
Argued opt-out on rung selection: rank the rungs to know which to build first, never to pick one for a live case. Which rung a specific account gets is a proportionality judgment - severity, evidence strength, history - and proportionality overrides efficiency every time the two disagree. An efficiency ranking applied to an individual enforcement decision is false precision, and it is exactly how a boundary-pushing customer ends up banned.
1. **Withhold pre-payout, with reason.** Most common, safest. "Delay, withhold, or deny" language tied to defined abusive behavior.
2. **Pause the referral link / cooldown.** Reversible; fits the aggressive-bargain-hunter case.
3. **Remove from the program.** For repeat confirmed violations; strike-based escalation with documented history.
4. **Claw back paid rewards.** Aggressive. One exchange's terms revoke _all_ rewards including the innocent referee's on discovered self-referral [published terms] - revoking the counterparty's reward is exactly the behavior regulators scrutinize; avoid unless the referee is a proven co-actor.
5. **Account action.** "Suspend indefinitely pending investigation" appears in published terms [published terms] - "indefinitely" is the word that will not survive regulator contact; bound every investigation in time.
Treat the abuser and the aggressive bargain-hunter differently: assess risk before the promotion is delivered and apply friction selectively; a loyal customer pushing boundaries for a better deal may be worth retaining despite low-level abuse [vendor claim, sourced to a named practitioner]. Rungs 1-2 for boundary-pushers; rungs 3-5 for confirmed patterns.
## Legal design constraints
**Publication is a precondition.** UK promotional rules require awarding advertised rewards as described, normally within 30 days, and withholding is justifiable only on criteria clearly set out in the promotional rules beforehand; rules must be amended only exceptionally [regulator code]. Practical consequence: a guardrail not published before the referral was made is not enforceable against that referral, and retroactive tightening is the named failure mode.
US doctrine converges: promising a reward on stated conditions and denying it on unstated ones is an ordinary deception case [regulator settlement]. For credit-adjacent programs, relying on fine print to cancel earned rewards may itself be an unfair or deceptive practice - a blanket "sole discretion" clause is weaker than it is drafted to look [regulator circular].
**Silent denial is a legal risk in some regimes.** EU platform rules require a clear, specific statement of reasons for suspending monetary payments or accounts, plus a free internal complaint system open at least 6 months, not resolvable by fully automated means [statute]. Scoping caveat, stated plainly: this binds "online platforms" (marketplaces, services publicly disseminating user content) - a DTC brand's own store generally is not one. Whether it applies to a specific business is a question for counsel; the design (reason string + human-reviewable appeal) is worth adopting regardless because it is also the cheapest trust protection.
**Guardrail power creates liability for referrer conduct.** UK rulings held that because a program operator could dictate how codes were shared, cap referrals, and revoke credits, it had sufficient control over customers' posts to be _responsible_ for them. Terms merely prohibiting the conduct were insufficient while the operator retained meaningful control [regulator rulings]. Consequence: publish sharing rules (where codes may be posted, required disclosures) and actually monitor them; the ability to enforce makes non-enforcement the operator's problem.
**Enforcement teeth are real.** The UK consumer regulator can now investigate and fine directly, up to 10% of global turnover; first-year totals were material but not existential [regulator]. US referrer-side note: referred-and-rewarded customers are endorsers with a material connection that must be disclosed clearly [regulator guides] - put the disclosure requirement in the sharing rules.
**The sharing mechanism itself is an exposure.** The largest documented single financial hit to a named referral program - a $9M settlement - came from the program's prefilled invite texts violating anti-spam law, not from user fraud [verified incident]. Guardrail the share flow: no prefilled mass-texting, referee consent respected.
## Appeals mechanics
- Publish the appeal channel in the denial message itself; respond within a stated SLA (14 days is a defensible default, self-set rather than standard [derive from own policy]). No referral-program-specific regulator SLA exists to calibrate against; the closest published adjacent anchor is insurance fraud-investigation practice, which tiers by complexity - a few days for triage, roughly 30 days for standard cases, 60-90 days for complex/organized ones. A different regime and a different risk profile, so treat it only as a rough shape (tier by complexity, not one flat number), never as a borrowed standard.
- A human reviews every appeal; log outcomes. Appeals-upheld rate is the program's measured false-positive rate - feed it into the leakage/friction computation.
- Uphold generously on ambiguity: the friction term carries the LTV multiplier.
references/guardrail-mechanics.md›
# Guardrail Mechanics
The control ladder, ordered by leverage per unit of friction. Vendor blogs present this order backwards - detection tooling first, program design last. Work top-down: each rung makes the next one cheaper.
- efficiency: `event > caps == hold > eligibility > verification > review`
- value: `event > eligibility > hold > verification > caps > review`
- effort: `review > event > verification > eligibility > caps == hold`
- compliance cost: `verification > eligibility > event == caps == hold > review`
Caps and hold tie because each is a payout-side number published in terms, shipped in one config change, gating no legitimate user, and each bounds a loss the other cannot - caps bound volume, hold bounds reversal. Event, caps and hold tie on compliance cost because none touches identity data or needs sign-off. Review sits lowest on that axis because a human in the loop reduces exposure rather than adding it.
Effort is composite: friction charged to legitimate users, build time, reversibility. Event design ranks high on it - rewiring the trigger is a quarter of product and billing work - yet still leads on efficiency, because that cost is one-time engineering while verification charges every legitimate signup forever. Caps and hold are near-zero on both build and friction; manual review is a standing job that never ends.
Default: caps, hold, and published eligibility first, always. Climb to event redesign the moment the qualifying event is bare signup or an unpaid action.
The order starves verification and review - high value against automated account farming and B2B shell entities, losing every efficiency round; promote them when per-item review cost sits below the reward value, or when an incident is confirmed automated rather than opportunistic. Treat this as a default, not a law: it shifts with context and with who executes it, so re-rank against the program's own answers before writing the spec.
Provenance tags:
- `[published terms]` - a program's own published rules.
- `[academic]` - peer-reviewed work.
- `[vendor claim]` - published by a party selling the remedy.
- `[verified]` - regulator/court filing or multiple independent reports.
- `[derive from own data]` - program-specific; compute the baseline from the program's own history rather than copying a number.
## Table of Contents
- [1. Qualifying-event design (highest leverage, near-zero friction)](#1-qualifying-event-design-highest-leverage-near-zero-friction)
- [2. Caps, budget ceilings, velocity, cooldowns](#2-caps-budget-ceilings-velocity-cooldowns)
- [3. Hold and validation windows](#3-hold-and-validation-windows)
- [4. Eligibility rules with memory](#4-eligibility-rules-with-memory)
- [5. Verification gates - the friction ladder](#5-verification-gates---the-friction-ladder)
- [6. Manual review (last, and scoped)](#6-manual-review-last-and-scoped)
- [B2B specifics](#b2b-specifics)
## 1. Qualifying-event design (highest leverage, near-zero friction)
Move the reward trigger as late as the business model tolerates, onto an event that is costly to fake and hard to reverse.
Published examples [published terms]:
- Dropbox: referee must accept the invite, install the desktop app, sign in from it, and verify email - four steps, none of them identity checks; the desktop install is expensive to fake at scale.
- Expedia: referee must create an account, book, and _complete the travel_ - close to unfalsifiable.
- Gemini (regulated): sign-up, ID verification, and $100 traded within 30 days; unverified accounts explicitly ineligible.
Design rule: if the current event is bare signup or an unpaid action, recommend moving it to a paid, delivered, or usage-verified milestone before writing any other rule. Requiring a payment instrument by the qualifying event also delivers the strongest detection signal for free.
## 2. Caps, budget ceilings, velocity, cooldowns
Published cap values [published terms]:
| Program | Cap type | Value |
| -------------------- | ----------------------- | ---------------------- |
| Dropbox | Lifetime referral count | 32 |
| Expedia | Annual reward count | 10 per year |
| Robinhood Crypto | Per-promotion count | 5 |
| Crypto.com App | Lifetime value | $10,000 |
| Constellation Energy | Annual value | $575 per calendar year |
| HealthExpress (UK) | Annual value | £3,000 per customer |
Two honest notes on caps:
- The $575 annual value is a tax-operations decision disguised as a fraud control: US referral rewards are generally taxable service income with issuer reporting at $600+, a threshold rising to $2,000 for tax year 2026 [verified from published tax guidance]. US programs anchored just under $600 should revisit.
- The usual real reason for caps is economic (an uncapped program cannibalizes paid upgrades), not anti-fraud. Say so; it changes where the cap sits.
Budget ceiling: a program-level maximum reward count or currency value per month/year across all campaigns [vendor capability, published docs]. Always set one - it converts a worst-case incident from unbounded to bounded.
Velocity and cooldowns: no referral-specific public numeric threshold exists, and this is domain fact rather than a research gap - fraud-tooling vendors publish starting-point conventions for the adjacent problem of batch account-registration fraud instead (SEON: flag over 3 registrations per device ID within 60 minutes; over 5 accounts per IP subnet within 24 hours). Treat these as a labeled adjacent-domain starting point for a program with no history yet, never as a referral-specific sourced fact - derive the real threshold from the legitimate-referrer distribution (e.g. flag beyond p95-p99 of weekly referral claims) [derive from own data] as soon as any history exists.
Pair every cap with a per-window velocity limit: a lifetime cap without one can be exhausted in a weekend. Add a cooldown after a flagged burst rather than a ban - it preserves the false-positive case.
## 3. Hold and validation windows
Set the hold to the actual refund/chargeback window plus processing time, never a round number. A 30-day hold on a product with a 60-day return policy is theatre.
Published anchors: a 30-day post-grant hold [published terms, brokerage], 2-4 weeks processing after enrollment [published terms, energy]. A vendor rule of thumb matches the return-policy window (7-30 days retail) timed to when 70-80% of returns have occurred [vendor claim] - use the full window when margins allow.
Show rewards in a visible pending state during the hold; a silent gap reads as denial.
## 4. Eligibility rules with memory
- New-customer definition beyond email match: no prior order on the payment instrument, delivery address, or account cluster - email alone is trivially rotated.
- Self and household exclusion, stated in terms. One published program excludes the referrer's own household and any referee who received a link from _anyone_ in the prior 12 months [published terms] - that cross-referrer cooldown kills ring re-farming of the same referee without touching genuine one-off referrals; copy it.
- Once-per-lifetime and long-cooldown rules are the discipline transferred from card issuers (once per product lifetime; once per 48 months; application-count windows) [published terms]. These transfer cleanly to any program because they are memory, not friction.
## 5. Verification gates - the friction ladder
Climb only as far as the reward value justifies. Rank the rungs before picking one:
- efficiency: `email opt-in == disposable-domain > payment instrument > phone/SMS > KYC`
- value: `KYC > payment instrument > phone/SMS > email opt-in == disposable-domain`
- effort: `KYC > payment instrument > phone/SMS > email opt-in == disposable-domain`
- compliance cost: `KYC > phone/SMS > payment instrument > email opt-in == disposable-domain`
- Email opt-in and disposable-domain blocking tie on every axis: both are a one-time config on the signup flow, both stop bots and neither touches a motivated abuser, and each blocks the half of automated farming the other misses.
- KYC leads on value and loses on efficiency by the widest margin on this page: severe friction, document retention and liveness data to hold, and a decision you cannot reverse once collected.
- Phone/SMS outranks payment instrument on compliance cost because a number carries messaging-consent rules; the $9M settlement in the abuse-patterns reference came from a share flow, not from fraud.
Re-rank on what the program already has:
- Where payment is collected before the qualifying event, the payment-instrument rung's effort collapses to zero and it takes the top spot outright - the strongest available gate, already paid for.
- Where the program is regulated, identity verification is already law-required, so its rung costs nothing at the margin.
The starved rungs are phone/SMS and KYC. Promote phone/SMS on confirmed automated account creation at a volume the cheap rungs demonstrably fail to stop; promote KYC only under a regulatory requirement, never as a fraud control.
Delete a ruled-out rung from the spec rather than listing it as rejected. A non-regulated program deletes the KYC row outright and records the deletion as one clause on the Verification line ("KYC deleted - non-regulated program"); a rung parked at the bottom of a table reappears as scope the first time an incident makes someone nervous.
| Gate | Abuse resistance | Friction | Use it? |
| ---------------------------- | ------------------------------------- | ------------------------------- | ----------------------------------------------- |
| Email double opt-in | Low vs motivated abuser, high vs bots | Near zero | Always |
| Disposable-domain blocking | Low-moderate | Near zero, rare false positives | Always |
| Payment instrument on file | High - scarce, costly to rotate | Moderate; kills tyre-kickers | Yes when payment is already in the flow |
| Phone/SMS verification | Moderate | Small, plus per-message cost | Usually |
| Full KYC document + liveness | Very high | Severe | Delete the rung unless the program is regulated |
The KYC verdict is evidence-based, not taste: 63% of surveyed European consumers abandoned a financial-services sign-up over cumbersome identity verification [vendor claim citing a named third-party survey]. Abandonment ranges ~25% to 60%+ by brand familiarity, with document upload the single biggest drop at 15-30% [vendor claim].
A regulated firm eats that cost because law requires it; imposing it to protect a $10 credit trades a large certain loss for a small uncertain one. What does transfer from regulated programs: eligibility memory, payment-instrument-as-identity, staged payout, and clawback tied to account-open duration (3-6 month clauses in published card terms) [published terms].
## 6. Manual review (last, and scoped)
A queue whose per-item review cost exceeds the reward value is a net loss no matter how accurate. B2C: exception path only, for flags above a value threshold. B2B: pre-payout human review of every reward is the ROI-positive default [vendor claim, consistent with the loss shape - few, large rewards].
Escalation-style triage (auto-approve / hold-for-review / reject with reason) beats binary blocking.
## B2B specifics
These stay the same across contexts: caps, budget ceilings, hold-equals-refund-window, eligibility memory, published enforcement. B2B diverges on three abuse controls plus one routing default.
- efficiency: `domain overlap > pipeline check > pre-payout review`
- effort: `pre-payout review > domain overlap == pipeline check`
Domain overlap and the pipeline check tie on effort - each is a single join against data the CRM and billing system already hold, built once and run automatically - while review is a standing per-deal human cost. Company-account credit sits off the efficiency axis entirely: it is a compliance control, not an abuse control, and it lowers exposure rather than buying detection, so ship it regardless of rank.
B2B diverges on:
- **Domain overlap is the check that matters.** Compare referrer and referee domains, billing entities, and admin contacts. A work-email requirement alone stops disposable-address farming but not the two highest-value B2B abuses: the shell company with a real domain, and the cross-company employee split.
- **Pipeline check.** Reject referrals of accounts already in the sales pipeline or trial before the referral timestamp - that is routing, not referring.
- **Company-account credit by default.** Paying an individual employee to influence a purchase is a procurement/gift-policy problem before it is a fraud problem, and in regulated sectors (healthcare, real-estate settlement) referral payments can be unlawful [verified as to the statutes existing; application is a question for counsel]. Offer individual rewards only as an opt-in the referrer's employer can veto.
- **Pre-payout review** of every reward, as above.
references/worked-examples.md›
# Worked Examples
Two filled specs (one B2C, one B2B) and one negative example. Thresholds tagged [illustrative] are defaults to replace with baselines derived from the program's own data; they are program-specific, never transferable.
## Example 1 - B2C meal-kit subscription (positive)
Context: $25/$25 double-sided credit, 30-day refund policy, payment instrument collected at first order, ~2,000 referrals/month.
```
REFERRAL GUARDRAIL SPEC - meal-kit refer-a-friend, 2026-08
Qualifying event : referrer credit fires when the referee's SECOND paid box is delivered
(paid + physically delivered = costly to fake; second box survives
one-box-and-refund farming). Referee discount stays on first box.
Caps : 12 rewards/referrer/year, $300 lifetime [economic cap, kept under the
$600 US tax-reporting line - rises to $2,000 for tax year 2026];
program ceiling $60,000/month [budget decision]
Velocity : flag >5 successful referrals/referrer/7 days [illustrative - replace
with p99 of legitimate referrers within 60 days]; cooldown, not ban,
on first breach
Hold policy : 35 days = 30-day refund window + 5 processing; reward shown as
"pending - releases <date>" from day one
Eligibility : referee is new if no prior order matches payment instrument OR
delivery address; referrer's own household excluded; referee ineligible
if referred by anyone in prior 12 months [copied from published
program precedent]; no stacking with other promos [published clause]
Verification : email double opt-in + disposable-domain block for all; payment
instrument arrives with the qualifying event anyway; no phone gate
(friction unjustified at $25), no KYC
Monitoring : payment-instrument reuse (tier 1, deterministic), similar-email check,
referred-vs-organic cohort dashboard (retention, refund rate, 90-day
revenue) by referrer decile; expected flag baseline 1-2.5% of devices
[vendor claim, other-market scope - sanity anchor only]
Enforcement : (1) withhold with reason string, (2) 30-day link pause, (3) program
removal after 2 confirmed violations, (4) clawback only for confirmed
self-referral, never the referee's discount; appeal in every denial
message, human-reviewed, 14-day SLA
Terms status : caps, eligibility, hold, and all 4 rungs added to published terms
BEFORE launch; existing earned rewards grandfathered
Calibration : 5% holdout cell with velocity flag off and 20-reward cap; compare
90-day cohort value per 1,000 exposed referrers at day 90; loosen if the
strict cell trails the holdout on that basis, or if leakage saved is less
than friction cost incurred on the same exposure base
```
## Example 2 - B2B SaaS (positive)
Context: $500 company-account credit per referred workspace converting to a paid annual plan, ~15 referrals/month, sales-assisted.
```
REFERRAL GUARDRAIL SPEC - B2B workspace referrals, 2026-08
Qualifying event : credit fires when the referee's SECOND monthly invoice is paid
(survives the refund window and trial churn)
Caps : 10 rewards/referring company/year; program ceiling $15,000/quarter
Velocity : any referrer >2 conversions/month goes to review [illustrative]
Hold policy : release after second paid invoice; no separate timer needed -
the qualifying event IS the hold
Eligibility : domain-overlap check between referrer and referee (admin contacts,
billing entity, payment instrument) - the check that matters; work-email
requirement kept but treated as weak (a shell has a real domain);
referee rejected if already in pipeline or trial before the referral
timestamp (routing, not referring)
Verification : billing-entity verification via the payment method already collected;
no individual identity checks
Review : pre-payout human review of EVERY reward - ~$30 review cost vs $500
reward is ROI-positive in B2B (and would not be at B2C values)
Reward routing : company-account credit by default; individual gift opt-in requires
named approval from the referrer's company (procurement/gift-policy
exposure precedes fraud exposure); regulated-sector referrals routed
to counsel before payout
Enforcement : withhold-with-reason → program removal → clawback via credit reversal;
every rung in the published program terms; appeals to a named human
Terms status : published on the program page; sales team briefed on the pipeline rule
Calibration : with ~15/month, holdout cells lack power - instead audit 100% of
rewards quarterly against CRM outcomes and track referred-account
12-month retention vs sales-sourced accounts
```
Note what is identical to B2C - caps, budget ceiling, hold-covers-refund-risk, eligibility memory, published rungs - and what diverged: domain overlap, pipeline check, universal pre-payout review, company-credit routing.
## Example 3 - fitness app referral program (negative: what not to do)
Context: $10/$10 credit. Every line below is a real failure mode; do none of this.
- **Full ID-document verification for every referred signup**, justified internally by "referral fraud is 21% of ecommerce fraud". Defects: the statistic is circular vendor citation [unverified - do not use], and document upload alone drops 15-30% of legitimate signups [vendor claim] to protect a $10 credit. Fix: stop the ladder at email + disposable-domain checks; the payment instrument arrives at subscription anyway.
- **Silent removal of "suspicious" rewards.** No reason, no appeal. Defects: support tickets, churn of wrongly flagged users, and a deception/consumer-protection exposure in several regimes. Fix: reason string + appeal path, built first.
- **14-day hold against a 30-day refund window.** Theatre: the farmer refunds on day 20, reward already paid. Fix: hold = 30 + processing.
- **A cap added mid-program and applied to already-earned rewards.** Retroactive tightening - unenforceable against past referrals and the exact behavior regulators name. Fix: publish first, grandfather earned rewards.
- **Top referrer banned as a "ring" on IP clustering alone.** She runs a gym; members share the gym Wi-Fi. IP is the weakest signal and households/venues share IPs by construction; the enthusiastic advocate is the known false-positive mode of cluster detection.
- Fix: corroborate with payment-instrument reuse, refund clustering, and her cohort's quality - which was excellent.
- Result of the ban: the program's best advocate now posts about it.
- **No budget ceiling.** The month the program went viral on a coupon forum, spend was unbounded. Fix: program-level monthly ceiling converts incidents from unbounded to bounded.
SKILL.md›
---
name: referral-abuse-guardrails
description: Define the operational guardrails that stop end customers from gaming a refer-a-friend program - reward caps, velocity limits and cooldowns, reward-hold windows tied to the refund window, eligibility rules, identity-verification gates, a published enforcement ladder, and abuse-monitoring signals. Produces a guardrail spec for B2C and B2B SaaS referral program managers. Use whenever the user mentions referral abuse, self-referral, fake accounts claiming referral rewards, referral rings, or a referral code leaking to coupon forums, even if they never say abuse. Do NOT use for professional-affiliate traffic fraud - use mbfinotti/partnerships-skills@affiliate-fraud-detection instead.
license: MIT
metadata:
author: Maya-Beth Finotti
version: "1.1.9"
---
# Referral Abuse Guardrails
Define the guardrails that stop end customers from gaming a customer refer-a-friend program, and deliver them as a guardrail spec: rules with thresholds, verification gates, a reward-hold policy, an enforcement ladder, and monitoring signals. This skill protects whatever reward structure already exists - it never redesigns it.
No ratified standard covers consumer referral abuse. Borrow exactly four things, nothing more, and only as a mental model, never as a compliance claim:
- GIVT/SIVT shape (ad-measurement standards): a cheap deterministic tier plus an expensive corroborative tier.
- OWASP OAT-019 Account Creation: the automated slice only.
- Trust-and-safety enforcement-ladder principles: proportionality, consistency, transparency, for the enforcement section.
- Sybil-attack result, as the strategic frame: fake identities can never be fully detected without a central identity authority, so every guardrail is really a cost imposed on the abuser.
The goal is making abuse unprofitable, not catching everything.
## Ground Rules
- Strictly defensive. Describe each abuse pattern only to the depth a defender needs to recognize and block it: state the observable tell in program data, never evasion technique, tooling, or step-by-step exploitation.
- Label every numeric threshold with its provenance: published program terms, academic result, vendor rule of thumb, or a baseline the user derives from their own data. Never present a vendor heuristic as an industry constant.
- Warn off two circulating numbers: "referral fraud = 21% of all ecommerce fraud" is circular vendor citation (vendors quoting each other) and the "$443B in false declines vs $48B fraud" figure is unverifiable precision. Cite the mechanism - false positives cost more than fraud because they carry lost LTV - never those numbers.
- Separate the genuine abuser from the aggressive bargain-hunter. The first gets the enforcement ladder; the second gets a rule tweak and is often worth retaining.
- A rule not published in the program terms before a referral was made is not enforceable against that referral. Design every rule together with its publication.
## Interview
Ask before designing anything. One question per message; multiple-choice where possible; skip anything already answered.
- What are the program mechanics and reward structure in force: sidedness, reward type and value per side, payout trigger?
- B2B, B2C, or both?
- What is the user-account and identity model: email-only signup? Phone? Payment instrument on file before the qualifying event?
- Which verification capabilities exist today (email confirmation, SMS, disposable-domain blocking, device signals, billing webhooks)?
- What data can actually be queried: referral events, signup metadata, payment records, refund/chargeback records, retention by cohort?
- What abuse has been seen so far, and how was it noticed?
- What reward value is at risk: per reward, and per month across the program?
- How long is the refund or chargeback window on the underlying purchase?
- What is the tolerance for friction versus leakage - would you rather overpay a few gamers or lose a few real referrals?
- Are program terms published today, and what do they already say about caps, eligibility, and reward denial?
- By what date must the guardrails be live - a relaunch, a board review, or an incident already bleeding?
- Do you want a one-off fix for the abuse already seen, or a compounding control set that keeps holding as the program scales?
- What is the effort ceiling: engineering time this cycle, review headcount, and is the qualifying event changeable at all?
The last three set the control ordering in Workflow step 4, so ask them before designing anything - by step 4 the reader has already committed to a path.
## Workflow
1. Run the Interview; collect every answer the spec depends on.
2. Confirm the scope boundary: the reward structure (sidedness, type, size, trigger) is a given. If it is the problem, say so and route to `mbfinotti/partnerships-skills@referral-incentive-design` (see Reference).
3. Map the program's abuse surface from [references/abuse-patterns.md](references/abuse-patterns.md): which patterns the reward value, identity model, and qualifying event actually expose it to.
4. Work the control ladder, using [references/guardrail-mechanics.md](references/guardrail-mechanics.md). Six controls compete for the same hours:
- **Event**: qualifying-event design.
- **Caps**: budget ceiling, velocity limits, cooldowns.
- **Hold**: reward hold window.
- **Eligibility**: rules with memory.
- **Verification**: gates.
- **Review**: manual review.
Vendor blogs present this order backwards - detection tooling first, program design last. Rank them:
- efficiency: `event > caps == hold > eligibility > verification > review`
- value: `event > eligibility > hold > verification > caps > review`
- effort: `review > event > verification > eligibility > caps == hold`
- compliance cost: `verification > eligibility > event == caps == hold > review`
Caps and hold tie because each is a payout-side number published in terms, shipped in one config change, gating no legitimate user, and each bounds a loss the other cannot - caps bound volume, hold bounds reversal. Event, caps and hold tie on compliance cost because none touches identity data or needs sign-off. Review sits lowest on that axis because a human in the loop _reduces_ exposure: several regimes bar a fully automated denial.
Effort is composite here - friction charged to legitimate users, build time, reversibility. Event design ranks high on it because rewiring the trigger is a quarter of product and billing work, yet still leads on efficiency: that cost is one-time engineering, while verification charges every legitimate signup forever.
Default: caps, hold, and published eligibility in the first pass, always. Climb to event redesign whenever the current qualifying event is bare signup or an unpaid action - nothing below it holds while the event is free to fake.
This order starves verification gates and manual review. Both are high value against the two abuses caps and holds cannot touch - automated account farming, B2B shell entities - and both lose every efficiency round. Promote them when per-item review cost sits below the reward value (the B2B default), or when an incident is confirmed automated rather than opportunistic.
Re-rank on the Interview answers and name in the spec which answer moved which control:
- A hard live-by date promotes caps, hold, and eligibility (config, one sprint) and schedules event redesign for the next cycle - never drops it.
- A compounding mandate promotes event design and eligibility memory, which keep working at no ongoing cost.
- A low effort ceiling deletes manual review and the upper verification rungs from the spec outright rather than parking them at the bottom; record which you deleted and why.
Re-rank again on what you already know about this program:
- A payment instrument collected before the qualifying event moves verification up sharply - the strongest gate is already paid for.
- An existing trust-and-safety function collapses review's effort.
- A regulated program already runs identity checks, so its top rung costs nothing at the margin.
Treat the ordering as a default, not a law: it shifts with context and with who executes it.
5. Handle B2B and B2C explicitly. Caps, holds, and eligibility memory work identically for both - say so. B2B diverges on:
- Domain-overlap checks between referrer and referee: the check that matters, since a work-email check alone is weak because a shell company has a real domain.
- Pre-payout human review: ROI-positive in B2B, not in B2C.
- Company-account credit by default: paying an individual employee is a procurement/gift-policy problem before it is a fraud problem.
6. Choose monitoring signals from [references/detection-signals.md](references/detection-signals.md), which carries the full per-axis ranking.
- efficiency: `payment-reuse == cohort-quality > velocity > email-similarity > graph > fingerprint`
The two leaders tie because both already sit in billing data, neither degrades with a browser or device change, and each catches exactly what the other misses. Cookie and IP linkage are excluded from the ranking, not demoted: their value is already at the floor, so ordering them would be false precision. Graph signals are what this order starves; see the reference for the condition that promotes them.
7. Design the enforcement ladder from [references/enforcement-and-compliance.md](references/enforcement-and-compliance.md): published rungs, a specific reason string for every denial, and a working appeal path - build the reason string and the appeal path before the detector. Keep legal constraints as design constraints and route the actual legal questions to counsel.
8. Verify every rule is publishable: flag any rule missing from current terms as unenforceable until published, and route the clause drafting to `mbfinotti/partnerships-skills@affiliate-program-terms`.
9. If you can query the program's event data, derive velocity and flag thresholds from the user's own legitimate-referrer distribution (e.g. p95-p99 of weekly referrals); otherwise mark them as illustrative defaults to replace with derived baselines within the first review cycle.
10. Emit the guardrail spec (Output Shape below), one section at a time for user validation; ground it in a matching worked example from [references/worked-examples.md](references/worked-examples.md).
11. Attach the calibration plan from the Pass Threshold below and iterate until it holds.
12. If your harness has persistent memory, memorize the decided thresholds, hold window, and enforcement rungs so a later tuning run starts from them instead of re-interviewing.
## Output Shape
Deliver every engagement as this artifact. Every threshold line carries a provenance tag; every rule line names the legitimate behavior that could trip it.
```
REFERRAL GUARDRAIL SPEC - <program>, <date>
Qualifying event : reward trigger + why it is costly to fake + reversibility note
Caps : per-referrer (period + lifetime), per-referee, program budget ceiling.
Take the values from the existing reward design where one exists and
record them as given; this spec enforces caps, it does not size them
Velocity : referrals/claims per referrer per window + cooldown after a burst
Hold policy : hold length = refund/chargeback window (+ processing), pending-state display
Eligibility : new-customer definition, self/household exclusion, cross-referrer cooldown,
B2B domain-overlap rule
Verification : gates by friction rung, escalation condition per rung, what is never gated
Monitoring : signals watched, expected flag baseline, cohort-quality dashboard
Enforcement : published ladder rungs, reason strings, appeal path + response SLA
Terms status : where each rule is published; unpublished rule = not yet enforceable
Calibration : holdout cell design, review cadence, leakage/friction computation
```
## Pass Threshold
Judge the spec on leakage and friction together - never a catch rate or precision target alone. No referral-specific false-positive benchmark is published anywhere; never substitute an industry number for the user's own holdout.
- Compute both on the same unit: Leakage = (invalid rewards paid) x (reward cost); Friction = (rewards wrongly withheld) x (reward cost + support cost + P(churn) x LTV). The friction term carries an LTV multiplier the leakage term does not, so a 1:1 error-rate trade is almost never break-even - when in doubt, loosen.
- Calibrate with a holdout: run a small cell under looser rules and compare it to the strict rules on all three conditions below. The spec passes only when all three hold:
1. **Total value, not per-signup**: the strict cell's 90-day cohort value **per 1,000 exposed referrers** is at least the holdout's. This condition is load-bearing and must never be replaced by a per-signup average.
- Tightening removes marginal signups, so per-signup value is non-decreasing in strictness.
- A per-signup gate is satisfied most easily by the most over-tight configuration and can never fail for over-tightening, which is the failure this whole section exists to catch.
2. **Quality**: the referred cohort beats organic on retention, refund rate, and 90-day revenue.
3. **Net of the formula above**: leakage saved by the strict rules exceeds the friction cost they incur, both computed on the same exposure base.
- If the referred cohort loses to organic even with sane guardrails, the program is buying signups, not acquiring customers - the defect is the reward structure, so route to `mbfinotti/partnerships-skills@referral-incentive-design` rather than tightening further.
- Iterate thresholds until all three conditions hold; if data to calibrate does not exist yet, say so in the deliverable and schedule the holdout as the first post-launch review gate.
## Common Failure Modes
| Defect | Consequence | Fix |
| -------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Guardrails so tight they kill legitimate referrals | Program starves; friction cost exceeds leakage saved | Apply the leakage/friction formula; loosen until cohort value per 1,000 exposed referrers recovers. A rising per-signup average alongside falling volume is the signature of this defect, never evidence against it |
| Caps without velocity checks | Abuser hits the lifetime cap in a weekend, undetected | Pair every cap with a per-window velocity limit and burst cooldown |
| Ignoring device and payment-instrument reuse | Cheap deterministic self-referral catches missed | Check payment-instrument reuse first; it is the strongest signal already held |
| Silent reward denial | Trust damage, support load, legal exposure in several regimes | Specific reason string + published appeal path, built before the detector |
| Retroactive rule tightening | Unenforceable against past referrals; regulator attention | Publish first, enforce after; grandfather already-earned rewards |
| Hold window shorter than the refund window | Referee refunds after payout; reward unrecoverable | Set hold = refund/chargeback window + processing time, per product line |
| Treating an enthusiastic advocate as a ring | Top referrer banned; worst possible word of mouth | Require corroboration beyond graph shape: reward-splitting, refunds, cohort collapse |
| Manual review cost exceeds reward value | Every review is a net loss regardless of accuracy | Reserve review for rewards above the review cost; B2B default, B2C exception |
| Full KYC on a low-value consumer reward | Sign-up abandonment dwarfs fraud prevented | Stop at payment-instrument verification; KYC is for regulated programs |
## KPIs
- Track:
- invalid-reward rate (leakage)
- wrongly-withheld rate from appeals upheld (friction)
- referred-vs-organic cohort deltas on retention, refund rate and 90-day revenue
- flag rate against the expected multi-accounting baseline
- hold-to-release time
- budget ceiling burn
- support tickets on denied rewards
- Report leakage and friction in currency on the same unit, side by side - one number alone always misleads.
- Escalate the spec itself when:
- appeals-upheld rate climbs (rules too tight)
- cohort quality decays while flag rate stays flat (rings under the radar)
- the qualifying event's refund rate rises (event too cheap)
## Invocation Examples
- "Our meal-kit box gives $25 to both sides and someone just farmed it with 40 plus-addressed email accounts. Write the guardrails before we relaunch."
- "We're launching give-10-get-10 in our fitness app next month - design the caps, hold policy, and verification gates so it doesn't get gamed on day one."
- "Our B2B SaaS pays $500 in account credit per referred workspace that converts to paid; finance suspects an agency is referring its own shell accounts. Set up the abuse guardrails and review process."
## Reference
- Read [references/abuse-patterns.md](references/abuse-patterns.md) when mapping the abuse surface - the consumer-gaming taxonomy with each pattern's observable tell, plus documented incidents.
- Read [references/guardrail-mechanics.md](references/guardrail-mechanics.md) when setting caps, holds, eligibility rules and verification gates - published values with provenance, the friction ladder, B2B specifics.
- Read [references/detection-signals.md](references/detection-signals.md) when choosing monitoring signals - strength ratings, which signals are degrading, calibration baselines.
- Read [references/enforcement-and-compliance.md](references/enforcement-and-compliance.md) when writing the enforcement ladder, reason strings, appeals, and the legal design constraints.
- Read [references/worked-examples.md](references/worked-examples.md) when shaping the deliverable - one B2C and one B2B filled spec, plus one negative example.
- See `mbfinotti/partnerships-skills@referral-incentive-design` for reward structure (sidedness, type, size, payout trigger, tiers) - this skill protects that structure, never redesigns it.
- See `mbfinotti/partnerships-skills@affiliate-fraud-detection` for professional-affiliate traffic and commission fraud.
- See `mbfinotti/partnerships-skills@affiliate-program-terms` for the consumer refer-a-friend terms wording only when the program also has a professional-affiliate tier.