Privacy policy

Kanjō is a household budgeting service, available at www.kanjo.sg and through the Kanjō iOS app. It is operated by Hanso Pte. Ltd., a company registered in Singapore.

This policy is written from the software, not from a template: everything below describes what the running system actually does. It covers Singapore's PDPA and, because the app ships in German and we expect users in the EU, the GDPR.

Questions, or any request about your data, go to support@kanjo.sg. A person answers; see Support for how long that takes.

The short version

You keep a ledger; we store it. We do not sell your data, we show no advertising, and we use no third-party analytics or tracking. The one disclosure that deserves your attention before anything else: when you scan a receipt or import a bank statement, that file is sent to Mistral's OCR 4 so its contents can be read. That is how the scanning feature works, it is optional, and it is described in full below.

What we collect

Your account

Your email address, and a password stored only as a bcrypt hash — we never hold the password itself. Optionally a display name, username and avatar image. Your base currency, language and timezone, because the timezone decides when a daily reminder actually arrives.

If you use Sign in with Apple we receive the identifier and the email address Apple chooses to share, which may be a private relay address. That works fine and we treat it like any other address. We never see your Apple password.

Your ledger

The service exists to hold this: expenses and income, with amounts, currencies, exchange rates, titles, notes and dates; categories and spending limits; accounts; recurring entries. Every change to an expense also writes an audit row — what changed and who changed it — because a category can be shared and "who edited this" is then a real question.

Location — only if you add it

An expense can carry a place: a name and precise coordinates. This is only ever stored when you tag an expense yourself. We do not track your location, and the app does not ask for location access in the background.

Receipts and statements you upload

Receipt photographs and bank statement files, kept so they stay attached to the expense and can be re-opened. For a scanned receipt we also keep the model's full response, so a bad parse can be looked at again rather than paid for twice.

Technical and security data

Your IP address, in two places: server logs, and the sign-in rate limiter that stops someone guessing at your password. Your browser's user agent, stored against each session so you can recognise your own devices. A session cookie to keep you signed in on the web. If you turn on notifications, a push token from Apple.

We do not use advertising identifiers, tracking pixels, or any third-party analytics product.

Agents you connect

You can connect an outside agent — Claude, or any MCP client — to your Kanjō account. We store a name for the token so you can tell your tokens apart, a short prefix, what the token is allowed to do, when it was last used, and when it expires. We do not store the token itself: you are shown it once, and we keep only a one-way hash, which is why we cannot show it to you again and cannot recover it for you.

What the agent may see is your choice and it is narrow by default. A token can be limited to sending statements, or sending receipts, or reading your spending, or writing it, or reading and reconciling your bank rows — or all of it, if you pick that. Settings → Agents lists every token with what it may do, and revoking one takes effect immediately.

This is the one way your ledger leaves our systems. When you point an agent at your account, what it reads goes wherever that agent sends it. We do not choose that destination, cannot see it, and have no agreement covering it. It is worth being deliberate about which token you create and what you allow it to reach.

Crash and error records

When something breaks on our servers we record it so it can be fixed: the error, where in the code it happened, the address of the page or endpoint, and the parameters of the request that failed. Those parameters are filtered for passwords, tokens and card details before being stored, and long values are cut short — but a request that failed while you were saving an expense may still contain what you were saving.

Because of that, these records are kept for 30 days only, which is the shortest retention period anywhere in Kanjō. They live on our own servers and are not sent to any error-tracking company. If you delete your account, your identifier is removed from them, while the technical record of the fault stays so the bug can still be fixed.

On iOS, crash reports come from Apple — only if you have agreed to share analytics with Apple in your device settings, and they reach us through App Store Connect. We ship no crash-reporting SDK of our own, so nothing about your use of the app is sent anywhere while it is running.

Usage events — our own, and short

We do keep a small record of which things you do, so we can tell whether the product works: that an account was created and verified, that a first category and a first expense were recorded, that receipt scanning, statement import or sharing was used, that a paywall was shown, and that a subscription started. Each row is a name, your account id, a timestamp, and at most a couple of labels such as "apple" or "stripe".

What it deliberately does not contain: no amounts, no merchants, no titles, no category names, no IP address, no device or browser details, and no page views or clickstream of any kind. It records that you scanned a receipt, not what the receipt said.

It runs on our own database — nothing is sent to a third party, and none of it is used for advertising, because we do not advertise. These rows are deleted after 400 days, and immediately if you delete your account. We are telling you about it because "first-party" and "self-hosted" still mean data is being collected.

