Data Processing Addendum

1.1 What this DPA covers. This DPA governs the Processing of Player Data: personal data about the Operator's players that we Process on the Operator's behalf when we provide the sportsbook service described in the Terms (the "Service").

1.2 What this DPA does not cover. It does not cover personal data that we Process as a controller for our own purposes, which our Privacy Policy describes, including:

(a) the accounts of the Operator's console users and invited team members (name, email, credentials, sign-in and security records, acceptance of the Terms);(b) the Operator's billing, invoicing and payment records;(c) messages and requests sent to us through our website or by email;(d) visitors of our website and of our public demo at demo.thesportsbook.app, where we run the demo sportsbook ourselves; and(e) the limited own-purpose Processing of Player Data described in Section 3.4.

1.3 Which law applies. This DPA applies whenever Data Protection Law applies to the Processing of Player Data, including because we are established in the European Union, even if the Operator and its players are outside the European Economic Area ("EEA").

2.1 Terms written with capitals that are not defined here have the meaning given in the Terms.

2.2 "GDPR" means Regulation (EU) 2016/679. "LOPDGDD" means Spanish Organic Law 3/2018 on the Protection of Personal Data and Guarantee of Digital Rights. "UK GDPR" means the GDPR as it forms part of the law of the United Kingdom. "Swiss FADP" means the Swiss Federal Act on Data Protection of 25 September 2020.

2.3 "Data Protection Law" means the GDPR, the LOPDGDD and any other law on the protection of personal data that applies to the Processing of Player Data, including, where applicable, the UK GDPR, the Swiss FADP and the US state privacy laws referred to in Section 13.

2.4 "controller", "processor", "data subject", "personal data", "Processing" (and "Process") and "supervisory authority" have the meanings given in the GDPR.

2.5 "Player" means an end user whom the Operator allows to use the Service through the Operator's own website, app or community.

2.6 "Player Data" means the personal data listed in Annex I that we Process on the Operator's behalf in providing the Service.

2.7 "Sub-processor" means a processor we engage to Process Player Data on the Operator's behalf.

2.8 "Personal Data Breach" means a personal data breach, as defined in Article 4(12) GDPR, affecting Player Data that we or our Sub-processors Process.

2.9 "SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021, or any clauses that replace them.

2.10 "Restricted Transfer" means a transfer of Player Data to a country outside the EEA that is not covered by an adequacy decision under Article 45 GDPR (or the equivalent under the UK GDPR or the Swiss FADP), where Data Protection Law requires a transfer safeguard.

3.1 The Operator is the controller. The Operator decides whether and how it offers the Service to its Players, which Players can use it, which identifier and display name its server sends us, which wallet mode it uses, which features and settings are switched on (including live features, match streams and branding), what it tells its Players, and how long it keeps its Players' data. The Operator is the controller of Player Data.

3.2 When the Operator is itself a processor. If, where permitted under section 11.2 of the Terms, the Operator uses the Service to Process Player Data on behalf of another controller, the Operator confirms that the other controller has authorised the Operator's instructions to us, including our appointment and the appointment of our Sub-processors. We then act as the Operator's sub-processor and the Operator remains our only point of contact. The Operator is responsible for passing on to the other controller any notice or information we give under this DPA.

3.3 We are the processor. We Process Player Data only on the Operator's behalf and on its documented instructions, as described in Section 5, except as set out in Section 3.4.

3.4 Limited own-purpose Processing. The Operator acknowledges that we also Process Player Data as an independent controller, and not on the Operator's behalf, only to the extent strictly necessary, for the following purposes, which we decide ourselves:

(a) keeping the Service, our systems and other operators secure, and preventing, detecting and investigating fraud, abuse and attacks;(b) checking compliance with the Terms, including the prohibition on real-money gambling and on giving tokens monetary value, and acting on suspected breaches;(c) counting monthly active Players to apply the Operator's plan limits and fees;(d) producing aggregated or de-identified statistics about the use and performance of the Service, which do not identify any Player or Operator; and(e) complying with legal obligations that apply to us, responding to lawful requests from courts and authorities, and establishing, exercising or defending legal claims.

