What we tested​

PlayCover-based sideloading of iOS apps onto ARM-based macOS, attempted against three operators in three jurisdictions:

What happened​

No successful exploitations across the three tested jurisdictions. All three platforms have robust defense against this hardware- abstraction method.

Why it matters​

PlayCover is the most credible iOS-on-Mac sideload tool. Three different geo vendors blocking it on three different operators is a clean "compliant tier" signal — worth recording as parity context against the FD WV PlayCover bypass on the same day, which is the outlier.

FD WV PlayCover bypass (failure) → · May 11 weekly sync →

What stayed. The DraftKings Sportsbook and the DraftKings mobile apps remain on GeoComply. This is a partial-displacement, not a wholesale loss.

Open question being tested. Whether running two different geolocation providers side by side introduces compliance or security gaps — internal ticket CIV-65: DraftKings DFS - validate the competitor's integration.

Why it matters. This is Radar's first major US live-traffic win on a Tier-1 operator. The sales narrative is two-sided:

• Concerning: DK's procurement team has now signed off on Radar for a regulated US product. Other operators may treat this as permission.
• Constructive: The pattern "challenger gets the DFS web slice, GeoComply keeps everything else" is the new template for second-source attempts. Lead with "we keep the high-stakes stuff" in displacement conversations.

Counter-evidence. Radar's compliance gaps across other operators (rooted-hidden Android, resigned iOS, GPS simulator, jailbroken iOS at Sleeper/PrizePicks/Fliff, Chrome extension at Underdog) are independent of this migration and should be in every DK-adjacent conversation.

Radar profile →

What we tested​

Three distinct exploitation methods against the FanDuel WV (Radar) deployment, from Tennessee:

1. iOS app resigning — re-signed FanDuel iOS app with security controls bypassed.
2. Virtualised environment emulation via VMOS — Android device-farm environment running a cloned profile.
3. Sideloading via PlayCover on ARM-based macOS — iOS app loaded on Apple Silicon Mac via PlayCover.

What happened​

All three succeeded. Each technique facilitated out-of-state betting on the WV app. Critical and persistent failure to prevent unauthorized access or potential multi-accounting activities.

Cross-reference — same vectors, different results elsewhere​

• iOS app resigning was detected at Bet Saracen AR on April 7 — see Radar / Saracen AR: resigned iOS app detected. The gap is FD-WV-specific or build-specific.
• PlayCover was detected at Bet365 MI, Fanatics TN, and Bet Saracen AR on the same day — see cross-operator PlayCover blocked. FD WV is the outlier.
• VMOS is also undetected at Bet Saracen AR — see Bet Saracen AR: VMOS not detected. The Android device-farm gap is wider than just FD WV.

Radar profile → · May 11 weekly sync →

What we tested​

Three spoof vectors against Bet Saracen AR (Radar): VMOS Android device-farm, PlayCover sideloading on ARM-based macOS, resigned iOS app.

What happened​

• VMOS (Android) — NOT detected. Out-of-state bet placed from Tennessee.
• PlayCover (ARM macOS) — detected and restricted ✓
• Resigned iOS app — detected and blocked ✓

Why it matters​

The mixed result confirms Radar's posture is per-vector-uneven: catches the ARM-macOS hardware-abstraction vector and resigned iOS app integrity, but the Android VMOS device-farm slips through. This is also the second operator (after FanDuel WV) where the same VMOS gap shows up — a structural Android detector issue.

Radar profile → · FD WV three-method bypass → · May 11 weekly sync →

What happened. No device-level geolocation in place. RobinHood relies solely on IP address to verify player location. Basic location- spoofing tools went undetected. A player can bypass all location restrictions without any sophisticated technical knowledge.

