Casino transaction history: follow the balance one movement at a time

Use a consistent period and currency

Choose the start and end of the period before comparing totals. A bank statement month and an operator’s seven-day report are not the same window. Time zones and the status date can also place a movement on a different displayed day.

Keep the account currency with every amount. If a bank converts a payment, retain the bank’s original and converted amounts separately. Do not force two currencies into one sum without recording the conversion basis.

Read the entry type before adding it

Deposits and withdrawals concern transfers across the account boundary. Stakes and returns concern game activity inside it. Adding all four columns as spending would double-count movements and can reverse the meaning of a return.

The example below is hypothetical. It assumes a single cash balance, completed entries only, no fees and no bonus balance. Real histories may show additional components that must be reconciled separately.

Do not count a pending request twice

An operator may reserve requested withdrawal funds before the external transfer completes. Read how that reservation is represented in available balance and history. The request and its completion can be stages of one movement, not two independent withdrawals.

Use the transaction reference to connect related events. If support refers to another reference, ask for the relationship between them. This is more useful than inferring payment progress from the balance figure alone.

What access should the account provide?

RTS 1 requires customers to have easy access to at least three months of account and gambling history without contacting the operator. It also addresses access to current balance information while logged in.

That minimum access period does not mean older records never exist. If you need a longer period or a different format, ask the operator what it can provide. Do not state a universal retention period from the three-month access requirement.

Keep the detail relevant to the question

For a missing or disputed entry, save the date, type, amount, currency, status and reference. Retain the support response that explains the movement. A broad screenshot of an entire account can disclose more personal information than the issue needs.

For a spending review, compare deposits, withdrawals and game results using their own definitions. A net-deposit figure and a game-loss figure can differ when opening or closing balances are present. Neither number is a recommended budget.

Use records to support an explanation, not a new transaction

Do not make another payment merely to test whether the old one appears. Ask for reconciliation of the existing reference. If the record contains an inactivity charge, obtain the applicable fee notice and calculation rather than treating it as an unexplained gambling loss.

Keep account records private. Redact full card numbers, voucher codes, identity images and unrelated personal details before sharing any report. This publication cannot access an operator ledger or settle an individual balance dispute.

Decide which question the history needs to answer

Account records can support several tasks: locating one missing deposit, checking a withdrawal, reviewing spending, explaining a fee or requesting remaining money after an access restriction. Choose the task before exporting or adding figures. A missing-payment enquiry needs a specific reference and stage, while a spending review needs a consistent period and opening and closing balances. Collecting every available number without a question can produce a large file that still leaves the relevant event unidentified.

To investigate a missing £35 credit, start with the attempted payment's date, currency and reference. In that illustrative enquiry, the yearly deposit total cannot show whether this particular attempt reached the account. A monthly spending review has a different aim: the same £35 would be one movement among many. Decide which task you are doing before preparing the summary. One calls for a matched reference; the other calls for a reconciled period with enough information to explain its opening and closing balances.

Write the question in one sentence before reviewing the file. If the question changes, keep the new calculation separate. This prevents a search for a missing withdrawal from silently becoming a claim about all historical losses, or a spending review from being treated as proof of a payment error. A record can support more than one analysis, but each analysis needs its own definitions and evidence.

Match the opening balance to the period

The opening balance is the starting point for the account calculation. It should refer to the beginning of the selected period and the same balance component used at the end. A current available-cash figure cannot substitute for an earlier opening total, and a screenshot taken midway through the interval needs its date retained. If the starting figure is unknown, ask for it or identify the limitation instead of inventing a zero balance.

Start an illustrative period with £40, then add a £25 deposit. On a simple cash-only basis, £65 is present before anything else happens. Starting at zero instead would leave only £25 explained and turn the original £40 into a mystery created by the calculation. This is why the opening figure matters as much as later transfers. The example assumes no other components; a real account may contain bonuses, open bets, pending requests or adjustments that need identifying separately before you total them.

If the account provides several components, record each separately and ask how they relate. Available balance, money reserved for a request and another displayed component should not be combined without understanding the interface. The operator's explanation is the relevant source for its own presentation. Keep any support answer with the corresponding screenshot so a later calculation can reproduce the interpretation rather than relying on memory.

Use signs consistently when following the running balance

A running balance adds amounts entering the selected account component and subtracts amounts leaving it. In a simple cash ledger, a completed deposit increases the balance, a stake reduces it, a game return increases it and a completed withdrawal reduces it. The original table uses that convention. Before adding a downloaded file, check whether its entries are already signed or whether separate debit and credit columns need interpretation.

The signs can be illustrated with £50 at the start, a £20 deposit, a £5 stake, a £2 return and a £10 withdrawal. The calculation is £50 plus £20 minus £5 plus £2 minus £10, which gives £57. Misreading the £2 return as a deduction gives £53 and creates a false £4 gap. These amounts are invented and assume no other movements. Before changing a sign to make a total fit, establish what the exported label actually means and how it affects the selected balance.

