Skip to content

With your consent we use cookies to measure advertising on Facebook and Instagram. More in the Privacy Policy.

Kimda

Main navigation

  • Home
  • Support
  • Privacy

Language

  • Čeština
  • Slovenčina
  • Русский
  • English
  • Deutsch
  • Français
  • Español
  • Italiano
  • Polski
  • Português
  • Nederlands
  • Українська
  • Türkçe
  • العربية
  • 中文
  • 日本語
  • 한국어
  • हिन्दी
  • Tiếng Việt
  • ไทย
  • Ελληνικά
  • Română
  • Magyar
  • Svenska
  • Norsk
  • Dansk
  • Suomi
  • Hrvatski
  • Български
  • Српски
  • עברית
  • Bahasa Indonesia

Theme

Try it

Kimda

Privacy Policy

Last updated: 27 October 2026

This is a machine translation. The Czech version is legally binding.

The Czech version of this policy is binding. Translations into other languages are for information only; in the event of any conflict, the Czech version prevails.

This document describes what data the Kimda app ("the app", "we") and the kimda.app website process, why and on what legal basis, who we share it with, how long we keep it and what rights you and your children have. The app is designed to be used by the whole family, including children — which is why we take particular care in protecting data.

1. Who is the data controller

The data controller is Mgr. Ivo Slávka, who operates the Kimda app as a sole proprietor registered in the Trade Licensing Register maintained by the Prague 8 Municipal District Office, Company ID 30070929, with registered office at Bergerova 1115/2, 182 00 Praha 8 – Kobylisy, Czech Republic. Contact email for privacy questions and for exercising your rights: privacy@kimda.app.

