Bonus abuse and multi-accounting

December 3, 2025 · 5 min read

When a product offers something valuable at signup, whether a free trial, a promotional credit, a referral bonus, or a discounted first transaction, a certain percentage of users will try to claim it more than once. Multi-accounting is the mechanism: one person creates multiple accounts, each appearing independent, each collecting the benefit. At low volumes it looks like a cost of doing business. At scale it is a fraud operation that drains promotional budgets, distorts acquisition metrics, and pollutes the user base with accounts that exist solely to extract value.

Account sharing is the adjacent problem. Two or more people use a single account, or one person uses multiple accounts interchangeably, undermining pricing models that assume one account per user. In subscription products, account sharing directly reduces revenue. In platforms with per-user security monitoring, shared accounts create blind spots because the behavioral baseline reflects multiple people, making anomaly detection unreliable.

Both problems are detectable through the same signals: entities that should be unique to one account appearing across several. A device identity on multiple supposedly independent accounts. An IP address shared across registrations in the same window. A phone number tied to more than one user.

How multi-accounting works in practice

The simplest form is a single person registering repeatedly with different email addresses. Each account claims the signup benefit. If the product doesn't check for shared device or IP signals across accounts, this works until someone reviews the data manually, which at scale means it works indefinitely.

More sophisticated operations use automation. Bots create accounts at volume, cycling through disposable email providers, rotating through proxy IP addresses, and varying registration details to avoid simple duplicate detection. Each account claims a promotional offer, a free trial, or a referral bonus. The operation runs until the promotional budget is exhausted or the fraud is discovered.

Referral fraud is a specific variant. A user creates multiple accounts and refers them to each other, collecting referral bonuses on both sides of each connection. The accounts may never be used beyond the referral event. The shared device identities and IP addresses connecting the referrer and the referred accounts are the primary detection signal.

Account sharing in subscription products often involves distributing login credentials across multiple people. The behavioral signals are sessions from geographically inconsistent locations in short timeframes, multiple distinct devices active on the same account simultaneously, and login patterns that reflect more than one person's daily routine.

What connects these problems

Bonus abuse, multi-accounting, and account sharing are different exploitation patterns, but they share the same underlying signals: entities that are supposed to be unique to one account appearing across multiple accounts or sessions.

The shared entities that matter most are device identities, IP addresses, and phone numbers. A device identity that appears across five accounts created in the same week is a multi-accounting signal. An IP address shared across a cluster of new registrations within a short window suggests coordinated creation. A phone number tied to more than one account, in a product where phone numbers should be unique, is a direct indicator.

The behavioral context around those shared entities determines the severity. Shared IPs alone are ambiguous. Corporate networks, university campuses, and household connections legitimately share addresses. Shared IPs combined with shared device identities, registration timestamps within minutes of each other, and disposable email addresses from the same provider are not ambiguous.

Detection with tirreno

tirreno tracks shared entities across accounts as part of its core behavioral model. When the same device identity, IP address, or phone number appears across multiple user accounts, the relevant rules fire and contribute risk weight to all associated accounts.

For account sharing, the session-level rules carry the most weight. Multiple countries within a single 30-minute window, multiple devices within the same short timeframe, and multiple IP addresses within a session are all scored as sharing indicators.

The enrichment API adds context to IP and email signals. Disposable email addresses, recently registered domains, and domains without MX records are common across bulk-created multi-accounts. IP addresses belonging to datacenter ranges or commercial VPN providers are consistent with proxy rotation used to distribute registrations across many apparent locations.

Risk scoring happens asynchronously. The user completes their registration or login while the rules fire and the score accumulates behind the scenes. If the score crosses a threshold, the account is flagged or suspended. If it doesn't, the user proceeds without interruption. The monitoring adds no steps to the user flow and no latency to the experience.

All risk weights are configurable from the rules page. Products differ in how aggressively they want to flag shared entities. A consumer product where household sharing is expected needs different thresholds than an enterprise product where each account should correspond to one person on one device. The manual review threshold surfaces accounts for investigation. The auto-blacklisting threshold triggers automatic suspension for accounts that accumulate unmistakable multi-accounting signals.

A practical integration plan

Multi-accounting detection is most effective when it is in place before a promotional campaign launches, not deployed retroactively after the budget has already been drained.

1. Map your registration incentives. List every signup benefit your product offers: free trials, promotional credits, referral bonuses, discounted first transactions, welcome offers. For each one, identify how it is claimed and what prevents a single person from claiming it multiple times. If the answer is "nothing beyond requiring a unique email address," that benefit is exposed.

2. Identify which shared entities your application can capture. Device identity, IP address, phone number, email domain. The more entity signals your registration flow sends to tirreno, the stronger the cross-account correlation. Determine which of these your application already collects and which require additional instrumentation.

3. Define your sharing tolerance. Not all shared entities indicate abuse. Household members may share an IP. Colleagues may register from the same corporate network. Decide what level of entity overlap is acceptable for your product and what crosses the line. Two accounts on the same device may be fine for a consumer app, but five accounts created from the same device in one week is not.

4. Instrument registration and redemption events first. Start by sending registration events and benefit-claim events to tirreno. These are the two moments where multi-accounting becomes costly. Apply the account_registration and promo_abuse presets to get immediate coverage, then tune thresholds based on what you see in the first review cycle.

5. Expand to session monitoring for account sharing. Once registration-stage detection is running, add session events (logins, page views, key actions) to detect account sharing in subscription products. The multi_accounting preset picks up ongoing shared-entity patterns beyond the registration stage.

Download at tirreno.com/download. The developer guide covers event tracking and custom rule development.