1. The data boundary
Fain is designed so raw imported financial records and raw question or conversation history remain in the customer’s browser storage. Hosted Fain systems are limited to authentication, billing, allowlisted measurement, non-financial operational metadata, and the approved aggregate context required for narration.
2. Information intended to remain in the browser
Local records can include source transaction rows, descriptions, merchant fields, account and IBAN data, filenames, source currencies, user classifications, confirmed balances, and raw Ask history. This information should not be sent to Fain’s hosted databases, model providers, marketing analytics, logs, or support tools.
3. Hosted account and billing information
Fain may process account credentials and profile fields, authentication events, workspace plan and entitlement state, subscription and payment status, trial and billing timestamps, support communications, and non-financial operational records. Stripe processes payment-method details under its own terms; Fain should store processor identifiers and status rather than full card data.
4. Hosted narration context
For a supported question, the browser may send a normalized intent, approved aggregate results, assumptions, warnings, engine version, and metric provenance to the narration service. The payload must exclude source rows, filenames, descriptions, merchants, account or IBAN data, email addresses, account identifiers, and other personal identifiers.
5. Measurement
Allowlisted events may record a registered marketing release, message, content, call-to-action, campaign, plan, supported intent, or usefulness reason. Measurement must not record financial values, filenames, raw questions, email addresses, user or workspace identifiers, full URLs, query strings, hashes, referrers, or arbitrary text.
Anonymous campaign context is intended to use session storage instead of persistent anonymous cookies. Raw marketing events are proposed for deletion after 120 days; only non-identifiable aggregate rollups should remain afterward.
6. Purposes and legal bases
A final notice must map each data category and purpose to an applicable legal basis, including account performance, payment administration, security, support, product measurement, consent where required, and legal compliance. Counsel must validate the analysis for the US states and other jurisdictions actually served.
7. Service providers and disclosures
The production notice must identify relevant categories and named providers for authentication infrastructure, hosting, payment processing, email delivery, model narration, operational monitoring, and legal compliance. Fain should not sell raw financial data or use it for behavioral advertising.
8. Retention and customer controls
Browser-local data remains until the user exports, resets, or clears browser storage, subject to browser and device behavior. Hosted records should follow documented retention schedules for account, billing, security, support, and legal obligations. Customers should be able to export or reset local records and request applicable hosted-data rights.
9. Security
Fain should describe concrete safeguards such as access controls, authentication, dependency review, secret management, encryption in transit, incident processes, payload tests, and least-data architecture. No system can guarantee absolute security.
10. Rights, children, changes, and contact
The final notice must include applicable state privacy rights, verification and appeal procedures, authorized-agent requests, non-discrimination commitments, children’s-data restrictions, change notices, controller identity, mailing address, privacy email, and any required regional disclosures.