2. What data we process and why

  • Account details: first name, last name, phone number, role (parent/child), selected language and theme, optional profile photo, the version of this policy and the time you agreed to it, for a parent the time they confirmed their legal age, and for a child the time, policy version and the parent who gave consent on behalf of the child (section 5). Your name and profile photo are visible to other members of your family in the app (a parent sees all members, a child sees their parents and siblings).
  • We use the phone number for identity verification (SMS code) and sign-in and its irreversible fingerprint also to protect the Premium trial period (section 6), after a number change to verify a request to return a hijacked account (security records below) and after restoring the database from a backup to hold a sign-in to a number that previously left the account (journal of phone changes below) - the app does not otherwise message anyone at the number or share it with third parties other than the SMS verification provider (Twilio, see section 4).
  • Family details: family name, who belongs to it, each member's role and settings (pocket money split percentages, currency, language and family time zone) and the history of changes to financial rules (who changed e.g. the interest rate, split percentages, currency or time zone, when, and from what value to what).
  • Join requests: first name, last name, role and phone number of the person who wants to join the family, and the time of the request - so the parent can see who they are approving.
  • Parental consent requests: type of request (removal of a parent or deletion of the entire family), who submitted it, whom it concerns and who approved, rejected or cancelled it (internal identifiers), timestamps (submission, deadline, reminder, resolution) and outcome (approved, rejected, cancelled, executed after expiry or invalidated); we do not store names, phone numbers or free text. Requests are visible to the parents of the family in the app.
  • Task details: task name, points, when it was completed/approved/rejected, and photos if the task requires a photo, including the technical fingerprint of the photo (see section 3).
  • Plans, routines and reminders: who a task is assigned to, the scheduled day and time, completion status, delay, rotation order and whether a reminder was sent.
  • Rewards and goals: the family rewards catalogue, reward requests, savings goals and the amounts a child has moved towards a goal. From this data, the parent overview derives aggregate completion, timeliness and fairness of assignment; it does not create a public ranking of children.
  • In-app financial data: points, virtual pocket money and how it is split, payout requests, loans and interest within the family - these are internal app records, not real banking or payment details. The app has no access to any bank account or payment card. A child's monthly summary (number of approved tasks, points, and with Premium also the amount for the current month; not box balances) is also visible to other children in the same family, unless a parent turns this off in the family settings.
  • Records of direct payouts and manual repayments: when a parent in the app pays out part of a child's balance directly (without a request from the child) or manually records a repayment of their loan, the server stores a separate record of each such operation that does not change further. It contains internal identifiers of the family, the child and the parent who performed the operation, the type of operation (direct payout, manual repayment), the amount, for a payout the box from which it was paid out, and a breakdown of the amount (for a payout into the part from own deposits and the part from credited interest, for a repayment into principal and interest), the time of the operation and a random request identifier. The record serves to demonstrate what the parent recorded in the app and when, and so that any family dispute can be assessed based on the record, not just by the resulting balance. This is internal app recordkeeping - the app itself does not transfer any money. The records are part of the data export (section 7) and are kept according to section 6.
  • Subscriptions: the family's subscription status (trial period, Premium, its validity and renewal) and any free access from a promo code; the server stores promo codes themselves only as an HMAC fingerprint and records code management (who, when, what action). We do not see payment details - the payment is processed by Apple or Google. The proof of consent to the immediate start of Premium, which we keep as proof of this consent, is described in section 6.
  • Sign-in and security: sign-in sessions of individual devices (when created, when last used and until when valid). The parent sees an overview of their signed-in devices in the Profile (only the time of sign-in and last use, without IP address and device name) and can sign them out individually. The server stores refresh tokens only as SHA-256 fingerprints, including fingerprints of already replaced tokens, to detect abuse of a stolen token. When requesting an SMS code, it stores a keyed fingerprint (HMAC-SHA-256) of the phone number and a SHA-256 fingerprint of the one-time challenge along with the number of attempts, for a number change and for confirmation of the deletion of the family also its purpose and the internal account identifier. It calculates rate limits, including the daily limit of sent SMS, based on the keyed fingerprint (HMAC-SHA-256) of the IP address or its network (IPv4 /24, IPv6 /56), phone number, a pair of phone number and network, or account, or based on the country or phone number prefix. The server derives the key to these fingerprints from a secret key stored outside the database, so the fingerprint cannot be converted back into a phone number or an IP address without it. Security records of important events (e.g. sign-in, join request, approval, rejection or removal of a member, new invite code, device sign-out, change of phone number, policy confirmation, parent's consent on behalf of a child or suspected token abuse) contain the event type, time and internal identifiers; for the removal of a member also their role (parent/child), for policy confirmation and parent's consent the policy version, and for the deletion of a child's account that had a debt, balance or pending requests, also the currency, written-off amounts and the number of pending requests. The record of a phone number change additionally contains an irreversible fingerprint of the original number (HMAC with a secret key) so that support can verify that a request to return a hijacked account is submitted by the true owner of the original number. Names, phone numbers and IP addresses are not in them. In addition, phone number changes and the removal or restoration of a family member are recorded in a separate journal described in the “Journal of phone and member status changes” bullet below.
  • Security notifications: when a parent signs in with an SMS code, other parents in the family receive a generic notification without a name and phone number; upon every sign-in with an SMS code (of a parent and a child), existing signed-in devices of the same account also receive a generic notification about the new sign-in. When changing the phone number (the new number is verified with an SMS code), the server signs out other signed-in devices of the account and existing devices of the account as well as parents in the family receive a generic notification; the original number is no longer retained – only its irreversible fingerprint remains in the security record of the change (30 days, see Section 6), irreversible fingerprints of the original and new numbers in the journal of phone changes (60 days, see below and Section 6) and for a parent who was a member of a family during its trial period, also a fingerprint under Section 6. When support restores a number at the account owner's request, it first verifies their identity: with an SMS code sent to the original number, whose fingerprint must match the fingerprint in the record of the number change. If such verification is not possible (the record of the change no longer exists or the owner does not have the original number), it verifies it with a confirmation from another parent in the family (verified by an SMS code sent to this parent's number) and with answers to questions asked by support; in that case, it first sends a notification to the devices of the account and to the parents in the family and returns the number no earlier than in 72 hours, unless someone objects; you will see this notification after signing in and directly in the app throughout the period. Without such verification, it will not restore the number and will not cancel any request – it can only sign out all devices of the account. If support has already returned the same account once in the last 30 days, it considers the next request a dispute and will not restore the number without further investigation. After the restoration, the server signs the account out on all devices, parents in the family receive a generic notification and the intervention is recorded (who performed it, when, which account it concerns and a link to your request – without the phone number). Parents also receive a generic notification upon the deletion of a child's account, upon the removal of another parent (including the removed parent) and upon suspected abuse of a sign-in token; in that case, the server signs the account out on all devices and cancels its registrations for notifications. The server first saves security notifications (e.g. about a new sign-in or device, change of phone number, change of financial rules, removal of a member, deletion of a child's account or suspected token abuse) into a queue (the type of notification, recipient - push token of the device or internal identifier of the family or account and language - and generic technical event type) and only from there it delivers them; it sends a notification upon returning a hijacked account by support (above) directly. If the delivery of the notification to parents or devices of a family member's account fails even after repeated attempts, the server stores only the internal family identifier, type of notification and time (without a push token and without a name) so that after the next sign-in in the app, the parent can see what notification it was and can confirm it; if the recipient has no device to which a notification can be sent, such a record is not created. The retention periods are set out in section 6.
  • Journal of phone and member status changes: in addition to the security records above, the server keeps a separate journal record for each change of an account's phone number (whether you make it yourself in the Profile or support makes it at your request) and for each removal or restoration of a family member. The record contains a random record identifier, internal account and family identifiers, the type of event (number change, number restoration by support, member removal, member restoration), the time of the event and - only for a number change - irreversible fingerprints of both the original and new numbers (HMAC-SHA-256 with a secret key that is stored outside the database). There are no fingerprints for member removal and restoration. Phone numbers, names and IP addresses are not in the journal. The fingerprint cannot be converted back to a phone number without the secret key, but because it is linked to the internal account identifier, it is pseudonymous data, not anonymous data. The journal serves only to protect against the consequences of restoring the database from a backup: to prevent a number that in the meantime left the account (and which someone else may have taken over) from returning to the account, and to reapply the removal of a family member that the backup does not contain. Therefore, when signing in with an SMS code and when verifying a phone number, the server compares the fingerprint of the entered number with the latest journal record; if it does not match, it holds the sign-in and refers to support. The record is stored in the database and usually within a few minutes also in a copy in separate non-public Cloudflare R2 storage (section 4) so that it survives a database loss between backups. Retention periods are specified in section 6.
  • Technical data: push token and a random device identifier that the app creates for delivering notifications (not a hardware identifier), the time of the last device registration, the sign-in to which the registration belongs, and the SHA-256 fingerprint of a random installation secret, by which the device proves that the push token belongs to it. After the registration is released (sign-out, member removal, security block or automatic cleanup), the server remembers two time-limited records so that someone else's account cannot take over the device's notifications: (a) a record of the released push token - SHA-256 fingerprints of the push token and installation secret, the internal family identifier and the time of release (thus the released token cannot be taken over by an account from another family); and (b) a record of the released device - internal account identifier, random device identifier, the same fingerprints and the time of release (thus the released device cannot be taken over again by another sign-in session of the same account, for example a stolen one, without proving that it is the same installation). Furthermore, the server keeps a device registration record (internal account and device identifier, push token fingerprint, event type and time) for 30 days, by which it monitors the limit of new device registrations per 24 hours. Retention periods are specified in section 6; a record of the released device is not kept upon account deletion. Furthermore, server operational logs (e.g. error states) without phone numbers and request content. On the phone, the app keeps sign-in tokens in secure storage and remembers the selected language and theme; it also communicates the selected language to the server so that notifications arrive in your language. What the app sends directly to the Expo and Sentry services is described in section 4.

