Built so we can't read your books, not so we won't.

Neo-Capital runs two ways, and they are not equally private. Most companies would quietly apply the stronger claim to both. Here is the difference, stated plainly.

If you want the version where no key ever touches our infrastructure at any moment, that is Desktop with Connected sync, and we would rather tell you that than sell you the wrong tier.

The interesting problem isn't encrypting data. It's signing you in without learning the secret that decrypts it. Neo-Capital solves it the way password managers do, by splitting your password into two independent halves before anything leaves your device.

1. Step 1: on your device

   Your password goes through scrypt, a deliberately slow, memory-hard function, together with a random salt. Slow is the point: it makes guessing passwords expensive for anyone who ever gets hold of the stored data.

2. Step 2: the split

   That result is split by HKDF into two keys that cannot be derived from one another. One unlocks your books. The other is what we receive as your "password" for sign-in purposes.

3. Step 3: what we get

   Only the sign-in half. It is a one-way derivation, so holding it tells us nothing about the half that decrypts anything. Your actual password never travels, is never logged, and is never stored: not hashed, not encrypted, not at all.

Your books themselves are locked with a separate data key, sealed to your account's public key. That indirection is what lets you change your password without re-encrypting every record, and what lets a firm share one set of books with a bookkeeper by sealing the same data key to their key too, never by handing anyone a password.

The password above is strong protection for your data and weak protection for your account: passwords get reused, phished and typed into the wrong box. Two separate controls address that, and they guard different moments.

Two-factor sign-in

Turn it on from your account and signing in also needs a six-digit code from your authenticator app. Standard TOTP: Google Authenticator, 1Password, Aegis, whatever you already use.

What a correct password gets you

With two-factor on: nothing until the code is answered. Not a session, and (this is the part that matters) not your encrypted private key either. That key plus your salt is exactly what someone would want to take away and grind against offline, so it is withheld along with everything else rather than handed over at the first step.

Backup codes

Ten, shown once when you switch it on. Each works a single time in place of a code from your app, so a lost phone is an inconvenience rather than a locked door. They stand in for the second factor only (never for the password), so a leaked sheet of them is still not an account.

Re-entering your password

Changing the things that protect your account (turning two-factor on or off, re-issuing backup codes, deleting the account) asks for your master password again, even though you are already signed in. A session token is something an attacker can end up holding: a shared computer, a laptop left open. Asking for the thing only you know is what stops a borrowed session becoming a locked-out owner.

Turning it off

Needs the password and a current code. Removing the protection is at least as sensitive as adding it, and it is the first thing somebody with a stolen session would try.

The shared secret behind those digits is held by our authentication provider, not in our database and not in your books: one fewer secret in a place we could leak it from.

For Online and for Connected sync. Everything else (every transaction, invoice, balance and note) is inside the ciphertext.

Your books

Encrypted. AES-256-GCM, a fresh random nonce for every single encryption, and authenticated: tampered ciphertext fails to open rather than decrypting to something plausible.

Your public key

Public by design. It is what other people's clients use to seal a shared set of books to you.

Your private key

Stored, but sealed under your password-derived key. We hold the locked box and not the key to it.

A sign-in secret

The one-way half from step 3. Enough to check that you are you; useless for decrypting anything.

A salt, and its version

Public inputs to the slow function above. The version records which parameters your account was created under, so we can strengthen them over time without locking anyone out.

Your email and billing

Ordinary account data, and the only part of this list a human here can read.

A breach of our infrastructure yields that list. Not your books: the encrypted blob, and no key anywhere near it.

If you evaluate software for a living, this is the section you skipped ahead to. No proprietary cryptography, no hand-rolled constructions, nothing invented here.

Symmetric encryption

AES-256-GCM with a fresh 96-bit random nonce per operation. Authenticated encryption throughout: there is no encrypt-without-authenticate path anywhere in the codebase.

Key agreement

X25519, with an ephemeral keypair generated per wrap, so compromising one sealed key does not unravel the others.

Key derivation

scrypt for passwords; HKDF-SHA256 with domain separation for everything derived from a master secret, so two keys derived for two purposes are independent.

Sync integrity

Each synced record is cryptographically bound to its position in the sequence, so a server cannot reorder, replay, or drop records without the client noticing.

Randomness

