Recipient verification

Copy

To optimise payment success rates and reduce returned transfer incidents, Wise performs a two-tier check during recipient creation: validation and verification.

Validation

Validation is the preliminary check performed immediately upon a create recipient account request. This process ensures that the submitted recipient data conforms to the required schema and regional formatting rules (for example, account number length and format).

If validation fails, the API returns an HTTP error response and the recipient resource is not created. You must surface the specific error details to the customer so they can correct the input before retrying the request.

Verification

Verification, also called confirmation of payee (CoP), is a more in-depth check that runs once all validations have passed. For supported currencies, this step confirms details such as whether the account exists at the destination bank, or whether the recipient's name matches the records held by the receiving institution.

Supported currencies

Recipient verification is currently active for:

• CNY (Chinese Yuan)
• EUR (Euro, for Enterprise/Embedded payouts to SEPA accounts)
• IDR (Indonesian Rupiah)
• INR (Indian Rupee)
• KRW (South Korean Won)

The following currencies will be supported soon:

• GBP (British Pound)
• EUR (Euro, for all partner and payout types)
• JPY (Japanese Yen)
• AUD (Australian Dollar)
• USD (US Dollar)
• MYR (Malaysian Ringgit)
• THB (Thai Baht)
• BRL (Brazilian Real)
• TRY (Turkish Lira)
• PKR (Pakistani Rupee)

For a full reference of supported recipient types, validated fields, verification behaviour, and possible outcomes per currency, see the Recipient verification reference guide.

Validation and verification process

All checks run sequentially during recipient creation. If an earlier step fails, later steps do not run.

Step 1: Field-level validation

Field-level validation checks the format and correctness of each input field. It runs first, before any external verification call is made.

If any field fails validation, the recipient resource is not created and the API returns an error response in the following format:

{
  "errors": [
    {
      "code": "NOT_VALID",
      "path": "name/fullName",
      "message": "The name provided is not valid."
    }
  ]
}

The path field identifies which input field failed. Multiple errors can be returned in a single response if more than one field is invalid. Surface these details to the customer and allow them to correct the input before retrying the POST /accounts request.

To see the validation rules for a specific field, send a retrieve recipient account requirements request and check the group array in the response for the field in question.

This example shows the group array for the IBAN field:

{
    "name": "IBAN",
    "group": [
      {
        "key": "IBAN",
        "name": "IBAN",
        "type": "text",
        "refreshRequirementsOnChange": false,
        "required": true,
        "displayFormat": "**** **** **** **** **** **** **** ****",
        "example": "DE12345678901234567890",
        "minLength": 14,
        "maxLength": 42,
        "validationRegexp": "^[a-zA-Z]{2}[a-zA-Z0-9 ]{12,40}$",
        "validationAsync": null,
        "valuesAllowed": null
      }
    ]
}

For currencies without verification, a recipient that passes all field validations is created immediately. For currencies with verification, the process continues to step 2.

Step 2: Verification (CoP)

Verification only runs after all field-level validations have passed. It calls an external provider (like a receiving bank, payment scheme, or third-party data service) to confirm the validity of the recipient details.

Two types of verification can occur, depending on the currency:

• ACCOUNT_EXISTENCE: Confirms that the account number is valid and reachable at the destination bank or payment provider.
• NAME_MATCHING: Confirms that the name provided matches the name registered on the account. For currencies that support NAME_MATCHING, account existence is implied.

In some cases, the account existence and name are verified together as a combined unit. The type of check that applies to each currency is specified in the Recipient verification reference guide.

Verification results in one of two outcomes:

• Non-blocking: The recipient resource is created and the verification result is returned in the confirmations object of the response. Depending on the outcome, further action may be required before the recipient can be used for a transfer.
• Blocking: An error is returned and the recipient resource is not created. Blocking outcomes occur when the external provider confirms that the account or details are definitively invalid (for example, an account number does not exist at the given bank). You must correct the input and retry the POST /accounts request.

Blocking errors follow the same format as field validation errors, with the relevant path and code values. For blocking error codes per currency, see the Recipient verification reference guide.

The confirmations object

When a recipient resource is successfully created after the verification step, the verification result is returned in the confirmations object of the response. If the confirmations object is not present in the response, you can retrieve it separately via GET /accounts/{accountId}.

The confirmations object has the following structure:

{
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "SUCCESS",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": false,
        "fieldsChecked": ["name/fullName", "details/iban"],
        "message": null,
        "resolvedName": null,
        "providedName": "John Doe",
        "recommendedUpdates": []
      }
    ]
  }
}

Notable fields in the confirmations object:

Verification outcomes

The value in the outcomes.outcome field indicates the result of the verification check.

PARTIAL_FAILURE, FAILURE, and COULD_NOT_CHECK are non-blocking outcomes. The recipient resource is created, but further action may be required before it can be used for a transfer. Check the requiresCustomerAcceptance field to determine what to do next.

Not all currencies support all four outcomes. For the outcomes possible per currency, see the Recipient verification reference guide.

Handling verification outcomes

When the outcome is anything other than SUCCESS, check the outcomes.requiresCustomerAcceptance field to determine whether explicit customer action is required:

• requiresCustomerAcceptance: false: In this case, a minor discrepancy may exist, but the recipient is usable without further action. You can choose to inform the customer of the discrepancy, but no PATCH request is required to proceed with a transfer.
• requiresCustomerAcceptance: true: This means the recipient cannot be used for a transfer until the customer has explicitly acknowledged the outcome. Present the verification result to the customer and obtain their confirmation before proceeding.
  • If the customer chooses to correct the details, create a new recipient by submitting corrected data via a new POST /accounts request.
  • If the customer confirms the existing details and accepts the outcome, call the PATCH endpoint to record their acceptance and unblock the recipient for use.

Accepting a non-SUCCESS outcome

To move a recipient to a usable state after the customer has acknowledged a non-SUCCESS outcome, call the confirmation acceptance endpoint.

curl -i -X PATCH \
  'https://api.wise.com/2026Q3/accounts/{accountId}/confirmations?quoteId=497f6eca-6276-4993-bfeb-53cbbbba6f08' \
  -H 'Authorization: Bearer <YOUR_JWT_HERE>' \
  -H 'Content-Type: application/json' \
  -H 'X-External-Correlation-Id: f47ac10b-58cc-4372-a567-0e02b2c3d479' \
  -d '{
    "acceptedOutcomes": true
  }'

Once acceptedOutcomes is true, the recipient can be used for a transfer.

Workflow summary

The standard integration flow for creating and using a verified recipient:

1. Submit a POST /accounts request with the recipient's details.
2. Check the confirmations.outcomes.outcome field in the response.
3. If requiresCustomerAcceptance is true, present the verification result to the customer. If they choose to proceed, call PATCH /accounts/{accountId}/confirmations with {"acceptedOutcomes": true}.
4. Create a transfer using the recipient.

If the POST /accounts request returns an error (blocking outcome or field validation failure), correct the input based on the errors array and retry from step 1.

Testing in the sandbox

You can test recipient verification for supported currencies in the sandbox with the following basic flow:

1. Create a recipient via POST /accounts/ with valid details.
2. Inspect the response. Check the confirmations.outcomes.outcome field.
3. If outcome requires acceptance (requiresCustomerAcceptance: true), call PATCH /accounts/{accountId}/confirmations with {"acceptedOutcomes": true}.
4. Create a transfer using the accepted recipient.

Note that some currencies have unique testing behaviours. Additional details about testing recipient verification coming soon.