Why we process data and on what legal basis:

  • Family account and app features (registration, family, tasks and photos, plans, reminders, rewards, goals, pocket money including records of direct payouts and manual repayments, notifications and subscriptions): performance of a contract, i.e. the terms of use (Art. 6(1)(b) GDPR). In addition, we process records of direct payouts and manual repayments and the history of changes to financial rules on the basis of our legitimate interest in the verifiability of financial operations and rules in the app and in resolving disputes in the family (Art. 6(1)(f) GDPR). In addition, we process the proof of consent to the immediate start of Premium and its copy outside the database on the basis of our legitimate interest in demonstrating this consent and in defending legal claims (Art. 6(1)(f) GDPR). For children's data, see section 5.
  • Sign-in verified by SMS code: performance of a contract (Art. 6(1)(b) GDPR) - without a verified phone number, it is not possible to sign in to the app.
  • Security and protection against abuse (sessions and token fingerprints, SMS code challenges, rate limits and daily SMS limit, security records, journal of phone and member status changes, memory of released push tokens and devices, a device registration record and a limit for new device registrations per 24 hours, a queue of security notifications and a record of undelivered notifications, operational logs, a phone number fingerprint against repeated use of the trial period, parental consent requests that protect the family from unilateral removal of a parent or deletion, and identity verification when support returns a hijacked account, including a record of such interventions): our legitimate interest in the secure operation of the service, protection of parent and child accounts and defense against abuse of SMS verification (Art. 6(1)(f) GDPR).
  • Bug fixing and app updates (error reports via Sentry, updates via Expo): our legitimate interest in a stable and secure app (Art. 6(1)(f) GDPR).
  • Handling your requests under section 7 and proof of how and when we handled them (e.g. the status of a completed deletion, a journal of completed deletions and an external deletion task): compliance with a legal obligation (Art. 6(1)(c) GDPR).
  • Advertising measurement on the kimda.app website (Meta Pixel): your consent (Art. 6(1)(a) GDPR), see section 9.

You can object to processing based on legitimate interest (section 7). The phone number is necessary for registration and sign-in; without it, the app cannot be used. The profile photo is optional and a photo of a completed task is only needed for tasks where the parent requires it. We do not use automated decision-making or profiling with legal or similarly significant effects (Art. 22 GDPR); automatic security limits, which for example temporarily block further SMS code attempts, serve only to protect accounts and the service.

3. Task photos

Photos that a child (or a parent on their behalf) uploads for a task can be seen only by members of the same family (parents and children in the app). They are not public, and the app does not share them with any other app or social network. A task photo can only be taken with the in-app camera. The app and then the server again remove metadata (such as GPS location or camera details) from the photo before saving it. Photos are stored in non-public object storage (see section 4) and the server will only release them to a signed-in member of the same family. A parent can request their deletion at any time.

