Security at ClearViewCash

The short version

• We never see or store your bank username or password — bank connections are read-only and handled by Plaid.
• We cannot move your money. There is no transfer, payment, or withdrawal capability anywhere in the product.
• Bank-connection credentials are encrypted at rest in a dedicated secrets vault, separate from application data, and are never sent to your device.
• Every database row is permission-checked at the database itself — not just in the app — and those rules are re-verified by an automated test suite on every code change.
• Deleting your account really deletes it, immediately, including revoking our access to your banks. See the data-deletion policy below.

Your bank credentials never touch us

Linking a bank happens inside Plaid’s secure widget — the same connection provider used by many major financial apps. Your bank login goes to Plaid (or directly to your bank via OAuth), never to ClearViewCash. What we receive is a scoped, read-only access token that lets us fetch balances and transactions, and nothing else. You can revoke any connection at any time from Settings, which also tells Plaid to invalidate the token on their side.

Encryption, in transit and at rest

• All traffic uses TLS, and browsers are instructed to never downgrade (HTTP Strict Transport Security with a two-year policy).
• The database is encrypted at rest by our infrastructure provider (Supabase, on top of AWS).
• Plaid access tokens — the one credential that grants ongoing read access to a bank connection — get an extra layer: they live in Supabase Vault, a dedicated encrypted secrets store, readable only by server-side code. They are never included in any API response to a client.
• The few places we hold sensitive account numbers (payout details for affiliate partners) are encrypted with authenticated encryption and are only ever returned as last-four masks — the full numbers are write-only.
• On mobile, your session token lives in the device Keychain (iOS) / Keystore (Android), not in plain app storage.

Permissions are enforced by the database, not the app

Every table in our database carries row-level security policies: the database itself refuses reads and writes that don’t belong to you, regardless of what any app, script, or compromised client asks for. Sharing in household spaces is allowlist-based — a partner sees an account, a balance, or a transaction only if you explicitly shared it, and a transaction you hide stays hidden no matter how much history accumulates.

We keep a written permission matrix of who can do what to every table, and a suite of 370 automated database-policy assertions runs against every code change to prove the matrix still holds — including the deny cases: members can’t grant themselves admin rights, can’t edit each other’s balances, and can’t see what wasn’t shared. Subscription tier and billing identity columns are server-only; a client cannot write its own entitlement.

Verified webhooks, authenticated jobs

Money-related messages from the outside world are not taken on faith:

• Plaid webhooks are verified with Plaid's signed-JWT scheme (ES256, key fetched from Plaid, request body hash checked) before we act on them.
• Stripe webhooks must carry a valid Stripe signature; unsigned or tampered events are rejected.
• RevenueCat (App Store billing) webhooks must present a shared secret.
• Our own scheduled jobs (trial expiry, downgrades, nightly forecasts) require a secret bearer token — they cannot be triggered by strangers.
• An unrecognized Stripe price never silently changes anyone's subscription: it alerts and does nothing.

Protecting your account

• Two-factor authentication (authenticator-app TOTP) is available to every account, free or paid, in Settings → Security.
• Passwords are handled by our authentication provider and stored only in hashed form; we never see them.
• Our own staff admin dashboard demands a fresh two-factor code on every entry, and the admin API independently re-checks it server-side.
• Web sessions are protected by strict security headers, including clickjacking denial (no site may embed ClearViewCash in a frame).

Tested like money software

Every change to ClearViewCash passes a continuous-integration gate before it ships: type checks, hundreds of unit and characterization tests over the money math, a dedicated test harness for every payment and bank webhook, the 370 database-policy assertions above, and a full build. Error monitoring runs on mobile, web, and our servers, so failures surface to us — not just to you. Our product analytics use a strict event allowlist engineered to exclude balances, transaction amounts, and account numbers.

Delete means delete

Deleting your account is self-serve, immediate, and complete: bank connections are revoked at Plaid, subscriptions billed by us are canceled, and your data is erased in the same operation — not flagged for cleanup later. The full walkthrough is in our data-deletion policy.

What we're still working toward

Honesty cuts both ways, so here is what we have not done yet: we are not SOC 2 certified. We maintain an internal SOC 2 readiness checklist and build controls against it, and we plan to pursue certification as the business grows. Our content-security-policy header is in a staged report-only rollout before enforcement, so we can flip it on without breaking bank linking or checkout.

Reporting a security issue

If you believe you have found a vulnerability, email support@clearviewcash.com with “Security” in the subject line. We read every report, we will respond, and we will never take legal action against good-faith research.