21 posts tagged with "xpoint"

Source. June 30, 2026 weekly sync — End-user Feedback (Valeria).
Dataset. Social Media Competitive Signals · Reddit + X/Twitter public posts.

GGPoker / WSOP (former 888) — flagged for awareness​

A GGPoker / WSOP player (former 888, XPoint deployment) reported to us that a location-related issue causes the game screen to freeze/blink, preventing any in-game action.

GGPoker is no longer a current GeoComply customer, but the report is flagged given competitive relevance in the poker / iGaming space.

BetRivers — RSI feedback scan summary​

Since the XPoint migration, there is a recurring pattern of desktop / WiFi geolocation failures that do not show up on mobile:

• Users on PC are flagged as out-of-state despite testing multiple browsers, networks, and even public WiFi.
• The same connection works fine on phone / tablet.
• Common workaround: switch to cellular-only or disable whichever network interface is not in use.

Representative quotes:

"Hello since they went to the new xpoint software I can no longer use my pc they keep thinking im playing out of state when im not. I have tried multiple pcs browsers my neighbors internet even using a pc at walmart with there internet and it doesnt work" — Reddit, May 19, 2026

"Started doing this to me this morning and I don't use a VPN. What I still can't figure out is that with Betrivers it won't let me place bets when I'm connected to my home wifi. I have to disconnect and only use cellular with Betrivers. Every other app is fine. This started about a month or so ago." — May 2026

Additional signals​

• Apple App Store review (June 21): consistent location-verification failures blocking bet submission. Workaround: navigate into support and back — but that triggers new scrolling / UI bugs.
• Twitter (April 21, June 9): geolocation described as inconsistent and "needing a serious update" — users report app reinstalls sometimes required to temporarily fix it.
• Delaware user (April 17): told their location was invalid while physically in-state on the Delaware-specific platform — suggests the boundary / geofence detection issue is not limited to ambiguous border cases.

Why it matters​

Public friction on BetRivers aligns with the June 23 / June 30 Pennsylvania field-test gaps on XPoint — desktop geo is failing users in production while mobile often works, and the same vendor missed sustained RDP sessions in controlled testing the same week.

June 30 weekly sync → · BetRivers PA CIV-88 retest (June 30) · BetRivers social brief (June 23)

Source. June 30, 2026 weekly sync.
Ticket. CIV-88: BetRivers PA — advanced spoofing review (retest).

What we tested​

Two additional spoofing checks from the June 23 CIV-88 cycle, confirmed during the week ending June 30:

1. FaceTime RDP — sustained session duration
2. Tailscale Mac-to-Mac RDP — detection reliability

Both against BetRivers Pennsylvania (XPoint).

What happened​

1. FaceTime RDP — 1-hour confirmed session

• ✗ A tester in New Jersey remotely controlled an iPhone in Pennsylvania via Apple's built-in FaceTime screen sharing.
• ✗ The session ran for a full hour — bets placed continuously on both sportsbook and casino throughout.
• ✗ No block or interruption at any point.

This confirms the initial FaceTime gap is not a brief window at login — it is an open, sustained exposure for the full session duration.

2. Tailscale Mac RDP — detection failed

• ✗ Two Macs paired under one Tailscale account.
• ✗ An out-of-state device initiates remote control of an in-state (PA) host via native macOS screen sharing (Finder).
• ✗ No local interaction required on the host — the remote connector receives full control.
• ✗ The geolocation check passes against the host's in-state position.

Why it matters​

Both retests deepen the Pennsylvania compliance picture from June 23:

• FaceTime — the gap is now quantified as hour-long, not transient. Any operator conversation about "we catch it eventually" is contradicted by a full session of uninterrupted wagering.
• Tailscale + macOS — the same unattended desktop-control pattern that GeoComply blocked on FanDuel NJ the same week remains undetected on BetRivers PA / XPoint.

Cross-reference​

• BetRivers PA (XPoint) — initial CIV-88 advanced spoofing (June 23).
• GeoComply / FanDuel NJ — same Tailscale Mac RDP method blocked immediately (June 30, CIV-94) — direct same-method, same-week contrast.
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19, CIV-73).

Xpoint profile → · June 30 weekly sync →

Source. June 23, 2026 weekly sync — End-user Feedback (Valeria).
Dataset. Social Media Competitive Signals · Reddit + X/Twitter public posts.

