A counterparty is one of three kinds. The kind determines which endpoint you call and, for self-hosted wallets, the subType you pass.

Kind	Endpoint	`subType` field
`VASP`	`POST /counterparty/vasp`	n/a
`OWNED`	`POST /counterparty/self-hosted`	`"OWNED"`
`THIRD_PARTY`	`POST /counterparty/self-hosted`	`"THIRD_PARTY"`

Regulatd (`VASP`) Counterparties

The user is sending to or receiving from a regulated exchange or VASP.

POST /api/v1/travel-rule/counterparty/vasp
Authorization: <HMAC>

{
  "userId": "<uuid>",
  "address": "0xabc...",
  "currency": "ETH",
  "network": "ETH",
  "vaspId": "<id from /vasps search>",
  "customerIdentificationNumber": "<the user's account id at that VASP>"
}

To find a vaspId, search the directory:

POST /api/v1/travel-rule/vasps
{ "search": "Kraken", "limit": 25 }

Self Hosted (`OWNED`) Counterparties

The user's own external wallet. Above the EUR threshold you must also prove the user controls it. The cleanest pattern is to provide the signature when you declare:

POST /api/v1/travel-rule/counterparty/self-hosted
Authorization: <HMAC>

{
  "userId": "<uuid>",
  "address": "0xabc...",
  "currency": "ETH",
  "network": "ETH",
  "subType": "OWNED",
  "signature": "<chain-specific signature over signedMessage>",
  "signedMessage": "I am verifying ownership of the wallet address 0xabc... as customer <userId>. This message was signed on DD/MM/YYYY to confirm my control over this wallet."
}

The signedMessage template is enforced server-side. The date is DD/MM/YYYY in UTC and must be yesterday, today, or tomorrow when the request arrives.

Chain	Signature scheme
Ethereum, Polygon, BNB Smart Chain	EIP-191 `personal_sign`
Bitcoin	BIP-137
Solana	Ed25519

If you prefer to register the address now and verify later, omit signature and signedMessage. Before the user exceeds the threshold, submit the signature with PATCH:

PATCH /api/v1/travel-rule/counterparty/:counterpartyId
Authorization: <HMAC>

{
  "userId": "<uuid>",
  "method": "WALLET_SIGNATURE",
  "signature": "<...>",
  "signed_address": "0xabc...",
  "message": "I am verifying ownership of the wallet address 0xabc... as customer <userId>. This message was signed on DD/MM/YYYY to confirm my control over this wallet."
}

Other (`THIRD_PARTY`) Counterparties

The user is transacting with someone else's wallet. Provide identifying information for the address owner.

POST /api/v1/travel-rule/counterparty/self-hosted
Authorization: <HMAC>

{
  "userId": "<uuid>",
  "address": "0xabc...",
  "currency": "ETH",
  "network": "ETH",
  "subType": "THIRD_PARTY",
  "entityType": "NATURAL",
  "firstName": "Jane",
  "lastName": "Doe",
  "country": "DE",
  "dateOfBirth": "1990-01-01",
  "placeOfBirth": "Berlin"
}

For a legal entity, use entityType: "LEGAL" with legalName (and optionally lei) instead of the natural-person fields.

THIRD_PARTY addresses cannot transact above the EUR threshold. Withdrawals are blocked; deposits are held for manual review.

Listing declared counterparties

POST /api/v1/travel-rule/counterparty
{ "userId": "<uuid>", "filter": "SELF_HOSTED" | "VASP" | "ALL", "page": 1, "limit": 20 }

filter is optional. "SELF_HOSTED" returns both OWNED and THIRD_PARTY declarations; "VASP" returns VASP declarations; "ALL" (the default) returns everything.

Returns { items, total, page }. Each item carries counterpartyId, counterpartyAddress, blockchain, type, subType, status, disabled, counterpartyData, and createdAt.