Should You Build Your Own Signup Fraud Detection?
You had a weekend of fake signups.
So somebody on the team wrote a few rules. A disposable email list, a cap on how fast new accounts could appear, a skip for anything that called itself a normal browser. The junk slowed down... for about a week.
The rules did exactly what they were written to do. They caught last week's pattern.
A new disposable domain landed on Monday. A ban evader came back on a fresh address from the same browser. A paying customer got blocked, and nobody could say why, because the person who wrote the check was shipping a feature. The rules had no owner.
Building signup fraud and fake account detection in-house fails there, not at the first commit. The first version is a weekend. The question is who maintains it, and who answers when it misses.
Dregs is one judgment layer you can hand that job to. Whether you use Dregs or keep the rules, someone still has to own the miss.
Who Owns It, Who Maintains It, and Who Answers
Those are three different jobs. If all three sit with one engineer who's already late on a feature, you don't have detection. You have a side project.
Who owns it. An owner is a name that is still there after the author of the first version has moved on. For a vendor, that shows up as a changelog, docs, a security page, and an inbox. Dregs publishes those. Questions go to dregs@dregs.com, and the contact page lists the same address. Dregs doesn't publish a response-time guarantee. An in-house rule set's owner is whoever last touched the file. When that person leaves, the owner leaves too.
Who maintains it. Disposable domains, device signals, identity links, and velocity rules go stale on a schedule set by the people abusing the form. Maintaining them is the actual product. Custom rules and lists still belong to your team either way: what counts as a suspicious account, what to review, what to remove. The difference is whether the signals underneath are someone's leftover weekend or a system with a maintainer.
Who answers when it misses. A miss has two shapes. A fake account gets through and sits in the user table counted as growth. Or a real customer is blocked, which is a false positive, and support has nothing to show except a rule that fired. Answering means the signals, the version of the rules, and a way to undo the block. Each Dregs score opens into its observations, so you can see exactly why that account was flagged. A regex with no history can't do that, and neither can a paragraph of model prose.
What You Are Still Maintaining in Year Three
The weekend version feels finished because it matches the incident you just had. The next three years are the incidents you have not had yet. This is the work, not a salary quote. Every row is hours your engineers aren't spending on the product.
| Job | The first weekend | The first year | The years after |
|---|---|---|---|
| Disposable email list | Copied once | Stale within weeks | A recurring update, or the check quietly stops working |
| Device signals | A library you added | Anti-detect browsers route around the first version | An arms race you didn't sit down to join |
| Identity links | Same email, or same IP | Plus addressing, dot tricks, a shared device, a returning ban | False positives if you link too eagerly, misses if you don't |
| Velocity | One threshold | The next wave arrives just under it | Rules that describe only the last incident |
| Crawler allowlist | Trust the user agent | That string is spoofable | Corroboration takes data from the network owner, not a header |
| Review and audit | A message in Slack | A queue, and a reason stored with the decision | Less manual review only if the evidence is still attached |
| Owner | Whoever had the weekend | Whoever still remembers the code | Often, nobody |
The user agent row is the one that teaches the rest. Skipping a crawler because the header says Googlebot works until someone copies the header. Telling a real crawler from a copy takes something the network owner publishes, not a string the client chose. That edge case is ordinary. It is also the kind of thing that eats a quarter if it lives in your backlog.
By year three the enterprising pest has a fresher disposable list than the one checked in on that first weekend. Your rule is a souvenir. The freeloaders aren't.
Dregs keeps four continuous scores on the account (Humanity, Authenticity, Uniqueness, and Behavior) and updates them moments after new activity. Linked accounts stay linked after the email changes, which is the identity graph, not a check on the same email address. You still set custom rules and lists, then badge rules and escalation rules, for what your product should review, limit, or remove. Escalations are how a person sees the accounts that should not be handled automatically. As of October 2026, Starter is $17 a month for 100 active identities. Current plans are on pricing.
Why an AI Fraud Detection Prompt Is a Poor Signup Scorer
The other shortcut shows up in the same week as the rules. Paste the signup into a model. Ask whether the account is fake. For five suspicious accounts on a Thursday afternoon, that works.
It stops working at the volume where fake account detection matters. A signup needs a decision before the account is useful. One model call per identity adds seconds and a bill, and both spike during a bot wave, which is the moment you can least afford to wait or to spend. Run it again on later events and you pay per event too.
Miguel Ríos Berríos described the same fork on a different job, AML alert review, in AgentRun: a harness for repetitive knowledge work (Grep.ai, September 2026). A script "breaks the first time a source changes its pages," and an agent "is expensive at scale." The team that keeps the script ends up "maintaining and constantly updating code." On a set of 100 alerts, a frontier-model agent cost $2.89 per alert and a structured workflow cost $0.25. Over 100,000 alerts, with fallback included, the workflow was $26K and the frontier model was $290K. Grep.ai builds a harness for repetitive knowledge work, not a fraud product, and those figures are for reading watchlist cards, not for scoring a SaaS signup. The lesson still carries: "The model that can figure anything out is the most expensive thing in the building."
A label is also the wrong shape of answer. Berríos writes that a constrained model call "answers with a label and no calibrated sense of how sure it is." A calibrated confidence means "a 0.7 is right about seven times in ten," so the threshold is "a number in code, not a feeling." A signup gate needs that number. Without it, the same account can draw a different verdict tomorrow or after a model update, and you can't explain the block. Reviewers of an automated decision ask "which model made it, on what inputs, under which version of the policy, and can you show me." A paragraph of generated prose can't.
The model also sees one record. Abuse shows up across accounts and over time: a shared device, a shared IP, plus addressing and dot tricks on the email, a velocity pattern, a ban evader coming back. A prompt that contains this signup can't see the ring it belongs to. World knowledge goes stale on the same schedule as a copied list. Disposable domains, proxy and datacenter ranges, and SMS pumping patterns change every week. A training snapshot doesn't.
And the fields are hostile. The name, the bio, and the email are written by the account under review. The more ambitious of these pests will write them for the grader. A prompt that trusts those fields is taking directions from the signup it is supposed to judge.
There's no loop, either. A one-off prompt doesn't grow an escalation queue, a review that corrects the next verdict, or a history you can hand to support.
Use the model on top of a score, not as the score. Investigation, triage, and rule tuning in Dregs are usable entirely through your AI assistant. The AI agents setup covers Claude, ChatGPT, Codex, Cursor, VS Code, and any other client that speaks MCP. The assistant can open a scored identity, read the observations, follow links to related accounts, and work the escalation queue. It doesn't replace the score, and it doesn't cover billing or account settings.
When You Don't Need Dregs
Several honest cases. Buying a judgment layer for any of them is a worse decision than the weekend of rules.
Tens of signups a day, and no abuse pressure. A disposable email check plus email verification is enough. You will know if that stops being true, because the user table will fill with junk. Until then, don't staff a program you don't need.
A handful of suspicious accounts, once. Asking a model about those few, or reading them yourself, is a reasonable afternoon. If you already have Dregs, the same afternoon can run through the assistant. Neither case is a reason to put a model in the signup path.
The problem isn't an account yet. Volumetric bots at the edge, before anything is registered, belong to your CDN or WAF. Card testing and other payment fraud at the charge belong to Stripe Radar, which is built for that decision. Catching bad signups earlier in the funnel can also reduce the payment fraud and chargebacks that follow. Dregs doesn't replace Stripe Radar, and it doesn't replace an edge bot tool.
You want a written explanation. A model is good at saying, in a sentence, what a deterministic score already concluded. That is a review aid. It isn't fake account detection.
If You Build It Anyway
Some teams should. The list above is the test. If you're on the other side of it, the in-house system still needs an owner, or it repeats the weekend story in year two.
- Name the owner. Not "whoever has time." A person whose job includes the miss.
- Schedule the lists. Disposable domains and the rest go stale whether or not anyone is assigned to notice.
- Write the threshold as a number, and version it. A feeling can't be audited, and it can't be rolled back.
- Store the evidence with the decision. A false positive should be a review, not a puzzle for support.
- Keep a way to undo a block. The paying customer from the lead is the reason.
- Don't trust a user agent alone. Corroborate a crawler with data from the network owner.
- Don't send one signup to a model and call the label a score. Use the model, if you use one, to explain a decision you can already defend.
Fake signups are the mess this is aimed at: junk in the user table, burned trials, accounts that were never a customer. The detection you keep is the detection someone will still answer for next year.
Frequently Asked Questions
Q: Why not just build signup fraud detection ourselves?
A: A rules-based version is a few weeks of work, and sometimes a weekend. Keeping disposable domains, device signals, identity links, velocity rules, and a review trail current is a permanent job. When the author of the rules leaves, the owner leaves too. Dregs maintains that job. As of October 2026, Starter is $17 a month for 100 active identities, so the team can keep shipping the product. You still set custom rules and lists for what to review, limit, or remove.
Q: Can AI fraud detection score each signup?
A: It can score a handful of suspicious accounts. At signup volume, each model call adds cost and seconds, and the bill spikes during a bot wave, which is when you can least afford the wait. The same account can get a different verdict after a model update, the answer is a label with no calibrated confidence, and the model only sees one record, not the device, IP, and email links across accounts over time. Attackers also write the name, bio, and email the prompt reads. Use a model to explain a score you already trust. Don't use the model as the score.
Q: Who is accountable when in-house detection misses?
A: Whoever owns the system. A miss is either a fake account that got through or a false positive on a real customer. Answering means naming the signals, the version of the rules, and a way to undo the block. A changelog, docs, a security page, and a contact address are how a vendor stays answerable. A rule file with no owner can't show why a user was blocked. Dregs publishes a changelog, a manual, and a security policy, and each score opens into its observations so you can see exactly why. Dregs doesn't publish a response-time guarantee.
Q: When should we not use Dregs?
A: Skip it when you have tens of signups a day and no abuse pressure. A disposable email check plus email verification is enough. Skip it for a one-off look at a handful of suspicious accounts, where asking a model, or reading the accounts yourself, is plenty. Use your CDN or WAF for volumetric bots that never become accounts. Use Stripe Radar for card testing and other payment fraud at the charge. Catching bad signups earlier can also reduce payment fraud later. Dregs doesn't replace Stripe Radar or an edge bot tool.
Q: What should we keep if we build detection ourselves?
A: Name an owner who isn't whoever has a free afternoon. Put an update schedule on disposable domains and other lists. Write the block threshold down as a number and version it. Store the evidence with the decision so a false positive is a review, not a mystery. Keep a path to undo a block. Don't trust a user agent on its own, because that string is spoofable. And don't send one signup record to a model and treat the label as a score.
Further Reading
Detect fake signups and fake accounts on your SaaS.
Dregs protects the signup flow with Humanity, Authenticity, Uniqueness, and Behavior scores that open into their observations. You can see exactly why an account was flagged, and your team keeps shipping the product.
Start Free Trial