Use cases by industry
Fraud detection by industry: where each attack starts
SaaS trial farms, fintech signup-bonus rings, e-commerce card testers, iGaming multi-accounters and the crews taking over patient and benefit accounts mostly run the same kit: a residential proxy, a fake browser, automation. What changes is the moment an account becomes worth faking or stealing. That moment is where the check goes, and it also decides what a review should trigger in your app.
The first attack in six industries
For each industry: the attack that usually arrives first, the moment it happens, what it looks like in the response and what the default policy does with it. Field names are the real ones from POST /v1/evaluate.
SaaS
Serial free trials
First attack: the same person on trial number twelve, with a new email, cleared cookies and a fresh residential IP. On an AI product every farmed trial is inference you pay for.
When: the trial signup, before a workspace, an API key or free quota exists.
The tell: send the new account's ID as accountId, and multi_account_device appears when the device is already linked to another of your accounts. A resetter who bothers with a fake browser usually shows up as antidetect_browser instead, which blocks; a throwaway inbox shows up as disposable_email when you send the signup email.
Default decision: a fake browser blocks and disposable_email raises allow to review. A device on several accounts is listed as a reason and leaves the decision alone, so act on it in your signup handler.
Fintech & banking
Fake accounts at onboarding
First attack: signup-bonus farms and synthetic applicants. A run of "different people", each on a new fake-browser profile behind a residential proxy in a bonus-eligible country, each with documents built to pass the identity check.
When: onboarding start, before you pay for the identity check. Check again at payout and beneficiary changes.
The tell: proxy_detected or antidetect_browser on an application or, when the farm reuses a device instead of a fresh profile, one device linked to several applicants (multi_account_device).
Default decision: a proxy or fake browser blocks, so the KYC fee is not spent on that application. A VPN alone returns review, and the application still goes to KYC, on your stricter path.
E-commerce
Card testing
First attack: a bot runs a stolen card list through small authorizations on your checkout or donation form to learn which cards are live. Depending on your processor, each attempt can carry a fee, and the charges that go through can come back as disputes.
When: checkout, after the form posts and before you create the payment intent.
The tell: automation_detected behind rotating proxies (proxy_detected) and, when the bot keeps its browser, the same device.visitor_id attempt after attempt while the IP changes every time.
Default decision: automation or a proxy blocks. Key your velocity limit on the visitor ID, not on the IP the bot changes on every attempt.
Gaming & iGaming
Bonus farming
First attack: one operator claims the welcome offer, referral reward or deposit match on dozens of accounts, often from emulators or fake-browser profiles. The same stack runs ban evasion and smurfing.
When: account creation, then the bonus or reward claim, before anything is credited.
The tell: multi_account_device with device.linked_accounts above 1, emulator_detected or antidetect_browser. A virtual_machine asks for review.
Default decision: an emulator or fake browser blocks; a virtual machine alone is review, with its reason listed. Gate the claim on device.linked_accounts in your claim handler, with a threshold taken from the values you log during watch mode (why not a Rules-tab setting).
Healthcare
Patient-portal takeover
First attack: leaked password lists tried against the patient portal, each guess from a different home connection, so no single address looks busy. One taken-over account opens the patient's records, prescriptions and insurance details.
When: portal login, after the account lookup and before the password compare. Password reset, at the request and again at completion.
The tell: a device this patient has never used (compare device.visitor_id with past logins), arriving with proxy_detected or automation_detected.
Default decision: a proxy or automation blocks; answer it exactly like a wrong password. A VPN alone is review: send a code to the phone on file. Hospitals, health systems and public-health bodies can apply to have the cap removed.
Government & public services
Benefit-account takeover
First attack: a stuffed login on a claimant account, the contact email changed so no notice arrives, then new bank details before the next payment. Relief schemes also see batches of applications filed under stolen, real identities.
When: the bank-detail or contact change, where a takeover becomes a payment. Then login, password reset and the application form.
The tell: a device this claimant has never used, over a proxy, minutes before the change. For stolen-identity batches: one device linked to many new applications (multi_account_device).
Default decision: a proxy, automation or fake browser blocks, so refuse the change and tell the old address. Review accepts the change into a hold with a cancel link; nobody is refused over a VPN. Public bodies can apply to have the cap removed.
What a review should mean in your industry
Industries differ most on the middle answer. Here is a VPN exit on a cloud server, with nothing else flagged, from the public sample endpoint (synthetic data you can reproduce; selected fields):
curl 'https://maskbreak.com/v1/evaluate/sample?scenario=vpn'
{
"sample": true,
"decision": "review",
"risk_score": 65,
"reasons": ["vpn_detected", "datacenter_asn"],
"network": { "vpn": true, "proxy": false, "datacenter": true,
"tor": false, "service": "PROTON_VPN" }
}
review means the evidence is not enough to refuse. Plenty of real customers use a VPN. What it should trigger depends on what the account is about to receive:
- SaaS trial signup: start the trial, and confirm the email before the free quota or API key is issued.
- Fintech onboarding: send the application to KYC on the stricter path and keep the reasons with it. A VPN alone is never grounds to decline.
- E-commerce checkout: take the order and step up with 3-D Secure, or hold shipment on a high-value basket.
- Gaming and iGaming: open the account, and hold the bonus, not the account, until email or phone verification passes.
- Patient portal: send a one-time code to the phone on file. Nobody is locked out.
- Benefits portal: accept the bank-detail change into a hold and tell the old address, with a cancel link.
Choosing between the score and the decision? Route on decision; the reasoning is in risk score thresholds.
Default decisions, and the rules each industry changes
The engine's defaults are the same for every account. On the console's Rules tab you set an action per signal (allow, review or block) and pin exceptions for a single IP address or device; when a rule changes the outcome, decision carries your answer and engine_decision keeps the default.
How rules combine
- Every rule applies to every check on your account, logins and checkouts included.
- A rule changes the decision only for the signal it names. Anything else on the same visit keeps its default weight: with VPN set to allow, a VPN visitor on a fake browser is still blocked, and with Multi-accounting set to review, a linked device behind a proxy still blocks.
- To lower a block, set a rule on the signal that caused it; a visit with two blocking signals needs both. Emulators and time-zone mismatches have no rule, so no rule lowers them.
| Signal | Default | When to change it |
|---|
Proxy (proxy_detected) | Block | Rarely. A known office or partner proxy can be pinned as an exception for that address. |
Tor exit (tor_exit_node) | Block | Health and public-service portals that must stay reachable over Tor can set it to review. |
| Automation, emulator, fake browser | Block | Keep it in almost every industry, and pin your own QA machines as exceptions. Only Bot / automation and Fake browser are Rules-tab settings; emulators have none. |
VPN alone (vpn_detected) | Review | Apps with only low-risk logins can move VPN to allow. Moving it to block turns away real customers. |
Anonymising network alone (anonymous_network) | Allow, reason listed | Read network.anonymous where a hidden origin matters, such as a bank-detail change, or set Anonymising network to review on the Rules tab; proxies and Tor exits, usually flagged as anonymising too, still block. |
Disposable email (disposable_email, when you send email) | Raises allow to review | Trial and bonus signups can set it to block. |
Cloud server alone (datacenter_asn; “Datacenter server” on the Rules tab) | Allow, reason listed | Consumer apps can set it to review; a proxy or headless bot on a cloud server still blocks. Leave it on allow where visitors browse from virtual desktops or corporate gateways. |
One device on several of your accounts (multi_account_device, needs accountId) | Listed, decision unchanged | Trial signups, bonus claims and referral payouts: read device.linked_accounts in that handler. A Rules-tab setting applies to every check, logins and checkouts included, from the second linked account on (how rules combine). |
Start every industry the same way: watch mode first, logging each decision and letting every visitor through, then enforce once the Events log matches what you expected. The staged rollout guide walks through it.
What Maskbreak does not replace
Maskbreak answers one question: who is really behind this visit. Keep the tools that answer the others.
- Fintech: your KYC and document-verification provider. Maskbreak screens the session before that check is paid for and verifies no identity itself.
- E-commerce: your payment-risk or chargeback tool. There is no order or transaction scoring here and no chargeback guarantee.
- Healthcare and government: passwords or passkeys, MFA and session management. The verdict tells you when to step up; it authenticates nobody, and there is no HIPAA business associate agreement.
- Everyone: there is no identity network shared between customers (device links are per customer and stored as one-way hashes), no manual review team, and the email check is a disposable-domain signal only. No detection rate has been benchmarked or published.
Questions about fraud detection by industry
Does fraud detection need to be different for each industry?
The detection mostly does not; the policy does. The residential proxies, fake browsers and automation behind a trial farm are the same ones behind a bonus ring or a stuffed portal login, so one evaluation reads all of them. What changes is where you call it (trial signup, onboarding, checkout, bonus claim, portal login, bank-detail change) and what your app does with a review.
Can one fraud detection API cover fintech, e-commerce and gaming?
For the session, yes: one POST /v1/evaluate returns allow, review or block with the reasons, at any of those moments. It does not cover the layers around the session: KYC and document checks in fintech, order scoring and chargeback guarantees in e-commerce, payment risk in iGaming. Keep those tools and put this check in front of them.
Where in my app should the fraud check go?
Just before an account receives something of value: the trial signup in SaaS, onboarding before KYC in fintech, checkout before the payment intent in e-commerce, account creation and the bonus claim in gaming, login and password reset on a patient portal, the bank-detail change on a benefits account. Start in watch mode, logging each decision and letting every visitor through, and enforce once your Events log looks right.
Will blocking VPN users hurt real customers?
It would, which is why a VPN on its own returns review, never block, under the default policy. Proxy, Tor, automation, emulator and fake-browser signals block. Each industry decides what review means: a one-time code at a portal login, a hold on a bank-detail change, 3-D Secure at checkout.
Can Maskbreak link fake accounts across my platform?
Within your own account, yes. Send your accountId with each evaluation and, when the browser device check completed, the response carries device.linked_accounts and, above one, the multi_account_device reason. Links are stored as one-way hashes and never cross to another customer.
How much does fraud detection cost for my industry?
The same in every industry: Maskbreak's Free plan includes 10,000 visitor checks a month, every signal included, no card, and paid plans start at €29 a month for 50,000. Every plan runs the same checks; plans differ only by volume, and larger volumes are on Enterprise. Approved public-interest organisations, such as public bodies and health providers, can have the cap removed.
Free plan: 10,000 visitor checks a month, no card. Paid plans from €29 a month.
No demo call. Sign up, copy the key, run your first check in watch mode.