BetRivers — investigation in progress​

BetRivers feedback is being investigated now for a full report. Early signals from the June 23 sync:

No volume spike, but XPoint sentiment is clear​

We do not see spikes in overall complaint volume on Reddit, but there is clear disapproval towards XPoint on BetRivers threads — consistent with the field-testing gaps on PA deployments this cycle.

Representative posts (May 2026):

"Hello since they went to the new xpoint software I can no longer use my pc they keep thinking Im playing out of state when im not. I have tried multiple pcs browsers my neighbors internet even using a pc at walmart with there internet and it doesnt work"

"Started doing this to me this morning and I don't use a VPN. What I still can't figure out is that with Betrivers it won't let me place bets when I'm connected to my home wifi. I have to disconnect and only use cellular with BetRivers. Every other app is fine. This started about a month or so ago."

KYC + support — spiking themes​

Sentiment fully leans towards KYC issues:

• Roughly every third post on r/betrivers is about not being able to verify an account for days.
• Support overload — no email replies for days; phone lines taking hours.

Not necessarily a direct geolocation correlation, but areas where GeoComply's KYC + geo stack positioning can help in operator conversations.

Why it matters​

Public XPoint friction on BetRivers aligns with both the June 16 / June 23 Pennsylvania test gaps and the Michigan RDP improvement with residual RustDesk timing risk — social noise and field results are pointing the same direction this month.

June 23 weekly sync → · BetRivers PA advanced spoofing (CIV-88)

Source. June 23, 2026 weekly sync.
Ticket. CIV-63: Bet365 MI — full Radar / XPoint integration research.

What we tested​

Remote desktop detection retest on bet365 Michigan and BetRivers Michigan (both XPoint) — RustDesk and the commercial RDP stack (HopToDesk, AnyDesk, TeamViewer).

What happened​

• ✓ HopToDesk, AnyDesk, TeamViewer — detected and blocked before a bet could be placed on both Michigan integrations. This is a key difference from prior cycles — XPoint did improve commercial RDP detection.
• ⚠️ RustDesk — blocked, but with timing and install nuance.
  • The prior launch-order identification lag (June 2 finding) was not reproduced under rigorous retest.
  • Session was blocked at the first interval check — approximately 290 seconds (~4.5 minutes) later.
  • RustDesk is detected only while actively running — not when merely installed. A player can have RustDesk on their device without triggering an alert until a session starts.

Why it matters​

Commercial RDP detection on Michigan deployments is materially better than historical baselines — worth citing in competitive conversations. The RustDesk result is improved but not clean: a ~4.5-minute active- session window and silent tolerance of a installed-but-idle copy still leave residual exposure, especially vs GeoComply's real-time mid-session blocks on comparable vectors.

Pennsylvania BetRivers deployments still show undetected native iOS and Tailscale paths in the same test window (June 23 advanced spoofing review, CIV-88).

Cross-reference​

• bet365 MI (XPoint) — RustDesk launch-order flaw (June 2, CIV-64).
• Bet365 MI (Radar / XPoint) — full validation (May 26, CIV-63).

Xpoint profile → · June 23 weekly sync →

Source. June 23, 2026 weekly sync.
Ticket. CIV-88: BetRivers PA — advanced spoofing review.

What we tested​

Advanced spoofing checks on BetRivers Pennsylvania (XPoint), building on the June 16 compliance analysis.

What happened​

1. Tailscale + Mac RDP — undetected

Two Macs on the same Tailscale account. Mac1 (out of state) connects to Mac2 (in PA) using macOS built-in screen sharing via Finder. Mac2 user does not need to be present — the remote user gets full control.

2. Rooted Android + mocked location — undetected (retested on mobile network)

Same non-compliant result on mobile connection. Setup uses Magisk with a renamed manager to avoid detection, root partially hidden. Key nuance: the mock location app (FakeGPS) is technically visible to BetRivers, but a custom low-level module suppresses the mock-location flag before BetRivers can read it — which is why it gets through. A second rooted device lost its integrity status and needs troubleshooting.

3. FaceTime RDP — undetected after local auth

The in-state person must physically handle the phone to log in and enter the 2FA code. Once logged in, the remote user takes full control — requires brief cooperation from the in-state user at the start, but no presence after that.

Why it matters​

