Privacy Policy

Lux Edge, a Cozens Corp Company, an Indiana corporation (“Lux,” “we,” “us”)

Effective date: [DATE] Last updated: [DATE]

1. Introduction

This Privacy Policy explains how Lux Edge (“Lux”) collects, uses, discloses, and safeguards personal information in connection with the Lux platform and our websites (including monetizelux.com, luxedge.io and their subdomains) and related services (collectively, the “Services”). Lux operates a real-time offer-decisioning marketplace. When a consumer visiting a website operated by one of our seller customers (each a “Seller,” also called a “Publisher”) does not meet that Seller’s internal marketing-qualification criteria — for example, a declined or non-converting applicant on a debt-settlement or personal-loan page — the Seller’s page calls the Lux decisioning service, and Lux’s machine-learning engine selects and ranks, from offers submitted by our buyer customers (each a “Buyer,” also called an “Advertiser”), a short slate of offers to display to that consumer. If the consumer clicks an offer, they are taken to the Buyer’s own website; any regulated downstream activity — consent collection, credit inquiries, telephone contact — occurs there under the Buyer’s own policies, not on Lux.

Lux operates primarily as a business-to-business service. In most of our processing activities we act as a service provider / processor on behalf of our business customers — the Sellers and Buyers described above (the “Controllers”) — who determine the purposes and means of processing. Consumers do not create Lux accounts, and the direct consumer relationship (and the consumer’s directly identifying information) remains with the Seller or the Buyer. Where we determine those purposes ourselves — for example, our own website, marketing, and account administration — we act as a business / controller, and this Policy applies directly.

2. Our data-minimization design

Lux is engineered to limit its exposure to raw personal information. In particular:

• Pseudonymization. Lux processes consumer identifiers in pseudonymized (hashed) form using a confidential, secret-managed salt; the only per-consumer identifier Lux retains is this salted hash, together with a random impression identifier (UUID) assigned to each decision. Lux does not maintain the salt-to-identity mapping for the purpose of re-identifying consumers.

• Exclusions — two different mechanisms, on two different paths. These were previously described as one control; they are not, and the difference matters.

• On the decisioning path, the Lux decisioning API operates an active denylist: it rejects direct consumer identifiers — name, email address, telephone number, Social Security number, and related keys — outright, for every caller, regardless of any customer configuration. It additionally accepts only a short, per-customer allowlist of coarse attributes (for example, credit-score band, debt-amount band, U.S. state, and device type).

• On the click / prefill path, there is no denylist. Values are constrained by a positive allowlist of eleven fields, and a value transmits only if all three of the following hold: the canonical field is on that hard-coded list, the buyer accepts that field, and the seller actually sent it. Sensitive identifiers are excluded by absence from the list rather than by explicit rejection. The net effect is the same — an unlisted field can never transmit — but the mechanism is an allowlist, and this Policy no longer describes it as a rejection. Year of birth is permitted; a full date of birth cannot pass.

Lux does not collect or store consumer telephone numbers, raw credit reports, or consumer consent records as part of the decisioning flow. Those data elements are handled by the applicable Controller (e.g., a seller or buyer) under their own compliance obligations.

• Deferred regulated activity. Regulated downstream activities that require consumer consent or a permissible purpose (for example, telephone contact governed by the TCPA, or credit-based activities governed by the FCRA) are triggered and performed by the Controller at the point of call transfer, not by Lux.

• Cohort-level learning and reporting, with a narrow reviewed clustering read. Raw decision and outcome records use a salted per-seller pseudonymous identifier and are treated as Personal Information. The learner does not use consumer identity as a feature; customer outputs are cohort-level and subject to the N=25 floor. A narrow, reviewed single-population clustering read may reference the pseudonymous key to compute incrementality, but it never returns individual consumer rows or joins an individual's outcomes across buyers. Lux does not build or sell individual consumer profiles.

3. Information we collect

3.1 Information about business users

• Name, business email, telephone, company, role, and login credentials of personnel at our seller and buyer customers.

• Billing, transaction, and account-administration information.

3.2 Consumer data processed on behalf of Controllers

• Hashed / pseudonymized consumer identifiers submitted by sellers or data partners.

• Coarse, non-identifying attributes used for decisioning (for example, credit-score band, debt-amount band, U.S. state, and device type), together with impression, click, and conversion events keyed to a random impression identifier and, where applicable, the billable value credited for a conversion.

The specific categories for each customer are governed by the applicable Data Processing Agreement (DPA) and its processing schedule.

3.2.1 Prefill relay

Where a buyer accepts them and a seller sends them, Lux relays a limited set of fields into the buyer's application form so a consumer does not retype what they have already provided. This is stated here for the first time; it was previously described in no customer-facing document.

