IDR recipient verification

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

When you create an IDR recipient via the Wise API, we automatically run a series of validations (format checks) and verifications (Confirmation of Payee, or CoP) before returning the response.

This guide provides details specific to the verification that occurs when creating IDR recipients.

Supported recipient types

IDR supports one recipient type only:

Step 1: Field-level validation

Field-level validation checks the format and correctness of input fields. If any fail, the recipient is not created and the API returns a validation error.

Indonesian local

The following validations occur when the recipient type is indonesian:

Sample field validation errors

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

Step 2: Verification

Verification checks name matching (type NAME_MATCHING) in a single call to the data provider. It only runs after all field validations pass.

How it works

1. Wise calls the data provider API with the recipient's bank code and account number.
2. Data provider first verifies the account exists.
   • If not, the outcome is blocking: either DOES_NOT_EXIST (account not found) or ACCOUNT_CLOSED (account has been closed). In both cases, recipient creation fails.
   • If the account exists, the data provider returns the registered name on the account.
3. Wise compares the registered name with the name you provided using our name-matching algorithm.

The comparison produces one of two results:

Fields checked by recipient type

Verification blocking outcomes

In some cases, verification discovers the account is invalid at the provider level. These are blocking as they cause the recipient creation to fail, even though field-level validation passed.

Sample blocking errors

{
  "errors": [
    {
      "code": "INVALID_ACCOUNT_NOT_EXIST",
      "path": "details/accountNumber",
      "message": "The account does not exist."
    }
  ]
}

Possible outcomes for IDR

What to do

V1 vs V2 endpoints

Both V1 and V2 endpoints run the same validations and verifications. The difference is the field naming and how the confirmation result is returned.

V2 request confirmations

When creating a recipient with V2, include the following in your request to receive the confirmations field:

{
  "type": "indonesian",
  "details": { ... },
  "responseConfiguration": {
    "additionalInformation": ["CONFIRMATION_RESULT"]
  }
}

Without this, V2 will create the recipient and run all checks, but will not include the confirmations field in the response. You would then need to fetch it separately via GET /v2/accounts/{id}.

Sample payloads

All payloads below show the confirmations field as it appears in the response after creating a recipient.

SUCCESS (name matched)

{
"id": 123456,
"type": "indonesian",
"accountHolderName": "Budi Santoso",
"details": {
 "bankCode": "bca",
 "accountNumber": "1234567890"
},
"confirmations": {
 "acceptedOutcomes": false,
 "acceptedAt": null,
 "quoteId": null,
 "outcomes": [
   {
     "type": "NAME_MATCHING",
     "outcome": "SUCCESS",
     "timestamp": "2026-03-08T10:30:00Z",
     "requiresCustomerAcceptance": false,
     "fieldsChecked": ["accountHolderName", "details/bankCode", "details/accountNumber"],
     "message": null,
     "resolvedName": null,
     "providedName": null,
     "recommendedUpdates": []
   }
 ]
}
}

PARTIAL_FAILURE (name doesn't match)

All name mismatches for IDR, whether a close match or a completely different name, produce PARTIAL_FAILURE. The recommendedUpdates field contains the registered name from BCA, so you can suggest the user update the name.

{
"id": 123456,
"type": "indonesian",
"accountHolderName": "Budi Santoso",
"details": {
 "bankCode": "bca",
 "accountNumber": "1234567890"
},
"confirmations": {
 "acceptedOutcomes": false,
 "acceptedAt": null,
 "quoteId": null,
 "outcomes": [
   {
     "type": "NAME_MATCHING",
     "outcome": "PARTIAL_FAILURE",
     "timestamp": "2026-03-08T10:30:00Z",
     "requiresCustomerAcceptance": true,
     "fieldsChecked": ["accountHolderName", "details/bankCode", "details/accountNumber"],
     "message": "The name you entered doesn't match the account holder's name. Please check and try again.",
     "resolvedName": null,
     "providedName": null,
     "recommendedUpdates": [
       {
         "path": "accountHolderName",
         "value": "Budi Santoso Wijaya"
       }
     ]
   }
 ]
}
}

COULD_NOT_CHECK (unsupported bank or service error)

Returned when an internal Wise error occurs.

{
  "id": 123456,
  "type": "indonesian",
  "accountHolderName": "Budi Santoso",
  "details": {
    "bankCode": "mandiri",
    "accountNumber": "1234567890"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "COULD_NOT_CHECK",
        "timestamp": "2026-03-08T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "details/bankCode", "details/accountNumber"],
        "message": "We couldn't verify the account holder's name right now. You can still proceed.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

Accept confirmation outcomes

The requiresCustomerAcceptance field is true when the outcome value is PARTIAL_FAILURE or COULD_NOT_CHECK.

Before you can use the recipient for a transfer, you must make a PATCH request to confirm the user has acknowledged the result.

Request

Endpoint: PATCH /v1/accounts/{accountId}/confirmations or PATCH /v2/accounts/{accountId}/confirmations

Body:

{
  "acceptedOutcomes": true
}

Response after acceptance

The response mirrors the original confirmations object, but now acceptedOutcomes is true and acceptedAt contains a timestamp:

{
  "confirmations": {
    "acceptedOutcomes": true,
    "acceptedAt": "2026-03-08T10:35:00Z",
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "PARTIAL_FAILURE",
        "timestamp": "2026-03-08T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "details/bankCode", "details/accountNumber"],
        "message": "The name you entered doesn't match the account holder's name. Please check and try again.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": [
          {
            "path": "accountHolderName",
            "value": "Budi Santoso Wijaya"
          }
        ]
      }
    ]
  }
}

Test in the sandbox

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

How to trigger each verification outcome

The verification result depends on the relationship between the name you provide when creating the recipient and the registered name on the actual bank account at data provider.

IDR verification behavior in the sandbox depends on the data provider API availability. If unavailable, verification will return ``COULD_NOT_CHECK`.