Data Processing Addendum

1. Roles and scope

For player screening data, the operator is the controller and [COMPANY NAME] ("InlineShield") is the processor. This addendum forms part of the Terms of Service.

2. Subject matter, nature, purpose and duration

• Subject matter and nature: receiving, analysing, scoring and storing registration data sent through the API or the browser script.
• Purpose: fraud and abuse screening at registration, for the operator, and improving that screening as set out in section 3b.
• Duration: the term of the agreement, plus the deletion period in section 6.

3. Categories of data and data subjects

• Data: email address, username, IP address, user agent, timing and behaviour signals (for example form dwell time and honeypot field), the browser time zone, browser languages and browser automation indicators (when the operator uses the browser check), and derived risk scores and verdicts.
• Also processed: IP-derived network and location data (country, city, ASN, ISP), detection reasons and triggers, reviewer actions and notes in quarantine, and allow and block list entries supplied by the operator.
• Data subjects: the operator's prospective players or users.

IP location and network lookups use a local database on our own servers, so no player data is sent to DB-IP. The Tor Project's public exit list is downloaded to our servers, and nothing is sent to it. IP geolocation by DB-IP (licensed CC BY 4.0).

3a. Mailbox comparison and VPN data

To detect the same mailbox used for several signups, we reduce the email address to a canonical form and compare it as a keyed hash (HMAC-SHA256 with a server secret and the operator's identifier). The comparison uses only that operator's own data and cannot be joined across operators. The canonical address is not stored. The browser check collects the data listed above for screening only; it creates no persistent identifier and is not fingerprinting.

VPN detection uses the X4BNet lists_vpn project (MIT licence), derived in part from IPLocate data (CC BY-SA 4.0), and time zones are matched to countries with the IANA time zone database (public domain). These are downloaded to our servers, and no player data is sent to them.

3b. Service improvement

To improve detection, InlineShield keeps labels (whether a screening was fraud or legitimate, from the operator's review decisions, its outcome reports, its "Mark as fraud / legitimate" button, or our own test runs, with an optional category and a short note) and feature snapshots (a privacy-safe summary of each screening: email domain and provider type, ASN, IP prefix (the /24 of an IPv4 address or the /48 of an IPv6 address), country, bot signals and the engine's result, with no email local part and no full IP address).

Learning across clients uses only the email domain, the ASN, the IP prefix and counts of distinct operators. An operator's labels never train another operator's model, and its labels and notes are never shown to another operator.

4. Controller's obligations

• The operator has a lawful basis for sending the data to us and for the screening, and gives its players the required notices.
• The operator's instructions, including its use of the API and its settings, comply with data-protection law.

5. Processor obligations

InlineShield will:

• process the data only on the operator's documented instructions, including instructions given through the API, unless the law requires otherwise (in which case we tell the operator first, unless the law forbids it);
• tell the operator if an instruction appears to us to infringe data-protection law;
• ensure that personnel with access are bound by confidentiality;
• limit support access: InlineShield support may access a client's console to provide support, only by a platform superadmin, for at most one hour at a time, and every access is logged and visible to the client in its activity log;
• apply the security measures in Annex 1;
• help the operator respond to data-subject requests, and with data-protection impact assessments and prior consultation of authorities, taking into account the nature of the processing;
• notify the operator of a personal-data breach without undue delay, and within 72 hours of becoming aware of it. The notice will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point;
• make available the information needed to demonstrate compliance with this addendum.

6. Retention and deletion

The raw email address, username, IP address and user agent of each screening and quarantine record, and in the webhook delivery log, are removed automatically after 180 days, and label notes 180 days after the label is recorded; the dashboard then shows "Removed after 180 days". Labels and feature snapshots (section 3b) are deleted automatically after 13 months.

The rest of the player screening data is kept for as long as the operator's account exists, unless the operator deletes quarantine records earlier in the dashboard or asks us to delete data. When the agreement ends, we delete the data within 30 days (or return it, if the operator asks for that instead). The exception is invoices (invoice number, amounts, dates, and the billing name, address, tax ID and email shown on them), which are kept after deletion because they are financial records. Backups are deleted automatically after about 16 days.

7. Audit

On reasonable notice, and at most once a year unless there has been a breach or an authority requires it, the operator may audit our compliance with this addendum. We will first provide documentation and answers to its questions; an on-site or technical inspection follows only if that is not enough.

8. Sub-processors

• Contabo Inc.: server hosting, United States (St. Louis, Missouri).
• Zylomail (smtp.zylomail.com): transactional email (verification, password reset, alerts).

Domain-name lookups (MX, TXT, DMARC and DKIM records of the email domain, and the IPv4 (A) records of its mail servers, never the full email address) are sent to the DNS resolvers configured on our servers, currently Cloudflare (1.1.1.1) and Google (8.8.8.8).

We do not currently use any AI or third-party analysis service for player data; we will add any such service to this list, with notice, before using it.

We put written data-protection terms in place with each sub-processor that stores or processes personal data (hosting and email provider) and remain responsible for them. Public DNS resolvers receive only email domain names, not personal data about individuals. Operators are notified of changes to this list 14 days ahead and may object by terminating the agreement.

9. International transfers

[COMPANY NAME] is established in Armenia, and data is hosted in the United States. For customers in the EU/EEA or the UK, we offer to sign the EU Standard Contractual Clauses (controller to processor, module 2) and the UK addendum; they are available on request to [email protected].

10. Precedence

On data protection matters, this addendum prevails over the Terms of Service.

11. Signed copy

To obtain a signed copy, email [email protected].

Annex 1: Security measures

• HTTPS with HTTP Strict Transport Security;
• passwords stored only as salted scrypt hashes; session, API-key and verification tokens stored as hashes;
• tenant isolation of customer data;
• SMTP credentials stored encrypted (AES-256-GCM);
• rate limiting and login lockouts;
• nightly database backups, deleted automatically after about 16 days.