bGuru

bGuru Sub-Processor List

Version 0.1.9published

Last updated: 2026-06-08

bGuru Sub-Processor List

This is the public list of all third-party sub-processors that bGuru engages to provide the Service. We update this list when a sub-processor is added, removed, or replaced — see the Changelog at the bottom of this page.

For the legal framework that governs these relationships, see:

  • Privacy Policy §5 (Sub-processors)
  • GDPR Art. 28 (Processor obligations) — applies for users in the EU/EEA
  • UK GDPR Art. 28 — applies for users in the UK
  • Israeli Privacy Protection Law 5741-1981 + Amendment 13 — applies for users in Israel
  • Comparable obligations under CCPA / CPRA / VCDPA / CPA / etc. for US users; under APPI / PIPA / PDPA / POPIA / etc. for users in other jurisdictions

If you have a question about any sub-processor, contact legal@bguru.app. We commit to responding within one month per GDPR Art. 12(3) and equivalent obligations.

Active sub-processors (MVP)

1. Supabase, Inc. — backend platform

  • Purpose: Postgres database, authentication, storage, edge functions, real-time subscriptions.
  • Data categories processed: account data (email, hashed password, OAuth identifier, display name), avatar images (user-uploaded or imported once from Google/Facebook OAuth profile picture at signup), prediction data (picks, scores, conviction values), social data (groups, follows, comments, reactions), session tokens (JWT).
  • Data residency: Frankfurt, Germany (eu-central-1). bGuru migrated to Frankfurt on 2026-05-29 specifically to maintain EU data residency.
  • Sub-processor of Supabase: AWS (infrastructure layer; AWS Frankfurt).
  • Legal basis for transfer to Supabase: For EU/UK users: data stays in Frankfurt (no international transfer). For US/Israel/rest-of-world users: contractual processor relationship under each jurisdiction's local law.
  • DPA: Supabase's standard DPA (GDPR Art. 28 + UK Addendum); see https://supabase.com/legal/dpa.
  • Privacy Policy of provider: https://supabase.com/privacy

2. OneSignal, Inc. — push notification delivery

  • Purpose: Delivery of push notifications to user devices (iOS APNs + Android FCM).
  • Data categories processed: OneSignal player_id (a unique device identifier issued by OneSignal), push token (issued by Apple APNs or Google FCM), notification preferences (opt-in/opt-out, topic subscriptions), notification delivery telemetry (sent / received / clicked).
  • Data residency: United States (primary); EU mirroring optional.
  • Legal basis for transfer to OneSignal: For EU/UK users: International Data Transfer Agreement (IDTA) / EU Standard Contractual Clauses (SCCs) Annex I-III per Implementing Decision (EU) 2021/914, supplemented by OneSignal's EU-US Data Privacy Framework certification. For Israeli users: PPL Regulations (Transfer of Data Abroad) 2001 with DPA-equivalent contractual protections.
  • DPA: OneSignal's standard DPA; see https://onesignal.com/dpa.
  • Privacy Policy of provider: https://onesignal.com/privacy_policy

