Privacy

Who is responsible

Controller

To be supplied: legal name and address — same as the Imprint

Contact for data protection

To be supplied: email address

Data protection officer

To be supplied: name, or “not required” — Art. 37 GDPR; likely not required at this size, but decide it explicitly

What is processed

The following is what the system actually holds today. It is accurate as written; extend it when a feature adds a category, and do not shorten it into generalities.

• Account data. The email address an account was invited with, and the identifier issued by the authentication provider. There is no public registration; access is granted from a server-side allow-list.
• Transactions. Everything in an imported bank export: booking date, counterparty, amount and currency, and the account it came from. This is the substance of the service and the most sensitive thing in it.
• Assignments and provenance. Which Space a transaction belongs to, which category it carries, and how it got there — from the import, by a rule, or by hand.
• Participants. Names, initials and optionally an email for the people a Space is shared with. Most participants have no account: they are recorded and split against, and they cannot sign in.
• Receipts. Images uploaded by the account holder and the values extracted from them, including the contents of an Austrian RKSV receipt QR code.
• Technical data. Server request logs, which include an IP address, a client identifier, and a trace identifier.

Who can see it

Every row is scoped to the account that owns it. A transaction is visible to its owner, and to a signed-in user linked to a participant of the Space it has been assigned to — and to nobody else. Assigning a transaction to a shared Space is the act that discloses it; until then, and permanently for anything kept personal, it is visible to one person.

A participant carrying a zero share still sees the transaction: visibility follows membership of a Space, never the size of a share.

Legal basis

• Art. 6(1)(b) — performance of a contract, for everything the service exists to do with an account's own data.
• Art. 6(1)(f) — legitimate interests, for security logging and abuse prevention.
• Art. 6(1)(a) — consent, for To be supplied: anything consent-based, e.g. the notify list.

Cookies

One cookie, and it is not optional: an HttpOnly session cookie set after sign-in, with SameSite=Lax and a maximum lifetime of fourteen days. It is strictly necessary to keep someone signed in, so it needs no consent banner. There is no analytics cookie and no third-party tracker on this site. The authentication token itself is deliberately never written to storage a script can read.

Processors and transfers

The service runs on To be supplied: hosting provider in To be supplied: region, and authentication is handled by To be supplied: auth provider. List every processor and, for each one outside the EEA, the transfer mechanism relied on.

How long it is kept

Imported transactions are never hard-deleted while an account exists — the ledger is auditable history, and a rule that silently removed a row would be unrecoverable. What that means for retention has to be stated concretely:

Ledger data

To be supplied: retention, and what account deletion does

Receipts

To be supplied: retention

Server logs

To be supplied: retention, e.g. 30 days

Your rights

Access, rectification, erasure, restriction, portability and objection under Art. 15–21 GDPR, exercised by writing to the contact above. A complaint can be lodged with the Austrian data protection authority (Datenschutzbehörde), Barichgasse 40–42, 1030 Vienna.

Before publishing this page

• Fill every dashed blank, and delete any row that does not apply.
• Re-read the factual sections against the code. They are accurate as of this writing and they are the part most likely to go stale.
• Add the notify list to “What is processed” and to retention once useEarlyAccess has an endpoint behind it.
• Remove the draft notice at the top of this page.