Privacy Policy
Version 1.8 · Effective from 1 October 2026
This policy explains what personal data the FinLad app and the finlad.site website process, for what purpose, on what legal basis and for how long they are kept. The data controller is FOP Itsekson Oleksii Volodymyrovych.
It is written to be read. If any part seems unclear, write to us through the contact form on the site and we will make the wording plainer.
1. Who processes your data
Controller: FOP Itsekson Oleksii Volodymyrovych, Ukraine. You can reach us through the contact form at finlad.site — that is the main channel for any question about this policy or your rights.
Processing follows the General Data Protection Regulation (GDPR, EU 2016/679) and the Law of Ukraine "On Personal Data Protection" No. 2297-VI.
2. What data we process
| Category | What exactly | Where it comes from |
|---|---|---|
| Account data | Google or Apple identifier, email address — through Apple this is usually an anonymous relay address (@privaterelay.appleid.com) rather than your own — interface language | From you when signing in with Google or Apple |
| Financial records | Transactions, accounts, categories, budgets, goals, utility services and readings, assets, investments. Amounts, balances and names are stored on the server encrypted end to end; the description, the merchant and the category name stay readable — that is what files your spending (section 11) | You create them in the app or import them |
| Bank access | Monobank access token (stored encrypted), imported statements | You add the token yourself; you upload the statement yourself |
| Receipt and document images | The photo you take for recognition — stored encrypted end to end (section 11) | Device camera, by your action |
| Technical data | Session and device records, server request logs, crash reports | Generated automatically as you use the app |
| Sign-in log | The date and time of every sign-in, sign-up, failed attempt and sign-out, the sign-in method, the IP address and the kind of app the request came from | Generated automatically when you sign in |
| Messages | Message text, plus name and email if you provide them, and any screenshots you attach (up to three images) | The contact form on the site |
| Family access | Who is in the family and since when, each member’s access level, the name of their device and the name the owner gave them, and which accounts and properties are shared. The family key passes through the server only sealed under the family’s own device keys — we cannot open it | Created when you make a family, join one or share something with it |
The calendar is the one exception that runs the other way. If you turn the setting on, the app adds your recurring payments as events to the device's own calendar. It asks for calendar access, and needs it in full on both systems: an event has to name the calendar it goes into, and removing one means finding it again — neither is possible without being able to look. What the app does with that access is narrow: it creates and removes only its own events, never reads your entries, and sends nothing from your calendar anywhere. Turning the setting off removes every event it created, and deleting a payment removes its event.
What we do not collect: an advertising identifier, your behaviour in other apps, contacts, precise location, or any payment details — payment runs only through the app stores (Google Play, and the App Store on iOS) and we never receive your card numbers.
An account can be created without telling us anything about yourself. The primary way to sign up is a single tap: the app creates a passkey on your device, and what we store is a random account id, a public key, a generated short name such as "FL-7F3A-K2M9", and your tier. No address, no name, no phone number is asked for or received. We will also state the limit of that anonymity plainly: every sign-in to any account goes into the sign-in log together with an IP address (see the row above) — so that you can find out about a sign-in that was not yours, and we can recognise guessing. That address does not name you, but the law treats it as personal data, so we do not hide it inside the general line about technical logs, and we delete it after 90 days. The "Account data" row above applies to people who chose to sign in with Google or, on iOS, with Apple: there we receive the identifier and the address from that account. Apple also lets you hide your real address — we then receive an @privaterelay.appleid.com alias and never see yours. That is your choice rather than a condition of use — and you can make it later, or never.
If you give us an email address yourself — in a message through the contact form, for instance — we have no way to verify it, so we do not use it as a way to sign in or to restore access, and we never merge two accounts by it. It stays what you made it: a way to reach you about that message.
If you send a problem report from the app or from the web portal («Report a problem»), your text arrives with the app version and the user-agent string — the same one your browser and the app send with every request — and, read from it, the platform, the operating-system version, the device model and the interface language. In the app that list is shown on the screen before you send and one switch leaves it out; in the web portal it travels with the report, and the form says so plainly. You may attach screenshots (up to three); they are stored with the message and deleted with it. If you were signed in at the time, the message is linked to your account; we still ask for a name and an address separately and still leave both optional, because an account identifier says who you are and not where to write back. Messages our checks judge to be spam are stored with that mark and never mailed to support; where the checks are undecided the text may be shown to a language model for that judgement (see «How the AI works and what it sees»).
The web portal at app.finlad.site is the same account in a browser rather than a separate service: it creates no new category of data and asks nothing further about you. It keeps less than the phone does, deliberately. The session marker lives in the tab’s own storage and disappears with it, and your financial records are held in the page’s memory by default — close the tab and nothing of them is left in the browser. If you turn on «Remember the ledger in this browser», a copy of the database is written to this computer’s browser storage; the portal asks that as a separate question and explains what it means: a copy in a browser is protected less well than one on a phone, so on a shared or work computer the better answer is no. The choice is yours — nobody makes it for you. An account cannot be created in a browser at all: it is created in the app on a phone, and the browser signs in to one that already exists.
3. Why, and on what legal basis
| Purpose | Legal basis |
|---|---|
| Providing the service itself: storing your financial records, computing budgets and statistics, syncing between your devices | Performance of a contract (Art. 6(1)(b) GDPR) — the Terms of Use you accept at the start |
| Connecting a bank and receiving your transactions automatically | Your explicit consent (Art. 6(1)(a)) — you add the token yourself and can revoke it at any time |
| Receipt recognition and category suggestions using AI | Your consent — the feature is triggered by your action and can be fully disabled with one switch in settings |
| Security, crash diagnostics, abuse prevention | Legitimate interest (Art. 6(1)(f)) — so the service works and does not lose your data |
| Replying to your message | Legitimate interest, and your act of providing the address |
| Anonymous website visit statistics | Legitimate interest — aggregated statistics, no cookies, no profiling |
4. Who we share data with
We do not sell your data and we do not pass it to advertising networks. It reaches only the providers the service cannot run without, and only to the extent their function requires:
| Recipient | What it receives | Why |
|---|---|---|
| Hetzner Online GmbH (Germany) | All server data — it is physically stored on their hardware; also technical request data for finlad.site | Hosting the server, the database and the website itself in the EU |
| Google LLC (Gemini API, USA) | Only the receipt, meter or bill image you sent for recognition, or the line you typed / the description from a statement. No amounts, balances, account names or your identifier | Image recognition, category suggestions and parsing a typed line |
| Anthropic PBC (USA) | The same, on the same terms — but only when the primary provider did not answer | Backup provider, so recognition does not disappear during an outage |
| Google LLC / Google Ireland Ltd | Google sign-in data; data about a purchase you made | Account sign-in, payment via Google Play |
| Apple Inc. / Apple Distribution International Ltd (Ireland) | Apple sign-in data — the identifier and an address that may be an @privaterelay.appleid.com alias; data about a purchase you made | Account sign-in on iOS, payment via the App Store |
| Functional Software, Inc. (Sentry), EU region | Crash reports: error type, stack trace, request route. Request bodies, authorization headers and images are stripped before sending | Fixing errors |
| JSC Universal Bank (Monobank) | Requests carrying your token to fetch your own transactions | Only if you connected the bank |
| Umami Software, Inc. | Anonymous page-view data: page, referrer, device type. It runs on the website finlad.site only. The phone app and the web portal app.finlad.site — the sign-in page included — carry no analytics at all. No cookies and no identifier that could recognize you | Website visit and sign-in statistics |
Family access, if you use it, is not a provider — it is other people. When you create a household and share an account, a property or the household’s plan, everything those records contain becomes readable by every member of it: amounts, balances, names, dates and any photographs attached. We do not choose those people and we cannot take back what they have already read. A member also receives the paid tier for as long as they are in the household. What is shared travels encrypted under a key held by the household’s own devices and not by us. Removing someone replaces that key: whatever is encrypted after that moment is beyond them — but nothing they have already read can be taken back. Leaving the household, or ending it, stops the sharing from that moment on.
Transfers outside the EU concern only the AI features (Google and Anthropic, USA) and Google or Apple sign-in, and take place under the standard contractual clauses of those providers; for users in the EU, the Apple party holding that data is its Irish company. Both model providers are used on their paid tiers, whose terms forbid training models on what is sent. If you switch AI off in settings, no transfer to them happens at all.
5. Where data is stored
The server and database are located in the European Union (Germany). Server backups are encrypted before they are written anywhere they will stay, and are stored in the EU as well; the key that opens them is kept apart from the server, so a copy that falls into the wrong hands along with the server stays unreadable. Receipt images are not retained on the server after recognition — they are processed in transit, and whatever you choose to keep stays in your app.
On the free tier sync is off by design: your financial records stay on your device only and never reach the server at all. The same is available on the paid tier — sync can be switched off in settings at any time, and the app then works locally: new records stay on the device.
The same rule holds in a browser, only stricter: nothing of your records stays there unless you ask for it. While «Remember the ledger in this browser» is off, the ledger lives in the tab’s memory and is gone the moment you close it. When it is on, the copy sits in this computer’s browser storage until you sign out or press «Delete data from this browser» — either action removes both the copy and the key that opens it. None of this changes anything on the server: it holds for a browser what it holds for a phone.
6. How long we keep it
- Account data and financial records — for as long as your account exists. After a deletion request they are kept for a further 7 days so you can change your mind, and are then deleted for good.
- Backups — one each night, kept 14 days on the server and 90 days in off-site storage. Data you deleted ages out of backups as they rotate, which takes at most 90 days.
- Server request logs — a limited technical period needed for diagnostics.
- The sign-in log — 90 days, after which entries are deleted automatically. Deleting your account deletes its log with it.
- Crash reports — per Sentry’s retention periods.
- Contact form messages and problem reports from the app, together with any screenshots and the device facts attached to them — until the conversation is finished, plus a reasonable period after. Screenshots and device facts are deleted with the message they belong to, never separately.
7. Your rights
You have the right of access, rectification, erasure, restriction of processing, objection, and data portability. Here is how to exercise them:
- Rectification — directly in the app: every record is yours to edit.
- Erasure — the "Delete account and all data" button in settings. This device’s copy is wiped at once and for good, every session ends, and the bank connection is disconnected. The data on the server is deleted after 7 days: throughout that time you can sign in and cancel the deletion — or finish it straight away without waiting. What comes back is the server copy; if your plan has no sync there is none, so there would be nothing to bring back. Once the window has passed we deliberately keep no shadow copy, so data cannot be restored. If you no longer have the app, send a request at finlad.site/delete-account and we will carry it out within 30 days.
- Access and portability — in the app: More → Data → Export data. Transactions download as a CSV sheet, and everything as a JSON file in a machine-readable format. Receipt photos are only listed in the JSON, because embedding them would make a file hundreds of megabytes long — the images themselves come out of the same screen, as their own archive. If you need a copy in some other shape, send a request through the contact form.
- Withdrawing consent — switch AI off in settings or disconnect the bank; this does not affect the lawfulness of processing before withdrawal.
You also have the right to lodge a complaint with a supervisory authority: in Ukraine, the Ukrainian Parliament Commissioner for Human Rights; in the EU, the authority where you live.
8. How the AI works and what it sees
The app calls an external model in exactly three cases: when you send a photo of a receipt, a meter or a bill for recognition; when a transaction description could not be categorized by its own rules; and when a line you typed by hand could not be parsed on the device itself.
- Amounts, dates, balances, your account names and your identifier are never sent.
- A description recognized as naming a person rather than a merchant (a card-to-card transfer, for example) is not sent at all and is left for manual categorization.
- The model’s answer is immediately turned into a local rule, so the same merchant is recognized next time without any outbound call.
- The model providers — Google (Gemini) and, when it is unavailable, Anthropic — are used on their paid tiers: under those terms, what is sent is not used to train the models.
- One switch in settings disables every AI feature. The app remains fully functional afterwards.
9. Cookies and website statistics
This site sets no tracking cookies and shows no consent banner, because it has nothing to ask you about: visit statistics are collected anonymously, without cookies and without identifiers that could recognize you or follow you across other sites. The one cookie it does set is the language you chose, so that the next page you open is in it — a strictly necessary technical setting, which needs no consent under the GDPR.
Everything else kept in your browser is your own settings — the theme you chose (light or dark) in local storage, and the language in the cookie above. Neither is sent anywhere except back to this site, and neither says anything about you.
The web portal at app.finlad.site sets no cookies at all, and carries no analytics on any page, the sign-in page included. What it keeps in browser storage is your settings — theme, language, your answer to the «remember the ledger» question — and it keeps the session marker in the tab’s own storage.
10. Children
The service is not intended for people under 16 and we do not knowingly collect their data. If you believe a child has created an account, write to us and we will delete it.
11. Security
- Connections to the server are HTTPS only.
- Bank tokens and two-factor authentication secrets are stored encrypted.
- Sign-in runs through Google, and on iOS through Apple as well, optionally with a passkey; inside the app you can enable a PIN or biometrics.
- Two-factor authentication (2FA) can be enabled in settings: signing in then needs a one-time code from an authenticator app in addition to your Google or Apple account.
- Crash reports are stripped of request bodies, authorization headers and images before they leave the device or the server.
There are no passwords in this service at all — we do not create them, accept them or store them. There are three ways in: a passkey on your device, Google or Apple sign-in if you chose it, and a recovery code. The app shows the recovery code once, right after sign-up; the server keeps only a one-way hash of it, so the code itself cannot be recovered from what we hold, and the number of attempts to enter it is limited. The code is shown once — at the moment it is created — and never again: no device keeps a readable copy of it. From the settings you can only generate a new one, which retires the old one, or remove the code if Google or Apple is linked to the account; once it is removed that provider can no longer be unlinked, so a way in always remains. The other side of that design we state plainly: if both the passkey and the recovery code are lost, nobody can restore access to the account — including us. That is exactly why the app has a backup that depends on no server.
Images — receipt photos, meter photos, utility bills and asset documents — are encrypted end to end, and it is not a setting anyone has to switch on: images are encrypted on your device under a key that belongs to your account, and they reach the server already encrypted: what is stored there is the encrypted file itself, its type and its size. The server never holds the key in usable form, so neither we as the operator of the service nor anyone with access to the server or the database can look at those images.
The key reaches your other devices in one of two ways: by pairing with a device that is already set up (the key is shown on your own screen and never travels the network), or with a recovery code the app shows once, when the account is created. A copy of the key encrypted under that code may be kept on the server — without the code it does not open. The other side of that design we state plainly: if you lose every device and the recovery code, nobody can bring those images back, ourselves included.
Amounts are encrypted end to end as well, not only images. Every figure that says something about your money — the amount of a transaction, an account balance, a budget, a credit schedule, a goal, an asset valuation, a meter reading and the charge computed from it — is encrypted on your device under your account’s key and reaches the server already encrypted. So is what those figures are called: the name of an account, a credit, a goal, a saving, an asset, an investment with its ticker and broker, a utility service with its provider and account number, a recurring payment, and the notes and tags you write yourself. A name says as much as a number — «mortgage» needs no figure beside it — so it is encrypted along with it. What the server keeps beside them is what it needs to carry the record at all: which account and category a row belongs to, its date, its currency code, and its description and merchant. Those stay readable because the app sorts your spending by them — including the names of your categories, which it uses to file a bank transaction when your phone is not online; everything else does not. Neither we as the operator of the service nor anyone with access to the server or the database can read a balance or work out what you earn and spend.
One code opens both the account and the figures. The app shows it when you set up, and a device that holds the key can show it again at any time — the code itself is stored only encrypted under the key it unlocks, so what the server holds is a blob it cannot open. A new device of yours gets the key in one of three ways: by asking a device you are already signed in on, which approves it behind your phone’s own biometrics and hands the key over encrypted, so the server relays something it cannot read; by scanning a QR code on your own screen; or with the recovery code. The other side of that design we state plainly: if you lose every device and the code, nobody can bring the data back, ourselves included.
What this does not cover: a bank import. When you connect a bank or import a statement, our server reads the amounts in order to match transfers and work out balances, and writes them in the clear; the first of your devices that holds the key encrypts them in place afterwards. Between those two moments those figures are readable on the server. Recognition works the same way and for the same reason (section 8). Encryption also begins only once every device signed in to your account runs a version that can read encrypted records — until then the figures travel readable, so that an older phone of yours cannot silently write a wrong balance.
What the encryption does not cover: when you send a photo for recognition, the frame passes through our server to the external model (section 8) — it is not stored there, but at that moment it is not encrypted under your key.
A browser is weaker than a phone, and we name that rather than work around it. On a phone the encryption key is held by the system’s hardware-backed store (Keystore on Android, Keychain on iOS), and a locked phone does not give it up. A browser has no such store at all: the key sits in the tab’s storage, disappears with the tab, and any code running on that page can read it. That is why the portal never mints a key — it receives one from your phone or from your recovery code — and why signing out removes both the key and any stored copy of the ledger from this browser — your records themselves stay on your phone and on the server. The same follows for our advice: on a shared or work computer, leave «Remember the ledger in this browser» off.
12. Changes to this policy
If the policy changes we will update the version number and date on this page. Material changes — ones that widen processing or add a recipient — will be announced in the app before they take effect.