Sub-processors
Last updated: August 6, 2026
The tables under “Sub-processors engaged by Well” below form part of Well’s data processing agreement and are the current list of Sub-processors engaged under Section 8 of that agreement. The later sections (systems you connect yourself, providers loaded in your browser, and vendors Well uses for its own business) are published for transparency and are not Sub-processors appointed by Well.
Before adding or replacing a Sub-processor, Well updates this page and notifies the administrative contact on the account at least 30 days in advance. You may object on reasonable data protection grounds within those 30 days by writing to privacy@wellapp.ai.
Where your data is processed, and under what
Well App, Inc. is a Delaware company. When Well processes personal data contained in your workspace, you are the controller and Well is the processor. Well’s application services run in Google Cloud’s us-central1 region, in Iowa, United States. Well does not offer European data residency, and this page does not imply otherwise.
Transfers out of the EEA, the United Kingdom and Switzerland rely on the European Commission’s standard contractual clauses, Module 2 (controller to processor), as set out in Section 6 of the data processing agreement. Well remains liable to you for its Sub-processors’ performance and imposes data protection obligations on them no less protective than those in that agreement. Section 4 of the privacy policy describes the same processing from the controller side, and your commercial terms are in the terms and conditions.
Three things sit in Europe today and are worth naming, because the rest of this page is a United States answer. Bank connections for institutions in the EEA and the United Kingdom run through Well’s European Plaid registration, for which Plaid names Plaid B.V. in Amsterdam, supervised by De Nederlandsche Bank, as the responsible entity. Well’s AI monitoring provider, Langfuse, is configured by default to its European region, and receives no content from your records in any case. And the compute region above is pinned in Well’s deployment configuration rather than left to a provider default, so it is a fact Well can be held to.
What Well does not have
Stated here so you do not have to discover it later in an assessment.
- No European hosting region. There is no EU deployment of Well today, and no published date for one.
- No published Article 27 representative in the Union. Well does not currently publish a designated representative; the contact for all data protection matters is privacy@wellapp.ai.
- No SOC 2 Type II report and no ISO 27001 certification. Where Well holds a SOC 2 Type I report, that report attests to the design of controls at a point in time and not to their operation over a period. Section 12 of the data processing agreement sets out how to obtain it.
- No published retention schedule per data category. Return and deletion on termination are governed by Section 11 of the data processing agreement; retention during the contract is not yet published as a table.
- No verified processing location for every provider below. Where Well has not established a provider’s processing location from that provider’s own published terms or from Well’s own configuration, the table says the location is determined by the provider rather than asserting a region.
Sub-processors engaged by Well
Grouped by the role each provider plays, because the four groups carry materially different data. “Where it processes” states what Well has verified, from Well’s own configuration or from the provider’s published terms.
Infrastructure and hosting
These providers hold or observe the platform itself. Everything you put into Well passes through the first row.
| Provider | What it does for Well | Personal data it processes | Where it processes |
|---|---|---|---|
| Google Cloud Platform (Google) | Hosts the Well platform: the API, the web application, the GraphQL query layer, the managed database, object storage for documents and media, job queues, and server logs. | All customer data held in Well, including bank transactions, invoices and their source documents, accounting records, email content and metadata, contact records for named individuals, and uploaded files. | Compute (the API, the web application, the GraphQL query layer and the job queues) runs in Google Cloud's us-central1 region (Iowa, United States). That region is pinned in Well's deployment configuration. The managed database and the document and media buckets are not region-pinned in that configuration, and Well does not claim European residency for them: the data processing agreement states plainly that Well does not offer European data residency. |
| Firebase Authentication (Google) | Identity provider. Handles sign-in with Google or Microsoft and issues the session tokens Well validates on every authenticated request. | Account identifier, email address, display name and profile photo URL released by the chosen identity provider, plus Firebase's own account and sign-in metadata, including sign-in timestamps and the IP address of each sign-in, which Google says it retains for a few weeks. | United States. Google publishes that Firebase Authentication runs only from US data centres and processes data exclusively in the United States, and that it encrypts this data at rest. |
| Firebase Remote Config (Google) | Holds the platform's feature-flag configuration. Well's API and web application read it to decide which surfaces and behaviours are switched on. | The flag configuration itself. No customer financial records, documents or contact records are sent to it. | Global. Google classes Remote Config as a global service, which may process at any Google Cloud location. That is a different answer from Firebase Authentication's US-only one. |
| Axiom | Application logging and error telemetry for the Well web application's own server-side route handlers and unhandled server errors. | Request and error telemetry, which can include account identifiers and the contents of failing requests. This is the web application's own request layer, not a telemetry pipe over your financial records. | Well's code sets no Axiom region, so the SDK's default United States endpoint applies. Axiom also operates an EU region. |
AI model providers
These providers see the content of your records. Well does not state a retention or model-training position on any provider's behalf. Each publishes its own terms, and the location column below says what those terms and Well's own configuration establish.
| Provider | What it does for Well | Personal data it processes | Where it processes |
|---|---|---|---|
| Gemini API (Google) | Default model provider for document, transaction and reconciliation processing: document classification, invoice and receipt extraction, optical character recognition, transaction categorisation, matching, and company identity resolution. | Document contents including page images; transaction details such as amount, date, remittance text, merchant and counterparty names; email content from a connected mailbox where Well scans it for banking and accounting signals; company and contact identity fields. | Well calls Google's Gemini developer API, which offers no choice of processing region. Google states that prompts and responses may be stored transiently or cached in any country in which Google or its agents maintain facilities. Google offers regional processing for the same models through Vertex AI; Well does not currently use it. |
| Anthropic | Model provider for the in-product assistant and agent, the month-close assistant, extraction of documents other than invoices, the browser agent that collects documents from third-party portals, and failover for background classification and matching. | Conversation content; the records the assistant reads to answer a question; the text of documents attached to a conversation or uploaded; and page content and screenshots of portals the agent navigates on the customer's behalf. | Anthropic's standard API endpoint. Well pins no region. |
| OpenAI | Model provider for generating the field mapping between a newly connected tool's API and Well's schema, naming conversations, vendor classification, and failover for document classification and extraction. | Sample records fetched live from a customer's connected accounting or banking tool during mapping generation; chat message content used to title a conversation; document text on the failover path; company names and domains. | Well calls OpenAI's default global API endpoint. OpenAI publishes a European (EEA and Switzerland) data-residency endpoint covering both storage and processing for the services Well uses; Well does not currently use it. |
| LlamaCloud and LlamaParse (LlamaIndex) | Cloud document parsing. Well sends an uploaded document to LlamaParse when Well's own parser cannot read it reliably: an empty or unusable local parse, or a quality check that fails after extraction. | The full contents of the uploaded document, including page images. This is the most sensitive payload Well sends to any provider on this page. | The LlamaCloud client defaults to LlamaIndex's United States endpoint, and Well's application configuration sets no override. LlamaIndex also operates a European endpoint. |
| Langfuse | Monitoring of Well's AI system. Well records a trace for each model call: which model, which product function, token counts, latency and cost. | Structural telemetry only. Well disables prompt and completion capture, so the content of your records is not sent to Langfuse. | Langfuse operates separate European and United States regions. Well's configured default is the European region. |
Connectivity, enrichment and lookup
These providers either carry data in from a system you connect, or receive slices of your records so Well can identify and enrich the companies and people in them.
| Provider | What it does for Well | Personal data it processes | Where it processes |
|---|---|---|---|
| Plaid | Bank connectivity. Establishes and maintains connections to customer bank accounts. | Bank account identifiers, balances, transaction records, and the account holder's name and contact details as returned by the institution. | Well holds separate European and United States Plaid registrations and connects institutions in the EEA and the United Kingdom through the European one. Plaid names Plaid B.V. (Amsterdam), supervised by De Nederlandsche Bank, as the entity responsible for individuals in the EEA. Plaid's own processing locations are determined by Plaid. |
| Chift | Accounting and invoicing connectivity for providers reached through the Chift aggregator: Evoliz and Sellsy. Both are marked coming soon in Well's catalogue and cannot currently be connected, so no customer data reaches Chift today. Well lists Chift in advance because the route is contractually engaged. Qonto is not reached through Chift. Well integrates with Qonto directly through its own connector, and can also read Qonto bank transactions through Plaid's European configuration. | Once the route is live: invoice and accounting records retrieved from the connected system, and the account-holder details Well passes when a connection is established. None today. | Determined by Chift. |
| FullEnrich | Contact enrichment. Well sends the identity attributes it holds for a person in your records and receives additional contact details back. | The name, email address and LinkedIn URL of individuals in your records. FullEnrich returns further contact details for those individuals. | Determined by FullEnrich. |
| Exa | Web search and content retrieval, used to identify and enrich the companies and people in your workspace. | Search queries built from your records: a counterparty's company name together with its website domain, a company name you type into Well's company lookup, and on contact-enrichment paths the name of an individual. | Determined by Exa. |
| Linkup | Web search used by Well's assistant and enrichment paths when a lookup needs current information from the open web. | Search queries built from your records, typically company names and website domains. | Determined by Linkup. |
| Pappers | French and European company registry lookups, used to resolve the identity of the companies in your records. | Company names, website domains and registration numbers (SIREN, SIRET, VAT) drawn from your records, and on a cold-start signup with no company domain, the account holder's own name. Responses are registry records, which routinely name legal representatives, directors and beneficial owners. For a sole trader, the company record is a record about a person. | Determined by Pappers. |
| OpenCorporates | Company registry lookups outside the French and European registries above. | Company names, domains and registration identifiers. Registry responses can include the names of directors, legal representatives and beneficial owners. | Determined by OpenCorporates. |
| TheirStack | Company lookup when you create your workspace, used to pre-fill your company's profile. | The domain part of the account holder's email address, never the full address and never a name. TheirStack returns company attributes such as country, city, size and industry. | Determined by TheirStack. |
| ipapi.co (Kloudend, Inc.) | IP geolocation. Used to pre-select billing currency at signup, to suggest the right banking region during setup, and as a country signal when identifying your company. | The IP address of your visitors and users. | United States. ipapi.co is operated by Kloudend, Inc., a United States company. |
| logo.dev | Supplies company logos. Well's servers request a logo for a company you transact with, keyed on that company's web domain. | The web domains of companies in your records. See also the browser-side request described below. | Determined by logo.dev. |
Communications and operational alerting
These providers carry messages out of Well, either to your users or to Well's own engineers when something breaks.
| Provider | What it does for Well | Personal data it processes | Where it processes |
|---|---|---|---|
| Twilio SendGrid | Sends transactional and notification email on Well's behalf. | Recipient email address and name; the subject and content of the message; any files attached to it, including customer source documents such as invoices and receipts where a workspace forwards documents by email; and the per-recipient delivery, open, click and bounce events SendGrid generates and returns to Well. | Well sends through SendGrid's global region (api.sendgrid.com). Twilio offers an EU data-residency region; Well does not currently use it. |
| WAX | Delivers the one-time code that verifies a Well user's phone number, and the confirmation message sent once that verification succeeds. | The phone number of a user who chooses to verify it, their first name, the name of their workspace, and the one-time code. | Determined by WAX. |
| Slack | Internal operational alerting. Well's engineers are notified in Slack when a connector or a document collection fails, so the failure can be repaired. | Your workspace name and identifier, the connector or collection involved, and the technical error message returned by the failing system. | Determined by Slack. |
Loaded in your browser
Two providers are contacted directly by your users’ browsers rather than by Well’s servers. That is a different transfer from the tables above: the request carries your user’s IP address and user agent, and it happens outside any server-side control Well applies. Google contracts Maps Platform on controller-to-controller terms, so it is listed here rather than as a Sub-processor.
| Provider | Why it is contacted | What it receives |
|---|---|---|
| Maps Platform (Google) | Address autocomplete in the records editor. | The address text your user types, together with their browser's IP address and user agent. |
| logo.dev | Company logos rendered next to a counterparty in records and chat. | The company domain being displayed, together with your user's IP address and user agent. |
Vendors Well uses for its own business
For these, Well is the controller rather than your processor: they support Well’s own billing and its own commercial relationship with you, not the processing of the records in your workspace. They are listed because they receive personal data, but the objection right in Section 8 of the data processing agreement attaches to the Sub-processor tables above, not to this section. Section 4 of the privacy policy covers Well’s controller-side processing.
| Provider | What it does | Personal data it receives |
|---|---|---|
| Stripe | Payment processing for Well's own subscription billing. | Billing contact details, subscription and payment records. Card details are collected by Stripe directly and are not held by Well. |
| Attio | Well's own CRM, holding signups, waitlist entries and prospect records. | The email address of a person who signs up or joins the waitlist, and how they reached Well. |
| Cargo | Enriches a new account holder's profile at signup so Well can set up the workspace with the right context. | The signup email address or LinkedIn URL used as a lookup key, and the name, job title, phone number and company returned against it. |
Systems you connect yourself
Well reads from accounting, banking, email, storage and CRM systems that you authorise through OAuth: for example Pennylane, QuickBooks, Xero, Qonto, Google Workspace, Microsoft 365 and Dropbox. Well does not appoint those providers and does not contract with them on your behalf; you already hold your own relationship and your own terms with each one. They are therefore listed here for transparency rather than as Sub-processors appointed by Well.
Two clarifications an auditor usually asks for. Well registers and holds the OAuth client credentials for several of these integrations; those credentials identify the requesting application only, while the access token you grant authorises access to your own account. And once data is retrieved from a system you connected, Well processes it. That processing, and the Sub-processors above who take part in it, are covered by the data processing agreement.
The same applies if you connect Well to an AI client of your own through the Model Context Protocol. That client’s model provider receives whatever data you ask it to read. You choose that provider, not Well.
The questions we are asked most
- Does my data leave the EEA? Yes. All of it. The platform runs in the United States and the model providers are contacted on their global endpoints, with the exceptions named at the top of this page.
- Under what transfer mechanism? The European Commission’s standard contractual clauses, Module 2, per Section 6 of the data processing agreement.
- Which providers see the content of my records? Google Cloud, which hosts everything, and the AI model providers listed in the second table. Every other provider receives a defined slice, described in its row.
- Does the browser agent send screenshots? Yes. When the agent collects documents from a third-party portal on your behalf, the page content and screenshots of that portal go to Anthropic, as stated in its row.
- Do you train models on my data? Well does not train models on customer data. Well does not make commitments on a provider’s behalf about its own retention or training; each provider publishes its terms, and Well will supply the terms and the data protection agreement it holds for any provider on this page on request.
- Can I get a countersigned DPA? Yes. Write to privacy@wellapp.ai and name your contracting entity.
Questions
Write to privacy@wellapp.ai for the contracting entity, transfer mechanism or data protection agreement covering any provider on this page. See also the data processing agreement, the privacy policy and the terms and conditions.