> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Travel Rule

> The Travel Rule is a compliance gate that stands apart from KYC: a user must upload Travel Rule information before any on-chain deposit address can be issued. This page covers three things: what the Travel Rule is, which capabilities the DeCard-Managed model provides, and one flow diagram. Details such as each endpoint's request and response fields and the EDD sub-object breakdown are linked out to the how-to pages.

## 📄 Guide

The **Travel Rule** is a requirement under the global anti-money laundering (AML) framework. It standardises the information exchanged during cross-border and virtual asset transfers so that financial transactions stay transparent and traceable. In the DeCard-Managed model, an end user must upload Travel Rule information before obtaining an on-chain deposit address: **a user who has not completed the upload cannot obtain a deposit address**, and therefore cannot make a cross-border deposit.

<Warning>
  **Prerequisite**: before calling these endpoints, the user must already have been created through the registration endpoint and you must hold their `externalUserId`. The Travel Rule upload should be completed before the user requests an on-chain deposit address.
</Warning>

***

## Capabilities in the DeCard-Managed model

DCS exposes standardised endpoints for managing Travel Rule information. Depending on how deeply you integrate, you can submit it server-side or let the user upload it themselves on a DCS-hosted page:

| Capability                              | Endpoint                                   | Method | Description                                                                                                                       |
| --------------------------------------- | ------------------------------------------ | ------ | --------------------------------------------------------------------------------------------------------------------------------- |
| Upload Travel Rule information          | `/account/v1/update-travel-rule`           | POST   | Submit the user's identity, address, and birth details (only `externalUserId` is required)                                        |
| Query Travel Rule information           | `/account/v2/query-travel-rule`            | GET    | Read back what was submitted, by `externalUserId`                                                                                 |
| Self-service upload via hosted page     | `/redirect/v2/guidance-link`               | POST   | With `action=TRAVEL_RULE`, the user fills in and uploads everything on a DCS-hosted page, so you never collect the sensitive data |
| Generate a pre-upload URL for EDD files | `/account/v1/generate-file-upload-prepare` | POST   | High-risk cases: obtain a presigned URL plus an `objectKey`                                                                       |
| Submit EDD files                        | `/account/v1/upload-edd-file`              | POST   | Submit references to source of funds (SoF) and source of wealth (SoW) evidence                                                    |

DCS focuses on four things: **data standardisation** (a single structure for document types, addresses, dates of birth, and so on), **endpoint support** (upload and query), **file management** (EDD, covering both source of funds and source of wealth), and **process linkage** (tied to obtaining an on-chain deposit address, since requesting an address before the upload is complete is rejected).

> **EDD (Enhanced Due Diligence)**: for high-risk cases such as large cross-border transfers or suspicious activity, DCS lets users submit 12 categories of supporting evidence in total, covering source of funds (SoF, 6 categories) and source of wealth (SoW, 6 categories). The flow is two steps: generate a pre-upload URL and upload the file, then submit the file reference. The full sub-object breakdown and fields are in the how-to links below.

***

## EDD file upload (Enhanced Due Diligence)

For high-risk compliance cases such as large cross-border transfers or suspicious activity, DCS offers EDD (Enhanced Due Diligence) file upload, letting users submit two kinds of supporting evidence: Source of Funds (SoF) and Source of Wealth (SoW). The flow has two steps:

1. **Generate the pre-upload URL**: call POST `/account/v1/generate-file-upload-prepare` with the list of file names to be uploaded, and receive a presigned URL and an `objectKey`.
2. **Submit the EDD files**: upload the files to the URL you received, then call POST `/account/v1/upload-edd-file` to submit the EDD file references for each dimension (each containing `fileName` plus `filePath`/`objectKey`).

**Request fields (EDD submission body)**

| Field               | Type   | Required | Description                                                                     |
| ------------------- | ------ | -------- | ------------------------------------------------------------------------------- |
| `externalUserId`    | string | **Yes**  | External user ID                                                                |
| `requestRef`        | string | **Yes**  | Unique idempotency key, used to prevent duplicate submissions                   |
| `applyId`           | string | No       | Virtual card application ID, to tie the evidence to a specific card application |
| `eddSowSalary`      | object | No       | Source of wealth (SoW) — salary income                                          |
| `eddSowBizRevenue`  | object | No       | Source of wealth — business revenue                                             |
| `eddSowGift`        | object | No       | Source of wealth — gift                                                         |
| `eddSowInheritance` | object | No       | Source of wealth — inheritance                                                  |
| `eddSowInvest`      | object | No       | Source of wealth — investment gains                                             |
| `eddSowOther`       | object | No       | Source of wealth — other                                                        |
| `eddSofSaving`      | object | No       | Source of funds (SoF) — salary savings                                          |
| `eddSofSale`        | object | No       | Source of funds — asset sale                                                    |
| `eddSofBizRevenue`  | object | No       | Source of funds — business revenue                                              |
| `eddSofCrypto`      | object | No       | Source of funds — cryptocurrency                                                |
| `eddSofInvest`      | object | No       | Source of funds — liquidated investments                                        |
| `eddSofOther`       | object | No       | Source of funds — other                                                         |

**EDD sub-object categories** (12 in total: 6 SoW plus 6 SoF, covering both the source of wealth and the source of funds)

