Bot and fake account detection for fintech, before you pay for KYC

The documents are the part the attacker paid for. A synthetic or rented identity is built to pass document checks, and KYC catches it late, at a fee per check. Faking the visit at volume leaves traces instead. Every “different person” needs a different connection and a different device, application after application, and that shows up as a relay, a tampered browser or a device reused across applications, which can be checked before you pay for KYC.

Proxy plus fake browser is the farming signature. A residential proxy gives each application a clean home address in an eligible country, and a fake (antidetect) browser gives it a fresh device profile. When Maskbreak’s network intelligence recognises the exit as a proxy, it reports network.proxy: true while network.datacenter is false; not every residential exit is known. Maskbreak’s device check reports signs that the browser environment is being faked (device.antidetect, with a tampering_score from 0 to 1). Both signals are block under the default policy.

A new profile per application does not reset the check. It looks for signs that the browser is lying about itself rather than for a device it has seen before. How much it sees varies with the tool and its settings.

Web visits only. emulator_detected is also block by default where the device check reports it, but the check runs in the browser. It is not a mobile-app SDK and does not see traffic from your native app.

Repeat devices, counted inside your own account. Send your application or account ID with each check. device.linked_accounts counts how many of your accounts the device has been used with, and the reason multi_account_device appears once that is more than one. IDs are linked as keyed hashes and never compared with another customer’s. The reason is added without changing the decision. To act on it, escalate in your own code (treat an allow that carries multi_account_device as review, or apply your own threshold to device.linked_accounts), or set Multi-accounting to Review or Block on the console’s Rules tab. A rule changes the decision only for the signal it names, so a proxy, bot, fake-browser or emulator block on the same visit stays a block. The same count catches self-referral and bonus farming.

Throwaway inboxes. Send the applicant’s email too, and a disposable domain adds disposable_email, which moves an allow to review. It is a domain check only: no mailbox verification, no email or phone reputation. More on fake signups.

What it will not catch. One patient fraudster applying once, from their own laptop on their own broadband, produces an ordinary visit and an allow. That application is a job for your KYC vendor and transaction monitoring. The visit check takes out the industrial part (the farms, the scripts, the rented device profiles) so the expensive checks spend their time on the rest.

Credential stuffing looks like a thousand strangers. Each attempt comes from a different residential address, so the per-IP limits and blocklists that stop one noisy server see nothing. What the attempts share is the tooling, which can show up as automation_detected for scripted and headless browsers, proxy_detected for the relay, tor_exit_node for Tor. All three are block by default. More in credential stuffing detection at the login.

Review is a step-up, not a refusal. A customer signing in over a VPN from a hotel is normal, which is why a VPN on its own returns review, with the VPN service named when known (network.service). Treat review as “ask for the passkey or second factor now”, not “decline”. The password and MFA still decide who the user is; the visit check decides how much proof to ask for. Why blanket VPN blocks cost real customers.

Check again before money leaves. A session that passed login can still be hijacked later, so evaluate the visit again on withdrawals, payouts, new beneficiaries and changes to payout details. You can store the device.visitor_id seen at sign-in and compare it at payout: a different device is a reason to step up. It is a risk signal, not proof of identity or a cryptographic device binding. See the account takeover playbook.

Gate the one-time code, too. Every OTP you send costs money, and a bot requesting codes for number ranges it earns a share on never types them in. A visit check before the send keeps scripted requests off your SMS bill. The SMS pumping guide shows the send-to-verify ratio that exposes it in your own data.

Route on decision, not on the score. A rule you set on the Rules tab changes decision and keeps the engine’s own answer in engine_decision, so your code never re-derives a threshold. See decision versus score.

Reasons you can put in a case note. Every reason is a stable machine code, which gives support and compliance a written answer to “why was this application declined?”. Keep it out of the customer-facing error: naming the signal that fired is free tuning feedback for the attacker.

Missing evidence is not a clean result. When the browser check did not complete, the device block is absent; once you enforce, hold the action for a verification step instead of treating it as allow. Each response also reports its own processing time in evaluated_in_ms, and measured figures are on /status.

No KYC, document or liveness checks. It does not read passports, match selfies or look up credit files, and it does no sanctions, PEP or adverse-media screening. It sits in front of the vendor that does.

No AML transaction monitoring or payment-risk scoring. It scores the visit, not the transfer, the card or the order. There is no chargeback guarantee.

Not MFA. It tells you when to ask for more proof. Passwords, passkeys, second factors and session management stay yours.

No shared identity network and no review team. Account linking counts your own accounts only, and your account IDs are never compared with another customer’s. There is no shared identity or consortium network, and no analyst reviews your cases. The device history fields (device.times_seen, device.first_seen) are the exception to “yours only”: they count sightings of the device across all checked traffic.

No published detection rate. None has been measured, so none is quoted. Run the check in watch mode on your own traffic and judge it by your own Events.

No compliance by association. Using a fraud API does not by itself make a deployment compliant. The check needs no name or document, but the visitor’s IP address is personal data under GDPR; the DPA and the privacy notice describe what is processed and for how long.