Pre-Transfer vs Post-Transfer Wallet Screening

There are two moments to screen a crypto transaction, and they answer two different questions. Before value moves, you screen the wallet address to decide whether to let the transaction happen at all. After value settles, you screen the transaction hash to record what actually moved and re-assess it against the latest intelligence. The first is a gate; the second is a ledger.

Didit's Wallet Screening API supports both. Pre-transfer screening takes a wallet address and returns a risk verdict before you accept a deposit or release a withdrawal. Post-transfer screening takes a transaction hash and assesses a confirmed transaction after the fact. Both return the same 0–100 risk score with LOW/MEDIUM/HIGH/CRITICAL bands and a source-of-funds breakdown, and both cost $0.02 per screening.

This guide explains the difference and how to wire each one into a real flow.

Key takeaways

• Pre-transfer = address, before value moves. Screen a wallet address to gate a deposit or withdrawal before it happens.
• Post-transfer = transaction hash, after settlement. Screen a confirmed transaction (by payment_reference_id) for record-keeping and ongoing review.
• Same verdict shape for both — a 0–100 risk score, a LOW/MEDIUM/HIGH/CRITICAL band, and exposure by source-of-funds category.
• Use both together in most flows: pre-transfer to decide, post-transfer to document and re-check.
• Triggered by currency_kind: "crypto" plus a direction (INBOUND / OUTBOUND); override per call with include_crypto_screening.
• $0.02 per screening with BYOK (Crystal or Merkle Science), regardless of which timing you use.

What each one screens

Pre-transfer screening evaluates a wallet address. You don't yet know that any value will move — you're asking, "if I accept funds from (or send funds to) this address, what am I exposed to?" The API traces the address's inbound and outbound history and returns its risk. This is the decision point: pass, hold for review, or decline before anything settles.

Post-transfer screening evaluates a specific transaction by its hash. The value has already moved; you're recording the risk of what happened and keeping it current. Because on-chain labels evolve — an address can be added to a sanctions list after you transacted with it — post-transfer screening (and periodic re-screening) keeps your records accurate for audit and ongoing-monitoring obligations.

Why it matters

Choosing the wrong moment creates real gaps. Screen only post-transfer and you've already accepted the funds before you knew they were risky — you're now unwinding a settled transaction instead of declining a pending one. Screen only pre-transfer and your records go stale: the verdict you captured at deposit time doesn't reflect intelligence that surfaced afterward, which weakens any audit trail and misses retroactive sanctions designations.

Regulators and good practice both point to the same answer: gate at the front with pre-transfer screening, then maintain an accurate, re-checkable record with post-transfer screening. Running both is why the $0.02 per-screening price matters — at that cost, screening twice is still an order of magnitude cheaper than a single screening on a legacy subscription.

Technical details

Both modes run on the unified /v3/ API inside Transaction Monitoring. The difference is whether you pass a wallet address or a transaction reference.

Pre-transfer — screen an address before accepting a deposit:

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "dep_61a0",
    "category": "finance",
    "currency_kind": "crypto",
    "direction": "INBOUND",
    "wallet_address": "0x4d2a...91bc",
    "include_crypto_screening": true,
    "subject": { "vendor_data": "user_5012", "role": "RECEIVER" }
  }'

Post-transfer — screen a settled transaction by its hash:

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "wd_77f3",
    "category": "finance",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "payment_reference_id": "0xabc123...def",
    "include_crypto_screening": true,
    "subject": { "vendor_data": "user_5012", "role": "SENDER" }
  }'

Both return the same verdict structure:

{
  "wallet_screening": {
    "risk_score": 41,
    "risk_band": "MEDIUM",
    "exposure": [
      { "category": "HIGH_RISK_EXCHANGE", "type": "DIRECT", "share": 0.27 }
    ]
  }
}

The trigger. Screening fires when currency_kind is "crypto" and a direction (INBOUND or OUTBOUND) is set. The default — whether crypto transactions screen automatically — is configured in Console → Transactions → Settings, and include_crypto_screening overrides it per call.

The key field. Pass a wallet_address for pre-transfer; pass the transaction hash as payment_reference_id for post-transfer.

Price. $0.02 per screening, either mode, with BYOK (Crystal or Merkle Science).

When to use each

Scenario	Use	Why
Accepting a deposit	Pre-transfer (address)	Decide before the funds are yours
Releasing a withdrawal	Pre-transfer (destination address)	Block sending to a risky wallet
Recording a settled transfer	Post-transfer (hash)	Accurate audit trail of what moved
Periodic re-screening	Post-transfer (hash)	Catch retroactive sanctions designations
Both gating and record-keeping	Both	Gate at the front, document after

Use cases

• Crypto exchanges — pre-transfer on every deposit and withdrawal to gate flow; post-transfer to keep a complete, re-checkable ledger.
• On/off-ramps — pre-transfer to block conversions involving high-risk wallets before settlement.
• Custodians — pre-transfer at intake, post-transfer re-screening on stored assets as labels evolve.
• Wallets — pre-transfer to warn a user before they send to a flagged address.
• VASPs — post-transfer records paired with Travel Rule data for a defensible compliance trail.

How to integrate with Didit

1. Set the default in Transactions → Settings — choose whether crypto transactions screen automatically and which provider key to use.
2. Gate at the front. Before accepting a deposit or releasing a withdrawal, POST /v3/transactions/ with the wallet_address and act on the band.
3. Record after settlement. Once a transaction confirms, screen it again with the hash as payment_reference_id.
4. Handle alerts. HIGH/CRITICAL screenings open alerts in the built-in case manager for investigation and SAR filing.

Frequently asked questions

What's the practical difference between pre- and post-transfer screening?

Pre-transfer screens a wallet address before value moves, so you can decline. Post-transfer screens a settled transaction by its hash, so you have an accurate, re-checkable record.

Do I need to do both?

Most teams should. Pre-transfer gates the flow; post-transfer keeps records current — including catching addresses added to sanctions lists after you transacted.

How do I screen a transaction hash?

Pass the hash as payment_reference_id on POST /v3/transactions/ with currency_kind: "crypto" and a direction.

Does running both cost twice as much?

Yes — $0.02 each — but at that price two screenings are still far cheaper than one screening on a legacy blockchain-analytics subscription.

Can I turn screening on only for some transactions?

Yes. Set a default in Console → Transactions → Settings and override per call with include_crypto_screening.

Ready to get started?

Read the Wallet Screening overview in the docs, see how it fits the platform on the Wallet Screening product page, and check per-call pricing on the pricing page. When you're ready, start free — 500 free KYC checks every month, and wallet screening at $0.02 per screening.