For this Processing we rely on our legitimate interests (keeping the Service secure, enforcing our contract with the Operator and billing the Operator) and, for (e), also on legal obligation. Section 4.8 of our Privacy Policy describes it, with its legal basis, its retention and how Players can exercise their rights with us. The Operator confirms that it may make Player Data available to us for these purposes, and it will inform its Players of them under Section 4.2.

We will not use Player Data for any other purpose of our own. In particular, we do not sell Player Data, use it for advertising or marketing, build profiles of Players, or combine it with data from our other products or services.

4.1 Lawfulness. The Operator is responsible for the lawfulness of the Processing of Player Data, including having a valid legal basis for it and for giving us the Player Data and the instructions it gives us.

4.2 Transparency. The Operator must give its Players, before they use the Service, the information required by Articles 13 and 14 GDPR (or the equivalent under other Data Protection Law). That information must:

(a) state that the sportsbook software is provided by a technology provider acting on the Operator's behalf (the Operator may, but need not, name The Sportsbook (thesportsbook.app) as that provider);(b) describe the Processing in Annex I, including the third-party content in Section 4.6 that the Operator's sportsbook uses; and(c) tell Players that the provider of the sportsbook software also Processes their data as a separate controller for the purposes in Section 3.4, and refer them to section 4.8 of our Privacy Policy at thesportsbook.app/legal/privacy, which explains that Processing and how to contact us.

We cannot inform Players ourselves because we do not know who they are, so we rely on the Operator to pass on this information. We publish a player notice template at thesportsbook.app/legal/player-notice that meets this Section 4.2 and that the Operator may adapt, but the Operator remains responsible for the content of the information it gives its Players.

4.3 Data minimisation. What the Operator must not send us. The Service is designed to work with a pseudonymous identifier. The Operator must:

(a) send as the Player identifier (user_ref) a pseudonymous value, such as a random or internal ID, and not an email address, phone number, legal name, government ID number, payment detail or any other directly identifying value;(b) send as the display name only a nickname or username the Player has chosen or agreed to, and not a value taken from a legal-name field in the Operator's records;(c) not send, or type into free-text fields (such as block reasons or wallet operation reasons), email addresses, phone numbers, legal names, precise location, any special category data (Article 9 GDPR), data about criminal convictions or offences (Article 10 GDPR), information about a Player's health, including any addiction or self-exclusion, government ID data or payment data; and(d) not send any other personal data that the Service does not need.

We have no duty to check the data the Operator sends. If the Operator breaches this Section 4.3, it does so at its own risk and Section 14.3 applies.

4.4 Age and minors. The Terms require that Players be at least 18 years old, or older where local law sets a higher age. The Operator must not allow children to use the Service and must not send us personal data about children. If the Operator becomes aware that it has sent us personal data of a child, it must tell us and delete or ask us to delete that data.

4.5 Lawful instructions. The Operator must make sure that its instructions comply with Data Protection Law and do not require us to act in breach of it.

4.6 Third-party content in the Player's browser. Only three features can make the Player's browser load content directly from a third party, which then receives the Player's IP address and browser information under its own terms: (a) images at an external address that the Operator enters in the console instead of uploading the file; and (b) the player of a streaming platform (such as Twitch, YouTube or Kick), which loads only after the Player clicks to watch and after a notice that the platform may set its own cookies; and (c) on pages of live matches, the match visualisation and, for some matches, video from the data provider, which the Player's browser receives directly from third-party live match data and video services, which also receive the match being viewed. The Operator is responsible for its choice under (a); (c) is part of the Service and not a choice of the Operator. All other content of the Embed, including fonts, is served from our own domains or through our Sub-processors.

4.7 The Operator's own systems and people. The Operator is responsible for:

(a) the security of its API keys, its servers and, where it uses the seamless wallet, its wallet endpoint and wallet secret;(b) the console users it invites and the access they have to Player Data;(c) any Player Data it exports, downloads or receives from the Service (including CSV exports, API responses and seamless wallet calls), which leaves our control once delivered; and(d) its own compliance with Data Protection Law as controller, including its records of processing, data protection impact assessments, breach notifications to authorities and Players, and responses to Players' requests.

5.1 Documented instructions. We Process Player Data only on the Operator's documented instructions, including with regard to Restricted Transfers, unless Union or Member State law to which we are subject requires otherwise. In that case we will inform the Operator of that legal requirement before Processing, unless that law prohibits it on important grounds of public interest.

