Acceptable Use Policy

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.

1. Purpose and Scope

1.1 This Acceptable Use Policy (the "AUP") governs the manner in which the ARYX platform (the "Services") may and may not be used. ARYX is a multi-tenant B2B software-as-a-service platform for health-plan enrollment, administration, and billing, operated by ARYX LLC ("ARYX", "we", "us"). The Services include the EnrollFlow enrollment application, ARYX CRM, ARYX Accounts (the identity, single-sign-on, and billing hub at aryx.pro / app.aryx.pro), AdvisorIQ, and the IT ticketing/support application, together with their APIs, webhooks, and interfaces.

1.2 This AUP is incorporated by reference into, and forms part of, the Master Subscription Agreement between the parties (see /legal/terms, the "MSA"). Capitalized terms not defined here have the meanings given in the MSA. In the event of a conflict between this AUP and the MSA regarding permitted use, the MSA controls unless it expressly defers to this AUP.

1.3 This AUP binds every party that accesses the Services: the Customer (also referred to as the "Tenant") — the health plan, agency/brokerage, or benefit administrator that subscribes to the Services — and every Authorized User the Customer permits to access the Services on its behalf. The Customer is responsible for ensuring that its Authorized Users, its own end users (including Members and prospective enrollees who transact through EnrollFlow), and any third party acting on the Customer's behalf comply with this AUP. A violation by any such person is treated as a violation by the Customer.

1.4 ARYX may update this AUP from time to time in accordance with the change-control and notice provisions of the MSA. New abuse vectors may require ARYX to act before a formal amendment cycle; Section 8 preserves ARYX's right to respond to imminent threats.

2. Definitions

Capitalized terms not defined here have the meaning given in the MSA. Key terms include:

• Authorized User — an individual (Tenant staff, administrator, agent, or contractor) whom the Customer authorizes to access the Services under the Customer's Subscription.
• Member Data / PHI — member and enrollee personal information and, within EnrollFlow, protected health information subject to HIPAA and the applicable Business Associate Agreement (see /legal/baa).
• Processor — Authorize.Net, the payment gateway used to tokenize and submit charges. ARYX uses Authorize.Net CIM (Customer Information Manager) stored payment profiles together with a schedule-driven recurring charge engine; card data is tokenized in-browser via Accept.js so that the primary account number ("PAN") and card verification value ("CVV") never reach ARYX systems.
• Subprocessor — a third party engaged to process data in support of the Services (including Supabase, Vercel, Resend, GoTo, and Authorize.Net).
• Tenant Isolation — the logical separation of each Customer's data enforced in Postgres through org-scoped Row-Level Security ("RLS") on Supabase, such that one Tenant cannot read or write another Tenant's data.
• Prohibited Data — any data type described in Section 5 that must not be entered into the Services or into fields not designed to receive it.

3. General Standard of Conduct

3.1 The Customer and its Authorized Users must use the Services only for their intended, lawful business purpose: enrolling and administering Members, managing Tenant relationships, provisioning identity and billing through ARYX Accounts, and the related workflows the Services provide. Use must at all times comply with applicable law, the MSA, this AUP, and the other policies incorporated into the MSA, including the payment-related policies at /legal/billing, /legal/funds-flow, and ARYX's refund and settlement standards (see also /legal/billing).

3.2 The Customer is responsible for all activity that occurs under its Subscription and its Authorized Users' credentials, whether or not the Customer authorized the specific activity, except to the extent the activity results from ARYX's own breach of its security obligations under the MSA.

4. Prohibited Conduct

The following activities are prohibited. This list is illustrative, not exhaustive; conduct that is analogous in nature or effect is likewise prohibited.

4.1 Unlawful and Harmful Use

Using the Services in violation of any applicable law, regulation, court order, or third-party right; to further fraud; to violate HIPAA, the Telephone Consumer Protection Act ("TCPA"), CAN-SPAM, state privacy or insurance laws, or export-control and sanctions laws; or to store, transmit, or promote material that is unlawful, defamatory, harassing, or infringing.

4.2 Malware and Malicious Code

Uploading, transmitting, introducing, or attempting to introduce any virus, worm, ransomware, trojan, logic bomb, or other malicious code, or any file or payload designed to disrupt, disable, overburden, or impair the Services, any Subprocessor system, or any other Tenant's environment.

4.3 Unauthorized Access and Circumvention of Tenant Isolation

