StatementReady Privacy Policy

Effective date: October 16, 2026 · Version: 0.14.6

This Privacy Policy explains how Varaxon Technologies LLC d/b/a StatementReady ("StatementReady," "we," "us") collects, uses, and shares information through the StatementReady website at statementready.net, the StatementReady web application, borrower upload pages, and related emails (together, the "Service").

1. Two kinds of information, two roles

StatementReady is a business tool for mortgage and loan brokers, loan officers, and processors ("Customers").

1. Account, waitlist, and website information about Customers' users, people who join our waitlist, and website visitors. We decide how this information is used, and this Policy governs it.

2. Borrower Data means bank statements uploaded by a Customer, or by a borrower through a Customer's upload link, plus the data we extract and the outputs we generate from them. For Borrower Data, the Customer is the financial institution under the Gramm-Leach-Bliley Act (GLBA) and the FTC Safeguards Rule (16 CFR Part 314). StatementReady acts as the Customer's service provider. We process Borrower Data only on the Customer's instructions, as described in our Terms of Service and Data Processing Agreement ("DPA"). This Policy describes that processing for transparency. The Customer's own privacy notice governs its relationship with its borrowers.

Borrowers: if a broker asked you to upload bank statements, the broker controls your information. Please contact that broker first. See Section 10.

2. Information we collect

2.1 Customer accounts

• Account details: your organization (brokerage) name, your email address, and your role (owner or member).
• Sign-in and multi-factor authentication: Sign-in records are held by Supabase Auth. Broker users must set up an authenticator app (TOTP). Loan data stays hidden until you've completed the MFA step (assurance level 2). We store the authenticator secret encrypted.
• Billing records: payments are handled by our payment processor, Stripe, through checkout pages hosted by Stripe on StatementReady's own Stripe account (Varaxon Technologies LLC d/b/a StatementReady; statement descriptor STATEMENTREADY). Stripe collects your card details, billing email and billing address, and processes them under its own privacy policy, including for its own fraud prevention and legal compliance. We do not collect or store card numbers, expiry dates, or security codes. We send Stripe your organization's internal ID and plan choice. We keep only Stripe customer and subscription identifiers, plan and billing interval, subscription status (for example active, past due or canceled), included and used loan-file counts, overage usage counts, invoice records and line items, and payment event identifiers. We count overage usage in our own system and send Stripe one usage event per overage loan file (the Stripe customer ID and a count, not loan contents) so Stripe can bill it on your monthly invoice.
• Terms and Privacy Policy acceptance: at signup, you tick a box to accept the Terms and this Privacy Policy. For each document we record the version you accepted and the time. We don't record your IP address or device for this. When we publish a new version, signed-in users are asked to accept it before they can open loan files. These records are deleted if your account or organization is deleted.
• Support messages you send us.

2.2 Waitlist sign-ups

When you join the waitlist we collect:

• your work email and role, and optionally your name, company, plan interest (pay-as-you-go, Solo, or Team), loan volume, and notes;
• a record of your consent: the time, the form version (currently `2026-10-16.1`), and a fingerprint (SHA-256 hash) of the exact consent text you were shown. Consent to product updates is required. Consent to marketing is optional and off by default. We reject a sign-up without consent;
• the status of your email confirmation. We use double opt-in: your sign-up stays pending until you click the confirmation link. Confirmation and unsubscribe links use random tokens, and we store only a hash of each token;
• one-way hashes (SHA-256) of your IP address and browser user agent, used only for rate limiting and abuse prevention. We do not store your raw IP address or user agent.

We keep waitlist records for 365 days after sign-up and then delete them automatically. You can unsubscribe or withdraw at any time using the link in our emails.

2.3 Borrower Data (processed for Customers)

