Balance — Children's Privacy Notice and Direct Notice to Parents

Effective date: 19 July 2026 Last updated: 19 July 2026

Applies to: every kid whose Android device has been paired with a parent's Balance account, regardless of the country the parent lives in.

This document is the Children's Privacy Notice that accompanies our Privacy Policy and the Direct Notice to Parents required under the U.S. Children's Online Privacy Protection Act ("COPPA"). It also satisfies the parent-notice obligations of the UK Age Appropriate Design Code ("UK Children's Code"), Article 8 of the EU/UK GDPR ("GDPR-K"), Article 16 of Chile's Law 21.719, and Articles 6 and 7 of Colombia's Law 1581 read together with the "superior interest of the minor" doctrine.

It is written for parents and legal guardians. The kid does not see, sign or click "I agree" on this document, on our Privacy Policy, on our Terms of Service, or on anything else inside Balance. The parent — a verified adult — makes every consent decision in Balance on the kid's behalf.

If you only have a moment, read Section 2 (the one-page summary) and Section 11 (how to refuse, review, correct or delete the kid's data).

1. Who is collecting and using your kid's data

EU representative under Article 27 GDPR. For families in the European Union and EEA, our appointed representative is Prighter EU Rep GmbH. Address: Schellinggasse 3, 1010 Vienna, Austria. Intake form: https://app.prighter.com/portal/12736305032.

UK representative under Article 27 UK GDPR. For families in the United Kingdom, our appointed representative is Prighter Ltd (UK). Address: 20 Mortlake High Street, London SW14 8JN, United Kingdom.

For other countries (the full list is in Section 14 of this Notice and in Section 18 of the Privacy Policy), the local regulator and complaint route are published in the country annexes that travel with this Notice.

2. One-page summary for parents

• Balance is a parental-control service. Its only purpose is to help you set healthy device habits for your kid on the Android phone or tablet you pair with your account.
• You — the parent — are in charge of every decision about your kid's data in Balance. Your kid does not sign up, does not see a Privacy Policy at sign-up, and does not click "I agree" anywhere. By creating the kid profile and pairing the kid's device, you exercise Verifiable Parental Consent under COPPA and parental authority under GDPR Article 8,Chile's Law 21.719 and Colombia's Law 1581.
• Balance shows no advertising to your kid, ever. No ad SDKs, no behavioural profiling, no third-party marketing sharing.
• We collect only what we need to run the parental-control service you signed up for. Per-app daily screen-time totals; the list of apps installed on the kid's device; a random device identifier; task and reward data; a push-notification token; and end-to-end-encrypted photo/video proof of completed tasks. The full list is in Section 4.
• We do not collect your kid's location, contacts, SMS, call logs, browsing history, microphone audio outside of explicit proof-video recording, biometric data, health data, or any other special-category data. Section 4.6 has the full negative list.
• Photos and videos the kid uploads as task proof are end-to-end encrypted on the kid's device before any network call. Our servers and our storage provider only ever see encrypted bytes — neither we nor our storage provider can view, recover, or hand over the plaintext.
• You can delete the kid profile and every byte of data tied to it at any time — from inside the app using the "Delete kid" action under the privacy settings, or by writing to .
• You can ask for a copy of the kid's data at any time. Use the in-app data-export action (under the privacy settings) or email . Statutory deadlines apply (Section 11).
• You can refuse any new collection at any time — typically by not enabling a feature (e.g. running Balance without ever requiring photo proof), by removing the kid profile, or by writing to us.
• You can withdraw your consent at any time, without affecting the lawfulness of past processing.

The rest of this Notice is the long-form version of those promises.

3. Why a separate Children's Privacy Notice exists

Balance has two real users in every household: a parent (an adult who creates the account, configures everything, and is the controller-side counterparty in our consent record) and a kid (a minor whose Android device the parent pairs to the account, and whose personal data is the subject of most of our processing). Because the kid is a minor, several jurisdictions require us to publish a notice specifically about how the kid's data is handled, separately from the general Privacy Policy. That is this document. It does not replace the Privacy Policy — it complements it.

This Notice also serves as the Direct Notice to Parents required by 16 CFR § 312.4(c) for U.S. families covered by COPPA. The Privacy Policy at privacy.html serves as the online notice required by 16 CFR § 312.4(d).

4. What information Balance collects about your kid

Because Balance is parent-gated, anything described below is collected only after you, the parent, have created the kid profile and paired the kid's device by completing the in-app pairing flow. Nothing in this list is collected before that step.

We organise this Notice by category — the same categories used in our Privacy Policy. Adding a new technical field to one of our databases does not change what you read here unless that field introduces a new category of personal data (for example, location data), and we have no plans to introduce one.

4.1 Information you give us when you create the kid profile

• The name you choose for the kid (free text, typed by you).
• The kid's age, and, optionally, birthday (YYYY-MM-DD) — you decide whether to provide a birthday.
• An optional avatar (an emoji you pick from the in-app list).
• A randomly-generated kid identifier (kidId) created by our server, so we can route data correctly.

We do not ask you for the kid's real surname, school, address, photo, government identifier, social-network handle, or any other identifier beyond the items above.

4.2 Information from the kid's paired Android device

The kid's device generates and transmits the items listed below. The kid does not type, click, or choose any of these — they are automatic outputs of the parental-control function the parent enabled.

• A device identifier (deviceId) — a random opaque string generated on the device the first time it pairs. It is not the Android Advertising ID, not the IMEI, not the SIM serial, and not the phone number. Its only purpose is to route data correctly between the parent and the kid's specific paired device.
• Per-app daily screen-time totals — for each app the kid uses, the total minutes used that day ("YouTube — 45 minutes today"). Used to enforce the limits the parent has configured. Retained for a maximum of 90 days, then automatically deleted.
• List of apps installed on the kid's device — for each app: package name, display name, icon (compressed thumbnail), install date, and a system-app flag. Used so the parent can pick which apps to limit. Replaced continuously by the kid's device on a daily refresh cycle.
• Task and reward data — the chores you, the parent, assign; the title and description the kid writes when proposing a task; the short note the kid can attach when submitting a task; the kid's marks of completion; your approval or decline decisions; the earned-time ledger that converts approved tasks into screen-time credit.
• A push-notification token (FCM) — an opaque token issued by Google's Firebase Cloud Messaging service so we can deliver operational notifications (task assigned, task approved, limit reached, etc.) to the kid's device.
• Health-check pings — the kid's device periodically tells our backend "I am reachable", so the parent's dashboard can show whether the parental-control service is running. The ping carries the deviceId and a timestamp — nothing else.

We do not record: - what the kid types on the keyboard; - what the kid sees on the screen (screenshots, screen-content, or screen-recording); - which websites the kid visits, or the kid's browser history or search queries; - which YouTube videos the kid watches (we count only that the YouTube app was foreground for N minutes; we do not look at the video URL, title, or recommendation history); - the kid's chats, messages, notifications from other apps, contacts, or address book; - the kid's voice or microphone audio outside of the active proof-video capture screen (see § 4.3); - the kid's location.

4.3 End-to-end-encrypted proof media (only when you configure a task to require photo or video)

You can configure a task so that the kid must submit a photo or video to mark the task done — for example, "show me your homework page". When the kid taps Capture, the kid's device opens the camera. Audio is captured only as the soundtrack of a proof-video (the photo path does not record audio). Nothing is uploaded until the kid hits Submit.

When the kid submits, the following happens on the kid's device, before any byte leaves the phone:

1. The kid's device generates a fresh per-file encryption key (a "file encryption key" or FEK).
2. The kid's device encrypts the photo/video with XChaCha20-Poly1305 (AEAD) using that FEK.
3. The FEK is then wrapped to your parent device's X25519 public key (and to each of your authorised parent devices, if you have more than one).
4. The kid's device requests a short-lived (5-minute) signed upload URL from our backend and uploads the resulting ciphertext directly to our storage provider, Google Cloud Storage, bypassing our application servers entirely.
5. The kid's device retains the proof for the time necessary to confirm the upload completed, then wipes the original plaintext from the device's cache.

The upshot is: our backend never sees the plaintext content of the photo or video, and our storage provider Google Cloud Storage never sees it either. Neither we nor any sub-processor can view, recover, transcribe, hash, or hand over plaintext proof media. Only the parent's authorised device(s) can decrypt the file. See Section 9 of the Privacy Policy for the cryptography in more detail.

There is no gallery picker — only on-device capture, so we know proof media originates on the device.

We do not use the kid's proof media for any purpose other than letting the parent review and approve/decline the linked task. We do not: - show the proof media to anyone outside the family; - analyse its content; - index, search, transcribe, or generate metadata from it; - repurpose it for product improvement of any kind.

Encrypted proof media is automatically deleted 30 days after the linked task closes (approved, declined, revoked, missed, or cancelled). The parent can delete sooner from inside the app.

4.4 Verification and security data about the parent that touches the kid record

A few items are technically attached to the parent (because the parent holds the account) but are listed here for completeness because they are part of the protection layer around the kid's data:

• One-time codes ("OTPs") issued to the parent when adding or reconnecting the kid's device. We store only an irreversible hash (SHA-256 plus a server-only pepper); the plaintext code exists briefly during the email send.
• An optional four-digit family unlock PIN the parent sets on the kid's device, stored only as a one-way SHA-256 hash. The PIN is the local parental override on the kid's device and is not a credential against our servers.

4.5 Operational technical data

When the kid's device contacts our backend we receive standard HTTP request data — method, route, response status, error code, request timing — which is kept in our server logs (retained per Section 8 of the Privacy Policy). For authentication-sensitive requests we also temporarily process the request's IP address to throttle abuse. The kid's device does not transmit a phone number, SIM identifier, Android Advertising ID, or any other persistent device identifier beyond the random deviceId described in § 4.2.

4.6 What we explicitly do not collect from your kid

To remove any ambiguity, Balance does not collect or process any of the following from your kid:

• precise or coarse geolocation;
• contacts, address-book entries, SMS messages, call logs, or phone-number identifiers;
• microphone audio outside of the active proof-video capture screen (audio is recorded only as the soundtrack of a proof-video the kid voluntarily records when a task explicitly requires video);
• browsing history or web-search queries;
• biometric identifiers (fingerprint, face, voice), health data, religion, ethnic origin, sexual orientation, political opinions, trade-union membership, or criminal-record data;
• any persistent advertising identifier (no Android Advertising ID, no Identifier for Advertisers, no SDK-generated ad-tracking id) — Balance shows no advertising;
• any data used for behavioural advertising, profiling, scoring, ranking or any decision affecting the kid that is not the literal application of the limits the parent has configured;
• any public posting, social-network feature, public profile, public username, friend-finding feature, or any feature that would expose the kid's identity to anyone outside the family;
• any data drawn from sources outside the kid's paired Android device (we do not enrich the kid's record from third-party data brokers, school records, social networks, or any external dataset).

