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

# Cancel Outbound SWIFT Payments

> Cancel a SWIFT payment locally before it is sent, or request cancellation of a sent payment (camt.056).

This guide covers cancelling payments **you sent**. On your side everything is referenced by the payment's **transaction ID** - the same ID you got when creating the payment; matching on the SWIFT network is handled by the platform.

For the opposite direction - another bank asking back a payment **you received** - see [Respond to cancellation requests](/payments/integration-guide/swift/inbound-cancellation).

How a cancellation plays out depends on where the payment is:

* **Not yet sent to SWIFT** (`Created`, `To sign`, `Signed`) - cancelled locally, nothing goes to the network
* **Already sent** - cancellation becomes a request (`camt.056`) that the correspondent may accept or reject

<Note>
  Once the payment is on the network, cancellation is a **request**, not a guarantee. The other side may accept or reject it depending on whether funds have been credited.
</Note>

## Flows

<Tabs>
  <Tab title="Before sending (local)">
    While the payment has not yet gone out to the SWIFT network, it can be cancelled **locally**: the payment simply moves to `Cancelled` and **nothing is sent to SWIFT**. No `camt.056`, no correspondent involved, guaranteed outcome.

    This window exists when **transaction signing** is enabled for your tenant - the payment waits in `To sign` until someone approves it, and **declining** it cancels the payment. Without signing, the payment is dispatched to the network right after creation, so there is no local cancellation window.

    <Steps>
      <Step title="Decline the payment">
        With transaction signing enabled, **decline** the payment instead of signing it - via the [decline API](/payments/api/swift/transaction-decline) or the PGW UI.
      </Step>

      <Step title="Payment is cancelled locally">
        The payment moves to **Cancelled** (final) and you receive the status webhook. Funds are never debited.
      </Step>
    </Steps>

    ```mermaid actions={true} theme={null}
    sequenceDiagram
      autonumber
      participant App as Your System
      participant Platform as Payments Platform
      participant SWIFT as SWIFT Network

      App->>Platform: Create SWIFT payment
      Platform-->>App: Webhook (Created / To sign)
      App->>Platform: Decline signing
      Platform-->>App: Webhook (Cancelled)
      Platform--xSWIFT: Nothing is sent
    ```

    After the payment reaches `Sent to clear`, local cancellation is no longer possible - use the **Cancellation request** flow in the next tab.
  </Tab>

  <Tab title="Cancellation request (camt.056)">
    You request cancellation by the payment's **transaction ID**; the platform sends the request to the correspondent bank over the SWIFT network and matches the answer to your payment automatically.

    <Steps>
      <Step title="You request cancellation">
        The platform first runs a **capability check**: cancellation support is configured per correspondent (deny by default). If the correspondent does not support cancellation, the request is refused immediately with a clear error and **nothing is sent** to the network. Otherwise the request is created - webhook `CANCELLATION_IN_PROGRESS`.
      </Step>

      <Step title="camt.056 sent to the correspondent">
        The cancellation request (`camt.056`) is signed and sent through SWIFT with your reason code, referencing the original payment.
      </Step>

      <Step title="Correspondent decides">
        There is no separate "accepted" message - the correspondent either sends the money back or refuses.
      </Step>

      <Step title="Accepted: funds come back">
        Acceptance **is** the returned money: a `pacs.004` payment return arrives - webhook `PAYMENT_RETURNED` (final). A separate **Payment return** transaction is created, linked to the original and tracked to completion via the SWIFT Frontend Tracker like any other return.
      </Step>

      <Step title="Rejected: payment proceeds">
        A `camt.029` resolution arrives with the rejection reason - webhook `CANCELLATION_REFUSED`; the original payment settles normally.
      </Step>
    </Steps>

    ```mermaid actions={true} theme={null}
    sequenceDiagram
      autonumber
      participant App as Your System
      participant Platform as Payments Platform
      participant SWIFT as SWIFT Network
      participant Corr as Correspondent Bank

      App->>Platform: POST cancellation request
      Platform->>Platform: Capability check (per correspondent)
      alt Correspondent does not support cancellation
        Platform-->>App: Error - cancellation not supported
      else Supported
        Platform-->>App: 200 {cancellationId}
        Platform-->>App: Webhook (CANCELLATION_IN_PROGRESS)
        Platform->>SWIFT: camt.056 (reason)
        SWIFT->>Corr: Deliver request
        alt Accepted
          Corr->>SWIFT: pacs.004 return (the funds)
          SWIFT->>Platform: pacs.004
          Platform-->>App: Webhook (PAYMENT_RETURNED) + Payment return created
        else Rejected
          Corr->>SWIFT: camt.029 REJECTED (reason)
          SWIFT->>Platform: camt.029
          Platform-->>App: Webhook (CANCELLATION_REFUSED) - payment proceeds
        end
      end
    ```
  </Tab>
</Tabs>

## Webhooks

Two webhook types are involved: the **payment** itself emits [Payment Status Change](/payments/webhooks/payment-status-change) events, while the **cancellation request** emits [Payment Cancellation Status Change](/payments/webhooks/payment-cancellation-status-change) events.

<Note>
  Status values are shown exactly as they arrive on the wire: the Payment Status Change webhook uses title case (`Cancelled`, `Sent to clear`), the Cancellation Status Change webhook uses upper snake case (`CANCELLATION_IN_PROGRESS`, `PAYMENT_RETURNED`).
</Note>

| Event                                       | Webhook                                       | `status`                                                 |
| ------------------------------------------- | --------------------------------------------- | -------------------------------------------------------- |
| Payment declined before sending             | Payment Status Change                         | `Cancelled`                                              |
| Cancellation request created                | Cancellation Status Change                    | `CANCELLATION_IN_PROGRESS`                               |
| Funds returned - `pacs.004` received        | Cancellation Status Change                    | `PAYMENT_RETURNED` (final)                               |
| Return transaction lifecycle                | Payment Status Change (`type=Payment return`) | `Created` → `Sent to clear` → (`Accepted`) → `Completed` |
| Correspondent refused - `camt.029` received | Cancellation Status Change                    | `CANCELLATION_REFUSED`                                   |

## API Reference

<Card title="Cancel Transaction" icon="ban" href="/payments/api/sepa/cancel-transaction">
  Initiate a cancellation request
</Card>

## Next Steps

<CardGroup cols={2}>
  <Card title="Payment statuses" icon="route" href="/payments/integration-guide/swift/track-payments">
    Follow the cancellation outcome on the payment
  </Card>

  <Card title="Statements" icon="file-lines" href="/payments/integration-guide/swift/statements">
    Reconcile returned funds
  </Card>
</CardGroup>