Common Transaction Reporting and Evidence Standard

1.Purpose and status#

1.1The problem this Standard addresses#

Every gambling regulator asks operators the same five questions about money. Did it come from the player? Was it checked before it was accepted? Was it credited correctly? Where did it go when it left? Is the money owed to players actually there? Each regulator asks in its own format, on its own calendar and through its own channel.

The research behind this version reviewed the published rules of sixty-seven jurisdictions on five continents (Annex B), from long-established online markets to markets that are opening, closed or still writing their rules. The questions are the same in all of them. What differs is a small set of parameters: which payment rails are permitted, at what amounts checks and reports are triggered, over what time window amounts are aggregated, how quickly a payout must be made, where data must be held, and for how long.

Three consequences follow from the absence of a common format:

• An operator licensed in several jurisdictions rebuilds the same evidence for each. In federal, provincial and entity systems — Argentina, Bosnia and Herzegovina, Canada, Nigeria, South Africa, the United States — the same facts arrive in as many shapes as there are licensing bodies.
• More than half of the jurisdictions reviewed run, or are building, a central system, data vault or state transaction register — from Italy, Spain, Denmark and Germany to Brazil, Colombia, Kazakhstan, Uzbekistan and Uganda. Each defines the operator-side data afresh, so every new connection is a bespoke integration.
• An operator that has implemented its controls well cannot prove it more cheaply than one that has not.

CTRES defines the shape of the evidence once and lets each jurisdiction set its own parameters.

1.2What this Standard is not#

• It creates no obligation. It formats evidence of duties that already exist under each jurisdiction’s law and licence conditions.
• It does not replace any authority’s central system, reporting portal or financial intelligence reporting schema, such as goAML, the FINTRAC reporting API, Infostat-UIF or SIGAP. It is the operator-side evidence layer from which those submissions can be produced (§7).
• It is independent of any authority. Every reference to a jurisdiction’s rules is a reading of published sources, offered to the authority concerned for review.
• It names no vendor and requires none.
• It does not cover game outcomes, wagering records beyond their reference, marketing data or behavioural analytics.

1.3Relation to the Curaçao edition#

The first edition of this Standard, prepared in September 2026, covered virtual assets only, under one jurisdiction’s crypto policy. This universal edition keeps its record model and makes three structural changes:

• Rail-neutral core. The record model describes any payment rail. Virtual assets become one rail module among seven (§6), and everything the Curaçao edition defined for them is kept.
• Jurisdiction profiles. Thresholds, windows, permitted rails, deadlines and retention periods are no longer written into the records; they are parameters of a profile (§5). Profiles for sixty-seven jurisdictions, researched from published sources, are in Annex B.
• Map, don’t replace. Each record carries the references that payment rails and regulators’ own systems issue, so a single source of truth can feed every submission (§7).

The full list of differences is in Annex F.

2.Scope#

2.1In scope#

Licensed gambling operators — online and, where an authority so chooses, retail and land-based — and the payment providers acting for them, for the following:

• Player deposits and withdrawals on any rail, and the payment instruments used.
• Every location where the operator holds money: player-funds accounts, operational and treasury accounts, provider balances, mobile money collection accounts, virtual-asset wallets and cash floats.
• Checks that precede the movement of money: identity and holder verification, sanctions, eligibility and exclusion registers, limits, source of funds, fraud and blockchain analytics.
• Taxes levied or withheld at the point of payment.
• Movements between the operator’s own funds locations.
• Reconciliation of each funds location, and of total player liabilities against the funds held to cover them.
• Exceptions, incidents, and references to reports filed with other authorities.

2.2Out of scope#

Game and wager records, which are referenced but not reproduced; marketing and affiliate data; behavioural analytics; and the content of suspicious transaction reports, which remains under the confidentiality rules of each jurisdiction (§12).

3.Design principles#

4.Record model#

Twelve record types. Each record is one line of JSON; each file holds one record type for one period. Core fields are listed below; rail-module fields are described in §6, and the complete catalogue is maintained as a machine-readable schema (Annex A), published at github.com/ctres-standard/schema.

4.1R1 Funds Location#

Every place the operator holds money, in any form. This is the record that answers segregation and protection requirements.