5. How we use the kid's data, and the lawful basis for it

We use the categories in Section 4 for one purpose only: to run the parental-control service the parent purchased. That means, concretely:

• enforce the per-app and schedule limits the parent has configured (uses §§ 4.2, 4.5);
• show the parent the kid's screen-time and installed-apps inventory in the parent dashboard (§§ 4.1, 4.2);
• assign tasks to the kid's device, return the kid's submissions to the parent, deliver the parent's approve/decline decision back to the kid, and apply earned-time credit to the limits (§§ 4.1, 4.2, 4.3);
• store the encrypted proof media until the linked task is closed plus the retention window in Section 8 (§ 4.3);
• deliver operational notifications to the kid's device — "task assigned", "limit reached", "earned time added" (§ 4.2);
• protect the kid's data from unauthorised access by throttling abuse, detecting credential-stuffing, and responding to security incidents (§§ 4.4, 4.5);
• comply with our legal obligations — including, where applicable, mandatory child-safety reporting (see Section 12) and lawful requests from public authorities.

Lawful basis (per jurisdiction):

• United States (COPPA): Verifiable Parental Consent — the parent's act of creating the kid profile and pairing the kid's device is logged as a Verifiable Parental Consent event, with timestamp, scope, locale, and the parent's identity. Under 16 CFR § 312.5(c), parent-gated collection that is necessary to maintain or analyse the functioning of a service provided to the parent for the kid is a recognised exception to the prior-consent requirement; we apply the consent model nonetheless, for transparency.
• European Union and EEA (GDPR): Article 6(1)(b) "performance of a contract" (the parental-control service contracted by the parent), with parental authority for the child under Article 8. Per-member-state digital-consent ages (13–16) drive the wording of this Notice — they do not change who consents in Balance, because the parent (a verified adult) is the consenter regardless of the kid's age.
• United Kingdom (UK GDPR + UK Age Appropriate Design Code): Article 6(1)(b) "performance of a contract" + parental authority, plus the Children's-Code design principles which are built into the app: no advertising, no profiling, data minimisation, default-private (the kid's data never leaves the family), and parent-controlled settings.
• Chile (Law 21.719, in force December 2026): parental consent for minors under 14; joint parent-and-minor consent for minors 14 to 18, satisfied in Balance through the parent's setup flow.
• Colombia (Law 1581 of 2012 + 2025 digital-safety framework): parental authorisation grounded in the "superior interest of the minor" doctrine.
• Argentina, Peru, Uruguay (other LatAm countries): parental consent + the local data-protection regime; specific contacts and complaint routes are listed in the country annexes.
• Brazil, India, Indonesia, Pakistan, Bangladesh, Mexico, Japan, Egypt, Türkiye, Tanzania, South Africa, Kenya, South Korea: parental (guardian / competent-person / legal-representative) consent obtained through the parent's setup flow — under Brazil's LGPD art 14 and the ECA Digital (Lei 15.211/2025); India's DPDP Act 2023 §9 read with the DPDP Rules 2025; Indonesia's PDP Law 27/2022 arts 25–26 and GR 17/2025 ("PP Tunas"); South Korea's PIPA art 22-2; Japan's APPI as applied by PPC guidance; Mexico's LFPDPPP (2025); Egypt's PDPL 151/2020; Türkiye's KVKK 6698; South Africa's POPIA §35 (competent-person consent); Kenya's DPA 2019 §33; Tanzania's PDPA 2022; Bangladesh's Personal Data Protection Act 2026; and, in Pakistan, parental authority under general law.

