Subprocessor Register
Effective Date: August 13, 2026
Version: 1.0
Operator: ARYX LLC (aryx.pro). The contracting party named on an Order Form controls for that transaction.
This page is the customer-facing Subprocessor Register for ARYX. It lists third parties that may process Member Data in support of the Services. Vendor-management process details are maintained internally and are available to Customers upon reasonable request under the DPA.
ARYX operates a multi-tenant B2B software platform for health-plan enrollment, administration, and billing. Core applications include EnrollFlow (member enrollment; may process PHI), ARYX CRM, ARYX Accounts (identity, SSO, org provisioning, and subscription billing), AdvisorIQ, and IT Ticketing / Support.
1. Subprocessor Register
10.1 The following table is the authoritative Subprocessor Register as of the Effective Date. It is a living document: it is updated whenever a Subprocessor is added, replaced, materially reconfigured, or retired, and each such change is versioned and dated. Where /legal/dpa (Annex III) or ARYX's third-party dependency standards summarizes Subprocessors, this Register controls in the event of any discrepancy.
10.2 "BAA status" is required for any Subprocessor that may store, transmit, or access PHI. "DPA status" is required for any Subprocessor that Processes member PII or financial data. Processing locations reflect each Vendor's contracted configuration (United States unless noted).
| Subprocessor | Service Provided | Data Categories (incl. PHI?) | Processing Location / Region | DPA Status | BAA Status (required if PHI) | Notes |
|---|---|---|---|---|---|---|
| Supabase | Primary Postgres database, Auth, and Storage; RLS enforces org-scoped multi-tenant isolation | Member PII, financial/transaction records, Tenant-staff credentials, PHI (yes) | United States | as executed with the vendor | Required; as executed with the vendor | System of record for all Member Data; Critical dependency. PHI resides here via EnrollFlow. |
| Vercel | Application hosting and edge/serverless compute for all apps | In-transit request data; PHI possibly in transit and in request/runtime logs — potentially yes | United States / global edge | as executed with the vendor | as required based on data categories (PHI may traverse hosting/logs) | Not a primary datastore of record; PHI exposure is transit/log-borne. Log retention and BAA scope are managed under vendor contracts. |
| Authorize.Net (Processor) | Payment processing; CIM stored payment profiles; Accept.js tokenization; inbound webhooks (Processor-specified signature verification) | Cardholder data (PAN/CVV — held by Processor, never by ARYX), payment tokens, transaction metadata. No PHI. | United States | Processor / merchant terms (Tenant holds the merchant account) | N/A (no PHI) | PCI-DSS validated service provider. Tenant holds the merchant account; funds settle Processor → Tenant. See /legal/funds-flow. Authorize.Net is the payment Processor; the Tenant holds the merchant account. |
| Resend | Transactional email delivery (enrollment, billing, notifications) | Member PII / contact identifiers; email content may contain PHI — potentially yes | United States | as executed with the vendor | Required if PHI in content; BAA or content-restriction controls as applicable | If message bodies can carry PHI, BAA is required; otherwise restrict content to non-PHI by design. |
| GoTo | SMS and voice for CRM and member communications | Member PII (phone numbers), message/call content & metadata. PHI possible if content includes it. | United States | as executed with the vendor | required if PHI may appear in content | Assess whether SMS/voice content can include PHI; restrict or execute BAA accordingly. |
10.3 Additional operational dependencies that are not classic Member-Data Subprocessors (e.g., DNS/CDN/TLS transit, identity providers used for Customer-federated SSO) are inventoried in ARYX's third-party dependency standards. Where such a dependency begins Processing Member Data, it is brought into this Register under ARYX's vendor management process.
2. Notifying Tenants of New Subprocessors; Objection Window
11.1 General authorization. Consistent with /legal/dpa, Customer provides general written authorization for ARYX to engage Subprocessors, subject to the notice and objection rights below.
11.2 Advance notice. Before adding or replacing a Subprocessor that will Process Member Data, ARYX will give affected Tenants at least 30 days' prior notice, identifying the new Subprocessor, the service it provides, the data categories involved (including whether PHI), and the processing region. Notice is delivered via email to the Tenant's notice contact of record and/or this Subprocessor Register page and is reflected in an updated version of the Register (Section 10).
11.3 Objection window and right. During the notice period, a Tenant may object on reasonable, documented data-protection grounds by notifying legal@aryx.pro. ARYX will work in good faith to address a reasonable objection (for example, by offering an alternative configuration or Subprocessor where feasible). If the parties cannot resolve a reasonable objection, the Tenant's sole remedy is to terminate the affected portion of the Services under /legal/terms, as provided in /legal/dpa.
11.4 Emergency substitutions. Where a Subprocessor must be replaced on short notice for security, continuity, or legal reasons, ARYX may make the change with such notice as is reasonably practicable and will notify affected Tenants promptly thereafter, preserving the objection right on a post-hoc basis.
3. Precedence, Cross-References, and Review
12.1 This Policy is owned by ARYX LLC and reviewed at least annually or upon any material change to the Vendor inventory, whichever is sooner. The Register (Section 10) is maintained on an ongoing basis and is the source of truth for the Subprocessor list referenced elsewhere.
12.2 This Policy is subordinate to, and does not amend, /legal/terms, /legal/dpa, and /legal/baa; in the event of conflict, those agreements control on their respective subject matter. Related documents: /legal/privacy, /legal/sla, /legal/funds-flow, ARYX's internal payment processing standards, ARYX's refund and settlement standards (see also /legal/billing), ARYX's financial reconciliation standards, ARYX's third-party dependency standards, ARYX's incident response commitments, ARYX's business continuity standards, and ARYX's data ownership and retention terms.
12.3 Governing law and venue for any dispute arising under this Policy are as set forth in /legal/terms (the laws of the United States / the courts designated on the applicable Order Form).
Questions about this document? Contact legal@aryx.pro. Related: all legal documents · Privacy Policy · Terms of Service.