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

```http
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:

```http
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.