Keep the source labels beside your interpreted signs. Do not overwrite the exported description with a simplified category until its meaning is clear. A private working column can record your interpretation while the original remains available. If one line is ambiguous, ask about that entry rather than changing signs until the total happens to match. A balanced sum is useful only when the classification of the movements is also justified.

Derive a game-result figure only under stated assumptions

For a simple cash account with no fees, bonuses, unresolved bets or adjustments, opening balance plus deposits minus withdrawals minus closing balance gives the amount lost through the remaining account activity. A negative result under that convention would indicate a net gain. State those assumptions and the sign convention clearly. The formula is not a universal shortcut for a real ledger containing components that have not been classified.

A simple illustration starts with £30, adds £80 in deposits, withdraws £25 and closes at £45. The remaining difference is £40: £30 plus £80 minus £25 minus £45. Under the stated assumptions, that is a £40 net game loss. Gross deposits are £80 and net deposits are £55. Each figure answers a different question, so label it when saving or sharing the calculation. None tells you what loss is affordable or supplies a budget for future gambling.

If a £3 fee also occurred, it needs its own treatment rather than being silently labelled a game loss. The remaining difference attributable to game activity under the amended example would be £37 after accounting for that fee. This is why a reconciliation should classify every non-game movement before presenting a net result. The calculation explains existing activity; it should not be used to justify further stakes or to plan recovery of past losses.

Check linked stages before removing apparent duplicates

A request, reservation, completion and correction can appear as separate observations about one movement. Equal amounts alone do not prove duplication, while different labels alone do not prove separate spending. Use references and the operator's explanation to connect the stages. Keep the original rows in the private file and create a summary only after their relationship is understood. Deleting an apparent duplicate too early can remove the evidence needed to explain the sequence.

Suppose a £45 withdrawal is reserved on request and later marked sent under a related identifier. Counting both rows as completed withdrawals gives £90. If the operator confirms that they are stages of one transfer, the completed movement is £45. This illustrates a counting risk without asserting that every account uses the same layout. Keep the labels and ask how the references connect before merging rows. A summary should follow that explanation, while the original observations remain available in the private file.

If two genuine requests exist, keep both even if they have the same amount and destination. Ask support which reference its answer concerns. A reply saying the withdrawal is complete cannot safely be applied to both without that link. Preserve any new trace identifier alongside the original request reference, with the explanation of how the two relate. This lets later replies from another organisation remain connected to the same movement.

Compare the bank and operator as separate ledgers

The bank records its own side of a payment, while the operator records the gambling account. The dates, labels and identifiers may differ. Match the operation using all the available non-secret details instead of assuming that identical amounts are sufficient. Keep bank-side entries and operator-side entries in separate parts of the private file, then note the relationship established between them. A single combined list can otherwise count the same transfer twice.

A £20 bank outflow and a £20 casino deposit may show opposite sides of the same transfer, rather than £40 spent. In this example, dates and references are needed to establish the connection. If the £20 operator credit is missing, the bank entry cannot identify its place in the operator ledger. Ask about the particular event and keep the reply. An assumed posting date would only fill the gap in your summary; it would not explain what either organisation actually recorded.

The same care applies to a withdrawal reaching a wallet and then moving to a bank. Those are separate legs with separate records. A wallet-to-bank receiving window should not be applied to the operator's earlier decision. The MiFinity guide provides a detailed example of this distinction. For the history review, the immediate task is to label each boundary crossing so the same value is not repeatedly counted as new gambling expenditure.

Retain currency instead of adding unlike amounts

An amount needs its currency. A provider entry in one currency and a bank receipt in another should be retained separately with the actual conversion information, if available. Do not add them into a single total merely because they belong to one payment journey. A later public exchange rate cannot establish the conversion used for an earlier request, and an approximate mental conversion may conceal a fee or rounding issue that needs a recorded explanation.

Imagine a record showing £40 on one side of a transfer and an amount in another currency on the other. Subtracting the printed numbers cannot establish a loss in that example. First obtain the conversion basis and any actual charge. Where confirmations supply them, keep requested amount, sent amount, fee and received amount as separate fields. An absent field should stay marked unknown until the organisation responsible for that part explains it. The apparent difference then remains a question supported by the original amounts.

For a single-currency spending review, exclude unrelated-currency entries from the sum until their treatment is defined. If you produce a converted summary for your own understanding, label the conversion basis and retain the original amounts. This keeps the summary from being mistaken for the provider's actual accounting record. The objective is an explainable calculation rather than a precise-looking total built from incompatible figures.

Investigate a gap by narrowing the unexplained movement

If the calculation does not match the closing balance, first check the selected dates, opening component, signs and entry statuses. Then identify which movement remains unexplained. Do not add an invented fee or game loss merely to make the total fit. A reconciliation difference is a question, not a category of spending. Keep the difference visible and ask for the entry or interpretation that explains it.

