Corvlyx Privacy Policy

Effective date: September 1, 2026

Status: Draft for counsel review — not legal advice. Replace placeholder contacts before publishing.

Introduction

Corvlyx (“we”, “us”, “our”) provides software for regulated insurance and financial-services outreach. This Privacy Policy describes how we collect, use, store, share, and protect personal information when you use:

• the Corvlyx marketing website and inquiry forms;
• the operator application (Lead Operations, Financial OS, and Marketing modules); and
• APIs, webhooks, and integrations connected to your deployment.

Corvlyx is a software vendor, not an insurance company, agency, or broker. We do not sell insurance products to consumers through the Service.

This policy applies to each single-tenant deployment of Corvlyx (one organization, one database, one shared operator login unless your contract states otherwise).

1. Roles: who is responsible for what

The Service includes compliance assistance features (consent fields, calling windows, do-not-call checks, dry-run defaults). It is a tool, not a compliance certification. Tenants remain solely responsible for their regulatory obligations.

2. Personal information we process

2.1 Lead & client records (Lead Operations / shared client record)

• Identity & contact: name, email, phone, postal address, date of birth (when collected), preferred language.
• Insurance / product interest: product lines, coverage needs, underwriting answers collected in intake or voice flows.
• Consent & notices: `consent_to_store_data`, `consent_to_calls_texts`, `consent_autodialed_written_agreement`, `privacy_notice_provided` (GLBA), channel-specific opt-outs, internal and FTC DNC status when configured.
• Operational metadata: lead score, validation errors, assignment, campaign history, call attempts, incidents, deduplication matches, vendor source fields, quarantine flags.
• Voice intake: call SID, turn transcripts or structured answers from Twilio `<Gather>` flows when voice intake is enabled.

2.2 Voice calling & auto-dialer

• Call initiation metadata (timestamps, agent, lead, disposition).
• Twilio webhook payloads (call status, from/to numbers).
• Voice approval-transfer and realtime voice session state when those features are enabled.
• Call recording: not enabled by default in Corvlyx voice modules unless your deployment configures it separately.

2.3 Outreach & messaging

• Weekly outreach agent: email/SMS content, delivery status, unsubscribe events, frequency-cap metadata.
• SMS / WhatsApp / Instagram DM agent: template sends, thread metadata, inbound replies, STOP/opt-out handling, 24-hour care-window replies.

2.4 Marketing & lead ingestion

• Vendor ping/post payloads, TikTok and Meta Lead Ads webhook data (including raw `source_fields_raw` preservation).
• Meta marketing OAuth tokens and page identifiers when connected.
• Lead discovery (OpenAI-assisted) uses configured models; prompts should not include unnecessary PII.

2.5 Financial OS, FNA & proposals

• Financial needs analysis inputs (income, debts, assets, goals) and generated reports.
• Insurance plan proposals generated from a stored FNA analysis.
• OAuth tokens for Google Calendar and Gmail (encrypted; no raw passwords).

2.6 Agents, licensing & administration

• Agent registry: name, license numbers, states, carrier appointments (self-reported — not verified against NIPR/DOI in the Service).
• Account-type metadata, seat allocation, license provisioning events.
• Shared deployment login credentials (password stored hashed; session JWTs).

2.7 Audit, security & operations

• Hash-chained audit log entries (`audit_log`, module-specific audit tables).
• Report access logs, AI audit logs, follow-up send logs, DLQ entries.
• Telemetry (only when `TELEMETRY_ENABLED=true`): allowlisted events with PII scrubbing; lead identifiers hashed where used.
• Security and rate-limit events; health checks (no consumer PII).

2.8 Website & commercial inquiries

• Pilot, demo, and contact form submissions: name, agency, work email, state, plan interest, honeypot fields.
• Cookie-banner dismissal stored in browser `sessionStorage` on the marketing site (not sent to our servers).

3. How we use personal information

We process personal information to:

• provide, operate, secure, and improve the Service;
• route leads, run campaigns, place calls, and send messages only where tenant configuration and recorded consent allow;
• enforce tenant-configured suppression, calling windows, and dry-run gates;
• generate worksheets (FNA) and proposals for agent review;
• sync with connected integrations (Twilio, SendGrid, Google, Meta) when credentials are supplied;
• maintain tamper-evident audit trails and support incident response;
• respond to tenant support requests and legal process;
• comply with applicable law.

