How Vantnod protects financial data and why the audit trail holds
A young product cannot ask for blind trust. This is the actual architecture: where the data lives, who can change what, and what stays switched off until it is safe.
The database lives in Frankfurt with point-in-time recovery, access is enforced row by row in the database itself, every money decision is server-stamped, and risky integrations stay off until they are real. The security model, without theater.
The question, stated plainly
Why should I trust a young product with my books? Founders ask us this directly, and accountants ask it more sharply. It is the right question, and it deserves a concrete answer rather than a page of badges.
Vantnod is built and operated by Impact Node Oy in Espoo, Finland. We cannot point to decades of history, so we point to architecture: where the data lives, what the database itself enforces, how history is written, and which capabilities stay switched off until they are safe. Everything below describes the product as it runs in production today.
One ground rule shapes all of it: there are no fabricated numbers anywhere in the product. Every figure traces back to a source entry, and example data is always labeled as example data. What we say about security has to meet the same bar.
Where the data lives
Your accounting data resides in the EU. The database runs in Frankfurt (eu-central-1) on managed, encrypted infrastructure, and all traffic is protected with TLS.
Backups run daily, and point-in-time recovery means the database can be restored to a specific moment, not just to last night's copy. In accounting that matters: the difference between losing zero minutes and losing a full day of entries is the difference between an inconvenience and a real problem.
We are not waving a compliance badge here. Data residency in the EU and these design choices support European privacy expectations, and we would rather describe the mechanisms than claim a stamp.
- 01Database in Frankfurt (eu-central-1), inside the EU.
- 02Daily backups plus point-in-time recovery.
- 03Managed encrypted infrastructure, TLS on every connection.
An audit trail the browser cannot rewrite
Every money-related decision in Vantnod is written server-side: who did it, what changed, and when. The browser never writes history directly and cannot edit it afterwards. Even a compromised or simply buggy client cannot forge the record.
A sent invoice is an immutable version. When something needs fixing, the correction is a new entry that references the old one, exactly how proper bookkeeping has always worked. Fiscal-year closings follow the same discipline: a closed year is not quietly edited but reversed and reclosed through lawful counter-entries.
The practical effect: the question 'who approved this, based on what, and when' has an answer without asking us to read a log you cannot see yourself.
- 01Server-stamped who, what, and when on every money decision.
- 02History cannot be written or edited from a browser.
- 03Sent invoices are immutable versions; corrections are new entries.
- 04Closed fiscal years change only through reverse-and-reclose entries.
Who can do what, enforced where it counts
Access rules are enforced in the database itself, row by row, not only in application code. Even if the application code had a bug, the database would still refuse to hand one company's rows to another company's user. Role-based permissions decide, on top of that, what each person can see and do.
AI has the same limit humans do, only stricter: Noa suggests, a human approves. Nothing files, pays, or posts on its own. The admin control plane is a fully separate surface with its own access layer, and admin identities and role grants live in the database, where they are auditable like everything else.
The browser side is constrained too. Content Security Policy is enforced, not report-only: scripts and network connections are restricted to an explicit allowlist, and the database connection is pinned to the project host.
- 01Row-level security in the database, company by company.
- 02Noa suggests, a human approves. Nothing posts alone.
- 03Separate admin plane, with admin identity and role grants stored in the database.
- 04Enforced CSP with an explicit allowlist, database connection pinned to the project host.
What we deliberately do not do yet
Two capabilities are visibly missing, on purpose. VAT filing to the tax authority is built and tested, 31 of 31 endpoints, and still not enabled in production. Filing someone else's taxes is not a feature you quietly trial in production. It stays off until the entire chain around it is provably solid.
Bank connections are coming through a PSD2-licensed aggregator, Enable Banking. Until a connection is real, the product shows no connected bank. When they arrive, your online-banking credentials stay with the bank and the aggregator. Vantnod never sees them.
Restraint is a security feature. A product that ships every integration the moment it compiles is asking you to absorb its risk. We would rather show an honest 'not yet' than a checkbox that quietly does less than it claims.