Build the packet before contacting anyone
A useful Rocket complaint packet should preserve the transaction record, the Rocket account information, the timing, and the incident context without changing the original material. Keep the account number and check digit exactly as shown. Record the transaction reference, date, time, amount, transaction type, and any displayed recipient information only when those details appear in the record available to you.
A transfer record can show that a payment event occurred. It does not, by itself, establish who controlled the recipient account, whether the recipient was a casino, whether a casino relationship existed, whether a payment was lawful, or whether a refund is due. Provider identity, recipient identity, transaction evidence, any casino claim, and complaint jurisdiction should remain separate.
For background on retaining transaction material, see Rocket payment guidance and MFS transaction evidence.
Where to find Rocket transaction details
Start with the original Rocket statement, transaction history, confirmation message, or other account record available to you. Preserve the record in its original form before making a cropped or annotated copy. A screenshot may show what appeared on a device at a particular moment, while a statement may provide a more structured account record. Neither should be treated as a substitute for the other.
Write down the account number and check digit separately from the recipient number. Do not assume that a displayed number proves ownership or control. If an entry contains a transaction reference or other identifier, copy it carefully and compare it across the statement and screenshot. If the records differ, preserve both versions and note the difference rather than silently correcting one.
The Rocket FAQ captured on 28 August 2026 says customers should never share a PIN. It also says that, for money sent to a wrong number, customers should immediately contact the Rocket helpline or visit a mobile-banking office. The FAQ does not promise that a transfer will be reversed. Read the official Rocket FAQ for that provider instruction. Do not include a PIN, one-time password, or full authentication secret in a complaint packet.
Keep the account number and check digit distinct
An account number identifies the relevant Rocket account record as displayed in the material you hold. A check digit is a separate part of the account presentation and should not be merged, omitted, or guessed. Retaining both exactly as shown helps the provider compare the complaint with its own records.
Use a private working note with separate labels such as “account number” and “check digit”. Mask unnecessary digits when sending a copy to a third party that does not need the complete number. Never publish account credentials or authentication information in a review, comment, social post, or open forum.
A recipient number is not the same thing as a verified recipient identity. A payment-provider listing or transfer does not prove that a recipient owns a particular website, business, or gambling service. If a complaint concerns a claimed casino payment, describe the claim as a claim and attach the underlying transaction evidence separately.
Statement and screenshot: different roles
A statement is useful for showing the account-side transaction entry and its recorded identifiers. A screenshot can preserve surrounding context, such as the screen on which a message, recipient label, or status appeared. Preserve the original files and note when each was captured or obtained, but do not invent a date if the record does not show one.
Avoid editing the original. If redaction is necessary, keep an untouched copy in a secure location and label the redacted version. Do not add arrows, captions, logos, or reconstructed text to the original evidence. An explanatory timeline can be supplied as a separate document.
| Evidence item | What it can help show | Boundary to record |
|---|---|---|
| Rocket statement or transaction history | An account-side entry, amount, date or time, and available reference | It does not prove recipient ownership or a refund entitlement |
| Original screenshot | What appeared on the device, including visible context | It may not establish that the screen was genuine or complete |
| Account number and check digit | The account identifiers shown in the record | They are not a PIN or proof of recipient identity |
| Transaction reference | A reference that may help provider matching | Do not infer a result from the reference alone |
| Timeline note | The order in which events were reported or observed | A note is not an independent provider record |
For related handling guidance, use receipt and privacy guidance and recipient identity guidance.
Record the incident without adding conclusions
Create a factual timeline: when the transaction appears to have occurred, when you noticed the issue, what record you retained, and which provider or authority you contacted. Use “the record displays” or “the user reports” where the material does not independently establish the event. Avoid describing a recipient as fraudulent, a casino, or an operator unless a competent dated record supports that precise description.
Keep contact attempts separate from transaction evidence. Save confirmation pages, case references, and correspondence where available, but do not state that a complaint has been accepted, resolved, or escalated unless the relevant body has confirmed that status. The complaint routes guide can help organise the next channel without turning a submission into a recovery promise.
Bangladesh Bank complaint framework
The Bangladesh Mobile Financial Services Regulations 2018 include transaction-authentication safeguards and a complaint and grievance-redressal framework, including provider dispute handling and CIPC escalation. The regulations do not establish the identity of a casino recipient or promise reversal of a particular transfer. See the Bangladesh Bank regulations for the stated regulatory material.
This framework does not remove the need to contact the relevant provider first where provider dispute handling is applicable. Present the transaction identifiers accurately, keep copies of what was submitted, and distinguish a request for review from a finding that wrongdoing occurred. A provider process may examine its own records; it does not automatically determine a separate commercial or gambling dispute.
| Situation | Evidence to organise | Appropriate description |
|---|---|---|
| Possible wrong-number transfer | Statement, reference, account details, timing, and contact record | “I believe the transfer may have gone to the wrong number” |
| Disputed transaction | Original record, screenshot, timeline, and authentication concerns | “I dispute or do not recognise this transaction” |
| Provider complaint | Packet, submission date, case reference, and reply | “A complaint was submitted to the provider” |
| CIPC escalation | Earlier complaint material and provider response, if any | “I am requesting review under the applicable process” |
| Claimed website or casino payment | Transaction record plus separately identified claim evidence | “The payment is alleged to relate to a named recipient or service” |
Which evidence belongs in a CIRT report
The BGD e-GOV CIRT incident form captured on 28 August 2026 asks for the affected domain and IP, logs or evidence, incident details, attack vector, impact, and steps already taken. The form is available at the BGD e-GOV CIRT incident report. Submitting it is not a police complaint, a casino adjudication, or a recovery guarantee.
Select technical material that addresses the incident rather than uploading every financial document indiscriminately. If a domain or IP is relevant, preserve the exact value as displayed in the source material. Include relevant logs, message headers, screenshots, or files only where they help explain the reported incident. Explain what happened, what impact is alleged, and what steps have already been taken. Do not claim that CIRT has verified the recipient, ruled on a casino balance, or ordered a refund.
| Escalation channel | Prepare | What it does not establish |
|---|---|---|
| Rocket or Dutch-Bangla Bank PLC. provider route | Transaction identifiers, account details, statement, screenshot, and timeline | It does not automatically prove recipient ownership or guarantee reversal |
| Bangladesh Bank framework or CIPC route | Provider complaint, relevant records, and response history | It does not identify a casino recipient from a payment record alone |
| BGD e-GOV CIRT | Affected domain or IP, logs or evidence, incident details, attack vector, impact, and prior steps | It is not a police complaint or casino adjudication |
| Police or other competent route | The records and a clear factual account requested by that authority | No outcome should be stated before an official record exists |
For a focused follow-up, see Rocket complaint escalation and wrong-recipient guidance.
Protect sensitive payment evidence
Do not share a PIN, one-time password, full security credential, or unnecessary identity document with an unverified contact. Store originals securely and use controlled copies when a submission requires redaction. Keep a record of where each copy was sent. Privacy corrections can be requested through privacy corrections.
A payment receipt, account number, and screenshot may contain personal or financial information. Do not upload them to a public page to prove a point. If a recipient asks for additional authentication information, pause and verify the request through an official provider channel. The Rocket FAQ’s dated instruction about not sharing a PIN is linked above and should be treated as provider guidance, not as a promise about the outcome of a dispute.
A concise submission checklist
Before submitting, check that the packet includes the account number and check digit as separate fields, the transaction reference if displayed, the amount and timing as recorded, an untouched statement or transaction record, an original screenshot where relevant, a factual timeline, and copies of any provider responses. State what is known, what is reported, and what remains unknown.
Do not add an assumed merchant, recipient owner, fee, deadline, reversal, refund, legal conclusion, or recovery probability. If the evidence does not identify the recipient, say so. If a domain appears in technical evidence, distinguish that domain from the payment account and from any claimed commercial relationship.
FAQ
Which Rocket transaction details should I retain?
Retain the account number, check digit, transaction reference if shown, amount, date and time if recorded, transaction type, recipient information as displayed, the original statement or history, relevant screenshots, and a factual timeline. Do not include a PIN or other authentication secret.
Why keep the account number and check digit distinct?
They are separate parts of the account presentation. Keeping both exactly as shown helps a provider compare the complaint with its records and avoids guessing, merging, or omitting an identifier.
What roles do the statement and screenshot serve?
A statement may show the account-side transaction entry and identifiers. A screenshot may preserve surrounding device context. Keep both where relevant because one does not automatically replace the other.
Which evidence belongs in a CIRT report?
Use material relevant to the reported technical incident, such as the affected domain or IP, logs or evidence, incident details, attack vector, impact, and steps already taken. The CIRT form does not decide a casino balance or guarantee recovery.
Does a Rocket transfer prove who received the money?
No. A transfer record can document a payment event, but it does not by itself prove recipient ownership, a casino relationship, casino legality, refund entitlement, or wrongdoing.