What proof of identity requests really check

Every operator running more than a handful of accounts eventually gets the same message: “We need to verify your identity.” It shows up on ad platforms, marketplaces, payment processors, and social apps. Most people either panic or assume it’s a random speed bump. Neither reaction is useful. The request is a specific, mechanical process, and understanding what it actually checks tells you more about account health than any forum thread will.

This isn’t a guide to beating verification. It’s a breakdown of what’s happening on the other side of the upload button, written from the position of someone who runs real proxy and cloud-phone infrastructure and has to keep dozens of legitimate accounts stable across it. If you manage multiple genuine accounts for a business, agency, or brand portfolio, knowing what these systems test changes how you build your setup from day one.

The document itself gets forensic treatment, not a glance

When you upload a passport or ID card, almost no platform has a human look at it first. It goes through an automated document pipeline that checks font consistency, hologram and microprint patterns against a known template for that document type and issuing country, and whether the image has been re-compressed or edited (JPEG re-save artifacts, mismatched noise patterns between the photo region and the text region, cloned pixel blocks). Metadata matters too: an uploaded image with no EXIF data, or EXIF data that says it was created in an editing tool rather than captured on a phone, is a flag on its own.

This is why screenshots of documents, or documents re-photographed off a screen, tend to fail even when the underlying document is completely real. The forensic layer isn’t judging whether you’re a fraud. It’s judging whether the file in front of it behaves like a native camera capture of a physical object.

Liveness checks aren’t about your face, they’re about your camera feed

The selfie-with-a-blink or turn-your-head-slowly step is a liveness detector, and it’s testing signal quality more than identity. It’s looking for depth cues from natural head movement, for the kind of micro-jitter a real camera sensor produces versus the flat, over-smooth motion of a played-back video, and for lighting that shifts consistently with the angle you’re told to turn to. A pre-recorded video, even a good one, tends to fail because the light doesn’t behave right relative to the movement.

This step then gets compared against the photo in the document using a face-match model, which is a separate check from liveness. Passing liveness but failing the match (or vice versa) tells the platform two different things, and both get logged.

Device and network fingerprints are cross-referenced against the account’s history

This is the part most people underestimate. A verification event doesn’t happen in isolation. It gets scored against everything the platform already knows about the account: the device fingerprint used during signup, the IP ranges the account has logged in from, the timezone and language settings on the browser, and whether the SIM or carrier data behind a mobile session matches the declared country on the ID.

If an account has spent three months logging in from one consistent residential IP range in Singapore, using a browser profile with a stable canvas and font fingerprint, and the ID upload happens from that same environment, the verification step is confirming something the platform already believes. If the account’s history is a patchwork of different countries, wildly different device signatures session to session, or data-center IPs, the ID upload becomes the moment where all of that inconsistency gets flagged at once, regardless of whether the document itself is genuine.

This is the actual argument for running separate, consistent browser profiles per account rather than one browser juggling everything. It’s not about hiding from a platform. It’s that platforms build a behavioral baseline for every account over time, and a verification check is graded against that baseline. An antidetect browser profile that keeps one account’s fingerprint, cookies, and session state isolated and stable is doing the same thing a real, dedicated device would do: giving that account a consistent story instead of a noisy one.

Proxy and location consistency is checked, not just presence of a proxy

Platforms don’t reject an account simply because it’s behind a proxy. Plenty of legitimate users are on VPNs or corporate networks. What actually gets scored is consistency and plausibility: does the IP’s ASN look like a residential or mobile carrier rather than a known data-center block, does the geolocation implied by the IP match the timezone and language of the browser, and does it match the country on the submitted document. A mismatch between “ID says Malaysia” and “session has run exclusively through US data-center IPs for six months” is a much bigger signal than the mere existence of a proxy.

This is why the type of proxy matters more than whether one is used at all. A residential or mobile IP tied to a real carrier in the region matching the account’s declared identity produces a coherent story. A rotating data-center proxy with no consistent geography produces the opposite, and it’s an easy pattern for automated risk scoring to catch because data-center ranges are published and platforms maintain lists of them.

Behavioral history around the request matters as much as the request itself

Verification isn’t usually triggered at random. Common triggers include a sudden change in login location, a spike in account activity, a new payment method, or reaching a threshold (spend, followers, transaction volume) where a platform’s policy requires it. What happens in the days before and after the request gets weighed alongside the document itself. An account that was stable and then suddenly verifies from a new device and immediately changes payout details is a different risk profile than one that verifies and continues behaving exactly as it always has.

This is the part warm-up practices are actually about. An account with a gradual, believable usage history, built on a consistent device and network profile from day one, arrives at a verification event with a track record to back it up. An account that was created yesterday and immediately pushed into high-value actions has no such record, and the document alone can’t manufacture one.

What this means for how you build the stack

None of this is a loophole to exploit. It’s a description of a system built to reward consistency and flag noise, which is exactly what you’d want if you were designing it yourself. The practical takeaway for anyone running a legitimate multi-account operation, whether that’s an agency managing client ad accounts, a seller running multiple storefronts, or a brand with regional accounts, is to treat infrastructure as part of the account’s identity, not an afterthought bolted on when a verification request shows up.

That means one browser profile per account with its own persistent fingerprint, a proxy whose type and geography actually matches where that account is supposed to be based, and a cloud phone or device profile that stays assigned to the same account rather than getting reused across a dozen of them. None of this guarantees a verification pass, and no one running real infrastructure should tell you it does. What it does is remove the self-inflicted inconsistencies that turn a routine check into a rejected one.

If you’re building out a fleet of accounts and want the underlying browser, proxy, and device layer to actually hold up, take a look at what we run at Multi Account Ops.

Get new guides and videos first — join the Telegram channel.