We do not sell personal information. We do not use tenant consumer data to train public AI models.

4. Lawful basis & consent

• Contract: processing necessary to deliver the Service to the tenant.
• Legal obligation: retention or disclosure where required by law.
• Legitimate interests: security monitoring, fraud prevention, and product reliability — balanced against tenant and individual rights.
• Consent: tenants must obtain and document consumer consent where required (TCPA, state autodial statutes, CAN-SPAM, SMS marketing rules, GLBA privacy notice, etc.). The Service records consent fields and may block actions when consent is missing.

5. How we share information

5.1 At tenant direction (integrations)

When the tenant connects third-party services, we share the minimum data needed to:

5.2 Infrastructure & subprocessors

A current subprocessor list should be maintained in your customer agreement or DPA. Update it when integrations change.

5.3 Legal & safety

We may disclose information to comply with law, court order, or government request, or to protect rights, safety, and integrity of the Service.

6. Security

• Encryption at rest: lead blobs, integration tokens, and sensitive columns use AES-256-GCM when `DB_ENCRYPTION_KEY` is set (required in production deployments).
• Indexing: HMAC-SHA256 for exact-match phone/email lookups without storing plaintext in index columns.
• Encryption in transit: HTTPS for all browser and API traffic.
• Access control: API key and session authentication; optional RBAC flags (`RBAC_ENFORCE`). Shared login per deployment today — not per-operator identity.
• Operational defaults: live outreach, messaging, and follow-up sends are off until explicitly enabled; promotion workflows available for follow-ups.
• Audit: hash-chained audit entries for sensitive actions where implemented.

No system is perfectly secure. Tenants should use strong passwords, protect API keys, and limit who can access the operator application.

7. Retention

Default retention is driven by tenant business and regulatory needs (insurance and GLBA contexts often expect multi-year retention). Unless your agreement specifies otherwise:

• Lead/client records: retained until the tenant deletes them or the deployment is decommissioned.
• Audit and send logs: retained for compliance and dispute resolution (default design target: up to 7 years where not shortened by contract).
• OAuth tokens: retained while the integration is connected; revoked on disconnect.
• Website inquiries: retained for sales follow-up and operational records.
• Telemetry: minimal retention when enabled; no raw PII in catalog events.

Deletion requests: end individuals should contact the tenant. Tenants may request Corvlyx assistance to export or delete data in a deployment, subject to legal holds and audit-log exceptions.

8. Your rights

8.1 If you are a consumer or lead

Contact the organization that collected your information (the tenant). They control your client record. Corvlyx processes data on their instructions.

8.2 If you are a tenant operator

You may access, export, correct, or delete lead data through the Service (where features exist) or by requesting support assistance. You are responsible for honoring end-individual rights for data you control.

8.3 California / other US state privacy laws

Where applicable, tenants may need a separate Data Processing Addendum and consumer-facing notices. Corvlyx does not determine the tenant’s consumer-facing privacy policy text.

9. International transfers

Data is primarily processed in the United States. Cross-border transfers use appropriate contractual safeguards where required.

10. Cookies & similar technologies

Marketing website (`/`)

• Session storage: dismisses the cookie/privacy banner for the browser session.
• Analytics: third-party analytics load only if IDs are configured in the deployment; default marketing build ships with none.
• No advertising cookies in the default Corvlyx marketing template.

Operator application (`/app.html`)

• Session token: stored in browser storage for authenticated API calls; required to use the app.
• No third-party ad tracking in the default operator UI.

Email open/click tracking may occur when outreach or follow-up features enable tracking pixels — tenants should disclose this in their communications.

11. Children’s privacy

The Service is not directed to children under 13 (or 16 where applicable). Tenants must not submit children’s personal information without lawful basis and parental consent where required.

12. Changes to this policy

We may update this policy to reflect product, legal, or operational changes. We will post the new effective date. Material changes affecting tenants will be communicated through reasonable channels (email, in-app notice, or contract amendment).

13. Contact

14. Related documents

Appendix A — Data minimization practices (engineering)

These are product defaults tenants should know about:

• Consent-gated `GET /api/leads/:id` when store consent is missing.
• Redacted lead views (`?view=redacted`) without email/phone.
• Report and PDF export masking unless a separate PII access token is presented.
• Telemetry fail-closed (`TELEMETRY_ENABLED=false` by default on Render).
• Dry-run defaults for outreach and messaging until live flags and credentials are set.