Open standard Draft for consultation Free to implement
One evidence format for every payment rail and every regulator
CTRES — the Common Transaction Reporting and Evidence Standard — lets gambling operators evidence payment flows to regulators in one shape: built once, applied under each jurisdiction’s own profile, delivered through the channels authorities already run.
- 67jurisdictions researchedPublished rules on five continents (Annex B)
- 12record typesR1–R12: from funds locations to report references
- 7payment railsCards to cash to virtual assets, one module each
- 0 US dollars, euros or any other currencylicence feesText CC BY 4.0 · schema and validator Apache 2.0
Why CTRES exists
Every regulator asks the same five questions about money
Each asks in its own format, on its own calendar and through its own channel. Across the 67 jurisdictions reviewed, the questions are the same. What differs is a small set of parameters.
- 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?
- An operator licensed in several jurisdictions rebuilds the same evidence for each — in federal and provincial systems, 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 register. Each defines the operator-side data afresh, so every connection is a bespoke integration.
- An operator that has implemented its controls well cannot prove it more cheaply than one that has not.
- The evidence is built once, as twelve record types, and each licence’s profile is applied to it.
- Records carry the references that rails and regulators’ systems issue, so existing submissions are produced from a single source.
- Good controls become cheap to prove: one payment, end to end, in an evidence pack.
How it works
Map, don’t replace
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.
Record
Capture payment evidence as twelve record types, R1–R12: one line of JSON per record, one file per record type and period, on any rail.
Apply the profile
The jurisdiction profile supplies the parameters — permitted rails, thresholds, aggregation windows, payout deadlines, coverage, retention. It never adds fields.
Package and fingerprint
manifest.jsonlists the licence, profile version, period, record counts and a SHA-256 hash per file. Its own hash is the package fingerprint.Deliver through existing channels
FIU reporting, central systems, data vaults, tax feeds. On request, an evidence pack shows one payment end to end.
1 Your systems
- Payment providers and railsAcquirers, banks, e-money and mobile money operators, vouchers, cash, chains
- Player accounts and ledgerBalances, credits, debits, payouts
- Checks and registersIdentity, sanctions, exclusion, limits, source of funds
- Treasury and statementsFunds locations, sweeps, provider balances
2 One CTRES source
Records
- R1
- R2
- R3
- R4
- R5
- R6
- R7
- R8
- R9
- R10
- R11
- R12
Twelve record types, one line of JSON each
Jurisdiction profile
- Permitted rails
- Thresholds and windows
- Payout deadlines
- Player-funds coverage
- Submission mode
- Retention
Parameters only — never new fields
3 Existing channels
- FIU reportinggoAML and national equivalents
- Central control systemsReal-time, in the authority’s protocol
- Data vaults and safe serversRecords in the authority’s schema
- Tax-authority feedsTaxes levied or withheld at payment
- Player-funds reportsCoverage of player liabilities
- Evidence pack, on requestOne payment, end to end
Who it is for
One format, four audiences, one shared record
Everyone who touches payment evidence in regulated gambling works from the same twelve record types.
Regulators and supervisors
- Your profile, your rules. Authorities own their profiles; corrections are adopted as submitted.
- Your channels stay. goAML, central systems and data vaults keep working; CTRES is the source they are fed from.
- One payment, end to end. Ask for an evidence pack per player, transaction or period.
Operators
- One format across licences. Build the evidence once; apply each licence’s profile.
- Cheaper audits. An operator that can produce evidence packs in minutes rather than weeks reduces the cost of its own audit (§9).
- Proportionate. Three conformance levels, from files on request to continuous records.
Payment providers
PSPs, banks, e-money, mobile money, VASPs
- Your references, end to end. The rail reference you issue ties each payment to your statements.
- Provider attestation (R11). Where money is pooled with you, your signed statement stands in for the operator’s own.
- Due diligence in one shape. R10 records your authorisation, licence and review dates.
Auditors and compliance teams
- Sample from evidence packs. Deposit, prior checks, payout and statements, in order.
- Gaps are visible. A control that left no record is reported as
not_recorded, not omitted. - Verifiable packages. A SHA-256 hash per file; the manifest’s hash fingerprints the package.
Rail-neutral by design
Seven rails. Twelve record types. One model.
Fields common to every rail live in the core records; fields that exist on one rail only live in its module. A jurisdiction that does not permit a rail leaves it out of its profile — nothing else changes.
- CardTokenised card number, BIN, funding type, acquirer reference
- Bank transfer and instant paymentsSEPA, Pix, Interac and others: masked account, end-to-end ID
- E-money and e-walletsWallet account identifier, funding-source type
- Mobile money and carrier billingHashed phone number, pay-bill code, operator receipt
- Vouchers and prepaidVoucher serial, issuer, point of sale
- Cash at retail or venueRetail point or cage, cashier, receipt
- Virtual assetsChain, asset, transaction hash, address
The record model, by the question each record answers
Where is the money, and is it all there?
- R1Funds LocationWhere does the operator hold money, for what purpose, and under what protection?
- R7Reconciliation StatementDo the books match the external statements, and are player liabilities covered?
- R11Provider AttestationWhere the operator cannot see the money directly, what does the provider certify?
Whose money is it, and was it checked first?
- R2Payment Instrument LinkDoes this instrument belong to this player, and may it receive payouts?
- R5Check DecisionWhich control ran, before which event, with what outcome?
What moved, when, and how?
- R3DepositWhat came in, from which instrument, when was it credited, and what was checked first?
- R4WithdrawalWhat went out, to which instrument, who released it, and how quickly?
- R6Internal MovementDid money move between the operator’s own locations, and was segregation kept?
Who handled it, what went wrong, who was told?
- R10Provider RegisterWho handles the money, under whose authorisation, after what due diligence?
- R8ExceptionWhat could not be explained, for how much, for how long, and who owns it?
- R9IncidentWhat happened that an authority must be told, and when was it told?
- R12Report ReferenceWhich reports were filed elsewhere, triggered by which records, against which deadline?
Jurisdiction profiles · Annex B
67 jurisdictions. Is yours right?
A profile turns the neutral record model into one authority’s rule set: permitted rails, thresholds and windows, payout deadlines, player-funds protection, submission mode and retention.
- Readings of published sources as at 2 October 2026, in 4 regions.
- Open for review by every authority — each profile is offered to the authority concerned.
- Corrections are adopted as submitted. Profiles belong to the authorities.
- 35EuropeView profiles: Europe
- 9Eurasia, Middle East and AsiaView profiles: Eurasia, Middle East and Asia
- 12AfricaView profiles: Africa
- 11The Americas and the CaribbeanView profiles: The Americas and the Caribbean
Researched from published rules Confirmed by the authority
Open by design
Free to read, free to implement, no vendor required
Any operator, supplier or authority may implement CTRES without fee or permission. The editor maintains the text, the schema, the register of profiles and the conformance suite, and publishes versions. Substantive changes are published for comment before adoption.
- CC BY 4.0
The text
Copy, adapt and redistribute, including commercially, with attribution.
Read online - Apache 2.0
JSON Schema
Records R1–R12, the package manifest and the structure of a jurisdiction profile.
ctres-standard/schema - Apache 2.0
validator-lite
Structural and Referential validation of a package, installable with pip.
Run the validator - None required
No vendor
CTRES names no vendor and requires none. Implement it without fee or permission.
Governance
Roadmap
Governance and versioning- October 2026CTRES v1.0, universal edition, published as a draft for consultationYou are here
- Q4 2026Authorities review their profiles; corrections adopted as submittedAuthorities, editor
- Q1 2027Pilots with volunteer operators across at least three rail mixes: cards and bank transfers; mobile money; virtual assetsOperators, editor
- Q2 2027Version 1.1 with confirmed profiles, versioned mappings to existing formats, and the conformance suite versioned alongsideEditor
- From July 2027Alignment review as the EU Anti-Money Laundering Regulation (EU) 2024/1624 begins to applyEditor, with EU authorities
Questions
Frequently asked
Is CTRES mandatory?
No. CTRES creates no obligation. It formats evidence of duties that already exist under each jurisdiction’s law and licence conditions, and it carries no regulatory force.
Does it replace goAML or our central system?
No — map, don’t replace. CTRES does not replace any authority’s central system, reporting portal or financial intelligence reporting schema. It is the operator-side evidence layer from which those submissions can be produced, and records carry the references those systems issue (§7).
Who owns the jurisdiction profiles?
What is the status of CTRES?
CTRES v1.0 is an independent open standard, published as a draft for consultation with authorities and industry. Authorities review their profiles in Q4 2026, pilots with operators follow in Q1 2027, and a working group of authorities and practitioners is convened once three authorities have reviewed their profiles (§13, §14).
What does it cost?
Nothing to implement. The text is licensed under CC BY 4.0; the JSON Schema and validator-lite under the Apache License 2.0. The conformance suite for profile-conformance and completeness checks is available on request (request access). No validator is a condition of using the Standard.
Do packages carry player identities?
No. Periodic packages carry pseudonymous player references, masked account numbers and hashed phone numbers. Identity data is provided only in an evidence pack answering a specific lawful request, under the same arrangements as existing regulatory correspondence (§12).
How do I comment?
Open an issue on github.com/ctres-standard/spec, citing the section or annex, or write to hello@ctres.org. Authorities can correct their own profile from the profiles page. Substantive changes are published for comment before adoption.
Read it, correct it, try it.
CTRES improves with every authority that reviews its profile and every operator that tests it on real rails.