Privacy Policy

Payment is handled entirely by Stripe. Card details are entered on Stripe’s own payment page or in Stripe’s own secure frame; they never reach this website’s servers, and are never stored here. Stripe also collects the shipping address and phone number needed to send the piece, and calculates sales tax from the address entered.

After a payment succeeds, this site receives back from Stripe and keeps:

• —Your name, email address and phone number.
• —What you ordered (item names, quantities and amounts), and the order total.
• —Your city, state and country, together with the order record.
• —Your full shipping address, which appears in the order notification email sent to the studio.

The full street address is not written into the studio’s customer records; those hold city, state and country only. It reaches the studio by email so the piece can be sent.

The contact and commission forms collect your name, email address, a phone number if you give one, and your message. The message is emailed to the studio, and the first 300 characters are kept with your contact details in the studio’s enquiry records so the conversation can be picked up later.

Both public forms carry a hidden field that human visitors never see. Submissions that fill it are discarded without being emailed or recorded; it exists to keep automated spam out of the studio’s inbox, and it does not affect real enquiries.

This site measures its own traffic. It records page paths, tagged clicks, clicks on links leaving the site, the site you arrived from (host and path only, never the full link), whether you are on a mobile or desktop browser, and a coarse country code supplied by the hosting platform. Two marketing parameters, utm_source and utm_campaign, are kept when a link carries them; every other query-string value is discarded.

To count returning visits, a randomly generated identifier is stored in your browser. It is not derived from your device, your network, or anything about you.

What is deliberately not recorded: your IP address is not stored, and neither is your browser’s user-agent string. There is no device fingerprinting. If your browser sends a Do Not Track signal, this site’s own analytics do not run at all.

This site sets no cookies of its own. What it keeps in your browser is local storage, which is not sent to the server with every request the way a cookie is: your light or dark theme choice, your shopping cart, the analytics identifier described above, and a flag noting the loading screen has been shown.

Stripe and the hosting platform are separate companies operating on their own terms, and may set cookies of their own when their components load. That is outside this site’s control and is governed by their policies.

Only the companies needed to take an order, make it, send it, and answer you. There are no advertisers, no data brokers, no affiliates, and nothing is ever sold.

About the print lab. Prints are produced and posted by Bay Photo Lab. This website has no automated connection to them: no integration, no interface, nothing that transmits your order. When an order arrives, the studio owner places the print order with the lab himself and gives them the name and address needed to post it. It is a manual step performed by a person, and it is described that way because that is what it is.

Product images on some pages are served from a content delivery network (static.wixstatic.com), so your browser fetches those images from it directly.

• —It does not sell, rent, or trade your information.
• —It runs no advertising or tracking pixels: no Google Analytics, no Google Tag Manager, no Meta pixel, no Hotjar, no Segment, no Mixpanel, no Clarity.
• —It does not build advertising profiles, and does not use your information to train any AI model.
• —The AI assistant offered on the company’s portfolio site does not run on this storefront, so nothing you type here is sent to an AI provider.

You can ask what is held about you, ask for it to be corrected, or ask for it to be deleted, by emailing customarchetype@gmail.com. Requests are handled by the owner personally.

To be straightforward rather than to sound impressive: there is no self-service export or deletion button, and no automatic deletion schedule. Records are kept while they remain useful for running the business and meeting tax obligations, and are removed on request. Turning off this site’s analytics is self-service; a Do Not Track setting in your browser stops it.

Some records cannot be deleted on request because another company is legally required to keep them: Stripe keeps payment records, and the studio must keep enough of an order record to satisfy tax law.

The site is served over HTTPS. Payment card data never touches these servers. The forms and public endpoints are rate-limited and size-capped, and text submitted through them is neutralised before it is written into the studio’s spreadsheet records so it cannot execute as a formula. The customer records themselves are readable only with a secret key held by the owner.

This shop is not directed at children and does not knowingly collect information from anyone under 13.

• —Transaction dates, descriptions, merchants and amounts.
• —Account names, institutions and types (checking, savings, credit, mortgage), and balances as reported by the institution.
• —The last four digits of an account or card number, never the full number.
• —The names printed on a statement, used to establish which household member owns an account.
• —An email address and display name, for signing in.

