A gambling transaction history is a record of account movements and gambling activity over a stated period. For a complaint, arrange those records into a timeline that preserves the original timestamps, references and status descriptions. The timeline should show what each source establishes and what still needs an answer.
A balance screenshot can show what appeared on a screen. It cannot, by itself, explain an earlier deduction or prove that a withdrawal reached a bank. This guide provides a working format for customers and the support teams reviewing their evidence. The example is invented; the British and Maltese sources were checked on 26 October 2026. It does not decide a claim or replace legal advice.
Collect the account history before interpreting it
Start with the exact website, legal operator, account reference, currency and disputed period. Save the applicable terms alongside the records. A brand can use another company's operating licence, so address the complaint to the business identified in the customer contract. The white-label gambling guide explains that distinction.
For gambling covered by Great Britain's remote technical standards, UK Gambling Commission RTS 1B sets two access requirements. Customers must be able to review a minimum three-month account and gambling history easily, without asking the business. On request, the business must provide at least 12 months as soon as practicable. Neither provision sets a universal complaint deadline or a worldwide record-retention rule.
The standard covers relevant account credits and debits, bets and results, winnings, and product transfers. Gaming information can be full or summarised, subject to its minimum requirements. It does not promise every customer a particular CSV format or a complete supplier log. If the visible history lacks the disputed round, identify it and ask for the relevant detail rather than assuming the summary proves an error.
Save the original download or message unchanged. Make a separate working copy for annotations and necessary redactions. Record when you obtained each item, the date range selected and any displayed time zone. If the site offers only an on-screen history, capture the period and surrounding entries, not just the line you dispute.
Give each event a source, a clock and a reference
Use one row per observed event. A withdrawal request, an operator status update and a bank credit belong on separate rows even when they concern the same amount. Include these fields in a spreadsheet or document:
- The source file and page, message or transaction reference that locate the evidence.
- The date and time exactly as displayed, including the stated zone or UTC offset.
- A separately calculated UTC time, or an explicit note that the zone is unknown.
- The event description, currency and amount, with the source's status wording unchanged.
- The resulting account entry, any linked reference and the specific point still disputed.
Keep the capture time separate from the event time. A screenshot taken on Monday may display a payment requested on Friday. If an email says only "yesterday", retain the email's own date and zone; do not silently replace the relative wording with a guessed timestamp.
When two systems use different identifiers, keep both and ask the operator to explain the connection. Equal amounts and nearby times are a possible match, not proof that two records describe the same payment. A later correction also needs its own row and a link to the entry it changes.
A fictional gambling transaction history in two time zones
Assume a cash account already contains £40. On 1 October 2026, a £20 deposit raises it to £60. The customer then requests a £25 withdrawal. This invented operator export expressly shows £35 available and £25 pending after the request. That split is an assumption of the example, not a rule for every wallet.
The account export explicitly uses UTC+02:00. The bank screen explicitly uses UTC. The short EX labels below are invented evidence-file labels, not real transaction numbers. There are no bets, bonuses, fees, conversions or other movements in this example.
| Evidence item | Original record time | UTC comparison | What the record shows | What remains unresolved |
|---|---|---|---|---|
| EX-A01, account export | 1 Oct 2026, 12:00 UTC+02:00 | 1 Oct, 10:00 UTC | £20 deposit credited; £60 available | No dispute about this entry |
| EX-A02, account export | 1 Oct 2026, 12:15 UTC+02:00 | 1 Oct, 10:15 UTC | £25 withdrawal requested; £35 available and £25 pending | Whether and when a payment was sent |
| EX-M01, operator email | 1 Oct 2026, 10:20 UTC | 1 Oct, 10:20 UTC | Email describes the withdrawal as "processed" | Meaning of that status and external payment reference |
| EX-B01, bank-history capture | Captured 1 Oct 2026, 10:25 UTC | Observation at 10:25 UTC | No matching credit in the displayed period | Whether a later credit or a return will appear |
The email follows the withdrawal request by five minutes, not precedes it by almost two hours. Subtracting the stated two-hour offset puts both on the same clock. Where a record supplies no zone, leave its UTC field unresolved until the source confirms it; the viewer's current location is not evidence of the system's setting.
The £25 has moved out of available cash in our assumed export. The bank capture shows no matching receipt at its observation time. Neither statement establishes that the transfer failed. The useful question is: what event does "processed" describe, and which external reference connects it to the requested withdrawal?
Preserve uncertainty instead of filling the gaps
Copy status words before adding an interpretation. "Requested", "approved" and "paid" may describe different events, but their meaning depends on the system that produced them. Ask for the relevant definition and supporting record. A support email is evidence of what the business said; it is not automatically a bank receipt.
Keep currency and amount types explicit. A stake, gross winning return, withdrawal and fee are different entries. If an account has both cash and bonus balances, record the buckets shown rather than combining them into an unexplained total. For the operator's separate accounting task, the casino wallet reconciliation guide follows wallet, provider and bank records through a worked bridge.
Write a factual observation beside an unanswered question. "No credit appears in the bank view captured at 10:25 UTC" describes the evidence. Calling the withdrawal stolen would add an allegation that this record does not establish. An incomplete export, missing zone or unexplained reference should remain visible in the file.
Send a short complaint with an evidence index
The Gambling Commission's complaint guidance directs customers to the business's procedure and asks for dates, times, amounts and supporting evidence. It also tells customers to retain copies of what they send. Put the disputed transaction and the outcome sought at the start of the message, then attach the chronology and an index locating the relevant records.
For the fictional case, a concise request would identify EX-A02, quote the email's "processed" wording and ask the operator to explain the payment stage, reference and pending balance. The requested outcome could be a trace and an explanation of the account treatment. It should not presume a refund is due before the payment outcome is known.
For a complaint within the Malta Gaming Authority's remit, its current complaint form asks for the operator, website, account alias, disputed amount, incident date and time, among other information. It accepts English or Maltese and strongly recommends trying the operator first. Those fields illustrate why a clear chronology helps; they do not make every gambling complaint eligible for the MGA channel.
Send records through the recipient's verified, stated channel. Keep originals private and use proportionate copies that retain the identifiers needed to investigate. Never include a password, one-time login code, card security code or wallet recovery phrase. If legitimate identity evidence is requested, check the recipient and purpose; the KYC guide explains why verification requests need their own context.
Frequently asked questions
Does a balance screenshot prove a missing payment?
It records the balance displayed when captured, but may not identify the movement being disputed. Keep the account-history entry, original timestamp and transaction reference with it. Compare a withdrawal with the relevant bank or payment record, and distinguish an absent credit at one observation time from a confirmed failed transfer.
Can I convert every timestamp to my local time?
Keep the source timestamp unchanged and put conversions in a separate field. Convert only when you know the source's zone or offset for that date. Otherwise label the conversion unresolved. Record when you captured the evidence separately, because a screenshot's creation time may differ from the transaction time it displays.
How much gambling history should a British account provide?
For activity covered by UKGC RTS 1B, customers must have easy access to at least three months without contacting the licensee, and at least 12 months on request, provided as soon as practicable. Those access windows do not set the deadline for a complaint or establish identical rights in other markets.
Leave the reviewer with a precise question
A useful gambling transaction history lets someone find the same entry, reproduce the time comparison and identify the missing explanation. Before sending it, check that every conclusion points to evidence and every uncertainty is labelled. Keep the sent message and receipt with the file; the Great Britain complaints and ADR guide covers that market's separate escalation route.