5.2 What the instructions are. The Operator instructs us to Process Player Data to provide, secure, support and maintain the Service in accordance with the Terms, this DPA and the Operator's configuration and use of the Service, including through the console and the API. These are the Operator's complete instructions at the time this DPA takes effect. Any additional or different instruction must be given in writing and is subject to our agreement, including on any reasonable fees, if it goes beyond the functionality of the Service.

5.3 Infringing instructions. We will inform the Operator immediately if, in our opinion, an instruction infringes Data Protection Law. We may suspend carrying out that instruction until the Operator confirms or changes it. We have no obligation to carry out a legal review of the Operator's instructions.

5.4 Confidentiality. We make sure that everyone we authorise to Process Player Data is bound by an appropriate duty of confidentiality, by contract or by law, and has access only to the extent necessary for their role.

5.5 Security. We implement and maintain the technical and organisational measures described in Annex II, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of the Processing, as well as the risks to Players. We may update those measures from time to time, provided that the update does not materially reduce the overall level of protection of Player Data. The Operator has reviewed Annex II and agrees that it provides a level of security appropriate to the risk, taking into account that the Service is designed to receive only pseudonymous Player Data.

5.6 Records. We keep a record of the processing activities we carry out on behalf of the Operator, as required by Article 30(2) GDPR.

5.7 Assistance. Taking into account the nature of the Processing and the information available to us, we will give the Operator reasonable assistance with:

(a) responding to requests from Players to exercise their rights (Section 9);(b) its obligations under Articles 32 to 36 GDPR (security, breach notification, data protection impact assessments and prior consultation), mainly by making available this DPA, Annex II and the information in Annex I.

We may charge a reasonable fee for assistance that goes beyond the features of the Service and the information we make available generally, unless the assistance is needed because of our own breach of this DPA.

6.1 General authorisation. The Operator gives us general written authorisation to engage Sub-processors. The Sub-processors in use on the date the Operator accepts this DPA are those listed in our sub-processor list at thesportsbook.app/legal/subprocessors, which the Operator authorises.

6.2 Obligations flowed down. When we engage a Sub-processor, we do so by a written contract that imposes on it data protection obligations that give Player Data at least the same level of protection as this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures. We remain responsible to the Operator for the performance of our Sub-processors' obligations, in accordance with Article 28(4) GDPR and subject to Section 14.

6.3 Changes. We will give the Operator at least fourteen (14) days' notice before a new Sub-processor starts Processing Player Data, by updating the sub-processor list and notifying the email address of the Operator's owner account or showing a notice in the console. If we must replace a Sub-processor urgently to keep the Service secure or available, we will notify the Operator before the new Sub-processor starts Processing Player Data, even if the notice is shorter than fourteen (14) days, and the Operator may object within fourteen (14) days after the notice under Section 6.4. If the objection is upheld, we will stop using that Sub-processor for the Operator's Player Data or Section 6.4 applies.

6.4 Objection. The Operator may object to a new Sub-processor on reasonable grounds relating to data protection, in writing to support@thesportsbook.app within the notice period. We will then discuss the objection in good faith and may propose a reasonable alternative. If we cannot resolve the objection within thirty (30) days, the Operator may terminate the affected part of the Service with effect from the date the new Sub-processor starts Processing Player Data. In that case we will refund pro rata the Fees the Operator has prepaid for the period after termination. This is the Operator's sole remedy for its objection. If the Operator does not object within the notice period, the new Sub-processor is deemed authorised.

7.1 Where we Process. We and our Sub-processors may Process Player Data in the countries listed in the sub-processor list, which include the United States.

7.2 Transfer safeguards. We will not make a Restricted Transfer of Player Data, and will not allow a Sub-processor to make one, unless it is covered by an appropriate safeguard under Chapter V GDPR. For our Sub-processors in the United States this is, where the Sub-processor is certified, the EU-U.S. Data Privacy Framework (and its UK Extension and the Swiss-U.S. Data Privacy Framework) and, in addition or where it is not certified, the SCCs incorporated into our contract with that Sub-processor. If a transfer safeguard stops being valid, we will rely on an alternative safeguard or take other reasonable measures to bring the transfer into line with Data Protection Law.

