Security.

Overview

This page describes the security controls in Boolance today. It is not a certification or an audit report: Boolance does not claim SOC 2, ISO 27001 or PCI DSS certification. No system is perfectly secure, and we update these controls as the product changes.

Accounts and sign-in

• Passwords are stored only as salted bcrypt hashes. New accounts verify their email address before using bookkeeping features.
• You can protect your account with an authenticator app and single-use recovery codes. Repeated failed codes lock further attempts for 15 minutes.
• Connecting or updating a bank requires a fresh authenticator code, and you set one up first if you haven’t.
• Sessions use HttpOnly, Secure, SameSite cookies. Resetting your password signs out your other sessions. Sign-in endpoints are rate limited.

Bank connections

• You sign in to your bank through Plaid. Boolance never receives your bank password.
• You confirm an explicit authorization before every new or updated bank link, and Boolance records that acknowledgment.
• Plaid access credentials are encrypted with AES-256-GCM. When you disconnect a bank, Boolance asks Plaid to remove the connection and clears the stored credential once Plaid confirms.
• Plaid and billing webhooks are accepted only with valid provider signatures.

Data protection

• Public connections use HTTPS (TLS 1.2 or newer). The application and database are hosted in the United States, and internal service traffic uses an encrypted private network.
• Our hosting provider encrypts database storage volumes and their backups at rest.
• Credentials you provide for Stripe, PayPal, Gmail and Outlook, and the original text of captured receipts, are encrypted by Boolance with AES-256-GCM.
• The running application uses a restricted database role that cannot change the database schema.

Company access and audit history

Every request is checked against your current company membership and role on the server; a company or role sent by a browser or client is never trusted on its own. Bookkeeping changes are recorded in audit history, and a locked reconciliation period rejects changes until it is unlocked.

Assistants and MCP clients

• Only a company owner or administrator can connect an assistant. Every connection is read-only unless they separately allow edits (the books:write permission), which never covers payments, bank connections, deletion, email or tax filing.
• Remote MCP clients connect with OAuth and PKCE: the owner or administrator approves the client, the company and the permissions it receives before any access. Access tokens expire within 15 minutes, grants last at most 30 days, and refresh tokens rotate; reuse of an old refresh token revokes the grant.
• For clients configured with a header, an owner or administrator can instead create a personal access token (starting with bk_mcp_). It skips the OAuth sign-in, is shown once, works for one company with the permissions chosen when it was created, including edit access if allowed, and expires after 1 to 90 days (30 by default). Treat it like a password.
• OAuth and personal tokens are stored only as hashes, work only for MCP (never as application sessions), and are rechecked against the creator’s current membership on every call. Browser cookies can’t be used for MCP. Revoke any client or token from Connections at any time.
• Each call is recorded in audit history without storing its raw arguments or results; edits also record the changed records.

Payments

Card details are entered in Stripe’s checkout through our billing provider, CashSDK. Boolance doesn’t receive or store card numbers. Only a workspace owner can start checkout or open the billing portal, and a plan becomes active only after Boolance confirms it with the billing provider, not because a browser returns from checkout.

Staff access

Boolance staff use a separate console with explicitly provisioned accounts. Staff sign-in requires a password and an authenticator code, and staff sessions are separate and expire after one hour. A customer company role never grants staff access.

Operations

We audit dependencies for known vulnerabilities before releases and follow documented patch deadlines and incident-response procedures. Error reports are designed to exclude personal information such as names, emails, cookies and request contents. See the Privacy notice for how we handle information.

Report a vulnerability

Email support@boolance.com with the affected feature, steps to reproduce using test data, and the impact you observed. Please don’t include bank credentials, access tokens, passwords or real financial records. We aim to acknowledge reports within two business days.

Please don’t access other customers’ data, run destructive or denial-of-service tests, use social engineering, or disclose details publicly before we have addressed the issue. We don’t offer a bug bounty.