Trust & security — Perkival

Where your data lives

A free Perkival account is required to use the product — there's no account-free mode. Your derived benefit data lives in your account so it's available on any device you sign in from; your bank credentials and session stay on your device — always.

Stays on your device

Never leaves your device

Your bank username and password — never collected, never transmitted, never stored by us.
Your signed-in session (cookies/tokens) — stays inside your browser, never sent to our systems.
Card numbers are stored masked — the last digits only, for telling cards apart. The full number is never captured.

Signing in to your Perkival account is required to use the product; diagnostics are a separate, opt-in channel that stays off by default — while it's off, nothing about your app usage leaves your device.

Always synced to your account

Your derived wallet

Only the derived benefit data: the cards you hold, your credits, amounts, dates, and history. That is what lets a second device show the same wallet.
Your sign-in email (or Apple/Google identity), used only to authenticate your Perkival account.
Synced data is treated as financial PII: TLS in transit, encryption at rest, strict per-user isolation, and identifiers masked out of logs and metrics.

Sign out and syncing stops. Delete your account and the data goes with it — see below.

What our servers never receive — by architecture, not policy

Your bank username or password — there is nowhere in the product to enter it for us.
Your session cookies or tokens — they stay inside your browser's session with the bank.
Your full card numbers — only the last digits are ever parsed.
Your bank transactions or statements — the extension parses only the account-list and benefits data.

We never log in as you, from anywhere. There is no server-side login code, no credential vault, and no "background refresh from our cloud." A tracker that stores your bank login on its servers is a breach honeypot; we chose an architecture where that class of breach is impossible for us to have.

What "derived" means

What the extension reads: While you browse your bank's site signed in, the site's own pages request your account list and benefits data. The extension reads those responses inside your browser — the same information already on your screen.
What comes out of that: A parsed, structured record: "Platinum ····1007 — dining credit — $100 per month — $80 used — resets on the 1st." That parsed record is the derived data. It's what's stored in your Perkival account, and it's the only thing that ever crosses from your device.
What never comes out of that: Credentials, session tokens, full card numbers, transactions. Raw identifiers are masked before they can reach any log or metric, on the client and on the server.

The threat model, in plain English

If our servers are breached

There are no bank credentials or sessions to steal — nobody can log in to your bank with anything we hold. Your derived benefit data (cards, credits, history) could be exposed; that's still personal financial information, which is why it's encrypted at rest, isolated per user, and kept out of logs.

If your laptop is lost or stolen

Your signed-in browser session lives on that machine. Protect it the way you protect the rest of your digital life: an OS account password and full-disk encryption (FileVault/BitLocker). You can also sign out of your Perkival account, or clear your device's local app settings, any time from Settings.

If Perkival disappears

Perkival requires our servers and your account to show your dashboard — there's no offline-only mode. What we can promise instead: your data is exportable to open formats — CSV and Excel — any time, so it's never locked in and never hostage, even if you decide to leave.

What the extension can touch

The https://*.chase.com/* permission lets Perkival run on Chase pages the user opens. This describes site access, not card or feature coverage.

It cannot read your email, your other tabs, or any other site. Remote-config for parser fixes is data-only (selectors, never code), so an update of logic always goes through a store-reviewed release.

The honest part: riding your own session

Disclosure: issuer terms, and a theoretical account-flag risk

Perkival works by riding the authenticated session you opened with your bank — it reads data from your own browsing, on your own device. We think that is the most defensible way to build this category: no stored credentials, no server-side logins, no impersonating you from a data center. But we owe you the caveats:

Most issuers' website terms restrict automated access. Issuers have historically blocked services that log in with stored member credentials from their servers. Perkival doesn't do that — but an issuer could still object to any tool it didn't build, and in theory could flag unusual activity on an account.
To keep the footprint minimal, capture is primarily passive — it reads the responses your own page visits already produced. Background refresh runs only while you are actually signed in, and is throttled to a minimum 15-minute interval (you can set it longer). There is no headless browsing and no login automation of any kind.
We have no reports of an account being flagged for using Perkival, and we won't invent statistics either way — the honest statement is: the risk is theoretical, nonzero, and yours to weigh. This is not legal advice.

Deleting your data

On your device: Settings has a clear-data control that clears your local app settings in one click. On our servers: deleting your Perkival account removes your user record and every row of your synced wallet — deletion is implemented in the backend as a first-class, tested operation (idempotent, confirmation-protected), not a support-ticket promise. Details, retention periods, and your rights are in the privacy policy.