INR 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 INR 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 INR recipients.

Supported recipient types

INR supports two recipient types:

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.

Bank account

The following validations occur when the recipient type is indian:

UPI

The following validations occur when the recipient type is indian_upi:

Sample field validation errors

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

Step 2: Verification

Verification runs only after all field validations pass. The result is reported in the confirmations object of the response.

How it works

For INR, verification confirms both account existence (type ACCOUNT_EXISTENCE) and name matching (type NAME_MATCHING) in a single call. These happen sequentially — account existence is verified first, and if the account exists, then name matching runs.

1. Wise calls the external verification provider with the recipient's account details.
2. The provider first verifies the account exists.

• If not, the outcome is FAILURE (account doesn't exist) and name matching is skipped.
• If the account exists, the 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 three confidence levels:

If the verification provider returns an error or times out, the outcome is COULD_NOT_CHECK. In this case, the recipient is still created, but you should inform the user that verification wasn't possible.

Fields checked by recipient type

Verification blocking outcomes

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

Possible outcomes for INR

Bank account recipient type

UPI recipient type

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": "indian",
  "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: Bank account

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

SUCCESS

{
 "id": 123456,
 "type": "indian",
 "accountHolderName": "Rajesh Kumar",
 "details": {
     "accountNumber": "1234567890",
     "ifscCode": "SBIN0001234"
      },
 "confirmations": {
 "acceptedOutcomes": false,
 "acceptedAt": null,
 "quoteId": null,
 "outcomes": [
     {
     "type": "NAME_MATCHING",
     "outcome": "SUCCESS",
     "timestamp": "2026-03-07T10:30:00Z",
     "requiresCustomerAcceptance": false,
     "fieldsChecked": ["accountHolderName", "details/accountNumber", "details/ifscCode"],
     "message": null,
     "resolvedName": null,
     "providedName": null,
     "recommendedUpdates": []
     }
   ]
 }
}

PARTIAL_FAILURE

{
  "id": 123456,
  "type": "indian",
  "accountHolderName": "Rajesh Kumar",
  "details": {
      "accountNumber": "1234567890",
      "ifscCode": "SBIN0001234"
  },
  "confirmations": {
      "acceptedOutcomes": false,
      "acceptedAt": null,
      "quoteId": null,
      "outcomes": [
          {
          "type": "NAME_MATCHING",
          "outcome": "PARTIAL_FAILURE",
          "timestamp": "2026-03-07T10:30:00Z",
          "requiresCustomerAcceptance": true,
          "fieldsChecked": ["accountHolderName", "details/accountNumber", "details/ifscCode"],
          "message": "The name you entered doesn't match the account holder's name. Please check and try again.",
          "resolvedName": null,
          "providedName": null,
          "recommendedUpdates": []
      }
      ]
  } 
}

FAILURE NO_MATCH_NAME

{
  "id": 123456,
  "type": "indian",
  "accountHolderName": "Rajesh Kumar",
  "details": {
    "accountNumber": "1234567890",
    "ifscCode": "SBIN0001234"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "FAILURE",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "details/accountNumber", "details/ifscCode"],
        "message": "The name you entered doesn't match the account holder's name. Please check and try again.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

FAILURE DOES_NOT_EXIST

V1 response (V2 uses name/fullName instead of accountHolderName in fieldsChecked):

{
  "id": 123456,
  "type": "indian",
  "accountHolderName": "Rajesh Kumar",
  "details": {
    "accountNumber": "1234567890",
    "ifscCode": "SBIN0001234"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "FAILURE",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "details/accountNumber", "details/ifscCode"],
        "message": "We couldn't verify this account. Please check the details and try again.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

COULD_NOT_CHECK

For a service error or timeout.

V1 response (V2 uses name/fullName instead of accountHolderName in fieldsChecked):

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

Sample payloads: UPI

UPI payloads have the same structure as Bank Account, but fieldsChecked contains only 2 fields (no IFSC):

• V1: ["accountHolderName", "details/accountNumber"]
• V2: ["name/fullName", "details/accountNumber"]

SUCCESS

{
  "id": 789012,
  "type": "indian_upi",
  "accountHolderName": "Priya Sharma",
  "details": {
    "accountNumber": "priya.sharma@okicici"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "SUCCESS",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": false,
        "fieldsChecked": ["accountHolderName", "details/accountNumber"],
        "message": null,
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

PARTIAL_FAILURE

{
  "id": 789012,
  "type": "indian_upi",
  "accountHolderName": "Priya Sharma",
  "details": {
    "accountNumber": "priya.sharma@okicici"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "PARTIAL_FAILURE",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "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": []
      }
    ]
  }
}

FAILURE NO_MATCH_NAME

V1 response (V2 uses name/fullName in fieldsChecked):

{
  "id": 789012,
  "type": "indian_upi",
  "accountHolderName": "Priya Sharma",
  "details": {
    "accountNumber": "priya.sharma@okicici"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "FAILURE",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "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": []
      }
    ]
  }
}

FAILURE DOES_NOT_EXIST

V1 response (V2 uses name/fullName in fieldsChecked):

{
  "id": 789012,
  "type": "indian_upi",
  "accountHolderName": "Priya Sharma",
  "details": {
    "accountNumber": "invalid.vpa@okicici"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "FAILURE",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "details/accountNumber"],
        "message": "We couldn't verify this account. Please check the details and try again.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

COULD_NOT_CHECK

V1 response (V2 uses name/fullName instead of accountHolderName in fieldsChecked):

{
  "id": 789012,
  "type": "indian_upi",
  "accountHolderName": "Priya Sharma",
  "details": {
    "accountNumber": "priya.sharma@okicici"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "COULD_NOT_CHECK",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "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, 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-07T10:35:00Z",
    "quoteId": null,
    "outcomes": [
      {
        "type": "NAME_MATCHING",
        "outcome": "FAILURE",
        "timestamp": "2026-03-07T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["accountHolderName", "details/accountNumber", "details/ifscCode"],
        "message": "The name you entered doesn't match the account holder's name. Please check and try again.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

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 or UPI.

PRIVATE entity type

BUSINESS entity type

Other scenarios