Lake Financial — Privacy Policy

Upcoming policy — effective October 5, 2026 at 00:00 UTC. Until then, the current Privacy Policy, effective August 31, 2026, remains in effect. This policy does not replace the Terms of Use. The separate Apple Membership Supplement addresses native purchases without changing existing arbitration or other rights.

Effective date: October 5, 2026
Last updated: September 20, 2026

This revision describes the native iPhone app’s authentication, Apple purchases, local reminders, optional measurement, feedback and deletion controls; clarifies profile images, transaction-location metadata, provider requests and retention. It does not introduce advertising inside the native app or replace the Terms of Use. The August 31 revision history below is retained for context.

Revision note (August 31, 2026): this revision replaces the July 24, 2026 policy, whose source and SHA-256 hash are archived. It adds disclosures for Vercel Web Analytics, Google Analytics 4, the Meta Pixel on the public funnel pages, the first-touch campaign-attribution cookie, the HubSpot customer-relationship system, the in-product accuracy survey, the free trial, and marketing email, and it corrects the July version's statement that the Service used no analytics or advertising technology, which stopped being accurate when advertising measurement launched in August 2026. Because the prior policy understated actual practice, this revision was published on an accelerated schedule rather than after a 14-day notice window; the notice describing the change is shown in the Service. Review by outside counsel is recommended and pending; publication was directed by the owner.

This Privacy Policy explains how Rieper LLC, an Indiana limited liability company doing business as Lake Financial ("Lake," "we," "us"), collects, uses, protects, shares, and deletes information when you use www.lakefin.net and the Lake application (the "Service").

Lake exists to show you your own money clearly. Handling your financial data carefully is not a side concern of that job — it is the job. This policy is written to be read, not skimmed past.

The short version

We do not sell your personal information. We never have and we do not intend to.
We do not share your financial data with advertisers. We use Vercel Web Analytics (cookie-free, aggregated) and Google Analytics (first-party cookies, measurement only, with sensitive URLs minimized) for usage statistics as described below. Our public landing and sign-in/sign-up pages use the Meta (Facebook) advertising pixel to measure our own advertising; it does not run on signed-in application pages, never receives your linked-account or financial data, and does not load at all when your browser sends the Global Privacy Control signal.
We keep a customer-relationship record. Your email address, plan and trial status, campaign attribution, and survey and feedback responses are kept in HubSpot, our customer-relationship system, so we can run the Service's emails and understand our customers. Lake does not automatically add linked-account records or derived spending details to that record. Feedback you submit is included as written.
We never see your bank username or password. You enter credentials or authorize access through Plaid Link or your financial institution's OAuth flow, not through Lake.
Your Plaid access tokens, optional profile fields, native Apple authorization bindings and retained tokens, notification tokens, pending account-cleanup instructions, and queued native feedback are encrypted at rest with AES-256-GCM, separately from ordinary database storage.
You can delete your Lake account from Settings at any time. Lake saves the minimum encrypted instructions needed to finish cleanup, removes your active Lake account records, revokes retained Apple sign-in credentials, and removes your Plaid connections, Clerk identity and HubSpot contact through a retryable process. If a provider step has not finished, Lake shows deletion as pending. Sections 5 and 6 describe the limited cleanup, security, provider, support and backup records that remain, including instructions for legacy Apple authorizations without a matching retained credential. Deletion does not cancel an Apple or Stripe subscription.
First-party usage measurement is optional and off by default. If you turn it on, Lake records the specified spending-summary and membership screen views with account and app-version context, and whether a new goal was created on iOS or the web. We use retained consented views to count returns on later days. The iOS app adds no advertising SDK or cross-app attribution.
We use your data to run Lake for you. Not to build a profile to monetize elsewhere.

The rest of this document is the detail behind those statements.

1. Information We Collect

1.1 Information you give us

What	Detail	Required?
Account identity	Email address and sign-in identifiers handled through Clerk; any name, username or profile image you provide or make available through a connected sign-in provider	Email and sign-in identity are required; name, username and profile image are optional
Optional profile	Birth year you choose to provide, plus any legacy gender value you provided before that field was removed	Optional — birth year is used only for an age-group comparison based on published public benchmarks; stored profile fields are encrypted at rest and separately deletable
Your labels and notes	Budget and category names, goal names and targets, account nicknames, colors and icons, transaction notes, custom merchant categorization rules	Optional
Attachments	Receipts and documents you attach to transactions (up to 4 MB per file, 5 per transaction)	Optional
Support and feedback	Support emails, including the sender address and any message, attachment, and email metadata you choose to send; answers you submit through in-product feedback prompts; in-app thumbs up, thumbs down, and dismissals on Insights, together with the Insight/template/instance context, relevant merchant, category, budget, or goal label, wording variant, and timestamp	Optional
Accuracy survey	If you answer the one-time in-product survey about the spending summary ("the reveal"), your multiple-choice answers about accuracy and usefulness and any free-text notes about what surprised you or looked wrong	Optional
Plan and trial status	Your plan, billing interval, subscription status, and — if you start the free trial — the trial's start and end dates	Created when you subscribe or start a trial

1.2 Financial information from your linked accounts

When you link a financial institution, Plaid Inc. facilitates the connection with that institution and provides us with account data on an ongoing basis. Depending on the institution and the accounts you select, this includes:

Account details — account name, official name, an account mask (typically the last four digits when the institution provides it), account type and subtype, currency
Balances — current balance, available balance, credit limits
Transactions — amount, date, authorized date, description as reported by your institution, merchant name, pending status, the institution's own category assignments and merchant-logo information. When Plaid supplies transaction-location metadata, Lake stores the city, region, store number, latitude and longitude with the transaction; it does not store the street address, postal code or country from that location object. Coordinates are not rounded before storage. This describes a transaction location, not live device location, and is separate from the optional nearby-reminder permission.
Investments — securities held, quantities, cost basis, market values, and related security details
Liabilities — for supported credit-card, student-loan, and mortgage accounts: APRs or interest rates, statement or principal amounts, minimum and last-payment amounts and dates, next due dates, payoff details, overdue status, and similar terms
Institution identity — the name and identifier of the institution, and the technical status of the connection