Accessing or attempting to access any account, org, data, or system that the Customer is not authorized to access. In particular, and without limitation, the Customer and its Authorized Users must not attempt to bypass, defeat, probe, or circumvent Tenant Isolation or the org-scoped RLS controls; must not attempt to read, modify, or exfiltrate another Tenant's data (including another Tenant's Member Data or PHI); must not manipulate org_id, tenant slug, JWT claims, session tokens, or SSO assertions issued by ARYX Accounts to impersonate another org or user; and must not exploit or attempt to exploit any vulnerability, misconfiguration, or defect to obtain access beyond the Customer's entitlement. Cross-tenant access attempts are treated as a serious security violation subject to immediate suspension under Section 8.

4.4 Scraping, Excessive Automation, and Rate-Limit Evasion

Using bots, scrapers, crawlers, or other automated means to access or extract data from the Services except through documented, authorized API endpoints and within published limits; generating load that is excessive relative to the Customer's Subscription or that degrades the Services for other Tenants; or evading, disabling, or working around rate limits, quotas, throttling, WAF rules, CAPTCHAs, or other protective controls (including by rotating IP addresses, keys, or accounts to defeat a limit).

4.5 API Misuse

Using ARYX APIs, webhooks, or integration credentials other than as documented and permitted (see ARYX's integration and API standards). This includes exceeding published rate limits; using deprecated or undocumented endpoints to obtain data outside the Customer's entitlement; sharing, reselling, or embedding API credentials in a manner that exposes them; forging or replaying webhook payloads; or failing to validate inbound webhook signatures the Customer is responsible for verifying.

4.6 Credential Sharing and Account Integrity

Sharing, selling, or transferring login credentials, API keys, or session tokens; permitting more individuals to use the Services than the Customer's seat entitlement allows by sharing a single credential; using another person's credentials; or circumventing authentication, single-sign-on, or multi-factor controls provided through ARYX Accounts. Each Authorized User must have their own individually attributable credential.

4.7 Prohibited Data in the Wrong Fields

Entering, uploading, or transmitting data types the Services are not designed to receive, or placing sensitive data into fields not designated for it — for example, entering a Member's Social Security number, PHI, or a full payment card number into a free-text note, name, tag, or comment field in ARYX CRM, a support ticket, or an email/SMS body. Prohibited Data must never be placed outside the designated, access-controlled fields designed for it. See also Section 4.11 and ARYX's PCI-DSS cardholder data posture.

4.8 Unlawful or Unsolicited Communications

Using the Services (including EnrollFlow notifications, ARYX CRM outreach, Resend email, or GoTo SMS/voice) to send spam, unsolicited bulk messages, unsolicited marketing SMS or calls, or any communication that violates the TCPA, CAN-SPAM, or applicable telemarketing, do-not-call, or consent requirements. The Customer is solely responsible for obtaining and maintaining the legally required consent for every message it originates and for honoring opt-outs, in accordance with ARYX's electronic communications standards. ARYX provides the delivery mechanism; the Customer is the sender.

4.9 Reverse Engineering

Decompiling, disassembling, reverse engineering, or otherwise attempting to derive the source code, underlying structure, models, or non-public design of the Services, except to the limited extent this restriction is unenforceable under applicable law; or accessing the Services to build a competing product or to benchmark for a competitor.

4.10 Interference with the Services or Other Tenants

Taking any action that imposes an unreasonable or disproportionate load on the infrastructure (Vercel, Supabase, or any Subprocessor); interfering with, disrupting, or degrading the Services or any other Tenant's use; conducting penetration testing, vulnerability scanning, denial-of-service testing, or "red team" activity against the Services without ARYX's prior written authorization; or attempting to gain unauthorized access to ARYX's or a Subprocessor's networks, servers, or data.

4.11 Payment Abuse, Fraud, and Card Testing

Submitting fraudulent, unauthorized, or knowingly invalid transactions; using the Services or the Processor integration to test, validate, or enumerate stolen, generated, or otherwise unauthorized payment cards ("card testing" / "carding"); initiating charges without a valid, disclosed authorization from the Member (see /legal/consent); processing transactions unrelated to the Customer's bona fide enrollment and administration activity; or using the Services to launder funds or evade sanctions. Because funds settle Processor → Tenant and never flow through ARYX, the Customer remains the party responsible to the Processor and card networks for the legitimacy of every transaction it originates.

4.12 Storage of Raw PAN and Sensitive Authentication Data

Entering, transmitting, or attempting to store a raw PAN, CVV/CVV2, full magnetic-stripe or chip data, or PIN/PIN-block ("sensitive authentication data") anywhere in the Services. ARYX maintains a PCI-DSS SAQ-A posture in which card data is tokenized in-browser via Accept.js and only an opaqueData token or CIM profile identifier is handled; introducing raw cardholder data into the platform (including into notes, tickets, uploads, or logs) violates this AUP and the Customer's own PCI obligations. See ARYX's PCI-DSS cardholder data posture.

5. Customer and Authorized User Responsibilities

5.1 The Customer must (a) keep credentials confidential and provision an individually attributable account for each Authorized User; (b) promptly deactivate access for Authorized Users who leave or change roles; (c) configure enrollment, communication, and billing workflows in compliance with law and with the consents obtained under /legal/consent and ARYX's electronic communications standards; (d) enter Member Data, PHI, and payment data only into the designated fields; and (e) monitor its own Authorized Users for compliance with this AUP.

5.2 The Customer must promptly notify ARYX (see Section 7) of any actual or suspected unauthorized access, credential compromise, cross-tenant data exposure, or other security incident involving the Services of which it becomes aware, consistent with the incident and breach-notification obligations in the MSA and /legal/baa.

6. Monitoring and Enforcement

6.1 ARYX does not routinely monitor the content of Customer data and is not obligated to do so. ARYX may, however, monitor use of the Services (including aggregate traffic, security telemetry, rate-limit and abuse signals, and audit logs) to operate, secure, and protect the Services and other Tenants, and to investigate suspected violations of this AUP, in each case consistent with /legal/privacy and applicable law.

6.2 ARYX may investigate suspected violations and may require the Customer's cooperation. The Customer must reasonably cooperate with any such investigation and must remediate a confirmed violation within the timeframe ARYX specifies given the severity of the issue.

7. Reporting Abuse

7.1 To report suspected abuse, security vulnerabilities, unauthorized access, cross-tenant data exposure, spam or unlawful communications, or other violations of this AUP, contact ARYX at:

• Abuse / general violations: hello@aryx.pro
• Security vulnerabilities and suspected breaches: legal@aryx.pro
• Privacy concerns: legal@aryx.pro
• Written notice: the notice address designated on the applicable Order Form

7.2 Reports should include enough detail to identify and reproduce the issue (affected app, org/Tenant if known, timestamps, URLs or endpoints, and a description of the conduct), while not including Prohibited Data (do not paste raw PAN, CVV, or unnecessary PHI into a report). ARYX will acknowledge and triage reports in accordance with its incident-response process and target response times of acknowledge within 1 business day; triage within 3 business days. ARYX does not tolerate retaliation against a person who reports a suspected violation in good faith.

8. Consequences of Violation

8.1 Range of remedies. A violation of this AUP may result, at ARYX's reasonable discretion and proportionate to the severity, in one or more of the following: a warning and request to remediate; throttling or rate-limiting; suspension of an individual Authorized User, an API credential, or a specific feature; suspension of the Customer's access to the Services in whole or in part; or termination of the Subscription in accordance with the MSA.

8.2 Immediate suspension. ARYX may suspend access immediately and without prior notice where it reasonably determines that the conduct (a) poses an imminent threat to the security, integrity, or availability of the Services, a Subprocessor, or another Tenant's data (including any cross-tenant access attempt under Section 4.3); (b) involves suspected fraud, card testing, or unlawful activity; (c) exposes ARYX to legal liability; or (d) is required to comply with law or a governmental request. Where practicable, ARYX will notify the Customer promptly after suspension and will restore access when the underlying issue is resolved to ARYX's reasonable satisfaction. ARYX will use reasonable efforts to scope any suspension narrowly to the offending user, credential, or activity, but reserves the right to broaden the scope where necessary to contain a threat.

8.3 Cooperation with authorities. ARYX may report conduct it reasonably believes to be unlawful (including payment fraud, card testing, unauthorized access, and unlawful communications) to law enforcement, the Processor, card networks, or other appropriate authorities, and may cooperate with, and disclose relevant information in response to, valid legal process, consistent with /legal/privacy and applicable law.

8.4 No liability for enforcement; survival. ARYX is not liable to the Customer or any third party for any good-faith enforcement action taken under this Section, including suspension or termination. Suspension does not relieve the Customer of its payment obligations for the affected period except as expressly provided in the MSA or /legal/billing. The Customer's indemnification obligations for AUP violations, and any accrued rights and remedies, survive termination.

9. Relationship to Other Policies

This AUP operates together with, and does not limit, the other components of the MSA, including /legal/terms, /legal/privacy, /legal/baa, /legal/sla, /legal/billing, /legal/funds-flow, /legal/consent, ARYX's refund and settlement standards (see also /legal/billing), ARYX's PCI-DSS cardholder data posture, ARYX's electronic communications standards, and ARYX's integration and API standards. Where a more specific policy addresses a subject (e.g., payment abuse, communications consent, API limits), that policy governs the detailed requirements and this AUP supplies the baseline prohibition.

---