• Bank-statement PDFs, stored only as encrypted ciphertext (AES-256-GCM) in a private storage bucket. Files are opened through short-lived signed links, and only for a signed-in user.
• Extracted data: financial institution, account type, the last four digits of account numbers, statement periods, opening and closing balances, and transactions (date, description, amount, credit or debit, running balance), plus categories, eligibility settings, user edits, and flags. Borrower names and account-holder names are encrypted at the field level (AES-256-GCM).
• We do not store full account numbers as data. We keep the last four digits, and any run of 8 or more digits in a transaction description is cut down to its last four before we store it. The source PDF itself may show full account numbers, but it is kept only as encrypted ciphertext and is deleted on the schedule in Section 6.
• Loan inputs the Customer enters: qualifying monthly income, ownership percentage, expense factor, purchase or refinance, loan program, and months required.
• Outputs: income worksheets, letter-of-explanation request lists, and Excel, CSV, and PDF exports. These are generated when someone opens or downloads them and aren't stored as separate files.
• Borrower contact and email records: the borrower email address a Customer enters for an upload link. We also keep a copy of each email the Service sends about a loan file (recipient, subject, and body), so the Customer can see what was sent.

2.4 Borrower upload pages

Borrowers don't create an account. An upload link works for one loan file. It expires after the number of days the broker chooses, from 1 to 7 (7 by default, and never more than 7). It allows a set number of uploads, from 1 to 50 (3 by default); an upload that fails doesn't count. The broker can revoke it at any time. We store only a hash of the link token. When a borrower uploads a file, we record the encrypted document, the upload time, that it came from a borrower link, and the request's IP address in the Customer's audit log. We don't record the borrower's user agent. The upload link record itself stores no IP address or user agent; the IP is recorded only on the audit entry `document.borrower_upload`.

2.5 Logs, error monitoring, cookies, and analytics

• Audit log: for each Customer organization we record actions such as views, exports, downloads, purges, and admin changes. Each entry holds the action, the ID of the item acted on, the user, the time, and (where captured) an IP address. Audit entries are designed to exclude names, email addresses, and account numbers, and entries that look like they contain them are rejected.
• Error monitoring (Sentry): Sentry runs only on our servers. There is no Sentry script in your browser, no session replay, and no Sentry cookie. Before an error report leaves our servers, a scrubber removes email addresses, account-number-like digit runs, tokens, and fields named like names, emails, descriptions, account details, passwords, cookies, phone numbers, Social Security numbers, addresses, and dates of birth. Borrower Data is not intended to be sent.
• Cookies: we use only strictly necessary first-party cookies, to keep you signed in and enforce multi-factor authentication. In production, sign-in runs on Supabase Auth, and the app sets Supabase's sign-in session cookie on statementready.net. By Supabase's default naming this is `sb-[project-ref]-auth-token`, which may be split into numbered parts (`.0`, `.1`, …) when large; sign-in flows may briefly set a related `…-code-verifier` cookie. It holds your sign-in session (access and refresh tokens); the access token inside it expires after a short period (3600 seconds by default; 900 seconds once applied) and the session ends on sign-out or a security event. A separate cookie, `sr_session`, exists only for local development sign-in and is not used in production. Borrower upload pages set no sign-in cookie. We set no analytics, advertising or tracking cookies, and neither Sentry nor PostHog sets any cookie. Stripe sets its own cookies on its hosted checkout and billing pages, under Stripe's policy. Details: statementready.net/cookies.
• Product analytics (PostHog): PostHog is not used in production. We do not send analytics events to PostHog, and there is no PostHog script in the browser.
• No tracking; no cookie banner: the Service uses no browser analytics scripts, tracking pixels, session recording or advertising cookies. Because it sets only strictly necessary cookies, it has no cookie banner. We don't sell personal information or share it for cross-context behavioral advertising; we'd honor a Global Privacy Control signal to the extent it applies to a sale or share (none today). We don't respond to browser Do Not Track signals as a separate protocol because we don't use third-party behavioral tracking.

3. How we use information

Account, waitlist, and website information is used to:

• provide, secure, and support the Service and your account, including MFA and audit logging;
• manage plans, usage, and billing;
• send service messages, such as team invitations, sign-up confirmations, and security and account notices;
• send product updates you've agreed to, and marketing email only if you opted in. Every such email includes a way to unsubscribe.
• prevent abuse, such as rate-limiting sign-ups using hashed IP and user-agent values; and
• comply with law and enforce our terms.

