Stop fraud by attack type: seven playbooks

Seven fraud attacks at a glance

Read across a row: where the attack lands, what gives it away, which reasons the evaluation returns and what the default policy does before you change anything on the console's Rules tab.

A VPN on its own is flagged for review, never blocked, because plenty of real customers use one. Proxy, Tor, automation, emulator and fake-browser signals block by default.

The Rules tab sets an action per signal for every check on your account, logins and checkouts included. A rule changes the decision only for the signal it names: set multi-account to Review and a second account opened from a fake browser still blocks, because the fake browser keeps its default. To lower a block, set a rule on each signal that caused it; emulators have no rule, so an emulator block stays. When a rule changes the answer, decision carries the rule's answer, engine_decision the engine's, and rule_matched names the rule that fired. How rules combine.

Worked attack models follow five incidents end to end (models, not customer results): serial SaaS trials, fintech signup-bonus farms, stolen cards behind residential proxies on a store checkout, a sportsbook bonus ring and a multi-account ring on a creator platform.

The fraud toolkit behind all seven attacks

The person farming your free trials and the crew stuffing your login rent from the same shelf. Each tool beats one familiar defence, and each leaves its own trace in the response:

One check cannot see the history you hold about an account. That is why several playbooks ask you to send your own accountId, and to compare device.visitor_id with the devices an account has used before. The evaluation reads the visit; your app knows the customer. Missing evidence is not a clean result either: when the browser check did not complete, the device block is absent, and your code should treat that as unknown.

What the API returns for two of the attacks

Trial number five from one laptop, over a VPN

The signup sends the new account's ID. Example response, selected fields:

{
  "decision": "review",
  "risk_score": 65,
  "reasons": ["vpn_detected", "datacenter_asn", "multi_account_device"],
  "network": { "vpn": true, "proxy": false, "datacenter": true,
               "tor": false, "service": "<VPN service, when known>" },
  "device": { "automation": false, "antidetect": false, "returning": true,
              "linked_accounts": 5, "multi_account": true }
}

The decision is review because of the VPN, not because of the five accounts. multi_account_device is reported and left to your policy, so the simplest move is to refuse the trial in your own handler once device.linked_accounts passes your limit. Set multi-account to Block on the Rules tab instead (it then acts on every check that sends an accountId, logins from a shared family laptop included) and decision becomes block, with engine_decision: "review" keeping the engine's answer and rule_matched naming multi_account. A review rule changes nothing in this example, because the engine already said review.

A card-testing script behind a residential proxy

Same endpoint, called from the checkout route. Example response, selected fields:

{
  "decision": "block",
  "risk_score": 90,
  "reasons": ["proxy_detected", "automation_detected"],
  "network": { "vpn": false, "proxy": true, "datacenter": false,
               "tor": false, "service": "<proxy network, when known>" },
  "device": { "automation": true, "antidetect": false, "emulator": false,
              "tampering_score": 0 }
}

A proxy and automation are both hard signals, so the default is block and the payment intent is never created. Route on decision rather than on a score threshold of your own; risk score thresholds explains why. Every response also reports its own processing time in evaluated_in_ms, and /status publishes measured figures.

Where to put fraud checks: four moments

Seven attacks, but only four places in a typical app where a check changes the outcome:

Signup and the OAuth callback. Fake signups, trial resets, throwaway emails and the first account of every multi-accounting ring. Send the email and the new account's accountId with the evaluation.

Login and password reset. Account takeover. Evaluate after the account lookup and before the password compare and the session, and answer a block exactly like a wrong password. Which endpoints need the check.

Checkout. Card testing. Before the payment intent, so a blocked attempt never costs an authorization fee.

The moment value moves. Bonus claims, referral payouts, promo codes, payout and email changes. This is where bonus abuse gets paid and where a takeover does its damage, so it deserves a second check even when signup and login already have one.

Start in watch mode: log each decision and its reasons, let every visitor through, and read a few days of Events in the console before you enforce anything. Then switch to enforce, which stops a block and holds a review. Decide separately what a check that never answered means for each action: a login may continue, a payout or email change should wait. Log that as your fallback, never as an allow. The quickstart, the SDKs and Workers example and the staged rollout guide cover each step, and fraud API timeouts covers the fallback per action.

What these playbooks do not cover

Every playbook here is about the visit: the network it came through and the browser it ran in. A stolen identity typed in by a real person on an ordinary home connection looks like a customer at that layer. Keep the tools that work on other layers.

Identity and payments. Maskbreak runs no KYC or document checks, scores no orders or transactions and offers no chargeback guarantee. Keep your identity provider, 3-D Secure and your processor's fraud tools; put this check in front of them so fewer bad attempts reach them.

Authentication. It does not replace passwords, passkeys, MFA or session handling. It flags a sign-in that arrives through infrastructure the account's owner is unlikely to use, whether or not the password turns out to be right.

Other companies' data. There is no shared consortium network. Account links stay inside your own account, and email checks stop at the disposable-domain signal.

Lists of IP addresses. A bare IP lookup covers Tor exits and published cloud ranges only. VPN and proxy verdicts, the service name when known, and every device signal need a live visit through POST /v1/evaluate. Why an IP lookup misses proxies.

Looking at it by industry instead? Fraud detection by industry maps the same attacks to SaaS, fintech, e-commerce, gaming, healthcare and government. Terms you meet in the playbooks are defined in the glossary.

Questions about fraud attack types

What are the most common types of fraud attacks on websites and apps?

These playbooks cover the seven that land on account and payment flows: account takeover at login, fake signups, card testing at checkout, bonus and promo abuse, free-trial abuse, multi-accounting and throwaway email addresses. SMS pumping, scraping and friendly fraud are real too, but they hit other endpoints or play out after the order, and sit outside these playbooks.

What is the difference between multi-accounting, bonus abuse and trial abuse?

Multi-accounting is the method: one person running several accounts. Bonus abuse and trial abuse are what the accounts are for, claiming the same welcome offer or referral reward again and again, or restarting a free trial. Detection is the same in all three: send your accountId and read multi_account_device and device.linked_accounts. The check point differs: the claim or payout for bonus abuse, the trial signup for trial abuse, signup and login for ban evasion.

Does a login from a VPN mean an account has been taken over?

No. A VPN on its own returns review under the default policy, because many real customers use one. The takeover pattern is a combination on an established account: a device the account has never used, arriving through a proxy or driven by automation. Proxy and automation block by default; a lone VPN is better answered with a one-time code than a refusal.

Can blocking IP addresses stop these attacks?

Rarely. Residential proxies give every attempt a clean home address, so per-IP limits and blocklists miss them. A bare IP lookup with Maskbreak covers only Tor exits and published cloud ranges; VPN and proxy verdicts, with the service name when known, and every device signal need a live visit evaluated through POST /v1/evaluate.

Do these playbooks replace KYC, MFA or my payment processor's fraud tools?

No. They add a check on the visit in front of those tools. Maskbreak does no identity-document checks, no order or transaction scoring, gives no chargeback guarantee and has no manual review team. Keep MFA, KYC and your processor's checks, and use the decision to choose who reaches them.

How much does it cost to run these checks?

The Free plan includes 10,000 visitor checks a month, every signal included, no card. Paid plans raise the allowance, from €29 a month for 50,000 checks; larger volumes are on Enterprise. Approved public-interest organisations can have the cap removed.