GuidesData Privacy & Redaction

Data Privacy & Redaction

How Forbidden Finance acts as a privacy gateway for API and AI connections — redacting fields and excluding accounts or categories on our servers before your data reaches any app or assistant. Fields are omitted, never masked.

Overview

When you connect an app or AI assistant to Forbidden Finance, you are not handing it your whole financial life. Each connection passes through a privacy gateway that you configure: you choose which fields are stripped and which accounts or categories are hidden entirely. Those choices are applied on Forbidden Finance's servers, before any data is sent.

This is the part we care most about getting right, so this guide is deliberately plain about what the gateway does and does not do.

Two controls, applied server-side:

  • Redaction — remove specific fields (a merchant name, an amount, an account balance) from what a connection receives, across every account.
  • Exclusion — hide specific accounts or categories so a connection never sees them at all.

Both are set per connection. A connection you give to a budgeting assistant can see different data than one you give to a spreadsheet script.

Fields are omitted, not masked

When you redact a field, it is left out of the response — not replaced with ***, [redacted], or a zero. The payload simply does not contain that field. There is no placeholder to reverse-engineer and no length hint to leak.

Every response says what was removed. The envelope's redacted_fields names the field ids your settings stripped, and filtered turns true when exclusions changed which rows or totals were served. Nothing is hidden about the fact that something was hidden.

What you can redact

Redaction works on a fixed registry of 18 fields. You cannot redact something the registry does not name, and a connection cannot ask for a field back.

AreaFields you can redact
TransactionsMerchant name, description, amount, tags, check number, external reference, memo / notes, purchase location
AccountsAccount name, account number mask, balance
Bank connectionsInstitution, connection error message
InvestmentsHolding name & ticker, holding value
LiabilitiesLiability name, liability balance
GoalsGoal name & description

Redacting one applies it everywhere that field appears — redact merchant and no transaction the connection ever sees will carry a merchant.

Three groupings are worth knowing about, because they are choices rather than accidents:

  • Purchase location is one field, not five. Street, city, region, postal code, and country are hidden or shown together. A postal code plus a city answers "where were you" as surely as a street line does, so offering them separately would be offering a privacy choice that does not really exist.
  • Institution is one choice across two payloads. Redacting a connection's institution removes the institution name and logo from the connection and from every account under it. The rail — provider, and source_aggregator where one applies — is never redacted: it names the pipe the data came over, not the bank it came from.
  • A user's own merchant labels follow the merchant field. The per-viewer display_name on a transaction is merchant identity for privacy purposes, so a connection that redacts merchant gets neither the bank's merchant name nor the user's own label for it.

There is one more pairing, on bank-synced rows that someone has edited. Those rows can carry the bank's original values alongside the current ones — provider_amount, provider_merchant_name, and so on. Each original is redacted together with the field it shadows: hide amount and provider_amount goes with it. Hiding the current value while leaking the original would be no privacy at all.

When redaction has knock-on effects

Some numbers can be reconstructed from others. If you hide a transaction amount or an account balance but still let a connection compute spending by category or net worth, the arithmetic hands the hidden number straight back. So Forbidden Finance closes those doors too.

Redacting transaction amount or account balance also disables the aggregates that could rebuild them: spending insights, net worth, debt summaries, and budget progress. The connection editor warns you before you turn one of these on, and the server enforces it either way.

This is the honest trade-off of a real privacy control: hiding a building-block number costs you the features built on top of it. You choose where that line sits, per connection.

Excluding accounts and categories

Exclusion is stronger than redaction — it removes whole accounts or categories from a connection's view:

  • An excluded account or category is absent from every list and from search results. It is not there to be found.
  • Asking for an excluded item directly returns a plain not-found, byte-identical to asking for something that never existed. A connection cannot tell "hidden from me" apart from "does not exist".
  • Totals never quietly leak an excluded item. Where an aggregate can be recomputed without the excluded input, the API does so and marks the response filtered. Where it cannot be computed cleanly, the API returns data-excluded rather than an approximate or leaky number.
Exclusion is the right tool for an entire account you never want an assistant to reason about — a private savings account, a joint account, a business card. Redaction is the right tool when you want the app to see that an account or transaction exists but not one particular detail about it.

One deliberate limitation

Net worth is unavailable entirely — both the current figure and the history — for any connection that excludes an account. Net worth is served from stored point-in-time snapshots, and a snapshot cannot be re-cut after the fact to subtract an account without risking a wrong number. Rather than serve a figure we cannot guarantee is exclusion-correct, we withhold it and return data-excluded.

Excluding a category does not affect net worth, and those requests are served normally.

Privacy applies to writes too

A connection cannot change what it is not allowed to read. If a write would touch a hidden field, the whole request is refused with 403 forbidden, carrying one fixed sentence:

This connection's privacy settings hide a field this request would change.

It names no field, ever. Which fields are hidden is itself the configuration, so a per-field answer would let a caller enumerate your privacy settings by probing writes one field at a time. The message is identical for every caller in every case.

The same principle shapes the bulk-categorize result: a transaction on an excluded account comes back not_found and an excluded category comes back invalid_category — the same answers a genuinely nonexistent id would produce.

Where enforcement happens

Everything above is enforced by Forbidden Finance's servers, at the single point every request passes through — not by the app, not by the AI client, and not by any connector running on your machine. A connection cannot opt out of your redaction, request an excluded account, or widen its own scope. It receives only the filtered view you configured.

That holds identically on the REST API and on MCP: the MCP tools route through the same authorize-and-redact path a /v1 request does, so a tool result is filtered exactly like the endpoint behind it.

This is why we call it a gateway rather than a setting: your privacy choices sit between your finances and the app, and the app only ever meets the far side of them.

What this does and does not promise

In the spirit of being straight with you:

  • It does limit what any connected app or AI assistant can read, field by field and account by account, enforced server-side.
  • It does tell you in every response what was redacted or filtered.
  • It does apply to changes as well as reads — a connection cannot edit a field it cannot see.
  • It does not change what you can see in the app. Your own view is always complete; redaction and exclusion apply only to connections.
  • It does not control what an app or AI provider does with data you do let through. Once a field is allowed and sent, the receiving app and its provider handle it under their own terms. Share only what you are comfortable sharing, and lean on redaction and exclusion to keep the rest back.

Frequently Asked Questions

If I redact a field, can the app tell what I hid?

It sees the field id in redacted_fields, so it knows that a field was removed — but not its value. The value is omitted from the payload entirely, with no placeholder and no length hint.

Does excluding an account slow anything down, or delete it?

No. Exclusion only affects what one connection can see. The account stays in your app, fully visible to you, and your other connections are unaffected.

Can an app get around my settings?

No. Redaction and exclusion are enforced on our servers at the one point every request goes through. An app cannot request a redacted field or an excluded account, and it cannot broaden its own access.

Why did an insight come back empty or refused?

You likely redacted a number it depends on — transaction amount or account balance — or excluded accounts that make up part of the total. That is the reconstruction guard working as intended.

Why did a write fail without telling me which field was the problem?

Because naming it would let a caller map your hidden fields by probing writes one at a time. Read the same resource first: the fields your connection may change are the ones that come back in the payload.

Can I change my mind later?

Yes. Edit a connection's redaction and exclusion settings any time under Settings > AI & API Connections. Changes take effect right away for that connection — there is nothing to reconnect.

Scopes & Permissions

How scopes, the changes switch, and privacy combine.

AI & API Connections

Create and manage connections in the app.

Getting Started with the API

Auth, envelopes, errors, and pagination.

Privacy Mode

Hide balances on your own screen.

Need more help? Contact us at [email protected].