All three vectors succeeded in a follow-up cycle. The Magisk module path defeats the SDK's mock-location signal at the OS layer — not merely by hiding the spoofing app. The Tailscale + macOS pattern delivers fully unattended desktop control, which is the highest-risk RDP class on Pennsylvania deployments this month.

Cross-reference​

• BetRivers PA (XPoint) — initial compliance analysis (June 16, CIV-88).
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19, CIV-73).

Xpoint profile → · June 23 weekly sync →

Source. June 16, 2026 weekly sync — End-user Feedback (Valeria).
Dataset. Social Media Competitive Signals · Reddit + X/Twitter public posts.

World Cup — no volume spike​

The FIFA World Cup has not affected the number of competitive signals we see in the monitoring window. Overall chatter volume is flat vs the prior period.

Bet365 (XPoint) — lower volume, same root issues​

Geolocation complaints dropped from 12 → 4 comparing the older monitoring period to the recent one. The nature of the complaints is unchanged:

• Mandatory third-party download (BrowserGuard / plugin friction).
• Geo check wiping the betslip mid-flow.
• Location dropout during live betting.

Lower volume does not mean the underlying UX / integration friction has improved — the same recurring themes persist.

KYC — accelerating share of total signals​

• KYC complaints: 0.8 → 1.3 per day (+63%).
• KYC share of total signals: 14% → 33%.

KYC friction is becoming a larger slice of end-user noise even as raw Bet365 geo complaint count falls. Worth tracking whether this is operator-specific or a broader market pattern in the next cycle.

Why it matters​

Bet365's geo narrative in social channels is shifting from volume to persistence — fewer posts, same complaints. The KYC spike is the new headline for operator-experience conversations and may feed the testing backlog if specific bypass claims surface.

June 16 weekly sync →

Source. June 16, 2026 weekly sync.
Ticket. CIV-88: BetRivers PA — compliance analysis.

What we tested​

A compliance analysis of BetRivers Pennsylvania (XPoint) covering native iOS remote-control methods, Tailscale + macOS native screen sharing, rooted Android with mock-location concealment, and a baseline suite of standard remote-access tools, IP-change detection, Android fake location apps (FLA), and a resigned iOS app.

What happened​

Vector	Result	Notes
Native iOS RDP (FaceTime + iPhone Mirroring)	✗ Undetected	Remote operator in an out-of-state location placed bets on the in-state Pennsylvania iOS device.
Tailscale + macOS native RDP	✗ Undetected	Mesh VPN tunneling combined with built-in macOS screen sharing was not flagged.
Rooted Android + concealed mock location	✗ Undetected	Root state and hidden mocked coordinates both went unnoticed; bets and gameplay succeeded from an exclusion state.
TeamViewer, AnyDesk, HopToDesk	✓ Blocked	Standard commercial remote-access utilities were identified and suppressed.
IP change detection	✓ Blocked	IP-based relocation checks fired as expected.
Android fake location apps (FLA)	✓ Blocked	Geolocation manipulation frameworks were detected before wagering.
Resigned iOS app	✓ Blocked	Tampered iOS binary was rejected.

Why it matters​

Three high-impact vectors — iOS screen sharing, Tailscale-based macOS RDP, and root-concealed mock location — all succeeded on the same operator while the "standard toolkit" checks passed. That pattern suggests detection tuned to known commercial RDP signatures and common FLA tools, but blind to native OS remote-control channels and Magisk-level telemetry suppression. The iOS and Tailscale gaps are especially material given prior undetected Tailscale findings on other XPoint deployments.

Cross-reference​

• BetRivers PA (XPoint) — advanced spoofing review: Tailscale macOS RDP, Magisk mock-location suppression, FaceTime handoff (June 23, CIV-88) — follow-up cycle on the same operator and ticket.
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19, CIV-73) — same Tailscale class of attack, different state.
• Bet365 MI (XPoint) — RustDesk launch-order flaw (June 2, CIV-64) — another XPoint desktop RDP gap in the same test window.

Xpoint profile → · June 16 weekly sync →

Source. June 2, 2026 weekly sync.
Ticket. CIV-64: MI advanced spoofing retest.

What we tested​

RustDesk remote access against bet365 MI (XPoint) on both Windows and macOS, varying the launch order of RustDesk relative to the XPoint geolocation client.

What happened​