Why it matters. This is not a geo vendor finding — RobinHood is not using a geolocation product. It falls significantly short of regulated gaming standards and represents a meaningful compliance exposure. Worth tracking as a competitive opportunity (RobinHood prediction markets is a greenfield for a real geo product) and as context when evaluating competitor footprints in prediction markets (Kalshi, Polymarket are also in Locance's expansion list).

Cross-reference, same test cycle. Bet365 TN (Radar) replay-attack: network-level attacks fully blocked. Minor visibility gap in the verification flow but not exploitable in practice — no compliance risk.

Radar profile → · Xpoint profile →

What happened. Both tools bypassed Locator's RDP detection. Out-of-state wagering succeeded on both platforms.

Three more gaps from the same test cycle (May 5 weekly).

• No state border buffer zones — players within 50m of the boundary experience frequent state-switching, persistent page refreshes, and inability to finalise cash-out.
• No IP-change monitoring — IP address changes during active sessions are not flagged. A critical spoofing indicator is missed.
• VPN restriction false positives — aggressive VPN blocks fire on legitimate corporate-network users, increasing support overhead.

Why it matters. Four distinct compliance gaps in a single Fanatics TN test, all in the flagship US deployment. This is the single strongest sales asset against a bundled-OpenBet platform pitch. Pair with the prior border- jumping finding and the TQJ-churn data point.

OpenBet profile → · SDK comparison →

What we tested​

Distance-graded validation runs against Bet Saracen AR (Radar browser-based deployment) from inside the regulated jurisdiction, on Mac + Windows desktops.

What happened​

• 350m+ from the state line — success rates remained high. ✓
• 100m mark — Mac devices cleared only 44% of verifications.
• Windows users — hit a persistent lockout after a single failure, further complicated by an atypical fraud_jumped_single_device flag during betting attempts.

Why it matters​

100m is a city-block distance — well inside the state. A 44% pass rate at that range is direct booked-bet revenue loss for the operator. The Windows persistent-lockout behaviour is worse: a single retry triggers an account-level block with no clear self-service recovery path. Support ticket volume scales linearly.

The fraud_jumped_single_device flag is interesting — it suggests Radar's device-fingerprint logic is misidentifying repeat verification attempts as suspicious device-jumping behaviour. Pair with the Underdog DFS device-counting bug (every login = new device) — same architectural class of problem.

Radar profile → · Underdog device-counting bug → · May 5 weekly sync →

What happened. Radar effectively restricted both active sessions — wagering outside permitted borders was prevented during tool operation.

Why it matters. This is one of the few positive Radar results we have. Sales conversations should be honest: AnyDesk + TeamViewer are detected at Saracen AR. The narrative is "Radar catches the obvious ones but misses the adjacent ones."

Cross-reference (same test cycle, less positive).

• Pre-loaded Windows "Remote Screen Sharing" triggered account restriction silently — false-positive RDP flag, high support-ticket risk.
• Cross-Boundary Validation passed: attempts to wager from Oklahoma uniformly blocked across all test cases.
• 350m+ from border: high success rates. 100m: Mac 44% pass rate; Windows users hit persistent lockout after a single failure with atypical fraud_jumped_single_device flag.

Action. Add HopToDesk, iPhone screen mirroring, RustDesk, VNC, MS Teams remote-control to the Radar test scope per the May 11 Betting Hero plan — these are the adjacent tools that distinguish "catches the obvious" from "is a compliance product."

Radar profile →

The finding​

The pre-loaded Windows Remote Desktop Connection app (labelled "Remote Screen Sharing" in the OS) triggers Radar account restrictions without notifying the user.

Why it matters​

This is a false-positive RDP flag: the app is present on virtually every Windows install, and is not running an active remote session. Triggering account restrictions silently from its mere presence is the worst case for support teams — the user has no idea what failed, no suggested resolution path, and no diagnostic message.

Cross-reference (same test cycle)​

On the same operator + same week, AnyDesk and TeamViewer were correctly restricted during active sessions (positive result). So the detector posture is: detects two real RDP tools, false-positives on one pre-installed Windows app it shouldn't flag. The RDP class is where Radar is most inconsistent.

Radar profile → · May 5 weekly sync →

Volumes​

• Location verification failures dominate end-user complaints — 38% of all findings in the monitoring window.
• DraftKings: 11 mentions — app lag causing re-verify loops.
• FanDuel: 9 mentions — location dropping mid-session.

Both patterns are consistent with geo-check frequency friction, not outright failures. That's an account-management conversation, not a displacement conversation.

Circumvention sophistication is growing​

Circumvention attempts are present in every weekly report and rising: 2 → 3 flags per week. The community has moved beyond basic VPN queries to peer-sharing GPS spoofing and mock-location methods on Reddit. An active DraftKings VPN bypass thread was still gaining replies in the April 27 report. Reddit-sourced bypass methods should feed directly into our spoofing test backlog.

ACTION ITEM: All spoofing cases (even implied) should be reported to the testing team to reproduce. Claimed DK Magisk bypass — test already requested.

KYC friction is the halo problem (23%)​

KYC friction (23% of findings) is concentrated at Fanatics and DraftKings — duplicate account suspensions, document rejection loops, 2+ week verification delays, SSN privacy objections.

QUESTION: Do we want to perform KYC competitor research? Do we want a list of all geolocation operators and their known KYC, with feedback about every KYC provider?

What happened. Undetected. Radar did not flag the browser-extension spoofing.

Adjacent gaps from the same test (April 28 weekly).

• Device-counting logic flaw — every login at Underdog is recorded as a new device, regardless of whether the device has been seen before. Inflates device counts and prevents multi-account detection — significantly weakening fraud detection.
• Border crossing — testing confirmed users can continue placing wagers for approximately 1 minute after entering a restricted zone before Radar intervenes. Regulatory compliance risk.
• Increased geolocation frequency + buffer-zone false positives — no single-license support; more frequent checks; unnecessary failures.
• Loss of meaningful error messaging — generic error messages for all geolocation failures post-GeoComply switch; ability to self-troubleshoot eliminated; support contact volume likely up.

Why it matters. A free Chrome extension that anyone can install defeating Radar's regulated-DFS deployment is the entry-level sophistication. The device-counting flaw makes multi-accounting effectively free. Bundle these into the Underdog talking points.

Radar profile →

It's a backend-toggled feature (Radar's backend enables it per integration), so we don't yet know whether it will be enabled for gaming markets. Tracking intensity also adjusts automatically based on geofence context — even mid-outage.

