Catching fake registrations at the door

October 24, 2025 · 4 min read

Registration fraud is an arms race, and the patterns change constantly.

You block disposable email providers. The fraudsters switch to free email accounts. You score free email addresses without reputation. They start aging accounts and building a minimal footprint before registering on your platform. You add device fingerprinting. They rotate devices or use antidetect browsers that generate unique fingerprints per session. You add behavioral signals, scoring session timing and form completion speed. They slow their automation to mimic human cadence.

Every countermeasure gets tested, studied, and eventually circumvented. Each round of escalation requires a specific response from your side. The response needs to be fast, because the window between a new tactic appearing and the damage accumulating is short. And it needs to be specific to your product, because attackers target the particular combination of checks your registration flow uses.

This is why registration fraud prevention cannot be outsourced. A vendor's model is trained on aggregate patterns across their customer base, not on the tactics targeting your product. Their update cycle is months, not hours. Their rule logic is proprietary, so when a new pattern appears in your data, you cannot write a rule to address it. You file a ticket and wait. By the time the vendor's global model catches a pattern your product has been experiencing for months, the attackers have already moved on.

Starting with a vendor and switching later is harder than it sounds. Your detection history, your rule tuning, your understanding of which signals matter for your user population, all of it lives on the vendor's systems. Migration means rebuilding from scratch with no behavioral baseline carried over. The longer you run on a vendor, the more expensive the switch becomes.

The goal is not to stop all fraud

Trying to eliminate fake registrations entirely is a losing strategy. Every additional verification step increases friction for legitimate users. Push far enough and you lose more revenue from abandoned signups than you save from prevented fraud.

The realistic goal is to make fraud financially unattractive. If the cost of creating and maintaining a fake account on your platform exceeds what the fraudster can extract from it, the operation becomes unprofitable and moves elsewhere. You do not need perfect detection. You need detection that raises the cost of fraud faster than attackers can lower it, and that means adjusting weights and rules as attack patterns shift, on your schedule, under your control.

What fake registrations look like

The specific forms vary, but the categories are consistent.

Stolen identity registrations use real identity details acquired from data breaches or dark web markets. Because the data is genuine, standard verification checks pass. The person whose identity was used may not discover the fraud for months.

Synthetic identities combine fragments of real data with fabricated elements: a valid identification number paired with a name and address that don't belong to the real holder. There is no real victim to file a report, which means detection has to come from signal analysis rather than complaints. Genuine digital identities have continuity: an email address with usage history, a device used across many sessions, connection patterns reflecting where the person lives and works. Synthetic identities tend to lack this continuity, and that gap is detectable when you control the rules that look for it.

Automated bulk registration creates large numbers of accounts simultaneously, cycling through identity variations to bypass duplicate detection. The behavioral signals during the session (form completion timing, input regularity, session depth) are the primary detection mechanism, and they require rules you can tune as the automation gets more sophisticated.

Bust-out patterns involve patience. The account behaves normally for a period, building history that earns higher limits or reduced verification. Once the threshold is reached, the account is exploited rapidly and abandoned. Detecting this requires monitoring that extends beyond registration into the full account lifecycle.

Detection with tirreno

tirreno is an open-source security framework that runs entirely on your infrastructure. Your backend sends registration events to tirreno with data it already has: user identifier, IP address, email, user agent. There is no client-side script and nothing visible to the user.

Every rule weight is adjustable and every rule is readable. When fraudsters shift from disposable emails to aged free email accounts, you lower the disposable email weight and raise the weight on addresses without breach history. When they move from datacenter IPs to residential proxies, you shift weight from IP-category rules to device and behavioral rules. When a new pattern appears that no existing rule covers, you write one. You are responding in hours, not waiting months.

Getting started

Install. Deploy a tirreno instance on any server or container you control. The administration guide covers setup and configuration.

Amend your registration flow. Send an event to tirreno from your backend at the point of registration. Include user identifier, email, IP, user agent, and event type. tirreno expects a username with each event, so send whatever identifier your application assigns at signup. The developer guide has the API schema.

Apply the account_registration preset. Open the rules page, activate the preset, and browse the activity page. Look for clusters of registrations sharing email addresses on recently registered domains, and sessions completing faster than human input allows.

Start tuning. Adjust rule weights based on what you see in your data. The current attack pattern against your product is in the activity page right now. The rules that catch it are yours to configure.

Download at tirreno.com/download. A live demo is at play.tirreno.com.