For regulators and supervisors
Evidence in one shape, through the channels you already run
CTRES gives operators one way to evidence payment flows, under the rules your authority sets. It adds no obligation and no channel. It asks one thing of you: check that your jurisdiction’s profile is right.
What CTRES gives you
Evidence over assertion
A control is reported as the record it produced, with a timestamp and an actor — not as a statement that the control exists.
Your rules, as parameters
Thresholds, aggregation windows, payout deadlines, permitted rails, coverage and retention are parameters of your profile — never constants in the format (§5).
Your channels, unchanged
goAML and national reporting APIs, central systems, data vaults and tax feeds stay as they are. CTRES is the operator-side source they are produced from (§7).
One payment, end to end
On request, an evidence pack per player, per transaction or per period: deposit, prior checks with timestamps, crediting, payout and statements (§9).
Player funds you can check
A coverage statement sets total player liabilities against the funds held to meet them, with any shortfall and when it was cured (R7).
Gaps you can see
A control that left no record is reported as
not_recorded, and anything that did not reconcile is listed with its value, age and owner (R8).Proof of what was submitted
Every package carries a SHA-256 hash per file; the hash of
manifest.jsonis the package fingerprint. A receipt that quotes it proves which package was submitted (§8.2).
Submission and access · §8
Your profile chooses the mode. None of them adds a channel.
- 01
Continuous
Where the authority runs a central system or requires real-time access
Records are generated as events occur. The authority’s system remains the channel; CTRES is the operator-side source and audit trail.
- 02
Periodic package
On the profile’s cadence — monthly, quarterly or semi-annual
R1, R7, R8, R10 and R11, with the conformance declaration; R2 to R6 as a full extract or a sample, as the profile sets
- 03
On demand
Within the profile’s deadline for information requests
The evidence pack (§9), per player, per transaction or per period
- 04
Incident
Within the profile’s incident deadline
R9, with the affected records referenced by identifier
Where CTRES feeds what you receive today
| Destination | What it receives today | CTRES source |
|---|---|---|
| Financial intelligence units (goAML and national equivalents) | Suspicious and threshold reports in the unit’s own schema | R3, R4 and R5 populate transactions and parties; profile windows drive aggregation; R12 keeps the receipt |
| FINTRAC (Canada) | Large cash, large virtual currency, casino disbursement and suspicious transaction reports through a JSON API | R3 and R4 with the 24-hour rule applied by the profile; R12 keeps the receipt |
| SIGAP (Brazil) | Signed XML files, daily and monthly | R3 and R4 feed the wallet-movement files; R12 keeps the file receipts |
| Central control systems (e.g. Italy, Greece, Bulgaria, Serbia, Ukraine, Kenya) | Transaction data in real time, in the authority’s protocol | authority_reference on R3 and R4 links each payment to the code the central system issued |
| Data vaults and safe servers (e.g. Netherlands, Denmark, Germany, Spain, Romania) | Account and transaction records in the authority’s schema, XML or JSON | R3 and R4 map to the vault’s payment records; R12 keeps the seal or upload receipt |
| Central limit files, registers and state hubs (e.g. Germany, Czech Republic, Kazakhstan, Uzbekistan) | A query before each deposit or bet, and the hub’s transaction identifier | R5 records each query and response, performed by the authority system; authority_reference carries the hub identifier |
| Tax-authority feeds (e.g. Mexico, Kenya, Uganda, Ghana) | Transactions and taxes, in real time or daily | tax_lines on R3 and R4; R12 keeps remittance receipts |
| Player-funds reporting (e.g. Malta’s monthly report; annual agreed-upon procedures in several jurisdictions) | Balances, liabilities and supporting statements | R7 coverage statement, with evidence references |
| Periodic regulatory returns (e.g. United Kingdom, Gibraltar) | Aggregated figures | Derived from R3, R4 and R7 |
From §7. The mappings are indicative; detailed mappings are maintained separately, versioned, and tested against each destination’s own schema wherever that schema is public.
What we ask
Review your jurisdiction’s profile
The 67 profiles published with this draft are researched from published sources as at 2 October 2026. Your review turns a researched profile into an authority-confirmed one.
Find your jurisdiction
Profiles are grouped by region on the profiles page: permitted rails, closed-loop rules, thresholds, player-funds protection, reporting and retention. Principal sources are listed in Annex B.
Tell us what is wrong or missing
State the parameter, the correct reading and the published source — with “Correct this profile” on the row, the contact form, or hello@ctres.org.
It is adopted as submitted
Corrections an authority makes to its own profile are adopted as submitted. A profile is published as confirmed only when the authority concerned has reviewed it.
- 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
Consultation · §15
10 questions for authorities
Each answer changes the Standard materially. Answer one or all of them — by email or through the form.
- 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?
Timeline · §14
Authority review comes first
Version 1.1 will carry authority-confirmed profiles alongside the researched ones.
- 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