4.2R2 Payment Instrument Link#

The link between a player and a payment instrument: whose it is, how that was established, and whether payouts may go to it. R2 is submitted as the full register at period end — every link ever made, including revoked ones with their status — and a player is identified by the pair player_ref_scope and player_ref, so that the same reference in two brands is never merged.

4.3R3 Deposit and 4.4 R4 Withdrawal#

The two records that carry the money. Both reference the instrument, the checks relied upon and the ledger entry, so that the payment, the decision and the player balance can be tied together without further enquiry.

4.5R5 Check Decision#

Any control that runs before money moves, recorded in a common vocabulary so that outcomes remain comparable across providers and registers. The Standard does not prescribe scoring.

4.6R6 Internal Movement#

Movements between the operator’s own funds locations — settlement from a provider to a bank, sweeps, tax remittance accounts — which is where segregation either holds or breaks. Fields: movement identifier; source and destination locations, at least one of which must exist in R1 — the other may be a provider from R10, such as an exchange or a settlement account; purpose (settlement | sweep | liquidity | conversion | tax_remittance | correction); whether the movement crosses purpose classes, with a justification where it does; approver and time; rail reference; amount and fees.

4.7R7 Reconciliation Statement#

Two kinds of statement turn reconciliation from a claim into a number.

• Location statement — one per funds location per period. Opening and closing balances from the external source (bank statement, provider settlement report, mobile operator statement or chain) and from the ledger, plus the provider’s own reported balances where the custody model is omnibus; inflows, outflows and fees; the unexplained delta, stated rather than hidden; exceptions raised; preparer and reviewer.
• Coverage statement — one per licence per period, or per day where the profile requires. Player balances, pending withdrawals and, where the profile counts them, open bets, giving total player liabilities; funds held against them by protection mechanism; funds in transit; any shortfall, and when it was cured.

The custody model declared in R1 selects the reconciliation profile. Applying a direct-custody profile to a pooled arrangement produces an exception on every transaction and tells the reader nothing.

4.8R8 Exception#

Anything the operator could not explain, in a common vocabulary, with a value, an age and an owner. A supervisor rarely needs the whole ledger, but always needs the list of things that did not reconcile. Fields: identifier, category, when and by what process it was raised, related records, amount, status (open | under_review | resolved | accepted_risk), age in days, resolution, owner.

Categories are drawn from a closed list, which includes at least: external movement without a ledger entry; ledger entry without an external movement; amount mismatch; check missing or performed after crediting; payout to an instrument not eligible for payouts; payout outside the closed-loop rule without justification; holder mismatch; credit-funded instrument where credit is prohibited; payout later than the profile deadline; movement across purpose classes without justification; location outside the inventory; provider without due diligence or authorisation; coverage shortfall; tax withheld but not remitted by its due date.

4.9R9 Incident and 4.10 R10 Provider Register#

R9 carries events an authority must be told about, with the deadline clock set by the profile: incident identifier, category, detected and notified times, the deadline that applied, the authority and channel used, related records and status.

R10 records each provider that handles player money — acquirer, bank, payment service provider, e-money institution, mobile money operator, voucher issuer, virtual-asset service provider or cash agent — with the authority that authorised it and the licence reference, whether the gambling regulator was notified of or approved it where the profile requires, the dates of due diligence and next review, where its data is held, and, for virtual-asset providers, Travel Rule capability.

4.11R11 Provider Attestation#

Where money sits in a provider’s pooled account, the operator cannot evidence individual movements from its own statements. R11 is the provider’s statement standing in their place: the period covered, the balance held for the operator, totals credited and debited, the reference scheme that links the provider’s records to the operator’s, and a signature. It applies equally to a card acquirer’s reserve, a mobile money collection account, an e-money balance and a virtual-asset provider’s pooled wallet. An operator whose provider will not supply R11 has not failed this Standard; it has discovered a control it cannot evidence, and reporting that plainly is more useful than reporting a reconciliation that was never possible.

4.12R12 Report Reference#

A link between CTRES records and reports filed with other authorities: suspicious transaction reports, cash and virtual-currency threshold reports, casino disbursement reports, periodic systematic reports, tax remittances and regulator notifications. Fields: reference identifier; report type; destination authority; channel (goAML, a national reporting API, a regulator portal or other); the profile rule that triggered it; related records; deadline; time filed; the receipt the destination issued.

