How would you detect and mitigate free trial abuse?

WHAT THIS TESTS: The interviewer wants to see if you can design a production-grade fraud prevention system rather than a single blunt fix. They care about layered defense, staged rollout, and balancing business metrics like conversion against abuse losses. Senior candidates should show they understand signal diversity, progressive friction, and the operational cost of false positives. They also want to hear how you prioritize engineering investment across detection, mitigation, and monitoring.

A GOOD ANSWER COVERS: First, device intelligence and fingerprinting to recognize returning hardware and browsers even when cookies are cleared. Second, rate limiting and velocity checks on signups from the same IP, ASN, or device fingerprint to stop bulk account creation. Third, progressive friction such as email verification, phone OTP, or low-value payment authorization only when risk scores cross thresholds, keeping low-risk user journeys smooth. Fourth, behavioral monitoring during the trial like feature usage patterns, time-to-value anomalies, or repeated identical workflows that suggest scripted abuse. Fifth, a discussion of explicit trade-offs for each layer: device fingerprinting is medium complexity and low friction but can be evaded by sophisticated actors; rate limiting is cheap to build but catches shared networks and VPNs; progressive verification improves accuracy but adds measurable drop-off at the top of the funnel; behavioral monitoring is high accuracy and low friction but requires ML infrastructure and delayed detection that misses the very first signup.

COMMON WRONG ANSWERS: A red flag is jumping straight to requiring government ID or credit cards for all users, which destroys conversion and ignores legitimate privacy concerns. Another mistake is relying solely on IP blocking, which generates massive false positives in corporate offices and mobile networks. Proposing a single silver bullet without discussing staged rollout, shadow mode, or A/B testing impact on funnel metrics also signals inexperience with product delivery.

LIKELY FOLLOW-UPS: How would you handle attackers using residential proxies or anti-detect browsers? What metrics would you use to tune the risk score threshold? How do you prevent collusion rings where each account looks unique? What is the cost-benefit of building in-house versus using a vendor like Stripe Radar?

ONE CONCRETE EXAMPLE: Suppose you see fifty signups in ten minutes from five IP addresses but all share the same canvas fingerprint and use disposable emails. A strong response is to rate-limit that fingerprint, require a phone verification OTP before trial activation, and flag the accounts for behavior review rather than immediately banning them. This preserves conversion for the rare false positive while raising the cost and latency for abusers.

Source: stripe.com