Delegate
privacy

What Delegate sees, stores, and never touches.

A focused privacy page for end users connecting their bank — what happens during connection, what data we keep, how to revoke access, and how to ask for deletion. For the engineering view of how data is protected, see Security & data handling.

Last updated: May 2026 · Contact: privacy@testdelegate.com
01

How bank connection works

When you connect your bank, you do that inside Plaid Link — a flow operated by Plaid Inc., not by Delegate. Plaid is the open-banking provider used by Robinhood, Wealthfront, Venmo, and most modern fintechs.

  • Plaid handles authentication. You enter your bank username and password into Plaid Link, or — at banks that support it — you authenticate via your bank's own OAuth screen. Either way, you authenticate at the bank, not at Delegate.
  • Delegate never sees your bank credentials. Your bank username, password, MFA code, and any device-trust prompts pass between you, Plaid, and your bank. They do not pass through Delegate's servers and are not logged by us.
  • OAuth where supported. For banks on Plaid's OAuth network (Chase, Capital One, Wells Fargo, USAA, and others), Plaid Link redirects you to your bank's own login screen, where your bank issues the authorization directly. Delegate has no visibility into what you type there.
  • What Delegate receives. After you finish, Plaid issues a token. Delegate exchanges it server-side for a read-only access token used to read the specific account data we need to score (account type, balance, transaction summary, account-holder name).
in-link disclosures
Plaid's own Data Transparency Messaging — shown inside Plaid Link — describes exactly what data is shared with Delegate, and how to manage it via Plaid's portal. We do not duplicate those disclosures here; instead, this page covers what happens on Delegate's side after Plaid passes data to us.
02

What Delegate stores

We retain the minimum needed to produce, justify, and audit a verification verdict. We do not collect or store more than this.

Field
Why we keep it
Retention
Account type
Whether the account is checking, savings, or prepaid. Prepaid is a strong synthetic-fraud signal.
7 years
Balance summary
Current and available balance at time of verification. Stored as part of the verdict record, not refreshed unless our customer has opted into continuous monitoring.
7 years
Account age
Date of the oldest visible transaction. Used to flag accounts opened within the last 14 days.
7 years
Transaction summary
Aggregate counts and flags only — total transaction count, unique-merchant count, payroll-cadence flag, recurring-deposit summary. Raw transaction descriptions are not retained long-term.
7 years (summary) · 0 (raw descriptions)
Account-holder name
Used for name-match against the name our customer collected at signup. Match outcome is one of the strongest fraud signals.
7 years
Plaid access token
Encrypted at the field level. Revoked immediately after verification unless the customer has opted into continuous monitoring for that account.
Until revocation
Verdict record
The score, verdict (allow / review / block), and reason codes — written to the hash-chained audit log.
7 years

The seven-year window matches the standard fraud-investigation retention period and what regulated financial-services partners require of their vendors. Customers can delete an individual end-user's record at any time on request; see "Data deletion" below.

we never collect
Bank usernames or passwords · MFA codes · Social Security numbers · routing or account numbers (full PAN) · credit card numbers · biometric data · government ID images · raw long-term transaction descriptions. If a feature would require any of these, we ship the feature differently or don't ship it.
03

Encryption

  • At rest: AES-256, applied at the volume level by our managed Postgres host. Backups are encrypted with the same scheme.
  • In transit: TLS 1.2+ (TLS 1.3 in practice) on every leg — between your browser and Plaid, between Plaid and Delegate's backend, between Delegate's backend and the database, and between Delegate's backend and customer integrations.
  • Field-level encryption for sensitive bank fields: Plaid access tokens and persisted account identifiers are wrapped with AES-256-GCM before being written to the database, so a database-level read does not expose them. rolling out
  • Key management: encryption keys are held in the deployment platform's secrets store, never in source control, and rotated on a documented schedule.
04

Revoking access

You can revoke Delegate's read-only access to your bank account at any time, directly from Plaid — no email required.

where to revoke
Go to my.plaid.com/portal. Sign in with the email you used at your bank, find Delegate in the list of connected apps, and choose Disconnect. This revokes our access token immediately — Delegate stops being able to read new data from that account from that moment.
  • Already-recorded verdicts stay. Revoking access stops further reads; it does not erase the verification record that was already produced. To remove the verification record itself, request data deletion (next section).
  • Continuous monitoring stops. If your account was being monitored on an ongoing basis, that stops the moment you disconnect in Plaid's portal.
  • Per-bank revocation. If you connected more than one account, you can disconnect them independently in the same portal.
