Sub-processor Register and Data Residency Statement
Version: 2026-10-subprocessors-v4 · Effective from: 2026-10-22
Download (Markdown)Save a copy of this document.
Last reviewed: October 2026. Every entry below reflects a verified configuration, not an intention.
This register is also Schedule 2 of the customer Data Processing Agreement.
1. The short answer
Your accounting data, meaning invoices, bank transactions, documents and partner data, is stored exclusively in the EU (AWS Frankfurt, eu-central-1) and served by compute in Frankfurt. AI document processing (extraction, categorization, matching, summaries) can run in the EU on AWS Bedrock (Frankfurt), which is a setting on each workspace and the default for new workspaces. The Bedrock service itself does not store or log prompts and results, and never shares them with the model provider (Anthropic); AIFT's own processing logs keep prompt and response copies in our Frankfurt database for 14 or 90 days before automatic purge (see §4). One narrow processing step uses a US provider: semantic-search embeddings (Voyage AI) receive short AI-generated summaries under Standard Contractual Clauses with zero data retention and no model training. Billing contact data is processed by Stripe, and AIFT's own invoices to subscribers are issued and emailed through Számlázz.hu in Hungary. A bot-protection check by Cloudflare runs on our sign-in pages. Where a workspace has the company-register check switched on, supplier lookups in the Hungarian company register are made at WellData in Hungary. Full list below.
2. Sub-processor register
| # | Sub-processor | Entity / HQ | Service | Personal data involved | Processing location | Transfer mechanism | Notes |
|---|---|---|---|---|---|---|---|
| 1 | Supabase | Supabase Inc. (US) | Database, authentication, file storage, serverless functions | All customer data: invoices, bank transactions, documents, partner and user data | AWS eu-central-1 (Frankfurt); backups same region | DPA w/ SCCs (US parent entity, EU hosting) | Private buckets, RLS tenant isolation, credentials in Vault |
| 2 | Vercel | Vercel Inc. (US) | Application hosting for the app and marketing site | App traffic in transit (incl. ledger data), request logs (IP addresses) | Functions pinned to fra1 (Frankfurt); static assets on global CDN; logs retained in-platform, no log drains, no integrations | DPA w/ SCCs / DPF | Middleware stores nothing; no analytics scripts |
| 3 | AWS Bedrock | AWS EMEA SARL (LU) / Amazon Web Services Inc. (US parent) | AI inference: extraction, categorization, matching, summaries, drafting (Claude models) | Invoice documents (incl. images), bank statement contents, transaction descriptions, partner names and tax IDs | EU, Frankfurt geography; inference routed only within EU regions | AWS DPA (GDPR terms; already in place for infrastructure) | Bedrock does not store or log prompts and completions and does not share them with the model provider; no training |
| 4 | Anthropic | Anthropic PBC (US) | AI inference (Claude models) for workspaces set to the US option, and for any processing step whose model is not yet available in the EU | Same categories as row 3, while a workspace or step is routed here | US (api.anthropic.com) | DPA + Standard Contractual Clauses in the Commercial Terms | No training on API data; bounded retention (30-day tier). Which workspaces route here is visible in the workspace's own settings |
| 5 | Voyage AI | Voyage AI / MongoDB (US) | Text embeddings for semantic search | AI-generated invoice and transaction summaries (contain partner names), search query text | US, stateless: vectors stored in our own Frankfurt database | SCCs | Zero data retention enabled. Summaries only, never documents |
| 6 | GoCardless | GoCardless Ltd (UK) | Open-banking bank account data feed (PSD2/AISP) | Account holder names, IBANs, balances, full transaction feeds | EEA per GoCardless GDPR statement; UK entity under EU adequacy | DPA in terms; UK adequacy + SCCs | Bank credentials entered only on the bank's own page, never visible to AIFT |
| 7 | Mailgun (Sinch) | Sinch (SE) / Mailgun Technologies (US) | Inbound email ingestion (invoice forwarding) | Full inbound emails: sender addresses, bodies, invoice attachments | EU region (Frankfurt); roughly 3-day message retention at Mailgun | DPA; DPF/SCCs for the US operating entity | MX: mxa/mxb.eu.mailgun.org |
| 8 | Resend | Resend Inc. (US) | Outbound transactional email (auth, invites, notifications, nudges) | Recipient names and addresses, invite and magic links, message bodies | EU sending region; account metadata and API logs US-side per vendor docs | DPA w/ SCCs | No open or click tracking, no pixels (deliberate) |
| 9 | Stripe | Stripe Payments Europe Ltd (IE) / Stripe Inc. (US) | Subscription billing | Accounting-office admin name, email, billing address, VAT ID; card data entered on Stripe only, never touches AIFT | Global (Stripe-managed) | DPA in ToS; DPF/SCCs | Office-level billing data only, no client ledger content; usage reported as aggregate counts |
| 10 | Cloudflare | Cloudflare, Inc. (US) / Cloudflare Germany GmbH | Turnstile bot-protection widget on authentication pages: sign-in, sign-up, forgot-password, resend-confirmation, password change | Visitor IP address, User-Agent and browser signals at the moment of an authentication attempt; a single-use verification token. No account content, no bookkeeping data | Global (Cloudflare edge; EU visitors typically served from EU points of presence) | Cloudflare DPA w/ SCCs | Strictly necessary security measure (bot and credential-stuffing protection). Widget served from challenges.cloudflare.com; server-side verification performed by Supabase Auth, so the secret never leaves the auth provider |
| 11 | GitHub | GitHub Inc. (US) | Static hosting of the help center | Visitor IP addresses (infrastructure logs only; no accounts, no content) | US (GitHub Pages) | DPF | Static docs only |
| 12 | Slack | Slack Technologies, LLC (Salesforce, Inc., US) | Internal notification channel for in-app feedback submissions, new account registrations and callback requests | For each feedback submission: the sender's name and email address, their firm and client workspace name, the page they were on, their language, and the message text they wrote. For each new account: the person's name, email address, firm name and language. For each callback request: the phone number the person left, plus their name, email address, firm name and language | US | Salesforce DPA w/ SCCs | Triggered when a user submits the in-app feedback form, when an account is created, and when a callback is requested. No bookkeeping records, documents or bank data are sent; the message text is whatever the sender chooses to write. Each event is stored in our Frankfurt database first, and Slack receives a copy. Slack retains these messages: on our current plan those older than 90 days are hidden from view rather than deleted, and would become visible again on a paid plan, so a copy held in Slack cannot be fully cleared on request |
| 13 | WellData | WellData Kft. (Hungary), operator of cegadatapi.hu | Hungarian company-register lookups for supplier partners: registered bank accounts, company status and company master data | The tax number of a Client Company's supplier, or its name when a user searches the register by name. Personal data where the supplier is a natural person or sole trader. A lookup tells WellData that the Client Company deals with that supplier | Hungary (EU) | Not required (EU) | Only for workspaces where the company-register check is switched on. Results are cached per tax number and reused across workspaces, so the same company is looked up at most once per validity period. For sole traders we keep only that the register lists them as such; owner and manager data we receive is discarded, never stored |
| 14 | Számlázz.hu | KBOSS.hu Kft. (Hungary) | Issuing AIFT's own invoices to subscribers, emailing them, and reporting the invoice data to NAV as Hungarian law requires | The office's name, billing address and tax number; the names and email addresses of the invoice recipients the office chose, and its shared billing address if one is set; the invoiced plan, period and amounts | EU (AWS Frankfurt), per the provider's privacy notice | Not required (EU) | Office-level billing data only, no client ledger content. Covers AIFT's own invoices for its fees, not the invoices in your workspaces |
Note on Cloudflare's scope: DNS is not proxied through Cloudflare (verified: responses carry no cf-ray, traffic resolves straight to Vercel). Cloudflare's only role in the data path is the Turnstile widget above. If DNS proxying or WAF is enabled later, this row must be widened to cover all app traffic, and that is a material change requiring customer notice under DPA §5.2.
3. Not sub-processors, but worth explaining
- NAV (Hungarian tax authority): a data source acting as an independent controller. The client company's own technical-user credentials are stored encrypted (write-only vault, EU), never visible to accountants or AIFT staff. Covered in the DPA as a processing activity (§10), not as a sub-processor.
- ECB / MNB: public FX rate feeds; no personal data is sent (currency code and date only).
- Customer-connected AI assistants (MCP): a customer may connect its own Claude / Mistral / ChatGPT account to AIFT; ledger data then flows to their chosen provider under their agreement. Customer-controlled, per-organization kill switch, every access audit-logged.
- The client company's own accounting system (Microsoft Dynamics 365 Business Central): where connected, AIFT reads master data from the client company's Business Central environment and, when a user sends them, writes partner cards, purchase invoices with the invoice document attached, and bank journal lines into it. Business Central runs under the client company's own agreement with Microsoft, so Microsoft is not our sub-processor. Access is approved by the client company's Microsoft administrator, needs no password or key of the client company, and can be withdrawn by the client company at any time. Today AIFT creates purchase invoices as drafts and does not post journal lines; posting is done in Business Central by a person. Covered in the DPA as a processing activity (§13), not as a sub-processor.
4. Supporting facts
- Fonts are self-hosted. The only third-party browser script in the app is the Cloudflare Turnstile bot-protection widget on authentication pages (strictly necessary security, no cross-site tracking).
- All storage buckets private; access via signed URLs with 60-second to 1-hour lifetimes; no public URLs anywhere.
- Row-level security on every customer-data table: cross-tenant isolation is enforced by the database, including for AI-assistant (MCP) access.
- AI request log (full prompts and responses) retained 14 days for the matching scorer and 90 days for everything else, then purged by a daily job. Cron logs 3 days.
- Bank credentials never touch AIFT (PSD2 redirect flow). NAV credentials: vault-encrypted, write-only, redacted from logs.
- Workspace offboarding: audited content and storage wipe, double-key guarded, covering database records and stored files.
- Billing evidence: a content-free, per-document ledger of what was billed each month is retained for 8 years under Hungarian accounting law; it contains no document content.
5. Where AI processing runs, and what you can choose
AI document processing has two possible locations, and it is a setting on each workspace.
- EU (recommended, and the default for new workspaces). Inference runs on AWS Bedrock in the Frankfurt geography and is routed only within EU regions. Prompts and results are not stored or logged by the service and are never shared with the model provider.
- US. Inference runs on Anthropic's first-party API in the United States, under Standard Contractual Clauses, with no training on your data and bounded retention. A workspace stays on this option only while it is set that way.
Two further points, so the picture is complete:
- A processing step may run in the US even when a workspace is set to the EU option, if the AI model that step needs is not yet available in the EU. This is temporary and applies to that step only, never to your stored data.
- Semantic-search embeddings always run in the US (Voyage AI, row 5), under Standard Contractual Clauses and with zero data retention. Only short AI-generated summaries and your search terms are sent, never documents.
Your stored data, in every case, remains in the EU (Frankfurt). The location setting affects processing only.