• Eleven fields, positive allowlist, enforced by the three-condition gate described in §2 above.
• Consent lines are excluded. A consent or authorization field is never relayed; the buyer obtains its own consent.
• Transient in Lux's systems, but present in the page. Relayed values are never written to any Lux database, key-value store, disk cache, or log. They are, however, delivered to the consumer's browser in the page body in order to reach the buyer's form. This Policy previously implied they were memory-only, which understated where the values appear.

3.2.2 Attributes Lux will not accept at all

Following counsel's direction of 2026-08-11, the decisioning API refuses any attribute constituting a prohibited basis under ECOA, Regulation B, or the Fair Housing Act: age (and any banding or derivation of it), race, ethnicity, color, religion, national origin, sex, gender, sexual orientation, marital or familial status, household size, receipt of public assistance, disability, and veteran or military status.

This refusal is absolute. It applies in every environment, in both strict and permissive validation modes, and regardless of any customer's configured allowlist — a customer cannot re-enable a prohibited basis by configuration. It binds at two independent layers: the request is rejected on arrival, and any campaign targeting rule referencing a denied attribute is dropped before it can influence a decision. The second layer is the load-bearing one, because campaign rules are read directly from the database rather than through an administrative interface.

A distinction that matters, and which this Policy states rather than leaves to inference. Three of the fields on the prefill allowlist in §3.2.1 — marital status, veteran status, and household size — also appear in the list above. That is deliberate and is not a contradiction:

• As decisioning inputs they are prohibited. No Buyer may target, rank, filter or exclude on them; they are never stored as a feature; the engine cannot read them.
• As transient prefill values they may pass through to a Buyer's own application form, where they are ordinary application fields used downstream for product fitting — a dedicated veterans' loan product being the clearest example.

The prohibition attaches to using a characteristic to evaluate or rank a credit offer, which Lux does not do. Relaying a value the consumer already supplied, to a form the consumer is choosing to complete, is not an evaluation. Lux additionally refuses veteran status as a decisioning input outright, which is stricter than the law requires.

3.3 Information collected automatically

• Device, browser, IP address, and usage/log data.

• Cookies and similar technologies (see our Cookie Policy).

Referrer control. The Lux offer page is served with Referrer-Policy: no-referrer, so no query parameter on that page — including any relayed prefill value — is disclosed to a Buyer's third parties through the referrer header when a consumer clicks through. This is a property of the offer page itself. An earlier draft attributed it to the outgoing redirect; that was inaccurate.

4. How we use information

• To provide, operate, secure, and improve the Services and our decisioning models;

• To administer accounts, authenticate users, and process billing;

• To perform the decisioning and matching functions requested by Controllers;

• To monitor, prevent, and investigate fraud, abuse, and security incidents;

• To comply with legal obligations and enforce our agreements;

• To develop and improve models on a de-identified or aggregated basis, consistent with applicable law and our customer agreements.

5. How we disclose information

• Customers. To our business customers (Controllers) as part of delivering the Services;

• Service providers. To sub-processors and vendors that host, secure, or support the Services, under written contracts (see the DPA sub-processor list);

• Legal / safety. To comply with law, legal process, or lawful government requests, and to protect rights, safety, and property;

• Business transfers. In connection with a merger, acquisition, financing, or sale of assets, subject to this Policy;

• With consent. With your consent or at your direction.

6. “Sale” and “sharing” of personal information

Certain U.S. state laws (including the California Consumer Privacy Act as amended by the CPRA) define “sale” and “sharing” broadly. Lux does not sell or share personal information as those terms are defined by the CCPA/CPRA. Contextual tuples used for learning are stripped of identifiers, and all processing for a customer is performed under a service-provider agreement that restricts use to that customer's business purpose.

Where Lux acts as a service provider under a written contract that prohibits retaining, using, or disclosing personal information except as necessary to perform the Services, such transfers are not a “sale.”

7. Your privacy rights

Depending on where you live, you may have some or all of the following rights, subject to legal exceptions:

• The right to know / access the personal information we hold about you;

• The right to delete personal information;

• The right to correct inaccurate personal information;

• The right to opt out of the sale or sharing of personal information;

• The right to limit the use of sensitive personal information;

• The right to non-discrimination for exercising your rights;

• The right to appeal a decision on your request (in certain states).

