I've been tracking the fake account economy's evolution. The scale is staggering.

Platforms are seeing 20-40% of new registrations coming from coordinated fake account operations in high-risk categories. But here's the critical insight most teams miss: the fraud doesn't start at registration. It starts at the device level, often days or weeks before any identity check occurs.

Most fraud prevention architectures have a fundamental blind spot. They're optimized for the registration checkpoint and transaction flow, completely missing the device-level signals that reveal coordinated fake account operations before they submit a single form.

Enter SHIELD, a Singapore-based platform (founded 2008) that's built around a thesis: "The device is the root of fraud." Instead of waiting for identity verification or payment activity, SHIELD detects fake account operations at the device level before any transaction or identity check happens.

Based on my research into their deployments across ride-hailing, fintech, and marketplaces, they're addressing a detection window that most fraud platforms ignore entirely (Or they’re relying on sub-optimal in-house device_ID's or easily bypassed ID's like google ad ID).

From my research across consumer-facing platforms, a clear pattern emerges around when fraud actually begins versus when it's detected.

Professional fake account operations don't just create accounts randomly. They test platform defenses, establish device presence, understand detection patterns, and coordinate across device farms before ever hitting registration checkpoints. By the time they create accounts, they've already mapped your blind spots.

Most fraud platforms activate at registration (identity verification) or payment (transaction monitoring). Everything happening at the device level before these checkpoints is invisible. Platforms see the registration attempt but miss the reconnaissance, device fingerprinting evasion, and coordination that preceded it.

Traditional fraud tools operate on a flawed assumption: that the first interaction with a fraudster is when they submit registration forms or attempt transactions. In reality, sophisticated fake account operators are interacting with your platform long before that, testing defenses and establishing patterns.

inDrive, one of the world's largest ride-hailing platforms, faced fraud syndicates running coordinated attacks across fake accounts, GPS spoofing, and driver-passenger collusion. Traditional fraud tools flagged individual suspicious rides or accounts but couldn't connect them back to the coordinated device-level operation orchestrating the scheme.

Based on my analysis of their approach, SHIELD is challenging a fundamental assumption in fraud prevention architecture.

Fraud prevention focuses on identity (PII-based verification) and transactions (payment risk scoring). The implicit assumption is that you need to know who someone is or what they're doing financially to detect fraud.

"Most fraud solutions assume you need personally identifiable information (PII) to stop fraud. They focus on the person or the transaction (onboarding or payment). We believe that's backwards. Fraud starts at the device level, before any transaction or identity check ever happens. The device is the root of fraud."