• ✓ RustDesk launched before XPoint → flagged immediately.
• ✗ RustDesk opened after XPoint was already active → undetected on both Windows and macOS. Over 50 consecutive location checks passed with the remote tool running.
• Detection only resumed once the XPoint client was manually rebooted.

Why it matters​

The behaviour points to a one-time startup scan for prohibited software rather than real-time monitoring. The vulnerability stems from a predictable initialization sequence: an adversary who recognises the pattern can bypass desktop geolocation on bet365 MI simply by activating remote access after launch — a repeatable, low-effort gap that leaves a notable regulatory exposure open for the duration of a session.

Cross-reference​

• OpenBet / Fanatics MI — HopToDesk undetected on Android (CIV-64) — the mobile half of the same MI advanced-spoofing retest.
• Bet365 MI (Radar / XPoint) — full integration validation (May 26) — prior multi-issue cycle on the same operator.
• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale undetected (May 26, CIV-73) — second XPoint remote-access gap, different mechanism.

Xpoint profile → · June 2 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-63: Bet365 MI — full Radar / XPoint integration research.

What we tested​

A full integration validation of Bet365 Michigan — Radar for the mobile app, XPoint for the web client. Covered: near-border behaviour, cross-state jurisdiction handling, two RDP attack paths (iOS, Windows), and post-failure UX.

What happened​

Area	Result	Notes
Near Canadian border (Belle Isle)	✗ Inconsistent at 200–1,000 m from the border. Betting slip continued to load but functioned unreliably — suggests an insufficient buffer zone.
Detroit ↔ Canada cross-border	✗ An erroneous jurisdiction alert fired on the betting slip, incorrectly telling the user wagering is restricted to New Jersey residents while on Bet365 MI.
iOS FaceTime RDP	✗ Undetected. A tester in Massachusetts placed bets remotely on a device located in Michigan with no issues.
Windows RDP	✗ Undetected. A tester in Massachusetts placed wagers on both the sportsbook and casino via a Windows device located in Michigan.
UX — post-VPN-detection recovery	✗ Persistent application glitches after a VPN-detection event. Tester unable to resume wagering; forced restart of the app required to restore functionality.

Why it matters​

This validation lands five separate issues on a single operator in a single test cycle:

1. Two compliance failures on the same border — buffer-zone unreliability + a flatly wrong jurisdiction message. Either could be cited as a regulator-facing defect.
2. Two undetected RDP paths — iOS (FaceTime) and Windows — both spanning multi-state remote sessions. RDP is the textbook remote-betting fraud vector and both paths went uncaught.
3. The UX recovery loop is broken even when detection does fire. A user who triggers a VPN block cannot recover without restarting the app, and receives no guidance on how to do so.

Cross-reference​

• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale + Screen Sharing undetected (May 26) — third undetected RDP path on Bet365 in two weeks (NJ and MI, two geo providers).
• Bet365 NJ (Radar) — Tailscale + RealVNC RDP undetected for 25+ minutes (May 19).
• Bet365 MI (Radar) — GPS simulator bypass, restriction not re-applied on re-entry (May 19) — distinct prior gap on the same operator.

Radar profile → · Xpoint profile → · May 26 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-73: Bet365 NJ — Remote Desktop via macOS Screen Sharing (XPoint).

What we tested​

A common fraud pattern: one computer remotely controls another computer in a different location to place bets. We tested whether Bet365's geolocation provider could detect this when the operator runs on XPoint (Bet365 NJ).

Stack used:

• Tailscale — a networking tool that connects two computers over the internet as if they were on the same local network.
• macOS Screen Sharing — Apple's built-in remote-desktop feature, driven through the Tailscale link.

What happened​

• ✗ Tester accessed Bet365 NJ from a different physical location through the macOS↔macOS remote session.
• ✗ XPoint failed to detect this remote-access method. Bets were placed without interruption.

Why it matters​

This is a clean compliance gap on a vector specifically targeted by remote-betting fraud. The bypass uses entirely off-the-shelf, legal tools — Tailscale and a feature already built into macOS — with no exotic configuration.

Follow-up testing across Radar, OpenBet, and GeoComply-integrated clients has been requested to scope whether this is XPoint-specific or a broader macOS RDP detection gap across providers.

Cross-reference​