To exercise these rights, contact us at pcozens.inc@gmail.com or [WEBFORM URL / TOLL-FREE NUMBER]. We will verify your request as required by law. You may use an authorized agent. Because much of the consumer data we hold is pseudonymized and processed on behalf of a Controller, we may need to route your request to the relevant Controller or require additional information to locate your data. Deletion requests are executed against the pseudonymized identifiers (the salted hash or the impression identifier); Lux cannot look up consumer records by name, email address, or telephone number because it does not store them.

European/UK residents: where GDPR/UK GDPR applies, you also have rights to restriction, objection, portability, and to lodge a complaint with a supervisory authority. Our lawful bases are [legitimate interests / contract / consent / legal obligation — CONFIRM].

8. Financial-data notice (GLBA)

Lux is an ad-decisioning technology service, not a financial institution, and is not directly subject to the Gramm-Leach-Bliley Act. Where Lux's customers are financial institutions with GLBA obligations of their own, Lux maintains administrative, technical and physical safeguards designed to support those downstream requirements, and any GLBA privacy notice is delivered by the financial institution rather than by Lux.

9. Data retention

We retain personal information only for as long as necessary for the purposes described in this Policy, to comply with legal, tax, and regulatory obligations, and to resolve disputes, in accordance with our Data Retention & Deletion Policy and the applicable DPA.

The principal periods confirmed by counsel are configured in the purge process and listed below. The purge process is configured and has been manually exercised; evidence of its first unattended scheduled execution is pending.

Point-in-time backup recovery covers a rolling 7-day window. A consumer deletion request is keyed to the pseudonymized identifier or the impression identifier, because Lux cannot search for a consumer by name, email address or telephone number — it holds none of them. Security and audit records are keyed by event rather than by consumer and are therefore not reachable by such a request; they age out on the schedule above instead.

10. De-identification, re-identification, and cohort reporting

Lux makes the following commitments publicly, because a technical control and a public undertaking are separate requirements under California law and Lux relies on both.

• We state the difference honestly. A salted, per-seller consumer hash is a pseudonymous identifier and remains personal information under the CCPA. Lux does not describe it as anonymous or de-identified merely because it cannot be mapped to a name. Records keyed to it are treated as personal information for every purpose in this Policy.
• What is de-identified is the learning corpus, and it is de-identified by construction. Pseudonymous keys are never carried into it. What the model learns from is unlinked contextual tuples — credit band, debt band, and outcome, within a population — which identify no consumer and cannot be re-linked to one. Publisher identity partitions populations; it is not a scoring input. A publisher's audience can carry a demographic footprint, so allowing the model to optimize on which publisher sent the traffic could disadvantage that publisher's audience with no protected attribute ever being used. Lux therefore bars publisher identity from the model's feature set outright. State is deliberately not among them. It is used exclusively as a pre-ranking licensing gate: an offer whose advertiser lacks a licence in the consumer's state is removed before ranking begins, and the model then scores only the remaining, eligible offers. Lux does not optimize which offer a consumer sees on the basis of where they live.
• We commit to maintain that data in de-identified form, to make no attempt to re-identify it, and to implement and maintain technical controls that prevent re-identification.
• We contractually prohibit our customers and sub-processors from re-identifying it, and will not authorize any party to do so on our behalf.
• Cohort reporting carries a minimum-cell floor and complementary suppression. Any customer-facing report that breaks results down by consumer attributes suppresses a cell built on fewer than 25 observations, showing it as "<25" rather than merging it into a neighbouring cell or flagging it. When exactly one cohort in a closed reported total would be suppressed, Lux withholds one additional cohort so the hidden result cannot be reconstructed by subtraction. If no peer cohort exists, the pooled total is withheld as well. The floor binds seller lift dashboards and any customer-facing performance report exposing attribute intersections. It does not bind counterparty account balances, billing statements, or internal administrative reporting held behind access control, none of which expose a consumer attribute profile.

11. Security

We maintain administrative, technical, and organizational measures designed to protect personal information, including encryption of data in transit and at rest, access controls, salt/secret custody controls, and monitoring. No method of transmission or storage is completely secure. See our Incident Response & Breach Notification Policy for how we handle security incidents.

12. International transfers

Lux is based in the United States. If you access the Services from outside the United States, your information may be transferred to, stored, and processed in the United States. Where required, we rely on appropriate safeguards such as the Standard Contractual Clauses. [CONFIRM whether Lux processes EU/UK data.]

13. Children’s privacy

The Services are not directed to children under 16, and we do not knowingly collect personal information from children.

14. Changes to this Policy

We may update this Policy from time to time. Material changes will be posted with a new effective date.

15. Contact us

Lux Edge, a Cozens Corp Company, an Indiana corporation

[REGISTERED ADDRESS]

Email: pcozens.inc@gmail.com Data protection contact: [NAME], pcozens.inc@gmail.com