TrackIt Life — Privacy Policy

---

1. Who we are

TrackIt Life is run by A&C Digital Ltd, a company registered in England and Wales (company number 17064862), trading as TrackIt Life. We are the data controller for the personal data described in this policy.

• Registered office: 124 City Road, London EC1V 2NX
• Privacy contact: privacy@trackitlife.app
• ICO registration reference: 00014707883

TrackIt Life is a hosted service. We run the servers it operates on; you do not host, install or operate any part of it yourself.

This policy is written to comply with the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.

2. The service is in beta

TrackIt Life is currently in beta. Sign-up may be open to everyone or by invitation at different times. The features and data flows described here are those in place at the date above. If we change what we collect or who we share it with, we will update this policy and tell you before the change takes effect.

3. Households, accounts and who controls what

3.1 An account is a household

In TrackIt Life an account is a household, not a person. One person creates the account and becomes its owner. The owner can invite other people to join the household as members. Most data in the platform — expenses, budgets, receipts, shopping lists, meal plans, the household diet profile — belongs to the household and is visible to its members according to their role.

3.2 Roles

3.3 What members can see of each other's data

• Household data (finance, grocery, the household diet profile including any children's entries) is shared. Every member can see it, subject to their role.
• Personal health data in the Fitness app — your fitness profile, weight log, body measurements, progress photos and workouts — is scoped to you. Other members do not see it in the app in normal use.
• The exception is the household export. When the owner downloads the household's data (see section 11), that file contains every member's user record, every member's fitness profile, weight logs and body-measurement records (including progress-photo details, though not the photo files themselves), and the household diet profile including children's ages, allergies and dietary preferences. A member who is not the owner can only download their own data.

3.4 Who is the controller for a member's data

A&C Digital Ltd is the controller for all personal data processed on the platform, including data about household members and about people the owner enters who do not have an account (see section 5.4 on children and other household members). The owner and other members decide what to enter, but we determine how the platform stores and processes it.

3.5 When a member is removed from a household

The owner (or an Admin, for Editors and Viewers) can remove a member. When that happens:

• the member loses access immediately and all their logged-in sessions are ended;
• they receive an email telling them they have been removed, which names the household;
• any pending invitation to the same email address is cancelled;
• their household data is not deleted — expenses, receipts and other household records they contributed belong to the household and stay with it;
• their user record is kept, marked as a former member, so that if they are later re-invited we can recognise them as a returning member rather than a stranger.

A removed member keeps their own individual rights (section 11) and can ask us to delete their user record.

3.6 When the whole account is deleted

Only the owner can request deletion of the whole account. Section 10 explains the timing. When the account is deleted, all household data is erased, including data contributed by members who were removed earlier, because that data belongs to the household. The user records of current members are deleted. The user records of former members are not deleted by the owner's request, because those people are no longer party to it; a former member can ask us to delete their record separately.

4. Information we collect — identity and account

When you create or join an account we collect and store:

• username and email address;
• your password, stored only as a salted bcrypt hash — we cannot read it;
• first name and last name;
• optional profile details: gender, age range, work status;
• email-verification and password-reset tokens while they are in use;
• your last login time;
• your multi-factor authentication (MFA) seed, if you enable MFA, stored encrypted (AES-256-GCM), and hashed single-use recovery codes;
• your idle-logout and vault auto-lock preferences;
• household details: household name, members, roles, invited email addresses and invitation tokens, and the signup invite code the account was created with, which records the email address it was used by;
• account settings including privacy choices (marketing opt-in, "do not sell" flag), suspension and deletion status, and which versions of our policies you have accepted;
• login sessions, each recording a hashed refresh token, the IP address and browser/device (user agent) used, and an expiry time.

Your account also carries a small profile record whose contents depend on what the setup flow submitted. It holds no category of data that is not already listed above or in section 5.

Whether you have to provide it. Your email address, username and password are a contractual requirement: we cannot create or operate an account without them, and the service cannot be used without an account. There is no statutory requirement to provide any of it, and no consequence of not providing it other than not having an account. Everything else is optional — the finance, fitness, diet and shopping records in section 5 are there because you chose to enter them, and each app can be left unused. If you do not enter optional data the features that depend on it have nothing to show, and the rest of the service continues to work.

4.1 Beta membership and sign-up

When you sign up, and while your account is in the beta, we also hold:

• your invite code — if you sign up with one, the code's record notes the email address you signed up with and when the code was used. It is deleted when your account is deleted (section 10);
• your 16+ confirmation — you confirm you are 16 or over when you sign up, and once more inside the app; we record the confirmation against your user, with a date and a consent-register entry. We never ask for your date of birth;
• Terms acceptance — which version of the Terms of Service your household's owner accepted, and when, as a consent-register entry;
• your beta dates — your account's beta status and the date your free beta ends;
• the beta reminder — whether you have asked us to email you 30 days before your beta ends. It is off unless you turn it on;
• extension requests — if the account owner asks for more beta time: when they asked, anything they wrote with the request, our decision, the note we send with it, and the end date before and after;
• the sign-up check — a short puzzle your browser solves, a hidden form field and a timing check, to keep automated sign-ups out. It runs in your browser against our own servers, with nothing sent to any third party; we keep only a short-lived record that a puzzle has been used, so it cannot be replayed, and nothing about you;
• unverified accounts — if no one in the household verifies their email address, the account is deleted automatically once it is more than 7 days old, at our next daily check (section 10).

These beta records are part of the household's data: kept until the account is deleted, included in the owner's export, and removed when the account is erased (section 10).

5. Information we collect — by app

5.1 Finance app

Amounts are encrypted before they leave your browser. Expense amounts, account balances, income and asset values, investment values, pension projections, property values, mortgage overpayments and credit-card balances are encrypted on your device with a key only you hold (section 13). Our servers store ciphertext and cannot read the figures.

The following financial information is stored in readable form so that the app can search, categorise and report on it:

• merchant or expense names, categories, tags, merchant type;
• transaction dates, payment method, status and source;
• where a transaction or an income came from a statement you uploaded, which upload it came in on. This is an internal reference to the upload record described under "Statement and invoice uploads" below — not a copy of the file or anything in it — and it is what lets us look for subscriptions and regular incomes in the statement you have just imported;
• currency;
• bank name, country, account type and display name — we do not store account numbers, sort codes, card numbers or the last digits of any of them;
• account holder name on each account you link, and any other spellings of your own name you tell the Import tab to treat as you (for example "A IYENGAR"). These are used only to recognise transfers between your own accounts. A transaction on a credit card may show the card's name you gave it in place of a holder name;
• an account fingerprint for each bank account and credit card you link. It is a keyed code (HMAC-SHA256) that the Finance app works out in your browser from the sort code and account number, or from the card number, using a key derived from your vault's private key (section 13). It lets the app recognise which of your accounts a statement file belongs to. We cannot turn it back into the numbers, and because the key never leaves your browser, nobody — us included — can work it out from a guessed number either. If you lose your passphrase, the fingerprints stop matching along with your encrypted amounts;
• the column layout of a statement file, once you have imported a file of that layout under a bank: a SHA-256 of its header row — the column names, never a value from the file — so that the next file laid out the same way is recognised as that bank's;
• your import preferences: the default payment method, the date format, and whether the Import tab auto-marks internal transfers, predicts categories, saves each month's incomes to its budget (adding to what is there, or replacing it) and reconciles budgets after an import. They also hold how income near the end of a month is counted — how many of a month's last days count toward the next month's budget, for the household and, where you ask us to remember it, for a particular account (filed under the same keyed fingerprint of that account we already keep, never its account number) — and any payer you tell the Import tab to always count toward this month or the next, by the payer's name as your statement prints it (for example "ACME LTD"), and whether you have dismissed the Import tab's explanation of that. They also hold the payers you tell us are not a regular income of yours (with "Not income" or "Dismiss" on a detected income source), each as a short form of the payer's name (for example "acme widgets") and never an amount. They also hold which of your linked accounts you told My Banks are not a credit card (by dismissing "Looks like a credit card"), each as the account's internal reference and never its number or name. They also hold the payees you told us are a payment to one of your credit cards or a move between your own accounts (by filing one under "Credit Card Payments" or "Transfers"), each as a short form of the payee's name with no numbers in it (for example "hfx clarity"), kept against that card's or account's internal reference, so the Import tab recognises them next time — never an amount;
• for each income saved to a budget: the payer's name as your statement prints it, the date it was paid and which of your linked accounts it arrived in (the amount is encrypted). We use the date and the account only to warn you when an import would add an income that is already on one of your budgets;
• mortgage and loan account references and sub-account numbers exactly as you type them. These are free-text boxes for you to tell one borrowing account from another, and we do not check or shorten what you put in them. If you type a full account number into one, that is what we store, in readable form. If you would rather we did not hold it, use a label that is meaningful to you instead — "flat, Nationwide" works as well as a number;
• the description line from each statement transaction and its raw type;
• for a subscription, direct debit or membership you track: the merchant's description as your bank prints it, simplified into a comparable form — and, where its charges have appeared under more than one wording ("SPOTIFY UK LTD", "DD SPOTIFY"), each of those wordings, added when a charge is matched to the payment, together with the name the payment had when it was added. We keep them separately from the name you give the payment, so that renaming "APPLE.COM/BILL" to "iCloud" does not stop us recognising its charges. If you tell us a regular payment we suggested is not that payment ("No, that's something else"), we keep its wording against the payment too, so we do not suggest it again. They are derived from statement lines and names we already hold and are never shown to you;
• a keyed fingerprint of each amount — on each transaction, on each subscription, direct debit or membership you track (and its past amounts), and on each period we match to a payment. It is a keyed fingerprint of an amount, computed on your device from your vault key; it lets us see that two amounts are equal without seeing them. We use it only to tell whether this month's charge is the same amount as last time. We cannot turn it back into the amount, and because the key is derived in your browser and never sent to us, nobody — us included — can work one out from a guessed amount. Another household's fingerprint of the same amount is unrelated to yours. If you lose your passphrase, the fingerprints stop matching along with your encrypted amounts;
• investment provider, holding name, ticker and wrapper; pension employer and contribution percentages; retirement age;
• physical assets: type, label (which may be a property address if you type one) and purchase details.

Statement and invoice uploads. When you upload a bank statement or an invoice for automatic parsing, the whole document is sent to our AI provider (section 7.1) and read there. A statement may contain your account holder name and sort code. We do not store the file. It is held in memory while it is being read and is never written to our disks or object storage. What we keep is a parse log recording the bank, the file name, file size, page count, the AI model used, token counts and the parse results.

Recognising which account a statement belongs to. When you add a CSV, spreadsheet or PDF on the Import tab, the Finance app reads its first rows (or, for a PDF, the text of its first page) in your browser, before anything is uploaded. A sort code, account number or card number it finds there is turned into the account fingerprint above and then discarded: it is never sent to us, and nothing else from the file is kept at that point.

We may suggest a recurring payment you did not enter. When you import a bank statement, we look at the merchants in it and, where the charges look like they repeat, we add a suggestion to your Subscriptions or Direct Debits list. It is only a suggestion until you accept it: it is not counted in your budget forecast, it does not generate a reminder, and it holds the same information as any payment you add yourself (described below). We also do this once a month over the statements you have already imported. Both are controlled by one setting — Finance → Settings → "Subscriptions and direct debits" — which is on unless you turn it off, and turning it off stops us looking and stops anything being added.

Recurring payments, and the record of each period. You can rename any payment to whatever you call it, and that name is yours alone — it changes nothing at your bank. You can also give a payment a nickname and say who it is for — someone in your household, or a few words of your own such as "the car" or "the dog"; we keep both with the payment and show them on your list, and we never use either to recognise a charge. If you tell us a direct debit pays off one of your loans or your mortgage, we keep which one, so that repayment is counted once in your monthly figures; if you tell us one does not, we keep when you said so, so we do not suggest it again. For a subscription, direct debit or membership you track, we also keep one record per period — one for September's charge, another for October's. Each says which payment it belongs to, which period it covers, the date the payment was expected, whether it arrived, was missed, changed price or was skipped, whether that was decided automatically or by someone in your household, and when. While a period is still open we may also keep the ids of the expenses on your statement that could be its payment — same merchant, within a few days of the date — so the amount can be checked; nothing else about them is copied. If we match it to an expense we keep the id of that expense, a copy of its encrypted amount and a copy of its amount fingerprint, so you can still see a price change after the expense itself is edited or re-imported. If you tell us one period was paid in more than one part, we keep the id of each of those expenses and their total, encrypted in your browser before it is sent to us, with that total's fingerprint — the adding-up happens there, not on our servers. That copy stays encrypted: our servers hold no key that could read it. When your amounts carry fingerprints, matching a charge to its period happens on our servers: we compare the charge's amount fingerprint with the payment's — equal fingerprints mean equal amounts, and that is all we learn — and record the match automatically, without ever seeing or comparing the amounts themselves. Until the fingerprints are there, the matching happens in your browser instead. We keep one record of when this matching last ran for your household — counts of what it checked and matched, and when — so it does not repeat work when nothing has changed. These records are worked out from the schedule you already gave us rather than entered by you, and they are created when you open a month — and, when you add a payment or tell us another statement line is one of its charges, for every month back to the first charge of it on your statements (up to two years), so its history is there from the start. Where we could not work out how often a payment recurs we assume monthly, and the record says so. We remember which payments you told us belong together — and which you told us to ignore, or that two identical lines were one payment imported twice or two real ones — as the merchant's wording and the amount's fingerprint, never the amount, so we do not ask you the same question again. If you tell us a regular line on your statements is not a bill, we keep its wording and when you said so, so we do not suggest it again unless you ask us to look again. We keep a shared list of how banks word merchant names — never who paid or how much: when someone confirms that a statement line is one of their payments, its wording, with dates and reference numbers removed, is added to the list so the same wording is recognised for every household, and because nothing in it is linked to anyone it is not removed when an account is deleted.

Regular incomes. You can also track money that comes IN regularly — a salary, a pension, a regular transfer from someone. We keep the same information as for a payment you make, plus the other names the payer appears under on your statements (so "ACME LTD SALARY" and "BGC ACME WIDGETS" are recognised as one employer), how far below the amount you plan with it may arrive before we ask you about it (a payment that arrives bigger is still that income), which month's budget it counts towards, and — if you added it from a suggestion — whether you chose to plan with the lowest, typical or average of its recent payments or an amount of your own. The payer's name is stored readable, like a merchant's; the amount stays encrypted, and deciding whether this month's salary is within the range you set happens in your browser. When a regular income is matched we record which of your saved incomes it was. We also suggest regular incomes from what has actually arrived: your browser reads the incomes saved to your budgets over the last 12 months, groups them by payer, and lists each payer that has paid you at least twice, with its last six payments and their lowest, typical and average amount. That is worked out in your browser — the amounts are decrypted there and none of those figures is sent to us. A suggestion becomes a regular income only if you add it.

Statement imports flow into the Grocery app. Transactions you import into the Grocery app to match against receipts are held there with the amount in readable (decrypted) form, unlike in the Finance app.

5.2 Fitness app — health data

The Fitness app processes special category data (health data under Article 9 UK GDPR). We process it only with your explicit consent (Article 9(2)(a)), recorded as the consent type Health Data (Fitness & Diet). We ask for it the first time you open the Fitness app, before the app will save anything at all: until you give it, the app stops at the consent step and no fitness record is written. Section 6 explains how consent is recorded and withdrawn. The health data we collect is:

• age, height, weight, gender (including "other" and "prefer not to say");
• activity level, workout preferences, training goal, free-text goal and notes (which may include injury or medical detail you choose to add);
• goal weight, maximum heart rate and how it was set;
• a dated weight log;
• body measurements (waist, chest, arms and similar);
• body and progress photographs — the image files are stored in our object storage, with the caption, file type and size recorded alongside;
• vitals such as resting heart rate;
• daily activity totals — steps, active energy, exercise minutes and stand hours, one record per day — where you connect Apple Health;
• workout sessions, logs, plans, templates, custom workout types, focus tags and AI-coach suggestions;
• the route of a run you record with GPS — your positions along the way, with their times — and the distance, pace, splits, elevation gained and pauses worked out from it (see "Runs you record with GPS" below);
• where you import a workout screenshot: heart rate, heart-rate zones and time in each, calories, duration, distance, pace, elevation, cadence, and exercise sets, reps, loads, tempo and rest as read from the image. The screenshot itself is read and then discarded; we do not store it.

We also record whether a measurement came from you, from a device or from Apple Health, with any external record id.

Apple Health. In the TrackIt Life iOS app you can connect Apple Health to the Fitness app. Nothing is read from Apple Health until you connect it, and when you do, iOS additionally asks you, type by type, what the app may read — you choose what to share. What we read and store, under the same explicit consent as everything else in this section, is: your workouts (with their route and heart-rate samples), your resting heart rate, body weight, body fat, waist and height, and your daily steps, active energy, exercise minutes and stand hours. We use this data only to show you your own history and trends inside the Fitness app. It is never used for advertising, and it is not shared with our AI provider beyond what the separate AI-coach consent in section 7 already covers if you have switched the coach on. Disconnecting Apple Health in the app stops all further reading; what was already imported stays in your account until you delete it, and all of it is deleted with your account (section 10). Separately, the in-browser import of an Apple Health export file remains off unless we have switched it on for your household — where enabled, it stores workout records under this same consent.

Runs you record with GPS. When you record a run with GPS — in the TrackIt Life iOS app, or in a phone's web browser — we collect your location: your positions along the route, with their times, and from them the distance, pace, kilometre splits, elevation gained and any pauses; in the iOS app, also your heart rate if Apple Health has it from your watch. Location is collected only during a run you start, from when you press Start until you finish or discard it — never at any other time. The first time, your phone asks your permission; in the iOS app that permission is "While Using the App" — the app never asks to use your location at other times — and it keeps recording while the screen is locked or the phone is in your pocket, which is what that permission covers for a run you have started. The map on the app's run screen is Apple Maps: to draw it, your phone fetches map images of the area around you from Apple, as any map does — we send Apple nothing, and without signal the map is simply blank while the run keeps recording. In the iOS app the run is first kept on your phone, in the app's own storage, so that it is not lost when there is no signal: it is sent to us when you finish, or as soon as you are back online, and then deleted from the phone. A run you discard is deleted from the phone at once and never sent. If you sign out before a run has been sent, it stays on the phone and is shown only to you when you next sign in. Once it reaches us it is stored with the workout, under the same explicit consent as everything else in this section, and it is deleted when you delete the workout, and with your account (section 10). Apple Health: where you have connected Apple Health, the iOS app also saves a run you record there as a workout, with its route — on your phone, by the app — unless you switch off "Save my workouts to Apple Health" in Fitness → Settings. That copy is then held by Apple Health on your phone and managed there: deleting the workout in TrackIt Life does not delete it from Apple Health.

Strength sessions you log in the app. In the TrackIt Life iOS app a strength session is logged on the app's own gym screen. It records what the Fitness app's live strength screen records: the exercises, and for each set you mark done its weight, reps, type (warm-up, working and so on), effort (RPE) if you give one and the rest you took before it, with any notes you add — no location and no heart rate. Like a run, the session is first kept on your phone, in the app's own storage, so that it is not lost when the gym has no signal: it is sent to us when you finish, or as soon as you are back online, and then deleted from the phone. A session you discard is deleted from the phone at once and never sent. If you sign out before a session has been sent, it stays on the phone and is shown only to you when you next sign in. Once it reaches us it is stored and deleted exactly as any workout is, under the same explicit consent (section 10). Apple Health: where you have connected Apple Health, the app also saves the session there as a strength-training workout — when it started and ended and, only when Apple Health holds your body weight, an estimate of the energy it used, worked out on the phone — unless you switch off "Save my workouts to Apple Health". As for a run, that copy is then held and managed by Apple Health.

5.3 Diet app — health data and religious belief

The Diet app processes special category data for two distinct reasons, and it asks for a separate explicit consent (Article 9(2)(a)) for each. Both are requested in the Diet setup wizard the first time you use the app, and until both are given the app saves nothing.

**Health data — the consent type Health Data (Fitness & Diet).** What makes this health data is the allergies, intolerances and dietary requirements the app records: an allergy or an intolerance is a statement about your body. It is not health data merely because the app notes what you ate.

• allergies and intolerances — a free list, treated as safety-critical;
• for the adult setting up the profile: age, sex, height, weight, goal (lose weight, gain muscle, maintain) and activity level;
• a consumption log: what was eaten, when, meal type, whether you ate out, the merchant name and any notes. This sits under the same consent as the requirements it is planned around;
• meal plans, recipes, dishes, your generation quota and view preferences.

**Religious and dietary requirements — the consent type Dietary & Religious Requirements (Diet).** Dietary requirements such as halal and kosher can reveal religious belief, which is its own special category under Article 9 — not a variety of health data. It gets its own switch so that you are not asked to declare an observance in order to record an allergy, or the reverse. Under it we store:

• your dietary requirements, including halal, kosher and similar observances, and any you record for children or other household members;
• foods you love or avoid, and preferred cuisines, stored alongside them.

We treat these as special category data whether or not your reason for choosing them is religious.

The Grocery app is not covered by either. What it records is purchases — receipts, items, prices, shops — not what anyone ate or what their body requires, so it runs on the ordinary Article 6 bases and needs no Article 9 consent. The one place it touches this data is the grocery household profile, which carries the household's dietary requirements: the analytics files built from it leave that field out for a household that has not given the dietary and religious consent, and withdrawing it removes the file (section 6).

5.4 Children and other household members entered by an adult

The Diet app lets an adult in the household record meal-planning details for children in the household — each child's age, dietary requirements and allergies, with a separate group for toddlers — and for other household members who do not have an account, recording their age, sex, dietary requirements and allergies.

We do not record their names. A person who has no account here has no way to reach us through the app, so we hold as little about them as the meal planner can work with: a position in the household, an age, and the requirements a plan has to respect. There is no name field for them in the apps and our API will not store one.

This information is entered by the adult, not by the child or the other person. A child's age, together with the household's combined dietary requirements and allergies, is sent to our AI provider to generate per-child meal plans (section 7.1). No name is sent, because none is held: a plan is requested for "child 2" or "adult 1".

Children's entries have no lower age limit — an adult can record an infant's requirements, and the meal planner is built to expect that. We do not make any claim that we do not collect children's data: we do, in this specific way. If you enter details about a child or about another adult, you are responsible for being entitled to do so. Those people have the same rights as anyone else (section 11) and can contact us directly.

Account holders must be 16 or over (see the Terms). The Fitness app will not accept a profile age below 16, because a fitness profile belongs to the person logged in.

5.5 Grocery app

• receipt uploads: the file name, type and size, and a content hash used to recognise a re-submitted upload. The image itself is not kept. Your photo or PDF is held in memory, read once by our AI provider (section 7.1), and discarded — it is never written to our object storage;
• the raw text read from the receipt (OCR text);
• merchant name, receipt date, cuisine, country and whether it was groceries, takeaway or shopping;
• each item line: name, quantity, unit, price, promotional or loyalty pricing, category and a confidence score;
• subtotal, total, savings, currency, any exchange-rate conversion and loyalty scheme;
• imported finance transactions (with amounts readable, as noted in 5.1);
• shopping lists, plans, budgets, staples you track, product sightings, category overrides, import records and your grocery profile.

5.6 Website visitors (no account)

If you use our website (trackitlife.app) you may give us:

• contact form: your name, email address, subject and free-text message, with your consent and its timestamp;
• website rights requests: your email address and the type of request, with a hashed confirmation token;
• earlier waitlist sign-ups: the waitlist has closed. If you joined it before it closed, we hold your email address, where you signed up from, your consent and its timestamp, and a hashed verification token, for the periods in section 10.

These records are matched to you by email address only.

Website analytics. The website counts visits with Umami, which we run ourselves. It is cookieless and stores nothing on your device to count a visit; it does not record query strings or the part of an address after a #, and if your browser sends a Do Not Track signal it records nothing at all. Our lawful basis is our legitimate interest in understanding how the website is used (Article 6(1)(f)), so the website shows no cookie banner. You can opt out on the website's Cookies page, which stores a single local-storage key, umami.disabled, in your browser (Cookie Policy section 9).

5.7 Reminders (all apps)

A reminder is a dated note you set for your household — "mortgage fixed rate ends", "card payment due", "order more coffee". We store the title you give it, any free-text notes you add (up to 2,000 characters), which app it relates to, the date and time it is due, your time zone, how often it repeats, whether you have marked it done, and which member of your household created it. Some reminders are generated for you from records you have already entered — a direct debit, a subscription, a card due date, a mortgage fixed-rate or early-repayment-charge end date, a loan promotional-rate end date, or a grocery staple you track. We may also suggest one when a period of a payment you track went wrong: a charge we did not see on your statements ("Check Netflix — not paid this month") or one that arrived at a different price ("Netflix charged a different amount — check the new price"). For a regular income you track, the same two questions read "Salary hasn't arrived yet" and "Salary arrived at a different amount". Neither kind ever includes the amount. Those two say the price is different; they never say what it is, because the figure is encrypted and only your browser can read it. You ask for this; nothing generates reminders on its own, and what it produces is a suggestion you accept or dismiss. Where it happens we keep a reference to the record it came from, and we copy two things out of that record into the reminder: its name and its date. The name is the label you gave it — "Rent", "Car loan" — or your bank's name if you left the label blank. We never read the amounts. The figures in your financial profile are encrypted so that only your browser can read them, and generating a reminder does not use them: no balance, payment, rate or outstanding amount is read, and none appears in a reminder. Generating a reminder collects nothing new about you — everything it uses is information already described in sections 5.1 and 5.5 — but please note that a reminder is visible to your whole household, so a finance record's name becomes visible to every member once a reminder is made from it.

Reminders belong to the household, not to the member who wrote one. Everyone in your household can see every reminder, including its title and its notes, and everyone can edit or delete them. There is no private reminder: if you would not want the other members of your household to read it, do not put it in a reminder. The notes field is free-form, so what it holds is whatever you type — we do not intend it for any category of information beyond what sections 4 and 5 already describe, but nothing stops you entering something else there.

Each member can separately turn off reminder emails reaching them. That is a delivery preference only: muting a reminder stops it emailing you, and changes nothing about what you or anyone else in the household can see.

Reminders are kept until the account is deleted (section 10). They are included in a household owner's data export and removed when the account is erased; because they are household data rather than yours alone, a member's own export does not include them, for the same reason set out in section 3.3.

6. Special category data — how consent works

For the health data in the Fitness and Diet apps, and for the dietary requirements that may reveal religious belief, our lawful basis is your explicit consent under Article 9(2)(a) UK GDPR (with Article 6(1)(a) for the ordinary personal data alongside it).

The two consents. There are two, and they are separate on purpose:

The Fitness app needs the first. The Diet app needs both. Neither is on by default and neither is bundled into signing up: you are asked in the app, on a screen that lists what it covers, before the app saves anything.

How consent is recorded. Every consent decision is written to a consent register as a new entry that records the consent type, whether it was given or withdrawn, the version of the policy in force, how it was collected, the time, and the IP address and browser used. Entries are never edited; a withdrawal is a new entry, and the platform always acts on the most recent one. You can see the full history of your decisions under Privacy Center → Consent History.

How to withdraw, and what happens when you do. Go to Privacy Center → Consent Settings and switch the relevant consent off. Then:

• The app stops accepting new entries immediately. With health consent withdrawn, the Fitness and Diet apps will not save a new workout, weight, measurement, allergy or meal log until you turn it back on. You can still open them, read what is already there, export it and delete it — withdrawal is not a trap door.
• Withdrawal deletes nothing. Everything already stored stays exactly where it is. Withdrawing consent and deleting data are two different things, and deletion is always available to you separately, from Privacy Center → Your Data or by deleting your account (section 10).
• The dashboard copies are cleared. We keep derived copies of some of this data to draw the analytics dashboards. Because keeping those in step is itself continuing to process the data, withdrawing the health consent clears the Diet app's derived copy, and withdrawing the dietary and religious consent clears the household dietary requirements held in the Grocery app's analytics profile. Your own records are untouched, and the copies are rebuilt if you consent again.
• Withdrawal does not affect processing that already happened.

Separate, individually switchable consents also control each AI feature (section 7.1), analytics cookies (Cookie Policy), marketing email, contributions to the shared workout and meal-plan libraries, and the categorisation training set (section 9).

7. Who we share personal data with

We use a small number of processors. Each processes data only on our instructions. No other third party receives your personal data. We do not sell personal data.

7.1 Mistral AI (France) — AI features

Each AI feature is switched off until you turn it on in Privacy Center → Consent Settings. When you use a feature, only the data listed below for that feature is sent. File names you upload are never sent; each upload is given a fixed label instead.

Mistral processes data in the EU (France) under a zero-data-retention agreement: what we send is not kept after the response is returned, and it is not used to train Mistral's models. Their model-improvement programme is switched off on our account. A document or image is handed to Mistral as a file for reading; we delete that file from Mistral as soon as it has been read, and a daily check deletes any that a failed deletion left behind, so none is held there for more than 30 days.

Consent is checked by our servers on every request, not only by the app: if the switch for a feature is off, the request is refused before anything is sent to Mistral, and the app tells you where to turn it on.

Merchant reference data. When merchant research reads a transaction description, or a receipt tells us how a shop is usually categorised, the result — for example, that a merchant is a gym — is added to a merchant reference list shared across the platform, so that the next household to see the same shop does not have to send it anywhere. Each entry records which accounts contributed to it. That means:

• it is included in your data export, like anything else attributed to you;
• when your account is deleted, you are removed from every entry you contributed to, and any entry left with no contributors is deleted with you. A shared entry outlives your account only for as long as another household is still standing behind it;
• entries created before we started recording contributions, and entries our own staff or our starting vocabulary created, belong to no household. They hold no personal data and are not affected by any deletion.

Every AI feature is off until you switch it on, including for our own staff: the maintenance job that re-categorises transactions in bulk checks each household's merchant-research consent before sending anything to Mistral, and skips the households that have not given it; the staff tools that categorise grocery items in bulk send item names only from households that have switched on receipt scanning, and skip the rest.

7.2 Brevo (France) — email only

All email we send goes through Brevo. Brevo sees the recipient address, subject and body of each message. The emails we send are: email verification, password reset, forgotten-username reminders (which contain your username), household invitations (which contain the inviter's email address and the household name), member-removal notices (household name), account suspension and reactivation notices (account name), deletion confirmations, existing-account notices, end-of-beta notices (the date your beta ends), beta extension decisions (whether we have extended your free beta, the date it now ends, and the note we send with the decision), reminder notification emails (the title and notes of each reminder that is coming up, and the date it is due), and website waitlist, contact-form and rights-request emails. One message goes to us rather than to you: when an account holder asks us for more beta time, we email ourselves the account name, the account holder's username, the date the beta ends and anything they wrote with the request — no email address. Brevo receives nothing else.

Two things about the reminder emails specifically, because they carry more of what you have written than any other message we send. They contain no amounts — no balance, payment, rate or outstanding figure appears in one, and the figures in your financial profile are encrypted so that only your browser can read them (section 5.7). And you can stop them: each member turns reminder emails off for themselves, per reminder, and we send them only to household members whose email address has been verified.

7.3 BunnyCDN (Slovenia) — content delivery

All traffic to TrackIt Life passes through Bunny's content delivery network. Bunny therefore sees your IP address, request headers, the URLs you request and the session cookies that travel with them (which are encrypted-transport, HttpOnly cookies — Bunny does not get your password or your vault passphrase). Bunny is established in the EEA and processes your data there.

7.4 OVH (France) — hosting

TrackIt Life runs on a dedicated server provided by OVH in Strasbourg, France. As the hosting provider OVH has physical custody of the servers holding all the data in this policy. OVH also provides DNS for our domains, which involves no personal data — a DNS provider answers questions about our server's address, not about you. Our own supporting services (cache, object storage, analytics, automation, the categorisation model) run on that same server and are not exposed to any third party.

7.5 Hetzner (Germany) — backups

We back up nightly to Hetzner in Germany — a second EU data centre. Each night we copy our main database, which holds everything in sections 4 and 5 (including readable merchant names and allergies), and our two supporting databases. Each copy is encrypted with AES-256 on our own server before it leaves, so what reaches Hetzner is already encrypted, and each is kept for 30 days. Financial amounts remain encrypted inside a backup on top of that, and your vault key is present only in its passphrase-protected form.

7.6 Where your data goes

Your data is stored in France (OVH) with backups in a second EU data centre (Hetzner, Germany), and is processed by Mistral (France), Brevo (France) and Bunny (Slovenia). Every processor we use is in the EEA. Transfers from the UK to the EEA are covered by the UK's adequacy regulations for the EEA, so no additional transfer safeguard — no IDTA, no Standard Contractual Clauses — is needed for any of them.

We do not use any processor in the United States.

TrackIt Life is run by A&C Digital Ltd, a company registered in England and Wales (section 1). Your data itself is held and processed in the EEA as described above.

8. Data we generate about you

To run and secure the service we also create records about your use of it:

• Activity log — what you did and when, with your IP address, browser and a device identifier. You can see your own activity log in Privacy Center → Activity Log.
• Security event log — login failures, suspicious token use and similar, with username, email, IP address, browser, device identifier and the request path.
• Staff audit log — every action our operators take that touches an account, including opening its detail page.
• AI parse logs and categorisation samples — see 5.1 and section 9.
• Rights-request records — each access, deletion, rectification, restriction or objection request, with an identity snapshot, IP address and browser.
• Erasure evidence — after an account is deleted, a record of opaque ids, timestamps and how many records were removed from each collection. It contains no name, email, IP address or username.

Our server logs are redacted before writing to strip fields such as age, weight, height, amounts, balances, income, passwords, tokens and keys. They are rotated daily and retained for 14 days.

9. AI and machine learning — improving categorisation

If you switch on Improving Transaction Categorisation in Privacy Center → Consent Settings, the text of your transaction descriptions may be used to improve our own transaction-categorisation model, which runs on our own server. The switch is off unless you turn it on, and nothing from a household that has not turned it on enters the training set — the check runs on every entry, including the ones our operators add by hand and the bulk maintenance jobs.

When one of our operators reviews a categorisation and confirms it, the description text and its category label are added to a training set. Each entry is tied to your account: it is included in your household export and deleted when your account is deleted. Only the description text and label are stored — never the amount, date, account holder name or sort code.

Turning the switch off stops anything further being added. It does not remove what is already there; use Privacy Center → Your Data, or delete your account, for that.

Where the same description text appears in more than one household it cannot be attributed to a single account. If a deletion request covers such text, we delete it for everyone rather than leave one household's deletion incomplete.

No third party trains a model on your data. Mistral processes your data to return a result and does not use it for training.

10. How long we keep your data

What deletion removes. Deletion removes your account, your users, your household and all of the household's data. That means, in full:

• all of your Finance data — expenses and their line items, imported statement transactions, budgets, categories, templates, reconciliations, import records, savings and recurring payments, the per-period record of each one, what you told us about which payments belong together and when we last matched them, the suggestions you told us are not bills, financial and account profiles, shared reports and insight reports, and the AI parse and usage logs;
• all of your vault key material — the wrapped private key held in your browser's vault, the copy we hold on our server so you can unlock on a new device, and your public key. After a deletion there is nothing left here that could decrypt an encrypted figure, including for us;
• all of your Fitness data, and the fitness files and progress photographs in our object storage;
• all of your Diet and Grocery data, including receipts, lists, plans and profiles;
• the analytics data files derived from your grocery, diet and fitness records;
• your entries in the categorisation training set, and your contributions to the shared merchant reference data (7.1);
• the activity, security and staff-audit logs for the account, and your website waitlist, contact-form and rights-request records;
• household invitations your household sent, and any invitation another household sent to one of your members, and the signup invite code the account was created with.

The deletion checks itself: after it runs, it re-counts every collection it touched, and if anything of yours survived the run is recorded as a failure with the detail rather than reported as a success.

What remains. Pseudonymised consent records (7 years, see above), rights-request records and erasure evidence (6 years each), the user records of former members (see 3.6), and shared merchant reference entries that another household is still standing behind (7.1). Nothing in that list contains your financial figures, your health data or your household's records.

Deletion of the platform's own synthetic training vocabulary, which belongs to no household and contains no personal data, is not affected by any account deletion.

11. Your rights and how to use them

You have the rights below under UK GDPR. Most can be exercised directly in Privacy Center; the rest by emailing privacy@trackitlife.app. We respond within one month of receiving a request. For complex or multiple requests we may extend this by up to two further months, and will tell you if so. Requests are free of charge.

Access and portability (Articles 15 and 20). Privacy Center → Data Rights → Export my data produces a ZIP file containing a JSON file and a README.

• If you are the owner, the export contains the whole household's data (see 3.3), with financial amounts included as ciphertext that only your vault key can decrypt. Progress photo files are not included; their storage references are.
• If you are any other member, the export contains only your own records: your user record, your own membership (role and join date), your fitness profile, plans, records, weight logs, workouts, body measurements, templates and coach suggestions, your consents, your rights-request history, your diet view preferences and your activity log. The file says so.
• Passwords, MFA seeds, recovery codes and reset or verification tokens are stripped from every export.
• Privacy Center also shows a summary of how many records of each kind the household holds.

Rectification (Article 16). You can edit your own records throughout the apps. For a formal correction request, Privacy Center → Data Rights lets you describe the correction; we handle it within one month.

Erasure (Article 17).

• Owner: Privacy Center → Account Actions → Delete account schedules deletion of the whole account 30 days later. You can cancel at any time before then. After 30 days deletion runs automatically. Privacy Center shows the status of a pending request, and of a completed one for 30 days afterwards.
• Other members: the same button submits a request to delete your own user record. Because the only automated deletion removes the whole household, which would destroy other members' data, we action member requests manually within one month.
• Section 10 explains what remains afterwards.

Restriction (Article 18). The owner can suspend the whole account from Privacy Center → Account Actions. A suspended account stops serving data immediately; every member is emailed; the owner can reactivate it. Non-owners who want processing of their own data restricted should contact us.

Objection (Article 21). Submit an objection through Privacy Center → Data Rights, or email us.

Withdraw consent (Article 7(3)). Privacy Center → Consent Settings, at any time. See section 6.

Automated decision-making. We do not make decisions about you that have legal or similarly significant effects by automated means. AI-generated categorisations, insights and meal plans are suggestions you can change or ignore.

Complain to a supervisory authority. You can complain to the Information Commissioner's Office at ico.org.uk or on 0303 123 1113. You do not have to raise your concern with us first — the right to complain is yours and does not depend on anything we do — though we would appreciate the chance to put it right. If you are in the EU or EEA you may complain to your own national data protection authority instead.

Website visitors without an account can request access to or deletion of their waitlist or contact-form data through the website's rights-request form. We send a confirmation email; the request is actioned once you confirm.

Household members and non-users — including other adults or children whose details an owner has entered — can exercise any of these rights by contacting us directly, whether or not they have an account.

12. Marketing and analytics

We only send marketing email if you have opted in, and you can opt out in Privacy Center at any time. Transactional emails (verification, password reset, invitations, security and account notices) are sent regardless because the service needs them.

We use a self-hosted analytics tool (Umami) that runs on our own domain and sends nothing to any third party. It is loaded only if you accept analytics in the cookie banner. See the Cookie Policy. Our website's analytics work differently and are described in section 5.6.

13. How we protect your data

• Financial amounts are encrypted in your browser before being sent to us, using the Paillier cryptosystem. The server stores only ciphertext and never sees a plaintext amount. The private key is generated in your browser and protected by a passphrase you choose. We store only a wrapped (passphrase-encrypted) copy so that you can unlock the vault on a new device; we cannot unwrap it, and if you lose your passphrase we cannot recover your encrypted figures. There is no reset and no back door; that is what makes the design work, and it puts the responsibility on you. Keep your passphrase somewhere safe: it is the only backup. There is nothing separate to export — the wrapped copy we hold is what lets you unlock the vault on another device, and it is useless without your passphrase. (The Vault Backup page in the Finance app's settings does not currently create or restore a backup.) If you lose your passphrase, every encrypted amount is unreadable for good — to you, to us and to anyone else, on every device. Your other records, which are not encrypted this way (see the next point), are unaffected. The wrapping uses AES-GCM-256 with a key derived from your passphrase by PBKDF2-SHA256: 250,000 iterations for the wrapped copy your browser keeps, and 200,000 for the copy we hold on our server so that you can unlock on a new device. The same private key, while it is unlocked in your browser, also keys the account fingerprints and the amount fingerprints described in 5.1 — two separate keys, each derived from it in the browser, held only in memory while the vault is unlocked and never sent to us.
• Where that key sits on your device. So that the Finance app can show you your figures, your private key is held in usable form only in the open tab's session storage, and only while the vault is unlocked: locking the vault, signing out or closing the tab removes it. At rest your browser keeps it only wrapped with your passphrase. Earlier versions of the Finance app could also leave a usable copy in your browser's local storage; signing out removes any such copy, and so does clearing this site's data in your browser. If you used TrackIt on a shared or borrowed device before 24 September 2026 and did not sign out there, clear this site's data on it. The Cookie Policy names the exact storage keys and when each is cleared.
• What that encryption does not cover. Merchant names, dates, categories, bank identifiers, and all fitness, diet and grocery records are stored in readable form so that the features can work. If our database were compromised, an attacker could see spending patterns but not the amounts.
• Passwords are stored as bcrypt hashes. MFA seeds are encrypted at rest with a key kept separate from our signing keys.
• Multi-factor authentication is available to you and mandatory for our staff. Staff use a separate login and session system, and every staff action touching an account is logged.
• Transport encryption (TLS) protects all traffic between you and us. Session cookies are HttpOnly and Secure.
• Cross-site request forgery protection: session cookies are SameSite-restricted and every state-changing request is checked against an allow-list of our own origins.
• Injection defence: requests containing database operator syntax are rejected before they reach any handler.
• Rate limiting on login, password reset, signup and account changes, backed by Redis, with backoff on repeated failures.
• Session-theft detection: refresh tokens rotate on every use; a replayed token revokes the whole session, for the attacker and the legitimate user alike.
• Device sessions (iOS app sign-in): if you turn on Face ID sign-in in our iOS app, your phone keeps a long-lived sign-in token in its own secure storage (the iPhone Keychain, released only by Face ID) and we keep a record of that device session — a one-way hash of the token (never the token itself), the device name you gave it, an install identifier, and when it was created and last used. The token is replaced on every use, expires 30 days after it was last used, and is revoked when you remove the device in Account → Devices, change or reset your password, or are removed from your household.
• Security alerting: automated rules check every minute for login failures, token failures, forbidden requests, unusual staff activity, replayed tokens and unusual deletion volume, and notify us.
• Database access uses least-privilege accounts. Supporting services are bound to the server's loopback interface and are not reachable from the internet.
• Log redaction strips sensitive fields before they are written.
• Backups: nightly, encrypted at rest with AES-256, copied to a second EU data centre, retained 30 days.

No system is perfectly secure. If we become aware of a personal data breach that is likely to result in a high risk to you, we will tell you without undue delay, and we will notify the ICO within 72 hours where required.

14. What we don't do

• We do not sell personal data or share it with advertisers.
• We do not collect GPS or IP-based location. Receipts record a country, and transaction descriptions supplied by your bank may contain a town name; we do not derive location from them.
• We do not collect biometric data, and nothing in the platform identifies you by a physical characteristic. The progress photographs in the Fitness app (5.2) are image files you upload and we store; we do not process them to recognise a face or a body, and nothing derives a measurement from them.
• We do not collect national identifiers — National Insurance numbers, social security numbers, passport or driving licence numbers. There is no field for one anywhere. The free-text caveat in 5.1 applies here as it does to account numbers: a free-text box holds whatever you type into it.
• We do not store bank account numbers, sort codes or card numbers, or the last digits of any of them. To recognise an account we keep only a keyed fingerprint, derived from your vault key, that we cannot reverse (see 5.1). The mortgage and loan reference boxes are free text, so if you type an account number into one of those we store what you typed (see 5.1).
• We do not train third-party AI models on your data.

15. Changes to this policy

We will publish any change here with a new version number and date, and tell account holders by email or in-app notice before a material change takes effect. The version you accepted is recorded against your account.

16. Contact

A&C Digital Ltd, trading as TrackIt Life 124 City Road, London EC1V 2NX privacy@trackitlife.app Company number 17064862 · ICO registration 00014707883