Verify the request: a practical crypto account safety workflow

Start with a written decision rule

Use this article as our proposed editorial workflow for handling unfamiliar requests and reviewing account access. The checklists, examples and acceptance criteria below are recommendations, without promised outcomes. Follow your exchange’s own instructions for the controls it actually provides.

This article does not certify any support handle, telephone number, messaging bot or recovery service. A source access date should not serve as your approval of a person who contacts you.

The official help hub introduces MaxData Info Bot as an assistant for questions about MaxData and the workspace. Keep that description attached to the help hub rather than extending it to an unrelated conversation. MaxData Help Hub. [EN-C1]

For this workflow, use “unverified request” as a working label whenever you have not completed your own check. Use “suspected incident” for an event you choose to investigate. Neither label requires you to announce that an account has been compromised.

Write your decision rule before you need it: “I will confirm account changes through a support route I open myself.” Make the rule specific enough to apply while reading an urgent message.

Our proposed routine for checking a support request

Begin by extracting the requested action. Ignore the sender’s introduction for a moment and complete this sentence: “This person wants me to…” Examples might include opening a page, sharing a code, changing an integration or approving a wallet action. Treat these as hypothetical requests, without drawing conclusions about a particular sender.

Then follow our proposed sequence:

1. Pause the requested action. Leave the message available for reference, but do not continue its instructions while checking it.
2. Open the service independently. Use a bookmark you previously checked yourself, or an address recorded in your own account notes.
3. Find support from that starting point. Navigate to the service’s help area or contact form without using the conversation’s link.
4. Ask about the exact task. Include the case reference, the requested change and the channel where the request arrived. Ask whether you should perform that specific action.
5. Record the decision. Save the route you used, the question you asked, the response and any unresolved uncertainty.

Our proposed acceptance criterion is confirmation of the task through that separately opened support route. Repeated reassurance in the original conversation does not complete this checklist. If the reply confirms only that a case exists, ask separately about the requested account change.

For an unresolved request, write “not confirmed” and leave the action paused. Do not substitute a deadline, a familiar profile picture or your desire to finish the task for the missing answer.

Our proposed boundary for credentials and approvals

Adopt a written policy for information you will not provide in a conversation. Our suggested list includes passwords, one-time login codes, recovery codes, API secrets and wallet recovery phrases. Apply the same boundary when preparing screenshots, support tickets and questions for an assistant.

Our proposed policy also excludes sending a payment, approving a wallet signature or granting remote control as a way of checking a support worker’s identity. If a conversation makes one of those actions a condition of receiving help, stop the task and ask through the support route you opened independently.

Prepare a short response in advance: “I will verify this request from inside the service. Please provide the case reference and describe the account action. I do not share authentication material in chat.” Use it as a script rather than improvising exceptions during a countdown.

For a new user, we suggest a minimal desk note with two instructions: open the service yourself and confirm the task there. For a frequent trader, add the account name and the proposed change. For an automation operator, also record the integration identifier and the permission being requested.

Keep these notes descriptive. Do not paste actual credentials into the template to make it more complete.

Our proposed exchange access review

Perform this review inside your own account and consult the operator’s documentation. The following items are a checklist to investigate, not a statement that every exchange offers every control.

Login and recovery. Check the contact details attached to the account against your own records. Set a separate password for the exchange and for its associated email account. Review the additional authentication methods described by the operator and choose your configuration. Record your recovery procedure without including recovery material in your ordinary support notes.

Sessions and devices. Review any available list of sessions, devices and login events. Mark entries you cannot associate with your own activity. Find the operator’s instructions for ending a session or signing out other devices. Leave unexplained entries on the review list until you have investigated them.

Withdrawals and account changes. Locate the documentation for withdrawal approvals and changes to account details. If an address list is available, compare its entries with your own records. Under our proposed rule, do not add an address merely because an unverified conversation instructs you to do so.

Connected services. Create an inventory containing the tool name, a non-secret key identifier, its intended purpose and its permissions. Our proposed convention is one inventory entry per integration and no withdrawal permission for a connection intended only for analysis or trading. Check the connection requirements in both providers’ documentation.

Finish with a short review note: checked items, open questions and paused actions. Avoid recording secret values. For an unfamiliar setting, write down the documentation question you need answered instead of guessing its meaning.

Our proposed separation between alerts and account administration

The English Pro Alerts guide describes an Alert as a notification associated with one condition and a Pro Alert as involving several conditions. Pro Alerts guide. [EN-C2]

The English Max Terminal guide lists publishing alerts, subscribing to other users’ alerts and creating trading automations based on Pro Alerts. This is a description of the document’s contents, without confirmation of feature availability on an individual account. Max Terminal guide. [EN-C3]

Our proposed operating convention is to keep market notifications separate from approval to change account access. For each alert, write down the analytical condition, the expected notification and the action you have authorized. Send requests for credentials or permission changes back through the contact verification routine.

For each integration, prepare a small operating card: configuration owner, intended activity, permission scope, place to pause it and conditions for restarting it. Before enabling an execution connection, rehearse finding those controls without submitting an order.

Use a practical acceptance test: can you identify the connection in the account panel and explain how you would stop it? If your only reference is the latest message in a notification channel, leave the rehearsal unfinished and locate the relevant documentation.

Our proposed response to a suspected incident

Use the following sequence to organize your response, adapting account actions to the operator’s instructions and the event you observed.

Stop the interaction. Pause the requested task and end the conversation. Do not send additional credentials as part of an alleged cancellation procedure. Open the account and its support route independently.

Describe what happened. Distinguish receiving a message, opening a page, entering information, approving an action and observing unfamiliar account activity. Record what you actually did and saw. Keep “I received an unexpected message” separate from “I found an unfamiliar withdrawal”.

Choose account actions from the documented procedure. Depending on the event, consider changing a disclosed password, ending sessions, disabling an integration or revoking an exposed key. For an unfamiliar withdrawal, follow the operator’s reporting route. Under our proposed rule, do not transfer assets to an address supplied by the unverified conversation.

Build a concise incident record. Include the time and time zone, contact channel, requested action, steps you completed and relevant operation identifiers. Remove credentials from screenshots. Separate observations from assumptions, and state the question you need support to answer.

Set conditions for resuming. Our proposed restart checklist requires a review of access, connected services and unexplained operations. Record what you checked and what remains uncertain. Keep an integration paused while an unresolved question concerns its permissions or ownership.

Do not make a recovery promise part of your own incident note. Ask for documented next steps and track the response through the support route you opened.

Rehearse with a hypothetical message

Imagine receiving a market notification followed by a direct message saying, “Your connection needs updating; send your login code.” This is a fictional exercise. Write down the request, open the service independently and draft a support question without including the code.

Next, identify the integration in your inventory and locate its pause instructions. Prepare a three-sentence incident note: what arrived, what you did and what remains unconfirmed. Our proposed completion criterion is a usable record and a clear decision about the paused task.

Repeat the exercise for a different fictional request, such as adding a withdrawal address. Keep the same decision rule even though the requested operation changes.

This article is educational. The invitation to create a MaxData account below is promotional and is separate from the proposed verification procedure.