Immediate priorities after suspected compromise
The first goal is to reduce further access. Use a different device that you believe is safe, where possible. Change credentials only through a trusted provider route, and record the approximate time of each security action. Do not delete messages, transaction notifications or device records before preserving them.
The second goal is to separate facts. An unfamiliar login, a changed credential, an unauthorised transfer and an authorised transfer to an unexpected recipient are different evidence questions. A payment-provider listing or transfer does not by itself prove a casino relationship, casino legality, recipient ownership, refund entitlement or wrongdoing.
Isolate the affected device
Isolation helps prevent a suspected malicious application, browser session or remote-access tool from continuing to observe credentials or approve activity. Disconnect the device from mobile data and Wi-Fi if you suspect active malware, remote control or phishing-related compromise. Avoid entering a new PIN or OTP on that device until it has been assessed or reset through an appropriate process.
The BGD e-GOV CIRT advisory published on 17 May 2026 describes an AsyncRAT campaign using fraudulent gambling infrastructure and localised bKash, Nagad and Rocket payment lures. The advisory concerns the malicious infrastructure it describes; it does not establish that bKash, Nagad, Rocket or every casino-related transfer is fraudulent. Read the CIRT advisory for that precise scope.
Secure credentials without destroying evidence
From a trusted device, use the provider’s established account-security process. Record when you changed the PIN, requested a block, contacted support or received a security notification. Do not send a PIN, OTP, full authentication code or recovery secret to a person who contacts you first. A screenshot of a request for an OTP can be useful evidence; the OTP itself should remain confidential.
If your mobile number, handset, email account or SIM may also be affected, address those risks through the relevant legitimate provider. Keep a written timeline with neutral wording: what appeared, when it appeared, what action you took and what response you received. Avoid editing screenshots in a way that removes dates, transaction IDs or recipient details.
Credential-reset records show what security action was taken. They do not prove who caused the compromise or whether a later transfer was authorised. For broader handling of suspicious payment messages, see phishing and fake support guidance.
Preserve transaction and device evidence
Retain the complete transaction notification where available. Useful records may include the transaction ID, date and time, amount, transaction type, masked account details, recipient or agent information shown by the provider, the message sender, relevant URLs, device details and the sequence of security actions. Keep original files where possible and make a separate working copy for redaction.
Do not publish a full phone number, PIN, OTP, national identity number, full account credentials or other unnecessary personal information. Store evidence in a location not controlled by the suspected device. A simple evidence log can distinguish an original record from your interpretation.
| Evidence item | What it can establish | What it cannot establish by itself |
|---|---|---|
| Provider notification or statement | That a recorded event or notification exists | Who operated the recipient account or caused the event |
| Transaction ID and timestamp | A reference for provider investigation | That the transfer was unauthorised or recoverable |
| Screenshot of a link or message | What was displayed or requested | That the sender, domain or payment recipient is genuine |
| Device and application notes | The suspected environment and sequence | That a particular malware family caused the loss |
| PIN or OTP reset record | That a security action was attempted or completed | That every later transaction resulted from the compromise |
For a structured record-keeping approach, use the MFS transaction evidence guide and receipt privacy guidance.
Separate unauthorised activity from an authorised transfer
Do not label a recipient a criminal, a casino operator or a fraudulent merchant solely because the name is unfamiliar. A displayed recipient name may not identify the beneficial owner. Conversely, an apparently familiar name does not prove that a particular transfer was legitimate. Keep the original provider record and ask the provider what recipient information it can verify within its remit.
| Question | Record carefully | Avoid claiming without supporting evidence |
|---|---|---|
| Did you approve the transfer? | Whether you entered or disclosed an authentication step | That an unknown person definitely made it |
| What device was used? | Device, connection and approximate time | That a named malware caused the event |
| Who appeared as recipient? | Exact provider-displayed name or number | That the displayed identity owns the account |
| What did the message request? | Text, sender, URL and attachments | That the sender is a verified provider |
| What remedy is sought? | Block, investigation, correction or dispute | That reversal or reimbursement is guaranteed |
The recipient and merchant-check guide explains why recipient identity and payment evidence should be handled separately.
Contact the payment provider through a trusted route
Use a provider channel that you locate independently rather than a phone number, link or chat account supplied in the suspicious message. Give the provider the transaction ID, time, amount, relevant account details requested through its secure process, and a concise timeline. State clearly whether you believe the event was unauthorised, whether credentials may have been exposed, and whether the device may contain malware.
Ask what case or reference number was created and retain the response. A provider investigation may examine transaction authentication and account records, but the available outcome depends on the facts and the provider’s process. Do not promise yourself or another person that a transfer will be reversed.
For a transfer to the wrong recipient, use the wrong-recipient guide. For transaction-ID preservation, see TRXID evidence guidance.
Understand Bangladesh Bank’s stated scope
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. Read the official Bangladesh Bank MFS regulations for that stated scope.
Start with the provider’s complaint process and preserve proof of submission. If the provider’s response does not resolve the issue, use the applicable escalation route and keep the original case reference. Regulatory escalation does not transform an allegation into an established finding, and it does not decide whether a separate commercial or gambling dispute is valid. See complaint escalation guidance and complaint routes in Bangladesh.
When CIRT reporting is relevant
CIRT reporting may be relevant where the incident involves a suspicious domain, malware, phishing, malicious infrastructure or another cyber incident. 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. Submitting the form is not a police complaint, a casino adjudication or a recovery guarantee. The official CIRT incident form identifies the information requested.
Preserve the suspicious URL, domain, IP information where available, message content, device observations and transaction references. Do not add assumptions to the report. Describe what you observed and identify uncertainty. CIRT reporting and a provider complaint can be separate actions; one does not replace the other.
| Situation | Immediate record or action | Appropriate route boundary |
|---|---|---|
| Suspected credential exposure | Isolate device, secure account from a trusted device, record reset time | Provider security process first |
| Unfamiliar transfer | Preserve notification, TRXID, amount, time and displayed recipient | Provider dispute or investigation |
| Phishing or malware indicator | Preserve URL, message, device notes and logs where safe | CIRT incident reporting may be relevant |
| Unresolved provider complaint | Keep case number and response | Applicable complaint or escalation route |
| Personal information exposed | Limit disclosure and request correction where appropriate | Privacy corrections |
Build a neutral incident timeline
A useful timeline has separate entries for the first suspicious message or device symptom, account access, credential changes, each transaction, provider contact, CIRT reporting and any later response. Use Bangladesh time if known and mark estimates as estimates. Preserve both successful and failed access attempts when they are visible. Avoid merging separate events merely because they occurred on the same day.
The timeline should distinguish provider-confirmed information from your own observation. For example, “notification displayed a transfer reference” is different from “recipient stole funds.” This distinction helps the provider, a cyber-incident reporter or an escalation body assess the record without treating an allegation as a finding.
What not to do after compromise
Do not send another payment to “unlock” an account, do not disclose an OTP to recover funds, and do not let an unsolicited helper control the device. Do not delete the suspicious application before recording its name and relevant details if doing so is safe. Do not publicly post complete transaction records or accuse a named recipient without verified evidence.
Do not assume that a payment-provider logo, account name or transfer record proves an underlying casino relationship. A payment record can support a transaction question; it does not establish licensing, ownership, legality, refund entitlement or wrongdoing. For ongoing account-safety practices, use the bKash payment hub and payment-risk guidance.
FAQ
What should I do first after suspected bKash account compromise?
Stop using the suspected device for sensitive activity, preserve visible notifications and transaction details, and secure the account through a trusted channel from a device you believe is safe. Record each action and do not share your PIN or OTP.
Why isolate the affected device?
Isolation can reduce the chance that a suspected malicious application, remote-access tool or phishing-related compromise continues to observe credentials or account activity. It also helps preserve the device state for later assessment.
Which transaction evidence should I retain?
Retain the original notification where possible, transaction ID, date, time, amount, transaction type, displayed recipient information, relevant messages or URLs and a timeline of credential and provider actions. Do not share PINs, OTPs or unnecessary personal data.
Is a CIRT report a substitute for a provider complaint?
No. CIRT reporting may address a cyber incident such as malware, phishing or suspicious infrastructure. A provider complaint addresses the payment account or transaction. The CIRT form states that submission is not a police complaint, casino adjudication or recovery guarantee.
Does a transfer prove who owns the recipient account?
No. A provider-displayed recipient name or transfer record does not by itself establish beneficial ownership, a casino relationship, legality, refund entitlement or wrongdoing.
Does Bangladesh Bank’s MFS framework guarantee reversal?
No. The framework includes authentication safeguards and complaint and grievance-redressal arrangements, but it does not promise reversal of a particular transfer or identify a casino recipient.
Editorial and correction details
Prepared by Casino Check BD Evidence Desk and edited by Casino Check BD Editorial Verification Desk. Review date: 28 August 2026. Requests to correct personal-information handling should use privacy corrections.