How Delegate handles your data.

When your end user connects their bank through Plaid Link, Delegate reads the minimum set of signals needed to score whether the account represents a real banking relationship. Specifically:

• Account type and balance summary — checking / savings / prepaid, with current and available balance.
• Account age — the date of the oldest visible transaction, used to flag freshly opened accounts.
• Transaction history (last 90 days, summarized) — we read transaction names and amounts for payroll detection and merchant-diversity scoring. Raw transaction descriptions are not retained long-term; we keep summary statistics (count, payroll-cadence flag, unique-merchant count).
• Account holder name — matched against the name your customer submitted at signup. Name-match is one of the strongest fraud signals we score.
• Optional payroll-detection signals — recurring direct deposits, cadence, average amount. Used to score whether the account looks like a real employed person's account.

• Database: Postgres, managed by Railway, hosted in the US-East region.
• Encryption at rest: AES-256, applied automatically by Railway's managed Postgres at the volume level.
• Encryption in transit: TLS 1.3 between Delegate's backend, the database, Plaid, and all customer integrations.
• Field-level encryption for sensitive bank fields — Plaid access tokens and persisted account identifiers are wrapped with AES-256-GCM using Node's built-in crypto module before storage. rolling out

The application servers and database run on Railway. We do not operate our own physical infrastructure. Database backups are encrypted and retained per Railway's managed-Postgres policy.

• API access: only requests authenticated with a valid customer API key. Keys are bcrypt-hashed before storage; the plaintext key is shown to the customer once at creation and never again.
• Tenant isolation: every database query is scoped to a customer's organization_id. Customers can only read and write their own end users' data. Isolation is enforced at the application query layer and verified by tests.
• Delegate staff: a single founder (Leo Cohen) has database access today. Production access is used only when troubleshooting a specific customer issue, with that customer's consent.
• No third-party access. We do not sell data, do not share it with analytics partners with PII attached, and do not run advertising or marketing-tech beacons against end-user records.

Plaid is our open-banking provider. They are how Delegate reaches more than 12,000 US financial institutions without negotiating each one individually.

• The user authenticates to their bank inside Plaid Link. The bank's username and password never touch Delegate's servers and are never stored by us.
• Plaid returns a public token to the user's browser. We exchange it server-side for a long-lived access token, which we encrypt and store. That token is used to read account data from Plaid.
• Plaid is SOC 2 Type II certified and operates at financial-institution-grade compliance levels. They are also the open-banking provider used by Robinhood, Wealthfront, Venmo, and most modern fintechs you've used.
• Plaid Production Agreement: in review (submission pending LLC formation; sandbox terms in effect for current testing).

• Verification records: retained for 7 years. This is the standard fraud-investigation retention window and matches what regulated financial-services partners require of their vendors.
• Plaid access tokens: revoked immediately after the verification flow completes — unless the customer has explicitly opted into continuous-monitoring for that end user.
• Per-end-user deletion: customers can request deletion of any end user's data via the API. Deletion is propagated to backups within 30 days.
• Account closure: when a customer closes their Delegate account, all data associated with that customer is deleted within 30 days, including from encrypted backups.

Every verification, every data access, every configuration change, every case resolution is written to an append-only audit log.

• Hash-chained: each entry's SHA-256 includes the previous entry's hash. Tampering with any record breaks the chain at that point and every entry after — mathematically detectable.
• Independent verification: your auditor can validate the integrity of the chain themselves, with no trust in Delegate, by recomputing hashes against the exported log.
• Open implementation: the hash-chain implementation is part of the same codebase that produces the verifications you score against. Available for inspection on request.
• Suitable as legal evidence: structured to qualify under FRE 803(6) Business Records Exception when paired with a custodian declaration.

We have tried to be precise about what is in place versus what is in progress. This section will change as our compliance posture matures.

Every third-party service Delegate uses that touches customer or end-user data is listed below. We will update this list and notify customers at least 30 days before adding a new subprocessor that processes user data.

• Breach notification: if a security incident affects customer or end-user data, we commit to notifying affected customers within 72 hours of confirmation, with what we know and what we're doing about it.
• Incident response plan: a written plan exists, is owned by the founder, and is reviewed quarterly. It covers detection, triage, containment, customer communication, and post-incident review.
• Cyber liability insurance: coverage is in process. We will publish carrier and limits here once the policy is bound. in process
• Vulnerability disclosure: if you've found a security issue, please email security@deliverfaster.services. We will acknowledge within one business day and keep you updated until resolution.