7.3 Transfers between the Operator and us. To the extent that the Processing under this DPA involves a Restricted Transfer between the Operator and us, the SCCs are incorporated into this DPA by reference, completed as set out in Annex IV, as follows:

(a) Module Two (controller to processor) applies where the Operator, as controller, is the data exporter and we are the data importer;(b) Module Three (processor to processor) applies where the Operator acts as a processor for another controller (Section 3.2), is the data exporter and we are the data importer;(c) Module Four (processor to controller) applies where we, as processor subject to the GDPR, are the data exporter and the Operator, established in a third country, is the data importer, including when the Operator accesses Player Data through the console or the API, or receives seamless wallet calls.

By accepting this DPA each party is deemed to have signed the SCCs, including their Annexes as completed by Annexes I, II and IV of this DPA.

7.4 UK and Switzerland. Where the UK GDPR or the Swiss FADP applies to a transfer covered by Section 7.3, the SCCs apply with the adaptations set out in Annex IV.

7.5 Precedence. If the SCCs conflict with this DPA or the Terms, the SCCs prevail to the extent of the conflict.

7.6 Transfer impact. We have assessed, and will keep under review, the laws and practices of the destination countries of our transfers, taking into account the pseudonymous nature of Player Data and the safeguards in place. We will give the Operator the information it reasonably needs for its own transfer impact assessment.

8.1 Notification. We will notify the Operator without undue delay, and where feasible within forty-eight (48) hours, after becoming aware of a Personal Data Breach affecting Player Data. We will send the notice to the email address of the Operator's owner account(s) and may also show it in the console.

8.2 Content. The notice will describe, to the extent then known: the nature of the breach, including where possible the categories and approximate number of Players and records concerned; the likely consequences; the measures taken or proposed to address the breach and mitigate its effects; and a contact point for more information. Where we cannot give all the information at once, we will give it in phases without undue further delay.

8.3 Response. We will take reasonable steps to contain, investigate and remedy the breach, and give the Operator reasonable cooperation so that it can meet its own obligations to notify supervisory authorities and Players. The Operator decides whether to notify authorities and Players, unless the law requires us to do so ourselves.

8.4 No admission. Our notification of a Personal Data Breach is not an admission of fault or liability.

8.5 Events outside this Section. Unsuccessful attempts or activities that do not compromise the security of Player Data, such as pings, port scans, failed sign-in attempts and blocked denial-of-service attacks, are not Personal Data Breaches. Incidents in the Operator's own systems, or caused by the Operator's API keys, wallet secret or console users, are the Operator's responsibility, although we will cooperate reasonably if they affect the Service.

9.1 Requests we receive. We cannot identify Players except through the identifier the Operator sends us. If we receive a request from a Player to exercise their rights:

(a) to the extent it concerns the Processing we carry out on the Operator's behalf, we will not respond to it ourselves (other than to tell the Player to contact the Operator, where we can identify the Operator) and will forward it to the Operator without undue delay; and(b) to the extent it concerns our own-purpose Processing under Section 3.4, we will answer it ourselves as controller, and may ask the Operator for the information we need to find the Player's data.

9.2 How we help. The Service lets the Operator view a Player's bets, balance and wallet operations, and export bet records, through the console and the API. Where the Operator cannot meet a Player's request with those features, we will, on the Operator's written instructions to support@thesportsbook.app:

(a) provide a copy of the Player Data we hold about an identified Player in a structured, commonly used and machine-readable format; and(b) erase that Player's identifier and display name and every value we derived from them (including internal usernames and technical email addresses and any occurrence in our audit logs and reason fields), replacing them with a random value, while keeping the related bet and balance records linked only to that random value for the Operator's reconciliation, unless the Operator instructs us to delete those records as well. The Operator acknowledges that records kept this way may still relate to the Player if the Operator keeps its own copies of the identifier,

within a reasonable time, which will normally not exceed fifteen (15) business days from a complete request.

10.1 If we receive a legally binding request from a public authority for disclosure of Player Data, we will, unless the law prohibits it: (a) notify the Operator promptly and, where possible, before disclosing anything; (b) review the request for lawfulness and challenge it where, after careful assessment, we conclude that there are reasonable grounds to consider it unlawful; and (c) disclose only the minimum Player Data needed to comply.

