Referral Abuse Guardrails

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: which patterns the reward value, identity model, and qualifying event actually expose it to.
4. Work the control ladder, using 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.

1. 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.