Compliance-gated payments (KYT)

What you’ll build

A receiving setup where every wallet that tries to pay you is screened against sanctions and risk lists before the payment can settle. If a wallet fails screening, the payment is blocked and the payer never reaches the sign step. A payment destination policy is the default for payments created against that destination, so you can keep some flows compliance-gated and others permissive. Audience: regulated fintech, marketplaces with compliance obligations, B2B platforms with KYC/AML requirements, any merchant who needs to refuse payments from sanctioned or high-risk addresses. This is a Know Your Transaction (KYT) policy, not a Know Your Customer (KYC) flow. There’s no document upload or identity verification on the payer side — just a wallet-address screening.

How it works

When you create a payment destination via the Auth API, you can attach a payment access policy that turns KYT screening on by default for that destination:

Payer opens your payment link

Wallet screening

Before the payment options view loads, Request Network’s compliance gate screens the connected wallet (and, for smart-account payments, the parent EOA as well).

Screening passes

The payment continues normally.

Screening fails

The secure payment page shows a policy-failure view and the payer cannot reach the sign step.

You can also choose how much information is visible to the payer until the wallet has passed screening — see Privacy options below.

Configure a KYT-gated destination

Pass an accessPolicy object when creating a payee destination:

curl -X POST "https://auth.request.network/v1/payee-destination" \
  -H "Cookie: session=YOUR_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tokenAddress": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
    "chainId": 1,
    "accessPolicy": {
      "mode": "kyt_all_wallets",
      "screeningProvider": "hypernative",
      "hideUntilApproved": true,
      "hidePayeeAddress": true
    }
  }'

Field	Type	Description
`mode`	`"off"` \| `"kyt_all_wallets"`	`off` is the default (no screening). `kyt_all_wallets` screens every payer wallet that connects.
`screeningProvider`	`"hypernative"` \| `"merklescience"`	KYT provider used for screening. Required when `mode` is `kyt_all_wallets` (omit it when `mode` is `off`). Choose `hypernative` or `merklescience` (Merkle Science, a multi-chain option).
`hideUntilApproved`	`boolean`	When `true`, the payment metadata (amount, currency, recipient) is hidden until the payer’s wallet has passed screening.
`hidePayeeAddress`	`boolean`	When `true`, the payee wallet address is masked throughout the payer flow — no ENS resolution, no copy button, no explorer link.

Both privacy flags are independent of mode — you can show payment details upfront and still gate the actual payment behind screening, or hide everything until the gate clears.

Destinations without an accessPolicy do not screen by default. A payment’s accessPolicy or Client ID KYT plan may still turn screening on.

How KYT settings are resolved

The destination’s accessPolicy is the default. These rules resolve the KYT mode and screening provider: A Client ID has at most one KYT plan. During hosted onboarding, the orchestrator defines it or the platform chooses it, never both.

A payment-specific policy — When you create a Secure Payment through the Dashboard or API without a Client ID KYT plan, you can include an accessPolicy. Its mode and screeningProvider apply to that payment instead of the destination default.
A Client ID KYT plan — When an orchestrator creates a payment with paired authentication, the Client ID may have a KYT plan. Whether the platform chose it during hosted onboarding or the orchestrator defined it, the plan sets the payment’s KYT mode and provider instead of the destination default. A platform can update its own plan in the Dashboard, but cannot change an orchestrator-defined plan. The payment request cannot set a different mode or screeningProvider. See Orchestrator KYT plans.
No Client ID KYT plan — A payment-specific policy can override the destination default. Without one, the payment uses the destination policy.

A Client ID KYT plan fixes only the KYT mode and screeningProvider. A payment can still set a payer-wallet allowlist and, when KYT is enabled, privacy options. Request Network stores the resolved configuration when it creates a Secure Payment. Updating a destination policy or a platform-defined Client ID KYT plan affects payments created afterwards, not existing payment links.

Privacy options

hideUntilApproved and hidePayeeAddress solve two different concerns:

hideUntilApproved — useful when the payment terms themselves are sensitive (commercial pricing, B2B contracts). The payer connects a wallet, gets screened, and only sees the amount/recipient if their wallet clears.
hidePayeeAddress — useful when you want to keep your receiving wallet from being scraped and re-used by the payer outside this payment flow. The payer can still pay (the secure payment app builds the transaction with the real address), but they don’t see the address copy/explorer-link affordances.

You can combine both for the strictest setup, or use either independently.

What payers experience

Scenario	Payer view
Wallet passes screening	Standard payment flow — connect, pick chain/token, sign.
Wallet fails screening	Policy-failure view; sign button is disabled. The payer is told the payment cannot proceed and to contact you for an alternative.
Screening in progress	Brief loading state between wallet connect and payment options view.

For smart-account payments on EVM, the gate screens both the connected EOA and the smart-account wallet — both must pass before payment proceeds.

Update or remove a policy

Change the policy on an existing destination by re-issuing the create call (the active destination is updated in place) or by calling PUT /v1/payee-destination:

curl -X PUT "https://auth.request.network/v1/payee-destination" \
  -H "Cookie: session=YOUR_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tokenAddress": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
    "chainId": 1,
    "accessPolicy": { "mode": "off", "hideUntilApproved": false, "hidePayeeAddress": false }
  }'

Setting mode: "off" reverts the destination to standard, unscreened behavior for new payments. Existing payment links retain the screening configuration recorded when they were created.

When KYT screening doesn’t replace your own checks

KYT screens individual wallet addresses against external sanctions and risk lists. It does not:

Verify payer identity (use KYC tooling for that).
Prove origin of funds — addresses can pass screening but still be linked to off-platform behavior you’d flag yourself.
Replace transaction-monitoring on your side after the fact.

Treat KYT as a first-line filter that blocks the most obvious cases, layered with whatever else your compliance program requires.

Hypernative Standard policy

Request Network offers two KYT screening providers: Hypernative and Merkle Science (a multi-chain option). When mode is kyt_all_wallets, you must set screeningProvider to one of them — there is no default. The Hypernative Standard policy defines the high-risk categories and related exposure thresholds applied when you screen with Hypernative. See Hypernative Standard Screening Policy for the full category list, exposure thresholds, and limitations.

Hypernative Standard Screening Policy

Review the default KYT policy categories, thresholds, and limitations.

Payee destinations

Full payee-destination reference, including the accessPolicy field.

🚀 Get Started

🎯 Use Cases

What you’ll build

How it works

Configure a KYT-gated destination

How KYT settings are resolved

Privacy options

What payers experience

Update or remove a policy

When KYT screening doesn’t replace your own checks

Hypernative Standard policy

Hypernative Standard Screening Policy

Payee destinations

​What you’ll build

​How it works

​Configure a KYT-gated destination

​How KYT settings are resolved

​Privacy options

​What payers experience

​Update or remove a policy

​When KYT screening doesn’t replace your own checks

​Hypernative Standard policy

​Related

Hypernative Standard Screening Policy

Payee destinations

What you’ll build

How it works

Configure a KYT-gated destination

How KYT settings are resolved

Privacy options

What payers experience

Update or remove a policy

When KYT screening doesn’t replace your own checks

Hypernative Standard policy

Related