Privacy Policy

Walletify — a private, non-commercial application. Last updated 15 August 2026.

1. Who runs this application

Alwin Paul operates this application as a private person. It is not a business, and it is not offered to the public. Contact: alwin.paulpv@gmail.com.

2. What the application does

The application reads the operator's own bank accounts and shows the operator a summary of income and expenses. It has exactly one user, who is also the operator.

3. What data it processes

• Bank account identifiers, including the IBAN and the account name.
• Transaction records: date, amount, currency, counterparty name, counterparty IBAN, and the payment reference text.
• Categories and rules that the operator creates.
• Merchant names derived from the transaction records, used to cache a merchant logo on the server.
• For categorisation suggestions: the subject and sender lines of matching invoice emails from the operator's own mailbox, read on the operator's own server with the operator's own credentials. When a subject states no price, the server also reads that message's body, and if needed its PDF invoice, on the same server, to take one number: the amount. That amount is used only to decide which email belongs to which bank transaction. The body, the file and the converted text are discarded at once. None of them is stored, and none is shown in the application.

The bank data feed also provides the account balance. The application stores each balance it receives, together with the moment it was reported, and shows the most recent one beside the account. Every record comes from the operator's own bank statements and the operator's own mailbox. No other person uses the application.

The operator can unlock the application with the fingerprint or face already on the phone. Matching stays on the phone. No fingerprint or face image is sent to the server.

4. Why it processes this data

The single purpose is a personal overview of the operator's own income and expenses. The data is not used for profiling, for advertising, for training a model, or for any other purpose.

5. Legal basis

Article 6(1)(a) GDPR: consent. The operator gives explicit consent to each bank during the authorisation step. The operator can withdraw that consent at any time, in the bank's own interface or by deleting the connection in the application.

6. Who receives the data

• The banks that hold the accounts, as the source of the data.
• Enable Banking Oy, a licensed account information service provider, which transports the data from the banks. See their own privacy notice at enablebanking.com/privacy-policy.
• Anthropic, an AI text service, used in ONE of the three flows below: filing a note. In that flow it is asked first, through the Claude command-line tool on the operator's own subscription, and it receives exactly what MiniMax would receive there and nothing more. When it cannot be reached, or answers unusably, that flow falls back to MiniMax. The categorisation suggestions and the category naming do not use this path. See their notice at anthropic.com/legal/privacy.
• MiniMax, an AI text service — used when the operator sets an API key on the server. It is the service the categorisation suggestions are sent to, the fallback for note filing, and the only service a category name is sent to. There are three such flows. First, categorisation suggestions: the server sends one uncategorised transaction's counterparty text, amount, and date, together with the subject and sender lines of a matching invoice email. Email bodies are never sent to a model, and neither are attachments or anything read out of them: a body or invoice PDF is read on the operator's own server only to match one amount, and the model receives the same three fields — subject, sender, date. Second, filing a note: when the operator types a sentence about one payment, the server sends that sentence as he wrote it, together with that payment's display name, amount, date and direction, and the names of his own categories. The reply is machine-checked: it may name one of his categories, or propose a NEW category name, which is itself checked for length and refused if it carries a digit, a currency sign, or the payee's own words. Third, naming a category's nature: the server sends the CATEGORY NAME the operator typed — no amount, no date, no merchant, no transaction text of any kind — and only for a name the application's own fixed list and its own arithmetic both left undecided. The reply is one of three words: income, expense, or unclear. Each name is sent at most once per ANSWER: once a reply arrives it is kept, including "unclear", and the question is asked again only if the operator renames the category. If the service does not answer at all — a timeout, or an error — nothing is kept, and that name is sent again on a later run. Anthropic is not asked in this flow. With no API key and no Claude tool, nothing reaches any of these services: the summaries are generated on the operator's server, and a note is not filed automatically.
• A logo service (the recommended configuration is Google's public favicon service) — only when the operator sets a fetch URL on the server. The server requests a payee's logo once and keeps the copy. It sends a domain name, and nothing else: never an amount, never an IBAN, never a date, never a transaction. The service can see which domain was asked for, and roughly when.
  The domain comes from one of three places. For a brand on a fixed list written into the code, it is that brand's own domain (for example rewe.de). For a payee that is not on that list, the server reads the payee's name as the bank writes it. If that name already holds a web address, the server uses the address the payee itself wrote. Otherwise the server may build a domain from the payee's name — but only when the name carries a company form such as GmbH, AG, UG or Ltd, which a registered company has and a private person does not. A payee whose name holds neither a web address nor a company form is never sent. Nor is the operator's own name, which the server recognises from his own accounts.
  Each payee is looked up at most once, ever. One request goes out, and the answer is kept whether it was a logo or nothing at all, so the same payee is never asked about again. With no fetch URL set, no logo request leaves the server at all. A payee whose logo is not found keeps the plain letters the application draws for it.

Nobody else receives the data. The phone application talks only to the operator's own server. The application uses no analytics service, no advertising network, and no error reporting service. No artificial intelligence service is called at all only when TWO things are unset on the server: the API key and the Claude tool. The Claude path needs no API key — it uses the operator's own subscription — so removing keys alone does not disable it.

7. Where the data is stored

On a private server operated by the operator, located in Germany. The database is not reachable from the public internet. Transport uses HTTPS only.

8. How long the data is kept

Until the operator deletes it. There is no automatic deletion, because the purpose is a long-term personal record. Deleting the database removes all of it.

9. Rights

The only data subject is the operator, who holds full and direct control over the database. The rights under Articles 15 to 21 GDPR — access, correction, deletion, restriction, portability, and objection — are exercised directly on that database.

10. Changes

This page changes when the application changes. The date at the top always shows the current version.