# Compliance and Risk Management

Tesser enables two compliance and risk checks for stablecoin payments: **Travel Rule data exchange** and **wallet risk screening**. For the field-level detail, see [Payment Participants](/overviews/payment-participants) and [Wallet Risk Screening Data](/overviews/wallet-risk-screening).

At a glance — how the two checks apply to each payment direction:

<Mermaid
  chart={`flowchart TD
  P[Payment] --> D{Direction?}
  D -->|Outbound| O1[Required Travel Rule data attached;<br/>authorization may be requested<br/>from the beneficiary VASP]
  O1 --> O2[Destination wallet screened]
  O2 --> O3{Approving<br/>risk_status?}
  O3 -->|Yes| O4[Payment executes]
  O3 -->|No| O5[Payment does not execute]
  D -->|Inbound| I0{Originator VASP requests<br/>authorization first?}
  I0 -->|Yes| I1{Beneficiary name<br/>matches your records?}
  I1 -->|No| IR[Authorization rejected —<br/>funds are not sent]
  I1 -->|Yes| I2[Funds land on-chain]
  I0 -->|No — direct<br/>on-chain transfer| I2
  I2 --> I3[Sending wallet screened — advisory]
  I3 --> I4[Available balance credits at<br/>block finality, regardless of<br/>screening outcome]
  I4 --> I5[You consume risk_status to decide<br/>whether to credit your end user]`}
/>