3. Functional Software, Inc. (dba Sentry) — crash reporting + performance monitoring

  • Purpose: Application error tracking, crash reporting, performance monitoring.
  • Data categories processed: device model, operating system + version, app version, anonymised user identifier, error stack traces, network request metadata (URL only, no body), performance metrics (route render times, etc.). No email, no display name, no prediction content — these fields are explicitly scrubbed before any data is sent to Sentry.
  • Data residency: EU region (sentry.io/eu). Specifically chosen to maintain bGuru's EU data residency posture (matches Supabase Frankfurt).
  • Sample rates at MVP: errors 100% (capture all), performance 10%, session replay 0% (off).
  • Retention: 30 days (Sentry's default; matches the free Developer tier).
  • Legal basis for transfer to Sentry: For EU/UK users: data stays in EU (no international transfer). For Israeli users: PPL adequate-country list (EU = adequate). For US users: standard processor relationship under CCPA Art. 1798.140(o).
  • DPA: Sentry's standard DPA (GDPR Art. 28); see https://sentry.io/legal/dpa/.
  • Privacy Policy of provider: https://sentry.io/privacy/

4. API-Football (API-Sports) — sports data feed

  • Purpose: Sports fixtures, results, statistics, team data, league data.
  • Data categories processed: None of bGuru's user personal data is transmitted to API-Football. This is a one-way ingest from API-Football to bGuru's servers (Supabase Frankfurt). API-Football has no view of bGuru's users.
  • Data residency: France (API-Football's servers).
  • Why on the sub-processor list: For transparency. API-Football is technically not a personal-data sub-processor (no personal data flows), but listing here makes the data-flow architecture fully visible.
  • DPA: Not required (no personal data processed by API-Football on bGuru's behalf).
  • Privacy Policy of provider: https://www.api-football.com/privacy

5. Apple, Inc. — App Store distribution + platform services

  • Purpose: iOS app distribution, App Store / TestFlight, push notification routing (APNs), platform-level telemetry (crash reports via Apple's built-in mechanism, install metrics, etc.).
  • Data categories processed: Apple ID (account-creation identity), device identifiers (vendor identifier per IDFV, NOT IDFA — bGuru does not request IDFA at MVP), platform crash logs (Apple's built-in mechanism, in addition to Sentry).
  • Data residency: Worldwide (Apple's infrastructure).
  • Legal basis for transfer to Apple: Standard platform-tier processor relationship. Apple's data handling is governed by Apple's own Privacy Policy.
  • DPA: Apple's developer terms include data-processing provisions.
  • Privacy Policy of provider: https://www.apple.com/legal/privacy/

6. Google LLC — Play Store distribution + platform services

  • Purpose: Android app distribution, Play Store, Google Play services (push notification routing via FCM, Play Integrity, etc.).
  • Data categories processed: Google account (account-creation identity), Android advertising identifier (GAID — not read by bGuru at MVP), platform crash logs (Play Console Vitals, in addition to Sentry). For users who sign up via Google OAuth: bGuru fetches the user's Google profile picture once at signup and stores it in Supabase Storage (Frankfurt). After that one-time import, Google does not continue to host the user's avatar on bGuru's behalf — Google is an identity provider only, not an ongoing image-hosting sub-processor.
  • Data residency: Worldwide (Google's infrastructure).
  • Legal basis for transfer to Google: Standard platform-tier processor relationship.
  • DPA: Google Play's developer terms include data-processing provisions.
  • Privacy Policy of provider: https://policies.google.com/privacy

7. Meta Platforms, Inc. (Facebook) — OAuth identity provider

  • Purpose: Optional "Sign in with Facebook" authentication. Facebook processes your Facebook account identity and, at signup only, provides your Facebook profile picture to bGuru for one-time import.
  • Data categories processed: Facebook account identifier (OAuth token, stable account ID), Facebook profile picture URL — accessed once at signup to import the avatar into Supabase Storage. After import, bGuru stores the image on its own servers and Facebook does not continue to host the image on bGuru's behalf.
  • Data residency: Worldwide (Meta's infrastructure).
  • Legal basis for transfer to Meta: Standard platform-tier identity-provider relationship. Meta's processing as an identity provider is governed by Meta's own Privacy Policy. The one-time avatar-import fetch is a standard OAuth user-profile-data request at signup.
  • DPA: Meta's developer terms include data-processing provisions.
  • Privacy Policy of provider: https://www.facebook.com/privacy/policy/

8. Cloudflare, Inc. — mini-site CDN + DDoS protection

  • Purpose: Hosting of the public mini-site (bguru.app) including the Terms of Service, Privacy Policy, Cookie Policy, Community Guidelines, sub-processor list page, and (later) share-link SSR pages. CDN, DNS, DDoS mitigation, Web Application Firewall.
  • Data categories processed: IP address (transient, for routing + bot-detection), browser User-Agent string (transient), Cloudflare's bot-detection cookie (essential function only, not behavioural).
  • Data residency: Worldwide (Cloudflare's edge CDN); EU edge nodes serve EU visitors per Cloudflare's data residency commitments.
  • Legal basis for transfer to Cloudflare: For EU/UK users: EU SCCs + Data Privacy Framework. For Israeli users: PPL DPA-equivalent contractual protections.
  • DPA: Cloudflare's standard DPA; see https://www.cloudflare.com/cloudflare-customer-dpa/.
  • Privacy Policy of provider: https://www.cloudflare.com/privacypolicy/

Sub-processors used by sub-processors (transitively disclosed)

For transparency, bGuru's primary sub-processors above themselves rely on the following infrastructure-tier providers:

  • AWS (Amazon Web Services) — used by Supabase for Frankfurt-region database + storage hosting.
  • Apple APNs / Google FCM — used by OneSignal for the actual push delivery transport.
  • Stripe — NOT currently used (no payment processing at MVP). Will be added in a future version if/when paid tiers ship.

Inactive / not-yet-used sub-processors (for transparency)

  • Stripe / Paddle / other payment processor — NOT used at MVP. Will be added when a paid Premium Tipster tier ships in a future version.
  • Google LLC (AdMob) — advertising (NPA Phase 1 and personalized Phase 2) — NOT active at MVP; planned for v1.1+. The AdMob SDK (react-native-google-mobile-ads) was removed from the MVP codebase on 2026-06-08 (branch chore/remove-admob-mvp). No ad data of any kind is transmitted to Google AdMob at this version of the Service. The re-introduction plan is documented in docs/features/feature-13-admob-rollout-plan.md. Phase 1 (NPA-only, npa=1, no IDFA, no GAID, no behavioral profile) is the first milestone; Phase 2 (personalized/behavioral advertising) is a further future step. When Phase 1 activates in v1.1+: the Google AdMob entry will be moved to the active section above, the 30-day material-change notice described in the Cookie & Ad-Tech Policy §9 will be issued before any ad serves, and the Privacy Policy and Sub-processor list will be updated to name AdMob as an active processor with full data-category disclosure.
  • k-ID / PRIVO / SuperAwesome KWS / Yoti (parental-consent providers) — NOT used at MVP. Will be added when Brazil / India / Canada / Quebec / Belgium markets are opened in v1.1.
  • Translation services — NOT used at MVP. Will be added when French / Dutch / German translations are commissioned for v1.1 Canada / France / Belgium re-opening.

How we choose sub-processors

For every prospective sub-processor, bGuru evaluates:

  1. Data minimisation — the sub-processor must process only the data necessary to perform its function.
  2. Data residency — preference for EU-region providers where available (matches our Frankfurt Supabase posture).
  3. Contractual protections — GDPR Art. 28-compliant DPA, UK GDPR equivalent, PPL-equivalent contractual protections, equivalent obligations under all other applicable laws.
  4. Sub-processor transparency — the sub-processor must publish its own sub-processor list and notify of changes.
  5. Security posture — current SOC 2 Type II report, ISO 27001 certification, or equivalent.

How to be notified of changes

We update this page when sub-processors change. For users who want active notification of changes:

  • EU / UK / Israel users — material additions of sub-processors (a category-of-data change, a data-residency change) are subject to the standard ToS §15 30-day material-change notice flow (in-app banner + email if you've provided one).
  • Other users — same notification mechanism applies.
  • Continuous monitoring — you may also subscribe to this page directly via the bGuru changelog feed (planned for v1.1).

Changelog

Date Change
2026-06-08 v0.1.9. Google LLC (AdMob) removed from the active sub-processors section. AdMob SDK removed from MVP codebase on 2026-06-08 (branch chore/remove-admob-mvp); no ad data is transmitted to AdMob at this version of the Service. AdMob entry moved to the "Inactive / not-yet-used" section with a description of the v1.1+ re-introduction plan. Cloudflare renumbered from #9 to #8.
2026-06-02 v0.1.8. Refined the Google AdMob (#8) under-18 ad-treatment description to use generic public wording rather than naming a specific Google SDK flag. The substantive behaviour is unchanged. Collapsed the public changelog's pre-launch drafting iterations into a single summary entry for clarity.
2026-06-02 v0.1.7. Refined the AdMob category-blocking description to match what's currently in place (Google AdMob console + kill-switch process). Reserved the word "contractually" until a written commercial agreement with Google is in place.
2026-06-02 v0.1.6. Refined the Google AdMob (sub-processor #8) data-category descriptions to focus on what bGuru transmits to AdMob rather than what AdMob internally accesses. "NOT processed: IDFA, GAID..." reframed as "bGuru does not pass to AdMob: IDFA, GAID, bGuru account ID, email address, display name, Picks, group memberships..."
2026-06-02 v0.1.5. Google LLC (AdMob) moved from inactive to active sub-processor (#8) — used for non-personalized contextual advertising at this version of the Service. NPA mode (npa=1 at every request): no IDFA, no GAID, no behavioral profile. Age-restricted ad-treatment settings applied for users registered as 16 or 17. Gambling-adjacent ad categories blocked. Kill-switch via Supabase platform_config. Inactive section updated to clarify NPA AdMob is now active, while personalized/behavioral mode remains inactive.
2026-06-02 v0.1.4. Updated the 'Inactive / not-yet-used' section to identify Google AdMob specifically as the planned future advertising sub-processor (currently not active). Described the data categories that will flow to Google at AdMob activation, the gambling-category block requirement, and the 30-day notice obligation before activation. No change to any active sub-processor.
2026-05-31 → 2026-06-01 Pre-launch drafting iterations (v0.1.0-draft through v0.1.3-draft). Multiple internal drafting iterations during the pre-launch review period. The substantive provisions described above were drafted, refined, and consolidated through this period.