How Finn handles your data: privacy and security for institutional users

Funds evaluating Finn ask the same questions in roughly the same order: what do you store, where does it live, who can see it, does it train your models, and can we run it inside our own perimeter. This page answers them directly. Where an answer depends on your deployment scope, it says so.

The short version: Segregated per client. Never shared. Never sold. Never used to train models for anyone else.

What Finn actually holds

Finn is useful because it knows your book. That means it holds your positions and watchlist, the thesis you maintain on each name, the notes and reports it has written for you, and the research you forward to it. Over time this becomes a private research corpus — every note and thesis compounds into a knowledge base that belongs to you.

That corpus is the point of the product, so the commitments around it are absolute:

Your data is segregated per client. Portfolio, theses, and corpus are held separately for each client. There is no shared pool, no cross-client retrieval, no aggregation across funds.

Your data is never used to train models for anyone else. Finn’s personalization to your style comes from your own corpus and memory, applied to you. Nothing you send Finn improves output for another client, and nothing is shared or sold. Ever.

Finn’s market data comes from licensed providers, not scraping. Company fundamentals, filings, and news run on licensed institutional data sources. You are not building research on unverifiable feeds, and your compliance team is not approving one.

Why email-native matters for compliance

Finn works through email and the calendar rather than a new platform. That is a workflow choice, but it is also a compliance property: everything Finn sends and receives travels through the communication channel your firm already archives and supervises. There is no separate chat log sitting outside your retention stack, no new endpoint for IT to approve, no export process to reconcile at audit time. Your existing archival captures the full record by default.

The same design keeps Finn cleanly on the research side of the regulatory line. Finn produces analysis, not investment recommendations. It does not execute trades, route orders, or touch broker connectivity. For a regulated fund, that means Finn sits in the same category as a junior analyst’s written work — reviewable, archivable, and outside the execution chain.

Deployment options

Different funds have different perimeter requirements, so Finn runs in three modes:

Standard (SaaS). Segregated tenancy on Finn’s infrastructure. The fastest path to running; suitable for funds whose policies permit vetted external SaaS. [CONFIRM: cloud provider + hosting region(s) — state them here; ODD teams will ask first.]

Private cloud. Finn deployed into a dedicated environment to meet data-residency requirements — your region, your jurisdiction. Scoped per engagement.

Dedicated deployment. For funds whose infosec requirements rule out shared infrastructure entirely, a dedicated deployment is available subject to scope. This is a conversation, not a checkbox — bring your security team and we will map Finn’s architecture against your requirements.

Model providers and subprocessors

Finn uses a multi-model architecture with multi-stage review rather than a single LLM pass. [CONFIRM: name the model providers, and state the retention terms of those API agreements — e.g. zero-data-retention or 30-day — plus whether provider-side training on API inputs is contractually excluded. This is the second question every DDQ asks; vagueness here reads as a red flag.] A current subprocessor list is available on request. [CONFIRM: the list exists and someone owns keeping it current.]

Retention and deletion

Your corpus exists to serve you, and it leaves when you do. On termination, client data is deleted on request. [CONFIRM: deletion SLA in days, backup-cycle carve-out, and whether an export of the corpus is provided — then state all three as numbers, not adverbs.]

Security review and due diligence

We complete security questionnaires and operational due diligence requests as part of institutional onboarding, and we walk security teams through the architecture under NDA. [CONFIRM: SOC 2 / ISO 27001 status. If a certification is held or formally in progress, state which and the timeline. If neither, say nothing here — an honest architecture review under NDA is credible; an implied certification that a DDQ then disproves is disqualifying.]

The short version

Your portfolio, theses, and research corpus are segregated, never shared, never sold, and never used to train models for others. Finn’s outputs travel through your existing archived email, inside workflows your compliance stack already supervises. Finn analyses; it never recommends trades or executes them. And if your infosec requirements need Finn inside your own perimeter, private-cloud and dedicated deployments exist for exactly that conversation.