| Sub-object          | Dimension        | Description                                                                                     |
| ------------------- | ---------------- | ----------------------------------------------------------------------------------------------- |
| `eddSowSalary`      | Source of wealth | Salary income (employer name, job title, annual income, plus evidence)                          |
| `eddSowBizRevenue`  | Source of wealth | Business revenue (company name, nature of business, annual revenue, plus evidence)              |
| `eddSowGift`        | Source of wealth | Gift (donor, relationship, donor's source of wealth, asset valuation, plus evidence)            |
| `eddSowInheritance` | Source of wealth | Inheritance (name of the deceased, relationship, year of inheritance, valuation, plus evidence) |
| `eddSowInvest`      | Source of wealth | Investment gains (investment type, valuation, plus evidence)                                    |
| `eddSowOther`       | Source of wealth | Other sources of wealth (description plus evidence)                                             |
| `eddSofSaving`      | Source of funds  | Salary savings (employer name, job title, annual income, plus evidence)                         |
| `eddSofSale`        | Source of funds  | Asset sale (evidence)                                                                           |
| `eddSofBizRevenue`  | Source of funds  | Business revenue (company name, nature of business, annual revenue, plus evidence)              |
| `eddSofCrypto`      | Source of funds  | Cryptocurrency (platform name, type of holding, plus evidence)                                  |
| `eddSofInvest`      | Source of funds  | Liquidated investments (investment type, valuation, plus evidence)                              |
| `eddSofOther`       | Source of funds  | Other sources of funds (description plus evidence)                                              |

> Every sub-object carries a `docUrls` array (`{ fileName, filePath }`) pointing at files already uploaded through the pre-upload URL. For the full field specification, such as the `recurringGifts` substructure of `eddSowGift` or which fields are mandatory in each sub-object, see the endpoint API reference page.

**Request example** (EDD file submission, showing only some sub-objects; placeholder data)

```http theme={null}
POST /account/v1/upload-edd-file HTTP/1.1
Host: {{dicard-server}}
Content-Type: application/json
```

```json theme={null}
{
  "externalUserId": "<externalUserId>",
  "requestRef": "<idempotency-key>",
  "applyId": "<applyId>",
  "eddSowSalary": {
    "employerName": "<employer>",
    "jobTitle": "<title>",
    "annualIncome": "100000",
    "docUrls": [
      { "fileName": "payslip.pdf", "filePath": "<objectKey-from-prepare>" }
    ]
  },
  "eddSofSaving": {
    "employerName": "<employer>",
    "jobTitle": "<title>",
    "annualIncome": "100000",
    "docUrls": [
      { "fileName": "bank_statement.pdf", "filePath": "<objectKey-from-prepare>" }
    ]
  }
}
```

**Response** (the envelope is always `{ code, message, messageDetail, data }`; on a successful submission **`data` is `null`**)

```json theme={null}
{
  "code": "<success code, e.g. SYS_SUCCESS>",
  "message": "",
  "messageDetail": {},
  "data": null
}
```

***

## Flow diagram

<Frame>
  <img className="block dark:hidden" src="https://mintcdn.com/dcs-0bf7a937/oUoeUKtwWWK2o-Li/imgs/en/diagrams/va-travel-rule-light.svg?fit=max&auto=format&n=oUoeUKtwWWK2o-Li&q=85&s=b8b83a6474e359d4f97a071b3dff1240" alt="Travel Rule upload and deposit enablement paths" width="630" height="632" data-path="imgs/en/diagrams/va-travel-rule-light.svg" />

  <img className="hidden dark:block" src="https://mintcdn.com/dcs-0bf7a937/oUoeUKtwWWK2o-Li/imgs/en/diagrams/va-travel-rule-dark.svg?fit=max&auto=format&n=oUoeUKtwWWK2o-Li&q=85&s=1a20b2a86d6c6b80e47d9d537458f520" alt="Travel Rule upload and deposit enablement paths" width="630" height="632" data-path="imgs/en/diagrams/va-travel-rule-dark.svg" />
</Frame>

> Requesting an on-chain deposit address before the Travel Rule upload is complete will be rejected. The `address` field set in the query response of `/account/v2/query-travel-rule` is not symmetrical with the upload request body (the query returns only `city`, `postalCode`, and `addressLines`), so code against the endpoint field specification.

***

## Next steps

* Full request and response fields and examples for upload and query: [Crypto Deposits](./crypto-deposit) (the Travel Rule is a prerequisite step for deposits; includes the `update-travel-rule` field table)
* Full parameters for the hosted page with `action=TRAVEL_RULE`: [H5 KYC / card application guidance page](../../integration-resources/h5-kyc-guidance) (for the 12 SoF/SoW sub-objects, see the "EDD file upload" section above)
* The overall compliance flow and where KYC sits in it: [Compliance · Overview](../../basic-concepts/compliance-kyc-flow)
* Obtaining an on-chain deposit address (the step downstream of the Travel Rule): [Crypto Deposits](./crypto-deposit)
* Full endpoint field specifications: `POST /account/v1/update-travel-rule`, `GET /account/v2/query-travel-rule`, `POST /redirect/v2/guidance-link`, `POST /account/v1/generate-file-upload-prepare`, `POST /account/v1/upload-edd-file`