10.2 Where the SCCs apply, Clause 15 of the SCCs governs requests from public authorities of a third country.

10.3 Nothing in this DPA prevents us from cooperating with a competent authority in relation to our own obligations, including where the authority investigates a suspected use of the Service for real-money gambling. Where the law allows it, we will tell the Operator.

11.1 During the Terms. We keep Player Data for as long as the Operator's sportsbook exists in the Service, unless the Operator instructs us to delete it earlier under Section 9.2 or by using a deletion feature of the Service.

11.2 Export at the end. On a written request made before, or within thirty (30) days after, the termination of the Terms or the closure of the Operator's sportsbook, we will make the Player Data of that sportsbook available to the Operator in a structured, commonly used and machine-readable format (for example CSV or JSON).

11.3 Deletion. Within ninety (90) days after termination of the Terms or closure of the sportsbook, we will delete the Player Data of that sportsbook or irreversibly de-identify it so that it is no longer personal data, except that:

(a) copies in our backups are deleted in the normal backup cycle, which currently keeps daily backups for thirty (30) days, and are not restored or used in the meantime except to recover from a disaster. If we restore a backup, we will take reasonable steps to delete again the Player Data that had been deleted before the restore;(b) in accordance with Article 33.4 LOPDGDD (and equivalent provisions), we may keep Player Data blocked, meaning isolated and protected against any Processing, for as long as liabilities could arise from our relationship with the Operator, only to make it available to courts, the public prosecutor or competent authorities, and we will destroy it at the end of the applicable limitation period; and(c) we may keep Player Data where Union or Member State law requires us to store it, for as long as that law requires, while continuing to protect it under this DPA.

11.4 Certification. On written request, we will confirm in writing that deletion has taken place.

12.1 Information. We will make available to the Operator, on written request, the information reasonably necessary to demonstrate our compliance with Article 28 GDPR and this DPA. This DPA, its Annexes and the sub-processor list are the first source of that information. We do not represent that the Service holds any security certification.

12.2 Audits. Where the information under Section 12.1 is not enough to demonstrate compliance, or where a supervisory authority requires it, we will allow and contribute to audits, including inspections, by the Operator or by an independent auditor appointed by the Operator, on the following terms:

(a) the Operator gives at least thirty (30) days' written notice with a proposed scope, except where a supervisory authority requires a shorter period or after a Personal Data Breach affecting the Operator's Player Data;(b) audits take place no more than once in any twelve (12) months, except where required by a supervisory authority or after such a Personal Data Breach;(c) the audit is carried out first by written questions and document review, and on site only if that is not enough, during normal business hours and without unreasonable disruption;(d) the auditor is bound by confidentiality obligations and is not a competitor of ours;(e) the audit does not give access to data of other operators, to our Sub-processors' facilities (for which we will provide the Sub-processor's own reports or DPA terms, where available), or to information protected by law or by third-party confidentiality obligations; and(f) the Operator bears its own costs and pays our reasonable costs of supporting the audit, unless the audit reveals a material breach of this DPA by us.

12.3 SCCs. Where the SCCs apply, this Section 12 describes how audits under Clause 8.9 of the SCCs are carried out, and does not limit the rights the SCCs give the Operator or a supervisory authority.

13.1 US state laws. To the extent that the California Consumer Privacy Act as amended by the California Privacy Rights Act, or another US state consumer privacy law, applies to Player Data, we act as the Operator's "service provider", "contractor" or "processor" (as those laws define them), and we:

(a) will not sell or share (as those terms are defined in those laws) Player Data;(b) will not retain, use or disclose Player Data for any purpose other than the business purposes set out in this DPA and the Terms, or outside the direct business relationship between the Operator and us, except as those laws permit;(c) will not combine Player Data with personal information we receive from others or collect ourselves, except as those laws permit;(d) will comply with the obligations those laws impose on us and provide the same level of privacy protection they require;(e) will notify the Operator if we determine that we can no longer meet our obligations under those laws; and(f) allow the Operator to take reasonable and appropriate steps to stop and remedy unauthorised use of Player Data, in accordance with Sections 9, 11 and 12.