Borrower Data is used only to provide the Service to the Customer that controls it. That means parsing statements, splitting combined PDFs, detecting accounts and periods, reconciling balances to the cent, classifying transactions, generating flags, worksheets, exports, and LOE lists, and sending upload links and reminders on the Customer's behalf. It is also used for security, troubleshooting the Customer asks for, and legal compliance.

We do not:

• sell personal information or Borrower Data;
• use Borrower Data for advertising or marketing;
• create or use de-identified or aggregated Borrower Data. Two things are not Borrower Data reuse: (1) PostHog is not used in production (Section 2.5), so no product-analytics events are sent; and (2) per-statement processing records that we keep in our own database inside the Customer's account and do not send to PostHog or any other analytics provider: whether the statement reconciled, page count, processing time, extraction path, AI processing cost, and a normalized key for the financial institution detected on the statement. We use them only to operate the Service and to show the Customer its own processing summary. They stay in the Customer's organization, behind row-level security, and are not shared. When the statement is deleted (by the 30-day purge, an earlier purge, deleting the loan file, or any other deletion of the statement), the institution key in its record is replaced with the marker "purged" and the record's link to the statement is removed. The rest of the record (extraction path and tier, whether the statement reconciled on the first pass and at the end, whether it was edited after passing, page count, AI cost and processing time) holds no institution key and stays in the Customer's organization until the organization is deleted, which deletes it. (Section 6).
• use Borrower Data to train AI models (Section 4); or
• make lending or credit decisions.

4. AI processing

