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 and Wallet Risk Screening Data.
At a glance — how the two checks apply to each payment direction:
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. 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.
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, 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[], and the raw transfer record is passed through in provider_metadata[].
Testing your inbound handling In sandbox and staging, 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.
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.
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:
Code
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.
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 for the complete list and how each value maps to the risk_status_reason_category field on the payment record.