• Bet365 NJ (Radar) — Tailscale + RealVNC RDP undetected for 25+ minutes — same operator, different geo provider, same Tailscale-based attack pattern.
• RSI BetRivers NJ (XPoint) — Tailscale RDP inconsistent (May 19) — second XPoint integration where Tailscale-based RDP is unreliably detected.

Xpoint profile → · May 26 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-73: BetRivers NJ — RDP via macOS.

What we tested​

Remote desktop access against the RSI BetRivers New Jersey XPoint deployment, driven from macOS via Tailscale. Two distinct attack methods were exercised:

1. Brief one-time approval — first-touch remote-session setup requires a single approval prompt at the controlled device.
2. Fully unattended — no prompt, no human interaction required at the controlled device after initial enrolment.

What happened​

• Most cases: not detected. XPoint failed to flag Tailscale-based remote access in the majority of runs, allowing bets to be placed from a physically separate location.
• When detection did trigger: inconsistent and trivially bypassable. Detection events did not persist — logging out and back in cleared the restriction and the session continued.
• Both attack methods confirmed. Both the one-time-approval path and the fully-unattended path placed bets successfully.

Why it matters​

This is the second cross-state confirmation of XPoint's RDP detection gap, alongside the FaceTime RDP failure at RSI Delaware (Apr 7). The gap is structural, not state-specific — RSI deployments in multiple states (AZ, DE, NJ) all show the same pattern.

Combined with the Bet365 NJ Tailscale + RealVNC bypass on Radar this week, both challenger providers running NJ sportsbooks are blind to Tailscale- driven remote sessions.

Cross-reference​

• RSI Delaware (XPoint) — FaceTime RDP not detected — same cross-region pattern, different RDP tool.
• Fanatics NJ (OpenBet) — droidVNC-NG RDP blocked and named — OpenBet handles a comparable RDP-on-Android vector at the same operator footprint.

XPoint profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-48: Test Fake Location using GPS Simulator Accessory on Competitor Apps.

What we tested​

A hardware GPS simulator accessory was used against the RSI BetRivers Tennessee (XPoint) deployment.

What happened​

The GPS simulator went fully undetected — no first-login error, no session-mid restriction. The tester logged into the Michigan app from Tennessee and played a casino game with no errors or restrictions triggered at any point.

Why it matters​

This is the cleaner-cut version of the Bet365 MI Radar gap on the same vector this week. Where Bet365 (Radar) flagged the simulator on first login and then forgot about it, RSI BetRivers (XPoint) never flagged it at all.

This is also consistent with our standing position on XPoint's unsigned iOS SDK (March 24): the SDK ships with a public GPS injection method and can be patched to inject coordinates before every compliance check. A hardware GPS-simulator accessory is a more expensive way to achieve the same outcome — and it still works.

Cross-reference​

• Bet365 MI (Radar) — GPS simulator re-entry bypass — Radar caught it once then let it through.
• Fanatics TN (OpenBet) — GPS simulator detected — clean detection with a specific error message.
• XPoint capability spoof.gps-hw is verified no since March 24 — this finding reinforces it on a fresh operator.

XPoint profile → · May 19 weekly sync →

Source. May 11, 2026 weekly sync — "Unsuccessful Spoofing Methods" section.

What we tested​

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

Operator	Geo provider	Result
Bet365 MI	Xpoint (web)	✓ Neutralized at authentication
Fanatics TN	OpenBet Locator	✓ Neutralized at authentication
Bet Saracen AR	Radar	✓ Identified at the betting stage

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 we confirmed. Bet365's geolocation stack is split — XPoint on the web, Radar on mobile.

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 →

Source. Reddit thread on Bet365 / XPoint from a Florida user. April 7 weekly research sync.

The signal. A Florida-based user publicly asked how to spoof Bet365 XPoint Verify. According to two other users in the thread, there are ways — and one user said "I can help you spoof it through Magisk."

Why this matters. This is a regulated-market vulnerability being openly shared between players. Magisk is a hidden-root tool for Android, the same class we've already shown XPoint fails to detect in internal testing. The community is one step ahead of the operator.

Action. Magisk + XPoint Verify bypass is now in the test queue (May 5 monthly brief: "Magisk bypass on Bet365 / XPoint" added to the 15-ticket queue).

Xpoint profile →

Source. Google Play Store review of the RushStreet Android app (XPoint-powered). Surfaced in the April 7 weekly end-user-feedback section.

