Bankbonimus Clearview

What this application is

Clearview reads balances and transaction history from its operator's own financial accounts and displays them on a single dashboard, so that account balances scattered across a dozen institutions can be seen in one place and tracked over time.

It has exactly one user, who is also the person who wrote it and the owner of every account it connects to. There are no other users, no customers, no sign-up, and no public access to the running application.

Who operates it

What data it accesses

When a financial institution is connected, the following is retrieved through that institution's authorized API:

• Account names, types, and the masked last four digits
• Current and historical account balances
• Transaction dates, descriptions, amounts, and categories
• Connection metadata: which institution, sync status, last sync time

The data is used for one purpose: displaying the operator's own balances, transactions, and net-worth history back to the operator. It is never sold, shared, transferred to any third party, used for advertising, used to train anything, or used to make decisions about any person.

What it never accesses

• Full account or routing numbers
• Bank credentials for Plaid, SnapTrade and Quiltt connections — those are entered inside the aggregator's own hosted flow and are never seen by this application. (Sophtron uses a direct-credential API: for that provider alone, credentials are passed through over TLS to Sophtron and are never stored.)
• Social Security numbers or government identification
• Analytics, telemetry, advertising identifiers, or location data

Connections

Connections are established through licensed data aggregators. Each connection is initiated by the operator and authenticated directly with the institution inside the aggregator's own flow.

Where the data lives, and how it is protected

Two places, and both are described here because a partial answer is not an answer:

• A local SQLite database on the operator's own Mac, which is covered by full-disk encryption (FileVault, XTS-AES-128).
• A Cloudflare D1 database backing the web dashboard, holding institution names, account names and masks, balances, transactions, and sync logs.

Access tokens are encrypted with Fernet (AES-128-CBC with HMAC-SHA256) before being stored, and the copy in the cloud database is ciphertext only — the encryption key stays in the macOS Keychain and is never transmitted, so the cloud component cannot decrypt a token even in principle.

Balances and transactions in the cloud database are not separately encrypted by this application; they rest under Cloudflare's own at-rest encryption and are protected in access terms by the gate described below.

The dashboard is not reachable from the open internet. It sits behind Cloudflare Access: human access requires a Google identity with multi-factor authentication, and two named machine credentials are additionally admitted for scheduled writes. Anonymous traffic is redirected to that login and never sees application data. All traffic uses TLS 1.2 or above.

Retention and deletion

Balance and transaction history is retained so that net worth can be charted over time; that history is the point of the application.

The operator can disconnect any institution from within the dashboard, which stops all further data retrieval and deletes the stored accounts, balances and transactions for it. Revoking the underlying authorization at the aggregator is a separate, deliberate step so that a disconnection can be undone without re-authenticating; it is performed with a maintenance tool and is verified by a monthly access review that flags any authorization still live after a disconnection.

An institution or an account holder who wants a connection terminated or data deleted can write to tcaputi@gmail.com.