Data transfer between countries

1) Purpose and area

Create a manageable and provably secure model for cross-border transfers of personal data (PII) and operational sets (KYC/AML, payments, RG/SE, CRM/marketing, gaming telemetry, logs/AWP, analytics/DWH), taking into account the requirements of iGaming licenses and data protection laws of different jurisdictions. The document complements the sections: "Data localization," "Deletion and anonymization," "GDPR: consent," "DSAR."

2) Basic concepts and principles

Cross-border transmission - any access/replica/processing outside the subject's/data's "home" jurisdiction.
Adequacy/equivalence - decisions of the regulator on the sufficiency of the protection of the recipient country.
Contractual arrangements - standard contractual provisions, local equivalents, supplementary agreements.

TIA - Transfer Impact Assessment

Sovereignty/residency - storage location and local control right.

1. Local-first: if possible, process locally; outward - minimally and according to the rules.

2. Minimization: "just as much as necessary"; preferably aggregates/aliases.

3. Cryptography and isolation: encryption, keys in the region, control/data plane separation.

4. Provability: log of each transmission, TIA and foundation artifacts.

5. Fail-closed: no ground or TIA - no transmission.

3) Roles and RACI

DPO/Head of Compliance (Owner) - policy, tolerances, TIA, exceptions. (A)

Legal - selection of transfer mechanism, contracts, local requirements. (R)

Security/Infra - encryption, KMS/HSM, network perimeters, audit. (R)

Data Platform/Analytics - de-PII/anonymization, federated/cohort reporting. (R)

Engineering/SRE - routing, tokenization, export control. (R)

Vendor Manager - register of sub-processors, confirmations, offboarding. (R)

Internal Audit - artifact samples, CAPA. (C)

4) Data Transfer Map

Source → appointment (country/cloud/vendor) → category of data → purpose → legal basis → transfer mechanism → protection (those) → periods of storage → responsibility.
Graphically fixed for: support/CS, analysis/reporting, fraud/risk rates, game providers and PSPs, affiliates.

5) Legal mechanisms (framework)

1. Decision on adequacy (if applicable): simplified path, but still need TIA artifacts and contracts with the vendor.
2. Standard/standard contractual provisions and local equivalents: include mandatory appendices (categories, objectives, measures).
3. Binding/additional agreements: clarify the duties of subprocessors, notifications about requests from government agencies.
4. Exceptions by law: point and rare (vital interests, contract requirement) - not for systemic export.
5. Intra-group rules: for holdings - corporate instruments with control.

6) Transfer Impact Assessment (TIA)

Reason: new vendor/country, new target, new categories (biometrics, RG/SE), change in key mode or routes.

• Transmission description (data/volume/frequency/participants).
• Legal environment of the recipient country (risks of access by government agencies, legal means of protection of subjects).
• Technical measures: encryption, keys (BYOK/HYOK), pseudonymization, split-processing.
• Organizational measures: NDA, training, need-to-know, logging, responses to requests.
• Residual risk/decision: allow/modify/deny; revision period.

TIA short form template: see § 15C.

7) Technical and organizational measures

7. 1 Cryptography and keys

At rest: AES-256-GCM; in transit: TLS 1. 2+/mTLS; PFS.
KMS: BYOK (we have keys), preferably HYOK (keys remain in the region); segmentation by market/tenant; unalterable audit of key operations.
Crypto-shredding: for backups and archives with deadlines.

7. 2 Minimization and de-identification

Aliasing before export (token gateway), storing mapping separately in the region.
Aggregates, k-anonymity/date binning and geo, suppression of rare categories.
PII-free logs/AWS and server-side tagging with zeroing of identifiers without consent.

7. 3 Insulation of planes

Global control-plane without PII; data-plane with PII locally.
Access to PII through a proxy layer with justification of the request and log.

7. 4 Requests from government agencies

Reaction contour: verification of legality, challenge, minimization of volume, notification (if allowed), entry in the register of requests.

8) Data categories and transfer rules

9) Vendors and sub-processors

Registry: Jurassic person, DC countries, sub-processors, certifications, transfer mechanisms, key mode.
Contracts: DPA + SCC/analogues, notifications about changing locations/sub-processors ≥30 days, audit/questionnaire rights, obligations to localize backups, SLA incidents and DSAR.
Onboarding/review: TIA, pentest/attestation, "sample transfer" test.
Offboarding: export/delete/crypto-shred + evidence.

