An exchange freezes withdrawals when its risk engine prevents a request from moving into the sending stage because inconsistencies have been detected in the source of funds, recipient address or account security profile.
A withdrawal freeze is an execution status in which the request is visible in the operation history, but it does not receive a txid and is not passed to the blockchain or payment gateway.
The funds remain on the exchange's internal balance, while the restriction applies only to the action of creating or completing a withdrawal with the specific parameters of that operation.
🔒 Where exactly the system stops a withdrawal
The withdrawal process consists of consecutive stages: request creation, parameter validation, risk-score calculation, security review and transaction sending.
A freeze always happens before the sending stage and is confirmed by the absence of a txid while a withdrawal request record already exists.
If the request has already received a txid, the risk engine has passed the blocking stage, and the later delay is recorded on the network side as a growing number of confirmations or on the external gateway side as a pending status without a change in the risk code inside the withdrawal history.
| Restriction level | Forbidden action | Visible effect |
|---|---|---|
| Account | Creating any withdrawal requests | Withdrawals are unavailable for all assets |
| Asset / Network | Withdrawal through a specific network | Some networks or tokens are unavailable |
| Address | Sending to a new address | Only whitelisted addresses are allowed |
| Withdrawal | Completing the request | The request stays on hold without a txid |
🧠 Two independent classes of blocking reasons
The system separates blocking reasons into funds risk and account-control risk, processes them through different modules and records the result on different review objects.
🧾 AML risk on deposits
The AML module assigns a risk score to a specific deposit based on source addresses and the route of funds, then checks that score when a withdrawal request is created.
- The deposit came from an address that blockchain analytics links to thefts, extortion activity or sanctions clusters.
- The funds passed through a mixer or transaction obfuscation service, which is detected by the structure of transaction inputs and outputs.
- Deposits arrived as a series of identical amounts inside a short time window, increasing risk scoring because the flow of funds looks split into fragments.
- The withdrawal request was created immediately after the deposit, without trading activity, conversion or internal movement of funds.
With an AML block, the restriction is more often applied to the specific amount or asset connected with that deposit.
🛡️ Security risk on the account
The security module estimates the probability of account takeover at the level of the session and change history, then blocks withdrawal as an irreversible action.
- The login was made from a new device or a new country, followed by an attempt to withdraw in the same user session.
- The password was recently reset, 2FA was disabled, or key contact details on the account were changed.
- A new withdrawal address was added and a request for a large withdrawal amount was created immediately afterwards.
- The session matches an IP or ASN that the system associates with phishing campaigns or mass login activity.
With a security block, the ban applies to the withdrawal confirmation action and remains until the system records a stable session and an unchanged account security profile.
🧱 How a request moves step by step into hold
The sequence below shows a simplified chain of checks that a withdrawal request passes before it is sent to the network.
| Step | Review object | How the ban is recorded |
|---|---|---|
| 1 | Request parameters | Withdrawal creation is refused, or the network and address validation returns an error |
| 2 | Source of funds | The request is created, but receives a hold with a deposit risk code and remains without a txid |
| 3 | Recipient address | A new address is forbidden, or address confirmation is required before sending |
| 4 | Session and security | Withdrawal confirmation is blocked until 2FA, device and change history are stabilized |
| 5 | Sending | If a ban exists, no txid is generated; if there is no ban, the request goes to the network |
The sequence reflects the operating principle of risk controls, but it does not disclose internal thresholds, signal weights or priority order.
📄 What data is requested during a freeze
Support requests are formed strictly around the object on which the system recorded risk.
With an AML block, the origin of funds is checked by the amount and date of the specific deposit, not by the account as a whole.
With an address block, proof of control over the recipient address is required, because the address itself is the risk object.
With a security block, the user must confirm continuous control over the account, device and access channels.
What closes the AML object
The AML review is lifted only when the system can match the deposit, the source of funds and the declared route without discrepancies.
- Confirmation of the source of funds that matches the specific deposit by amount and date.
- Transfer history showing the source address and the transaction identifier of the deposit.
- An explanation of the route of funds that matches the observed chain of transaction inputs and outputs.
If at least one element of the chain is not confirmed, the deposit risk remains active and the withdrawal is not allowed.
What closes the security object
A security review is lifted after the system records stable account control and no new anomalies.
- Identity confirmation and enabled 2FA recorded in the security settings.
- Device or session confirmation matching the most recent successful login.
- No new password, 2FA or withdrawal-address changes during the review period.
If new security changes appear, the system continues to hold the ban on withdrawal confirmation.
A mismatch in amounts, dates or owners between the deposit and the documents automatically keeps the request in hold.
✅ Actions that speed up release of the block
The speed of unfreezing depends on how accurately the reason recorded in the system is resolved.
- Specify the parameters of the blocked request and the reason code shown in the operation history.
- Match the withdrawal to a specific deposit by amount and date.
- Stop changing account settings until the review is closed.
- Use a confirmed address or provide a signed message.
- Do not recreate withdrawal requests in batches.
If the withdrawal was requested immediately after a password reset, 2FA disablement or address addition, the system often holds the ban specifically on withdrawal confirmation until the security history no longer contains new changes.
These actions reduce the number of inconsistencies that compliance and security teams must analyze manually.
⏳ Why a freeze can last for several weeks
The review period grows when compliance and security teams have to match not one request, but a chain of objects: deposits, addresses, transactions and account-profile changes.
🔗 A transaction chain expands the scope of review
Each intermediate transfer increases the number of matches between the blockchain and internal balance logs.
- Each deposit adds a source of funds that must be confirmed by amount and date.
- Each new address in the route requires checking connections with risk clusters.
- Each internal conversion requires matching the trade log with the withdrawal balance.
- Each withdrawal to a new address requires confirmation of ownership and the reason for changing the recipient.
A growing number of objects increases the volume of manual matching by amount and time.
🛡️ Security anomalies keep confirmation on hold
The security engine records account changes as risk events and forbids withdrawal confirmation until the security profile becomes stable.
- Changing the password, disabling 2FA or changing the device creates a risk event in the security history.
- A withdrawal attempt in the same session increases the takeover score and turns on hold.
- Repeated settings changes during the review extend the block.
- Adding a new withdrawal address moves the case into repeated validation.
New security events keep the ban on withdrawal confirmation active.
| Reason for extension | What exactly is compared | What breaks the timeline |
|---|---|---|
| Many deposits | Deposit amounts and dates against documents | A document without a link to the deposit |
| Long address route | Connections between addresses and transactions | Unexplained intermediate transfers |
| Security changes | 2FA, password and device history | New profile changes |
A long freeze is connected with the volume of objects being checked and with data inconsistencies, not with a technical malfunction of the withdrawal itself.
🧭 Why this explanation is not enough
This material shows the principle of withdrawal blocking and the points where the ban is recorded, but it deliberately does not disclose internal AML-scoring thresholds, weights of security events or the priority logic of risk signals.
To see how similar restrictions work in real life - with delays, refusals and additional checks - it is useful to look at user cases and typical withdrawal problems on crypto exchanges.