Privacy Policy

How ScrublyIQ handles merchant financial data, broker account data, and the third-party services we use to deliver the platform.

Our Role and Legal Status

ScrublyIQ is a software tool. We are not a financial institution, lender, broker, funder, or consumer reporting agency, and we make no funding decisions. We process bank statements solely on behalf of the subscribing broker, who directs the analysis and is solely responsible for all funding, underwriting, and credit decisions. The analysis ScrublyIQ produces is a workflow aid for that broker — it is not a consumer report and is not assembled or furnished as a consumer report under the Fair Credit Reporting Act (FCRA). We do not sell, share, or otherwise monetize merchant financial data.

1. What Data We Collect

  • Merchant data: business name, business location, merchant bank statement PDFs, and transaction-level data extracted from those PDFs (dates, amounts, memos, running balances).
  • Broker account data: name, email address, organization affiliation, authentication session metadata, and feature-usage telemetry.
  • Payment data: processed by Stripe. Full card numbers are never transmitted to or stored on ScrublyIQ servers.
  • Support communications: emails, in-app messages, and related metadata when you contact us.

2. How We Use It

  • To generate Deal Cards — fundability score, tier, DSCR, and narrative.
  • To run fraud and anomaly detection on uploaded statements (balance reconciliation, PDF forensics, duplicate-period detection, and related checks).
  • To match merchant profiles against the funder qualification criteria stored in the platform.
  • To run third-party verification services (OFAC, Middesk, TIN, address, Google Places) when a broker triggers them.
  • To meter credit usage, compute billing, and provide receipts.
  • To send transactional account emails and security notifications.
  • To maintain the security, availability, and integrity of the Service.

3. How We Store It

  • Uploaded bank-statement PDFs are stored in private Supabase object storage and permanently deleted within 72 hours of upload. They are never publicly accessible — the application serves them only through short-lived signed URLs scoped to the authenticated broker.
  • Within that same 72-hour window, the analysis record is scrubbed of everything that identifies the merchant or its counterparties: the business name and location, the masked bank-account identifier, every third-party verification and enrichment result, broker free-text notes, and internal file hashes are permanently purged and cannot be recovered from the live service. What is retained is a de-identified, aggregated financial summary and the derived analysis — monthly deposit, balance, and NSF totals, ratios such as DSCR, the fundability score, tier, and funder matches, and the generated underwriting narrative — so the broker’s portfolio and deal history stay intact. The underlying bank-statement PDFs, the merchant identity, and raw transaction-level detail (individual dates, amounts, and memos) do not survive this window.
  • Bank account numbers are never stored in full. Only the last four digits are retained, as a masked “acct-XXXX” identifier. Routing numbers are never stored.
  • The raw text extracted from a statement is never persisted. It exists only transiently in memory during processing and is discarded once the analysis is produced.
  • Merchant-identifying fields (business name, location, and related PII) and all enrichment data are encrypted at rest using AES-256-GCM at the application layer before being written to the database.
  • All data in transit is encrypted using TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enforced with a 2-year max-age and preload.
  • The primary database is hosted on Supabase PostgreSQL with row-level security enabled.
  • Encrypted operational database backups are retained for disaster recovery and purged on a rolling cycle; data deleted from the live service ages out of backups as that cycle rotates.

4. Subprocessors and Third-Party Services

ServicePurposeData SharedLocation
AnthropicAI processingBank statement PDFs and transaction textUnited States
MiddeskBusiness verificationMerchant name, EIN, addressUnited States
SmartyAddress validationMerchant address onlyUnited States
Google PlacesBusiness lookupMerchant name and addressUnited States
OpenCorporatesBusiness registration lookupMerchant name and jurisdictionUnited Kingdom
OFAC SDN APISanctions screeningMerchant name onlyUnited States
SupabaseDatabase and file storageAll merchant dataUnited States
ClerkAuthenticationBroker identity onlyUnited States
StripeBillingBroker payment onlyUnited States
VercelHostingAll application trafficUnited States
Upstash RedisRate limiting counters onlyNo merchant dataUnited States
AxiomObservability logsScrubbed of PIIUnited States
SentryError monitoringScrubbed of PIIUnited States
ResendTransactional email to brokersBroker email onlyUnited States