Why it matters. This is a meaningful step in Radar's strategic direction documented in the Apr 14 weekly: shifting from "where is the user?" to "can we continuously trust this location?" The 3-week-to-2-month release cadence is producing functionality that's interesting in retail / non- gaming contexts but unproven in regulated contexts.

Watch point. We need to validate whether offline-generated geofence events satisfy regulatory requirements (the regulator typically expects a server-side decision and full audit trail per transaction). If Radar enables offline events on a gaming integration, this is a finding worth escalating.

GitHub monitoring. As of Apr 14, we are subscribed to both XPoint and Radar GitHub repos to track new releases, SDK changes, and any publicly visible technical updates going forward.

Radar profile →

The signals.

• Fanatics users report selfie / ID scans failing repeatedly on sign-up.
• A separate account suspension immediately following a winning streak — with funds held and bank statements submitted but no resolution.

Consistent with the pattern of negative Fanatics / OpenBet sentiment tracked since February.

Why this matters. The "post-winning-streak suspension" is a specific fraud-investigation playbook problem that operators run into when their KYC + geo + risk stack is uncoordinated. Locator's lack of IP-change monitoring (May 5 test) and the absence of state-line buffer zones (50m state-switching at Fanatics TN) compound the post-win review pile.

Bigger pattern (May 5 monthly brief). KYC friction is now 23% of all end-user complaints in monitoring. Not a geo issue but creates halo damage: users conflate geo lockouts and KYC holds into a single "the app won't let me play" complaint.

OpenBet profile →

The findings​

• Mobile Hotspot Incompatibility — geolocation verification is unstable when connected via mobile hotspots on Mac + Windows; prevents legitimate wagering.
• Installation Workflow — access denial during web installation triggers persistent download prompts, regardless of whether the software is already on the system.
• Auto-Launch — Radar initiates automatically on system startup (Mac + Windows) without consent. Intrusive UX, support load.
• Desktop CPU — location checks trigger 4% CPU spikes every 10s at 600m from the border. Consistent resource drain — and the closer you get to the border, the more frequent the checks.
• Software Compatibility — inconsistent Radar performance across macOS Tahoe 26.0.1 vs 26.3.1 and Chrome 146 vs 147. Point releases break the integration.

Why it matters​

Three of these (auto-launch, install prompts, hotspot incompat) generate support tickets. The CPU pulses are not catastrophic but become noticeable on poker tables. The macOS / Chrome version sensitivity is the most concerning — Radar's desktop integration is fragile across the exact version range that most US users sit on.

For BetSaracen players this stacks on top of the existing generic "account security" error messaging (no diagnostic data, high self-troubleshoot friction).

Radar profile → · April 14 weekly sync →

What we tested. Approach to the OK state border from inside the regulated jurisdiction at varying distances, on iOS / Android / desktop (Mac+Windows over public Wi-Fi).

What happened.