10) Backups, logs and analytics

Backups: in the same region; export abroad - only in encrypted form + HYOK; when the deadline is reached - crypto-shred.
Logs/AWS: PII-free by default; if not, local storage, short retention.
Analytics/DWH: global reports only aggregates/cohorts; banning raw identifiers outside the region.

11) Processes and events

Through process: transfer inquiry → check of a profile of the market → choice of the mechanism → TIA → coordination → technical measures → start → monitoring → artifacts/audit.

• `xborder_transfer_requested/approved/denied`
• 'transfer _ executed '(volume/time/vendor)
• `key_accessed_for_transfer` (KMS audit)
• `gov_request_received/responded`
• `vendor_location_changed`
• `transfer_review_due`

12) Data and artifacts (model)

transfer_record {
id, market_from, market_to, vendor, purpose, lawful_basis,
mechanism{adequacy    scc    local_clause    exception}, tia_id,
data_classes[], pii{yes/no}, deidentification{pseudo    anon    none},
encryption{at_rest, in_transit, keys{scope: BYOK    HYOK, kms_region}},
executed_at_utc, volume{rows, mb}, retention_days, backups{region, crypto_shred:true},
approvals{legal, dpo, security}, status, evidence_uri(WORM)
}

tia {
id, date, countries_involved[], legal_risk_summary, gov_access_risk,
technical_measures[], organizational_measures[], residual_risk{low    med    high},
decision{allow    modify    deny}, review_at
}

13) KPI/KRI and dashboard

X-Border Transfer Rate (by target/vendor/country).
TIA Coverage (% of transmissions with current TIA).
BYOK/HYOK Coverage.
Anonymous Export Share (% of exports in aggregates/aliases).
Vendor Location Drift (location change incidents).
Gov Request Count and average response time.
Auditability Score (% of records with full package of artifacts).

14) Checklists

A) Before transfer

• Purpose and legitimate purpose confirmed.
• Mechanism selected (adequacy/contract/analog), TIA performed.
• Aliasing/anonymization configured; volume minimized.
• KMS/Keys: BYOK/HYOK, log enabled.
• Vendor contract: DPA + SCC/equivalent, DC/sub-processor change notifications.
• Residency of backups and crypto-shred in plan.

B) In operations

• Monitoring'vendor _ location _ changed'and alerts.
• Periodic revision of TIAs and mechanisms.
• DSAR/deletions are correctly applied at the perimeter of the recipient (or through anonymization).
• Transfer logs and KMS audits are available to the audit.

C) Audit/Improvements

• Quarterly 'transfer _ record' samples for completeness.
• CAPA on Incidents/Complaints/Regulatory Findings.
• Vendor "revoke access" test + confirmation of deletion.

15) Templates (quick inserts)

A) Clause "cross-border transfer"

B) Notification of a government agency request

C) Brief TIA (one-pager)

16) 30-day implementation plan

Week 1

1. Approve cross-border transmission policies, RACIs and TIA/DPA templates.
2. Build a map of current flows and a register of vendors/locations/keys.
3. Configure KMS by markets (BYOK/HYOK), enable unchanging key auditing.

Week 2

4) Enable aliasing before export and PII-free logs/AWS.
5) Start the 'transfer _ record '/' tia' registry (WORM artifacts).
6) Update contracts with critical vendors: locations, notifications, offboarding procedures.

Week 3

7) Pilot 2-3 streams (CS, DWH reports): measure Anonymous Export Share, BYOK Coverage.
8) Train Product/CS/BI/Legal on government request procedures and escalations.
9) Connect alerts' vendor _ location _ changed '.

Week 4

10) Full release; KPI/KRI dashboard and quarterly TIA reviews.
11) CAPA by findings; plan v1. 1 - federated analytics/diff. privacy in reports.
12) Offboarding test of one vendor: deletion/crypto-shred, confirmation.

17) Interrelated sections

Localization of data by jurisdictions

Data Deletion and Anonymization/Retention and Deletion Schedules

GDPR: Consent Management/Cookies and CMP Policy

Privacy by Design / DSAR

At Rest/In Transit, KMS/BYOK/HYOK encryption

Compliance Dashboard and Monitoring/Internal and External Audit