Your crypto transfer did not arrive. Here is what is happening

A crypto transfer that does not arrive is usually not lost, it is held. Incoming funds are screened for exposure to risky and sanctioned addresses, and above a provider's threshold they are not credited to the general account. The mark travels with the address rather than with your intentions, verdicts differ between analytics providers, and a wrong mark can take weeks of correspondence to lift while the balance is unavailable. What you control is the flow you build before that happens, not the verdict itself.

How screening actually works

Every address and every transaction carries a risk score built from the origin of the funds. Blockchain analytics walks the chain backwards looking for exposure to sanctioned addresses, mixers, hacks and darknet markets, and expresses the result as a proportion of exposure rather than a yes or no. Above the threshold your provider has set, an alert fires and the money is held instead of credited.

The important property is that the mark belongs to the address, not to the person holding it now. You can receive perfectly honest payment for perfectly ordinary work and inherit the history of a wallet you have never interacted with, because a payer two or three hops upstream did something you will never know about.

Two things people learn late

The first is that exposure can surface after a transfer has already settled. The counterparty chain fills in over time, and funds that passed the initial check become the subject of a review weeks later, at which point they are already sitting in your balance and now they are not moving.

The second is that a mark can simply be wrong. Removing it means weeks of correspondence with a compliance team that is not yours, on their schedule, while the balance is unavailable. For a business that receives crypto from a wide circle of payers, this is the single most common way an already-open account is lost.

Why two providers give two answers

Recognised blockchain analytics providers run different databases, different methodologies and different thresholds. The same funds pass at one and stick at another, and neither of them is lying to you. On top of that, each payment institution sets its own tolerance for what it will accept, so the same analytics verdict produces different outcomes at two institutions.

Which is why «it cleared last time» proves nothing about the next time, and why a counterparty insisting their wallet is clean is describing one verdict from one tool on one date.

If your transfer is already held

• Ask what specifically triggered it: a direct hit, indirect exposure, and at what depth in the chain. The answer determines whether this is a documentation problem or a routing problem.
• Assemble provenance for that specific inflow: who the payer is, the contract, the invoice, what was bought, and where they state the funds came from.
• Send it as one pack. Answering in instalments restarts the queue every time and is the main reason these cases run for months.
• Plan liquidity without those funds. Assume weeks, not days, and say so internally before someone promises a supplier.
• Do not shuffle the remaining balance between wallets while a review is open. Movement during a review reads badly and adds a second question to the first one.
• Do not ask the payer to resend the same funds from a different wallet. It converts a documentation question into something that looks like an attempt to disguise the source, and that is a much worse conversation.

The decision to credit, hold or release is always the provider's. Your job is to make the honest answer easy to verify.

Building a flow that survives screening

• Screen before you receive and before you send, not after the alert. A screening step in your own process costs minutes and is the only part of this you control.
• Make screened wallets a condition of doing business and put it in the contract, so asking is routine rather than an accusation.
• Keep pools separate. The pool you pay contractors from should be funded from screened sources and kept apart from anything received from an unfamiliar payer.
• Record provenance at the time of the transaction, not when someone asks for it eight months later.
• Declare the crypto leg at onboarding. Questions about it before onboarding are cheap. The same questions after a large inflow are not.
• Keep the stablecoin contour next to the fiat one rather than instead of it, and check the provider's minimum holding period before conversion, because same-day pass-through is exactly the pattern their own bank reads as transit.
• Keep a second relationship that can take the flow if the first one decides your payer mix is not for them.

This is not about avoiding checks. It is about building a flow that survives them, which is the only version of this that keeps working.