13.2 Other laws. Where another Data Protection Law applies to Player Data, this DPA applies to it with the changes needed to meet that law's requirements for contracts between controllers and processors. If that law requires terms that this DPA does not contain, the Operator must tell us and the parties will agree them in good faith.

14.1 Terms apply. Each party's liability arising out of or in connection with this DPA, and with the SCCs as between the parties to the extent the law allows, is subject to the limitations and exclusions of liability in the Terms. Those limitations never apply to liability that cannot be limited or excluded by law, including liability for wilful misconduct or gross negligence.

14.2 Players and authorities. Nothing in this DPA limits either party's liability towards Players under Article 82 GDPR, or the rights of Players as third-party beneficiaries under the SCCs, or either party's responsibility towards supervisory authorities. Where both parties are liable to a Player for the same damage, each party may recover from the other the part of the compensation that corresponds to the other party's responsibility for the damage, as provided in Article 82(5) GDPR. Nothing in the Terms, including the provisions on third-party beneficiaries and on what the Operator may tell Players, limits the rights that Players have as data subjects under this DPA, the SCCs or Data Protection Law.

14.3 The Operator's responsibility. The Operator will indemnify us against claims by Players, supervisory authorities or other third parties, including reasonable legal costs and any fines imposed on us to the extent allowed by law, to the extent they arise from: (a) the Operator's lack of a legal basis, or failure to inform its Players, for the Processing it instructs; (b) the Operator's instructions; (c) personal data the Operator sends in breach of Section 4.3 or 4.4; or (d) images the Operator loads from an external address under Section 4.6(a). This indemnity does not apply to the extent the claim results from our own breach of this DPA or of Data Protection Law.

15.1 Term. This DPA takes effect when the Operator accepts the Terms and continues for as long as we Process Player Data on the Operator's behalf, including after the Terms end until deletion under Section 11.

15.2 Order of precedence. For matters relating to the Processing of Player Data, the following order applies in case of conflict: (1) the SCCs, where they apply; (2) this DPA; (3) the Terms.

15.3 Changes. We may change this DPA to reflect changes in Data Protection Law, guidance or decisions of supervisory authorities or courts, new standard contractual clauses, or changes in the Service, provided that the change does not materially reduce the protection of Player Data. We will give at least thirty (30) days' notice of a material change, except where a shorter period is required by law or by a supervisory authority. If the Operator objects to a material change, it may terminate the Terms before the change takes effect, and we will refund pro rata the Fees it has prepaid for the period after termination.

15.4 Severability. If any provision of this DPA is found invalid or unenforceable, the rest of the DPA remains in effect, and the invalid provision is replaced by a valid provision that comes as close as possible to its purpose.

15.5 Governing law and courts. This DPA is governed by the laws of Spain, and the courts of Spain have exclusive jurisdiction, without prejudice to Clauses 17 and 18 of the SCCs where they apply, and to any mandatory rights of Players or powers of supervisory authorities.

15.6 Contact. Questions about this DPA, notices, objections and instructions go to support@thesportsbook.app. We have not appointed a data protection officer because the law does not require us to.

A. List of parties

Data exporter / controller (Modules Two and Three: exporter; Module Four: importer): the Operator, identified by the legal name, country and address it gives in its billing profile (which the Operator must complete when it accepts this DPA or, at the latest, before its first Paid Plan invoice) and by its console account. Contact person: the owner of the Operator's console account, at the email address registered in it. Activities relevant to the Processing: offering a play-for-fun sportsbook to its Players through the Service. Role: controller (or processor on behalf of another controller, see Section 3.2). Signature and date: acceptance of this DPA in the console, recorded with its date.

Data importer / processor (Modules Two and Three: importer; Module Four: exporter): The Sportsbook (thesportsbook.app). Contact: support@thesportsbook.app. Activities relevant to the Processing: providing the sportsbook software and hosted service described in the Terms. Role: processor (or sub-processor). Signature and date: acceptance of this DPA by the Operator.

B. Description of the Processing

Categories of data subjects
Players: people whom the Operator allows to use the sportsbook through its own website, app or community. Under the Terms they must be adults; we do not verify their age.

Categories of personal data