• How it works: we read a PDF's text layer first. For scanned PDFs, we send one page image at a time, with our extraction instructions, to an AI model provided by Anthropic, PBC. We may also send ambiguous transaction descriptions to Anthropic to help classify them.
• Models: Claude Haiku is the default. Claude Sonnet is used only when a Haiku retry still fails to reconcile a statement to the cent. Anthropic is our only AI provider. No other AI provider receives statement data.
• Checks: AI output is checked by deterministic code, not AI. Each statement must reconcile to the cent (opening balance plus credits minus debits equals closing balance), and anything that doesn't is flagged for human review beside the source page. Users can correct results.
• No automated decisions: StatementReady doesn't make lending, credit, or eligibility decisions. Brokers, lenders, and underwriters do, and they are responsible for verifying outputs.
• No training: we use Anthropic's API under Anthropic's Commercial Terms of Service, which state: *"Anthropic may not train models on Customer Content from Services."* Those terms define Customer Content as "Inputs" (submissions to the Services by Customer or its Users) and "Outputs" (responses generated by the Services to Inputs). (Anthropic Commercial Terms of Service, §B "Customer Content," version effective June 17, 2025, https://www.anthropic.com/legal/commercial-terms, checked 2026-10-15.)
• Retention by Anthropic (standard API retention). StatementReady uses Anthropic's API without a zero-data-retention arrangement. Anthropic's commercial data retention policy says:
• *"For Anthropic API users, we automatically delete inputs and outputs on our backend within 30 days of receipt or generation, except: When you use a service with longer retention under your control (e.g. Files API); When you and we have agreed otherwise (e.g. zero data retention agreement); If we need to retain them for longer to enforce our Usage Policy (UP); In compliance with the law."*
• *"We retain inputs and outputs for up to 2 years and trust and safety classification scores for up to 7 years if your chat is flagged by our automated trust and safety systems as violating our Usage Policy."*
• *"If permitted in your contract with us, we may anonymize your organization's data for research or statistical purposes, in which case we may retain this information for longer."*

(Anthropic Privacy Center, "How long do you store my organization's data?", article dated July 1, 2026, https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data, checked 2026-10-15.)

• In practice: statement page images, prompts and transaction descriptions sent to Anthropic, and the responses, are deleted by Anthropic within 30 days by default. Content that Anthropic's automated trust-and-safety systems flag as violating its Usage Policy may be kept for up to 2 years, with classification scores kept for up to 7 years. Anthropic may also retain data where required by law. The API request carries no retention setting.
• No training: Anthropic Commercial Terms §B (above). Anthropic's developer docs also state: *"Retained data is never used for model training without your express permission."* (https://platform.claude.com/docs/en/build-with-claude/api-and-data-retention, checked 2026-10-15.)

5. How we share information

• With the Customer that controls it. Borrower Data is available only to the brokerage organization that owns the loan file. Database row-level security isolates each organization's data, and it is enabled and forced on every application table. A borrower's uploads go only to the broker who sent the link.
• With our service providers (subprocessors), under contracts that limit their use:

We don't use advertising networks, tracking pixels, browser analytics, or any AI provider other than Anthropic for statements. A current list will be kept at statementready.net/subprocessors. For Customers on our DPA, we will email the account owner at least 30 days before a new or replacement subprocessor begins processing Borrower Data, and we update the list for every change. In an emergency we may replace a subprocessor sooner and will tell you as soon as practicable afterward (DPA §7.3).

• For legal reasons: to comply with law or valid legal process, protect rights and safety, or investigate fraud or misuse. Where the law allows, we tell the Customer before disclosing its Borrower Data.
• Business transfers: in a merger, acquisition, financing, or sale of assets, subject to this Policy and the DPA.
• With your direction or consent.

6. Retention and deletion

Customers control the retention of Borrower Data and are responsible for exporting anything their own legal or lender obligations require them to keep.

7. Security

We are building our information security program around the GLBA Safeguards Rule (16 CFR 314.4) so Customers can include StatementReady in their service-provider oversight. Measures implemented in code include:

• AES-256-GCM encryption of source PDFs and of borrower and account-holder names;
• last-four-only storage of account numbers;
• row-level security isolating each organization, enabled and forced on all application tables in our hosted database;
• required authenticator-app MFA before loan data is shown;
• hashed, single-loan, revocable upload links that expire within 7 days and allow a limited number of uploads;
• audit logging; and
• error reports scrubbed of personal information.

Encryption in transit (TLS) will apply once the Service is deployed. No independent security audit or penetration test has been done yet. Before launch we plan a security self-assessment with free tools, and a third-party penetration test after we have revenue. StatementReady is designed to support brokers' Safeguards Rule obligations for their service providers. No method of transmission or storage is completely secure.

8. Security incidents

If we become aware of a security incident affecting Borrower Data, we will notify the affected Customer within 72 hours, as described in our DPA, so the Customer can meet its own obligations (including any FTC notice under 16 CFR 314.4(j)). We will notify individuals or regulators directly where the law requires us to.

9. Your choices and rights (users, waitlist members, and visitors)

• Access, correction, and deletion: update account details in the app, or email support@statementready.net to ask for access to or deletion of your account or waitlist information.
• Email: use the unsubscribe or withdraw link in any of our emails. Service messages will continue while you have an account.

We won't discriminate against you for exercising your rights.

10. Borrowers

If you uploaded statements through a broker's link:

• The broker (our Customer) asked for your documents and controls how they are used. StatementReady processes them on the broker's behalf.
• Please contact the broker with questions or requests. If you contact us, we will refer you to the broker and help the broker respond.
• Upload links are tied to one loan file, expire within 7 days (the broker chooses 1–7), allow a limited number of uploads (1–50; 3 by default), and can be revoked by the broker. By default, source files are purged 30 days after the broker creates the loan file, unless the broker deletes them sooner.

11. Business use; location; children

The Service is for businesses in the United States. It isn't directed to consumers or to children, and we don't knowingly collect children's personal information. Our database and file storage are in the United States (AWS us-east-1).

12. Changes

We may update this Policy. For material changes, we will email account owners before they take effect.

13. Contact

Varaxon Technologies LLC d/b/a StatementReady · 5372 Washington Street, Camp Lejeune, NC 28547 · support@statementready.net (privacy, security, and general questions)