In-app Consent Texts and Flow
The complete Cashletics consent flow, user-facing texts and withdrawal paths.
B BLOCK · FOR USERS
In-app Consent Flow
& Texts Specification
HJ-001-EN
| Data Controller | Mózer Ferenc (sole trader) |
| Registered address | 6044 Kecskemét, Hetény-Belsőnyír 268/2., Hungary |
| Tax number | 41905517-1-23 |
| Privacy contact | privacy@cashleticsapp.com |
| Effective date | 12 October 2026 |
| Prepared by | Dr. Crespo Zsuzsanna | zsuzsanna@crespo.hu |
| Version | v1.10.2 |
| Target audience | Developer (implementation) + GDPR audit |
| Governing language | Hungarian (HJ-001). In case of any discrepancy between the Hungarian and English versions, the Hungarian version shall prevail. |
cashleticsapp.com/legal.php · Public consent-flow notice GDPR-compliant ✔
|
1. Purpose and scope
This document describes the consent and declaration management flow of the Cashletics mobile application as it operates from 12 October 2026. It covers:
the mandatory declarations and optional choices shown at registration and at legal re-acceptance, with the user-interface texts in Hungarian and English;
the feature-bound permission requests (Health Connect step count, banking notification import);
where the leaderboard participation and the prize-draw rules acceptance take place;
the withdrawal paths and their effects, including pending operations;
the actual data structure of the consent log (GDPR Article 7(1));
the Google Play compliance summary.
|
2. Overview — decision points
The app does not request consents in a fixed multi-step registration sequence. At registration, the three mandatory declarations (Terms, Privacy Policy, age) are requested on the registration screen, without optional toggles (Section 4.1). The post-login consent screen, with three mandatory declarations and two optional toggles, is shown when the core declarations are missing or the document versions have changed (Sections 4.2 and 4.5). The optional choices are off by default and can be given or withdrawn at any time under Profile → Settings. Permission for health and banking data processing is requested only when the user switches on the respective feature.
| Decision | Nature | When and where | Document |
|---|---|---|---|
| Acceptance of the Terms | ⛔ Mandatory | At registration on the registration screen; at legal re-acceptance on the consent screen | ASZF-001 |
| Acknowledgement of the Privacy Policy | ⛔ Mandatory — acknowledgement, not consent | At registration; at legal re-acceptance | AT-001 |
| Age declaration (16 years) | ⛔ Mandatory | At registration (with year of birth for e-mail registration, in a separate dialog for a Google account); at legal re-acceptance | KK-001 |
| Usage statistics (Firebase Analytics) | ✔ Optional — off by default | Profile → Settings; at legal re-acceptance on the consent screen | CK-001 |
| Personalized ads (AdMob) | ✔ Optional — off by default; Free plan only (in the current version all ads are non-personalized, Section 4.4) | Profile → Settings; at legal re-acceptance on the consent screen | CK-001 |
| Step count (Health Connect) | ✔ Optional — health data, explicit consent | When the step-count feature is switched on | HE-001 |
| Banking notification import | ✔ Optional | When the automatic notification import is switched on | BH-001 |
| Leaderboard participation | ✔ Optional — STANDALONE consent (GDPR 7(4)) | On first opening the leaderboard, or in Settings | ASZF-001 10, AT-001 4, ROPA-001 09 |
| Acceptance of the prize-draw rules | A condition of the specific reward-programme action — not of registration or the core functions | Before the daily reward wheel, the ad-funded extra spin and joining a campaign, if there is no acceptance of the current version (Section 8.2) | PR-001 |
| Marketing push notifications (FCM) | ⏳ Future — not currently active | Before activation a separate opt-in and a document update are required | AT-001 8 |
|
3. Flow diagram
The diagram below shows the logical sequence of registration, of the post-login consent screen and of the feature-bound permission requests.
|
4. Registration and consent screen — mandatory declarations and optional choices
4.1 Registration
Besides the account details, the e-mail registration screen requests the year of birth (in YYYY format) and three mandatory checkboxes, unchecked by default: acceptance of the Terms, acknowledgement of the Privacy Policy and the declaration of being at least 16 years old. There are no optional toggles on the registration screen.
For registration with a Google account, and before Google sign-in on the login page, a separate dialog requests the year of birth and the 16+ declaration; acceptance of the Terms and acknowledgement of the Privacy Policy are recorded by two checkboxes on the registration screen.
The year of birth is used only for a local pre-check: four digits, and the year of birth may be at most the current year minus 16; the 16+ declaration is required separately as well. The app does not save the year of birth, and it is not included in the consent log: the log records the declaration and the KK-001 version (ageConfirmed, agePolicyVersion).
For a new registration, the two optional choices (usage statistics, personalized ads) start switched off; the user can switch them on under Profile → Settings.
4.2 Consent screen (after login)
The consent screen is shown after login if any of the three core declarations is missing or outdated — including at legal re-acceptance (Section 4.5). The screen is blocking: without the three mandatory declarations the app cannot be used. It does not request the year of birth, only the 16+ declaration.
|
4.3 Interface labels — Hungarian and English
| Hungarian interface | English interface |
|---|---|
| „Elfogadom az ÁSZF-et” | „I accept the Terms” |
| „Tudomásul veszem az Adatkezelési tájékoztatót” | „I acknowledge the Privacy Policy” |
| „Nyilatkozom, hogy elmúltam 16 éves” | „I confirm that I am at least 16 years old” |
| „Használati statisztika (Analytics)” | „Usage statistics (Analytics)” |
| „Személyre szabott reklámok” | „Personalized ads” |
| „Folytatás az engedélyhez” (Health) | „Continue to permission” (Health) |
| „Folytatás a beállításhoz” (banki import) | „Continue to settings” (bank import) |
4.4 Rules of operation
The mandatory checkboxes are unchecked by default; none of them is pre-ticked (GDPR Article 7, Recital 32).
Continue remains disabled until all three mandatory boxes are checked.
Acceptance of the Terms is a contractual declaration. Acknowledgement of the Privacy Policy is not consent: it records that the data subject has received the information required by GDPR Article 13. The two declarations are separate checkboxes and separate log events.
The age threshold (16 years) is supplied by the server-side legal configuration; the declaration records the age limit set out in KK-001. The app does not store the year of birth entered at registration (Section 4.1).
Usage statistics and personalized ads are two separate toggles, off by default. Neither is a condition for continuing; each can be given and withdrawn separately, with its own log event (GDPR Article 7(2)–(3), Recitals 32 and 43).
Personalized ads can only appear in the Free plan; no ads are shown in the PRO plan. In the current version of the app every ad request (banner and rewarded ads) is non-personalized, regardless of the toggle; the toggle records the user's choice. Google's own consent interface (UMP) is described in Section 11.
The choices are recorded in the consent log (Section 10).
4.5 Legal re-acceptance
The published document versions and the age threshold are held in the server-side legal configuration. The app requests the core declarations again when the version of the Terms, the Privacy Policy or the age policy (KK-001) changes; a change of the configuration revision alone does not trigger re-acceptance. In that case the full consent screen is shown, not only the changed document: all three mandatory checkboxes are unchecked and both optional toggles are switched off.
On saving, the toggle positions set on the screen replace the earlier optional choices: a toggle left switched off records the off state even if the user had previously consented. The versions of the health, banking, leaderboard and prize-draw decisions are handled by their own permission requests (Sections 5, 6 and 8).
|
5. Step count — Health Connect permission (feature-bound)
5.1 When it is shown
Not part of registration. It is shown when the user switches on the step-count-based feature. Optional; if declined, the step-count features are unavailable and the rest of the app can be used unchanged.
5.2 Notice and explicit consent
Step count is health data; the legal basis for processing it is explicit consent under GDPR Article 9(2)(a). Before requesting the system permission, the app shows a separate, scrollable notice dialog (Google Play Health Connect requirement). The verbatim text of the notice is set out in Section 4 of HE-001.
The interface element for explicit consent is the positive button of the notice dialog: „Continue to permission” (on the Hungarian interface „Folytatás az engedélyhez”); there is no separate checkbox. The „Not now” button declines: no system permission request is opened. If there is no current Health consent, after the positive button the server first records the consent (health_accept event), and only then does the app request the Android Physical activity and Health Connect permission.
The in-app consent and the Android system permission are two separate states: the system permission can still be refused after the consent has been recorded, and this does not by itself delete the recorded consent; without the system permission no step count can be read.
5.3 System permission
After the notice, Android's own Health Connect permission screen is shown. The app requests only permissions related to step count and aggregated step totals for past periods (READ_STEPS, READ_HEALTH_DATA_HISTORY, ACTIVITY_RECOGNITION); it does not request GPS, routes, heart rate or workout type. If the user refuses the permission in the system screen, the feature is unavailable and the app continues to run.
5.4 iOS — HealthKit
iOS / HealthKit is not currently active; this section must be updated before the iOS version is launched.
5.5 Logging
The decision is recorded in the healthConsent and healthPolicyVersion fields of the consent log (Section 10).
6. Banking notification import (feature-bound)
6.1 When it is shown
Not part of registration. It is shown when the user switches on the „Automatic notification import” toggle under Profile → Settings. Optional; without it, expenses can be recorded manually.
6.2 Notice
Tapping the toggle is not in itself an approval: a separate notice dialog opens, without a separate checkbox. The positive button is „Continue to settings” (on the Hungarian interface „Folytatás a beállításhoz”), the declining button is „Do not allow” („Nem engedélyezem”). If the user declines, Android's notification access setting is not opened. If there is no current consent, after the positive button the server records the consent (bank_notification_accept event) and the import is switched on.
The verbatim text of the notice — which notifications the app processes and which data are stored — is set out in BH-001.
6.3 System permission
If Android notification access has not yet been granted, the app opens its settings page (Settings → Apps → Special app access → Notification access), where the user switches on the system-level permission. A consent recorded in the app does not mean that the system-level permission has also been granted. The notification listener service may start only after the system-level permission has been granted, and the permission status must be checked at every app start.
6.4 Logging
The decision is recorded in the bankNotificationConsent and bankPolicyVersion fields of the consent log (Section 10).
7. Marketing push notifications (FCM) — future
|
8. Leaderboard participation and prize-draw rules
8.1 Leaderboard participation
Showing the username, avatar and score on the public leaderboard is a separate, optional consent that is not part of the mandatory declarations (GDPR Article 7(4)). The decision point is available on first opening the leaderboard and in Settings, and can be withdrawn at any time. On withdrawal, the link between the public leaderboard identifier and the user is deleted. Logging: leaderboardConsent, leaderboardPolicyVersion.
8.2 Prize-draw rules
Acceptance of the prize-draw rules (PR-001) is not a condition of registration or of the app's core functions. The app requests it in a separate acceptance dialog (Accept / Cancel) before the first daily reward-wheel spin, the ad-funded extra spin and joining a campaign, if there is no acceptance of the current version of the rules. The rules can be opened from the dialog and their version is shown. If the user declines, the action does not start.
The acceptance is recorded by the server (raffle_rules_accept event; raffleRulesAccepted, raffleRulesVersion — PR-001); a new version of the rules requires a new acceptance. There is currently no active campaign with physical prizes. Entry tickets can be redeemed from reward points (CP) only from CP verifiably earned free of charge; purchased CP cannot be used for this (PR-001). The free ticket reward of the daily reward wheel is independent of this.
9. Withdrawal and changes
Every optional choice can be withdrawn at any time, as easily as it was given (GDPR Article 7(3)). Withdrawal does not affect the lawfulness of processing before the withdrawal.
| Where | What is withdrawn | Effect |
|---|---|---|
| Profile → Settings → usage statistics (Analytics) toggle | Usage statistics | Analytics data collection stops; separate withdrawal log event. |
| Profile → Settings → personalized Free ads toggle | Personalized ads | The personalisation consent ends and non-personalized ads are shown in the Free plan (in the current version all ads are non-personalized regardless of the toggle); separate withdrawal log event. Google's choices can be changed independently (Section 11). |
| Switching off the automatic notification import toggle | Banking notification import | The import stops. If a server error occurs, the import remains switched off and a retry is offered. Transactions recorded earlier are kept. |
| Withdrawal of Health consent (in the app) | Step-count processing | Synchronisation stops and the app initiates deletion of the step data stored in the app: previously stored step-count data is deleted within 30 days (HE-001). If a network error occurs, the deletion remains pending, processing stays switched off, and no new permission can be started until the deletion is completed. The original data stored in Health Connect are managed by Android; the withdrawal does not delete them. |
| Leaderboard setting | Leaderboard participation | Public display ends; the link to the public identifier is deleted. |
| Restriction of processing screen | The optional consents, each separately | The consents can also be withdrawn individually from this screen, with the effects above. |
| — | Terms, Privacy Policy, age declaration | Cannot be withdrawn separately; the contract ends when the account is deleted (Account → Delete account, DEL-001). |
|
10. Consent log — GDPR Article 7(1)
The controller must be able to demonstrate that the data subject has consented to the processing. Cashletics records this at two levels: the current state of the user's choices, and a separate event record for every change.
10.1 Structure
|
10.2 Event types
Acceptance of the Terms and acknowledgement of the Privacy Policy create separate events: terms_accepted and privacy_acknowledged respectively.
Usage statistics and personalized ads use separate grant and withdrawal event types (for example ad_personalization_revoke).
The feature-bound decisions create their own events: health_accept, bank_notification_accept, raffle_rules_accept (Sections 5, 6 and 8).
The version fields contain the identifier of the document version published at the time of the event (format, for example: ASZF-001-v1.5-2026-07-05).
10.3 Rules
Event records can be written only by a server-side function (recordedBy: server_callable_v1); the timestamp and the version data are set by the server, and no client-side timestamp is used.
The log does not contain IP addresses (the controller's live check of 7 September 2026).
The field name privacyAccepted is retained from the earlier schema; it means acknowledgement of the Privacy Policy, not consent.
On account deletion the original event records and the current state are deleted. Before that, the data needed to demonstrate consent are copied to a separate, reduced evidence archive (legal_consent_evidence): the choices, the document versions, the event type and time, the language and the configuration data, with a keyed (HMAC) pseudonymous identifier instead of the user identifier. This is pseudonymisation, not anonymisation. Name, e-mail address, year of birth and IP address are not included in the archive. If archiving fails, the account deletion does not proceed.
Retention: the evidence archive is kept for at most 5 years after account deletion (ROPA-001 08), to demonstrate consent and to establish, exercise or defend legal claims.
11. Google Play compliance summary
| Google Play requirement | Cashletics implementation | Status |
|---|---|---|
| Prominent disclosure before the Health Connect permission | 5.2 — separate notice dialog and „Continue to permission” button when the feature is switched on | ✔ Implemented |
| Prominent disclosure before notification access | 6.2 — separate notice dialog and „Continue to settings” button when the feature is switched on | ✔ Implemented |
| Explicit, not pre-ticked acceptance | 4.1–4.2 — checkboxes unchecked by default | ✔ Implemented |
| Withdrawal within the app | Section 9 | ✔ Implemented |
| Consent log | Section 10 | ✔ Implemented |
| Google UMP (AdMob) | After the app's own mandatory declarations, the app updates Google's consent status (UMP), shows Google's consent form where required, and only then requests ads. Google's choices and Cashletics' own toggles are separate states and do not overwrite each other. Google settings: Profile → Settings → AdMob privacy settings (where offered by the SDK). | ✔ Implemented |
| Marketing push opt-in (FCM) | Section 7 | ⏳ Future |
| iOS HealthKit NSHealthShareUsageDescription | 5.4 | ⏳ Before iOS launch |
12. Governing Language and Version Control
|
| Version | Date | Changes | Approved by |
| v1.5 | 1 August 2026 | Initial version | Dr. Crespo Zsuzsanna |
| v1.7 | 1 August 2026 | Sybell registered address corrected (DPA-001); DPA-002 clause 3.6 breach notification narrowed + non-excludable liability categories; DPA-003 liability cap (12 months’ fees, min. HUF 500,000); publication date updated | Dr. Crespo Zsuzsanna |
| v1.8 | 1 August 2026 | Legal review approved (DPIA-001, LIA-001, PR-001; DPA-002 clause 3.6 + liability framework; DPA-003 liability cap). Signatures pending. | Dr. Crespo Zsuzsanna |
| v1.9 | 1 August 2026 | PiggyRun mini-game, Piggy Coin, entry ticket types (standard/silver/gold) and random reward packages (loot boxes) regulated; loot box gambling-law classification approved; gamification data elements extended (AT-001, ROPA-001); DPA-001 AdMob/Firebase acceptance dates; DPIA-001 I4 closed. | Dr. Crespo Zsuzsanna |
| v1.9.1 | 1 August 2026 | Sybell (DPA-002): instead of signing the draft agreement, Section 11.1 of Sybell’s GTC (20 July 2026, Art. 28(3) and (9) GDPR) governs the processing; references updated; GTC archived. | Dr. Crespo Zsuzsanna |
| v1.10 | 1 August 2026 | DPA-003 (Balázs Bánki): implementation of the developer comments — narrowing of the developer role and data categories, incident notification under Art. 33(2) GDPR, notification of unlawful instructions under Art. 28(3) GDPR, clarification of third-country transfers, deletion of the minimum liability floor. Addition of administrator feature switches and audit log (ROPA-001 row 17, 12-month retention); clarification of the admin interface access matrix (SZ-001 2.1). | [külön nem került jóváhagyásra — a v1.10.1 váltotta fel] |
| v1.10.1 | 6 August 2026 · suppl. 4 September 2026 and 5 September 2026 | EN terminology alignment (Article, Data Controller); implementation of the legal review decisions; data categories of the four undocumented collections in Section 4 of AT-001. Supplement of 4 September 2026: placeholder instead of a pre-filled signature date in unsigned copies (14 documents); GDPR Article 12(3) “without undue delay” wording implemented (AT-001 HU/EN, EJ-001); in DPIA-001 the retention of health data after withdrawal changed from 7 to 30 days, aligned with HE-001; corrected EU-US Data Privacy Framework reference in the English version of BH-001; in DPA-002 the processing relationship recorded as based on Section 11.1 of the Sybell GTC and the Controller's written instruction instead of a signature; column misalignment corrected in the Article 28 record of DPA-001. In addition: in ROPA-001 and ATJ-001 the number of recorded processing activities corrected to the actual 25 (previously 17 and 16 respectively); in the consent examples of HJ-001 the reference to the never-published AT-001 v1.8.3 corrected to the published v1.8. Implementation of the legal review decisions (4 September 2026): the assistance obligation under GDPR Article 28(3)(f) added as clause 3.7 of DPA-002 and clause 3.10 of DPA-003; in the Play Data Safety table of GPS-001, transfers to Firebase Analytics are no longer declared as sharing — consistent with the document's own conceptual distinction — and health and fitness data are no longer declared as required; Firebase Analytics (L1) and the aggregated analysis built on it (L3) removed from the scope of LIA-001, as their legal basis is consent, with the exclusion table extended accordingly; the incorrect reference to the Hungarian Infotv. removed from the age-limit reasoning of KK-001, together with the identical wording in GPS-001 and XHV-001; the response deadline in EJ-001 aligned with the public undertaking in AT-001 (60 days in total at most); an explanatory note added to the 30-day undertaking under Article 12(3); the Hungarian version of BH-001 supplemented with the description of third-country transfers; AT-001 now states the storage location of Cloud Firestore as the eur3 European multi-region, consistent with ROPA-001; the developer added to the list of processors in AT-001, and the instruction clause of DPA-003 extended with the transfer wording; in six places the term “anonymised” refined to “pseudonymised”. Based on the Controller's statement of 4 September 2026: two-factor authentication for the admin interface is recorded with its actual completion date (1 September 2026) instead of an expired deadline; the emergency shutdown access issued in the developer's name has not yet been activated, therefore the access matrix of SZ-001 and the transitional provision in clause 3.9.8 of DPA-003 record the current and the final state separately, listing the data actually accessible through that role; the revocation of the earlier project-level (Editor) permission is recorded. The data subject branch of INC-001 received the exemption grounds under GDPR Article 34(3), the retention period of ROPA item 06 was aligned with AT-001, an expired external reference was replaced, and header-row repetition was enabled for two multi-page tables in SZ-001. The duplicate logo on the first page — already present in the header — has been removed from the document body (29 documents); the header logo is unchanged and no document text was altered. Supplement of 5 September 2026: the withdrawal table clarified to 30-day deletion for step count; a separate consent checkbox added to the health consent screen; the package-level legal approval recorded in the version table. Supplement of 6 September 2026: based on the Controller's reply of 5 September 2026, the effective date of the package was changed from 1 August 2026 to 1 October 2026 (79 places; the applicability wording of DPA-003, the approval dates in D2-UGY and the dates in the version tables were deliberately left unchanged). Supplement of 6 September 2026 following the external quality review (P2), 37 confirmed findings: leaderboard participation added to the consent table as a separate, standalone and withdrawable consent (GDPR Art. 7(4)); the open status of the consent flow implementation recorded; the marketing push reference corrected to Section 8 of AT-001-EN. Following the P3–P5 external reviews (operability · data-subject perspective · adversarial) of 6 September 2026: the step-count screen now names aggregated totals for earlier periods alongside the daily value (aligned with HE-001). Third supplement of 16 September 2026 (legal reviewer's decisions 7, 8 and 10 of 15 September 2026): HJ-001 (HU/EN) now records the two requirements to be implemented before publication — separating acceptance of the Terms from acknowledgement of the Privacy Policy with two consent events, and separate, individually revocable toggles for analytics and personalised advertising — and the closing condition of CHK-001 L-15 was extended accordingly; the accepted residual risk row of DPIA-001 was supplemented with the relationship between the liability cap in Section 14.1.3 of the Sybell GTC and Article 82 GDPR, and with the bilateral amendment requested. Supplement of 24 September 2026: the effective date of the package changed from 1 October 2026 to 12 OCTOBER 2026. Reason: under Section 14 of ASZF-001 and Section 9 of AT-001, users must be notified of changes at least 15 days before the effective date; publication and notification took place on 27 September 2026 (instead of the previously planned 25 September). The signature date of KK-001 and PR-001 is the day of publication. | Dr. Crespo Zsuzsanna |
| v1.10.2 | 3 October 2026 · suppl. 8 October 2026 | Description of the consent flow aligned with the app's actual operation, based on the controller's technical deviation list of 2 October 2026 and the live check of the consent log on 7 September 2026: acceptance of the Terms, acknowledgement of the Privacy Policy and the age declaration are three separate checkboxes, unchecked by default, on one consent screen; usage statistics and personalized ads are two separate toggles, off by default (the reviewer's decisions 7 and 8 of 15 September 2026 have been implemented; the 'to be implemented before publication' markers have been removed); Health Connect and the banking notification import request a separate notice and permission when the feature is switched on, replacing the former five-step registration sequence; the withdrawal paths, the step-data deletion initiated on Health withdrawal, the restriction screen and legal re-acceptance clarified; the consent log described according to its actual structure (legal_consents, legal_consent_events, without IP addresses); Hungarian–English interface label table; the pre-drafted text of the future FCM screen removed; the v1.5a supplement moved to Section 5.3. The effective date remains 12 October 2026. Supplement of 8 October 2026, before publication (based on the controller's technical answers of 3 October 2026): the registration screen (year of birth, three mandatory checkboxes) distinguished from the post-login consent screen (three checkboxes, two toggles); the trigger of re-acceptance and its effect on optional choices; the actual buttons and sequence of the Health and banking notices; where the prize-draw rules are accepted; the consent-log evidence archive after account deletion; the relationship between Google UMP and the app's own toggles; in the current version all ad requests are non-personalized; the condition for redeeming entry tickets from reward points (CP only verifiably earned free of charge). | Dr. Crespo Zsuzsanna |
Acknowledgement of Receipt
Data Controller .................................................... Mózer Ferenc Date: [upon signature] |
Prepared by .................................................... Dr. Crespo Zsuzsanna Date: [upon signature] |
Next scheduled review: 1 August 2027