• iOS — validation unsuccessful until 100m from the state line.
• Android — validation unsuccessful until 220m from the state line.
• Desktop (static, public Wi-Fi) — verification failed at 1,750m from the border on both Mac and Windows. Success threshold undetermined.

Why it matters. Legitimate users physically inside the licensed state — but close to the border — can't bet. The mobile case (100–220m windows) maps directly to lost revenue: 100m and 220m are city-block distances, not edge cases.

The 1,750m desktop failure is more severe — the user is nowhere near the border, and the system still can't verify. That's not a buffer zone, that's a broken validation flow.

Radar profile → · April 14 weekly sync →

Cadence​

Radar ships every 3 weeks to a couple of months. We are now subscribed to both XPoint and Radar GitHub repositories to track new releases, SDK changes, and any publicly visible technical updates going forward.

Strategic direction​

Clear shift from "where is the user?" to "can we continuously trust this location?" — via four axes:

1. IP-triggered re-validation — location re-checked on network / IP change.
2. Multi-signal decisioning — motion, device context, network alongside GPS.
3. Indoor / vertical accuracy — floor-level detection on mobile plus BLE beacons.
4. Modular fraud architecture — plugin-based, allows rapid new detection logic.

Why it matters​

This is the architectural pitch Radar is making to non-gaming customers (retail, mobility) — and the same plumbing is what lets them say "we're adding compliance signals quickly." Worth watching whether the v3.31.0 offline geolocation events (April 24) are enabled on any gaming integration — that would be a notable regulator-attention moment.

Radar profile → · April 14 weekly sync → · v3.31.0 offline events →

Headline. FanDuel dominated complaints this week — persistent location errors, bans for cross-state logins, and one high-impact case: a user denied a $12,000 payout due to a "suspicious location" flag.

Adjacent signals.

• DraftKings — multiple reviews citing location checks taking 10+ minutes, disrupting live bets.
• Bet365 (XPoint web / Radar mobile) — continued app freeze + bet slip erasure reports; one user must delete and reinstall the app every session.
• Fanatics (OpenBet) — location error on first launch reported by new users.

Why this matters. A denied $12K payout in public Reddit / X chatter is the kind of operator-anxiety story account managers can use to start a conversation about geo-check frequency tuning. Note: state attribution is hard from the public posts; whether the user was on a GeoComply or non-GeoComply state is uncertain.

QUESTION (from the weekly): Do we want to contact our clients about feedback, and if so, how do we want to approach them?

Why it matters. Bet365 is XPoint's flagship US reference, often quoted in displacement conversations. Confirming that even Bet365 needed a co-provider on the most important surface (mobile = the bulk of session volume) reframes the displacement narrative. The pitch becomes "Bet365 needed two challengers to do the job GeoComply does with one."

Adjacent signal. Bet365 (XPoint web) social signal continued through April: wrong-state detection (MD placed in NJ), endless XPoint Verify install loop, app freeze + bet slip erasure, delete-and-reinstall every session, 1-star reviews. Bet365 (Radar) Android also accumulated 1-star reviews ("location verification is trash", "Stuck on trying to find the location, very bad app, likely a scam").

Spoof posture, same operator. Reddit user publicly asked how to spoof XPoint Verify from Florida. Two users offered help via Magisk. Worth a dedicated Magisk + XPoint Verify investigation.

Xpoint profile → · Radar profile →

What we tested. Jailbroken iOS device with root hiding enabled. Attempted to wager from a prohibited location on three operators in sequence: Sleeper Sports, PrizePicks, Fliff.

What happened. All three allowed the wager through. Radar did not detect the jailbroken / root-hidden state on any of the three.

Why it matters. This is a structural Radar SDK gap that surfaces at every operator, not an operator-specific bug. The same compliance hole appears in three different deployments (DFS, sweepstakes, social gaming) within a single week of testing.

Radar profile → · April 7 weekly sync →

What we tested. Re-signed iOS app on Bet Saracen Arkansas.

What happened. Radar successfully detected the resigned app and displayed appropriate error messaging — betting activity was prevented, and the account was not auto-blocked. Clean result.

Cross-reference. Contradicts the FD WV result from March 31, where the same attack class went undetected and bets were placed from TN. Two operators, two different outcomes for the same exploitation method — points to inconsistent / operator-specific detector behaviour in Radar's SDK. Follow-up validation scheduled pending the next iOS app release.

Radar profile → · March 31 FD WV failure → · April 7 weekly sync →