Written for someone who has to justify this choice to a partner or an auditor. Everything in the first section is in place today. Everything we have not done yet is in the second section, named plainly rather than left to inference.
Bank connections go through Plaid. You authenticate with your bank inside Plaid's own flow — we never see or store your bank credentials, and we hold no ability to move money. We request transaction data only; the access is read-only. Today that integration runs against Plaid's sandbox while we complete production access, so a live connection is not yet available.
Every connection — browser to app, app to database, app to the accounting engine — is TLS-encrypted. Our database provider encrypts data at rest on its managed infrastructure. Where a connector requires a stored API token, we encrypt it with AES-256-GCM using a key held only in the server environment, and if that key is not configured we refuse to store the token at all rather than keep it in the clear.
Your data lives in Postgres with row-level security enabled on every table that holds it. The policies scope each row to the account that owns it, enforced by the database rather than by application code — a query that forgets to filter still returns nothing that isn't yours.
Rule versions are append-only: editing a rule creates a new version with provenance, and a database trigger blocks UPDATE and DELETE on the old one. Imported source records are write-once — the trigger refuses an edit even from our own service credentials. Postings are insert-only and the database rejects one that carries a failed review or that doesn't balance.
The engine drafts; it never posts. An independent check re-derives each entry and a failed check blocks posting entirely. The posting itself is an explicit action recorded against the person who took it, alongside the rule version that produced the entry. AI is used to help author rules in plain English — never to compute or book a number.
API keys and service credentials are read from the server environment and never reach the client bundle. The browser never talks to a bank, to our accounting engine, or to a model provider directly — every such call is made server-side.
We would rather you learn this here than discover it in diligence.
We are working toward SOC 2 Type II readiness. We have not completed an audit and hold no SOC 2 report today. If your process requires one, we are not there yet — ask us where we are and we will tell you specifically.
The product runs on managed infrastructure (Vercel, Supabase, Railway) on entry-level plans. Backups are those the providers offer by default, and we have not yet completed a documented restore test. Formal backup and disaster-recovery commitments come with the upgrade to paid tiers.
No external penetration test or security audit has been performed. There is no formal incident-response commitment or uptime SLA. We are a small team building in the open about it.
An upload is parsed on our server into rows. We store the parsed transactions, the source record for each one (kept verbatim so a number can always be traced back), the original file in private per-account storage, the rules you approved, and the entries drafted from them.
It is your data. Ask us to delete it and we will, and you can delete an imported period or a saved close yourself from within the product. See the privacy policy for the full list of what is collected and who processes it.
Email abe.kim92@gmail.com. Tell us what you found and how to reproduce it; we will acknowledge you and keep you posted on the fix. We will not pursue action against good-faith research that avoids privacy violations, data destruction, and service disruption.