> ## Documentation Index
> Fetch the complete documentation index at: https://requestnetwork-fix-req-350-remove-unused-webhook-events.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance-gated payments (KYT)

> Screen payer wallets for sanctions and risk before accepting a payment. Set a default KYT policy on each payment destination.

## 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](https://auth.request.network/open-api/#tag/payee-destination), you can attach a **payment access policy** that turns KYT screening on by default for that destination:

<Steps>
  <Step title="Payer opens your payment link" />

  <Step title="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).
  </Step>

  <Step title="Screening passes">
    The payment continues normally.
  </Step>

  <Step title="Screening fails">
    The secure payment page shows a policy-failure view and the payer cannot reach the sign step.
  </Step>
</Steps>

You can also choose how much information is visible to the payer until the wallet has passed screening — see [Privacy options](#privacy-options) below.

## Configure a KYT-gated destination

Pass an `accessPolicy` object when creating a payee destination:

```bash theme={null}
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.

<Note>
  Destinations without an `accessPolicy` do not screen by default. A payment's `accessPolicy` or Client ID KYT plan may still turn screening on.
</Note>

## 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.

```mermaid theme={null}
flowchart TD
    A[Create incoming Secure Payment] --> B{Which KYT plan, if any, is set for this Client ID?}
    B -->|Orchestrator-defined| C[Use orchestrator's Client ID plan]
    B -->|Platform-defined| D[Use platform's Client ID plan]
    B -->|None| E{Payment sets a mode or provider?}
    E -->|Yes| F[Use payment accessPolicy]
    E -->|No| G[Use destination accessPolicy]
    C --> H[Store resolved configuration]
    D --> H
    F --> H
    G --> H
```

* **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](/orchestrators/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](/use-cases/restrict-payer-wallets) and, when KYT is enabled, [privacy options](#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`:

```bash theme={null}
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](/use-cases/hypernative-standard-screening-policy) for the full category list, exposure thresholds, and limitations.

## Related

<CardGroup cols={2}>
  <Card title="Hypernative Standard Screening Policy" href="/use-cases/hypernative-standard-screening-policy" icon="shield-halved">
    Review the default KYT policy categories, thresholds, and limitations.
  </Card>

  <Card title="Payee destinations" href="/api-features/payee-destinations" icon="location-dot">
    Full payee-destination reference, including the `accessPolicy` field.
  </Card>
</CardGroup>