We do not receive or store your online banking credentials. You enter them through Plaid Link or authorize access through your financial institution's OAuth flow. Lake receives an access token, which is encrypted before it is stored and is used solely to fetch the data above.

Information handled by Plaid during connection. New bank connections in the native app request Plaid’s Transactions product. Its connection scope includes account-owner contact information, which may include name, email, phone number and address. This is separate from the transaction-location fields described above. Lake’s current native integration does not request Plaid Identity or Identity Verification and does not receive those owner-contact fields through its Transactions response.

Plaid also offers an optional returning-user flow. If you choose to be remembered, Plaid can collect and verify a phone number and associate it with saved bank connections for future use. Lake does not prefill a phone number or receive it from that flow. This is Plaid’s feature, separate from Lake sign-in and optional usage measurement. See Plaid’s returning-user explanation and its end-user privacy policy.

1.3 Information we generate

Derived information — merchant normalization and repeat-place or repeat-category groupings; visit counts and frequency; the usual-spend estimate from recent eligible visits; mapped spending-limit amounts and estimated visits left; detected recurring income streams; and budget pacing, snapshots, rollups, trends, forecasts, volatility measures, anomaly flags, and Insights. Lake calculates these from your linked-account and user-provided data.
Enriched transaction fields — a cleaned merchant name, a category, and a merchant logo, described in Section 3.
Alerts — unusual-transaction, low-balance, and goal-off-track notices, with their dismissal state.
Lifecycle events — timestamps for when your account was created, when you first synced a linked institution, when a trial started or is scheduled to end, and when a subscription started or ended, recorded in our customer-relationship system as described in Sections 1.5 and 3.1.

1.4 Information collected automatically

The web analytics, advertising pixel and campaign-cookie descriptions in this section concern the website and web application. Section 1.6 describes the native iOS app. A website you choose to open from the app is also subject to that website's processing. Authentication and bank-return callback pages do not load Lake marketing or analytics scripts.

Authentication and session data — handled by Clerk, including session cookies strictly necessary to keep you signed in.
Saved website deletion check — before deletion starts, Lake saves an expiring signed status receipt in a necessary browser cookie. In production the cookie is HTTPS-only, HttpOnly and limited to the Lake host; page scripts cannot read it. It contains a one-way identity hash, issue/expiry times and a signature, with no email, bank credentials or financial details. It lets this browser check the existing deletion record after sign-out or removal of the sign-in account. It cannot start another deletion or access financial data. The cookie expires within 30 days, or sooner when bounded by an already completed record. Clearing browser cookies removes this saved check. An unavailable or expired receipt does not prove deletion finished.
Server and security logs — Vercel processes request information such as IP address, timestamp, user agent, requested path and search parameters, request identifiers, region, response status, and function or routing metadata for hosting, security, abuse prevention, and debugging.
Route and page-view analytics — Vercel Web Analytics receives route and page-view data across the Service that may include timestamp, hostname, page URL, framework route, filtered query parameters, referrer, approximate location derived from IP address, browser, operating system, device type, and analytics script version. Lake sends no custom events to Vercel Web Analytics. Before a page view is sent, Lake replaces transaction identifiers and reversible spending-detail keys in the corresponding detail URLs with route placeholders and removes query strings and fragments from those two normalized URLs.
Google Analytics (site-wide) — the Service uses Google Analytics 4 (Google LLC) to understand how the Service is used. Google Analytics sets first-party cookies (including `_ga`) and receives information such as your IP address, browser and device information, approximate location derived from IP address, the pages you visit, and product-funnel events such as sign-up, paywall views, and checkout starts. Lake configures it for measurement only: Google Signals and ad-personalization are disabled, automatic page tracking is replaced with events that pass through the same URL minimization described above for Vercel Web Analytics (transaction identifiers and reversible spending-detail keys are replaced with route placeholders before transmission), and no linked-account or financial data — no merchant, amount, balance, or account detail — is ever included in an event. Google's handling is governed by Google's privacy policy (policies.google.com/privacy); you can opt out with the Google Analytics opt-out browser add-on (tools.google.com/dlpage/gaoptout) or by blocking cookies.
Advertising measurement (public funnel pages only) — the public landing page, the sign-in and sign-up pages, and the brief post-signup welcome page load the Meta Pixel, which sets Meta advertising cookies (including `_fbp`) and sends Meta Platforms, Inc. information such as your IP address, browser and device information, the funnel page visited, referrer, cookie identifiers, and standard events (page views, and a signup-completed event on the welcome page). Lake uses this to measure whether its Facebook ads work and to reach ad audiences. The pixel does not load on signed-in application pages, no linked-account or financial data is ever sent to Meta, and the pixel does not load at all when your browser sends the Global Privacy Control (GPC) signal. Meta's use of this information is governed by Meta's own privacy policy (facebook.com/privacy); you can also limit Meta's ad targeting at facebook.com/adpreferences, and browser tracking protections or blocking third-party cookies likewise limit the pixel.
Campaign attribution cookie — if you first arrive at Lake from a link carrying campaign parameters (`utm_source`, `utm_medium`, `utm_campaign`, `utm_content`), Lake stores those values in a first-party cookie named `lake_utm` for up to 90 days. It is written once — your first visit's values are never overwritten — and contains only those campaign labels, never an identifier of you. If you later create an account, the stored campaign labels are copied to your customer-relationship record (Section 1.5) so we know which of our campaigns brought you, and the cookie has no other use.

