Effective date: 23 July 2026 · Version: 2026-07-23-provider-v3
This Provider Service Offer ("Offer") constitutes a binding public offer by Xyro Gaming Limitada, cédula jurídica 3-102-930374, a company incorporated under the laws of the Republic of Costa Rica, with registered address at Puntarenas, Garabito, Jacó, Costado Este de la Municipalidad de Garabito (hereinafter "The Aggregator", "we", "us"), to any legal entity or authorised representative thereof ("Provider", "you") that registers for access to the Aggregator Service as a game content provider. By completing the Provider registration process and confirming acceptance of this Offer, the Provider enters into a binding agreement ("Agreement") with The Aggregator on the terms set forth below.
The Aggregator operates software-as-a-service (SaaS) computational infrastructure that purchases API-processing capacity from Providers and resells metered API-processing capacity on a pre-paid basis to online gaming operators that contract directly with The Aggregator and to Platform Partners that supply their own casino-management solutions to downstream online gaming operators. The Aggregator is the Provider's customer for Metered Successful API Calls and is independently the service provider to each Operator under either a separate Operator Service Offer or a separate Platform Partner Service Offer. For traffic transmitted under a Platform ID, the Platform Partner replaces the direct operator as The Aggregator's Operator-side contractual counterparty; the Platform Partner's downstream Platform Operators do not accept a Service Offer from The Aggregator. The Aggregator does not independently initiate a Real-Money Game Session or Game Round, determine a game outcome, accept a wager, maintain a Player wallet, or receive, hold, transmit, or settle Player funds. As at the Effective Date, The Aggregator does not hold a gaming licence and, based on the current design and operation of the Aggregator Service and the activities it presently performs, does not consider itself to operate or conduct gaming. Regulatory classification depends on the applicable jurisdiction and the activities actually performed; The Aggregator does not represent or warrant that no gaming-related licence, registration, approval, or other authorisation can ever be required. The Aggregator's intended role is that of a B2B technology provider and reseller of metered API-processing capacity, not a legacy GGR-share aggregator.
Nothing in this Agreement creates a joint venture, partnership, agency, employment, or fiduciary relationship between The Aggregator and the Provider, or between the Provider and any Operator. The limited technical rights and permissions in Section 7 do not transfer ownership of Provider Content. There is no separate game royalty, revenue share, GGR share, or content-licensing payment between the Provider and an Operator for access through the Aggregator Service; the per-Metered-Successful-API-Call payment under Section 8 is the Provider's contractual consideration from The Aggregator for that use.
---
bet transaction described in Schedule A gives rise to one Metered Successful API Call; the other API Calls relating to that Round are not separately payable.bet transaction is commercially payable under Schedule A.The Provider undertakes that, for every API Call that The Aggregator routes to the Provider RGS on an authenticated request attributable to an Operator, and for every transaction or result communication the Provider RGS sends through the Aggregator Service, the Provider shall:
The Provider further undertakes that responses (i) reflect the Provider's own authoritative game state, (ii) do not depend on data, signals, or instructions originating outside the Provider's own systems other than those passed through the API Call payload, and (iii) include the integrity, correlation, and metering fields specified in the API specification.
The Provider is duly incorporated and validly existing, and the person completing registration has full authority to bind the Provider. All information supplied during registration is accurate, complete, and not misleading.
The Provider is the sole and exclusive owner, or duly authorised licensee, of all Intellectual Property Rights in the Provider Content, including all rights necessary to grant the limited technical right in Section 7.2. All Provider Content has been independently certified by an accredited testing laboratory (e.g. GLI, BMM, iTech Labs, eCOGRA, or equivalent) to the extent required by the jurisdictions in which Operators offer it to Players. The Provider warrants the accuracy of the RTP, mathematical model, payout tables, RNG implementation, and certification status of each item of Provider Content. The Provider shall upload current certification reports and material technical specifications to the Provider Workspace and update them promptly on any material change.
Where applicable, the Provider holds all B2B supplier licences, permits, and regulatory approvals required to make the Provider Content available in the jurisdictions where Operators offer it. The Provider shall notify The Aggregator within five (5) Working Days of any suspension, revocation, restriction, or material change in its regulatory status or in the certification status of any Provider Content.
The Provider maintains and enforces AML/CTF policies and procedures that comply with applicable laws. Neither the Provider nor any of its beneficial owners, directors, or officers is listed on any sanctions list maintained by the UN, EU, US (OFAC), UK, or any other applicable sanctions authority. The Provider shall cooperate fully with The Aggregator in any AML/CTF investigation or regulatory inquiry.
The Provider shall not engage in any activity that could damage the reputation, security, or operational integrity of the Aggregator Service, The Aggregator, or any Operator.
The Aggregator may request, at any time, evidence of the Provider's ongoing compliance, including current certification reports, B2B supplier licences, AML/CTF policy documentation, information-security summaries, and insurance evidence. The Provider shall respond within ten (10) Working Days. The Aggregator may, on reasonable notice and at its own expense, conduct or commission a third-party audit to the extent it relates to the Provider's use of the Aggregator Service.
Providers are strongly recommended (but not contractually required) to maintain professional liability (E&O), cyber liability, and product/IP-infringement cover adequate to the scale of the Provider's content output. The Aggregator may request evidence of cover in connection with high-volume Provider Content or specific incident response.
Each party warrants compliance with applicable anti-corruption and anti-bribery laws, including the UK Bribery Act 2010 and the US Foreign Corrupt Practices Act.
The Provider shall, on a continuous basis and at its own expense:
Access is granted in stages: sandbox, staging, and production. The Aggregator determines timing and conditions. Sandbox and staging API Calls are non-billable to Operators and non-payable to the Provider.
The Provider shall upload to the Provider Workspace, and keep current, copies of all valid testing-laboratory certificates and material technical specifications for each item of Provider Content. The Aggregator stores such records for the Provider's and Operators' regulatory-evidence purposes; The Aggregator does not validate, audit, or warrant the substance of such records.
The Provider may configure availability rules that suspend specific Provider Content for specific Operators or geographies. Ordinary catalogue changes take effect as soon as reasonably practicable and within twenty-four (24) hours. Emergency or legally required restrictions take effect under Section 11.2 and Schedule C. The affected Provider Content will appear as unavailable in the Operator's catalogue; The Aggregator may withhold confidential reasoning from the Operator but may disclose that the restriction originated with the Provider where required by law, a competent authority, the Operator Service Offer, or fair incident handling.
The Aggregator reserves sole discretion to approve, delay, condition, or deny Provider access where (a) certification appears expired, withdrawn, or jurisdictionally inadequate, (b) the content carries unmitigated regulatory risk, (c) a credible third-party IP claim has been raised, or (d) the Provider RGS chronically fails to meet Section 2.3 and Schedule B (Section 11.5 also applies).
All Intellectual Property Rights in Provider Content remain the sole and exclusive property of the Provider or its upstream licensors. Except for the limited technical rights and Operator permission in Section 7.2, nothing grants The Aggregator, an Operator, or a Platform Operator a standalone content or distribution licence, or any right to modify, decompile, reverse-engineer, create derivative works of, or exploit Provider Content outside the Aggregator Service and Provider RGS.
The Provider grants The Aggregator a limited, non-exclusive, worldwide, royalty-free, revocable right, for the term, to: (a) receive, decode, route, cache to the extent technically necessary, authenticate, and transmit Provider Content API payloads; (b) reproduce Provider Content thumbnails, names, and metadata strictly for listing in the Operator dashboard and, subject to Section 7.4, on the "Supported Providers" page; (c) store certification records and integration artefacts uploaded by the Provider; (d) generate, retain, and audit metering-ledger entries describing API Calls; and (e) permit provisioned Operators to access, display, and use Provider-hosted Provider Content solely through the Aggregator Service and Provider RGS for Player-facing gaming in territories the Provider has made available. Where the Operator is a Platform Partner, paragraph (e) includes the minimum technical permission necessary for that Platform Partner to make Provider-hosted Provider Content accessible through its tested integration to its Platform Operators under assigned Operator IDs, subject to Provider availability rules and the Platform Partner remaining responsible to The Aggregator for all such access. The Aggregator may sublicense the minimum technical rights necessary to its listed infrastructure sub-processors and pass through the permission in paragraph (e) to provisioned Operators, but may not grant any broader right. No Platform Operator receives a direct licence or enforcement right from the Provider under this Agreement.
These rights are strictly limited to operation of the Aggregator Service and the authorised Operator access described above. The Aggregator shall not train any machine-learning model on Provider Content, use Provider Content for a product unrelated to the Aggregator Service, or use Provider Content in marketing or sales material beyond the consent granted under Section 7.4.
All Intellectual Property Rights in the software and technology comprising the Aggregator Service remain the exclusive property of The Aggregator. The Provider receives a limited, non-exclusive, non-transferable, revocable licence to use that software, technology, and related documentation solely for integration purposes.
Each party grants the other a limited, non-exclusive, royalty-free right to use the other's name and logo to identify the relationship. Marketing campaigns, press releases, and pitch decks require prior written consent (not unreasonably withheld).
The Provider warrants that the Provider Content does not infringe any third-party right, and shall defend, indemnify, and hold The Aggregator harmless per Section 10. The Aggregator may, on receipt of a credible third-party infringement notice, suspend delivery in accordance with Schedule C clause C.11.
For each Metered Successful API Call originating from the Provider RGS, routed through the Aggregator Service to a direct Operator's designated wallet or callback endpoint or, for Platform traffic, to the applicable Tested Acceptance Point, accepted there, and recorded in the metering ledger in accordance with Schedule A, The Aggregator shall pay the Provider the rate in clause 8.2.
An "API Call" is one discrete request-and-response or callback-and-acknowledgement transaction routed through the Aggregator Service. A Game Round may involve several API Calls. Only the single eligible production bet or equivalent wager/debit transaction that satisfies every condition in Schedule A clause A.2 is a Metered Successful API Call. Session launch, balance, result, win, refund, rollback, acknowledgement, retry, and other technical communications relating to the Round are not separately payable.
For the avoidance of doubt, the Metered Successful API Call is the contractual metering unit evidenced by one successfully accepted eligible transaction uniquely mapped to one billable Round. Absent a signed provider-specific addendum expressly defining a multi-wager Round, no Round may produce more than one Metered Successful API Call. Payment is compensation for the Provider RGS processing and related technical permission under this Agreement, not a share of any gaming revenue, wager value, bet amount, win, GGR, NGR, or other Money-Path metric.
win, payout, result, refund, rollback, and void communications; free or promotional transactions identified as non-billable; health checks; retries within the documented retry window; idempotent duplicates; monitoring traffic; and calls rejected before reaching the intended endpoint are non-payable (Schedule A clause A.3).The Aggregator Service is designed and operated as SaaS API-routing and metering infrastructure, and The Aggregator acts as a reseller of metered API-processing capacity. The Aggregator does not independently initiate Game Sessions or Rounds, determine game outcomes, accept wagers, maintain Player wallets, or accept, hold, route, escrow, transmit, or settle Player or Operator gaming funds. Its functions for the Provider are limited to onboarding and compliance coordination, API routing and observability, metering, Operator pre-payment administration, and settlement of the Provider on a per-Metered-Successful-API-Call basis. Fees are independent of wager value, Player win or loss, GGR, NGR, revenue share, or any other Money-Path metric.
Except as expressly stated in this clause, this Agreement is solely for the benefit of its parties. Each Affected Operator, including a Platform Partner for affected traffic under its Platform ID, is an intended third-party beneficiary solely of the Provider's indemnity obligations under Section 10.1 and Schedule C clause C.10(a) and may enforce those obligations directly. An Affected Operator takes that limited benefit subject to the same notice, defence-control, causation, mitigation, no-double-recovery, limitation, governing-law, and dispute-resolution provisions that would apply if The Aggregator enforced the obligation. No Platform Operator, Player, end user, regulatory authority, or other third party receives any right, and no broader contractual privity between the Provider and an Operator is created. Any Platform Operator loss or claim must be addressed through its Platform Partner under their separate relationship.
The Provider is, correspondingly, an intended third-party beneficiary solely of an Operator's indemnity for Operator-attributable Incidents to the extent expressly granted in the applicable Operator Service Offer or Platform Partner Service Offer. The Aggregator shall, following a substantiated claim and subject to confidentiality and applicable law, provide the affected parties with the identity and relevant contractual extract reasonably necessary to exercise the limited beneficiary right. The Aggregator does not guarantee an Operator's performance or solvency and is not a surety for an Operator's indemnity.
An Affected Operator accepts the limited benefit by giving written claim notice to The Aggregator at legal@aggregator.gg and to the Provider at the notice address The Aggregator supplies for that claim. By enforcing the benefit, the Affected Operator accepts Section 16 and may commence or be joined to an arbitration solely for the covered claim. Before such acceptance, the parties may amend or revoke the benefit; after acceptance, they may not revoke an accrued claim without the Affected Operator's consent.
The parties acknowledge that regulatory classification depends on the applicable jurisdiction and the activities actually performed. The Provider shall not make a materially false or misleading statement to an authority concerning The Aggregator's activities. The Provider shall indemnify The Aggregator under Section 10 only to the extent a regulatory claim, investigation, requirement, or classification is directly caused by (a) the Provider's material breach of this Agreement or applicable law; (b) unlawful, unlicensed, uncertified, or non-compliant Provider Activities; or (c) a materially false or misleading statement made by or on behalf of the Provider concerning The Aggregator. The Provider has no liability under this clause to the extent the matter results from The Aggregator's own services, conduct, documentation, representations, or failure to obtain an authorisation legally required for The Aggregator's own activities.
The Provider shall indemnify, defend, and hold harmless The Aggregator and each Affected Operator from and against third-party claims and documented direct losses, damages, liabilities, regulatory fines to the extent legally indemnifiable, and reasonable external legal and remediation costs, in each case to the extent directly caused by: (a) the Provider's material breach of this Agreement, including Section 2.3, provided that an operational target miss alone is not a breach or indemnity trigger; (b) a claim that Provider Content infringes a third-party Intellectual Property Right; (c) unlawful, unlicensed, uncertified, or non-compliant Provider Activities; (d) a claim concerning fairness, RNG integrity, RTP, game mathematics, certification status, or authoritative game state of Provider Content; (e) a Provider-attributable Incident under Schedule C clause C.10(a); (f) fraud, money laundering, sanctions evasion, or illegal activity originating in systems controlled by the Provider; or (g) the regulatory-classification circumstances described in Section 9.5. The indemnity includes amounts that The Aggregator is legally required to pay an Affected Operator under the Operator Service Offer for the same Provider-attributable matter.
The Aggregator shall indemnify, defend, and hold harmless the Provider from third-party claims and documented direct losses to the extent directly caused by: (a) The Aggregator's gross negligence or wilful misconduct; (b) infringement of third-party Intellectual Property Rights by the software and technology comprising the Aggregator Service, excluding Provider Content; (c) The Aggregator's material breach of Section 12 or Schedule D; (d) The Aggregator's material failure to perform the direct Operator or Platform Partner onboarding checks expressly required by Section 2.4 in good faith; (e) a materially false review summary, Platform Operator notice record, or other materially false statement supplied by The Aggregator concerning an Operator or the Provider; or (f) a claim or regulatory process alleging that The Aggregator failed to obtain a licence, registration, approval, or authorisation legally required for The Aggregator's own activities. For paragraph (f), the duty to defend and bear reasonable covered defence costs begins when a substantiated allegation is made; the duty to indemnify a final liability applies only to the extent the required authorisation and The Aggregator's failure to obtain it are established by a final decision or a settlement approved under Section 10.3. This indemnity is subject to the liability cap in Section 9.3(a), except to the extent Section 9.3(e) applies. It does not make The Aggregator a guarantor of an Operator's information, conduct, indemnity, or solvency.
An indemnified person shall give prompt written notice of a claim, provide reasonable supporting evidence, mitigate avoidable loss, and provide reasonable cooperation at the indemnifying party's expense. Delay in notice reduces liability only to the extent it materially prejudices the defence. The indemnifying party may control the defence with qualified counsel reasonably acceptable to the indemnified person, but may not settle a claim in a manner that admits fault by, imposes a non-monetary obligation on, or fails to give a full release to the indemnified person without that person's prior written consent, not to be unreasonably withheld. No person may recover more than once for the same loss. For an Incident, the final RCA, agreed allocation, settlement, or arbitral award shall determine causation and allocation; participation in a Sync-Up is not an admission of liability.
The Aggregator may immediately suspend the Provider's access, in whole or for specific Provider Content or Operator routes, without prior notice, if: (a) fraud, AML, or illegal activity is reasonably suspected; (b) a B2B licence is suspended, revoked, or expires; (c) certification underpinning Provider Content is suspended, revoked, expires, or is materially impugned; (d) an IP notice is accompanied by a court order or creates imminent regulatory or infringement harm, while any other credible IP notice is handled under Schedule C clause C.11; (e) the Provider breaches a material term, provided that an operational target miss alone is handled under Schedule B; (f) continued service exposes The Aggregator to regulatory, legal, or reputational risk; (g) a competent authority requests suspension; or (h) the Kill-Switch under Schedule C is activated.
Suspension does not release The Aggregator from payment obligations for Metered Successful API Calls completed prior to suspension.
The Provider may immediately suspend affected Provider Content, Operators, geographies, or routes, without liability for an availability-target miss, where the Provider reasonably determines that suspension is necessary to address (a) an actual or suspected security Incident; (b) unlawful use; (c) a sanctions, licensing, certification, or regulatory concern; (d) a competent-authority direction; (e) a credible IP-infringement risk; or (f) imminent material harm to Provider Content, the Provider RGS, Players, an Operator, or the Aggregator Service. Emergency action may be taken without prior notice, provided the Provider notifies The Aggregator as soon as reasonably practicable and supplies the factual basis to the extent legally permitted.
If an undisputed amount remains unpaid for more than thirty (30) calendar days after its due date, the Provider may suspend new Game Sessions and new Rounds on written notice until full payment, without waiting a further remediation period. For another material Aggregator breach that does not create an emergency, suspension may occur if the breach remains uncured thirty (30) calendar days after written notice.
Unless the Provider elects to suspend immediately under this Section, the thirty (30)-calendar-day period is intended to allow The Aggregator to notify affected Operators and, where practicable, to complete or wind down active promotions in an orderly manner. The purpose of that process is to reduce avoidable disruption to Operators and Players and to protect the Provider's reputation and continuing commercial relationships with Operators. The Provider nevertheless retains the right, at its sole discretion, to disable or suspend its API, Provider Content, Operators, geographies, or routes at any time. Where technically safe and legally permissible, the Provider shall use reasonable efforts to allow an already accepted Round to reach a consistent final state. Every suspension shall be proportionate in scope and, where based on a remediable ground, lifted promptly when that ground is remedied, unless the Provider elects otherwise in its sole discretion.
Where the Provider RGS materially and repeatedly misses the operational target in Schedule B clause B.4 and the Provider fails to implement an agreed remediation plan, The Aggregator may, at its discretion and without breach: (a) deprioritise routing, (b) cap the rate of API Calls routed, (c) suspend specific Provider Content, or (d) initiate termination. Before exercising (a)–(c), The Aggregator shall use commercially reasonable efforts to notify the Provider via the Provider Workspace and allow proportionate remediation, unless immediate action is required under Section 11.1. Deprioritisation does not entitle the Provider to compensation; payment for Metered Successful API Calls completed during deprioritisation remains due.
The Aggregator processes Provider registration, account, billing, and business-contact data as controller. For Player-adjacent personal data transmitted by a direct Operator, the direct Operator is controller, The Aggregator is processor, and the Provider is The Aggregator's sub-processor to the extent it processes that data solely to execute Provider Content and return transaction or result communications. For Platform traffic, the intended chain is Platform Operator as controller, Platform Partner as processor, The Aggregator as sub-processor, and the Provider as further sub-processor, subject always to the functions actually performed and applicable law. If any party independently determines a distinct purpose and essential means for processing, it acts as an independent controller for that processing and is responsible for the corresponding notice, legal basis, and compliance obligations. Schedule D governs the Provider's sub-processing or further-sub-processing relationship with The Aggregator.
Provider registration, contract, billing, and non-payload metering records processed by The Aggregator as controller are retained in accordance with the Privacy Policy and for any longer period required by applicable law. Operator Personal Data, including Platform traffic data, is subject to Schedule D and shall not be retained under this clause merely because the Provider Agreement remains active.
For Provider business-contact and account data processed by The Aggregator as controller, individuals may exercise applicable rights by contacting legal@aggregator.gg. A request concerning Operator Personal Data shall be forwarded through the applicable contractual chain to the direct Operator or Platform Partner, and The Aggregator and the Provider shall act only on documented instructions unless applicable law requires otherwise.
TLS 1.2+ in transit; encryption at rest; access controls; key rotation; append-only audit logging; continuous monitoring.
If The Aggregator receives a regulatory request relating to the Provider, it shall (a) notify the Provider promptly unless prohibited, (b) provide reasonable cooperation as required by law, (c) disclose Provider data as legally required.
Schedule D applies where the Provider processes Operator Personal Data as The Aggregator's sub-processor or further sub-processor and is intended to satisfy the flow-down requirements of GDPR Article 28(4).
Each party shall maintain the confidentiality of the other party's confidential information, including pricing (in particular Operator-paid package rates and Aggregator margin), certification reports, technical specifications, API documentation, business strategies, and proprietary systems. Obligations survive termination for five (5) years; trade-secret status survives indefinitely.
During the term and for twelve (12) months thereafter, neither party shall solicit or induce any employee, contractor, or agent of the other party to terminate their relationship, save in response to a general non-targeted job advertisement.
If the Provider opts in during registration, The Aggregator may send product updates, release announcements, and commercial communications.
This Agreement shall be governed by the laws of the Republic of Costa Rica, without regard to conflict-of-law provisions.
Good-faith negotiation for thirty (30) calendar days. Failing resolution, binding arbitration under the ICC rules, conducted in English, seat in San José, Costa Rica, sole arbitrator. Either party may seek injunctive relief from a court of competent jurisdiction.
The Provider may not assign without The Aggregator's prior written consent. The Aggregator may assign to an affiliate or in connection with a merger, acquisition, or sale of substantially all of its assets.
If any provision is invalid or unenforceable, the remaining provisions continue.
This Offer, together with all Schedules and any written addenda signed or accepted in accordance with this Offer, constitutes the entire agreement between The Aggregator and the Provider. The Operator-facing rate card, Platform Partner Commercial Terms, and The Aggregator's margin are not part of this Agreement.
No failure or delay constitutes a waiver.
Events beyond reasonable control, including natural disasters, war, terrorism, sanctions, pandemics, cyberattacks beyond commercially reasonable security measures, or third-party infrastructure failure not caused by the affected party's negligence.
Sent to the contact details on registration (Provider) or the address in §17.11 (Aggregator).
English. The English version prevails in any translation.
Electronic communications, signatures, and records (including acceptance via the registration checkbox) satisfy any legal writing or signature requirement.
The parties are independent contractors. No agency, partnership, joint venture, employment, or fiduciary relationship.
---
A.1 API traffic and Game Rounds. A Game Session begins only when an authenticated session-initiation request attributable to a provisioned Operator is routed to the Provider RGS. For Platform traffic, the request is transmitted through the tested Platform Partner integration and identified by Platform ID and Operator ID. The Provider RGS executes each Game Round and may generate multiple API Calls, including bet, win, refund, result, acknowledgement, balance, rollback, or other technical communications. These communications do not each become payable merely because they are successfully routed. The category labels describe the purpose of routed messages; they do not mean that The Aggregator authorises a wager, determines an outcome, maintains a wallet, or effects a gaming settlement.
A.2 Eligible billable API Call. One Metered Successful API Call is recorded for one unique production bet or equivalent wager/debit transaction representing a billable Game Round where all of the following occur: (a) the Provider RGS sends an authenticated, schema-compliant transaction bearing a unique Provider transaction identifier and a Round identifier, or another documented identifier that uniquely maps that transaction to one Round; (b) the Aggregator Service routes it to the direct Operator's designated wallet or callback endpoint or, for Platform traffic, the integration-specific Tested Acceptance Point; (c) that endpoint or Tested Acceptance Point accepts it with the success status specified in the API documentation and integration test record; and (d) the Aggregator Service records the request and corresponding acknowledgement within the same trace context, including Platform ID and Operator ID where applicable. Each eligible transaction carries an Aggregator correlation ID (x-aggregator-call-id). Absent a signed provider-specific addendum expressly defining a multi-wager Round, neither the same Provider transaction nor the same Round may produce more than one Metered Successful API Call.
A.3 Non-billable / non-payable categories. The following are not Metered Successful API Calls and are not payable: Game Session launch, resume, or end requests; balance queries; win, payout, result, settlement-status, refund, rollback, or void communications; free-round or promotional transactions identified as non-billable under the API specification; health checks and Aggregator Service monitoring; retries within the documented retry window; idempotent duplicates; calls rejected before reaching the intended endpoint; and sandbox, staging, or integration-validation traffic. These communications may still be logged as technical API traffic for security, support, and incident reconstruction.
A.4 Successful versus Failed eligible API Call. An eligible API Call is Successful only if it satisfies every condition in clause A.2, including acceptance by the direct Operator's designated endpoint or the applicable Tested Acceptance Point. It is Failed if it times out, fails authentication or schema validation, receives a non-success or malformed acknowledgement, cannot be routed to the applicable acceptance point, or is subsequently identified as an idempotent duplicate. A Failed eligible API Call produces no Operator-side balance deduction and no Provider payout. A verified reversal or refund of a previously recorded eligible transaction is handled as a metering and RCTI correction under Sections 8.8 and A.6, not as an SLA service credit.
A.5 Metering ledger. Append-only, tamper-evident, stored with periodic integrity checks. Each entry records: correlation ID, Operator ID, Platform ID where applicable, Provider ID, Provider Content identifier, category, request timestamp, response timestamp, success/failure classification, and idempotency key. It is the authoritative source for the count of Metered Successful API Calls and Provider payout/RCTI calculation. For Incident attribution, money-path questions, and game-outcome questions, the multi-source reconstruction rule in Schedule C applies.
A.6 Audit and correction. The Provider may audit a disputed period and obtain correction of every verified discrepancy in accordance with Section 8.8.
A.7 Outage exclusion. Periods during which the metering layer is itself unavailable, flagged in the Schedule B SLA report, are reconciled retrospectively with adjustments processed on the next RCTI cycle.
---
B.0 Scope and nature of SLA. This Schedule sets operational service-level objectives for The Aggregator's API Routing Layer and the Provider RGS. It does not guarantee the availability, correctness, RTP, fairness, or playability of Provider Content. A Provider-RGS failure does not count against the Routing Layer target, and an Aggregator Routing Layer failure does not count against the Provider target. All availability, success-rate, response, and resolution figures in this Schedule are targets to which the relevant party shall use commercially reasonable efforts to aspire; they are not warranties or guaranteed minimums unless a signed addendum expressly states otherwise.
B.0.1 Measurement definitions. "Routing Layer" means the authentication, routing, metering, and observability components controlled by The Aggregator that form the API-facing boundary of the Aggregator Service. "Total Routing Minutes" means the total clock minutes in the relevant calendar month. "Unavailable Minutes" means whole minutes during which the Routing Layer is materially unable to authenticate and route eligible production API traffic at the Routing Layer, excluding the circumstances in clause B.2.
B.1 Routing Layer availability target — 99.9%. The Aggregator shall use commercially reasonable efforts to achieve monthly availability of at least 99.9%, measured at the Routing Layer.
> Availability% = (Total Routing Minutes − Unavailable Minutes) ÷ Total Routing Minutes × 100
For the avoidance of doubt, this target applies only to The Aggregator's own Routing Layer infrastructure. It is not a guarantee of overall game availability or the end-to-end Operator experience, both of which also depend on the Provider RGS and Operator systems.
B.2 Exclusions from Routing Layer SLA. Unavailable Minutes do not include time attributable to:
B.3 Nature of targets; no SLA credits. No cash or in-kind service credit, token, payout uplift, refund, liquidated damages, or penalty accrues solely because a target in this Schedule is missed. The parties shall cooperate in good faith on incident review and a proportionate remediation plan where a target is materially or repeatedly missed. This clause does not prevent correction of an erroneous metering or RCTI entry, termination for a separate uncured material breach, or liability for fraud, wilful misconduct, gross negligence, or any matter that cannot lawfully be excluded.
B.4 Provider-RGS performance target — 99.9%. The Provider shall use commercially reasonable efforts to achieve, in each calendar month, a successful processing and schema-compliant response rate of at least 99.9% for applicable API Calls that reach the Provider RGS. This operational target is measured separately from the commercial Metered Successful API Call classification in Schedule A.
B.4.1 Exclusions from the Provider target. Failures during the following intervals do not count against the Provider target:
B.4.2 Remediation of repeated target misses. Failure to meet a target does not, by itself, create a payment, refund, credit, damages, or termination entitlement. If the Provider materially misses the target for two consecutive calendar months, the parties shall agree a reasonable remediation plan. Failure to implement that plan, or continued material underperformance affecting service, may engage Section 11.5 and, if it becomes a separate material breach, Section 11.3. The Aggregator shall make relevant performance telemetry available in the Provider Workspace.
B.4.3 No double-counting. A technical failure shall be attributed to either the Routing Layer for clause B.1 or the Provider RGS for clause B.4, but not both. The metering ledger is authoritative for commercial counts only; technical attribution for a disputed incident is determined from all available evidence under Schedule C.
B.5 Support tiers.
B.6 Severity levels.
| Severity | Definition | First response | Resolution target |
|---|---|---|---|
| Critical / P0 | Routing Layer down, metering ledger unavailable, active money-path safety event | 30 minutes | 4 hours |
| High / P1 | Significant degradation, partial outage, fraud incident | 2 hours | 8 hours |
| Medium / P2 | Non-blocking integration issue, documentation gap, performance regression | 8 hours | 5 Working Days |
| Low / P3 | Cosmetic, low-impact feature request | 2 Working Days | Best efforts |
B.7 Required ticket information. Correlation ID(s), UTC timestamps to the minute, expected vs. observed behaviour, severity classification, reproduction steps.
B.8 Reporting. Monthly SLA report via the Provider Workspace showing availability percentage, P0/P1 incidents, scheduled maintenance, Provider-RGS performance telemetry, and remediation status for material target misses.
---
C.1 Purpose and scope. This Schedule sets out the parties' obligations to monitor, prevent, detect, contain, investigate, and remediate fraud, abuse, and security incidents. It supplements §4.9, §6, §10, and §11.1. In conflict with another provision, this Schedule prevails for incident-handling procedures only.
C.2 Definitions.
C.2.1 Multi-source incident reconstruction; no single authoritative end-to-end record. The Aggregator operates at the API-routing and metering layer. It may transiently process wager, win, refund, balance, or result fields carried in routed API payloads, but it does not maintain the authoritative Player-wallet, GGR, settlement, RNG, or game-state ledger; calculate GGR; determine game outcomes; or control Player funds. Accordingly, no single party holds an authoritative end-to-end record of an Incident. Each party to this Agreement shall contribute its own records. The Aggregator shall use its contractual rights under the applicable Operator Service Offer or Platform Partner Service Offer to request corresponding records from the affected Operator. For Platform traffic, the Platform Partner shall obtain reasonably necessary records from its Platform Operator under their separate relationship and contribute them under the Platform Partner Service Offer. The Aggregator shall assemble the RCA from all records reasonably available. The Platform Operator does not become a fourth contractual party merely because its evidence is included.
The scope of authoritativeness is split:
C.3 Continuous monitoring obligations of The Aggregator. The Aggregator shall, at its own expense and on a continuous basis:
/.well-known/security.txt endpoint, accept responsible-disclosure submissions, and acknowledge credible reports within five (5) Working Days.C.4 Continuous monitoring obligations of the Provider. In addition to §4.9, the Provider shall:
C.5 Kill-Switch. The Aggregator maintains, and the Provider may operate from the Provider Workspace, a Kill-Switch capable of (a) globally pausing delivery of Provider Content, (b) selectively pausing a specific item of Provider Content, and (c) selectively pausing delivery to a specific direct Operator, Platform Partner, Operator ID, or geography. The parties shall use commercially reasonable efforts to make an authenticated Kill-Switch instruction effective within sixty (60) seconds, subject to network and dependency conditions, and shall log each invocation. The Aggregator may activate the Kill-Switch in a Section 11.1 circumstance or under Section 11.5; the Provider may do so under Section 11.2.
C.6 Detection and notification matrix. On the earlier of (i) confirmed detection or (ii) the time a reasonable security-operations function would have had grounds for suspicion, the detecting party shall raise the Incident through the published support channels and notify all materially affected parties within:
| Severity | Trigger examples | Notice window | Channel |
|---|---|---|---|
| Critical / P0 | Money-Path Incident; confirmed Personal Data Breach affecting Operator Personal Data; confirmed credential compromise with active exploitation; Kill-Switch event | 1 hour | Emergency phone + Telegram + email + dashboard |
| High / P1 | Suspected compromise; fraud-pattern detection; failed sanctions screen; sub-processor breach notification | 8 hours | Telegram + email + dashboard |
| Medium / P2 | Single-event anomaly under investigation; loss of authenticator by privileged user | 24 hours | Email + dashboard |
| Low / P3 | Routine vulnerability disclosure; threat-intelligence sharing; post-incident reports | 5 Working Days | Dashboard |
Notifications are mutual, parallel, and do not depend on conclusive attribution of fault.
C.7 Support handling and containment. Following detection, the Incident is handled by each party's support/security function according to its role and the SLAs in clause C.6 and Schedule B. (a) Each party may, without breach, immediately isolate its own systems. (b) The Aggregator may, without breach, exercise the Kill-Switch unilaterally per clause C.5. (c) The Provider may request emergency suspension via the incident channel; The Aggregator shall act within sixty (60) minutes of a verified request. (d) Within four (4) hours of Critical/High notification the parties shall designate an Incident Commander; failing agreement, The Aggregator acts as Incident Commander pro tem. (e) Containment durations are excluded from Schedule B availability calculations during the Forensic Window. (f) Each party shall apply an evidence-preservation hold for not less than twelve (12) months, or such longer period as required by law or by written request of the Incident Commander.
C.8 Incident Reports. Within seventy-two (72) hours of Critical/High containment (and within five (5) Working Days for Medium), each party to this Agreement that is materially involved shall submit a written Incident Report to the Incident Commander. The Aggregator shall use its contractual rights under the applicable Operator Service Offer or Platform Partner Service Offer to request a corresponding report from an affected Operator. For Platform traffic, the Platform Partner shall obtain and include reasonably available supporting evidence from the affected Platform Operator. Each Incident Report shall contain, at minimum:
Common contents (all parties): Incident reference ID + reporting party's internal reference; reporting party, named incident contact, and 24/7-reachable channel; detection (timestamp UTC to the minute, method, detecting system); incident category and severity with justification; chronological timeline; affected scope (counterparties, games, routes, pseudonymised Player/session IDs, API-Call correlation IDs, estimated monetary exposure); the reporting party's own ledger/log excerpt; containment actions with timestamps; preliminary cause hypothesis and confidence level; evidence-preservation confirmation (location and retention-end date); regulatory-notification status; known impact on other parties; remediation actions taken and planned; open questions.
The Aggregator's additional contents: API-Call metering-ledger excerpt; Routing-Layer health; Kill-Switch invocation log; relevant sub-processor status.
The Operator-side additional contents: for a direct Operator, its Player wallet/transaction/GGR ledger excerpt, pseudonymised KYC status of affected accounts, geolocation and sanctions-screening results, bonus/promotion context, chargeback and AML flags, and estimated Player-payout exposure; for a Platform Partner, its Platform ID, affected Operator IDs, integration-layer and tenant-isolation logs, Tested Acceptance Point evidence, and the corresponding downstream evidence it can reasonably obtain under its Platform Operator agreement.
The Provider's additional contents: game-state and RNG audit excerpt; certification status of affected Provider Content; settlement ledger excerpt; backend health during the window; any Software Defect linkage; mathematical-model integrity attestation.
Omissions are weighed against the omitting party at the Sync-Up.
C.9 RCA and Sync-Up. Within thirty (30) days of containment, The Aggregator shall use commercially reasonable efforts to assemble the available Incident Reports into one written RCA covering timeline, cause, scope, contributing factors, mitigation, and recommended remediations. Within ten (10) Working Days after circulation, The Aggregator shall convene a damage-allocation Sync-Up among the parties bound to participate under their respective Service Offers. The Provider shall participate; The Aggregator shall use its rights under the applicable Operator Service Offer or Platform Partner Service Offer to procure the affected Operator's participation. For Platform traffic, the participating Operator-side party is the Platform Partner, which shall obtain downstream evidence and cooperation under its own Platform Operator relationship. Minority statements may be annexed. No Platform Operator or other non-party becomes bound to this Agreement merely by supplying evidence or participating.
C.10 Damage allocation framework. Determined at the Sync-Up on the basis of the multi-source reconstruction, not on any single party's ledger. The Aggregator's liability remains subject to Section 9.3; the Provider's and any Operator's obligations are governed by Section 10 of the respective Service Offer:
C.11 Money-Path-specific procedures (Large Win, Software Defect).
C.12 Sanctions and AML escalation. The Aggregator is an API-routing infrastructure provider and does not operate proactive sanctions or AML screening of all API-Call traffic and is not the ecosystem sanctions or AML gatekeeper. Sanctions and AML compliance on the underlying gaming activity is the Provider's responsibility under Section 4.4 and clause C.4 of this Offer and the applicable Operator's responsibility under the Operator Service Offer or Platform Partner Service Offer. For Platform traffic, the allocation between a Platform Partner and its Platform Operator depends on their actual functions and separate agreement, without reducing the Platform Partner's obligations to The Aggregator.
Where The Aggregator becomes aware — through a binding legal order, sanctions designation, competent-authority instruction, or its own anomaly telemetry — that specific API-Call traffic is associated with a sanctioned party, a Restricted Jurisdiction, or unlawful activity, The Aggregator may block or suspend the affected traffic; such blocked calls are Failed under Schedule A clause A.4 (symmetric refund).
C.13 Regulatory notification. Each party is solely responsible for identifying and making the regulatory, supervisory, data-protection, financial-intelligence, sanctions, and law-enforcement notifications that apply to it under the laws of the jurisdictions in which it operates and under the licences and authorisations it holds. No party is responsible for, or warrants the sufficiency of, another party's regulatory analysis or filings. The parties shall cooperate in good faith to provide one another with the factual information reasonably necessary for each to meet its own notification obligations within the applicable statutory windows (including the 72-hour personal-data-breach window under GDPR Article 33). No party shall make a public statement about an Incident that identifies another party without that party's prior written consent (not to be unreasonably withheld), except where disclosure is required by law, court order, or a competent authority.
C.14 Records retention and continuous improvement.
---
To the extent the Provider processes Operator Personal Data routed to the Provider RGS, the Provider acts as The Aggregator's sub-processor or further sub-processor under GDPR Article 28(4). For direct Operator traffic, the intended chain is direct Operator as controller, The Aggregator as processor, and Provider as sub-processor. For Platform traffic, the intended chain is Platform Operator as controller, Platform Partner as processor, The Aggregator as sub-processor, and Provider as further sub-processor. These descriptions depend on the functions actually performed and do not override applicable law.
---
End of Provider Service Offer (v3 — effective 23 July 2026).
This document is available in English only. The English version is the legally binding version.