Receipt and statement scanning, in detail

When you scan a receipt or import a bank statement, the image or file is sent to Mistral (the OCR 4 / Document AI API, in the EU) to be read. The response comes back as merchant, date, total and line items, which the app then shows you for confirmation.

This matters more than the rest of this page, so plainly: a receipt is a photograph of what you bought, where, and when. A bank statement is months of that. Both leave our servers and reach a third party when you use these features.

Mistral's API terms state that data submitted through the paid API is not used to train their models. We have no separate arrangement beyond those published terms. If that is not acceptable to you, the features are optional — every expense can be entered by hand, and nothing is sent anywhere if you do.

Who else is involved

These are the only third parties in the path, taken from the code rather than from a vendor list:

An agent you connect yourself is not in this list, and that is the point: it is not a supplier we chose on your behalf. It is software you pointed at your own data, and the responsibility for where it sends that data sits with you and with whoever runs it.

• Mistral (EU) — receipt images and statement files, as described above.
• Apple (US) — verifying Sign in with Apple, App Store subscriptions, and delivering push notifications.
• Stripe (US/EU) — if you subscribe on the web. Your card details go to Stripe directly and never reach us; we hold only a customer reference and the subscription's status.
• Frankfurter (EU) — currency conversion. It is asked "what was EUR to SGD on this date". It receives no information about you.
• Our own infrastructure — the database, the file storage for your receipts, and the mail server that sends your sign-in links all run on hardware we operate. They are not third parties.

Where your data lives, and leaving Europe

Our servers are in Europe. Hanso Pte. Ltd. is a Singapore company, so if you are in the EU your data is processed by a company outside it, and the receipt scanning described above sends files to the United States.

We rely on the standard contractual clauses in our providers' terms for those transfers. We are telling you this rather than burying it, because a Singapore-operated service is not what most people assume when they see a European server.

Why we are allowed to hold it

For your ledger, your account and your subscription: because we need it to provide the service you asked for — performance of a contract, in GDPR terms, and consent under the PDPA.

For rate-limiting and server logs: our legitimate interest in keeping accounts from being broken into.

For receipt scanning and push notifications: your consent, given by using the feature or enabling the notification, and withdrawable by stopping.

How long we keep it

These are the periods the software actually enforces:

• Sign-in links expire after 15 minutes and work once.
• Email verification links expire after 24 hours.
• A signed-in session lasts 60 days, and is replaced every time it is used. Signing out ends it immediately.
• Ended sessions are deleted 30 days later; expired links are deleted nightly.
• Sign-in throttling forgets an address after 15 minutes.
• Your ledger, receipts and statements are kept until you delete them, or until you delete your account.
• An agent token expires after 90 days unless you choose shorter, and can never be created for longer than a year. Revoking one stops it working immediately.

Three honest caveats. An expense you delete is marked deleted and kept, so that you can restore it and so the audit trail still makes sense — it is removed for good when you delete your account. Our server logs currently have no fixed retention period; they are kept as long as the platform keeps them, and we would rather say so than quote a number we do not enforce. And a revoked or expired agent token stays in your list rather than disappearing, so that the list shows what has existed rather than quietly forgetting — all of them go when you delete your account.

Your rights

Under the PDPA and the GDPR you can ask for access, correction, deletion, portability, and you can object to processing. In practice:

• See it — the app shows you everything it holds.
• Correct it — edit it in the app.
• Take it with you — download a complete copy as a JSON file from Settings, or from /api/v1/auth/export. It contains your account, ledger, categories, accounts, recurring entries, receipts, exchange rates and sharing — everything except credentials. This is not a paid feature.
• Delete it — Settings → delete account removes the account and everything belonging to it, in one transaction. It cannot be undone.
• Object or withdraw consent — stop using receipt scanning, turn off notifications, or delete the account.

If you have shared a category with someone, deleting your account removes the expenses you created in it. The other members keep the category and their own entries, and will see yours disappear. Terms covers this.

For anything you cannot do yourself, write to support@kanjo.sg.

Children

Kanjō is not intended for children under 13, and we do not knowingly collect their data. If you believe a child has created an account, write to us and we will remove it.

Changes, and a limitation worth stating

If this policy changes materially we will say so in the app rather than only changing the date at the top.

This policy was written by the people who built Kanjō, and has not been reviewed by a lawyer. It is meant to be accurate about what the software does rather than to be comprehensive legal cover, and we would rather tell you that than let you assume otherwise. If something here is wrong or unclear, telling us is genuinely useful.