Signed-in application pages do not use advertising cookies, advertising pixels, session recording, or cross-site behavioral trackers; the Meta Pixel described above runs only on the public funnel pages. Vercel states that Web Analytics does not use cookies and stores page-view data in anonymized, aggregated form rather than associating it with an individual or IP address. Vercel also states that its visitor-identification hash is reset every 24 hours; that statement does not mean page-view records are deleted within 24 hours. See Vercel's Web Analytics privacy documentation at vercel.com/docs/analytics/privacy-policy.

1.5 Your customer-relationship record

Lake keeps a customer-relationship record for each account in HubSpot, keyed to your email address. It can include: your lifecycle stage with Lake (signed up, activated, trialing, subscribed, or churned, with timestamps); your trial start and end dates; the first-touch campaign labels described in Section 1.4; your answers to in-product feedback prompts and the accuracy survey; and the delivery history of emails we send you. Lake does not automatically copy linked-account records, balances, transactions, merchants, holdings, liabilities or derived spending information into that record. Feedback you submit is included as written, so do not add financial details that support does not need. Native and web account lifecycle updates share this record. Native operational updates include signup, first completed bank sync, trial dates and verified paid-access status. Submitted native feedback includes the text and app context you reviewed; optional native screen-view events are not copied into this record. Lifecycle updates do not add financial or merchant details. Section 3.1 describes HubSpot as a processor; Section 6 describes how this record is deleted with your account.

1.6 Native iOS app information

Account name and images. The signed-in app displays an available name or username and profile image from your Clerk account. These can originate from a connected sign-in provider. The app requests the profile image from its HTTPS image address. Merchant images currently come from Plaid-provided logo addresses; the current native financial endpoints do not generate Logo.dev fallback requests. Image hosts receive the requested image address and ordinary network information, including the requesting device’s IP address. A merchant-image address can identify the merchant. Lake does not attach your account token, balance or transaction amount to these image requests. A missing or rejected image displays a local symbol or initials.

Authenticator setup. Clerk currently requires multi-factor authentication. During authenticator enrollment, Clerk creates the setup secret and verifies the code you enter. The app displays that setup information. Backup codes are not currently enabled. If you choose to open an authenticator app, iOS passes the setup address, including its secret and account label, to the app handling that address. That app handles the information under its own terms. Lake does not send these secrets to its financial backend or analytics, or persist them in its own device store; leaving setup or changing account clears the enrollment state. Any copy you save yourself remains where you save it.

Sign in with Apple. Clerk provides account sign-in. If your Lake account is linked to Apple and Lake has no stored revocable grant for that Apple identity, the native app asks you to confirm Apple authorization before entering the main app. This one-time enrollment lets Lake revoke its Apple sign-in authorization when you delete your account. Lake checks the saved grant on later visits; sign-out and account deletion remain available while enrollment is unfinished.

Lake receives an Apple user identifier, identity token and authorization code, and binds the confirmation to your current Lake identity and session using a short-lived challenge. Lake verifies the identity token and exchanges the authorization code with Apple for a refresh token. The grant journal stores a one-way hash of the code, encrypted identity/session and challenge details, an encrypted refresh token, ownership hashes, state and timestamps. It does not retain the raw authorization code or identity token. If Apple returns tokens but Lake cannot finish verifying the exchange, Lake retains those refresh or access tokens encrypted solely to revoke them during cleanup; they do not grant access to Lake. These records support authentication, account ownership, replay prevention and deletion, independently of your optional measurement choice. Section 5 describes their retention.

Apple purchases. When you buy through the App Store, Apple handles your payment method. Lake receives verified purchase information needed to provide access and handle billing changes: product and transaction identifiers, original transaction identifier, purchase and expiry dates, renewal status, refund or revocation status, Apple environment and verification timestamps. Lake creates an account token that links an Apple purchase to the Lake account that made it. Lake does not receive your full card number or Apple Account password. These billing records support entitlement checks, restoration, reconciliation and abuse prevention; they are not sent as optional screen-view events or advertising postbacks. For specifically admitted beta and review accounts, Lake also stores an account-specific Sandbox-access expiry and the intended Apple environment of a pending purchase. Admission lasts at most 30 days per grant and can be withdrawn earlier. Verified test purchases remain distinct from real paid access and are not reported as revenue. The admission field is removed with the Lake account; verified purchase history follows the billing-record retention described in Section 5.

TestFlight beta testing. Apple automatically shares crash logs, usage information and device/build and invitation details with Lake; your name and email may be included. Lake's optional usage setting does not disable this TestFlight collection. If you submit TestFlight feedback, Apple shares your comments, screenshots and accompanying diagnostics with Lake. This is separate from Lake's in-app feedback form. We use TestFlight reports to diagnose and improve the beta. We review them only in App Store Connect, do not download or export them, and do not copy or share them with third parties. See Apple's TestFlight privacy notice and Section 5.

Optional usage measurement. This account choice applies to Lake's website and native iOS app and is off by default. If you turn it on, Lake receives an event when you view your spending summary or the membership screen, together with an event identifier, event name, Lake account identifier, timestamp, platform, app version and build number. This first-party measurement helps us assess those two product experiences. It includes no merchant name, account balance, transaction amount, financial account detail, free-text answer, advertising identifier or general tap history. The events remain in Lake's database and are not sent to advertising networks or HubSpot. We derive return counts from views of your spending summary on at least two distinct UTC calendar days within the retained history; this creates no additional event payload and does not establish that a session was useful to you. When the saved account preference permits measurement and the client has confirmed consent without a pending local refusal, Lake also records whether a newly created goal came from iOS or the website. Goal creation still works when this optional context is withheld. This optional platform field contains no goal name, merchant, target or financial amount. Missing, historical or expired origin stays unknown. Turning measurement off stops these events and clears the optional events and goal-origin fields once the server confirms the change. Necessary account, billing, security and support processing and the separate web practices in Section 1.4 continue.

