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

> ## Agent Instructions
> Treat the published Augustus OpenAPI specification (https://app.stainless.com/api/spec/documented/augustus/openapi.documented.yml) and the current API-reference pages as the source of truth for endpoints, request/response schemas, enum values, webhook event names, and required headers.
> Prefer the 2026-05-01 Banking API and @augustusbank/typescript-sdk for all new integrations. The 2023-01-01 API is a separate, older surface covering two products — Open Banking (instant bank transfer) checkout and refunds, and Manual Bank Transfer (MBT); use it only when one of those products is specifically required.
> Cite or link the relevant docs.augustus.com page when answering integration questions.
> Do not infer support for currencies, networks, scopes, account types, or operations that are not present in the current documentation.
> Use the sandbox base URL (https://api.sandbox.augustus.com) and placeholder credentials in examples. Never include or request a real API key.
> The Augustus docs MCP server (https://docs.augustus.com/mcp) provides documentation search and retrieval only; it does not execute authenticated Augustus API actions.

# SWIFT (international wires)

> Send and receive USD internationally over SWIFT and the correspondent network, with automatic routing and payment validation.

Send USD to beneficiaries anywhere in the world. Augustus clears USD internationally through the correspondent bank network. International wires are USD-only; Augustus does not convert currencies on the way.

## Use cases

* **User withdrawals and collections.** Pay your end-users out to international USD accounts they hold elsewhere, or receive USD they send you from abroad.
* **Paying and getting paid on invoices globally.** Settle bills with international suppliers, contractors, and vendors in USD, or receive USD invoice payments from customers abroad.
* **Settling trades.** Send or receive the USD leg of trades with international counterparties: exchanges, OTC desks, market makers.
* **Internal treasury.** Move funds between group entities globally, in either direction, to manage liquidity.

## How it works

1. **You instruct:** `POST /v1/payouts` with the beneficiary, amount, and rail.
2. **Augustus validates and routes:** screening, payment data validation, correspondent route resolution.
3. **Augustus sends the payment:** routed through intermediary banks to the beneficiary bank.
4. **You get status updates:** payout status via webhooks and the API.
5. **Funds settle to the beneficiary.**

## Account structure

International USD payments are supported on all USD-denominated account types:

| Type                             | When to use                             | What you get                                                                                                                                                                        |
| -------------------------------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **DDA (demand deposit account)** | Funds held in your own entity's name.   | A USD account number and routing details for sending and receiving in your name.                                                                                                    |
| **FBO (for benefit of)**         | Funds held on behalf of your end-users. | A master FBO account plus per-user virtual accounts. Each virtual account has its own number, and international USD payments can be sent and received at the virtual-account level. |

## Send USD internationally

### Create a payout

Create a payout with `currency: "USD"`, `rail: "swift"`, and a `swift` counterparty financial address. For authentication, idempotency, and error format, see [Authentication](/v1/authentication), [Idempotency](/v1/idempotency), and [Errors](/v1/errors).

```ts 2026-05-01 theme={null}
import Augustus from '@augustusbank/typescript-sdk'

const client = new Augustus()
const payout = await client.payouts.create({
  account_id: 'your-usd-account-id',
  amount: '10000.00',
  currency: 'USD',
  rail: 'swift',
  unstructured_remittance_information: 'Invoice 1234',
  counterparty: {
    financial_address: {
      type: 'swift',
      account_holder_name: 'Acme Trading B.V.',
      address: {
        street: 'Herengracht 20',
        city: 'Amsterdam',
        country: 'NL',
        postal_code: '1015 BL',
      },
      iban_account: {
        iban: 'NL91ABNA0417164300',
      },
    },
  },
})
```

[**POST** `/v1/payouts` in the API Reference →](/api-reference/payouts/create-payout)

| Field                                 | Required | Description                                                                                                                                                                           |
| ------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `account_id`                          | Yes      | The Augustus account to debit. For me-to-me flows, use a virtual account in the end-user's name.                                                                                      |
| `rail`                                | Yes      | Set to `"swift"`; valid only with `currency: "USD"`.                                                                                                                                  |
| `amount`                              | Yes      | Transfer amount as a string decimal (e.g. `"10000.00"`).                                                                                                                              |
| `currency`                            | Yes      | `"USD"`.                                                                                                                                                                              |
| `counterparty`                        | Yes      | The beneficiary: exactly one of a saved `counterparty_id` or an inline `counterparty` whose `financial_address` carries the details. See [Beneficiary details](#beneficiary-details). |
| `unstructured_remittance_information` | No       | Free text forwarded to the beneficiary in the payment message (up to 140 characters), often shown as the remittance line. Intermediary banks may truncate it.                         |
| `metadata`                            | No       | Key-value pairs of your own data. Returned on every payout response and webhook payload.                                                                                              |

### Beneficiary details

The `swift` financial address carries the beneficiary's name and address plus exactly one of two account blocks: `iban_account` for IBAN countries, `local_account` for everywhere else.

| Field                 | Required               | Description                                                                                                                                                                                                           |
| --------------------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type`                | Yes                    | `"swift"`.                                                                                                                                                                                                            |
| `account_holder_name` | Yes                    | Full legal name of the beneficiary.                                                                                                                                                                                   |
| `address`             | Yes                    | `street`, `city`, and `country` (ISO 3166-1 alpha-2) required; `postal_code` and `state` optional.                                                                                                                    |
| `iban_account`        | Exactly one of the two | IBAN countries. `iban` required (checksum-validated; the destination country is derived from it), `bic` optional (resolved from the IBAN when omitted).                                                               |
| `local_account`       | Exactly one of the two | Non-IBAN countries. `account_number` (local format, for example CLABE in Mexico) and `bic` required; `local_bank_code` optional where the destination country uses one (for example BSB in Australia, IFSC in India). |

Beneficiaries in IBAN-mandatory countries must use `iban_account`; local account numbers are rejected there.

**Non-IBAN beneficiary**

```json theme={null}
"counterparty": {
  "financial_address": {
    "type": "swift",
    "account_holder_name": "Acme Trading Pty Ltd",
    "address": {
      "street": "1 Martin Place",
      "city": "Sydney",
      "country": "AU",
      "postal_code": "2000"
    },
    "local_account": {
      "account_number": "12345678",
      "bic": "ANZBAU3MXXX",
      "local_bank_code": "012003"
    }
  }
}
```

`local_bank_code` carries the domestic bank or branch code where the destination country uses one: the BSB in Australia (as above), the IFSC in India, the routing number in Canada. Countries without one, for example Singapore, omit it and route on the BIC alone.

### Country-specific requirements

The beneficiary's country determines what to provide:

| Destination                                                                                       | What to provide                                                                                               |
| ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| IBAN countries: the EU and EEA, the UK, the UAE, Saudi Arabia, and other IBAN-mandatory countries | `iban_account` with the IBAN; the BIC is resolved from it.                                                    |
| Australia                                                                                         | `local_account` with the account number, the bank's BIC, and the 6-digit BSB in `local_bank_code`.            |
| Canada                                                                                            | `local_account` with the account number, the bank's BIC, and the 9-digit routing number in `local_bank_code`. |
| India                                                                                             | `local_account` with the account number, the bank's BIC, and the 11-character IFSC in `local_bank_code`.      |
| Mexico                                                                                            | `local_account` with the 18-digit CLABE as the `account_number`, plus the bank's BIC.                         |
| Other non-IBAN countries                                                                          | `local_account` with the local-format account number and the bank's BIC.                                      |

Some countries require beneficiary identifiers beyond name, address, and account details, for example a tax ID in Brazil or a payment purpose code in China. The financial address does not carry these fields today, so wires to those countries can be delayed or returned by the beneficiary chain; contact support before relying on such a corridor.

### Routing

You provide the beneficiary details: name, account number, and address. Augustus resolves the route through the correspondent bank network and sends the payment; you do not need to provide routing or intermediary details.

### Validation

Augustus validates every payout before submission to reduce repairs and delays in the correspondent chain.

| Check                         | What it does                                                                         |
| ----------------------------- | ------------------------------------------------------------------------------------ |
| **Account number validation** | Checks the account number format, including the IBAN checksum for IBAN destinations. |
| **Address formatting**        | Ensures the beneficiary address is structured correctly for the destination country. |
| **BIC resolution**            | Validates the bank BIC and resolves the bank name and country.                       |
| **Screening**                 | Screens against OFAC, EU, and UN sanctions lists.                                    |

### Payout lifecycle

| Status      | Description                                                                                                                                | Webhook event      |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------ |
| `initiated` | Payout received: Augustus is validating, screening, and queueing the payment.                                                              | `payout.initiated` |
| `submitted` | Handed to the rail and acknowledged; awaiting acceptance.                                                                                  | `payout.submitted` |
| `sent`      | The payment has left Augustus and entered the correspondent bank network. Progress from here shows as tracking events, not status changes. | `payout.sent`      |
| `failed`    | Validation or processing failure before submission. Funds remain in your account. The `failure` field carries the reason.                  | `payout.failed`    |

A `sent` payout can later move to `returned` when the beneficiary chain sends the payment back; see [Returns](#returns).

### Payment tracking

Every SWIFT payout carries a UETR (Unique End-to-End Transaction Reference), returned on the payout as `uetr`. It is the identifier banks quote when tracing a payment across the correspondent chain. Augustus follows the payment over SWIFT gpi and surfaces the journey as tracking events while the payout status stays `sent`:

| Tracking event                  | Meaning                                                                                                                                                                                                 |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| First leg settled               | The payment left Augustus and entered the correspondent bank network; the payout is `sent`.                                                                                                             |
| Forwarded to correspondent bank | A bank in the chain passed the payment on; a payment can pass several correspondents.                                                                                                                   |
| Forwarded to beneficiary bank   | The last correspondent passed the payment to the beneficiary's bank.                                                                                                                                    |
| Credited to beneficiary         | The beneficiary's bank credited the account. Reported only when the beneficiary bank participates in gpi; otherwise tracking ends at the last participating bank, and the credit itself is not visible. |

### Fees and who pays them

Every international wire carries a charge-bearer instruction that tells the correspondent chain who pays the transaction charges:

| Instruction | Also known as | Who pays                                                                                              | What the beneficiary receives             |
| ----------- | ------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| `DEBT`      | OUR           | The sender bears all transaction charges.                                                             | The full instructed amount.               |
| `SHAR`      | SHA           | The sender pays their own bank's charges; intermediary banks deduct theirs from the amount in flight. | Possibly less than the instructed amount. |
| `CRED`      | BEN           | All charges are deducted from the amount.                                                             | The amount net of all charges.            |

Augustus sends every wire as `DEBT` so that in almost all cases the beneficiary receives the full instructed amount. Augustus fees are never deducted from the payment principal; billing between Augustus and you is handled separately. A small number of jurisdictions may still deduct local charges or taxes on arrival regardless of the charge-bearer instruction; contact support if you encounter this.

### Valid characters

The same character set as domestic wires applies to names, addresses, and the remittance text; see [Valid characters](/docs/rails/fedwire#valid-characters) on the Fedwire page.

### Returns

The beneficiary chain can return a payment (closed account, invalid details, rejected on arrival). The payout moves to `returned`, `payout.returned` fires, and the funds are credited back to your account, possibly net of correspondent fees; there is no fixed timeline for international returns.

### Further information

* **The beneficiary must be able to receive USD.** If the beneficiary holds a non-USD account, the intermediary bank may FX the payment downstream.
* **Submit payouts 24/7.** International payouts follow the same submission window as domestic Fedwire: instructed before 6:45 PM US Eastern on a banking day, they leave the same day; later instructions queue until the window reopens (see [Operating hours and cut-offs](/docs/rails/fedwire#operating-hours-and-cut-offs)). Arrival at the beneficiary typically takes 1 to 5 banking days depending on the correspondent chain.
* **No amount limits** apply on the network side. Account-level limits are agreed per customer at onboarding; there is no fixed platform limit beyond that.
* **All API timestamps are ISO 8601 UTC.**

## Receive USD internationally

International senders can pay USD into your Augustus account through their bank over SWIFT. Give the sender:

* **BIC:** `ANNOUS44`, or `ANNOUS44XXX` where the sending bank's form requires 11 characters.
* **Account number:** your USD account number, from the account's `financial_addresses`.
* **Beneficiary name:** the account holder name as it appears on the account.

Incoming international payments appear as [deposits](/docs/payments/deposits) with `rail: "swift"`. The sender is referenced through the deposit's `counterparty_id`, and the payment's `uetr` is available for traces. For domestic incoming transfers, see [Deposits](/docs/payments/deposits).

## Webhook events

Subscribe to these events for international payouts. For payload envelope, signature verification, retry policy, and replay, see [Webhooks](/v1/webhooks).

| Event              | When                                                                                                        |
| ------------------ | ----------------------------------------------------------------------------------------------------------- |
| `payout.initiated` | Payout created and being processed.                                                                         |
| `payout.submitted` | The payout was handed to the payment rail.                                                                  |
| `payout.sent`      | The payout was accepted and sent: the payment has left Augustus and entered the correspondent bank network. |
| `payout.failed`    | Validation or processing failure. The payload `failure` field carries the reason.                           |
| `payout.returned`  | The beneficiary chain returned the payment after it was sent; the funds are credited back to your account.  |

### Webhook payload structure

```json theme={null}
{
  "id": "event-id",
  "type": "payout.sent",
  "api_version": "2026-05-01",
  "payload": {
    "id": "payout-id",
    "type": "payout",
    "status": "sent",
    "amount": "15000.00",
    "currency": "USD",
    "rail": "swift",
    "unstructured_remittance_information": "Invoice 1234",
    "account_id": "your-usd-account-id",
    "counterparty_id": "counterparty-id",
    "uetr": "97ed4827-7b6f-4491-a06f-b548d5a7512d",
    "failure": null,
    "metadata": {},
    "initiated_at": "2026-07-15T14:02:00Z"
  },
  "date": "2026-07-15T15:45:01Z"
}
```