R12 never carries the content of a suspicious transaction report. Where tipping-off and confidentiality rules apply, R12 is held by the operator and disclosed only to an authority entitled by law to see it; periodic packages then carry counts and timeliness only.

5.Jurisdiction profiles#

A profile is a short configuration, in the machine-readable structure defined by the schema (Annex A), that turns the neutral record model into one authority’s rule set. It contains parameters only and never adds fields. The table lists the parameters, with examples drawn from the profiles in Annex B.

Profiles carry effective dates, so a new rule, a market opening or a change of regulator becomes a new profile version rather than an edit — Finland’s licensing from July 2027 and Latvia’s transfer of supervision to its tax authority are examples. Where a market is closed to online gambling, as in India and Kosovo, the profile covers payment-side blocking only.

Profiles belong to the authorities. The editor publishes a profile as confirmed only when the authority concerned has reviewed it; until then it is marked as researched from published sources, as every profile in Annex B is today. Where a federal or provincial system has several licensing bodies, a profile may inherit from a shared base and override only what differs, so that provinces or states agree the common part once.

6.Rail modules#

Each rail adds the identifiers it naturally carries and the external evidence it naturally produces. A jurisdiction that does not permit a rail leaves it out of its profile; nothing else changes.

The virtual-asset module carries forward everything in the Curaçao edition: wallet purpose classes and temperature, key-control models, same-asset and same-wallet withdrawals, blockchain analytics as a check type, and custody models for pooled provider wallets.

7.Mapping to existing regulatory formats#

CTRES does not compete with the formats authorities already receive. It is the source those submissions are produced from, and the place an authority can look when a submission raises a question.

The mappings above are indicative. Detailed mappings are maintained separately from this Standard, versioned, and tested against the destination’s own schema wherever that schema is public.

8.Submission and access#

8.1Modes#

The profile chooses the mode. None of them adds a channel.

8.2Formats and integrity#

• JSON Lines, UTF-8, one record per line, one record type per file. A CSV profile with identical field names is permitted at Level 1.
• Timestamps in ISO 8601 with an explicit offset. Amounts as decimal strings, never floating point. Currencies as ISO 4217 codes; virtual assets by chain and contract.
• Every package carries manifest.json: licence, profile identifier and version, period, record counts, a SHA-256 hash per file, and the generating software and version. The SHA-256 of manifest.json is the package fingerprint: a receipt that quotes it proves which package was submitted. The manifest may be signed with the operator’s certificate where the profile requires.
• Corrections are submitted as a new package that supersedes an earlier one by identifier and reason, so that the record of what was known when is preserved.

8.3Transport and location#

Through the authority’s existing channel. Periodic packages are pseudonymous, so a package seen in transit reveals no player identity. Data location follows the profile. The Standard proposes no new channel and moves no data across borders.

9.Evidence pack#

The pack answers a single supervisory question on any rail: show me this money, end to end. It is assembled from records already defined and contains, for one deposit and the withdrawal that followed it:

• The player reference, verification status and the level of due diligence applied at the relevant threshold.
• The deposit: rail, instrument, holder-match result, amount, rail reference and any authority reference.
• The checks that preceded crediting, with timestamps that prove the order.
• The crediting entry, and any difference from the amount received, with its reason.
• Taxes levied at the payment and their remittance.
• The withdrawal: destination, closed-loop result, checks, approver, and the times requested and paid.
• The location and coverage statements for the period, any exception referencing the transaction, and any report reference the requester is entitled to see.

An auditor can sample directly from these packs. An operator that can produce them in minutes rather than weeks has reduced the cost of its own audit — the commercial reason to adopt the Standard, irrespective of supervision.

10.Conformance levels#

An operator declares its level in the conformance statement at Annex D, signed by the responsible officer.

11.Validation#

A format helps only if conformance can be checked mechanically. Validation is defined here by class, not by rule, so that rules can evolve without reopening the Standard.