If saving a refusal fails, the app remembers a one-way hash of the existing Clerk account identifier in app-only preferences so measurement remains paused for that account across sign-out and relaunch. This value is not a new device or installation identifier and is not transmitted for analytics. It is removed when the refusal is confirmed by the server or account deletion begins or completes.

The website uses browser local storage for the same protection: a one-way hash of the existing Lake account identifier and a random marker for the pending change. The marker prevents an older response from clearing a newer refusal; it is not a device identifier and is not sent to Lake. The local pause survives navigation and reload until a confirmed off save, a successful later opt-in, or clearing that browser's site storage. Other devices continue to use the saved account preference until the server applies the change. If the browser blocks this preference storage, these optional events are withheld.

Bank-link continuity. To return from a bank’s authorization page, the website temporarily saves a Plaid Link token, a timestamp and the connection flow, with the originating Lake account identifier for a new link or a connection identifier for reconnecting in browser local storage. A new-connection flow may also include existing Lake connection identifiers, public institution identifiers, bank names and connection status so Lake can warn before adding another connection to the same bank. It does not store bank login credentials or the successful exchange token there. Lake rejects and clears this continuation when it is next read after 30 minutes, and clears it when the flow finishes or is canceled. If you abandon the flow and never return, it can remain until you clear that browser’s site storage.

Saved deletion checks. Before submitting account deletion, the native app saves a signed status receipt in this device's Keychain. It contains a one-way identity hash, validity and expiry times and a signature; the app also stores a local receipt identifier, an account hash and the latest status/dates. It includes no raw account identity, email, bank token or financial details. The receipt permits only a check of this request's pending, next-retry, completed or unavailable status, including after sign-out or removal of the authentication account. It does not grant access to financial data or start another deletion. New receipts expire within 30 days; a receipt issued after completion expires no later than 30 days after completion. Earlier 90-day receipts keep their original expiry, but cannot recover completion records already removed under Section 5. The app keeps at most 16 saved checks and does not silently evict an older pending check to make room; completed or unavailable checks can be dismissed. Keychain access is limited to this device. A next-retry time is not a promised completion date, and an unavailable or expired receipt does not prove deletion finished.

Lake also counts goal creations and settled goal results from the records needed to provide those features. These internal reports contain aggregate counts, separated from optional platform context; they do not add merchant names, spending limits, visit counts or financial amounts to analytics or CRM. Pending results are not treated as failures, and a settled result does not establish that you viewed it.

Goal-result notifications. Only if you enable them, Lake admits a random installation identifier for the signed-in account and registers an Apple Push Notification service (APNs) token, with the app topic, environment, ordered registration revision and expiry. The admission has a random generation identifier and a fixed 90-day expiry; token updates do not extend that period. Lake encrypts the token and retains a one-way token hash. A revocation capability is kept in the app's device-only Keychain so an earlier permission can be withdrawn even after sign-out; Lake stores its hash with the admission and replay-protection records described in Section 5. Notification content is limited to a generic Lake update and an opaque event identifier. It contains no bank, merchant, amount, goal name or reward details. Opening a notification requires the appropriate Lake account to retrieve the actual result. Notification permission does not affect your points, paid access or measurement choice. Delivery is not guaranteed.

Optional nearby and weekly reminders. Nearby reminders are off by default. You choose a merchant and search an area, such as a street, town or ZIP code. The search sends the merchant name and the area you enter to Apple Maps; displaying a map also uses Apple’s map service. Lake does not send your current device coordinates as the search query. Apple processes its service requests under its Maps privacy notice.

If you save a place and enable nearby reminders, iOS checks entry into an approximately 350-foot area around it. Location and notification permissions are requested separately when needed; background matching requires the corresponding iOS permission. Lake keeps up to five selected place names, addresses, coordinates and merchant identifiers, an account-binding hash, reminder preferences and delivery timestamps in protected storage on this device. Lake does not upload this local setup or a device-location history to its backend, analytics or CRM. It does not continuously record a location trail. Local notifications contain generic text; opening one retrieves the signed-in account’s spending context. The independent weekly check-in is a local scheduled notification and does not require location permission. Turning either reminder off cancels its monitoring or schedule but retains its saved setup. Sign-out, account change and account deletion clear the local reminder setup. iOS controls delivery, which is not guaranteed.

Feedback you submit. The native feedback form contains four optional answer fields, with at least one answer required to submit and a limit of 300 UTF-16 units per answer; some emoji use more than one unit. Before submitting, you can review the text and the included app version, build number and iOS version. The form sends a submission identifier and this context under your authenticated Lake account. It uploads no attachments, bank records or automatic diagnostics. Lake holds the submission in an encrypted delivery queue. When native customer-relationship delivery is enabled, Lake sends it to its existing HubSpot support/customer record, using your current account email to associate it. When delivery is disabled, it remains queued until delivery resumes or the queue retention limit is reached. A queued acknowledgement means Lake has saved the submission, not that support has received or read it. Retried submissions are deduplicated. Please omit financial details and other sensitive information that support does not need; we do not automatically add them to your answers. Your answers are submitted as written, so information you choose to type is included even when it describes your finances.

Sharing Lake. If you choose Share Lake, the iOS share sheet shares the public Lake home-page link. It does not include your account, bank data, referral identifier or a conversion claim. The destination app or service you choose handles the share under its own terms. Lake does not upload your contacts or record an attributed referral from this action.

The support screen also lets you choose to share the app version, build, iOS version and notification status displayed there. Those details are included only in the diagnostics share you initiate, without bank data, account identifiers or saved deletion receipts.