We do not collect from Players: email addresses, legal names (unless a Player chooses their own name as a nickname), dates of birth, postal addresses, government ID, payment data, precise location or device fingerprints.

Sensitive data
None. The Operator must not send special category data or data about criminal convictions (Section 4.3).

Frequency of the transfer / Processing
Continuous, for as long as the Operator uses the Service.

Nature of the Processing
Receiving, storing, organising, using, displaying and transmitting Player Data to run the sportsbook: opening Player sessions on the Operator's request; accepting, pricing, settling and re-settling bets; keeping managed token balances or sending token movements to the Operator's seamless wallet endpoint; showing Player Data to the Operator in the console and through the API; applying the Operator's limits and blocks; hosting, backup, logging and security; support; deletion and de-identification.

Purpose of the Processing
Providing, securing, supporting and maintaining the Service for the Operator under the Terms, and the purposes set out in Section 3.4 to the extent described there.

Retention

• While the Operator's sportsbook exists: kept until the Operator asks for deletion (Section 9.2) or the Terms end (Section 11).
• Launch tokens: deleted about one day after they expire. Records used to stop duplicate bets: deleted within about 48 hours.
• In-memory rate-limit data: kept only for the time window of the limit.
• Hosting request and application logs: up to three (3) days for website logs and up to thirty (30) days for API and application logs.
• Backups: daily, each kept thirty (30) days and then deleted.
• After the Terms end: as set out in Section 11.

Sub-processors
Subject matter, nature and duration as described in the sub-processor list referred to in Annex III.

C. Competent supervisory authority

• Where the Operator is established in an EEA Member State, the supervisory authority of that Member State (for Modules Two and Three).
• Where the Operator is not established in the EEA but is subject to the GDPR under Article 3(2) and has appointed a representative, the supervisory authority of the Member State where its representative is established.
• Where the Operator is not established in the EEA and has not appointed a representative: the supervisory authority of the Member State where the Players whose data is transferred are located.
• For Module Four and for our own obligations as processor: the Agencia Española de Protección de Datos (AEPD).

This Annex describes the measures we apply to Player Data. It is written to be accurate, not to promise more than we do.

1. Design and data minimisation

• The Service is designed to work with a pseudonymous Player identifier chosen by the Operator. We do not ask Players for contact details, identity documents, payment data or location.
• Players have no password with us. Only the Operator's server, using its secret API key, can open a Player session.
• We do not run analytics, advertising or tracking scripts in the embedded sportsbook.

2. Encryption

• All traffic to our public services is encrypted in transit with TLS. Our domain is on the browser HSTS preload list, so browsers only connect to it over HTTPS.
• Connections between our application and our database run inside our hosting provider's private network and are encrypted with TLS.
• Backups are stored with a storage provider that encrypts stored objects at rest.
• Operator API keys are stored only as one-way hashes and shown in full only once, when created. Calls we send to the Operator's seamless wallet endpoint are signed with HMAC-SHA256.

3. Access control and authorisation

• Each Operator's data is separated logically by a tenant identifier that is taken only from the authenticated token or API key, never from the request body. We test tenant isolation with an access-control test matrix.
• Tokens are typed by audience (player, operator console, platform staff and launch token) and cannot be used for another audience. Player sessions expire after 12 hours and console sessions after 8 hours. Sessions can be revoked centrally.
• Console access is role-based (owner, admin, viewer), and every change in the console is recorded in an audit log with the account and IP address.
• Access by our staff to Player Data is limited to authorised personnel who need it to operate, support and secure the Service. Staff accounts are individual, and every write action by staff is recorded in an audit log with the reason where required.
• Passwords for console and staff accounts are stored with bcrypt (cost factor 12) and must meet a minimum length and a common-password check. Sign-up codes, password-reset and invitation tokens are random, single-use, time-limited and stored only as hashes.

4. Protection against abuse and attacks

• Rate limits apply per API key, per Player, per IP address and per account, together with sign-in and sign-up limits.
• Requests from browsers are restricted by origin allow-lists (CORS) for each surface.
• Uploaded image files are checked by their content type, limited in size, and SVG files are sanitised on the server.
• Outbound calls to Operator wallet endpoints are guarded against server-side request forgery.
• Seamless wallet operations are idempotent and retried from a durable queue, with failures visible to the Operator for reconciliation.