For each uploaded photo, the server calculates a technical fingerprint (a checksum and a simplified 64-bit image fingerprint). It only serves to let the app recognize when the same or an almost identical photo is used for a task again, and to ensure the photo belongs to the task for which the child just took it in the app. The photo cannot be displayed or reconstructed from the fingerprint, and it is deleted along with the photo. The record of the time challenge for the photo (who requested it in the app, for which task and when) is deleted by the server after 7 days. The parent sees a warning next to the photo when the photo does not have a valid app time check or is very similar to a previous photo, as an aid during approval; the check does not guarantee that the photo cannot be spoofed.

4. Who we share data with and transfers outside the EU

We only share data with providers who operate the app for us (processors), and only to the extent they need to do so. Processors may only use the data to provide their service for us and according to our instructions. Apple and Google act as independent controllers for store purchases.

  • Hosting provider (Railway) - operates the app server and the database where the app data is stored.
  • Cloudflare - the private R2 object storage keeps profile photos and photos of completed tasks transferred in encrypted form, database backups (encrypted even before transmission in such a way that they can only be decrypted with a private key we keep outside the cloud), a log of completed deletions (only internal identifiers, type of deletion and time), the journal of phone and member status changes (section 2: internal identifiers, type and time of the event and for a number change irreversible number fingerprints) and a copy of the proof of consent to the immediate start of Premium (section 6: internal family and user identifiers, time of consent, chosen plan, start of the paid period, store transaction identifier and version of the displayed text) in non-public buckets; access to the photos remains controlled by the signed-in Kimda backend. Cloudflare also operates the kimda.app website (section 9).
  • Twilio (phone verification by SMS code) - receives the phone number and the code you enter solely for the purpose of delivering and verifying the SMS code.
  • Expo (650 Industries) - firstly, it delivers notifications: it receives the device push token, the installation identifier for notifications, the native Apple or Google token, a generic notification text or emoji and a generic technical event type. We do not send database IDs, names, task names or amounts in push messages. Expo forwards the message to the Apple Push Notification service or Firebase Cloud Messaging. Secondly, it delivers app updates (EAS Update): the app asks Expo servers on every launch if a fix is available. In doing so, Expo receives the device IP address, platform, app version, installed update identifier, optionally the text of the last error that crashed the app, and a random installation identifier EAS-Client-ID, which the app permanently stores on the phone and which does not change even after sign-out. We do not link it to your account and the app does not send it to our server.
  • Apple and Google - as independent controllers, they process the purchase and management of subscriptions in the App Store and Google Play; as push services (Apple Push Notification service, Firebase Cloud Messaging), they deliver notifications to devices.
  • RevenueCat (processing of subscriptions via the App Store / Google Play, for parent accounts only) - processes the family identifier, purchase history, the Apple receipt or Google purchase token, time of last use and technical device data (e.g. device type and operating system). It does not receive the name or phone number of any parent or child from Kimda. RevenueCat advertising/attribution integrations and manual collection of advertising identifiers are not enabled in the app.
  • Sentry (technical error reports from the app and server, for fixing bugs) - receives the error type, location in the code, app version and operating system. Both the app and the server are configured not to send it the name, phone number, sign-in token, request content or IP address. The Kimda organization in Sentry is hosted in the EU data region (Germany).
  • Email provider (Spaceship, Spacemail service) - delivers and stores emails you send us at privacy@kimda.app or support@kimda.app.

Railway, Cloudflare, Twilio, Expo, RevenueCat, Sentry, Spaceship, Apple, Google and Meta (section 9) are companies based or backed in the USA, and may therefore process data outside the European Economic Area. For transfers outside the European Economic Area, we use a mechanism under Chapter V of the GDPR that applies to the specific recipient and processing - typically the recipient's certification under the EU-USA Data Privacy Framework (an adequacy decision by the European Commission, Art. 45 GDPR) or standard contractual clauses approved by the European Commission (Art. 46(2)(c) GDPR). We will provide you with information about the mechanism for a specific recipient and about where a copy of the relevant safeguards can be obtained upon request at privacy@kimda.app.

We do not sell data from the app, share it with advertisers or use it for targeted advertising. Measurement of advertising on the kimda.app website, with the visitor's consent, is described in section 9.

5. Parental consent and children's roles

Only an adult may set up the app (the "parent" role and a new family). An account with the "child" role is only ever created after joining with an invite code that only the parent knows - so a child can only take part with the knowledge and consent of the parent who shares the code. Furthermore, every connection of a child or another parent must be explicitly approved by a parent in the app; until approved, the new member can only see the family's name. The family invite code is valid for 48 hours, an unapproved request is automatically deleted after 72 hours, and a rejected or cancelled one immediately. By registering in the "parent" role, you confirm that you are of legal age and that you have the legal right to consent to the processing of your children's data in the app.

