Send assets without PII

This workflow covers outgoing transfers where PII (Personally Identifiable Information) is not required. The Travel Rule message is created with counterparty information before submitting the transfer intent.

Prerequisites

Travel Rule setup complete
Wallet addresses registered with Notabene

Process flow

Step 1: Create Travel Rule message

Create a Travel Rule message with counterparty information:

POST /v1/domains/{domainId}/compliance/travel-rule/providers/{provider}/messages

Request body:

Field	Type	Description
`originator`	object	Originator identifier (contains `@id` - DID or identifier for the party)
`beneficiary`	object	Beneficiary identifier (contains `@id` - DID or identifier for the party)
`asset`	string	Asset identifier (e.g., `bip122:000000000019d6689c085ae165831e93/slip44:0`). See Notabene asset registry for supported formats.
`amount`	string	Transfer amount
`ref`	string	Reference identifier for the transfer
`agents`	array	Agents involved in the transfer. Each agent has `@id`, `for`, and `role` (values: `VASP`, `Custodian`, `SettlementAddress`, `SourceAddress`, `Gateway`, `Unknown`)

Response:

Field	Type	Description
`createTransfer201Response.transfer`	object	Transfer details from Notabene
`suggestedIntentId`	string (uuid)	The intent ID to use when creating the transfer intent
`travelRuleId`	string	The Travel Rule message ID for status checks

Step 2: Get transfer status

Check the transfer status to verify the Travel Rule message was created:

GET /v1/domains/{domainId}/compliance/travel-rule/providers/{provider}/messages/{travelRuleId}

Unlike the with PII workflow, there are no PII requirements to fulfill when PII is not required.

Step 3: Create Transfer Order intent

Create the Transfer Order intent using the suggestedIntentId returned in Step 1.

Transfer Order intent payload:

Field	Type	Required	Description
`payload.accountId`	string (uuid)	Yes	Source account ID
`payload.ledgerId`	string	No	Ledger identifier
`payload.parameters.operation`	object	Yes	Transfer operation details including `destination`, `amount`, and `type`
`payload.type`	string	Yes	Must be `v0_CreateTransferOrder`

Critical

Use the suggestedIntentId from Step 1 when creating the intent. This links the compliance check to your transaction.

Step 4: Risk screening

If transaction screening is configured (Chainalysis or Elliptic), Ripple Custody screens the transaction first.

If screening fails (high risk score): The transaction is immediately rejected. No Travel Rule check occurs.
If screening passes: The workflow proceeds to the Travel Rule check.

Step 5: Travel Rule check

Notabene verifies counterparty information.

Step 6: Compliance decision

Ripple Custody evaluates the results:

Screening Result	Travel Rule Result	Decision
Approved	Approved	`AUTO_APPROVED`
Rejected	—	`AUTO_REJECTED` (Travel Rule skipped)
Approved	Rejected	`AUTO_REJECTED`
Inconclusive	Inconclusive	`NEED_EXPLICIT_DECISION`

If the decision is NEED_EXPLICIT_DECISION, manual review is required in Ripple Custody.

If only one check is configured (screening only or Travel Rule only), the decision is based on that single check.

Step 7: Execution and settlement

If AUTO_APPROVED: Transaction executes on blockchain, then Notabene is notified of settlement.
If AUTO_REJECTED: Intent closes, then Notabene is notified of rejection.

Verify transfer status

Poll the Travel Rule transfer status to confirm successful execution:

GET /v1/domains/{domainId}/compliance/travel-rule/providers/{provider}/messages/{travelRuleId}

Key response fields:

Field	Type	Description
`transfer.status`	string	Notabene transfer status (e.g., `SETTLED`, `REJECTED`)
`transfer.direction`	string	`OUTGOING` for this workflow

Next steps

Send with PII — When PII is required
Receive assets — Handle incoming Travel Rule transfers