The native app has no advertising SDK, IDFA collection or cross-app tracking integration. Clerk's optional native SDK telemetry is disabled; required authentication processing and provider security records still apply. These statements do not change the separate web practices described in Section 1.4.

2. How We Use Your Information

We use your information only for these purposes:

To provide the Service — automatically track spending from linked accounts; identify and display repeat-place or repeat-category habits, usual spend, visit frequency, recent visits, and matched spending-limit context; display accounts, balances, transactions, and selected liability indicators; receive and maintain supported investment holdings and liability details; and run budgets, goals, snapshots, reports, exports, and Insights.
To authenticate you and secure your account — verify who you are, detect and prevent fraud and abuse, and protect the integrity of the Service.
To process payments and administer plans — create and manage subscriptions, one-time purchases, and free trials, and determine which features your plan entitles you to.
To communicate with you about the Service — service, security, billing, trial-status, and account notices; responses to your support requests. These operational messages are part of the Service and are sent to all accounts.
To send marketing communications — with the limits in Section 6, we may send you product news, feature announcements, and offers by email. Every marketing email includes a working unsubscribe link, and unsubscribing never affects your account, your data, or the operational messages in purpose 4.
To measure our advertising and understand usage — the web analytics and advertising-measurement processing described in Section 1.4, campaign attribution as described there, and the optional first-party usage measurement described in Section 1.6.
To improve and personalize the Service — diagnose errors, fix calculations, rank Insights, select among Insight phrasing variants after enough feedback, honor Insight dismissals, and evaluate whether the spending summaries we show are accurate and useful, using your survey and feedback responses.
To comply with law — meet legal, tax, and regulatory obligations, and respond to lawful requests.

We do not use your financial data to build advertising profiles, to train models for sale or licensing to third parties, or for any purpose unrelated to operating Lake for you.

Aggregated and de-identified data. We may create aggregated operational statistics that cannot reasonably be linked to an individual and use them to operate and improve the Service. Lake's current age-group comparison uses published Federal Reserve survey benchmarks, not pooled Lake-user financial data. We do not re-identify de-identified data or license it to third parties.

We share information only in the circumstances below. We do not sell personal information, and we never share your linked-account or financial data with advertisers. The Meta Pixel measurement on our public funnel pages (Sections 1.4 and 3.1) may constitute "sharing" for cross-context behavioral advertising under some state privacy laws; Section 6 describes how to opt out, and the pixel is suppressed automatically for browsers sending the Global Privacy Control signal. It is the only such sharing Lake engages in.

3.1 Service providers who process data for us

Provider	Role	What it receives
Plaid Inc.	Bank account connections and merchant images	Credentials or authorization entered through Plaid Link or your financial institution's OAuth flow, never through Lake, plus authorized financial data and account-owner contact information used by Plaid during connection. Plaid may also collect a phone number when you choose its returning-user flow (Section 1.2). Its image service receives merchant-logo requests and ordinary network information as described in Section 1.6. Plaid's handling is governed by its end-user privacy policy.
Clerk	Authentication and identity	Email address, sign-in identifiers, login/session and security information, optional name/username/profile image, and authenticator enrollment information. A connected sign-in provider may supply profile fields you make available. Profile-image hosting receives image requests as described in Section 1.6.
Apple Inc. — Sign in with Apple, App Store, TestFlight, APNs and Maps	Native authorization/revocation, purchases, beta testing, optional notifications and place search/maps	Lake and Apple exchange the sign-in, token-revocation, purchase/account-token, beta-testing and notification information described in Section 1.6. Optional place searches send merchant and entered-area text to Maps. Apple handles payment details and its own account, authentication, billing, maps and delivery records under its terms.
Stripe, Inc.	Web payment processing	Your payment method and billing details, entered directly with Stripe. Lake never receives your full card number. We store only Stripe's customer and subscription identifiers, your plan, and its status.
Neon	Database hosting	All data described in Section 1 that we store, as our hosting infrastructure
Vercel Inc. — hosting	Application hosting, scheduled jobs, and server/security logging	Requests and application data processed in transit, plus the request and log information described in Section 1.4
Vercel Inc. — Web Analytics	Cookie-free route and page-view analytics	The analytics information described in Section 1.4. Lake sends no custom events and normalizes the two sensitive detail-route values described there before transmission.
HubSpot, Inc.	Customer-relationship management and email delivery	Your email address and the customer-relationship record described in Section 1.5: lifecycle stage and timestamps, trial dates, first-touch campaign labels, and your feedback and survey answers. Lake does not automatically add linked-account records or derived spending details; feedback is included as written. Governed by HubSpot's privacy policy at legal.hubspot.com/privacy-policy.
Trove (Headline)	Transaction enrichment	For each transaction we enrich: the description, amount, date, and a pseudonymous Lake user identifier. Not your name, email, bank-account numbers, or balances.
Logo.dev	Website merchant logos	Requests are made from your browser, exposing its IP address and the merchant domain requested. Lake does not attach your account identifier, balance or transaction amount. The current native financial endpoints do not generate this fallback. Logo.dev describes API request logs in its privacy policy.
Google Workspace / Gmail	Receiving support email sent to support@lakefin.net	Sender address, recipient address, subject, message body, attachments, and email routing metadata included with the message
Google LLC — Google Analytics 4	Site-wide usage analytics (measurement only; Google Signals and ad-personalization disabled)	First-party analytics cookies (including `_ga`), IP address, browser and device information, and pages visited with sensitive detail URLs normalized to route placeholders before transmission. Never linked-account data, balances, or transactions. Governed by Google's privacy policy at policies.google.com/privacy.
Meta Platforms, Inc.	Advertising measurement via the Meta Pixel, on public funnel pages only	Cookie identifiers (including `_fbp`), IP address, browser and device information, referrer, and which of the landing, sign-in, sign-up, or welcome pages was visited, including a signup-completed event. Never your identity as a Lake member, and never linked-account data, balances, or transactions. Suppressed entirely for browsers sending Global Privacy Control. Governed by Meta's own privacy policy at facebook.com/privacy.

