Travel Rule - DCS Technical Documentation

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

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.

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:

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

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

{
  "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)

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

Flow diagram

Travel Rule upload and deposit enablement paths

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 (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 (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
Obtaining an on-chain deposit address (the step downstream of the Travel Rule): Crypto Deposits
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

​📄 Guide

​Capabilities in the DeCard-Managed model

​EDD file upload (Enhanced Due Diligence)

​Flow diagram

​Next steps

📄 Guide

Capabilities in the DeCard-Managed model

EDD file upload (Enhanced Due Diligence)

Flow diagram

Next steps