# Verifying recipient details 

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

## Validation

Validation is the preliminary check performed immediately upon the `POST /v1/accounts` request. This process ensures that the submitted recipient data conforms to the required schema and regional formatting rules, such as field lengths and format checks.

If the data is malformed, the API returns an HTTP error status code and the recipient resource is not created. In such cases, you must surface the specific error details to the customer to rectify the input before re-attempting the request.

## Verification

For certain supported currencies, a more in-depth verification process is carried out once the initial validation has been passed. This level of verification, called confirmation of payee (CoP), confirms details like the existence of the account or that the recipient's account number and name match the records held by the destination bank.

## 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)


## Handling verification

When a recipient resource is successfully created, the verification results are contained in the `confirmations` object of the create recipient account response. The `confirmations.outcomes` array provides the details about the type of verification and the status.

### Verification outcomes

The `outcomes.outcome` field in the `confirmations` object for a recipient account that was successfully created indicates the status of each verification check that occurred.

Verification outcomes can be:

- `SUCCESS`
- `FAILURE`
- `PARTIAL_FAILURE`
- `COULD_NOT_CHECK`


`SUCCESS` indicates that verification was successful and the details are correct. The recipient resource is ready for immediate use, with no further action required.

If the outcome is anything other than successful, this indicates a **non-blocking** outcome and additional action may be required before you can use the recipient for a transfer.

Check the `outcomes.requiresCustomerAcceptance` field to determine what action is required, if any.

- If `requiresCustomerAcceptance` is `false`: This means a minor discrepancy may exist, but the recipient is created and usable. You can choose to inform the customer of the discrepancy, but no further action is required to proceed.
- If `requiresCustomerAcceptance` is `true`: This means the recipient cannot be used for a transfer without explicit approval from the customer. To move the recipient to a usable state, you must present the mismatch details from the outcomes array to the customer.
  - If they choose to update the details, submit the corrected data by creating a new recipient with a new `POST` call to the `/v1/accounts` endpoint.
  - If the user confirms the existing details and makes no changes, make a `PATCH` call to the [recipient confirmation endpoint](/api-reference/recipient/recipientconfirmationsaccept) to supply the customer's explicit acceptance and unblock the account.


## Related endpoints

- [Create a recipient account](/api-reference/recipient/recipientcreate)
- [Check account and quote compatibility](/api-reference/recipient/recipientcompatibilitycheck)
- [Accept confirmation outcomes](/api-reference/recipient/recipientconfirmationsaccept)
- [Recipient Account schema](/api-reference/recipient) — see the `confirmations` field