The quote.

"I've been playing poker and lately it's been freezing up, losing location, and I've got kicked off and lost money on tournaments."

Why this matters. RushStreet AZ was XPoint's flagship GeoComply displacement in January 2026, and RSI DE was added in April. This is a live customer of the live deployment describing the exact failure mode internal testing keeps surfacing — freezes, location loss, mid-session session termination. The lost-tournament-money detail is also a regulator-attention magnet.

Adjacent context. XPoint's Mac CPU spikes (0.5% → 16% at 1-min intervals during poker, RSI DE testing April 7) are consistent with the poker-specific symptom the player reports.

Xpoint profile →

What we confirmed. Splash Sports (DFS) is planning to offload XPoint in June 2026. Reported in the Apr 7 weekly research and reconfirmed Apr 14.

The reason. Splash Sports runs DFS game modes that have different state-by-state availability. XPoint requires the operator to build the multi-state handling themselves — there is no XPoint product equivalent of:

• GeoComply Multipass — one integration, many regulated jurisdictions.
• GeoComply Dynamic Boundaries — operator-configurable boundary logic per game / per state.

Why it matters. This is direct sales evidence that XPoint's developer-friendly auth model (clientKey per session, no expiry, JWT, auto re-geolocation, jurisdictionArea field in response) does not actually solve the multi-jurisdiction problem. Lead with this in any DFS RFP conversation.

Action. Confirm Splash Sports as a GeoComply opportunity for the June 2026 offload window. Use the Splash Sports narrative in any operator conversation where XPoint is being evaluated for a multi-state product.

Xpoint profile →

What we tested. RSI Delaware deployment (newly live, April 2026), iOS device localised to DE, driven remotely via FaceTime RDP from a Michigan host. Both casino and sportsbook flows.

What happened. No RDP detection. The MI-based user successfully placed remote wagers on the DE platform across both products.

Cross-reference. The same gap was previously confirmed at the RSI AZ deployment (Jan 2026 migration from GeoComply). Two operators, two regions, same SDK gap — this is structural.

Related RSI DE findings (same test cycle).

• Account SUSPENDED on DE-MD border crossing before any spoofing attempt was made.
• Near-border pass/fail points inconsistent, erroneous failures even moving away from the boundary.
• Static/mobile toggling required at MD + DE borders — major UX friction vs GeoComply's seamless PA.
• macOS install requests access to documents folder (known security concern).
• AnyDesk installed (but not running) silently blocks betting — false positive RDP flag.
• Mac CPU spikes 0.5% → 16% at 1-minute intervals during poker.

Xpoint profile →

What we obtained. Raw iOS and Mac Xpoint SDKs (Mar 24 weekly sync). The iOS SDK is unsigned, the SDK module is findable, and the response payload returns raw coordinates + compliance decision in plaintext.

What it means. An attacker can patch the app to inject coordinates, placing the user inside a permitted jurisdiction before every compliance check. The trust boundary is on the client. This is not a bug — it's an architectural exposure.

Cross-reference. May 5 monthly brief documents "XPoint returns compliance decisions and raw coordinates in plaintext to the client with a public GPS injection method." Magisk bypass on Bet365 XPoint Verify is publicly discussed on Reddit (Apr 7 + Apr 14) — two users offering help.

Why it matters. SDK hardening (signed binaries, obfuscation, license-bound runtime) is a category-defining requirement for regulated gaming geo. Xpoint sells on developer-friendliness, but for a regulator-facing compliance product the same property is the structural problem.

Xpoint profile → · Xpoint document (internal)

Source. Reddit + X/Twitter public posts. Monitoring initiated March 2026.

Bet365 / XPoint is generating strong negative signal. Users report:

• Wrong-state detection — Maryland users placed in New Jersey
• Endless XPoint Verify install loop on desktop
• Multiple posts explicitly contrasting the broken Bet365 experience with GeoComply-powered books that "work fine"

Users are naming the provider switch as the root cause. This is a clean attribution — the geo layer is being identified by the community itself, not just by us.

Contrast. GeoComply complaints in the same monitoring window are vague and operator-attributed. Negative posts on FanDuel / DraftKings / Hard Rock exist, but frustration is directed at the operator experience, not the geo layer. No posts characterise GeoComply as fundamentally broken.

Xpoint profile →