We process a child's data only to the extent necessary for the functioning of the family account set up and managed by the parent, i.e. for the performance of the contract with the parent (Art. 6(1)(b) GDPR). The parent, as the legal representative, decides on the child's participation: they share the invite code, explicitly approve the child's connection and can remove the child from the family or request the deletion of their account at any time. The child only acknowledges the policy during registration; consent to the processing of their data is given by the parent when they approve the child's connection in the app, and the server records the time, the parent and the policy version. For children approved with an older version of the app, the app will additionally request the missing consent from the parent. If the processing required consent and the child was not yet 15 years old (the age limit in the Czech Republic under Art. 8 GDPR and Section 7 of Act No. 110/2019 Coll., on personal data processing), the parent gives consent on behalf of the child. The child's rights under section 7 can be exercised by the parent on their behalf.

6. How long we keep data

We keep account and family data until a user requests deletion of the account or of the entire family. Mere inactivity in the app does not trigger automatic deletion. Users therefore do not have to open the app regularly in order not to lose the family history, and they can start the deletion at any time directly in the app or request it at privacy@kimda.app. We keep the history of changes to financial rules (section 2) for the entire duration of the family's existence, without a time or total numerical limit (a family may save changes to financial rules a maximum of 30 times per hour), because it serves as an immutable proof of who changed the rules and when, for example in a dispute between parents; it cannot be edited or deleted in the app. After the deletion of the entire family (section 7), the server deletes it during the next cleanup; the deletion of an individual member's account does not change it and only an internal identifier without a name remains with it.

