Conditional KYC: why a crypto swap can pause and what to do next

A crypto swap can pause for verification after the provider receives funds if its terms permit later checks. The first useful step is to identify where the transaction has stopped. A transfer waiting on the network, an uncredited deposit and a provider's identity review are different problems with different next actions.

Do not send more money to make a hold disappear. Preserve your order record, use the provider's official support channel and ask what condition must be met for completion or return. A refund may itself be subject to checks, fees and technical restrictions. There is no universal deadline or automatic right to an immediate blockchain return that this guide can promise.

What conditional verification actually changes

Conditional ID means a service does not routinely request identity documents at the start but reserves checks for particular circumstances. The important change is the timing of the decision. If verification happens before a deposit, you can consider the request while still controlling the funds. If it happens afterward, the provider may already control the deposited asset.

Identity verification establishes information about the customer. A source-of-funds request asks about the origin of the money. Transfer-information checks may concern the parties to a transaction. These are related compliance processes, but supplying one item does not necessarily answer every question in another process.

The provider's explanation may be limited. That does not make every delay legitimate, and it does not establish misconduct by itself. Work from the documented status, the current terms and the correspondence you actually receive. Avoid guessing at an undisclosed screening trigger or treating a forum explanation as the provider's reason.

There is also a difference between a service's stated policy and the legal obligations that apply to it. For a specific example, Article 17 of EU Regulation 2023/1113 provides risk-based procedures for handling missing transfer information, including requesting information, rejecting, returning or suspending a transfer. That provision is a scoped legal example, not a universal rule for every swap worldwide.

Locate the pause before choosing a response

Start with the sending side. Was the transfer broadcast, and is there a transaction identifier? If a wallet has not broadcast a transaction, the receiving provider cannot process an on-chain deposit that does not yet exist. A pending transaction in a wallet also needs to be distinguished from a transaction included on the network.

Next check the network, destination address and asset representation against the order. A transfer on the wrong network may be visible on that network but absent from the receiving system's expected deposit route. The presence of a transaction hash does not prove that the intended service received a supported asset in the required way.

If the transfer is on the intended network, inspect the order status through the official site. “Waiting for confirmations”, “deposit detected” and “verification required” describe different stages. The exact wording varies; use the provider's documented meaning rather than assuming that every pending status is a compliance hold.

When the status is unclear, ask support to identify the current stage. A useful question is whether the deposit is recognized, whether the order is awaiting network confirmations or internal processing, and whether the provider requires any action from you. Keep the questions separate so the answer can be checked.

Preserve a useful private record

Keep the order identifier, the terms that applied when you created the order, the relevant quote details and the correspondence. Record dates and times with a time zone. These details help distinguish an expired quote from a later review and make it easier to explain the sequence consistently.

Save the network and transaction identifier privately if they are relevant to the official support process. Do not publish a complete transaction history to attract attention. Public posts can connect addresses, amounts and personal information in ways that are difficult to reverse.

Juno Swap does not need those transaction details. If you report an editorial error, send the affected page, the disputed statement and a public source where available. Do not email identification images, seed phrases, private keys or full transaction records to the publication.

Separate what you know from what you suspect. “The order page requested documents at this time” is an observable event. “The provider intends to keep the funds” is a conclusion requiring different evidence. A clear chronology is more useful to a support reviewer than an accusation unsupported by the record.

Confirm the channel before answering a request

Open the provider's official website using an address you have independently checked, then locate its support or verification route. Do not rely on a direct message from an account that appeared after you discussed the issue publicly. A familiar display name or copied logo does not establish that the sender represents the service.

Ask what information is required, why the request is relevant to the order where the provider can explain it, and where the information should be submitted. Read the applicable privacy information before deciding whether to provide documents. A request should be evaluated in the context of the actual provider and process, not a generic promise that all verification portals are equivalent.

Never disclose a seed phrase or private key. Those secrets authorize control of funds; they are not identity documents. Likewise, do not install remote-control software or transfer a separate “release deposit” merely because an unsolicited contact says it will resolve the hold.

If a message conflicts with the official order page, pause the conversation and verify it through a separate official route. This is a channel-authentication problem before it is a document-submission problem. Sending sensitive material quickly does not resolve uncertainty about who is receiving it.