If you calculate a closing balance of £62 but see £59, the unexplained amount is £3. That illustrative gap could concern a fee, omitted stake, correction or error; its size does not identify the cause. Recheck the source entries and ask about the specific difference. If support supplies a £3 adjustment, keep its date and purpose alongside the record. Matching the arithmetic helps, but you still need to understand what the entry represents before giving the difference a category in your spending review.

Avoid using a new deposit as a diagnostic test. An extra payment changes the balance but does not identify the missing old movement. Likewise, a fresh wager can make the ledger harder to reconcile while adding risk. Ask about the existing record through the genuine support channel. The useful next action follows the unresolved line or field, without requiring a new transaction to make the question concrete.

Keep an inactivity charge separate from gambling results

A dormant-account deduction concerns administration and should be identified with its applicable notice and fee calculation. Do not fold it into a game-loss total simply because it reduces the balance. Retain the description, date and amount of each charge. The dormant-account guide explains how to ask about last activity, notice and frequency; the history review supplies the movement that needs that explanation.

Three £2 inactivity deductions would total £6. With no other unexplained movement, they would account for a £6 balance reduction in this simple example. That answers the calculation, not whether the charge met the guidance or was properly notified. Keep both questions in the record. The amounts can reconcile while the fee notice or terms remain disputed. This prevents a correct sum from being treated as a complete explanation of the basis for charging, or an unresolved notice from obscuring what the ledger actually adds up to.

If a charge is later corrected, retain the correction and the original line. A refund-like adjustment changes the later balance but does not erase the earlier observation. Recording the sequence allows a reader or support agent to understand why the displayed balance differed at the time of the enquiry. Do not rewrite the past file as if the charge never appeared; preserve the source and add the explanation alongside it.

Review access requirements without inventing retention rules

The existing RTS source addresses easy access to at least three months of account and gambling history without contacting the operator. That is an access requirement, not a universal statement that older records have been destroyed or must exist forever. If the needed period is not visible, ask the operator what it can provide and in which format. State the exact interval and type of record needed for your question.

An older inactivity-fee enquiry may need a last-activity entry beyond the history readily shown on screen. This example calls for a request naming the missing period and record. The current display cannot prove that earlier activity never happened. An email confirmation may help locate the interval, but it cannot supply a complete ledger by itself. Keep it for the event it establishes, then ask the operator what further record it can provide to answer the particular question about the balance or charge.

If account access is restricted because of a break or exclusion, ask for administrative records through genuine support without requesting renewed gambling access. The balance-return guide explains the related distinction. Access to a statement and access to games are different goals. A private record request can remain focused on existing money and dates while protective controls stay in place.

Share a relevant extract rather than every personal record

For support, identify the entries needed to answer the question and use the established secure channel. A broad account screenshot can expose full names, payment instruments, usable voucher codes or unrelated personal transactions. Keep the original privately and create a separate redacted copy. Inspect the exported copy before sending, including notification banners and background areas that may contain sensitive information beyond the line you intended to show.

For a missing-credit enquiry, you could provide the date, amount, currency, status wording and reference requested through genuine support. That illustrative summary needs no password or one-time bank approval. A trusted person drafting it with you can use a redacted version instead of a complete statement. Check what each field does before sharing it: locating an entry is different from granting access or authorising spending. The payment-security guide explains that distinction, which remains relevant even when you are only trying to make the record easier to understand.

Do not send account documents to this publication for adjudication. The site explains record-reading methods and source requirements, but cannot access an operator ledger or settle a private dispute. Keep the official response with the relevant entry. If more information is requested, establish its purpose and secure route rather than repeatedly forwarding full documents through several informal conversations.

Leave a calculation someone else can follow

A useful final note states the period, currency, opening and closing components, included movement types and any unresolved difference. Someone reading the note should be able to understand how the total was obtained without guessing the signs or treating every displayed row as completed spending. Keep the original export or screenshots privately so the calculation can be checked against the source if a later reply changes an interpretation.

Name the result you calculated. Gross deposits, net deposits, game results and remaining balance are different outputs even when drawn from the same file. Reconciliation describes past activity; it does not establish a target for spending, permission for another payment or a refund promise. If an entry is still unexplained, keep it visible and ask about that entry next. Assigning the gap to an assumed fee or loss may make the total look tidy, but it leaves the original question unanswered.

Preserve the version used for the enquiry

Keep a short change note when you revise a working calculation. An illustrative £10 entry might initially look like a withdrawal, then be explained as a reservation already counted elsewhere. Save the operator's explanation and update your summary to reflect it. The note shows why your total changed without altering the original export or suggesting that its source record was edited. A later reader can then distinguish the first interpretation from the explanation that led you to count the entry differently.

Date the revised calculation and keep it attached to the same case reference. A support agent should be able to distinguish your earlier interpretation from the later explained version. This is especially useful when several messages quote different totals. The final figure remains limited by its stated assumptions, and any unresolved entry should remain visible rather than being removed to produce a tidy result.