Lake uses these providers for the roles listed above. Their agreements and published terms govern their processing, and some providers may have independent legal obligations or expressly permitted uses, including billing recordkeeping or use of de-identified or aggregated data. They are independent companies with their own security programs; we do not control them.

Support messages. Google Workspace / Gmail receives support and legal notices sent to support@lakefin.net. Native feedback submitted inside Lake uses the separate encrypted queue and configured HubSpot delivery described in Section 1.6. The native feedback flow adds no artificial-intelligence drafting service. Replies are written by us. Support correspondence is retained as described in Section 5 and is deleted on request.

We also continue to monitor contact@rieper.org directly for notices sent under the prior policy.

3.2 Other disclosures

When you ask us to — for example, when you export your transactions to CSV, or explicitly direct us to share something.
Legal requirements — when we reasonably believe disclosure is required by law, subpoena, court order, or lawful government request. Where permitted, we will attempt to notify you first.
Protecting rights and safety — to investigate fraud, enforce our Terms, or protect the rights, property, or safety of Lake, our users, or the public.
Business transfer — if Lake is involved in a merger, acquisition, financing, or sale of assets, information may transfer as part of that transaction. We will notify you before your information becomes subject to a materially different privacy policy, and you will have the opportunity to delete your account first.

Other than the funnel-page Meta Pixel measurement described in Sections 1.4 and 3.1, we do not disclose your information to data brokers, advertising networks, or credit reporting agencies.

4. How We Protect Your Information

Encryption in transit. All traffic to and from the Service uses TLS.
Encryption at rest for the most sensitive fields. Plaid access tokens, optional profile fields, native Apple authorization bindings and grant receipts, notification tokens, pending account-cleanup instructions, pending bank-exchange receipts and queued native feedback are encrypted with AES-256-GCM using a key held outside the database, in addition to the encryption our database provider applies to storage.
We never store bank credentials. There is nothing in our systems to steal in that category.
Ownership scoping. User-specific records are tied directly to your user identifier or through an owned parent record. Authenticated application queries and routes are designed to enforce that ownership boundary.
Authenticated webhooks. Incoming notifications from Plaid are cryptographically verified (ES256 signature) and rejected if verification fails.
Least-privilege secrets. Provider credentials are held as environment secrets, not in source code, and the application refuses to start without the required ones.

No system is perfectly secure. We cannot guarantee that unauthorized access will never occur. Protect your side of it too: use a strong, unique password, enable multi-factor authentication where offered, keep your email account secure, and tell us at support@lakefin.net if something looks wrong.

If we discover a breach affecting your personal information, we will notify you and any required authorities as required by applicable law, without unreasonable delay.

5. How Long We Keep Information