The following periods apply to other specific records:

  • SMS code challenges (fingerprints of the phone number and challenge): valid for 10 minutes; after successful verification, the server deletes them immediately, otherwise no later than an hour after they expire.
  • Rate limits and daily SMS limit (fingerprints): the server deletes them 24 hours after the end of the monitored period; the daily SMS limit always ends at midnight UTC.
  • Sign-in sessions: the sign-in token is valid for 15 minutes; the session ends after 30 days of inactivity, at the latest after 90 days, or earlier upon sign-out. The server deletes the ended session, including token fingerprints, 30 days after it ends.
  • Invites and join requests: the family invite code is valid for 48 hours and an invite for another parent for 24 hours; an unapproved join request is automatically deleted after 72 hours, a rejected or cancelled one immediately. The record of an invite for another parent (the code, who created it and who used it) is deleted by the server 30 days after its expiration, use or cancellation.
  • Security records in the database (section 2): the server automatically deletes them after 30 days. The journal of phone and member status changes is governed by its own period specified below.
  • Journal of phone and member status changes (section 2): the server deletes a record in the database no earlier than 60 days after its creation, and only after it has copied it to separate storage (a copy is usually created within a few minutes). The server does not delete a record that failed to copy until copying succeeds, and it therefore remains in the database even longer than 60 days. The copy in separate non-public Cloudflare R2 storage is deleted by the storage itself 60 days after being stored. Upon deletion of an account or the entire family (section 7), the server deletes the journal records of the deleted account or family from the database; their copy in the storage expires at the latest 60 days after storage.
  • Photos: unattached photos that could not be assigned to a profile or task are removed by the server after 24 hours; the record of the time challenge for a photo is deleted after 7 days (section 3) and the technical record of a deleted photo (only internal identifiers) 30 days after the photo is deleted.
  • Push token and device identifier: until the device is signed out, the member is removed from the family or the account is deleted, or until Apple or Google marks it as invalid. In addition, the server deletes them itself if the app has not renewed the device registration for 90 days (it renews it on every sign-in and launch), or if the user has not had a valid sign-in session for more than 30 days. After the device is signed out (even remotely in the Profile) or its sign-in ends, nothing is delivered to the device. An exception is registrations from before the deployment of this version, which the app has not renewed since: signing out one device remotely will not disconnect them, the Sign out all devices option will; otherwise, the server deletes them according to the periods above. The server deletes the record of the released push token (fingerprints, family and time) after 30 days, or earlier if the device registers again. The server deletes the record of the released device (internal account identifier, random device identifier, fingerprints and time) after 91 days - that is, only after the expiration of the longest possible validity of a sign-in session (90 days) - or earlier if a device of the same account registers again. A record of the released device is not kept upon account deletion; if it was already created when deletion was initiated, the server deletes it upon its completion. The period for the record of the released push token thereby remains unchanged. The technical fingerprint of the push token for a sent reminder serves only to verify delivery; the server deletes it after evaluating the delivery, at the latest 30 days after sending. The server deletes the device registration record (internal account and device identifier, push token fingerprint, type of event and time; section 2) after 30 days from its creation, even if you delete the account in the meantime.
  • Security notification queue and undelivered notifications (section 2): the server removes the notification recipient data (device push token or internal identifier of the family or account and language) from the stored queue record immediately after delivery or after giving up on delivery, but no later than 7 days after the notification is created; only the internal family identifier (in case of an exceptional database error temporarily also of the account) may remain in it until the undelivered notification record is written (below). It deletes the remaining record (type of notification, generic technical event type, time and technical error message) 30 days after processing. It keeps the record of an undelivered notification for a parent (internal family identifier, type of notification and time, without a push token and without a name) until the parent confirms it in the app; it deletes a confirmed record once it is older than 90 days. It deletes a record of a family that no longer exists during the next cleanup.
  • Saved responses of financial operations: so that a repeated request after a network outage does not record a payout, loan or other financial operation twice, the server remembers the response to it for 30 days. The record of the operation itself (type of operation, its random identifier, internal identifiers of the family, actor and affected member, SHA-256 fingerprint of the request and time) is part of the financial history and is kept until the account or family is deleted.
  • Records of direct payouts and manual repayments (section 2): unlike the saved response above, which is deleted after 30 days, these records are kept until the child they concern or the entire family is deleted (section 7).
  • Stored records of repeated scheduler requests: so that a repeated request after a network failure does not create a task schedule twice, the server keeps a record of its creation for 60 days (internal family and parent identifiers, type of operation, random request identifier, SHA-256 fingerprint of the entered schedule parameters, a link to the created schedule and time). The server also deletes the record upon deletion of the account of the parent who created the schedule, and upon deletion of the entire family (section 7).
  • Account deletion request: an unconfirmed deletion request is invalidated after 45 days and deleted at the latest after another 400 days; the record of the completed deletion (only internal identifiers and status, without names and contacts) is kept as proof that we handled your request, namely for 3 years from the handling. To the same extent (internal random identifier of the account or family, type of deletion and time), we keep a log of completed deletions so that after a possible database restore from a backup, all subsequent deletions are reapplied. The server deletes the log record in the database no earlier than 180 days after its creation, and only after it has copied it to a separate storage (the copy is usually created within a few minutes); the server does not delete a record that failed to be copied until the copying is successful. The copy in the separate non-public storage is deleted by the storage itself after 60 days from its storage. The encrypted export of the log, which is part of the database backup, expires together with the backup (at the latest after 30 days).
  • Parental consent requests: an open request is valid for 14 days; it is only extended if another parent joins the family in the meantime (for a request to delete the family, the new parent receives their own 14 days, but at most until the end of a possible protection period following the removal of another parent), or after restoring the database from a backup (except for a request to delete the family, which is valid only until the end of the protection period). A request to delete the family that would expire during the 14-day period following the removal of another parent lasts until the end of this period and then expires. During the 14-day period following the removal of another parent, the family cannot be deleted; a request to delete the family submitted during this period will expire after its end. After the period expires, the only remaining parent can delete the family directly in the Profile. The server deletes a resolved request after 90 days.
  • Phone number fingerprint after account deletion or number change: to prevent the Premium trial period from being repeatedly obtained by deleting an account and registering anew, upon deletion of an account of a parent who was a member of a family during its trial period, and upon a number change of such a parent (even when the number is changed by support at their request), the server stores only a fingerprint of the previous phone number (HMAC with a secret key) and the time — not the number itself. A new registration with the same number will not receive the trial period. The server deletes the fingerprint after 12 months.
  • Emails you send us: for the time necessary to handle your question or request and to prove how we handled it.
  • Record of support and administration interventions: the server automatically deletes the record of the intervention in the database (type of intervention, who performed it, when, which family it concerns and the request number – without names and phone numbers; this is how we record the restoration of a number and signing out of devices by support, the export of family data upon request and the management of promo codes and free access) after 3 years. We keep the log of support requests (request number, date, internal account identifier, method of identity verification and result – without the phone number) encrypted outside the database and also retain it for 3 years as proof of how we handled the request.

Production operational and security hosting logs may be kept for no more than 30 days. Technical error reports of the app and server are kept by Sentry for no more than 90 days so that we can trace and fix errors that only appear after the release of a new version of the app; any operational backups of Sentry expire no later than 90 days after their creation. Database backups are taken daily, encrypted even before transmission from the production environment and deleted 30 days after being taken, so previously deleted data will remain in them for no more than 30 days; they are not used to routinely restore a deleted account. If we had to restore the database from a backup, we would reapply deletions made after the backup was taken according to the log of deletions. The hosting, database and storage settings must technically enforce these periods, and the operator reviews them regularly.

If deletion of a record at an external subscription provider cannot be completed immediately, Kimda anonymizes the local personal data without further delay once the media have been removed. In order to safely retry the external request, it keeps only the internal random family identifier and the technical deletion status, not names or phone numbers. The server deletes the record of this external deletion task (internal family identifier, provider designation, number of attempts, times and the last error code, without names and phone numbers) 90 days after its completion; an unfinished task is kept until it is completed.

