One reference can describe several different events
A forex or CFD operator receives two bank entries with the same reference. One might be a second genuine deposit, a duplicated statement import, a corrected bank message or a transfer from an unrelated sender who reused old instructions. Automatically crediting both entries can create an unsupported trading balance; automatically deleting one can conceal real money that still needs allocation.
The operational task is to establish which events actually occurred and who is entitled to each receipt. This guide concerns payment records and allocation controls for appropriately authorized businesses. It does not determine whether a firm may offer trading services or whether a particular customer can be accepted in a given market.
Establish the applicable records framework
For firms within its scope, the FCA's CASS 7.15 framework addresses accurate client money records and reconciliation. It is a UK regulatory reference, not a rule automatically applicable to every international broker. Determine the relevant permissions, client money treatment and responsible personnel before translating that framework into a local operating procedure.
A useful internal objective is simpler to express: every credited balance should be traceable to a verified event, and every unresolved receipt should remain visible. Staff should be able to explain why a match was accepted, who approved it and which later correction would reverse it. A familiar payment reference alone cannot provide that explanation.
Give the bank event its own identity
Preserve the original bank file or authenticated message and assign a receipt record independently of the customer's reference text. Retain the bank's transaction identifier, account, amount, currency, booking date and value date where supplied. Keep the raw values alongside normalized search fields so that formatting changes do not erase distinctions useful during investigation.
The import process should identify an already received bank event without assuming that all transfers carrying an identical reference are duplicates. Test repeated file delivery, overlapping statement periods and corrected records. An import deduplication decision belongs to the bank event layer; the customer allocation decision belongs to a separate layer linked to it.
Compare evidence before selecting a client
Bring the candidate entries into one review view. Compare sender details available through approved channels, bank identifiers, timing, amount, currency and prior allocations. A matching amount is useful context but not conclusive evidence. Two clients can send the same amount on the same day, particularly when funding instructions suggest a standard minimum.
Customer screenshots can support an investigation but should not replace authenticated banking evidence. If the sender identity or entitlement remains uncertain, route the receipt through the established review process. Avoid revealing another customer's name, balance or reference while asking the claimant for clarification. Explain what information is needed without inviting the customer to guess the missing details.
Separate receipt status from trading availability
Use distinct states for received, identified, allocated and available for the relevant account activity. The system should not release a balance merely because support attached a client identifier to a case. Define which checks and approvals move the receipt forward, and ensure the trading platform respects the resulting status.
Where a provisional allocation is permitted by the firm's reviewed policy, make its conditions explicit to authorized staff. Record the financial exposure and the person responsible for resolving the uncertainty. Do not improvise a temporary credit to quiet a complaint if the downstream system cannot prevent inappropriate withdrawals or other use of an unverified balance.
Correct errors through linked entries
If a duplicate credit has already been posted, preserve the original entry and create the approved correction with its reason and case reference. Rewriting the original history makes later statements, support responses and reconciliation difficult to explain. The correction should show the affected account, amount, currency and relationship to the verified bank event.
Payment operations should coordinate with the relevant trading, compliance and finance owners before changing an available balance. A ledger correction can have consequences beyond the receipt itself. Staff need a defined escalation route for positions, withdrawals or statements affected by the error rather than treating the adjustment as an isolated bookkeeping task.
Close the exception with a complete explanation
An exception is ready to close when the bank event, allocation and customer ledger agree, or when the remaining difference has a documented owner and approved treatment. Record which evidence resolved the ambiguity. If the apparent duplicate was a second genuine payment, retain both receipt identities and explain why both were allocated.
Review repeated exceptions for preventable causes. Shared funding instructions, recycled references, ambiguous customer identifiers or overlapping imports may be creating avoidable manual work. Measure the age of unresolved receipts and the frequency of allocation reversals. A lower exception count is useful only if it reflects better matching rather than hidden or prematurely closed cases.
What it means to Merchants
A duplicate reference should trigger a controlled comparison, not an automatic credit or deletion. Keep bank event identity separate from customer allocation, preserve unresolved receipts and correct mistakes through linked records. The practical result is an account history that finance, support and the responsible control functions can explain consistently, while the actual legal and client money treatment remains governed by the firm's applicable framework.