Pockora
Privacy Policy
Effective date: 21 October 2026
App: Pockora (iOS bundle com.gj11.expensestracker, Android package com.gj11.expensestracker)
This policy explains what data Pockora collects, what stays on your device, what is shared with third parties, and the choices you have. It is written in plain English; if anything is unclear, contact us at the address at the bottom.
TL;DR
- Your expense data — every amount, category, note, recurring rule, budget, and country — is stored locally on your device in SQLite. We never receive it, store it on a server, or share it with anyone. Three narrow exceptions: shared groups (next bullet); the dates of your foreign-currency entries, which we send to fetch the exchange rates for them (section 2B — no other field of the entry goes with them); and a payment-app notification you choose to send us as a sample, which may show that one purchase (below, and section 2, B3).
- Shared groups are opt-in, and their contents do leave your device. If you create or join a shared expense group, that group's expenses, splits, settlements, member names and activity sync through Google Firebase so your co-members can see them. Everything outside a shared group stays local.
- An account is optional. The whole personal side of the app works signed out. Signing in (email + password, Sign in with Apple, or Sign in with Google) is required only for shared groups, and stores your email address and display name so co-members can tell who is who.
- We use Google AdMob for ads. In this release the only ads are optional, rewarded ads you choose to watch — for example to unlock an extra group. Banner and interstitial (full-screen) ads are switched off. AdMob receives standard device signals (IP address, advertising identifier, device model) — never your expense data.
- We use Sentry for crash reports and a diagnostic log of what the app is doing (that an export ran, that a group was shared). It carries technical context and the fact of an action — never your amounts, titles, notes or categories.
- We use Google Firebase Realtime Database (with anonymous authentication) to fetch live currency exchange rates. The request reveals your IP address and the anonymous sign-in id the app creates on first launch — never your expense data.
- Receipt scanning (early access at the time of writing). If you choose to scan a receipt, the one photo or PDF file you pick is sent through our backend to Google's Vertex AI so the items can be read and named in your language. Nothing leaves the device until you pick it. We keep no copy of the file or the result — the items land in the form on your device, and our backend discards the file once the answer is back. Google handles it under its Cloud terms (linked in section 2B); at the time of writing those rule out using it to train its models. We ask before your first scan. The app shows you what is sent and what to leave out, and records on your account that you agreed, which text you agreed to and when; you can withdraw that agreement at any time in Settings → Privacy & ads → AI document scanning, which hides both Scan receipt and Import a statement until you agree again. We do count your scans against your account (how many you have used, how many today), and we keep a technical record of each scan — its duration, how many lines were read, how many tokens were billed — never the photo or what was on it.
- Statement import (early access at the time of writing). If you choose to import a card or bank statement, the one file you pick — a PDF, a photo of a page, or a CSV export — is sent through our backend to Google's Vertex AI so the transactions can be listed. Nothing leaves the device until you pick it. We keep no copy of the file or the result — the rows land on your device for you to review before anything is added to your ledger. While they wait for your review, they stay on your device only: the rows the reader returned (dates, merchant names, amounts) and the choices you made so far are kept in the app's own storage on your phone — beside your ledger, so your device backup (iCloud or Android) includes them exactly as it includes your ledger, and nothing of them reaches us — for up to 7 days, or until you add or discard them, whichever comes first; the file you picked is never kept, on the device or by us. We never ask the model for a card number, an account number, a name, a balance or a credit limit: there is no field for one in what we ask for, and the instruction says so in as many words. The same agreement covers this: we ask once, before your first scan of either kind, and it can be withdrawn in Settings → Privacy & ads → AI document scanning. We do count the import against your scans, and we keep a technical record of it — its duration, how many rows were read, how many tokens were billed — never the file or a single transaction from it.
- Helping Pockora read a payment app (Android, only if you choose to). For a payment app Pockora cannot read yet, you can let it keep one notification of that app as a sample, so we can teach Pockora to read its purchases. Every run of 4 or more digits in it — card numbers, codes, reference numbers — is hidden on your phone before the sample is even saved, and a notification with a one-time code is discarded unread. You see exactly what would be sent, and nothing leaves your phone until you tap Send to Pockora. A sample you send is kept for 90 days, used only for that, and deleted sooner with your account if it was sent from that account (section 2, B3).
- Notifications. Budget alerts and daily spending summaries are scheduled locally by your phone. If you use shared groups, we additionally send push notifications about group activity, which requires storing a device push token against your account. Once a day we also send a silent message that displays nothing: it tells the app that fresh exchange rates have been published so it can pick them up in the background and have them ready before you open it. It carries no personal data, and only devices where you allowed notifications receive it.
- iOS only: personalized ads would require App Tracking Transparency permission. This release never asks for it and never runs the ad-consent form, so the app sends Google no personalization signal and no consent record. What Google serves on that basis is governed by its own defaults and by your device's ad settings, which you control at the OS level (section 4).
- You are in control of exports and backups. When you email a CSV or save a backup file, the file goes wherever you tell it to go. An iCloud backup (iPhone) or a Google Drive backup (Android) goes to your own account, encrypted on your phone first. We are never in the middle.
1. Who we are
The data controller for Pockora is Guy Jovani, trading as Pockora, the publisher of the app. You can reach us at support@pockora.com. Our Terms of Service govern your use of the app; this policy forms part of them.
Pockora is a personal expense-tracking app. What you record for yourself stays on your phone: we never receive your amounts, titles, categories or notes. Two things do use servers — the optional shared-groups feature, which stores that group's data and the account record that identifies you inside it in Google Firebase on our behalf, and a small exchange-rate lookup that sends the dates it needs rates for, and nothing else about those entries.
2. What we collect, why, and where it goes
We split this into three buckets so you can see exactly where each piece of data lives.
A. Data that stays on your device
The following lives only in the SQLite database (or, where a row says so, in small files beside it) inside the app's sandboxed storage on your phone. It is not transmitted to us, AdMob, Sentry, Firebase, or anyone else, with these exceptions: expenses you deliberately put inside a shared group (bucket B below); the backup files you choose to export, and the iCloud or Google Drive backup you choose to make (section 3); on Android, the operating system's own Auto Backup, which can copy app data to your Google account automatically — that is an OS feature, not ours, and you can turn backup off in Android's settings; and the dates (no other field) sent to fetch missing exchange rates, described in bucket B.
| Data | Examples |
|---|---|
| Expense entries | Amount, currency, category, payment method (cash/card), date, note, country |
| Income entries | Amount, currency, source label, date, note |
| Pockets | Names ("Rent", "Thailand 2026"), icons, colors, budgets, recurrence rules |
| Recurring rules and installment plans | Cadence, start/end date, generated entries |
| Custom expense-type presets | Names, icons, colors |
| Settings | Home currency, theme, notification preferences, list defaults, and the email address you last exported to. (Your language is the exception on this row: if you sign in, it is stored with your account so push notifications arrive in the right language.) |
| Groups and people | The groups you create or join (name, emoji, currency, note), their expenses, splits and settlements — for a shared group, a local copy of what syncs to you — and the people you add: their names and avatar colours, your private nicknames for them, and an email address you add for a person, kept on your device to pre-fill their invites |
| Backup metadata | firstLaunchAt install timestamp, adsRemoved entitlement flag (currently always false) |
| Statements awaiting your review (only if you import one) | The rows the reader returned (dates, merchant names, amounts) and the choices you have made so far — kept beside the ledger, in your device backup like it, for up to 7 days or until you add or discard them. The file you picked is not kept. |
| Apple Pay taps (iPhone, only if you set up the Shortcuts automation) | The amount, merchant name and date of a tap, kept on the phone as a draft for you to confirm, and deleted as soon as you save it as an expense or discard it. Drafts are left out of device backups. The card you paid with is never passed to Pockora. |
| Card purchase texts (iPhone, only if you set up the Shortcuts automation) | Your automation hands Pockora the purchase texts (SMS) that match your filter, and nothing else from Messages. The amount, merchant name and date are kept on the phone as a draft until you save or discard it. Drafts are left out of device backups. The text also shows your card's last 4 digits, and card companies send one-time codes by text: Pockora never stores, sends or logs either, and a text with a one-time code is discarded unread. Nothing is uploaded. |
| Google Wallet taps and payment-app payments (Android, only if you turn on Notification access for Pockora) | Pockora reads Google Wallet's notifications, and the purchase or transfer notifications of the payment apps you turn on (Cal, Isracard, Max, Cibus Pluxee, bit), on your phone, and keeps a payment's amount, merchant name — for a bit transfer, the name of the person you paid — and date as a draft until you save or discard it. For Wallet's latest notification it also keeps when it arrived and one word for what came of it (added, not a purchase, no payment found, not saved) — never its text — so the Google Wallet taps settings can show it. Both are left out of device backups and deleted by Erase this phone. Notifications from other apps are ignored and never stored. The notifications also show your card's last 4 digits: Pockora never saves them and they never leave your phone. Payment apps also send one-time codes: Pockora never stores, sends or logs them, and a notification with a one-time code is discarded unread. Nothing is uploaded — unless you choose to send Pockora a sample: if you ask it to help read a payment app it cannot read yet, one notification of that app is kept on your phone, its runs of 4 or more digits already hidden, until you send or discard it (B3). |
| Google Drive backup settings (Android, only if you use it) | The Google account you picked for backups (its email address, which Google gives the app with the access — kept on this phone only, never sent to us), the time of your last backup, this phone's backup key — kept locked by Android's Keystore, so it never leaves the phone in readable form — with the public parts of its locks, and the ids of the passkeys that locked or opened a backup on this phone. Kept in small files beside the database, all of it left out of device backups and phone-to-phone transfers. |
If you delete the app, this data is deleted with it. None of it was ever sent to us, so there is nothing on our side to delete — with the single exception of anything you chose to put in a shared group (bucket B). A Google Drive or iCloud backup you made is in your own account, not ours: it stays there until you remove it (section 3).
B. Data sent to third-party services we use
| Service | When it is contacted | What is sent | What is never sent | Their privacy policy |
|---|---|---|---|---|
| Google AdMob | The AdMob SDK initialises on every app launch (that is what makes an ad available at all); an actual ad request happens only when you choose to watch a rewarded ad — banner and interstitial ads are switched off in this release | IP address, device model and OS version, coarse country, ad-side telemetry (impressions, completions), and the resettable advertising identifier — GAID on Android; on iOS only if you have separately allowed tracking for this app, because this release never asks (see 2C) | Your expense entries, categories, notes, amounts, totals, names, email, account info | policies.google.com/privacy and policies.google.com/technologies/ads |
| Google User Messaging Platform (UMP) | Not presented in this release. The flow that shows the consent form runs only when banner ads are enabled, so in normal use no form appears and no consent string is collected or sent | IP address, your consent choices in the IAB Transparency & Consent Framework format | Your expense data | Same as AdMob above |
| Firebase Authentication | Only if you sign in (required for shared groups, receipt scanning and statement import) | Your email address, or the identifier Apple/Google returns for Sign in with Apple / Sign in with Google; an account ID; IP address | Your expense data | firebase.google.com/support/privacy |
| Cloud Firestore (shared groups; also our early-access tester list — section 10) | For groups you create or join; and, when you are signed in with a confirmed email address, each time the app starts (at most once a day after that) to check whether that address is on our early-access tester list | For the tester-list check: your signed-in email address, which can read your own entry only. For groups: that group's name, emoji, currency, archive state, an optional group note and its per-group notification scope; each shared expense's title, amount, currency, date, category, country, exchange rate, split mode and free-text note, plus any itemised lines on it (item name, price, who it is assigned to); who paid and who owes what; settlements and their notes; each member's display name, avatar colour and email; and an append-only activity log that records the before-and-after values of edited entries, including a full snapshot of the entry as it was. If you invite someone, the invite the group's members can see holds only a masked form of the address you sent it to (for example y•••@gmail.com); the full address is kept in a separate record that only our server code can read, until the invite is purged, 30 days after it expires — accepted or not (your own phone keeps the copy you typed). A join request holds the requester's name and verified email. The group also keeps its owner's choice of who can invite people (every member, or only the owner) | Anything outside a shared group — your personal expenses, budgets, notes and categories never touch it | Same as above |
| Cloud Functions | On group events (sending, listing or opening an invite, requesting or approving a join, creating or revoking a share link, unlocking an extra member slot after you watch a rewarded ad, leaving, deleting your account) — some of these run before you sign in, when you tap an invite link | The group and account identifiers involved in that event, and — for an invite — the invitee's email address; opening an invite link sends the link token, your IP and an app-attestation token | The contents of your expenses | Same as above |
| Cloud Functions — exchange-rate backfill | When a foreign-currency entry of yours has no stored rate for its date, or when you type such a date into a form | The list of dates we need rates for — no amount, title, category, currency or note. Those dates are derived from your own entries, so this is the one case where something computed from your personal data leaves the device outside a shared group, and like every call to our backend it carries your IP, an app-attestation token and, if you are signed in, your account's sign-in token — so those dates are attributable to your account | Your amounts, titles, categories, notes | Same as above |
| Cloud Functions — receipt scanning, forwarding to Google Vertex AI (Gemini) | Only when you tap Scan receipt on an expense and pick a photo or a PDF file — from the camera, your photo library, or your files. Nothing is read or sent before that choice, and nothing else in your library or your files is touched | The one photo or PDF file you chose. A photo is downscaled on the device to about 1,500 pixels and re-encoded, which strips its camera and location metadata; a PDF is sent as you picked it, including any document properties it carries (such as its title and author); your app language (so the items come back in it); the currency the expense is entered in; the expense's country, if it has one; and the list of the app's built-in category ids, so one can be suggested. Like every call to our backend it carries your IP, an app-attestation token and your account's sign-in token. The scan is counted against your account (free scans used, scans today), and we keep a technical record of each scan: when, how long it took, how many lines were read, the receipt's language code, and how many tokens were billed | We keep no copy of the file: our backend forwards it and discards it once the answer is back, and the answer itself goes straight to the form on your device. You are asked before the first scan — the app names Vertex AI, says what to leave out, and records your agreement on your account (which text, and when); withdrawing it in Settings → Privacy & ads → AI document scanning hides the feature until you agree again. Google handles it under its Cloud terms — at the time of writing those rule out using customer data to train its models, and whether it holds a request briefly in order to run it is governed by those terms (linked). Your other photos, your other files, your expense data, your name and email never go with it. Leave out anything that shows a card number or other people — the app asks the model to read the receipt, not to judge what else is in frame | cloud.google.com/terms/cloud-privacy-notice and cloud.google.com/vertex-ai/generative-ai/docs/data-governance |
| Cloud Functions — statement import, forwarding to Google Vertex AI (Gemini) | Only when you tap Import a statement on a pocket and pick a file — a PDF or CSV export, a screenshot, or a photo of a printed page. Nothing is read or sent before that choice, and nothing else in your files or your library is touched | The one file you chose. A PDF is sent as you picked it, including any document properties it carries; a CSV is decoded to text on our backend and the text is sent; a photo is downscaled and re-encoded on the device, which strips its camera and location metadata. With it go: your app language (so merchant names come back in it), the currency of the pocket you are importing into, and the list of the app's built-in category ids. Like every call to our backend it carries your IP, an app-attestation token and your account's sign-in token. We ask the model for the transactions only — each row's date, merchant or description, amount, currency, whether it is a purchase, a refund, a payment, a fee, and any installment count — and the request explicitly forbids returning a card number, an account number, a card holder's name, an address, a balance or a credit limit, in any field. The import is counted against your scans, and we keep a technical record of it: when, how long it took, how many pages or lines were read, how many rows came back and of what kinds, and how many tokens were billed | We keep no copy of the file: our backend forwards it and discards it once the answer is back, and the rows go straight to the review screen on your device — nothing is added to your ledger until you tap Add. While they wait for your review they are kept on your device only (the app's own storage, beside your ledger — in your device backup as your ledger is, never with us), for up to 7 days or until you add or discard them; the file itself is not kept. You are asked before the first scan — the same one-off agreement as receipt scanning, recorded on your account and withdrawable in Settings → Privacy & ads → AI document scanning, which hides both features until you agree again. Google handles it under its Cloud terms — at the time of writing those rule out using customer data to train its models, and whether it holds a request briefly in order to run it is governed by those terms (linked). Your other files, your other pockets, your name and email never go with it | cloud.google.com/terms/cloud-privacy-notice and cloud.google.com/vertex-ai/generative-ai/docs/data-governance |
| Cloud Functions — samples you choose to send (Android; see B3) | Only when you tap Send to Pockora on a sample you asked Pockora to capture and have reviewed | That one notification's title and texts — every run of 4 or more digits already hidden on your phone, and hidden again by our backend — its channel name, the payment app's package name and version, and your phone's language. Like every call to our backend it carries your IP, an app-attestation token and your account's sign-in token (the anonymous one the app creates, if you never signed in); the sample is stored with that account's id so we can limit how many one account sends (5 a day, 30 in 90 days), and it is kept for 90 days | Card numbers and one-time codes (a sample that still looks like a one-time code is refused and never stored), the notifications of any other app, your expense data, your name and email | Same as above |
| Firebase Cloud Messaging | Only if you allow notifications, for two things: activity in a shared group you belong to, and the daily silent "new rates published" message (any device that allowed notifications receives that one, signed in or not) | For group activity: a device push token and an identifier the app generates for this install (not a hardware id) stored against your account, plus the contents of the notification itself: group name, who did what, the expense title, and the amount — which you can suppress with Hide amounts in notifications (section 4). For the rates message: the device joins an FCM topic — a broadcast list Google keeps — which registers this device's push token with Google and stores nothing extra on our side; the message is data-only and holds two timestamps (when the rates were published, when the next publication is due), nothing about you, and nothing is displayed | Your personal expense data | Same as above |
| Firebase App Check (App Attest on iOS, Play Integrity on Android) | Every app launch, signed in or not | A device/app attestation token issued by Apple (App Attest, falling back to DeviceCheck) or Google (Play Integrity), proving the request comes from a genuine copy of the app rather than a script. Tokens also refresh in the background while the app runs. Apple and Google see the attestation request | Your expense data, your identity | Same as above |
| Sentry | On crashes and unexpected errors, and as an ongoing diagnostic log while you use the app | Stack trace, OS version, device model, app version, locale, the failing source line; plus diagnostic log lines and product events — that a backup was exported or imported, that a group was shared, that an ad loaded or finished, that a sum didn't reconcile. These carry the fact of an action, counts, and technical context such as a currency code — never your amounts, titles, notes or categories | The amounts, titles, notes, categories, or any contents of your entries — expense fields are deliberately excluded from logs | sentry.io/privacy |
| Google Firebase Realtime Database (read-only, anonymous auth) | Foreground app launches, currency-rate refreshes, and the background refresh that follows the daily silent message above | IP address at the moment of the request, an anonymous Firebase auth UID generated on first launch (if you later sign up with an email address, that same anonymous identity is upgraded in place and becomes your account) | Your expense data, and — until you choose to sign up — your identity | firebase.google.com/support/privacy |
| Google Drive (Android, only if you use the Google Drive backup) | When you tap Back up to Google Drive, Restore from Google Drive or Remove from Google Drive, or a row that changes how the backup is locked or which account it goes to (each ends in a backup, after the same confirm), and — once you have picked an account for it — when Backup & restore opens, to show your last backup's time. Your phone talks to Google directly; nothing passes through us | Access for the Google account you picked, limited to a hidden app folder in your Google Drive (the app cannot see or change any other file there); the encrypted backup (section 3) and two private labels on it — which key sealed it, and short fingerprints of the locks that open it, so your other phones can tell a lock they lack. The file's outer header is readable: when it was made, the app's data version, which key sealed it, and the public parts of its locks (which passkeys or passphrase can open it). Google sees your IP address, as for any request | Your data or the backup key in readable form (the key travels only locked by each passkey or passphrase), your passkey or your passphrase — and nothing of the backup ever reaches us | policies.google.com/privacy |
Pockora's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
We do not use dedicated analytics products such as Mixpanel, Amplitude, Google Analytics, or the Facebook SDK. The closest thing we have is the Sentry diagnostic log described above, which records that certain actions happened (an export, a group share) so we can tell whether a feature is broken. We do not sell your data, and we do not share it with data brokers.
B2. Sending an invite (contacts, WhatsApp, SMS, email)
When you invite someone to a shared group, you choose how to send the link. On iOS you may pick one contact: the system presents its own picker and hands back only the contact you tapped, so the app never asks for contacts permission, never reads your address book, and uploads nothing to us. On Android there is no picker at all — the link goes straight to the system share sheet and you choose the app to send it with. The invite link is then handed to whichever app you chose: WhatsApp (Meta), your SMS app, or your mail app. From that moment the message is in that app's hands and its privacy policy applies. The invitee's address is also stored on our side, where only our server code can read it, until the invite is purged 30 days after it expires; the group's other members see a masked form of it, never the address itself (see the Cloud Firestore row above).
B3. Samples you choose to send (Android)
Pockora reads a payment app's notifications only once it knows how that app words them. For an app it cannot read yet, the taps page shows a Help button beside that app. Tapping it opens a screen that explains the following and asks for your agreement:
- What is kept. Once you agree, Pockora keeps the next notification that app shows on your phone — just that one — as a sample: its title, its texts and its channel name. It is usually a payment notification, so the sample may show that payment as the app wrote it — its amount, the merchant (for a transfer app such as bit, the name of the person paid), often the date — which is exactly what Pockora has to learn to read. Every run of 4 or more digits (card numbers, codes, reference numbers) is replaced with asterisks before the sample is saved on your phone, and a notification that carries a one-time code is discarded unread. Nothing else on your phone is read, and the notifications of other apps are ignored.
- What is sent, and when. You first see exactly what would be sent — with your phone's language and the payment app's version — and nothing leaves your phone until you tap Send to Pockora. Our backend hides the digits again and refuses a sample that still looks like a one-time code.
- Why. Only to learn how that app words a payment, so that a later version of Pockora can read it. A sample is never shared, sold or used for ads.
- How long. A sample you send is deleted automatically 90 days after you send it — or as soon as you delete your account, if it was sent from that account. A sample sent before signing in is tied to the anonymous identity the app created on your phone. If you then create your account on that phone, that identity becomes your account, so deleting the account takes the sample too; if you instead sign in to an account you already had, the sample stays with the anonymous identity, which no account deletion reaches: it goes at the 90 days, or sooner if you email us the app and the day you sent it.
- How to stop. Tap Stop on the taps page while Pockora waits for a notification, or Discard once it has one — a discarded sample is deleted from your phone. Turning off Notification access for Pockora stops it too, and Erase this phone removes a sample you have not sent.
C. Data the operating system handles for us
These are not collected by Pockora — your phone's OS controls them — but we mention them so the picture is complete:
- App Tracking Transparency (iOS only). This release does not present the ATT prompt — the flow that would trigger it runs only when banner ads are enabled. So no tracking permission is requested by us. On iOS that means AdMob sees an advertising identifier only if you have already allowed tracking for this app at the OS level; otherwise it does not. Whatever you have already set at Settings → Privacy & Security → Tracking continues to apply, and you can change it there at any time.
- Location (optional, foreground only). If you grant location permission, the app reverse-geocodes your country only to put your local currency at the top of the coin picker. We never store coordinates, never run in the background, and never send location data to our own servers or to any advertiser. The country lookup itself is performed by the operating system's geocoder — Apple's on iOS, Google's on Android. Denying the permission has no functional impact other than the currency picker not auto-prioritizing your country.
- Biometrics / passcode (optional). If you choose to hide transactions behind Face ID, Touch ID or your device passcode, the app asks the operating system to verify you. The OS returns only pass or fail — we never see your face, fingerprint or passcode.
- Passkeys (Android, for the Google Drive backup). When you lock your Google Drive backup with a passkey, Android's own sheet saves it in your password manager — Google Password Manager, Samsung Pass or another you use — under a name that says what it is, with your phone's name and the month, so you can tell it apart from others. The password manager keeps and syncs it under its own terms. Each time you use it, it gives the app a secret that only that passkey can produce, on your phone, to lock or open the backup; the passkey itself never reaches Pockora, and nothing of it reaches us.
- Notifications. Budget threshold alerts and daily spending summaries are local: scheduled and rendered by your phone, never pushed from a server. Shared groups are the exception — activity in a group you belong to (a new expense, an invite, a join request approved) is delivered as a push notification through Firebase Cloud Messaging, which requires us to store a device push token against your account. The second exception is invisible: once a day, after the exchange-rate feed publishes, we broadcast a silent message so the app can fetch the new rates in the background — nothing is shown, nothing about you is sent, and nothing is stored on our side. Revoking notification permission stops both; deleting your account deletes the stored tokens.
D. Our website (pockora.com)
Invite and group links point at pockora.com, and this policy is published there. If someone opens one of those links, our web host receives the request the way any web server does — the IP address, the browser's user-agent, and the link token in the URL — and messaging apps that show a link preview fetch the page too. The pages are static: they load no analytics, no third-party fonts or scripts, and set no cookies. The app itself also fetches one file from pockora.com, about once a day and when you open its taps page: the signed list of payment apps (Android) and card companies' purchase texts (iPhone) it can read, and how to read them, so a newly supported one needs no app update. That request carries what any web request does — the IP address and the app's user-agent — and nothing about you, your phone's notifications or texts, or your expenses.
E. Emails you send us
If you email support@pockora.com — for example to ask us to read your card's app or your card company's purchase texts, which the taps page invites you to do — we receive your email address and whatever you write. We use it only to answer you, keep it in our support mailbox, and delete it when you ask. The app never sends an email for you: the row on the taps page opens your own mail app with a short template to fill in (lines for the app's or company's name and your country — nothing is filled in for you), or shows our address if the phone has no mail app; nothing reaches us until you send it.
3. What you do with your own data
When you use the export or backup features in the app, you decide where the data goes. We never receive a copy.
- Email export (CSV). Tapping "Send via email" opens your phone's mail composer with a CSV attached and a recipient you typed yourself. We do not see the email or its contents.
- File share / backup export (JSON). Tapping "Save / Share file" opens the OS share sheet. Whichever app you pick (Files, Drive, iCloud, AirDrop, etc.) receives the file, and the privacy policy of that destination then applies.
- iCloud backup, iOS only — encrypted. The app can write a backup straight to your own iCloud Drive in one tap. It is never automatic — you tap it, and the app explains what happens before it writes. Before it leaves your phone, the backup is encrypted (AES-256-GCM) with a random key that your phone makes and keeps in your iCloud Keychain, which Apple encrypts end to end and syncs only to the devices signed in to your Apple Account. So the file in your iCloud Drive cannot be read in the Files app, on iCloud.com, by Apple or by us, while Pockora on your own iPhone or iPad opens it with nothing to type. We never receive the key, and the app never reads it outside the one step that seals or opens the backup. There is no fallback: a device that does not have that key (iCloud Keychain turned off, or a new device that has not synced yet) cannot open the backup, and if every copy of the key is lost — for example, when you reset your Apple Account's end-to-end encrypted data — nobody can open it, us included. A backup written by an earlier version of the app is plain JSON until your next iCloud backup replaces it. It goes to your Apple account, not to us, and Apple's privacy policy governs it from there.
- Google Drive backup, Android only — encrypted. The app can write a backup straight to a hidden app folder in your own Google Drive, in the Google account you pick the first time (it need not be the one you sign in to Pockora with). It is never automatic — you tap it, and the app explains what happens before it writes. Its access is limited to that folder: it cannot see or change any other file in your Drive. Before it leaves your phone, the backup is encrypted (AES-256-GCM) with a random key that your phone makes and keeps locked by Android's Keystore. That key is in turn locked by a passkey saved in your password manager (Google Password Manager syncs it to the devices signed in to the same Google Account; Samsung Pass only to Samsung phones), by a recovery passphrase you choose, or by both — on a phone that cannot save a passkey (Android 8 and older, or no password manager that supports it), by a passphrase alone. Any of them opens the backup on another phone (a passkey only on Android 9 and newer). Pockora never stores the passphrase or sends it anywhere. We never receive the file, the key, the passkey or the passphrase, and nobody can reset them: if every passkey and passphrase that locks a backup is gone, nobody can open it, us included. The file's outer header — when it was made, the app's data version, which key sealed it, and the public parts of its locks — is not encrypted, so that a phone can tell how to open it. The app keeps one backup there: each one replaces the last, and the app asks Drive to delete its older versions. It counts toward your Google storage. You can delete it in the app (Remove from Google Drive, which also forgets the account on this phone) or on drive.google.com (the gear → Settings → Manage apps → Pockora → Options → Delete hidden app data); uninstalling the app does not delete it. Neither ends the app's access to that folder — you do that in your Google Account, under your connections to third-party apps. It goes to your Google account, not to us, and Google's privacy policy governs it from there.
- What a backup contains. Every backup — shared, or saved to iCloud or Google Drive — holds your personal entries, pockets, categories, budgets, settings and your people book (the names you gave people you split with), and deliberately excludes shared-group data. Treat it accordingly: it names other people.
- Backup files are plain JSON unless you protect them. Each time you save a backup file, you choose. An unencrypted file can be read and edited — treat it as you would a screenshot of your bank account: do not post it publicly, do not share it with anyone you would not show your statements to; the app says so before it is saved. A protected file is sealed with a passphrase you choose, by your phone's own cryptography (AES-256-GCM, its key derived from the passphrase with PBKDF2-SHA256). Pockora never stores the passphrase or sends it anywhere (if your phone's password manager offers to save it, that is your choice): nobody can open the file without it — not us — and nobody can reset it. (iCloud and Google Drive backups are always encrypted, as described above.)
- Restore. Restoring overwrites the in-app data with the contents of the backup you choose; a protected file asks for its passphrase first, an iCloud backup is opened with the key in your iCloud Keychain, and a Google Drive backup with one of its passkeys or recovery passphrases. Nothing about the backup is sent to us.
4. Your choices and controls
| What you can do | Where |
|---|---|
| Reset the AdMob advertising identifier | iOS: Settings → Privacy & Security → Tracking and Settings → Privacy & Security → Apple Advertising → Reset Advertising Identifier. Android: Settings → Privacy → Ads → Reset advertising ID |
| Turn off personalized ads | The in-app switch is not available in this release. We never run the ad-consent form, so the app sends Google no personalization signal and no consent record — but we cannot warrant what Google serves on that basis, so the controls that actually bind are the OS-level ones in the row above. The app's own Personalized ads switch and Reset ad consent row live in Privacy & ads; they appear only where an ad-consent form applies (EU/EEA/UK) and once that form has run — neither is true in this release. |
| Stop push notifications about a shared group | Open the group → Edit group → Mute notifications (or Notification settings to switch off individual categories). Muting covers activity in that group — new expenses, settlements and so on. It does not cover invite and join-request pings about the group; the only control that stops every push is revoking notification permission for Pockora in your phone's system settings. |
| Hide only the amounts inside push notifications | A granular Hide amounts in notifications switch exists, but it currently sits in the app's legacy settings interface, which is not exposed in this release. Until it is, use the controls in the row above. (The Push notifications switch in Settings governs the reminders your phone schedules locally — it does not stop shared-group push.) |
| Stop the daily silent exchange-rate message | Revoke notification permission for Pockora in your phone's system settings. The device leaves the rates broadcast on its next launch, and the app simply fetches rates when you next open it instead — nothing else changes. (The Push notifications switch in Settings governs the reminders your phone schedules locally; it does not stop this message.) |
| Stop sending crash reports | Crash reporting is part of the app's core stability tooling and is on by default. To stop it entirely, uninstall the app — there is no separate toggle today. We are evaluating a toggle for a future release. |
| Delete your account and the data we hold server-side | Settings → Account → Delete account. No app, or cannot sign in? Email support@pockora.com and we delete it within 30 days of confirming the request is yours — the steps are on pockora.com/delete-account. This deletes your account record (email address, device push tokens, preferences, your AI-scanning agreement), any pending invites addressed to you, any join requests and notification samples sent from your account, your place on our early-access tester list, and unlinks you from every shared group — your email address included, in groups you left before too. Some things are deliberately kept: in groups other people are still in, the entries you created and the group's history of changes stay, under your display name marked "(deleted)", so the remaining members' balances stay attributable to a person. The full list is on pockora.com/delete-account and in section 10. |
| Delete the data on your device | Uninstall the app. The local database is removed with it. |
| Delete your Google Drive backup (Android) | In the app: Settings → Backup & restore → Remove from Google Drive — it deletes the backup from your Drive and forgets the account on this phone. Or on drive.google.com: the gear → Settings → Manage apps → Pockora → Options → Delete hidden app data. Uninstalling the app does not delete it, and a backup left in an account you switched away from (Use another Google account) stays there until you delete it in Google Drive. To also end the app's access to that hidden folder, remove Pockora from your Google Account's connections to third-party apps. |
| Keep receipt photos and files on your device | Receipt scanning is optional and starts only when you tap Scan receipt and pick a photo or a PDF file. If you would rather not send one to Google's Vertex AI, type the amount or the items instead — the form works exactly the same by hand. There is nothing to delete on our side afterwards: we keep no copy of the file. |
| Keep your statements on your device | Statement import is optional and starts only when you tap Import a statement on a pocket and pick a file. If you would rather not send one to Google's Vertex AI, add the transactions by hand or scan their receipts — the pocket works exactly the same. There is nothing to delete on our side afterwards: we keep no copy of the file, and no card or account number is ever asked for or received. |
| Stop helping Pockora read a payment app (Android) | On the taps page, tap Stop while Pockora waits for that app's next notification, or Discard on the sample it caught — nothing is sent, and a discarded sample is deleted from your phone. A sample you already sent is deleted automatically after 90 days — or with your account, if it was sent from that account (B3); to have it deleted sooner, email support@pockora.com with the app and the day you sent it. |
| Withdraw your agreement to AI document scanning | Settings → Privacy & ads → AI document scanning → Turn off. Both Scan receipt and Import a statement are hidden until you agree again — the row itself stays, so you can turn it back on from the same place. Nothing already read is affected — a statement already read stays on your device for its 7 days, or until you add or discard it — and there is nothing to delete on our side: we keep no copy of any file you scanned. |
| Leave a shared group | Open the group → Edit group → leave. Two limits apply: you cannot leave while you still owe or are owed money in that group (settle up first), and if you own the group and are the last person left, the action becomes Delete group instead. Expenses you already shared stay with the group, because the other members' balances depend on them. |
| Withdraw consent for personalized ads (EU/EEA/UK) | Same as "Turn off personalized ads" above. Withdrawal applies prospectively — past ad impressions cannot be un-served. |
| Request access, correction, or deletion of personal data we hold (GDPR / UK GDPR / Israeli PPL / CCPA) | Email support@pockora.com. If you have never signed in, we hold nothing linked to you and will say so — except a sample you chose to send us (B3), which is tied only to the anonymous identity the app created and which we delete on request (tell us the app and the day), any email you sent us (E), our servers' logs of the app's requests, deleted after 30 days, and your place on our early-access tester list if we asked you to try features early (section 10). If you use shared groups, we hold your account record and the group data you and your co-members created; we answer within 30 days. |
5. Legal basis for processing (EU / EEA / UK users)
Where the GDPR or UK GDPR applies, the legal bases we rely on are:
- Consent (Art. 6(1)(a)) — relied on for AI document scanning (receipt scanning and statement import). You are asked in the app before your first scan, in plain words and at the point of use; the agreement is recorded on your account (which version of the text, and when) and can be withdrawn at any time in Settings → Privacy & ads → AI document scanning, which hides both features until it is given again. Withdrawal applies prospectively — a file already read cannot be un-read, though we kept no copy of it. Consent is also the basis for the notification samples you choose to send (Android, section 2, B3): the app asks before it keeps one, shows you exactly what would be sent, and sends nothing until you tap Send to Pockora. Consent is also reserved for personalized advertising via AdMob, recorded through the UMP consent form, and is not relied on for that in this release: that form is never presented, so no ad consent is collected and no advertising processing depends on it.
- Contract performance (Art. 6(1)(b)) — for the optional account and shared-groups feature. You ask us to share a group's expenses with the people you invited; we cannot deliver that without processing the group's data and your display name and email.
- Legitimate interests (Art. 6(1)(f)) — for running the free, ad-supported tier of the app (in this release: the optional rewarded ads, requested without any personalization signal from us), for crash reporting (keeping the app stable), for our early-access tester list (offering unfinished features to the people we asked to try them, section 10), for fetching exchange rates (delivering the multi-currency feature you opened the app for), and for answering an email you send us (section 2, E). You can object at any time using the contacts and toggles above.
We do not process special-category data.
6. CCPA / CPRA notice (California users)
We do not "sell" personal information for money. Under CCPA's broad definition, sharing data with AdMob for personalized advertising can count as "sharing" of personal information. In this release the app collects and transmits no personalization signal and no consent record. We cannot warrant how Google treats an ad request on that basis, so the control that actually binds is at the OS level: limit or reset your advertising identifier (iOS Settings → Privacy & Security → Tracking and Apple Advertising; Android Settings → Privacy → Ads), which is the live Do-Not-Share control. If a future release enables personalized ads, the in-app Personalized ads switch becomes available and acts as the in-app opt-out.
You also have the right to know, delete, correct, and to non-discrimination. If you have never signed in, we hold no personal information linked to you — apart from a sample you chose to send us (section 2, B3), any email you sent us (section 2, E), our servers' 30-day logs and your place on our early-access tester list if we asked you to try features early (section 10) — and a "right to know" request is answered with those alone, or "nothing to provide." If you use shared groups, we hold your account record and that group's data — see section 4 for how to request or delete it.
7. Israeli PPL notice
Pockora is offered in Hebrew and used in Israel. Under the Privacy Protection Law (חוק הגנת הפרטיות, התשמ"א-1981) you have the right to inspect and correct any personal data we hold about you. If you have never signed in we hold none, apart from a sample you chose to send us (section 2, B3), any email you sent us (section 2, E), our servers' 30-day logs and your place on our early-access tester list if we asked you to try features early (section 10); if you use shared groups we hold your account record and that group's data. Data subject requests can be addressed to support@pockora.com.
8. International data transfers
The third parties named in section 2 (Google, Sentry) operate globally and may process data in the United States and other countries outside the EU/EEA, UK, or Israel. Where required, transfers rely on the European Commission's Standard Contractual Clauses (SCCs) as published and accepted by these providers, plus any supplementary measures they describe in their own policies.
9. Children
Pockora is not directed at children under 13 (under 16 in the EU/EEA/UK) and we do not knowingly collect personal data from children. If you are a parent or guardian and believe your child has provided us with personal data, contact us at support@pockora.com and we will help — though, as explained, we typically have no data on our side to remove.
We have not declared a child-directed audience in the App Store or Play Store. We do not set AdMob's child-directed or under-age-of-consent flags, so our requests carry no such tag.
10. Data retention
- On your device. Data lives until you delete it — per entry, or by uninstalling the app.
- Your iCloud or Google Drive backup. In your own account until you remove it (section 3) — we hold no copy.
- Shared groups (Cloud Firestore). A group's data lives as long as the group does. Deleting your account removes your account record, your email (in groups you left before too), your push tokens and your group memberships; the expenses you contributed and the group's history of changes remain with the group (the remaining members' balances are computed from them) and your display name is retained on them, marked "(deleted)", so those balances stay attributable to a person. When the last member leaves, the group is deleted outright; when an owner deletes a group that still has members, it is marked deleted immediately and permanently purged 30 days later.
- Other server-side windows. Invites, accepted or not, are purged 30 days after they expire, and shareable group links 30 days after they are revoked; join requests after 60 days; unused device push tokens after 60 days; a notification sample you chose to send (Android) 90 days after you sent it, or with your account.
- Emails you send us. Kept in our support mailbox to answer you, and deleted when you ask (section 2, E).
- AdMob. Per Google's published retention policy at the link in section 2.
- Early-access tester list. If we asked you to try features before everyone else, your email address is on our tester list (Cloud Firestore), with the features you may try, so the app can offer them to you. We add it by hand; it is deleted with your account (when your sign-in confirms that address), or whenever you ask.
- Server logs. Our backend's operational logs (Google Cloud Logging) can carry your account's id and the IP address a request came from, for troubleshooting; they are deleted after 30 days.
- Sentry. Crash events are retained for 90 days by default and then automatically deleted, per Sentry's policy.
- Firebase Realtime Database. Anonymous auth records and rate-fetch logs follow Google's standard retention. We do not store any user data in this database — we read pre-published exchange rates and write nothing.
Apart from the account and shared-group records described above, we hold no separate database of users.
11. Security
- Your local data sits inside the app's sandboxed storage and is protected by your device's native at-rest encryption (Data Protection on iOS, file-based encryption on Android).
- All network requests we initiate (AdMob, UMP, Sentry, Firebase) are made over HTTPS/TLS.
- Shared-group data is protected by server-side security rules: a group's expenses, members and settlements can only be read or written by accounts that are members of that group, and membership itself is enforced on the server rather than by the app. One deliberate exception: anyone holding a share link can see a preview — the group's name, how many members it has, the display name of whoever created the link, and whether you have already asked to join; a personal invite shows less, just the group name and who invited you — because that is what makes an invitation meaningful. The preview never exposes the roster, the members' email addresses, or any expense.
- We do not implement extra in-app encryption on top of the OS layer for the local database. If you want defense in depth, enable a device passcode and biometric unlock — these are the primary controls keeping your local data private.
No system is perfectly secure. We will not promise "bank-grade encryption" because, like every honest claim about security, the reality is that the OS does the heavy lifting and we rely on it.
12. Changes to this policy
When this policy changes substantively (new third-party SDK, new data collected, change in legal basis), we will:
- Bump the Effective date at the top.
- Update the "Updated [month year]" line at the bottom of the Privacy & ads settings card in the app.
- For material changes, tell you in the app. (No in-app policy-change notice is built yet — this is a commitment for when one ships, not a description of today.)
For minor edits (typos, restructuring, clearer wording without expanding what we do), we update the date and leave it at that.
13. Contact
Questions, requests, or complaints about your data go to support@pockora.com. If we cannot resolve a concern, you may contact your local data-protection authority — for EU/EEA residents that is your member-state DPA; for UK residents the Information Commissioner's Office (ICO); for Israeli residents the Privacy Protection Authority (הרשות להגנת הפרטיות).
Pockora is a personal-finance app. We try to keep this policy as boring as the rest of the app: nothing surprising, nothing oversold, and nothing that contradicts what the in-app screens already tell you.
← Back to home