Honest answers to the questions we hear most before connecting a financial account.
Your financial data is encrypted in transit using TLS 1.2+ and encrypted at rest in our database using AES-256. Tokens that authorize access to your bank, accounting, or payments provider are stored separately from your transaction data and never logged in plaintext.
We do not sell, rent, or share your financial data with any third party for marketing, advertising, credit scoring, or any other purpose. Your data is used solely to power the anomaly detection, runway analysis, and weekly pulse features you signed up for.
Access to production databases is gated behind role-based credentials, and all access is logged and reviewed. We follow least-privilege principles — even our own engineers cannot read arbitrary customer data without an explicit, time-bound grant during an active incident response.
No. Every integration ProfitPulse supports — Plaid, Wave, Stripe, QuickBooks, Xero — is configured with read-only scopes only. We never request, store, or use permissions that would allow us to initiate transfers, send payments, issue refunds, modify transactions, change account settings, or close accounts on your behalf.
When we fetch transactions, balances, invoices, or aging reports, we are strictly consuming data. There is no write path from our code into your financial institution or accounting system.
You can verify this yourself by opening your bank or accounting provider's connected apps screen at any time and inspecting the permissions granted to ProfitPulse — you will see only read scopes such as "Read accounts" or "Read transactions", never "Move money" or "Initiate payments".
ProfitPulse sees the data we need to do our job: transaction dates, amounts, merchant names, categories, account balances, invoice aging, and (if you connect Wave or Stripe) revenue and expense line items tied to a period.
We do not see, request, or store account numbers, routing numbers, debit or credit card numbers, Social Security Numbers, tax IDs, dates of birth, passwords, security questions, one-time codes, or any other credential that would allow us to impersonate you or impersonate your business.
Bank login credentials are handled entirely by Plaid (or the equivalent provider), which returns an opaque access token to ProfitPulse. We never see your actual username and password, and we cannot use the token on any site other than the original connection.
Disconnecting is one click inside the app. Open Settings → Integrations, find the connection you want to remove, and click "Disconnect". We immediately revoke our stored access token, delete the corresponding import job history, and stop fetching new transactions. Existing transaction history you chose to import into ProfitPulse will be retained unless you also click "Delete my data" in the same screen.
Disconnecting inside ProfitPulse does not automatically revoke access upstream. We recommend a second step inside the source system for total peace of mind: in Plaid, open your bank's connected apps screen and remove ProfitPulse; in Wave, QuickBooks, or Xero, revoke the OAuth grant under "Connected apps"; in Stripe, remove the API read-only key from the Stripe dashboard.
Both revocations are independent and either one alone is sufficient — ProfitPulse will fail its next sync and mark the connection as inactive as soon as the upstream token is gone, even if the in-app disconnect has not yet been clicked.
Only you. And, if you invite them via Settings → Team, the user seats you explicitly add to your ProfitPulse workspace. Each invited seat is a real human login with the same role-based permissions by default, and you can revoke any seat at any time.
ProfitPulse employees do not browse, read, or otherwise access customer financial data as part of normal operations. Customer support engineers only see what you choose to share in a support ticket (typically screenshots, log lines, or specific transaction IDs), and only with your explicit consent for the duration of an open ticket.
If a genuine incident requires engineering access — for example, a bug that prevents your dashboard from loading — the request is logged with a business justification, time-bound, reviewed by a second engineer, and revoked once the incident is resolved.