We retain the proof of consent to the immediate start of Premium (internal family and user identifiers, time of consent, chosen plan, start of the paid period, store transaction identifier, internal identifier of the purchase attempt and version of the displayed text) for the period necessary to prove this consent in a potential dispute, standardly 3 years from its granting. Upon expiration of the period, the proof is deleted in a controlled manner. The proof is not deleted together with the account or the family (section 7). We also store its copy (without the internal identifier of the purchase attempt) in the separate non-public Cloudflare R2 storage (section 4) so that the proof survives a loss of the database between backups; the storage deletes it itself after 1125 days from its storage.

7. Your rights

You have the right:

  • to access all data the app keeps about you and your family (Art. 15 GDPR),
  • to correction of inaccurate data (Art. 16 GDPR) — you can change your phone number yourself in the Profile after verifying the new number with an SMS code; if you lose access to your account (for example because someone else changed the number from a signed-in device), we will change it at your request upon identity verification,
  • to deletion of an individual member's account (Art. 17 GDPR) - directly in the app (Profile → Delete account), the app irreversibly removes or anonymizes the name, phone number, photo and push token, and deletes all photos you uploaded; for a child's account, also the photos for their tasks uploaded by a parent on their behalf. The account can then no longer be used to sign in and no name or contact details remain with it. In the task and payment history, only the accounting facts necessary for the continuity of the rest of the family remain (points, amount, status and time); the free-text note is deleted and the names of tasks and goals are replaced with a neutral value. This history is not deleted, because it remains linked to the rest of the family (otherwise their mutual accounting would no longer add up), but it is tied only to a record without a name and contact details. The child's records of direct payouts and manual repayments (section 2) are deleted along with the child. The server deletes the records of the journal of phone and member status changes (section 2) from the database; their copy in separate storage expires at the latest 60 days after storage. If a child has a debt, balance or pending requests, the app will show them what amounts they will lose before deletion, and they must explicitly confirm the deletion; parents will then receive a generic notification. A member whom a parent has removed from the family can, after verification by SMS code in the app, permanently delete their account themselves and thereby free up their phone number,
  • to cascading deletion of the entire family - when a parent explicitly confirms deletion of the entire family, we anonymize all its members, delete their photos and, in addition, replace free texts and the names of custom tasks, goals and rewards with neutral values; we also delete the family's records of direct payouts and manual repayments (section 2), the history of changes to the family's financial rules (during the next cleanup) and records of the journal of phone and member status changes of its members (a copy of the journal in separate storage expires at the latest 60 days after storage). Removal of another parent requires the consent of the affected parent: explicit rejection stops the action, without a response it is carried out after 14 days. Deletion of the entire family in which there is another parent requires the explicit consent of every other parent; without the consent of all, the request is cancelled after 14 days and the family is not deleted. A family from which another parent was removed in the last 14 days can be deleted no earlier than 14 days after their removal. Accounting records of a deleted family, including balances and statuses of children's loans and savings, are removed from the operational database no later than 30 days after deletion; they may remain in encrypted backups for at most another 30 days before the backup is deleted. The proof of consent to the immediate start of Premium is not deleted with the deletion of the family (section 6). Anonymized records of the application of partner codes, which do not contain personal data, are kept for partner record-keeping and protection against abuse. Once the media have been removed the local anonymization is carried out even if RevenueCat is temporarily unavailable; the external request is then safely retried using only the internal family identifier. RevenueCat carries out the deletion asynchronously. This does not cancel a subscription managed by the App Store or Google Play - the parent must cancel it separately in the settings of the relevant store,
  • to restriction of processing (Art. 18 GDPR), for example when you contest the accuracy of the data, for the period until we verify it,
  • to portability (Art. 20 GDPR) - we will provide the data you have provided to us and which we process based on a contract in a structured, commonly used and machine-readable format (e.g. JSON), or, at your request, we will transmit it to another controller, where technically feasible,
  • to object (Art. 21 GDPR) to processing based on our legitimate interest (section 2); we will then stop the processing unless we demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or we need it for the establishment, exercise or defense of legal claims,
  • to withdraw consent at any time (Art. 7(3) GDPR) - you can withdraw consent to advertising measurement on the website via the "Cookie settings" link in the website footer (section 9); the withdrawal does not affect processing prior to it,
  • to lodge a complaint with a supervisory authority (Art. 77 GDPR) - in the Czech Republic, this is the Office for Personal Data Protection (Úřad pro ochranu osobních údajů), Pplk. Sochora 27, 170 00 Praha 7, website uoou.gov.cz; you can also contact the supervisory authority in the EU member state where you live or work.