Detect fake account operations at the source, the device, rather than waiting for registration or payment checkpoints. This shifts fraud detection from reactive (catching bad actors after they're in) to proactive (stopping them before they establish presence).

"Relying on weak device IDs and only starting to control platform access at the registration checkpoint" is the #1 mistake teams make. By the time registration happens, sophisticated fake account operations have already mapped your defenses and know how to bypass them.

Device fingerprinting persistence - Maintains stable device IDs across sessions and browsers and apps. This is critical because fake account operations rely on appearing as "new" devices to evade detection. SHIELD's persistence reveals when the same device is creating multiple accounts over time.

Real-time performance - ~14ms fraud decisions without impacting user experience. This matters because device-level detection must happen before registration loads, meaning any latency directly impacts legitimate user conversion.

Rather than point-in-time checks at registration or payment, SHIELD monitors device behavior continuously throughout sessions. This catches attacks as they escalate rather than after damage occurs.

Our intelligence, your decisions." SHIELD provides real-time JSON payloads with device intelligence that clients use to shape user experience, feed ML models, and enrich investigations. They explicitly don't action decisions, instead giving platforms the intelligence to make context-aware choices.

SDK-based with lightweight implementation. Most clients see meaningful insights within the first week and measurable fraud reduction within the first month. Time-to-value measured in days, not months.

Pure device signals rather than requiring PII, transaction data, or identity verification. This enables fraud detection before any of that information exists.

Industry agnostic due to device-first approach. Key industries include fintechs, digital banks, e-wallets, ride-hailing, delivery, iGaming, marketplaces, IDV/KYC vendors, and SaaS platforms. Essentially any consumer-facing mobile app or website dealing with account creation fraud.

Notable deployments:

Decision makers - Product, Trust & Safety, and Fraud teams. This stakeholder mix reflects that fake accounts impact both user experience (Product concern) and platform integrity (Fraud/Trust concern).

inDrive transformation:

Pre-SHIELD reality - Fraud syndicates operating across multiple vectors: fake accounts, GPS spoofing, and collusion between fake driver and passenger accounts. Millions in losses plus platform trust erosion affecting genuine users.

Detection challenge - Traditional fraud tools could flag individual suspicious rides or accounts but couldn't connect them back to coordinated syndicate operations. Each fraudulent activity looked isolated.

SHIELD deployment - Global rollout of device intelligence across the platform.

Results:

From investigating individual suspicious accounts to understanding the device-level coordination behind fake account syndicates.

SHIELD's approach illuminates several trends in how fake account fraud actually operates versus how it's typically addressed.

Sophisticated operations involve coordinated syndicates using device farms to create and control multiple accounts over time. These aren't simple bots failing CAPTCHA—they're organized fraud rings with specific economic objectives.

Professional fake account operators create accounts, let them age to appear legitimate, then activate for fraud. By the time they commit fraud, the account history looks normal. Device-level intelligence reveals the coordination invisible to identity or transaction analysis.

In marketplaces and ride-hailing, fake account fraud often involves collusion between multiple account types (buyer/seller, driver/passenger). Traditional fraud tools analyze each account independently. Device intelligence reveals when supposedly independent accounts are controlled from the same devices.

In location-based platforms (ride-hailing, delivery, gaming), GPS spoofing is often paired with fake accounts. The account might pass identity checks, but device intelligence reveals location manipulation that traditional KYC misses entirely.

Platform operators are investing heavily in identity verification and payment fraud prevention while the fake account problem operates in a detection blind spot—before identity checks and outside payment flows.

Niche device fingerprinting tools offer device identification but may lack the fraud-specific intelligence and continuous monitoring that platforms need for fake account detection.

Pure device-first fraud intelligence rather than comprehensive fraud platform. The "our intelligence, your decisions" approach means they're providing signals rather than actioning blocks. This positions them as complementary to existing fraud infrastructure rather than replacement.

Market timing factors:

Device-level fraud detection is moving from specialized capability to core infrastructure requirement as fake account operations become more sophisticated and costly.

The detection window is shifting earlier in the user journey - From post-registration identity verification to pre-registration device intelligence. Platforms that wait until registration to start fraud prevention are giving fake account operations too much information about their defenses.

Intelligence vs. decision separation is becoming standard architecture - Rather than fraud tools that both detect and block, platforms want intelligence layers they can combine with business context for nuanced decisions. SHIELD's "our intelligence, your decisions" reflects this trend.

Strategic question for platform operators - At what point in the user journey does your fraud prevention activate? If the answer is "registration" or "first transaction," you're missing the device-level coordination that precedes both.

SHIELD represents the maturation of device-first fraud prevention from niche capability to core platform infrastructure. Their positioning challenges the assumption that identity verification is the first line of defense against fake accounts.

If your fraud prevention starts at registration or payment, you're giving sophisticated fake account operations a free reconnaissance window to map your defenses and coordinate attacks.

Established player (founded 2008) with significant platform deployments (Alibaba, Deliveroo, inDrive). Product-market fit validated across multiple high-scale verticals.

Platforms that adopt device-level fraud intelligence gain earlier detection of coordinated fake account operations before they establish presence. As fake account economics become more sophisticated, the detection timing advantage becomes more valuable.

Based on my research, SHIELD is addressing a real architectural gap in how most platforms think about fake account prevention—the assumption that fraud detection should start at identity verification rather than device presence.

Where does fraud prevention start in your platform architecture? Hit reply and let me know if you're seeing device-level coordination that identity verification misses.

Tool Details:

​