All vendors above are contractually bound to process data on ScrublyIQ's behalf only. We do not sell merchant data. ScrublyIQ maintains Zero Data Retention agreements with AI vendors where technically feasible. This list was last updated 2026-04-23 and may change as services are added or removed.

5. AI Processing Disclosure

Bank statement text extracted from your uploads is processed by Anthropic’s API. Anthropic does not use API inputs to train models. ScrublyIQ has requested Zero Data Retention entitlement from Anthropic — this will be updated when confirmed. Until then, requests are subject to Anthropic’s standard 30-day retention for abuse monitoring only. No other AI vendor is used to process bank statement content.

6. Data Sharing

  • We do not sell merchant data. Ever.
  • We share data with subprocessors listed in the table above only as necessary to provide the Service, and only under contractual privacy and security obligations.
  • Third-party verification services run only when the broker explicitly triggers them within the platform.
  • We do not transmit merchant data to funders. Any submission of merchant information to a funder is initiated and controlled by the broker outside the Service.
  • We may disclose data when legally compelled (subpoena, court order, regulatory demand) and will push back on overbroad requests when appropriate.

7. Broker Responsibilities

For the purposes of applicable data-protection law, brokers are the data controllers for their merchant relationships and ScrublyIQ acts as a data processor on the broker’s behalf. Brokers are responsible for obtaining merchant consent and any underlying legal basis before uploading merchant financial documents, and for responding to merchant requests regarding access, correction, or deletion of their data. ScrublyIQ will assist with such requests when asked by the broker of record.

8. Data Retention and Deletion

  • Uploaded PDFs are permanently deleted within 72 hours of upload by a scheduled retention job.
  • Within 72 hours, the merchant’s identity, the masked bank-account identifier, all third-party enrichment and verification results, broker notes, and internal file hashes are permanently purged and cannot be recovered from the live service.
  • A de-identified analysis record is retained for the broker’s portfolio tracking: the analysis date, status, risk tier, and an aggregated financial summary (monthly deposit, balance, and NSF totals, ratios such as DSCR, the fundability score, funder matches, and the underwriting narrative). It contains no merchant identity, no account numbers, no raw statement documents, and no transaction-level detail.
  • Brokers may request deletion of specific analyses, their entire account, or any broker-level data at any time by emailing support@scrublyiq.com.
  • Encrypted operational backups are purged on a rolling cycle; data deleted from the live service ages out of backups as that cycle rotates.
  • Audit logs (authentication, admin actions, security events) are retained longer for security and compliance purposes and are kept separate from merchant financial data.

9. Security

  • AES-256-GCM encryption for merchant PII at rest at the application layer.
  • TLS 1.2+ for all data in transit; HSTS enforced.
  • Authentication handled by Clerk (SOC 2 Type II certified) with multi-factor authentication available.
  • Rate limiting on every API endpoint via Upstash Redis.
  • Row-level security on database tables; all access scoped to the authenticated user or organization.
  • Comprehensive audit logging for authentication, admin actions, and data access.
  • Regular internal security reviews. Vulnerability reports may be sent to security@scrublyiq.com; we acknowledge within 48 hours.

10. GLBA Compliance

ScrublyIQ operates as a financial-services technology platform and treats merchant financial data as "nonpublic personal information" under the Gramm-Leach-Bliley Act (GLBA). Our written information security program aligns with the GLBA Safeguards Rule (16 CFR Part 314), including risk assessment, access controls, encryption at rest and in transit, secure development practices, vendor-management review of subprocessors, incident-response procedures, and an annual review of the program. A designated qualified individual oversees the program. Suspected security incidents are triaged under that program and disclosed to affected brokers as required.

11. Contact. Privacy questions, data-subject requests, and account deletion requests: support@scrublyiq.com. Security vulnerability reports: security@scrublyiq.com.

12. Last Updated. April 2026.