If you cannot or do not want to complete verification

Read the refusal and refund clauses before assuming that declining a request cancels the order. Ask whether the provider offers a return in your situation, which conditions apply, and whether verification remains necessary for that return. The answer may depend on the route and the legal context.

Clarify the returned asset and network. An intended payout asset is not necessarily the asset that a refund would use. A return may concern the original deposit rather than the quoted output. Also establish whether network costs or other documented deductions apply, and whether the provider requires a particular refund-address procedure.

Do not assume the sending address is a usable refund address. A transfer from a custodial account may originate from an address managed by the platform rather than a personal deposit address assigned to you. A supported return route must be confirmed with the relevant parties; copying an address from a block explorer is not enough.

Ask for the next review step and the provider's stated time frame if one exists. Treat an estimate as an estimate. This guide cannot supply a universal number of hours or days, and an unrelated payment-services deadline should not be imported into a crypto dispute without checking its actual legal scope.

A hypothetical paused order

Suppose a customer creates an order without an account, sends the correct asset on the correct network and then receives an identity request. The terms previously stated that checks could occur. That sequence is consistent with a conditional policy, but it does not by itself answer whether the request, handling or eventual outcome is appropriate.

The customer should first confirm that the request appears in the official order flow. They can then ask whether the order is paused pending identification, whether source-of-funds evidence is also required and what the refusal process provides. Each answer narrows the next decision without assuming that the quote remains executable indefinitely.

Now change one fact: the customer sent the right ticker on an unsupported network. A verification discussion may no longer be the only issue. Even after an identity question is resolved, the deposit may require a separate technical review. Completion of one process does not demonstrate completion of another.

Change a different fact: an unsolicited account demands a second payment to “unlock” the first. That message should not be treated as part of the provider's process without independent confirmation. The correct response starts with authenticating the channel, not negotiating the requested payment.

Escalate through a documented route

If ordinary support does not address the issue, look for a formal complaint process in the provider's own documents. Present a concise chronology, the unresolved question and the outcome you are requesting. Keep copies of what you submit and of the responses.

Further options depend on the provider's legal entity, the applicable jurisdiction and your circumstances. A regulator, ombudsman, court or law-enforcement body may have a defined remit, but a general crypto guide cannot tell every reader that a particular body can recover funds or handle their case. Verify the body's scope through its official information.

For a substantial dispute, consider qualified legal advice appropriate to your location and the relevant entity. Do not pay an unsolicited recovery agent on the strength of a promise to reverse an irreversible transfer. A persuasive story about special access is not evidence of authority or capability.

Public reporting can alert others, but it should distinguish an unresolved complaint from an established finding. Remove personal details and avoid publishing documents that create additional exposure. A factual report can explain that a response is pending without asserting a conclusion the evidence does not support.

Reduce uncertainty before the next deposit

Read later-check and refund provisions before comparing small differences in price. If you cannot accept a documented verification condition, choose not to start that route. There is no need to invent a workaround or misstate eligibility to finish a transaction you are not comfortable entering.

Check custody and execution separately. A payout to a personal wallet does not prevent the provider from holding the deposit during the swap. A route involving an aggregator may also require you to identify the executing partner whose terms govern the hold.

Juno Swap separates Policy checked from a completed funded trade and a refund test. The methodology explains those evidence boundaries. Read what no KYC means for policy interpretation and choosing the correct network for the technical checks that help distinguish a review from a routing error.

Questions readers ask

Is every delayed swap frozen for KYC?

No. A delay can occur before broadcast, during network confirmation, at deposit recognition or during provider processing. Establish the documented stage before treating the problem as an identity review.

Does refusing identification automatically produce a refund?

No general rule in this guide establishes that outcome. Read the applicable refusal and refund terms, including any checks required before a return. Ask about the asset, network, deductions and next step.

Should I send another deposit to speed up the process?

Do not send additional funds merely to remove a hold. Independently verify any request through the official channel and understand its documented basis. An unsolicited demand is not evidence of a legitimate release process.

Can Juno Swap recover the funds or contact the exchange for me?

No. Juno Swap is an independent publication, not a recovery service or transaction intermediary. It can receive reports about errors in its own coverage, without sensitive documents or full transaction details.