Privacy Policy

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, except for the internal regression-testing retention described in the Data Retention section, and the broker 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, feature-usage telemetry, and the referral or lead source entered at upload, which may be a person’s name.
• Verification inputs and results: when a broker runs a verification or enrichment check, the merchant’s EIN and jurisdiction, the merchant owner’s name, email address, and phone number as entered by the broker, and the results returned by the services listed in the Subprocessors section (including business-registration, sanctions-screening, contact-risk, and public court-record results). These are purged on the schedule in the Data Retention section.
• 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 surface fraud and anomaly indicators on uploaded statements (balance reconciliation, PDF forensics, duplicate-period detection, and related checks) for the broker’s review.
• To match merchant profiles against the funder qualification criteria stored in the platform.
• To run the verification and enrichment services listed in the Subprocessors section, which run only when the corresponding feature is enabled and, where applicable, only when a broker triggers the check.
• 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

• Except for the regression set described in the Data Retention section, uploaded bank-statement PDFs are stored in private Supabase object storage and are deleted by a scheduled retention job once they are 72 hours old; deletion is normally completed within 24 hours after that point. 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, other than the names of financing providers detected as existing positions, which are retained as part of the portfolio record: 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 an aggregated financial summary containing no merchant identity, no account numbers, no source documents, and no transaction-level detail, together with 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

All vendors above are contractually bound to process data on ScrublyIQ’s behalf only. We do not sell merchant data. Not every vendor listed is active at all times: the verification, enrichment, and backup-extraction services run only when the corresponding feature is enabled and, where applicable, only when a broker triggers the check. They are listed here because they are part of the platform, not because every scan reaches them. Where an AI vendor offers a Zero Data Retention option, we enable it once it is approved for our account; the current status of ZDR for AI processing is described in the AI Processing Disclosure section below. This list was last updated 2026-08-27 and may change as services are added or removed.

5. AI Processing Disclosure

Bank statement content from your uploads is processed by the services named in this section, each of which is listed in the subprocessor table above. Anthropic’s API receives statement text and statement page images, and is used for extraction, transaction classification, and narrative generation. Under its commercial API terms, Anthropic does not use API inputs to train its models. Google Cloud Document AI receives statement pages and performs optical character recognition and bank-statement parsing for the banks routed to that pipeline. Under its commercial terms, Google does not use Google Cloud customer content to train its models. ScrublyIQ does not use merchant statement data to train, fine-tune, or otherwise improve any AI model, and we do not permit our vendors to do so. ScrublyIQ has requested Zero Data Retention entitlement from Anthropic — this will be updated when confirmed. Until then, requests are subject to the retention period in Anthropic’s then-current commercial terms (30 days as of the date of this Policy), for abuse monitoring only. A third service can receive statement content: Firecrawl, a backup extraction service used only when the primary parser cannot read a PDF, which receives a short-lived signed link to the file rather than the file itself, and which is not an AI service. Apart from Anthropic, Google Cloud Document AI, and Firecrawl, no service listed in the subprocessor table above receives bank statement content; the verification and enrichment services receive only the narrow fields shown there.

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.
• The verification and enrichment services listed in the Subprocessors section run only when the corresponding feature is enabled and, where applicable, only when a broker triggers the check.
• 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 deleted by a scheduled retention job once they are 72 hours old; deletion is normally completed within 24 hours after that point.
• Exception: a small, fixed set of statements that we hand-select is retained beyond this window, indefinitely, for the sole purpose of internal regression and accuracy testing of our own extraction software. That testing measures whether the software still reads documents correctly; it does not train, fine-tune, or otherwise modify any AI or machine-learning model, and we do not use this data, de-identified or otherwise, to do so. These statements are kept in private, service-role storage that is never exposed to the application or to other brokers, are never shared, sold, or used for any other purpose, and are not something a broker can opt into or out of. Every statement outside this hand-curated set is deleted on the standard 72-hour schedule.
• 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.
• An analysis record containing no merchant identity, no account numbers, no source documents, and no transaction-level detail 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.
• ScrublyIQ may retain data beyond the schedule described in the Privacy Policy where retention is required by law or legal process or by a preservation obligation, or where ScrublyIQ reasonably determines that retention is necessary to investigate suspected fraud or misuse of the Platform or to establish, exercise, or defend legal claims. Retained data is used only for that purpose. Copies residing in routine backup, disaster-recovery, or archival systems are deleted in the ordinary course of those systems’ cycles.
• 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.
• Application-level ownership checks scope every request to the authenticated user or organization; row-level security is additionally enabled on all database tables as a secondary control.
• Comprehensive audit logging for authentication, admin actions, and exports.
• 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 voluntarily applies the standards the GLBA Safeguards Rule sets for nonpublic personal information to all merchant financial data. 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 without undue delay and in any event within 72 hours of confirming a security incident affecting Customer Data.

11. Contact

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

12. Last Updated

August 2026.