Never collected: full account or card numbers, Social Security numbers or other government identifiers, online-banking usernames or passwords, location data, device identifiers, advertising identifiers, or anything about anyone outside the household.

• —Statements the user downloads from their own institutions and imports (PDF and CSV).
• —Direct bank connections via Plaid. Planned, not active as at this date. Credentials are entered into Plaid’s own interface and are never seen by this application; what comes back is an access token.
• —Manual entry by the user.

The application uses Anthropic’s Claude for two features. This is stated plainly, and in detail, because it means personal data leaves the application.

• —Statement identification. When a statement is imported and the deterministic parser cannot work out which institution and accounts it covers, the first 120 lines of the document are sent: the header and summary region, never the transaction body.
• —Ask. When a user asks a question about their finances in natural language, relevant ledger data is sent to answer it.

What the identification step sends, in full. The header region of a statement carries the account holder’s name and mailing address as the institution printed them, along with the institution, the statement period, and often the beginning and ending balances. Digit runs of five or more characters are reduced before sending, so full account numbers do not leave the machine. Names and street addresses are not redacted. This is a real disclosure of personal data to a third party, and it is stated here rather than buried.

Identification results are cached on the operator’s local disk, keyed by a hash of the already-redacted header, so re-importing an unchanged statement sends nothing.

Categorisation does not use Anthropic. Transactions are categorised by the household’s own rules and a built-in keyword table, entirely locally. No transaction description is sent anywhere for that purpose.

Both AI features are optional. With no API key configured, statement identification falls back to the deterministic parser and the Ask feature is unavailable.

On model training: Anthropic’s Commercial Terms of Service state that Anthropic does not train its models on customer content submitted through the paid API. That is Anthropic’s commitment under its own terms, not a control this application enforces; it is cited as the current published position and re-checked at each policy review.

There are no others: no analytics, no advertising, no tracking, no data brokers, no affiliates. The application sends no email of any kind.

All connections are HTTPS. Data at rest is encrypted with AES-256 by the database provider. Bank access tokens are additionally encrypted with AES-256-GCM under a key held outside the database. Row-level security is enforced by the database itself on every table, including the one reporting view, which is declared security_invoker so it is evaluated under the querying user’s own policies.

• —See everything held; the application’s whole purpose is showing it. Self-service.
• —Correct anything, including re-categorising a transaction. Self-service.
• —Withdraw a bank connection, which stops further collection immediately and deletes the stored token. Self-service.
• —Export: not yet built into the application; the operator produces a full extract from the database on request.
• —Delete any account or transaction, or the entire dataset: not yet built into the application; see below.

On deletion, stated as it is rather than as intended. Seeing, correcting and disconnecting are self-service. Export and deletion are currently operator actions: the owner carries them out directly against the database, on request from either household member, the same day. Row-level security grants DELETE to the owner role only, so the second household member requests deletion rather than performing it. Self-service deletion and export controls are planned before the application is exposed to the public internet or connected to a live banking provider.

Financial records are kept while they are useful for household bookkeeping and tax purposes. Tax-relevant records are kept seven years, the outer bound of the IRS assessment period, and non-tax-relevant transactions are kept on the same schedule because a category can be reclassified later.

• —Plaid access tokens: deleted immediately on disconnection, and revoked with Plaid. A bearer credential for bank data has no reason to outlive the connection.
• —Account records: while the account is tracked, then seven years after the last transaction.
• —Authentication records: while the account is active, then 90 days.
• —Application logs: 30 days.
• —Statement PDFs and CSVs: held on the operator’s local machine, retained seven years alongside tax records; not uploaded to the application database.

Deletion is a hard delete from the database. There is no soft-delete tier and no “deleted” archive that quietly retains the row. Provider-level encrypted backups may hold a copy until they expire on the provider’s own rotation. On account closure, all data associated with a user is deleted within 30 days, except records that must survive under the tax schedule above.

Disconnecting a bank deletes the access token immediately, but transactions already imported remain: they are the household’s own financial records, and deleting a year of history because a connection closed would destroy the books.

Both users are the account holders whose data is processed, and each enrols explicitly by signing in and connecting or uploading their own accounts. Consent for a bank connection is captured by Plaid at the point of connection, and can be withdrawn at any time by disconnecting the institution.