Skip to main content
Wire Transactions

Send a high-value wire payment

Use the Wire Transactions V1 API to initiate digitally signed wire payment instructions from any J.P. Morgan account holding branch worldwide, supporting domestic and cross border payments, including automated foreign exchange (FX), as well as payments debited from third party bank accounts (for example, multibank payments) where applicable. Send a request that follows the transactionRequestObject schema. The API returns your endToEndId, a J.P. Morgan payment reference (jpmcPmtRefId), and processing status details.

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.

Select your request pattern (account configuration and clearing route)

Select the request pattern that aligns with your account configuration and clearing route. The API examples illustrate common wire clearing options, including U.S. book transfers, U.S. Fed wires, CHIPS wires, and in country domestic wires for markets such as Brazil, Canada, Hong Kong, the U.K., and the E.U., as well as supported payment structures like Payment on Behalf Of (POBO) and For Further Credit (FFC).

The agent chain and identifiers you provide qualify the wire. Depending on the clearing route, you may need to include specific financial institution identifiers (for example, BIC vs. ABA), and in some flows an intermediary/agent chain to ensure the payment routes and credits correctly.

Format the debtor account and agent consistently:

  • Use either an IBAN or an account number, never both.
  • If you provide an IBAN, don't include an ABA based debtor agent.
  • If you provide an account number, include one valid agent identifier (BIC or ABA), as the clearing flow requires.
  • Provide only one identifier type per agent. Don't mix BIC and ABA in the same agent object.

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 for a wire and to track it later through the Wire Transactions 1 API. You’ll get the best results when you treat it as a controlled identifier instead of free form text. Generate and validate endToEndId using these rules:

  • Keep it at 15 characters or less.
  • Use only alphanumeric characters, and keep alphabetic characters uppercase.
  • Avoid starting it with a hyphen or colon, and avoid non alphanumeric input that can create processing issues.
  • Keep it unique during the configured retention period, which can be six months or one year depending on your production setup. Reuse during that window can lead to rejection.
  • After the retention period, you can reuse an identifier, but track and trace queries return the status for the latest payment that used that endToEndId.

Choose an amount structure

Provide one of these two amount models inside creditTransferTransactionInformation.amount:

  • instructedAmount with currency and amount
  • equivalentAmount with currencyamount, and currencyOfTransfer

Example request

his example shows a minimal U.S. book transfer wire pattern. In production, make sure your agent identifiers and intermediary/agent chain details align with the intended clearing route and wire qualification requirements.

{
  "paymentMethod": "TRF",
  "paymentTypeInformation": {
    "serviceLevelCode": "URGP"
  },
  "requestedExecutionDate": "2021-01-01",
  "debtor": {
    "name": "YOUR COMPANY NAME",
    "postalAddress": {
      "country": "US"
    }
  },
  "debtorAccount": {
    "accountNumber": "1234567890",
    "currency": "USD"
  },
  "debtorAgent": {
    "aba": "021000021",
    "country": "US"
  },
  "creditTransferTransactionInformation": {
    "endToEndId": "12345678",
    "amount": {
      "instructedAmount": {
        "currency": "USD",
        "amount": 1
      }
    },
    "creditorAgent": {
      "financialInstitutionId": {
        "aba": "021000021",
        "postalAddress": {
          "country": "US"
        }
      }
    },
    "creditor": {
      "name": "CREDITOR NAME",
      "postalAddress": {
        "country": "US"
      }
    },
    "creditorAccount": {
      "accountNumber": "1234567890"
    }
  }
}

Send the request

Submit a request to the wire credit initiation resource under the /tsapi/v1 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.