The first article in this series made a promise: Moneta does the bookkeeping and the ledger keeps the truth. That promise is only worth anything if the answer to a simpler question is airtight. Who can get at the data? This article is about the three different answers Moneta has, because money data faces three different threats: outsiders, Moneta itself, and the other person in your household.
Threat one: everyone outside the household
The database organizes every row of data under a household, and the household is resolved from your sign-in session on every single request, never from the page or from a parameter the client sends. When the data layer opens a connection, it switches to a restricted database role that can only see rows belonging to the household recorded in that session.
The reason this matters is that it makes cross-household leaks a database-level impossibility rather than an application-level hopefully-not. A bug in one screen cannot show you another family's transactions, because the database itself refuses to return them. There is a test suite dedicated to trying: it fires requests across household boundaries and checks that nothing comes back. The tests are written to be able to fail. Each one flips its guard off and proves the alarm sounds, so a future refactor cannot silently hollow out the protection while the suite stays green.
Three concrete examples of how deep this goes:
- Every transaction is stamped with both the record and the household it belongs to, and references between records are tenant-paired, so a record from another household cannot even be pointed at.
- The database refuses to update, delete, or wipe the transaction and audit tables for any role, including the application's own.
- Authenticated responses are marked never-cache, so no money figure sits in a browser or intermediary cache where it does not belong.
Threat two: Moneta itself
Letting a conversational accountant write to real financial records sounds reckless until you see the leash. Moneta's conversation runs with the same household scope as the member talking to it, so it cannot see past the same privacy walls you cannot. Several actions require a member to approve a card in the chat first, and the approval is recorded on the server. When the action runs, the server reads the stored proposal directly, so what executes is exactly what was approved, even if the wording drifts a moment later.
Moneta never touches arithmetic on your money. All figures are computed by the server from the ledger, and the rule against the accountant doing its own math is enforced at the deepest layer of the product, not asked nicely in a setting. A bad day on the conversation side degrades the chat. It does not corrupt the books.
Even the choice of thinking engine is a security decision that belongs to you. Your household brings its own key and picks its own provider, so your financial conversations do not have to flow through any particular company. The custom provider option refuses internal and local network addresses, so a misconfigured endpoint cannot become a doorway back into the server.
Threat three: the other person in the household
This is the threat every household finance app I know handles badly, and it is the one Moneta treats as a first-class design problem. Two people share books. Two people still have individual purchases.
The household admin sets one of three visibility levels. At the loosest, everything is visible to both. At the strictest, each member sees their own accounts and the shared ones, and a partner's personal spending is simply not there. Not grayed out, not behind a "hidden" chip. Absent, filtered out of the query before the screen is built.
The important property is where the rule lives. It is enforced in the database, not in the app. Curiosity cannot defeat a setting it cannot reach, and there is no admin override that quietly peeks, because the override does not exist. The export feature obeys the same rule, and when visibility is restricted the exported files deliberately leave out who created a transaction, so the file on your laptop leaks no more than the screen did.
Privacy between two people is only real if it survives both of them being admins of their own curiosity.
The audit trail
Every account and transaction event writes an entry to a tamper-proof audit log, in the same database transaction as the change itself. Updates and deletes to the audit log are refused at the database level for every role. If a record exists, the record of how it came to exist exists too, and neither the app, Moneta, nor a curious member can retire the paperwork.
Why I built it this way
None of these ideas are exotic. Paired records, database rules that only let you touch what your household owns, history that cannot be rewritten, approval gates, they are established patterns from regulated systems. The work was applying all of them at once, in a product two ordinary people use on their phones, without turning it into an IT project.
That is the same bar I hold client work to. When I build an automation that touches business records, it gets the same treatment: approvals recorded before execution, history that cannot be rewritten, and access decided by the data layer rather than by the interface. If you have a process where the honest answer to "who can see this data?" is "whoever clicks around", that is fixable. Book a call and let's design the version where the walls are in the foundation.