Cryptographic sources only: for keys, nonces, salts, recovery codes and tokens. No general-purpose random number generator touches anything security-bearing.

Comparisons

Constant-time on every authentication path, so timing cannot be used to guess a secret one byte at a time.

In transit

HTTPS everywhere, certificate-validated, with outbound connections restricted to known hosts and blocked from reaching internal addresses.

Connecting a bank is the moment most people hesitate, and they are right to. Two things make it safe, and both are structural rather than promises.

If you use Get Paid to let customers pay an invoice by card, the card fields on that page belong to Stripe, rendered by Stripe's own code, submitted directly to Stripe. Card numbers do not pass through our servers, appear in our logs, or exist anywhere in our code. The money moves between your customer and your own Stripe or Square account. We are not in the middle of it.

Every message Stripe sends us is cryptographically signed and verified against the exact bytes received before anything is recorded, and each payment is recorded idempotently, so a duplicate or replayed notification cannot mark an invoice paid twice. Nobody can cause a payment to appear in your books without an actual signed message from Stripe.

Every posting, edit, reversal and void is written to a history that the application cannot rewrite: the database itself refuses updates and deletions on it. Each entry is cryptographically linked to the one before it, so removing or altering a row breaks the chain. The whole chain is re-verified every time you open the audit page, and a break is reported loudly rather than quietly.

Access events, connector changes and exports are recorded in the same trail, not a separate one, so "a copy of this book left the building" is a line in the same history as the journal entries.

An assistant with write access to a general ledger is a genuinely risky idea, so it is built to be structurally limited rather than well-behaved.

Nothing changes without a click

Every change the assistant wants to make becomes a card you read first, showing exactly which rows it touches. It runs when you press Apply, and every applied change is reversible and lands in the audit trail above.

No way out

Not one of the assistant's tools can fetch a URL, send an email, or write a file. Even if a model were manipulated into trying to leak your data, there is nowhere for it to send it.

Data is quoted, not obeyed

Text that arrives from outside your business (a vendor's invoice memo, a bank description, an uploaded document) is explicitly fenced before the model reads it, and the model is instructed to treat anything inside as evidence rather than instructions.

A read-only switch

One setting stops the assistant changing anything at all, checked both when a change is proposed and again at the moment you apply it.

Your key or ours

Bring your own API key and your data goes to the provider you chose, billed to you. Or use Neo-Capital AI and it runs on ours. Either way it is never used to train anything.

Some of the strongest things about this software are things it doesn't contain.

• No analytics or tracking SDKs. The desktop app does not phone home. There is no telemetry library in the build, and error reports are sent only when you press the button that sends one.
• No data brokering. We can't read your books, so there is nothing to sell, benchmark, or feed to a lending product. This isn't restraint. It's arithmetic.
• No account required on desktop. Buy it, install it, use it. Your books never need to meet us.
• No hidden admin access. There is no support tool that opens a customer's books, because no such tool could work.

At signup you are shown a one-time recovery code, once. It is the consequence of everything above: since your password is the only thing that derives your keys and we never receive it, there is no "send me a reset link" that could possibly work. A company that can reset your encryption password is telling you something about who holds your keys.

The recovery code recovers the same underlying keys under a new password, so shared books and connected devices keep working afterwards. Write it down and put it somewhere real. If you lose both the password and the code, your books are not recoverable: not by you, and not by us.

Can you read my books?

No. On desktop we never have them. Online and on Connected sync, what we hold is ciphertext and we do not have the key.

If you get hacked, is my financial data exposed?

No. An attacker gets encrypted data and no key to open it.

Can one of your employees look at my data?

No. Nobody here holds your keys. There is no internal tool that could.

What happens if you receive a subpoena?

We can produce your email and billing records. Your books would be handed over as ciphertext, which is all we have.

Do you train AI on my data?

No. We can't read it. When you use the assistant, your data goes to the model provider for that request only, under your own API key if you brought one.

Do you support two-factor?

Yes: TOTP, from your account settings, with backup codes. With it on, a correct password alone gets an attacker nothing at all: no session, and not your encrypted key either.

Can the bank connection move my money?

No. It requests read access to transactions and nothing else.

What if Neo-Capital goes away?

Desktop books are a file on your machine and stay yours. Everything exports (full book files, CSV, PDF), and the desktop app keeps working without us.