Most signup flows are designed by taking things away. If you remove a field, conversions improve. Skip the email confirmation, and more users activate. If someone checks the data and sees the phone number field isn’t needed, that goes too. This approach usually makes sense and is good product work for most of a product’s life.
But this same process also makes it easier and cheaper for someone to create fake accounts.
The FTC reported that people lost $16 billion to fraud in 2025, which is a 25% increase from the previous year and the highest amount ever recorded. Almost all of that money moved through accounts—whether to receive, launder, or steal it. Often, the fraud a product faces a year and a half after launch actually starts much earlier, during the onboarding steps teams keep optimizing.
The signup form is the easiest and least expensive place to stop fraud
The longer fraud goes undetected in your system, the more expensive it becomes. If you block a fake account at signup, you only lose one potential user. If you catch it after the first deposit, you have to deal with a reversal and a support ticket. If you find it six months later, you face chargebacks, manual investigations, regulatory filings if you’re licensed, and any harm the account caused to other users. If you never catch it, someone else will—often a payment processor or a journalist.
This is why identity checks should happen when the account is created, not later during the first withdrawal. KYC software is built into the signup process and answers a few key questions before the account is even made: Is the document real? Does the face in front of the camera match the document? Does the person match the information they entered? Have you already onboarded this person under different names this week?
Notice that users can’t simply answer these questions by typing more carefully. That’s important. Any check that relies only on the data users submit can be easily scaled by attackers, just as it can by you.
What actually arrives at your signup form
Four things show up, and each needs a different defense.
The first type is a stolen identity used without changes. The attacker uses a real name, document number, date of birth, and address, but none of it belongs to them. Data checks pass because the information is real.
The second type is a synthetic identity. The Federal Reserve defines this as “the use of a combination of personally identifiable information (PII) to fabricate a person or entity in order to commit a dishonest act for personal or financial gain.” For example, someone might use a real national ID number, a fake name, and a real address. Since there’s no direct victim, nothing gets flagged, and the account can act normally for a long time while its limits increase.
The third type involves documents that have been generated or changed by AI models. FinCEN issued an alert about this on 13 November 2024, describing how criminals alter real images, create fake faces, and combine these with stolen personal information to make fake driver’s licenses and passports. Now, a photo of a document is a rendering challenge, and the technology has become very advanced.
The fourth type is often the most interesting to engineers because it’s a software attack, not a forgery. Instead of showing a fake document to a camera, the attacker sends video directly into the verification system. FinCEN calls this out as a red flag: “A customer uses a third-party webcam plugin during a live verification check.” Your liveness check sees a perfect face because it’s being fed a perfect image. There was never anything in front of a real camera.
The checks that hold up
The hard truth is that the most obvious way to build this won’t stop any of these four types of fraud.
Just reading the document isn’t the same as verifying it. OCR can pull a name and date of birth from an image and send them to your database, but that only proves the text is readable. True verification means checking the document’s security features, fonts, layout, and machine-readable zone against how that document is really issued by the country. This is a reference-data problem before it’s a machine-learning problem.
Matching a selfie doesn’t prove the person was actually present. A face match only shows that two images look alike. Liveness checks are supposed to confirm the second image came from a real person, not a screen or file. But the injection attack described earlier can fool basic liveness checks, so you need to verify something about the capture method itself, not just the image.
Device and location signals can catch things that images miss. FinCEN’s red flags include cases where a customer’s “geographic or device data is inconsistent with the customer’s identity documents” and when there are rapid transactions in new accounts with little history. These are easy signals your app already collects but often ignores.
Most real fraud detection happens when you compare accounts. One suspicious signup might not mean much. But forty signups in a week that share a device fingerprint, document template, and similar birthdays are clear signs of fraud. This only works if you store verification results as structured data that your fraud system can analyze, not just as a simple pass or fail.
Friction is a budget, so spend it where the risk is
Teams often resist verification because they imagine the strictest version being applied to every user. But it doesn’t have to be that way, and doing so is a sure way to lose good customers who were never a risk.
Think of friction as something you can spend. A returning user on a familiar device making a small purchase should face almost no checks. A new account asking for a high limit from a location that doesn’t match its document should get a full document and liveness check. For cases in between, use a partial check that only escalates if something looks suspicious.
There’s a practical point to consider early: the rules that trigger each level of checks should be in your configuration, not hard-coded. Fraud patterns change faster than your release schedule. If you need a new deployment to tighten a threshold, it probably won’t happen in time.
For example, if a gaming platform discovers a bonus-abuse ring on a Friday night, it needs to increase checks for new accounts within an hour—not wait for the next sprint.
Building it yourself is a bigger project than it looks
Engineers are right to ask if this is something to buy. But the real question isn’t just build or buy—it’s which part you should build yourself.
The capture and verification layer becomes outdated quickly. Every country issues several types of identity documents, each with unique layouts and security features, and they get redesigned without notice. If your template library is a year old, it won’t just miss fraud—it will also reject real customers with new documents, costing you real signups even as you think you’re stopping fraud.
Liveness checks are even harder because they’re adversarial. You’re not just tuning a model against a fixed set of data—you’re up against people who test your system, figure out what works, and share those methods. A detection model that worked well last year is now familiar to attackers.
Then there’s the capture channel, which isn’t a model problem. To defend against injected video, you need SDK-level work for each mobile platform and browser, plus a way to prove the images came from a real camera on a real device. This is specialized engineering with no clear finish line.
Holding biometric data brings its own exposure on top. Illinois BIPA requires prior written consent, gives individuals a private right of action, and sets statutory damages at $1,000 per negligent violation and $5,000 per intentional or reckless one. Under GDPR, biometric data processed to identify someone is special category data with stricter conditions attached. Building the stack means owning all of that yourself, permanently.
What’s worth building is the layer above. Your risk rules, scoring, step-up logic, and understanding of how accounts relate to each other are unique to your product, and no vendor can provide them for you. The document and liveness layer below is just infrastructure. Someone has to maintain it, but it doesn’t have to be your team.
The mistake that costs the most
The most common mistake isn’t just choosing the wrong vendor. It’s treating verification as a simple screen, when it should be a signal.
If your verification step just returns a yes or no and forgets everything else, you lose most of the valuable information. Details like document type, country, device, number of attempts, reasons for failure, and similarities to rejected accounts are all useful to your system. If your integration only asks “did they pass,” all that data is lost.
Design verification as a signal that feeds into your risk scoring and support tools. Then, onboarding isn’t just an extra step—it’s your first and most affordable piece of evidence about every customer. The teams that control fraud best aren’t the ones with the fanciest tools. They’re the ones who put a real check at the front door and actually use the information it gives them.
- What Are Android Vitals? A Simple Guide for Developers - September 10, 2026
- How Online Fraud Starts at the Onboarding Stage And How to Stop It - September 10, 2026
- Finding the Best AI Software Development Agency: 2026 Buyer’s Guide - September 9, 2026