The catalogue of individual checks, their severities, the tolerances that separate a rounding difference from a discrepancy, and the materiality thresholds that make an exception reportable are deliberately not fixed in this Standard. They belong to each authority to set, and they will change more often than the format. They are maintained separately as a versioned conformance suite, so that a package can be tested against a named suite version and a named profile version, and the result reproduced later.

Wherever an independent source exists — the chain for virtual assets, bank and provider statements, an authority’s own central system — completeness is checked against that source and not only against the operator’s account of it.

An open reference validator for the Structural and Referential classes, validator-lite, is published under the Apache License 2.0 at github.com/ctres-standard/validator-lite. Validation under the Profile conformance and Completeness classes depends on the parameters this section leaves to each authority and is provided separately. No validator is a condition of using this Standard; an implementation validated by any other means is equally conformant.

12.Data protection, confidentiality and retention#

• Periodic packages carry pseudonymous player references, masked account numbers and hashed phone numbers. Names, addresses and identity documents are not included.
• Identity data is provided only in an evidence pack answering a specific lawful request, and travels under the same arrangements as existing regulatory correspondence.
• Retention follows the profile. An operator licensed in several jurisdictions retains for the longest period that applies.
• Suspicious-report confidentiality is preserved: R12 holds references only and is disclosed only to authorities entitled to see it (§4.12).
• Data location follows the profile.
• Virtual-asset addresses are public by nature; the link between an address and a player is not, and is treated as personal data throughout.

13.Governance and versioning#

14.Roadmap#

15.Questions for authorities#

Each answer changes the Standard materially.

• Is the profile for your jurisdiction in Annex B correct, and what is missing?
• Which rails do you expect to permit, restrict or review over the next two years — in particular virtual assets and new instant-payment schemes?
• Would a common operator-side format reduce the cost of connecting operators to your central system or reporting channel?
• Which submission mode fits your supervision: continuous, periodic package, on demand, or a mix?
• Which holder-verification methods do you accept as evidence that an instrument belongs to the player?
• Where player money sits in a provider’s pooled account — a payment provider, mobile money operator or virtual-asset provider — does a provider attestation (R11) satisfy you, or do you expect the operator to evidence it directly?
• Should report references (R12) be visible to you in periodic packages, as counts only, or not at all?
• For federal and provincial systems: would licensing bodies accept a shared base profile with local overrides?
• If you run a central register, hub or data vault, would you publish its schema, so that a mapping file can be maintained and tested against it?
• May operators refer to this Standard, in the policies and procedures they file with you, as the format in which they will evidence their controls?

Annex A.Field catalogue#

The extracts in §4 and §6 are sufficient to build a working implementation of every record type. The complete catalogue adds formats, enumerations, conditional requirements and examples for each field, together with the profile schema. It is maintained as a versioned machine-readable schema — JSON Schema for record types R1–R12, the package manifest and the structure of a jurisdiction profile — published under the Apache License 2.0 at github.com/ctres-standard/schema, so that implementations can be tested automatically rather than read.

Annex B.Jurisdiction profiles#

Readings of published sources as at 2 October 2026, summarised to the parameters in §5 and grouped by region. They are a reference, not legal advice. “Not found” means that no published rule was located, not that none exists; “to be confirmed” marks a reading the sources did not settle. Each row is offered to the authority concerned for review, and a corrected row replaces this one as submitted.

This table is wide; scroll horizontally to see every column.

Principal sources#