5. Availability and recovery

• A full backup of the database is taken daily and stored off-site with a different provider from our hosting provider, and each backup is kept for 30 days. Each backup is checked for completeness when it is created, and we have tested restoring from a backup.
• Deployments use health checks so that a new version only receives traffic once it is running.
• We can pause betting for one sportsbook or the whole platform (maintenance mode) while keeping data intact.

6. Infrastructure and physical security

• We do not operate our own data centres. The Service runs on the infrastructure of the Sub-processors listed in Annex III, which are responsible for the physical and environmental security of their facilities under their own security programmes and data processing terms.
• The Service shares hosting infrastructure with other products operated by us. Those products are separate from the Service and are not covered by the Terms or this DPA. Player Data is kept logically separate by tenant, and those other products do not use Player Data.

7. Logging and monitoring

• Application logs and hosting request logs are kept for a limited time (see Annex I, "Retention").
• Security-relevant actions of Operators and of our staff are recorded in audit logs.

8. Retention and deletion

• Short-lived records (launch tokens, duplicate-bet protection records, pending sign-ups, password-reset tokens, revoked sessions) are deleted automatically by scheduled jobs.
• Deletion and de-identification at the Operator's request and at the end of the Terms follow Sections 9 and 11 of the DPA.

9. Organisation

• Staff with access to Player Data are bound by confidentiality.
• We keep a record of processing activities as processor and follow a documented procedure for handling security incidents and Personal Data Breaches.
• We review these measures when the Service changes significantly and at least once a year.
• We choose Sub-processors that offer sufficient guarantees and bind them by written data processing terms.

10. Assistance to the Operator

• For Players' rights: the console and API show each Player's bets, balance and wallet movements, and bet records can be exported. Other requests are handled under Section 9 of the DPA.
• For Sub-processors: the same measures, as applicable, are imposed by the contracts with each Sub-processor (Section 6.2 of the DPA).

The Sub-processors authorised under Section 6.1, with their purpose, location, the Player Data they Process and the transfer safeguard, are listed in our sub-processor list at thesportsbook.app/legal/subprocessors, as updated under Section 6.3. The version of that list in force on the date the Operator accepts the Terms forms part of this Annex.

Where the SCCs apply under Section 7.3:

1. Clause 7 (docking clause): applies.
2. Clause 9(a) (sub-processors): Option 2 (general written authorisation) applies. We inform the Operator in writing of any intended addition or replacement of a Sub-processor at least 14 days in advance, as set out in Section 6.3 of the DPA. In the urgent cases described in Section 6.3 the notice may be shorter, but it is always given before the new Sub-processor Processes Player Data, and the Operator keeps a 14-day period to object. Section 6.4 of the DPA describes the objection procedure. (Modules Two and Three.)
3. Clause 11(a) (redress): the optional language does not apply.
4. Clause 13 (supervision): the competent supervisory authority is set out in Annex I.C. (Modules Two and Three.)
5. Clause 17 (governing law): Modules Two and Three: Option 1, the law of Spain. Module Four: the law of Spain.
6. Clause 18 (choice of forum and jurisdiction): Modules Two and Three: the courts of Spain. Module Four: the courts of Spain.
7. Annex I of the SCCs: completed by Annex I of the DPA.
8. Annex II of the SCCs: completed by Annex II of the DPA.
9. Annex III of the SCCs: completed by Annex III of the DPA.
10. Clause 8.9 (audits) and Clause 8.5 (deletion): carried out as described in Sections 11 and 12 of the DPA, to the extent consistent with the SCCs.
11. United Kingdom: for transfers subject to the UK GDPR, the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner (version B1.0, in force 21 March 2022, or any version that replaces it) applies. Table 1 is completed with the parties' details in Annex I; Table 2 with the modules and options above; Table 3 with Annexes I to III of the DPA; in Table 4, either party may end the Addendum as set out in its Section 19.
12. Switzerland: for transfers subject to the Swiss FADP, the SCCs apply with these changes: references to the GDPR are read as references to the Swiss FADP where the transfer is subject to it; the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority for those transfers; the term "Member State" does not prevent data subjects in Switzerland from bringing claims in their place of habitual residence.