Security at Atlas Ledger

Last Updated: October 9, 2026

1. Bank connections

• You link a bank, card, loan, or investment account through Plaid, or for some institutions Teller. You enter your bank login on their screen, not ours. Atlas Ledger never receives or stores your banking username or password.
• The provider gives us an access token for your connection. We store it encrypted with AES-256-GCM in our database and leave it out of your data download.
• We ask Plaid only for account, balance and transaction data, plus investment holdings if you agree to share them.
• Atlas Ledger cannot move your money. Bank transfers are switched off in production, so the app cannot start a payment or transfer from your accounts. "Record a Transfer" only notes a transfer you made somewhere else.
• When you delete your account we ask Plaid or Teller to revoke our access. Removing the last account of a Plaid connection from Atlas Ledger revokes that connection too.

2. Signing in

• If you use a password, we store only a bcrypt hash of it. When you choose a new password we check it against known data breaches using Have I Been Pwned's range search, which only ever receives the first five characters of the password's hash, never the password. (If that service cannot be reached, the check is skipped rather than blocking you.)
• You can also sign in with Google or Apple. In that case your password stays with them.
• On the website you can add a passkey (Settings → Security Settings) and sign in with your device's fingerprint, face or PIN instead of a password. Passkeys can't be phished, and we store only the public half; the private key never leaves your device.
• You can turn on two-factor authentication with an authenticator app in Settings → Security Settings. You get one-time recovery codes in case you lose your phone, and turning it off needs both a code and your password.
• Once you are signed in, your session is kept in HttpOnly cookies that scripts on the page cannot read. The access token expires after 15 minutes and is renewed with a separate refresh token that the browser sends only to our sign-in endpoints.
• Repeated failed sign-ins are rate limited, and an account that keeps failing is locked for a while (15 minutes at first, longer if it continues).
• When someone signs in to your account from a browser or device we haven't seen before, we email you.
• In Settings → Security Settings ("Where you're signed in") you can see the devices that are signed in and sign out any of them, or all of them except the one you're using.
• Deleting your account asks you to prove it's you again first: your password (or a recent sign-in if you use Google or Apple).

3. How your data is protected

• In transit: all traffic uses HTTPS, and we tell browsers (with HSTS) to use HTTPS for our site for a year.
• At rest: bank-connection access tokens, crypto-exchange secrets and tokens, and two-factor secrets are encrypted in our database with AES-256-GCM. Other data, such as balances and transactions, is not separately encrypted by the application.
• Access: every request is checked against your account, so you can see only your own data (and household summaries you have chosen to join).
• Web protections: CSRF tokens on requests that change data, a Content Security Policy that limits which scripts can run and where pages can send data, a rule that stops other sites from showing our pages inside a frame, and rate limits on the API, with tighter limits for sign-in, AI features and report downloads.
• Analytics and error reports: our product analytics masks all text and form inputs and knows you only by a numeric ID and your plan, never your name, email, or dollar amounts. Error reports are configured not to send default personal data. Details are in our Privacy Policy.
• Business model: Atlas Ledger is paid for by subscriptions. We do not sell your personal information and do not use it for advertising.

4. Your data, your choice

• Download my data (Settings, any plan) gives you a ZIP of the personal data we hold about you. Passwords, two-factor secrets and connection tokens are left out for your safety.
• Delete Account (Settings) removes your data from our live database and revokes our bank connections. What deletion does and does not cover is listed in section 9 of our Privacy Policy.
• AI features are optional and can be turned off. How we use AI lists exactly what they send.

5. How we run the service

• We back up our database every day. Backups rotate out automatically, and the oldest copies are kept for up to about 90 days. An automated job regularly restores the latest backup into a scratch database to check that it actually works.
• We keep a continuously updated standby copy of the database on a separate server, so the service can be recovered if our main server fails.
• Our dependencies are scanned for known vulnerabilities every night, and updates are proposed automatically.
• An automated monitor signs in to a test account around the clock and alerts us if signing in breaks.
• Our deployment pipeline ships a change only after our automated test suite, including end-to-end browser tests and security checks, has passed.
• Security-relevant events and administrative actions are recorded in an audit log that we keep for up to 365 days.

6. What we don't do yet

We would rather tell you than have you assume:

• No independent security audit or certification (such as SOC 2) yet.
• No paid bug bounty. We welcome reports and will credit you if you'd like (see below).
• No public status page yet.

7. Reporting a security problem

If you think you've found a security vulnerability in Atlas Ledger, please email [email protected] with "Security" in the subject. Tell us what you found, the steps to reproduce it, and what an attacker could do with it. Our contact details are also published in security.txt.

When testing, please:

• use only accounts you own, and never access, change, or delete anyone else's data (if you come across it, stop and tell us);
• avoid anything that could degrade the service for others, such as denial-of-service attacks or heavy automated scanning;
• don't use social engineering, phishing, or physical attacks against us or our users;
• give us a reasonable amount of time to fix the problem before you share it publicly.

Safe harbor: if you make a good-faith effort to follow these guidelines, we will not take or support legal action against you for your research, and we will work with you to understand and fix the problem.

What to expect: we aim to reply within a few business days and will keep you updated while we work on a fix. We don't pay bounties, but with your permission we'll gladly thank you by name. Problems in services we rely on (such as Plaid, Stripe, Google, or Apple) should go to those companies directly.