← SCENARIOS
SCENARIO

Deposit from one wallet, withdrawal to another

On its own this is ordinary: people change wallets, exchanges rotate deposit addresses, a custodial withdrawal never comes back to the same place. It is also the shape of a pass-through: fund, barely trade, withdraw somewhere else. From the on-chain data alone, the two look the same.

What separates them is whether the customer can demonstrate control of the destination, and whether the funding and withdrawal sit on one customer record rather than in two unrelated screenings.

What happens

  1. Ask the customer for a signature

    A wallet-ownership request sends the customer a short message to sign with the destination wallet. It moves no funds and costs nothing. A valid signature establishes control. A customer who will not produce one has told you something too.

  2. The coverage matrix records which of those you got

    walletOwnership reads COMPLETE when a signature was verified and NOT_AVAILABLE when none was held. The file never says "verified" because somebody ticked a box.

  3. The withdrawal is linked to the customer record

    Passing a customer reference puts the deposit and the withdrawal request on the same record, so the lifecycle pattern is visible in the case rather than reconstructed afterwards from two screenings nobody connected.

  4. Travel Rule data is recorded or marked MISSING

    If no originator or beneficiary data was held for the transfer, the coverage says so. Nothing is inferred.

The shape of it

ILLUSTRATIVE SHAPE · The shape of the coverage block for this case. It is not a captured response, because the interesting values depend on what your customer actually produced. Run it in the sandbox to get your own, with your policy applied.

{
  "coverage": {
    "walletOwnership": "COMPLETE",        // a signature from the destination wallet was verified
    "customerBehaviour": "COMPLETE",      // funding history was evaluated against your rules
    "travelRule": "MISSING",              // no originator/beneficiary data was held for this transfer
    "sanctions": "COMPLETE",
    "issuerFreeze": "COMPLETE"
  }
}

COMPLETE against walletOwnership is the only line on this page that is hard to obtain and hard to fake. It is the difference between a customer who says the wallet is theirs and one who proved it.

MISSING is not a failure state. It records that a mandatory check could not run, which is what an examiner is entitled to know.

What this does not do

A signature proves control of a key at a moment in time. It does not prove the customer is the beneficial owner of the funds, and the file should not be read as saying so.

KYTGate does not decide whether to permit the withdrawal. It establishes what is known and applies your policy; the decision remains yours and is recorded as such.

Next

How ownership verification works →
The message format, what a valid signature proves, and what it does not.
Try it against your own addresses →
Fifty screenings a month, isolated tenant, real data.

Questions

What if the customer cannot sign because the funds are on an exchange?

Then walletOwnership stays NOT_AVAILABLE and the file says so. Many destinations are custodial and cannot sign, and the record should say that control was not demonstrated.

Does a signature request touch the customer's funds?

No. It is a message signature: no transaction, no gas, no movement. The request wording says this to the customer in those terms.

SEE IT ON YOUR OWN DATA

One e-mail link gives you an isolated tenant and an API key. The screen that shows the key also shows a first call with a real listed address already in it. The sandbox includes fifty screenings a month on real data and is deleted after seven days.

Get a sandbox Download the sample pack