Confirm an outgoing transfer

Tell the receiving institution when your wallet confirms an outgoing transaction

After your wallet confirms the same authorised transaction, report its identifier from your backend using the original secret API key. Do not send this for a merely broadcast transaction, an uncertain payment, or a different payment job.

POST /api/v1/transactions/{id}/travel-rule/execution/confirmation
Authorization: Bearer <secret-api-key>
Content-Type: application/json

{
  "expectedRevision": 2,
  "externalExecutionId": "<same-durable-payment-job-uuid>",
  "txid": "<wallet-confirmed-transaction-identifier>",
  "confirmedAt": "2026-09-06T12:00:00.000Z"
}

Use the original consumed revision. confirmedAt must be at or after consumption and not in the future. txid is an asset-specific identifier (letters, digits, underscores or hyphens; at most 256 characters), not an explorer URL. Your system is responsible for checking that it identifies the exact authorised transaction.

The response returns confirmation.messageId, confirmedAt, source: "CUSTOMER" and the message delivery status. Persist the exact request in your durable job: repeating it returns the same message; changing its transaction ID or timestamp conflicts. There is only one confirmation per consumed execution, regardless of HTTP retries. No extra execution is authorised.

Send the prepared message through the existing endpoint:

POST /api/v1/transactions/{id}/travel-rule/exchanges/{confirmation.messageId}/send
Authorization: Bearer <secret-api-key>
Content-Type: application/json

{}

Myaza uses the institution's authenticated callback from the approval that preceded execution. Your request cannot choose another URL, institution, amount or asset. The transaction identifier is encrypted in the exchange journal; audit entries and webhooks contain metadata only. Peer and retention checks still apply, even when the original clearance has expired.

ACKNOWLEDGED means the institution received the confirmation message, not that Myaza independently verified settlement. UNCERTAIN means delivery needs reconciliation; sending again does not repeat the network POST. Subscribe to travel_rule.exchange.updated and read the execution or transfer endpoint for the latest status. The dashboard separately shows Reported by your system and Transfer confirmation · Message received. Settlement remains UNKNOWN until independent evidence is available.

The operator must provision execution signing configuration, reviewed institution connections and country-specific requirements before enabling live use. Product templates and local tests do not qualify a country or prove live interoperability.