Skip to main content
Wire Transactions

Send a high-value wire payment from financial institution to financial institution

Use the Wire Transactions V2 API to submit digitally signed USD wire payment instructions between financial institutions (FI) that hold U.S.-domiciled J.P. Morgan accounts.

This capability:

  • Supports domestic and cross border USD wire flows
  • Uses ISO 20022-aligned messaging
  • Is currently available to a limited set of FI clients

You should treat this API as a specialized USD clearing solution for FI-to-FI use cases, not a general-purpose wire initiation API. Confirm alignment with the USD Clearing product team before expanding usage across additional flows.

When to use this endpoint

Use this endpoint to create a high-value wire payment instruction and receive a bank reference you can use for reconciliation and downstream tracking: POST /payments/wires/credit.

Before you begin

Set up these prerequisites before you send requests:

  • Use mutual Transport Layer Security (mTLS) for connectivity and authentication.
  • Send a digitally signed payload and set the Content-Type header to text/xml.
  • Remove carriage returns and line feeds from all payment instruction text.
  • For APAC wires, except China and Taiwan local wires, limit characters to the SWIFT X character set.

Choose your wire initiation pattern

Select the initiation pattern that aligns with your business flow, and set paymentTypeInformation.transferType accordingly:

  • Use transferType: CUSTOMER for customer credit transfers (pacs.008 equivalent), where the wire represents movement of funds on behalf of an end customer, even when initiated by a financial institution.
  • Use transferType: FI for financial institution credit transfers (pacs.009 equivalent), where the payment represents an interbank or treasury level transaction rather than a customer payment. You may include optional interbank reference fields such as relatedReferenceId when they apply to your flow.
Note

For Wire Transactions API V2, J.P. Morgan assigns the UETR, and you don't provide it at initiation.

Market and regulatory requirements

Payment formatting requirements vary by destination country, currency, clearing system, and regulatory obligations.

Some beneficiary and debtor fields that appear optional in the API schema may become required when a payment is processed through a specific clearing network or regulatory framework.

Examples include:

  • SEPA payments
  • SWIFT payments
  • Country-specific regulatory reporting requirements
  • Know Your Customer (KYC) validation requirements

SEPA example

For certain SEPA payments involving private individuals, you may need to provide a complete Date and Place of Birth structure:

{
  "dateAndPlaceOfBirth": {
    "birthDate": "",
    "cityOfBirth": "",
    "countryOfBirth": ""
  }
}

Providing only birthDate may result in payment rejection depending on the beneficiary bank validation rules and regulatory requirements.

Build the request

Create a JSON request body that follows transactionRequestObject and includes the required top-level fields:

  • paymentMethod
  • paymentTypeInformation with serviceLevelCode
  • requestedExecutionDate 
  • debtor 
  • debtorAccount 
  • debtorAgent
  • creditTransferTransactionInformation

Set paymentMethod and service level

  • Set paymentMethod to TRF.
  • Select a valid paymentTypeInformation.serviceLevelCode value, such as URGP or BKTR, based on your payment flow. 

Populate endToEndId

Use endToEndId as your primary client reference and as the lookup key. Generate and validate endToEndId using these rules:

  • Keep it at 16 characters or less.
  • Use only alphanumeric characters, and use uppercase when you include letters. 
  • Avoid a hyphen or colon as the first character.
  • Keep it unique for the configured retention period, which can be six months or one year, since reuse during retention triggers upfront rejection.
  • Expect the API to return the latest payment when more than one payment shares the same endToEndId after the retention period.

Add financial institution routing and settlement details

Add financial institution-specific routing and settlement fields only when the wire represents a financial institution credit transfer (transferType: FI) or when your flow requires explicit interbank routing instructions.

  • Populate instructingAgent.financialInstitutionId.bic when you need to identify the sending or correspondent financial institution using a BIC, which is typical for cross border or correspondent wire flows.
  • Populate instructedAgent.financialInstitutionId.aba for U.S. domestic financial institution payments where clearing occurs using the Fedwire system.
  • Populate settlementInformation.settlementAccount.accountNumber for U.S. financial institution to financial institution payments when you must reference a specific settlement account (for example, a nostro or vostro account).
  • For customer credit transfers (transferType: CUSTOMER), these financial institution-only routing and settlement fields generally aren't required because routing derives from the customer account and instructed agent details.

Choose an amount structure

Provide one of these amount models inside creditTransferTransactionInformation.amount:

  • instructedAmount with currency and amount
  • equivalentAmount with currencyamount, and currencyOfTransfer, and include interbankSettlementAmount when your flow uses it

Example request

This example shows a U.S. financial institution to financial institution credit transfer pattern. It includes relatedReferenceId as an optional interbank reference:

{
  "initiatingParty": {
    "id": {
      "organizationId": {
        "other": {
          "id": "BANK"
        }
      }
    }
  },
  "instructingAgent": {
    "financialInstitutionId": {
      "bic": "AAAANL2UXXX"
    }
  },
  "instructedAgent": {
    "financialInstitutionId": {
      "aba": "021000021"
    }
  },
  "settlementInformation": {
    "settlementAccount": {
      "accountNumber": "<FI Client's Settlement Account with JPM>"
    }
  },
  "paymentMethod": "TRF",
  "paymentTypeInformation": {
    "serviceLevelCode": "URGP",
    "transferType": "FI"
  },
  "requestedExecutionDate": "2021-02-03",
  "debtor": {
    "name": "DEBTOR FI Name"
  },
  "debtorAccount": {
    "accountNumber": "<FI Client's Account# with JPM>"
  },
  "debtorAgent": {
    "aba": "021000021",
    "country": "US"
  },
  "creditTransferTransactionInformation": {
    "relatedReferenceId": "25725457",
    "endToEndId": "TESTTRAN123",
    "uetr": "39d69da1-515d-48a2-b889-9baa75c32288",
    "amount": {
      "instructedAmount": {
        "currency": "USD",
        "amount": 6052683.57
      }
    },
    "creditorAgent": {
      "financialInstitutionId": {
        "bic": "XXYYUS33XXX"
      }
    },
    "creditor": {
      "organizationId": {
        "bicOrBei": "XXYYDE33ABC"
      }
    }
  }
}

Send the request

Submit a request to the wire credit initiation resource under the /tsapi/v2 base URL for your environment.

Review the response

A successful response returns HTTP 200 and includes:

  • endToEndId
  • jpmcPmtRefId
  • sendTimeStamp
  • messageType
  • processingInfo.statusCode and processingInfo.statusText

Handle errors and retries

Plan for these common response patterns:

  • HTTP 400 returns validation errors such as missing endToEndId, invalid serviceLevelCode, invalid debtor account and agent combinations, or invalid request formatting.
  • HTTP 403 returns unauthorized access errors.
  • HTTP 503 can occur due to timeouts, and the payment can still process successfully, so you'll get safer outcomes if you check transaction status before you retry.