05

Data deletion

You have the right to request deletion of your data. Two paths, depending on what you want removed.

  • If you connected your bank via a Delegate customer (e.g. an investment platform that uses Delegate to verify users): contact that company directly. They can delete your record via the Delegate API — that's the cleanest path because your relationship is with them.
  • If you'd rather email Delegate directly: write to privacy@testdelegate.com. Include the email address you used to authenticate, the approximate date of verification, and the name of the company that asked you to verify. We will confirm receipt within one business day, complete the deletion within 30 days, and propagate it to backups within the following 30 days.
  • What gets deleted: the verification record, all stored fields listed in "What Delegate stores" above, and any cached Plaid identifiers. The hash-chained audit log retains an entry recording that a deletion occurred (without the deleted contents) — this is required to keep the log's integrity property and is a standard pattern for audit-grade systems.
  • Plaid-side data: deletion of records held by Plaid is governed by Plaid's own portal at my.plaid.com/portal. We can confirm we have asked Plaid to delete on our side, but the Plaid relationship is between you and Plaid.
06

Third parties

Plaid is the only third party that touches your bank data. No marketing-tech, no advertising, no data brokers, no analytics-with-PII partners are involved in the bank-verification pipeline.

For full transparency, here is the complete list of sub-processors Delegate uses — including ones that touch infrastructure or billing but not bank data — so you can see the whole picture:

Sub-processor
What they handle
Plaid
The only sub-processor that touches your bank data. Open-banking provider. You authenticate to your bank inside Plaid Link; Plaid returns account, balance, transaction-summary, and identity data to Delegate via API.
Railway
Application hosting and managed Postgres database. US-East region. All persistent Delegate data lives here, encrypted at rest.
Resend
Transactional email (password resets, team invites, auditor verification codes). Receives recipient email addresses only — no bank data.
Anthropic
Optional AI-assisted reasoning on flagged cases. Only invoked on customer opt-in; the model receives structured reason codes and verdict context, never end-user PII directly.
Stripe
Billing only. Stripe receives the customer's billing email and payment method — never end-user bank data or verification records.

We update this list and notify customers at least 30 days before adding any new sub-processor that processes user data.

07

Compliance

We try to be precise about what is in place versus what is in progress. Calling something "certified" before an auditor has signed a report would be misleading — so we don't.

SOC 2
SOC 2 audit-ready, not yet audited. The controls, tooling, and documentation needed for a SOC 2 Type II audit are in place from day one — hash-chained audit log, access reviews, encryption posture, change management. The audit itself is scheduled to begin once we have our first paying customer at scale. We are pre-launch today. audit pending
Gramm-Leach-Bliley Act
We handle non-public personal information in alignment with the Gramm-Leach-Bliley Safeguards Rule. Administrative, technical, and physical safeguards are documented and reviewed. aligned
Section 1033
This page exists in the form required by the CFPB's Section 1033 rule on personal financial data rights: clear disclosure of what data is collected, by whom, how to revoke access, and how to request deletion. Plaid's own Data Transparency Messaging covers the in-Link disclosures required by the same rule. in place
GDPR / CCPA
Delegate currently serves US customers verifying US end users. Our data handling meets CCPA standards and the relevant GDPR requirements for that scope. If you need a DPA for an EU-resident user base, contact privacy@testdelegate.com. us scope covered
Plaid developer policy
Delegate complies with the Plaid Developer Policy, including the requirement to maintain this dedicated privacy page, to limit data use to the disclosed purpose, and to honor Plaid-side revocations. Plaid Production Agreement in review (sandbox terms in effect for current testing). in review
08

Contact

Privacy questions & deletion requests
Data deletion · subprocessor inquiries · DPAs · "what do you have on me?" requests
privacy@testdelegate.com
Security disclosures
Vulnerabilities, suspected breaches, security research
security@deliverfaster.services
Revoke Plaid access
Stop Delegate from being able to read your bank account, immediately
my.plaid.com/portal