How we handle your data

Every record you store in Oikome is row-level secured to your account. That isolation is enforced by the database itself, not just by the application — the database will not return another household’s rows, whatever the application asks for. This isolation has been explicitly audited.

When you upload a statement, it is parsed in memory to extract its transactions and then discarded — the file itself is never written to storage. Only the transactions you review and approve are kept.

Oikome never asks for your banking logins. You import from statements you already have, so there are no bank credentials for us to hold.

Your data is encrypted in transit and at rest, and hosted in the EU (Ireland).

We’re a small company, and we treat that as a security feature: a written access policy means your data is never viewed except for a support request you initiate or a security incident — and we’ll always tell you exactly what we can and can’t see, rather than hiding behind compliance badges.

Today our protections are governance and database-level isolation, and we publish our access policy rather than hiding it. We’re building toward application-layer encryption of the most sensitive fields, and — as the team grows — formal separation of duties. We’d rather tell you what’s true now than what sounds good.

Our written access policy permits production user data to be accessed in exactly two situations: a support request you initiate — limited to the minimum data needed to resolve it — or the investigation of a suspected security incident or data-integrity fault. No other browsing, sampling, analysis, or export of identifiable user data is permitted, including for testing or product research; product testing uses demo-seeded accounts only. Every access under either condition is logged: the date, the condition, the user affected, what was accessed, and why. An empty log is the expected state.