Data	Retention
Account and financial data	For as long as your account is open
Data for a disconnected institution	Deleted from Lake's active database when you remove that institution from Settings, subject to the backup and provider rules below
Optional profile (birth year and any legacy gender value)	Until you delete it from Settings or delete your account, subject to the backup rule below
Active Lake database records linked to your user	Deleted from the active Service when you delete your account, subject to the exceptions below (see Section 6)
Neon database backups and point-in-time recovery history	Our database's configured point-in-time recovery window is currently six hours (verified September 17, 2026); deleted rows leave recovery history when that window lapses. If we lengthen the window, it will not exceed 30 days, and this policy will be updated.
Customer-relationship record (HubSpot)	Account deletion queues contact archival and retries it if the provider is unavailable. Deletion is not reported complete while this step is pending. HubSpot may retain residual or recoverable copies under its own policies; verify provider purge/retention before treating archival as full erasure.
Trove enrichment request data	Trove receives enrichment requests as described in Section 3.1 and handles them under its own agreements and policies; a fixed retention period has not been confirmed. We will update this row when that information is established. The requests never contain your name, email, or account numbers.
In-app Insight feedback, accuracy-survey answers, and feedback-prompt records	Retained with the active Lake account and deleted from the active database when the account is deleted, subject to the Neon backup rule above; copies written to the customer-relationship record follow the HubSpot row above
Support correspondence	Retained in our support mailbox until deleted manually; deleted on request (Section 6). Not deleted automatically when you delete your Lake account.
Billing and transaction records held by Stripe or Apple	Retained by the billing provider under its terms and applicable recordkeeping obligations, independent of your Lake account. Local Apple purchase/account-token records are removed with your Lake account; deletion does not cancel the provider subscription.
TestFlight beta reports	Apple retains beta feedback for one year and may retain crash and usage data until bugs are resolved. Lake keeps no separately downloaded or exported copies. Apple-held installation and other records follow its privacy notice.
Vercel server and security logs	Retained or made available under Lake's then-current Vercel plan and configuration and Vercel's applicable terms; reporting availability is not necessarily the same as deletion
Vercel Web Analytics	Retained or made available under Lake's then-current Vercel plan and Vercel's applicable terms. The 24-hour visitor-identification-hash lifecycle described in Section 1.4 is not a page-view deletion period.
Campaign attribution cookie (`lake_utm`)	Expires from your browser after at most 90 days; the copied campaign labels on your customer-relationship record follow the HubSpot row above
Optional first-party web/native usage events and goal origin	View events expire after 90 days. The optional iOS/web goal-origin field is cleared 90 days after goal creation. Confirmed withdrawal or account deletion removes both earlier. Derived later-day return counts use only retained consented view history. Scheduled cleanup enforces expiry; necessary goal/result records follow their existing retention and are not deleted by a measurement choice.
Minimal verified billing lifecycle events in Lake's business service	Expire after 90 days or are removed on account deletion; they are separate from optional usage events and provider-held billing records.
Native feedback delivery queue	Feedback text and app context are encrypted while pending. Delivery or final failure clears the ciphertext. Pending submissions expire after 90 days and have their ciphertext cleared. Terminal delivery/deduplication records, including a keyed digest, expire 90 days after completion or failure. Account deletion removes the owned queue records earlier; a delivered HubSpot copy follows the HubSpot row above.
Pending account deletion	The encrypted Clerk identity, email, Plaid cleanup credentials and verified Apple subject/client revocation results are kept only while needed to finish the requested cleanup. During deletion, Lake also retrieves an available Apple web sign-in access token from Clerk when needed for revocation and saves it only in the encrypted cleanup instructions. Apple-confirmed revocation clears that token. Each completed step removes the data it no longer needs. Once cleanup completes, Lake removes the ciphertext and original Lake account identifier and keeps a one-way identity hash, any manual Apple-revocation flag, and limited request/retry timestamps and count for 30 days to prevent replay or accidental account recreation. Scheduled cleanup removes that completed record. Unresolved provider outcomes remain pending for reconciliation rather than being reported as completed deletion.
Native Apple sign-in grants and pending token cleanup	The encrypted refresh token and grant binding remain while needed to provide account access and revoke the authorization on deletion. Returned tokens whose exchange could not be verified remain encrypted solely for cleanup. Confirmed revocation clears each retained token. The ownership-hash binding is removed when account deletion completes. An unresolved exchange or revocation remains pending for reconciliation, without a fixed completion deadline.
Native Apple authorization challenges and replay records	A challenge can be used for five minutes; its encrypted identity/session binding, identity hash and use/expiry times become eligible for scheduled cleanup 30 days after expiry. The grant journal keeps authorization-code, identity and Apple subject/client hashes, challenge identifiers, state, timestamps and encrypted binding details. Unexchanged, rejected or revoked attempts become eligible for scheduled cleanup 30 days after their last update. Active grants and unresolved exchanges are excluded from that expiry rule and follow the preceding row. These security periods are Lake choices, not claims that a law requires retention.
Bank-exchange recovery records	A one-way public-token hash, owner identifier, state and timestamps support retries. An exchanged access token and item identifier, any explicit confirmation of an existing connection at the same institution, and a cleanup reason are encrypted until the bank connection is durably saved or removed. Unused or terminal attempts expire after 30 days; unresolved receipts remain only while needed for connection recovery or deletion. Account deletion removes the associated attempts once cleanup is possible.
Native request-limit windows	One-way scope hashes, counters and expiry times are kept for one minute and removed on subsequent request admission. No raw address or identity is stored in these windows.
Optional notification registration and delivery	Registered devices expire with their admission, 90 days after that admission is issued; a token update does not extend it. Result events and delivery eligibility expire after 32 days for date-anchored goals. Legacy calendar-month results keep their next-month-first-day 14:00 UTC cutoff, at most 32 days after creation. Cleanup removes expired records. Withdrawal removes the owned device/token and delivery records, and account deletion removes owned notification records.
On-device nearby and weekly reminder setup	Selected places, account binding, preferences and delivery timestamps stay in protected storage on this device while saved. Turning reminders off retains the setup; removing a place removes its saved selection. Sign-out, account change and account deletion clear the setup and cancel monitoring/schedules. Lake holds no server copy of it.
Notification admission and replay protection	The random installation and admission-generation identifiers, account identifier, hashed revocation capability, revision, last action and fixed expiry prevent old registrations from being replayed. Withdrawal retains this record until the admission expires, without the APNs token. Account deletion removes account-owned admissions; expired admissions and legacy unowned replay records are removed in bounded cleanup batches. Expired or earlier admission generations cannot register again. Re-admission creates a new generation with a new 90-day period. These are security records, not a claim of anonymous data or legally required retention.
Saved native deletion checks	New signed status capabilities expire within 30 days and no later than 30 days after an already completed request. Earlier 90-day capabilities retain their signed expiry. Device-only Keychain retains the account hash, local receipt ID and latest status until you dismiss a completed or unavailable check. At most 16 checks are stored, with no silent eviction. The server stores no separate receipt table: it reads the limited deletion record above, retained for 30 days after completion. A legacy check can become unavailable before its receipt expires. Receipt expiry does not stop unfinished cleanup or prove completion.
Saved website deletion check	A necessary HttpOnly cookie holds one signed status receipt for up to 30 days, never beyond 30 days after an already completed request. A later prepared deletion replaces this browser's saved check. Lake stores no separate receipt table; it reads the same limited deletion record retained for 30 days after completion. Cookie expiry or removal does not stop pending cleanup or prove completion.
Browser pending measurement refusal	Browser local storage keeps a hash of the existing Lake account ID and a per-change random marker until confirmed off, successful explicit later opt-in, or clearing site storage. These values are not transmitted for analytics.
On-device pending measurement refusal	An app-only hash of the existing Clerk account identifier is retained across sign-out/relaunch until the server confirms the refusal or account deletion begins or completes. It is not sent for analytics.
Aggregated, de-identified statistics	May be retained indefinitely, as they no longer identify you

6. Your Choices and Rights

Several controls for data in the active Service are available directly in the app; other requests and provider or retention exceptions are described below.

In the app, at any time:

Disconnect an institution — Settings. Lake attempts to instruct Plaid to remove the connection, then deletes that institution's active Lake records, including its accounts, transactions, attachments, holdings, and liability details.
Delete your optional profile — Settings. Removes your birth year and any legacy gender value without affecting anything else, subject to the Neon backup rule in Section 5.
Edit or delete your notes, attachments, budgets, goals, and categorization rules — wherever you created them.
Export your transactions to CSV — available on Premium and Lifetime plans and during an active free trial.
Delete your account — Settings. Lake first saves limited encrypted cleanup instructions and removes the active Lake account records, including linked accounts, transactions, notes, attachments, budgets, goals, snapshots, alerts, local subscriptions, survey answers, feedback queues and owned notification records. It removes the Plaid connections, revokes retained Apple sign-in credentials before removing the Clerk identity, and removes the HubSpot contact, retrying unfinished steps. A pending-deletion message means provider cleanup is still outstanding; signing in does not recreate the deleted Lake account. You can retry deletion, and Lake continues scheduled cleanup. The native saved receipt lets you check pending or completed cleanup after sign-out or removal of your sign-in account, subject to the expiry and retention limits in Section 5. If a legacy Apple-linked account has no matching retained grant, the status also directs you to remove Lake under Sign in with Apple in your Apple Account settings; Lake does not claim automatic revocation of that missing grant. A missing provider response or unreadable credential requires provider reconciliation before completion can be confirmed. Deleted account data is unavailable through the active Service and cannot be restored by you. The limited records in Section 5, including unresolved cleanup and security records, follow their stated retention rules. Deleting Lake or deleting your account does not cancel an Apple or Stripe subscription. Cancel through Apple Account subscription settings for App Store purchases or the billing portal for Stripe purchases. You may still request immediate account deletion.
Turn off optional first-party usage measurement — the native or web privacy control pauses collection locally and requests that Lake stop and delete these optional events and goal-origin fields for your account. A failed save keeps collection paused on that device or browser; other devices use the saved account preference until the server applies the change. The control does not change the separate web analytics/cookie practices in Section 1.4. Necessary billing, security and support processing continues.
Turn off goal-result notifications — use the app control or iOS notification settings. Revocation removes the Lake device registration and prevents future eligible sends; Apple/device settings also control presentation.
Turn off nearby reminders or the weekly check-in — each has a separate control in the native app. You can remove individual saved places and change location permission in iOS Settings. These choices do not enable optional measurement or affect account access.

Marketing email. We send marketing email only about Lake itself — product news, feature announcements, and offers. Every marketing email contains a working unsubscribe link that takes effect promptly, and you can also write to support@lakefin.net to be unsubscribed. Unsubscribing does not affect service, security, billing, or trial-status messages, which are part of operating your account. We do not send marketing on behalf of third parties.

By contacting us at support@lakefin.net, you may also:

Access the personal information we hold about you, in a portable form
Correct inaccurate information
Delete your information, if you prefer we do it rather than doing it yourself
Withdraw consent for any optional processing
Ask questions about anything in this policy

We will respond within 45 days, and will tell you if we need more time. We do not charge for these requests, and we will never penalize you, degrade your service, or change your price for making one.

Verification. To protect you, we will verify a request by confirming control of the email address on your account before acting on it.

State privacy laws. Depending on where you live — including under the Indiana Consumer Data Protection Act, the California Consumer Privacy Act, and comparable laws in other states — you may have statutory rights to access, correct, delete, port, and opt out of certain processing, and to appeal a denied request. Some of these laws may not currently apply to Lake because of our size, and some financial data is exempt from them under the Gramm-Leach-Bliley Act. We extend the rights described in this section to all Lake users regardless of whether a statute compels it. If we deny a request, we will explain why and how to appeal; you may also contact your state Attorney General.

Opting out of ad-measurement sharing. The only cross-context sharing Lake engages in is the funnel-page Meta Pixel described in Sections 1.4 and 3.1. Lake honors the Global Privacy Control (GPC) signal: when your browser sends it, the pixel does not load and nothing is sent to Meta. You can also prevent the pixel with browser tracking protection or by blocking third-party cookies, limit Meta's use of collected data at facebook.com/adpreferences, or write to us and we will explain what Meta received. It never involves your linked-account or financial data.

7. Children's Privacy

Lake is intended for users 18 and older. We do not knowingly collect personal information from anyone under 18. If you believe a minor has provided us information, contact support@lakefin.net and we will delete the account and its active Lake records, subject to the provider, support-record, backup, and legal-retention exceptions in Section 5.

8. Location of Processing

Lake is operated from the United States and currently serves users in the United States. Your information is stored and processed in the United States and in other locations where our service providers operate infrastructure. If you access the Service from outside the United States, you understand your information will be processed in the United States, where privacy laws may differ from those in your location.

9. Changes to This Policy

We may update this Privacy Policy. A change is material if it expands the categories of personal information we collect, adds a new category of recipient or a new purpose for sharing, reduces your rights or choices, or lengthens retention of identifiable data. For material changes, we will give at least 14 days' advance notice by a prominent notice in the Service — and by email once we operate a service-email channel — before the change takes effect, and the notice will state the effective date. Non-material changes (clarifications, provider renames, corrections that do not expand collection or sharing) take effect when posted with an updated "Last updated" date. Continuing to use the Service after a change's effective date means you accept it; if you do not accept a change, stop using the Service and delete your account before the effective date. We preserve superseded versions, including the July 24, 2026 original and its hash, and will provide any prior version on request. A revision to this Privacy Policy does not change the arbitration opt-out period in the Terms of Service, which runs from your first acceptance of the Terms.

10. Contact Us

Questions, requests, or concerns about privacy:

Rieper LLC (d/b/a Lake Financial)
c/o Registered Agents Inc
5534 Saint Joe Road
Fort Wayne, IN 46835
United States

Email: support@lakefin.net
Web: www.lakefin.net

Rieper LLC is an Indiana limited liability company, Business ID 202607202020836, operating under the assumed business name Lake Financial. This Privacy Policy is incorporated into the Lake Terms of Service.