Inbound payments also create records for a sender Tesser has not seen before. A transfer from an unrecognized wallet address produces an unmanaged account representing that address — see [Receive an Inbound Payment to a Wallet](/how-tos/receive-an-inbound-payment-to-a-wallet#sending-wallet-account-handling). Separately, where a Travel Rule or wallet screening provider names an entity in the flow that Tesser cannot match to your records, Tesser creates a Counterparty for that entity — see [Payment Participants](/overviews/payment-participants).

## Travel Rule Data Exchange

The Travel Rule requires financial institutions to transmit originator and beneficiary identity and account information alongside qualifying transfers. For stablecoin payments, that data does not travel with the blockchain transaction itself. Instead, it must be transmitted between Virtual Asset Service Providers (VASPs) through a Travel Rule data-exchange platform. 

Tesser is integrated with [Notabene](https://notabene.id/), a leading provider with 1,900+ VASPs in its network. 

**On outbound payments**
- Tesser can request authorization from the beneficiary VASP prior to sending funds on-chain, per your organization's policy and subject to the beneficiary VASP's ability to respond to authorization requests. This allows your organization to confirm that the (economic) owner of the destination wallet address as identified by the Beneficiary VASP is the intended beneficiary. (In other words, do you and the Beneficiary VASP agree on whom you are planning to send funds to?)
- Tesser will submit the required originator and beneficiary information for the beneficiary jurisdiction to the Beneficiary VASP. During onboarding, your organization will be informed of required data points for originators (your organization's customers or end-users) and beneficiaries for the planned jurisdictions. When you register originators and beneficiaries via API, Tesser enforces collection of those data points.


**On inbound payments**
- The originator VASP may request authorization before sending funds on-chain. When this occurs, Tesser will evaluate the Beneficiary identity info sent by the Originator VASP against your beneficiary records. If the name of Beneficiary supplied by the Originator VASP for the destination wallet address does not match the identity info you have for that wallet, Tesser will reject the authorization. This prevents funds being sent erroneously to the wrong beneficiary, which can create an exception flow. 
- For payments above your jurisdiction's threshold (e.g. USD 3000 in the United States), Tesser will enforce policies with Notabene to require originator VASPs to transmit all required Travel Data. 

**On all payments**
Identity data received through a Travel Rule provider-facilitated flow is recorded on the payment: the reconciliation outcome for each party appears in [`participants[]`](/overviews/payment-participants), and the raw transfer record is passed through in [`provider_metadata[]`](/overviews/payment-participants#raw-travel-rule-data).

**Testing your inbound handling**
In sandbox and staging, [Simulate a Travel Rule Inbound Payment](/how-tos/simulate-a-travel-rule-inbound-payment) lets you rehearse an inbound Travel Rule authorization and rejection against a real Notabene counterparty, without a second VASP of your own.

## Wallet Risk Screening

Every payment's external wallet is screened via a blockchain analytics provider to identify potential risks about the receiving wallet (outbound payment) or sending wallet (inbound payment). The screen evaluates the wallet's activity and exposure aggregated across **all chains the wallet exists on,** not only the network for this particular payment, to ensure the full scope of the wallet's risk is identified.

Which wallet is screened, and what the outcome gates, depends on direction:

| Direction | Screened wallet | What the outcome gates |
| --- | --- | --- |
| **Inbound** | The **sending** wallet | **Advisory.** Funds are credited to your wallet's available balance at block finality regardless of the screening outcome. The result is a signal you consume to decide whether to credit your end user, quarantine, or return funds. |
| **Outbound** | The **destination** wallet, or the destination VASP wallet when the beneficiary is VASP-hosted | **Gating.** The payment does not execute unless screening resolves to an approving outcome. |


### What screening evaluates

The screened wallet is analyzed across several kinds of signals:

- **Ownership** — the wallet's own risky activity.
- **Counterparty** — the wallet has directly transacted with a risky wallet.
- **Indirect** — the wallet has indirect (multi-hop) exposure to a risky wallet.
- **Behavioral** — the wallet exhibits transaction patterns commonly associated with obfuscation or laundering techniques.
- **Entity attribution** — the wallet is attributed to a known entity (e.g. an exchange, an issuer, a custody service, a DeFi protocol/contract/developer, a sanctioned actor), with an accompanying confidence level.

See the full list of [wallet screening risk categories](/overviews/wallet-screening-risk-categories).

### How the decision is made

Screening produces one `risk_status` per payment. Multiple inputs are used to determine the `risk_status`.

- **Allowlist/Blocklist.** Your organization can maintain an **allowlist** of trusted counterparties and a **blocklist** of prohibited ones. A blocklisted counterparty is rejected ahead of every other check; an allowlisted counterparty is approved, bypassing the remaining checks. If a counterparty appears on both lists, the blocklist wins. *Note: The confidence score for an external entity must exceed your organization's threshold, otherwise Tesser will not attempt to match the identified entity to the entries on the allowlist or blocklist.
- **Severe findings about the wallet and its activity automatically reject.** A configurable set of severe categories (for example, sanctions or terrorist financing) rejects the payment when found in the wallet's own on-chain activity or behavior pattern, regardless of volume.
- **The screened wallet is classified as VASP-hosted or self-hosted.** The classification selects which materiality thresholds apply in the next step. A wallet is treated as VASP-hosted when the flow can be facilitated through a Travel Rule data provider, or if the entity the wallet screening provider attributes to the wallet carries a custodial entity category (for example, Exchange or Financial Services); a wallet with no entity attribution is treated as self-hosted.
- **Remaining indicators have their materiality thresholds applied.** Other findings count only when they are *material* — when the exposure exceeds configurable thresholds relative to the wallet's total volume or in absolute dollar terms. This is what lets a legitimate, high-volume custodial wallet pass despite incidental contact with flagged addresses. **Material findings resolve by severity: low and medium severity approve automatically, high severity routes the payment to manual review, and severe rejects.**
- **A failed screen is automatically rejected by default.** If screening cannot complete, Tesser applies your configured screening-failure action (default: automatically rejected). A screening failure is distinguishable on the payment record from a risk-based rejection.

Every outcome is reconstructable from the payment record: the signals that determined it — with configured thresholds and observed values — appear in `risk_status_reasons[]`, and the raw screening response is passed through in `provider_metadata[]`. See [Wallet Risk Screening Data](/overviews/wallet-risk-screening).

### Risk statuses

| `risk_status` | Meaning |
| --- | --- |
| `unchecked` | Initial state; screening has not yet resolved. |
| `automatically_approved` | No material risk found. |
| `awaiting_decision` | Material exposure warranting review by your organization. |
| `automatically_rejected` | A severe finding, a blocklisted counterparty, or a screening failure (per your configured failure action). |
| `manually_approved` | A reviewer in your organization approved the payment. |
| `manually_rejected` | A reviewer in your organization rejected the payment. |

Every `risk_status` change fires a `payment.risk_updated` webhook.

## Manual Review Process

Payments with `risk_status` of `awaiting_decision` can be resolved through the risk review endpoint:

```bash
curl -X POST https://api.tesser.xyz/v1/payments/{paymentId}/review \
  -H "Authorization: Bearer your-access-token" \
  -H "Content-Type: application/json" \
  -d '{
    "is_approved": true
  }'
```

After a decision is recorded, `risk_status` transitions to `manually_approved` or `manually_rejected`, and `risk_reviewed_by` and `risk_reviewed_at` are populated. Payments can also be reviewed in the Tesser dashboard.

## Testing Risk Checks

To build and test your compliance handling against every outcome (`automatically_approved`, `awaiting_decision`, and `automatically_rejected`), Tesser provides testing mechanisms in sandbox for both directions: known test beneficiary addresses for outbound payouts and a simulate endpoint for inbound payments. See [Test Compliance Risk Checks](/how-tos/test-compliance-risk-checks).

## What Your Organization Can Configure

Each of the following ships with a Tesser default and can be tuned for your organization:

- **Allowlist and blocklist** — the counterparties on each list.
- **Severe categories** — the set of categories that reject automatically when found in the wallet's own ownership or behavior.
- **Custodial entity categories** — the entity categories treated as an indication the wallet is VASP-hosted.
- **Materiality thresholds** — the relative (% of wallet volume) and absolute (dollar) thresholds, per payment direction and wallet custody type.
- **Screening-failure action** — how a failed screen resolves, per direction.
- **Entity attribution confidence threshold** — how confident an entity attribution must be before Tesser relies on it.

Contact us to review or change your organization's configuration.


## Travel Rule Information Transmitted

Account information is collected and transmitted as part of Travel Rule compliance for stablecoin payouts or fiat payouts:

| **Information transmitted** | **Required for Originator** | **Required for Beneficiary** | **Notes** |
| --- | --- | --- | --- |
| **Legal Name** | Individual's legal first and last name, or Business's legal entity name | Individual's legal first and last name, or Business's legal entity name |  |
| **Physical Address** | Legal address of the individual or business. (Street address, City, State/District/Region, Postal Code, Country) | Legal address of the individual or business. (Street address, City, State/District/Region, Postal Code, Country) | No P.O. Boxes or virtual addresses. |
| **Legal Entity Identifier** | Required for business originators of fiat payouts. Not required for individuals. | Not required for beneficiaries | Legal entity Identifier may be a registration number or tax ID. |
| **Account Identifier*** | Account Number or IBAN. | Account Number, IBAN, or Wallet Address. | For cash-funded remittance transaction, will be a unique identifier for the originator or transaction |
| **Financial Institution (FI) info** | Name and Identifier of the FI | Name and Identifier of the FI (For fiat payouts only) |  |

> *For Travel Rule purposes, information about the originator's fiat account is typically transmitted to beneficiary financial institutions, unless wallets are provisioned for *and* self-custodied by the originator. When your organization is the custodian of the wallets, the fiat bank account that ultimately funds the transaction is identified in the payment instruction via the `funding_account_id`.

## Wallet Risk Categories

Wallets are screened against the screening provider's full set of risk categories and behavioral patterns. See [Wallet Screening Risk Categories](/overviews/wallet-screening-risk-categories) for the complete list and how each value maps to the `risk_status_reason_category` field on the payment record.