• United Kingdom: Gambling Commission — LCCP 4.1.1, 4.2.1, 6.1.2; AML guidance parts 6–7; 2026 ML/TF risk assessment; quarterly returns consultation response (gamblingcommission.gov.uk).
• Ireland: Gambling Regulation Act 2024 ss.136, 164, 165 (revisedacts.lawreform.ie); S.I. 31/2026; Criminal Justice (Money Laundering and Terrorist Financing) Act 2010 ss.24, 55.
• Gibraltar: Gambling Act 2025 (gibraltarlaws.gov.gi); Remote Technical and Operating Standards; AML Code for remote operators. Isle of Man: GSC AML/CFT guidance v1.3 and licensing requirements (isleofmangsc.com). Alderney: AGCC legislation and Schedule 4 (gamblingcontrol.org).
• Malta: MGA Directives 2/2018 and 3/2018; MGA DLT Policy (2023). Italy: Legislative Decree 41/2024; technical rules TRIS 2024/0405/IT. Greece: Ministerial Decision 79835/2020; HGC AML Regulation 554/5/2021. Cyprus: Betting Law 37(I)/2019; NBA Directives 3.2020 and 15.2024 (nba.gov.cy).
• Portugal: Decree-Law 66/2015 and SRIJ instructions (srij.turismodeportugal.pt). Spain: Ley 13/2011 and DGOJ data-model resolutions (boe.es; ordenacionjuego.es). France: ANJ AML reference framework (anj.fr).
• Netherlands: Besluit kansspelen op afstand; Ksa CDB guidance (kansspelautoriteit.nl). Belgium: Gaming Commission player-protection rules (gamingcommission.be). Germany: GlüStV 2021 §§6a–6j; GwG §16; LUGAS technical guideline. Austria: bill 594 d.B. (parlament.gv.at). Switzerland: ESBK and fedpol guidance.
• Denmark: executive orders 682/2025 and 684/2025. Sweden: Spellag 2018:1138 and SFS 2026:90 (riksdagen.se). Norway: Pengespilloven 2022 (lottstift.no). Finland: new Gambling Act (finlex.fi). Estonia: EMTA guidance (emta.ee). Latvia: Gambling and Lotteries Law (likumi.lv). Lithuania: Gaming Law (lpt.lrv.lt).
• Romania, Bulgaria, Hungary, Poland, Czech Republic, Slovakia: CMS Expert Guide to Gambling Laws in CEE; njt.jog.gov.hu; hazard.mf.gov.pl; mf.gov.cz; slov-lex.sk. Serbia: uis.gov.rs rulebooks. Croatia: Games of Chance Act (zakon.hr; narodne-novine.nn.hr). Montenegro: Law on Games of Chance 2025 (sluzbenilist.me).
• Ukraine, Georgia, Armenia, Azerbaijan, Kazakhstan, Uzbekistan: matsne.gov.ge; lex.uz; MONEYVAL mutual evaluation reports (rm.coe.int); national regulator notices.
• United Arab Emirates: GCGRA policy paper and Cabinet Resolution 134/2025 (gcgra.gov.ae). India: Promotion and Regulation of Online Gaming Act 2025 (egazette.gov.in). Philippines: PAGCOR and BSP notices.
• South Africa: National Gambling Act 2004; FIC guidance. Malawi: Gaming and Lotteries Act 2022; Money Laundering Regulations 2020. Kenya: Gambling Control Act 2025; draft regulations 2026 (gra.go.ke). Nigeria: Supreme Court SC/1/2008; LSLGA notices. Ghana, Botswana, Zimbabwe, Eswatini, Lesotho, Angola, Tanzania, Uganda: regulator and FIU sites; CMS Expert Guide to Gambling Laws in Africa.
• Curaçao: National Ordinance on Games of Chance (2024); CGA AML/CFT Regulations (2025); CGA crypto policy guideline (2026). Brazil: Law 14,790/2023; SPA/MF Ordinances 615, 722, 827, 1,143 and 1,231 of 2024; SIGAP manual. Argentina: UIF Resolution 194/2023; IPLyC Resolution 791/2019.
• Colombia: Coljuegos Acuerdo 04/2016 and technical resolutions. Peru: Law 31557 and DS 005-2023-MINCETUR; Res. SBS 03622-2025. Mexico: Reglamento de la Ley Federal de Juegos y Sorteos; SAT Annex 17. Chile: Senate bill on online betting platforms. Panama: MEF–JCJ resolutions.
• Canada: AGCO Registrar’s Standards for Internet Gaming; FINTRAC guidance and reporting API; BC Gaming Control Act. United States: N.J.A.C. 13:69O (nj.gov); 31 CFR Part 1021 (ecfr.gov).

Annex C.Example records#

Synthetic records with illustrative values, abbreviated. They show the shape of the data and are not drawn from any operator.

Card deposit (R3), with holder match and limit check:

{
  "tx_id": "D-2026-104511",
  "player_ref": "P-20931",
  "player_ref_scope": "licence-A",
  "direction": "deposit",
  "rail": "card",
  "instrument_id": "I-77812",
  "provider_id": "PSP-03",
  "rail_reference_type": "acquirer_reference",
  "rail_reference": "74987506291000123456789",
  "amount": "150.00",
  "currency_or_asset": "EUR",
  "amount_reporting_ccy": "150.00",
  "initiated_at": "2026-11-04T19:02:11+01:00",
  "credited_at": "2026-11-04T19:02:14+01:00",
  "credited_amount": "150.00",
  "ledger_entry_ref": "L-552019",
  "check_ids": [
    "C-90211",
    "C-90212"
  ],
  "limit_check": "within_limit",
  "outcome": "accepted"
}

Mobile money deposit (R3), with a tax line and an authority reference:

{
  "tx_id": "D-2026-339120",
  "player_ref": "P-55102",
  "direction": "deposit",
  "rail": "mobile_money",
  "instrument_id": "I-MM-0931",
  "provider_id": "MMO-01",
  "rail_reference_type": "operator_receipt",
  "rail_reference": "TJK4X9ZQ2L",
  "authority_reference": "CMS-20261104-0081734",
  "amount": "1000.00",
  "currency_or_asset": "KES",
  "credited_at": "2026-11-04T20:15:09+03:00",
  "credited_amount": "950.00",
  "tax_lines": [
    {
      "type": "excise_on_deposit",
      "rate": "0.05",
      "amount": "50.00",
      "authority": "tax_authority",
      "due_at": "2026-11-05",
      "remittance_ref": "TR-20261105-01"
    }
  ],
  "ledger_entry_ref": "L-881204",
  "check_ids": [
    "C-71820"
  ],
  "outcome": "accepted"
}

Instant-payment withdrawal (R4), with closed-loop evidence and payout timing:

{
  "tx_id": "W-2026-220871",
  "player_ref": "P-31007",
  "direction": "withdrawal",
  "rail": "bank_transfer",
  "instrument_id": "I-77990",
  "rail_reference_type": "instant_payment_e2e_id",
  "rail_reference": "E1234567820261104193512345678901",
  "amount": "420.00",
  "currency_or_asset": "BRL",
  "requested_at": "2026-11-04T19:30:02-03:00",
  "approved_by": "rule:auto-payout-v4",
  "approved_at": "2026-11-04T19:30:05-03:00",
  "paid_at": "2026-11-04T19:35:12-03:00",
  "destination_rule": "same_instrument",
  "source_instrument_ids": [
    "I-77990"
  ],
  "check_ids": [
    "C-91002"
  ],
  "outcome": "accepted"
}

Virtual-asset deposit (R3), under a pooled provider wallet — no hash exists, so the provider reference is the anchor:

{
  "tx_id": "D-2026-000512",
  "player_ref": "P-1190",
  "direction": "deposit",
  "rail": "virtual_asset",
  "instrument_id": "I-VA-2210",
  "provider_id": "VASP-01",
  "rail_reference_type": "provider_reference",
  "rail_reference": "INV-77120-AA",
  "amount": "250.000000",
  "currency_or_asset": "USDT-ERC20",
  "off_chain_movement": true,
  "credited_at": "2026-11-04T10:12:44Z",
  "credited_amount": "250.00",
  "check_ids": [
    "C-77401"
  ],
  "outcome": "accepted",
  "attestation_ref": "ATT-2026-11-VASP1"
}

Coverage statement (R7), daily:

{
  "statement_id": "COV-2026-11-04-LIC-A",
  "kind": "coverage",
  "period_end": "2026-11-04T23:59:59+01:00",
  "player_balances_total": "1840220.15",
  "pending_withdrawals_total": "61200.00",
  "open_bets_total": "88415.40",
  "player_liability_total": "1989835.55",
  "funds_held": {
    "segregated_account": "1902400.00",
    "guarantee": "150000.00"
  },
  "in_transit_total": "41880.10",
  "shortfall": "0.00",
  "prepared_by": "finance_ops",
  "reviewed_by": "compliance_officer"
}

Annex D.Conformance declaration (template)#

For signature by the operator’s responsible officer.

Annex E.Glossary#

Annex F.Differences from the Curaçao edition#

End of draft. Corrections to any profile are especially welcome: the Standard is only as good as the authorities’ reading of it.