Chapter 1
Principal Providers & App Data Flows
This register identifies principal providers that are confirmed or expected to support Mosey and separates the static public website from the mobile app. A provider’s legal role can differ by processing activity: some act as processors/service providers on Mosey’s instructions, while others may act as independent controllers for their own services. Production integrations and contracts determine the final role.
1. Purpose and legal roles
Moseyaround Limited is responsible for deciding why and how core Mosey member information is processed. This register provides additional transparency about principal external organisations involved in delivering the service.
The labels processor, service provider, independent controller and similar terms depend on the actual processing activity and contract. Mosey does not describe every provider as a processor merely because its technology appears in the app.
Before production launch and after material integration changes, Mosey should document the role, purpose, information flow, contract/DPA and international-transfer position for each provider.
Back to top ↑2. Static public website – Cloudflare
Provider: Cloudflare.
Purpose: static website hosting/delivery, DNS/content delivery, performance and security functions used for the public Mosey website.
Typical technical information: IP address, request/network information, browser/user-agent and security information necessarily generated when delivering or protecting the site.
Mosey does not currently use the static website for behavioural advertising, advertising cookies, analytics cookies or tracking pixels. Cloudflare infrastructure/security processing is not represented as Mosey behavioural advertising tracking.
Back to top ↑3. Google / Firebase
Provider: Google, including Firebase and Google Cloud services used by the Mosey app.
Confirmed/planned Mosey functions include authentication, Cloud Firestore, Cloud Functions, Cloud Storage where used, Firebase Cloud Messaging, App Check, and crash/diagnostic services where enabled in the production build.
Depending on the feature, information may include account/user identifiers, authentication information, profile data, Acorn/reward records, app activity records, device/security information, push-notification tokens and diagnostic information.
Any analytics, advertising or additional Google SDK must be separately reflected in the production App Technology Schedule rather than assumed to be covered merely because Firebase is used.
Back to top ↑4. Apple and Google platform services
Providers: Apple and Google.
Purpose may include Apple Sign in/Google Sign-In, app distribution/platform services and user-authorised activity integrations such as Apple Health/HealthKit or Android Health Connect.
Mosey only requests activity permissions needed for the disclosed feature. HealthKit/Health Connect activity data must not be provided to advertising networks, advertising SDKs or offerwall providers for advertising, targeting or profiling.
Apple and Google may process information independently under their own platform/account terms for services they provide directly to the user. The exact legal role depends on the relevant service.
Back to top ↑5. ayeT Studios – rewarded advertising and offerwalls
Provider: ayeT Studios.
Purpose: app offerwall, rewarded-advertising, offer attribution, completion/eligibility verification and related anti-fraud functions where the integration is enabled.
Depending on the production integration, information may include app/account pseudonymous identifiers, device/advertising identifiers where permitted, IP/network information, offer interactions, attribution/completion information and fraud/security signals.
Mosey must configure the integration so Apple Health/HealthKit and Health Connect activity data is not supplied for advertising, targeting or profiling. Gambling/betting and high-risk financial-trading offer categories should be blocked for UK users at provider/account level where the provider supports category controls.
Advertising/offerwall storage or device-access technologies are not treated as essential merely because the SDK is installed; applicable consent/opt-out requirements must be implemented in the app.
Back to top ↑5A. GemiAd LLC – GemiWall offerwall
Provider: GemiAd LLC (“GemiAd”).
Purpose: optional GemiWall offerwall opportunities, offer delivery, attribution, completion/eligibility verification, reward administration and related fraud-prevention functions where enabled in the Mosey app.
Depending on the integration and user choices, GemiAd may process information such as identifiers, device or advertising identifiers where permitted, IP/network information, offer interactions, timestamps, attribution/completion information and technical or fraud-prevention signals as described in GemiAd’s privacy information.
Mosey will not provide Apple Health/HealthKit or Health Connect data to GemiAd for advertising, offerwall targeting or profiling. Non-essential storage or device-access technologies used for the offerwall remain subject to applicable consent and opt-out requirements.
A GemiAd rejection or reversal may affect Acorns linked to the relevant offer transaction, but does not by itself determine permanent Mosey account termination or forfeiture of unrelated legitimately earned redeemable value.
Back to top ↑5B. Prodege, LLC – optional surveys and rewarded opportunities
Provider: Prodege, LLC (“Prodege”).
Status: intended/optional integration. This entry applies when Prodege functionality is enabled in the production Mosey app; the production SDK/provider register must be checked before launch and updated if the final integration differs.
Purpose: optional surveys or rewarded opportunities, participation and completion verification, respondent/data-quality controls, fraud prevention and support for disputed transactions.
Depending on the final integration and user choices, Prodege may process identifiers and technical, network, interaction, survey, completion, quality and fraud-prevention information described in its own privacy information. Mosey will not provide Apple Health/HealthKit or Health Connect data to Prodege for advertising, survey targeting or fraud profiling.
Prodege uses multi-layered respondent verification and fraud/data-quality controls. A Prodege rejection or reversal may affect the Acorns attached to the relevant transaction, but does not by itself determine permanent Mosey account termination or forfeiture of unrelated legitimately earned redeemable value.
Back to top ↑6. Lifestyle Gift Cards / Motivates Inc. Ltd – gift-card fulfilment
Provider: Lifestyle Gift Cards, owned and operated by Motivates Inc. Ltd (company number 11319734).
Purpose: supply and/or fulfil gift-card rewards selected by eligible members.
Only information necessary for fulfilment should be disclosed. Depending on the provider/model, this may include a redemption reference, reward type/value and recipient delivery information such as an email address.
Lifestyle Gift Cards / Motivates Inc. Ltd is Mosey’s UK gift-card fulfilment provider. Where necessary to fulfil a selected reward, Mosey may provide the minimum information required for fulfilment, such as reward value/type, redemption reference and recipient delivery details. Lifestyle/Motivates may also process information under its own terms and privacy information when a member registers, exchanges or uses a Lifestyle Gift Card.
Back to top ↑7. Transactional email / communications provider
Provider: to be confirmed before production transactional email is enabled.
Purpose may include account/service messages, reward-delivery communications, security notices, complaint/privacy correspondence or other transactional messages.
Typical information may include email address, display name where used, message content/template variables, delivery status and security/delivery logs.
Marketing communications must not be assumed to have the same legal basis or consent position as transactional/service communications.
Back to top ↑8. Additional advertising or analytics providers
Any additional production advertising, attribution or analytics provider — including Google advertising services if enabled — must be named in this register and in the App Technology Schedule before or when it is activated.
The entry must identify the actual purpose and information flow and whether the provider acts on Mosey’s instructions or for its own purposes. The fact that a provider supplies an SDK does not determine its legal role.
No such provider may receive HealthKit/Health Connect activity data for advertising, targeting or profiling.
Back to top ↑9. Payment providers
Mosey is currently designed as a free-to-use rewards app and does not need a payment provider merely for members to earn or redeem Acorns.
If an optional paid feature or subscription is introduced, the applicable app-store/payment provider and its data flow will be added to this register before or when that feature launches.
Back to top ↑10. Processor due diligence and contracts
Where an organisation processes personal information on Mosey’s behalf as a processor, Mosey will use appropriate contractual arrangements and assess whether the provider offers sufficient guarantees for security and data-protection compliance.
Where a provider determines its own purposes for particular processing, Mosey will assess the resulting controller-to-controller disclosure rather than incorrectly treating that processing as processor-only.
Back to top ↑11. International transfers
Some providers or their subprocessors may process information outside the United Kingdom or the member’s home state/country. Mosey will identify the relevant transfer mechanism and contractual safeguards where required by applicable law.
The production provider register should record relevant hosting/processing regions where they are configurable or materially relevant, including the selected Firebase/Google Cloud region.
Back to top ↑12. Production App Technology Schedule
This public register is complemented by the App Technology Schedule described in the Cookie & App Technologies Policy.
Before each material production release, Mosey should verify the SDKs actually bundled in the app and record provider, SDK/technology, purpose, information accessed/stored, essential/optional status, consent/choice basis where applicable, persistence/retention and relevant privacy documentation.
Unused, removed or merely planned SDKs should not be presented as active data recipients.
Back to top ↑13. Changes and member transparency
This register will be updated when a principal provider is added, removed or materially changes its role or data flow. Material privacy changes will also be reflected in the Privacy Policy and app notices where appropriate.
Mosey will review this register at least annually and as part of material provider/integration changes.
Back to top ↑14. Contact
[email protected] – privacy and provider/data-flow enquiries
[email protected] – security enquiries
[email protected] – legal enquiries
Back to top ↑19. Named Launch Providers and Status
- Google Firebase / Google Cloud — authentication, database, cloud functions, messaging, storage and related app infrastructure
- Cloudflare — DNS, CDN, static website delivery, security and website analytics where enabled
- Google Sign-In and Sign in with Apple — optional account authentication
- Google AdMob — mobile advertising, measurement and fraud prevention where advertising is enabled and permitted
- ayeT Studios — optional offerwall opportunities, attribution, completion verification and offerwall fraud prevention
- GemiAd LLC / GemiWall — optional offerwall opportunities, attribution, completion verification, reward administration and offerwall fraud prevention
- Lifestyle Gift Cards / Motivates Inc. Ltd (company number 11319734) — UK gift-card reward fulfilment and recipient redemption/exchange services
Lifestyle Gift Cards / Motivates Inc. Ltd is identified as Mosey’s UK gift-card fulfilment provider. The transactional-email provider must still be named before that live processing begins. Final production data flows must be checked against the executed provider agreements.
International transfer mechanisms depend on the provider, contracting entity and hosting configuration. Mosey will record the applicable transfer safeguard (for example an adequacy regulation, IDTA or UK Addendum) in its internal vendor register before production processing where required.
Back to top ↑Document record
Version history
| Chapter title | Effective date | Status |
|---|---|---|
| Principal Providers & App Data Flows | 25 August 2026 | Approved master wording |
Contact [email protected] or [email protected].