In every one of these countries, the monitoring, screen-time limits, task, and reward features of Balance are performed at the parent's direction, strictly for the safety, well-being, and parental supervision of the kid, and are never used for advertising, profiling, or any other commercial purpose. This is the "safety of the child" purpose recognised by Part B of the Fourth Schedule to India's DPDP Rules 2025, the parental-supervision-tool framing of Indonesia's GR 17/2025 ("PP Tunas") and Brazil's ECA Digital (Lei 15.211/2025), the competent-person consent model of South Africa's POPIA §35, and the legal-representative consent model of South Korea's PIPA art 22-2.

We do not rely on the kid's consent for any of the processing in Section 5. The kid is a data subject under Balance, not a consenter.

6. We do not show advertising to the kid, and we do not profile the kid

Restated here because it is the single most important promise of this Notice:

• No advertising. Balance shows no ads, in-app or otherwise. No ad SDK is embedded in the app. We do not generate, request, or read the Android Advertising ID. We do not sell, lease, license, or otherwise share the kid's personal data with any advertising network, data broker, audience-builder, attribution platform, or marketing partner.
• No profiling. We do not build a profile of the kid for any purpose other than the literal application of the limits the parent has configured (which is not "profiling" within GDPR Article 22 or the UK Children's Code, because it produces no decision about the kid — it simply applies your settings).
• No nudge or engagement-maximising design directed at the kid. Balance is a parental-control service; we are not optimising for the kid's screen-time. We do not deploy autoplay, infinite scroll, streaks-as-pressure, FOMO mechanics, or any of the dark-pattern features the UK Children's Code calls out.
• No public profile, no friend graph, no chat, no public UGC, no social discovery. The kid does not have a Balance profile that is visible to anyone outside the family. The kid's screen-time data, task data, and proof media are visible only to the parent who paired the device.

In several countries, this is also a statutory command we embrace: Brazil's ECA Digital (Lei 15.211/2025), Indonesia's GR 17/2025 ("PP Tunas") ban on the commercial profiling of children, and India's DPDP Act 2023 §9(3) prohibition on tracking, behavioural monitoring, and targeted advertising directed at children all prohibit what Balance already refuses to do.

7. Disclosures of the kid's data — sub-processors

We use a small number of service providers to run Balance. Each is bound by a written data-processing agreement that requires them to follow our instructions, keep your kid's data secure, and not use it for their own purposes. Below is the list specifically as it touches the kid's data:

We do not use Resend (our email sub-processor) to send anything to the kid — only to the parent.

We do not embed any third-party advertising SDK, attribution SDK, behavioural-profiling SDK, or social-login SDK directed at the kid in the Balance app. The kid build embeds only one Google diagnostic SDK — Firebase Crashlytics — for crash-diagnostics only. The kid's device makes network calls to: (a) our backend; (b) Google Cloud Storage for the encrypted-media upload; (c) Google Firebase Cloud Messaging for push delivery; and (d) Google Firebase Crashlytics on app crash. There is no analytics SDK on the kid build. Firebase Analytics is present on the parent build only — never on the kid build — and even on the parent build it is off by default and collected only with the parent's opt-in consent (see § 3.5 and § 6 of the Privacy Policy). Analytics plays no part in how we handle the kid's data.

We do not sell, rent, or trade the kid's personal data. We do not "share" the kid's personal data for cross-context behavioural advertising as defined in any applicable U.S. state privacy law.

For families in the EU/EEA and UK, the international-transfer mechanisms that protect the cross-border movement of the kid's data are described in Section 7 of the Privacy Policy.

8. How long we keep the kid's data — retention schedule

This is the COPPA-mandated written retention schedule applied to the kid's data.

We do not keep the kid's data after the kid's record is deleted, except (a) in the operational-backup window noted above, which then expires automatically, and (b) where a law in the parent's country requires us to retain a specific record (in which case we retain only what the law requires, for only as long as it requires, and in isolated archival storage).

9. Security measures protecting the kid's data

We use, at minimum, the following technical safeguards for the kid's data. The Privacy Policy's Section 9 contains the canonical description; this Notice repeats the items most relevant to a parent.

• TLS 1.2+ for everything in transit between the kid's device and our backend, between the kid's device and Google Cloud Storage, and between the backend and our other sub-processors.
• End-to-end encryption of proof media on the kid's device with XChaCha20-Poly1305 (AEAD), with the per-file key wrapped to each authorised parent device's X25519 public key. Our servers never see the unwrapped key.
• Argon2id key-derivation for the parent's media-key blob, with parameters tuned to make brute-force expensive.
• Bcrypt password hashing for the parent (never relevant to the kid's account because the kid has no password).
• OTP hashing with SHA-256 plus a server-only pepper.
• Short-lived (5-minute) signed URLs for the kid device's direct upload to Google Cloud Storage and for the parent device's direct download — the upload bypasses our backend.
• Strict logging discipline — keys, passwords, one-time codes, and plaintext media bytes are forbidden in our logs by code-review rule.
• Pinned sub-processor list — the kid's device makes no network call to any third party outside the table in Section 7.

If a personal-data breach affects the kid's data, we will notify the competent supervisory authority and, where required by law, you, in line with GDPR Articles 33 and 34, the U.S. state breach-notification regimes that apply to your state, and the equivalent rules elsewhere.

10. Your rights as parent

As the parent, you can exercise the following rights at any time, on your behalf and on your kid's behalf:

• Review — see every category of data we hold about your kid. The family screens in the app are the live view; the data-export feature delivers a downloadable JSON archive (Section 11).
• Correct — change the kid's name, age, birthday, or avatar in the kid-profile screen.
• Delete — delete the kid profile and every byte of data we hold about that kid. Use the in-app "Delete kid" action (under the privacy settings), or write to . Deletion is final and cascades across every collection we hold and every encrypted media object we store.
• Withdraw consent to ongoing collection — by removing the kid profile, which immediately stops further collection from the kid's device and triggers the deletion cascade once the 1-hour in-app cool-off elapses (or under the statutory deadlines in Section 11 for email/manual requests).
• Refuse any new collection — by simply not enabling a new feature (for example, you can run Balance indefinitely without ever requiring photo proof).
• Restrict processing — ask us to pause processing while a dispute is resolved.
• Portability — receive a copy of the data you provided to us in a structured, machine-readable format.
• Object — object to processing carried out on the legitimate-interest basis (limited to security and abuse-prevention; the core parental-control function rests on contract).
• Lodge a complaint with the regulator in your country — Section 14 of this Notice and Section 18 of the Privacy Policy list the regulator and complaint route for each country.

These rights are concurrent: exercising one (for example, deletion) does not waive the others.

Country-specific mechanics: in Mexico these rights are exercised as ARCO requests under the LFPDPPP (2025); in India through the grievance channel of the DPDP Act 2023, within the statutory response timelines of the DPDP Rules 2025; in South Korea the legal representative (the parent) exercises the under-14 kid's rights under PIPA art 22-2. The country annex for your country names the route.

11. How to refuse, review, correct or delete the kid's data — concrete steps

We have tried to make every action you might want to take possible from inside the app, in a small number of taps.

Inside the app — fastest route:

1. Open Balance on the parent's device.
2. Sign in.
3. Open the in-app privacy settings.
4. Choose one of: - Export data — generates a downloadable JSON archive of your family record (see Section 12 of the Privacy Policy for the format). - Delete kid — pick the kid; you will be asked to confirm; after confirmation we immediately stop collection from that kid's device, set the kid record to pending_deletion, and run the deletion cascade once the 1-hour in-app cool-off elapses (email/manual requests are honoured under the statutory deadlines in Section 11). The encrypted proof media for that kid is deleted in the same cascade. - Delete account — deletes the parent account and every kid profile attached to it (full cascade as described in the Privacy Policy).

By email — for jurisdictions where you prefer an evidentiary trail, or if the in-app flow is unavailable:

Write to from the email address you used to register the account, and include: - the kid's first name and (if you set one) avatar — enough for us to find the right record; - the action you want us to take (review / correct / delete / restrict / port); - where you live (so we apply the correct statutory deadline).

We will reply within the following maximum deadlines: - Under GDPR / UK GDPR: 30 calendar days from the date we receive the request (extendable to 90 days for complex requests, with notice). - Under most U.S. state privacy laws (CCPA/CPRA, VCDPA, CPA, CTDPA, UCPA, TDPSA, and others): 45 calendar days, extendable by 45 more with notice. - Under COPPA (FTC's Direct-Notice rule): without unreasonable delay, in practice within 10 business days for verified parental deletion requests.

We may ask you to confirm the email address on file — by entering an OTP we send to that address — before we act on a deletion or access request, to make sure we are talking to the actual account holder and not someone impersonating you.

Refusing further collection without deleting anything:

You can refuse a future category of collection by simply not enabling the feature that produces it. For example: do not enable photo-proof on any task, and Balance will collect no media from the kid's device. Disable a task type, and Balance will stop collecting the data that task type produces.

12. Child safety, reporting, and our cooperation with authorities

Balance is a parental-control app, not a social network. We do not host public profiles, public posts, friend lists, chat, comments, or any other surface where the kid could be contacted by a stranger or could publish content publicly. Proof media is private to the family and is end-to-end encrypted (Section 4.3).

If you ever want to raise a child-safety concern — either about Balance itself, or about something that has happened on the kid's device and relates to Balance — please write to (named child-safety contact: ). We treat child-safety reports as our highest-priority queue and aim to acknowledge within one business day.

The Balance app also offers an in-app reporting button on every proof-media screen, so a parent or a paired kid device can submit a concern directly from the place it arises. (This feature lands in app version Phase 3.4 — for the latest status, see the in-app About screen.)

Where applicable law requires us to report Child Sexual Abuse Material (CSAM) or other forms of child sexual exploitation and abuse (CSAE) to a competent national authority (for example, the U.S. National Center for Missing & Exploited Children, NCMEC, under 18 U.S.C. § 2258A; or to your national hotline within the EU under the proposed CSAE Regulation), we will report and cooperate as the law requires. Because proof media is end-to-end encrypted, the only data we are in a position to share with such authorities is the metadata around an encrypted object (size, timing, the parent's account); we cannot share plaintext content we cannot read.

13. Changes to this Notice

We may update this Notice from time to time. If we make a material change to the kid-data section — for example, if a new sub-processor would be able to see kid data, or if a retention period for a kid-data category gets longer — we will:

• update the "Last updated" date at the top of this Notice;
• notify the parent in the app at next launch and by email at the address on file;
• obtain renewed Verifiable Parental Consent before any change that materially expands collection, sharing, or retention of kid data takes effect for the kid's existing record.

We will not retroactively reduce protections that already apply to kid data we hold without an opt-in from the parent first.

14. Country annexes

This Notice is the global, universal version. For each country we publish a short annex naming the country's regulator, the parental-complaint route, the country-specific age threshold under that country's law, and any additional country-specific rights you have. The country-annex set is:

• United States (federal COPPA + applicable state laws).
• United Kingdom (UK GDPR + UK Children's Code).
• All 27 EU member states + Iceland, Liechtenstein, Norway (EU/EEA).
• Argentina, Chile, Colombia, Peru, Uruguay.
• Canada, Australia, New Zealand, Singapore, Philippines, Israel, Hong Kong (SAR), Malaysia, Thailand, Taiwan.
• Andorra, Monaco, San Marino.
• Brazil, India, Indonesia, Pakistan, Bangladesh, Mexico, Japan, Egypt, Türkiye, Tanzania, South Africa, Kenya, South Korea.

For the countries in the last line above, the statutory consent-age thresholds are summarised in the consent-age table in Section 5.6 of the Privacy Policy. In Balance the parent — a verified adult — consents on the kid's behalf regardless of the threshold, so every threshold is satisfied by design.

Inherited territories (Puerto Rico, Guam, US Virgin Islands; Bermuda, Cayman Islands, Channel Islands, Isle of Man, Gibraltar; the French overseas departments and territories; Greenland; Aruba and the BES; Åland) follow the privacy regime of their parent country, and the parent-country annex applies.

The annex set is published alongside this Notice at children.html and is incorporated by reference.

15. Quick-reference contacts

• Privacy / DSAR / data export / deletion: ()
• Child safety and security incidents: ()
• General help:
• EU representative: Prighter EU Rep GmbH, Schellinggasse 3, 1010 Vienna, Austria · intake form: https://app.prighter.com/portal/12736305032
• UK representative: Prighter Ltd (UK), 20 Mortlake High Street, London SW14 8JN, United Kingdom
• Postal address: BabaYaga Program, TOO, ul. Ongarsynova 10, kv. 175, Esil district, Astana 010000, Kazakhstan
• Telephone:
• Companion documents: Privacy Policy at privacy.html · Terms of Service at terms.html · Child-Safety Standards at child-safety.html · Account-Deletion page at delete-account.html.

End of Children's Privacy Notice and Direct Notice to Parents.