For operators, payment providers and auditors
Prove good controls once — for every licence
Build your payment evidence once, in an open format, and apply each licence’s profile to it. Then show any payment end to end, from deposit to statement, in one evidence pack.
Why adopt
Today, good controls cost as much to prove as bad ones
An operator that has implemented its controls well cannot prove it more cheaply than one that has not. CTRES changes the arithmetic.
One format across licences
The same twelve record types serve every licence; only the profile applied to them changes. In federal and provincial systems — Argentina, Bosnia and Herzegovina, Canada, Nigeria, South Africa, the United States — the same facts no longer need as many shapes as there are licensing bodies.
Cheaper audits
An auditor can sample directly from evidence 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, irrespective of supervision (§9).
Fewer bespoke integrations
More than half of the jurisdictions reviewed run, or are building, a central system, data vault or state register. Records carry the references those systems issue, so each submission is produced from one source (§7).
What is in it for you
Three roles, one shared record
Operators
Online and, where an authority so chooses, retail and land-based.
- Build once, apply each licence’s profile. Thresholds, windows and deadlines live in the profile; your records carry the raw facts.
- Start where you are. Level 1 allows manual assembly on request; Level 3 generates records as events occur (§10).
- Pseudonymous by default. Periodic packages carry no names, addresses or identity documents (§12).
- Corrections without rewriting history. A new package supersedes an earlier one by identifier and reason (§8.2).
Payment providers
Acquirers, banks, payment service providers, e-money institutions, mobile money operators, voucher issuers, virtual-asset service providers and cash agents.
- Your reference is the anchor. Acquirer reference, end-to-end instant-payment ID, operator receipt, voucher serial or transaction hash ties each record to your statements.
- Provider attestation (R11). Where money sits in your pooled account, your signed statement of balance and totals stands in for the operator’s own statements (§4.11).
- The checks you offer count. Issuer name checks, account-name checks, mobile operator KYC and signed messages are recognised holder-verification methods.
- One due-diligence record. R10 holds your authorisation, licence reference, review dates, data location and, for virtual assets, Travel Rule capability.
Auditors and compliance teams
External auditors, agreed-upon-procedures engagements and in-house compliance.
- Sample from evidence packs. The deposit, the checks that preceded crediting with timestamps that prove the order, the payout, statements and exceptions (§9).
- Computed, not declared. Where a fact can be derived from other records, validation derives it instead of trusting a flag (§3).
- Reconciliation as a number. Location statements state the unexplained delta; a coverage statement sets liabilities against funds held (§4.7).
- Reproducible results. A package tested against named suite and profile versions can be tested again later (§11).
Conformance levels · §10
Proportionate: comply with files, or with an interface
Three levels let a small operator comply with files and a large one with an interface. An operator declares its level in the conformance statement at Annex D.
- Level 1
Records
Every record type applicable under the operator’s profile can be produced on request, within the profile’s deadline, in CSV or JSON, with a manifest.
Typical operatorSmall operator; manual assembly permitted
- Level 2
Structured
Periodic packages are submitted on the profile’s cadence in the defined format and pass structural and referential validation.
Typical operatorMost operators
- Level 3
Continuous
Records are generated as events occur, exceptions are tracked to closure with ageing, and the authority may pull a period on request.
Typical operatorLarge or multi-licence operator; operators connected to a central system
How to start
From reading to a validated package
Read the record model
Twelve record types in §4, rail modules in §6, example records in Annex C.
Get the JSON Schema
Records R1–R12, the manifest and the structure of a profile, under the Apache License 2.0: ctres-standard/schema.
Validate a package
Install validator-lite and run it on the synthetic demonstration package, then on your own.
Join a pilot
Q1 2027, with volunteer operators across at least three rail mixes. Tell us your rails.
Beyond structure: the conformance suite
Profile-conformance and completeness checks depend on parameters each authority sets, so they are maintained separately as a versioned conformance suite. It can be made available to authorities for evaluation and to operators for self-checking before submission. It is not a condition of using the Standard.
Pilots · Q1 2027
Test CTRES on your own rails
Pilots run with volunteer operators across at least three rail mixes. Tell us which rails you use and which jurisdictions you are licensed in.
Cards and bank transfers
Acquirer settlement reports, bank statements and instant-payment confirmations as external evidence.
Mobile money
Hashed phone numbers and operator receipts; mobile operator statements and tax-integration records where they exist.
Virtual assets
On-chain data and provider attestations for pooled wallets — carried forward from the Curaçao edition.