Send your request to privacy@kimda.app. To ensure we do not hand over or delete data to someone else, we will first verify that the request is made by the account owner (for example, by confirmation from the phone number associated with the account); never send us codes from sign-in SMS. The only exception is the code from the SMS marked “Kimda obnova účtu”, which support will request from you only in response to your own request for the return of a hijacked account, or to your own confirmation of such a request from another parent in your family (section 2); even then, tell it only to support, never to another family member. Support requests this code from you exclusively by e-mail from the address support@kimda.app with your request number, never by phone or through another family member. We handle requests for access or portability by exporting the family's data in JSON format (without sign-in tokens and their fingerprints and without fingerprints of original phone numbers from security records, which serve only to verify a request for the return of an account, and without the journal of phone and member status changes, which serves only to protect against taking over a number; the export includes records of direct payouts and manual repayments (section 2); for photos it contains their technical fingerprint according to section 3, we will provide the photos themselves separately upon request); we record each export (who prepared it, when and based on what request). Upon request, we will provide you with event data from the journal of phone and member status changes (type and time, without fingerprints). We will respond without undue delay, at the latest within one month; in more complex cases, we may extend the period by a further two months, of which we will inform you in good time. The rights of a child can be exercised by a parent as their legal representative.

8. Security

The app does not use passwords (sign-in only via a verified phone number). Access is protected by a short-lived sign-in token valid for 15 minutes and a refresh token, which the server stores only as a fingerprint; upon proven reuse of an already replaced refresh token, the server signs the account out on all devices, cancels its registrations for notifications, writes a security record and notifies other parents. In production, communication between the app and the server takes place over HTTPS. Photos are kept in non-public storage, and before releasing them the backend verifies the account and membership of the same family. Database backups are encrypted even before transmission and can only be decrypted with a private key stored outside the cloud; promo codes are in the database only as an HMAC fingerprint with a key outside the database, and we record promo code management. The server does not write phone numbers, tokens or request content into operational logs.

9. The kimda.app website and cookies

This section applies only to visitors of the kimda.app website, not to use of the app. The website runs on the Cloudflare network, which technically processes the IP address and browser data on each visit in order to deliver the page and protect it against attacks; Cloudflare keeps records for website error diagnostics for a maximum of 3 days. Depending on the browser language (and for the download link, also the device type), the website redirects you to the appropriate version of the page. The legal basis is our legitimate interest in a secure and functional website (Art. 6(1)(f) GDPR). The website remembers the selected theme only in your browser (localStorage). Your cookie decision is stored in localStorage and in a strictly necessary technical cookie kimda-consent-proof (valid for 180 days), which contains only the type of choice and the time of the decision, with no identifier of a person or account. Your browser technically sends it with every request to the website; the server does not evaluate it, it is used only by the script in your browser to verify that consent has not been withdrawn. This cookie does not require consent and is not used for measurement or advertising.

Only if you choose "Accept" in the banner on the website does the website load Meta Pixel from Meta Platforms Ireland Limited. It stores a cookie in your browser (e.g. _fbp, valid for up to 90 days) and sends Meta data about the visit: the page visited, IP address, browser data and the cookie identifier. We use it to measure the effectiveness of advertising on Facebook and Instagram. The legal basis is your consent (Art. 6(1)(a) GDPR and Section 89(3) of Act No. 127/2005 Coll., on electronic communications). We are jointly responsible with Meta for the collection and transmission of this data; its further processing, including any transfer to the USA under the EU-USA Data Privacy Framework, is carried out by Meta as an independent controller in accordance with its policy at facebook.com/privacy/policy. We never send data from the app, your account or your family to Meta.

Without consent, Meta Pixel is not loaded at all. You can withdraw your consent at any time via the "Cookie settings" link in the website footer; the website then deletes the Pixel cookies and no longer loads the Pixel.

If you join the tester group in Google Groups via the tester page, the group administrator will see the email of your Google account; we will use it only for testing the app and for access to its test version in Google Play. The test version for iPhone is distributed by Apple via TestFlight. Google and Apple process the data as independent controllers in accordance with their policies. The legal basis is your request to participate in testing (Art. 6(1)(b) GDPR). The email will remain in the group until you unsubscribe from it or until the testing ends.

10. Changes to this policy

We will inform you in the app and on the kimda.app website of any material change to this policy. The app recognizes which version of the policy you have agreed to: it will ask parents to confirm the new version (and where applicable for consent on behalf of children), and a child will acknowledge it. We will record the time and version of the confirmation.

11. Contact

Questions about personal data protection: privacy@kimda.app

Kimda – the family app for chores and pocket money
Privacy Policy Terms of Use Support Account deletion

© 2026 Mgr. Ivo Slávka, Company ID 30070929, Bergerova 1115/2, 182 00 Praha 8 – Kobylisy, Czech Republic · support@kimda.app