> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ibantrack.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Match Results

> Understanding verification outcomes: How to interpret status, match_result, and status_reason

# Understanding Match Results

The `match_result` field is the core outcome of your request. It is **only available** when the verification `status` is `completed`.

`match_result`returns one of four possible outcomes:

## Match

```json theme={null}
{
  "id": "abc123ab-3171-4e97-92ec-a11e9fabc123",
  "status": "completed",
  "match_result": "match"
}
```

**Meaning:** The provided name **exactly matches** the bank's registered account holder.

**Recommended actions:** ✅ Proceed with confidence. The IBAN belongs to the expected person/entity.

**Example:**

* You send: `"Jean Dupont"`
* Bank has: `"Jean Dupont"`

## Close Match

```json theme={null}
{
  "id": "abc123ab-3171-4e97-92ec-a11e9fabc123",
  "status": "completed",
  "match_result": "close_match",
  "matched_name": "JEAN DUCLOS"
}
```

**Meaning:** Minor discrepancies detected, but likely the same person/entity.

**Common causes:**

* Typos: `Dupont` vs `Dupond`
* Abbreviations: `J. Muller` vs `Johann Muller`
* Maiden names: `Marie Martin` vs `Marie Dubois`
* Legal Suffix Inconsistency (business accounts): `Klausen Logistic GmbH` vs `Klausen Logistic `or `Transports Martin SAS` vs `Transports Martin`

**Recommended actions:**

1. Request the user to provide a valid IBAN/Name combination
2. **OR** auto-accept if your risk tolerance allows

<Tip>
  Most `close_match` results are legitimate accounts with minor data entry errors.
</Tip>

***

## No Match

```json theme={null}
{
  "id": "abc123ab-3171-4e97-92ec-a11e9fabc123",
  "status": "completed",
  "match_result": "no_match"
}
```

**Meaning:** The provided name **does not match** the bank's records.

**Common causes:**

* Wrong IBAN entered (valid format, but wrong recipient).
* Account holder changed (e.g., business sold or rebranded).
* Fraud attempt (identity theft or invoice manipulation).

**Recommended actions:** ⛔ **Do not proceed** with payment. Request the user to confirm or correct the IBAN / name combination or to provide a proof of account ownership.

***

## Account Not Verifiable

```json theme={null}
{
  "id": "abc123ab-3171-4e97-92ec-a11e9fabc123",
  "status": "completed",
  "match_result": "account_not_verifiable",
  "status_reason": "verification_not_possible"
}
```

**Meaning:** The bank was reached (`status` = `completed`) and the **IBAN format is valid** (checksum verified), **but the account holder verification is not applicable for this specific account**.

**Common reasons:**

* Account type doesn't support verification e.g. savings accounts, closed accounts, or other account types not eligible to account holder verification
* The internal bank policy do not allow name matching on this specific account type

**Recommended actions:**

* Treat as **medium risk**
* Request additional confirmation or fallback verification

***

## Decision Matrix

| Result                   | Risk Level     | Recommended Action         |
| ------------------------ | -------------- | -------------------------- |
| `match`                  | ✅ Low          | Proceed (auto-approve)     |
| `close_match`            | ⚠️ Medium      | Review + user confirmation |
| `no_match`               | 🔴 High        | Block + request new infos  |
| `account_not_verifiable` | 🟠 Medium-High | Manual review              |

***

## matched\_name field

Ibantrack follows a **data minimization by design** approach, the`matched_name` is returned only when `match_result` is `close_match` and in a normalized form.

It is **never returned** for `match`,`no_match` or`account_not_verifiable`

This ensures:

* compliance with European data protection principles,
* reduced exposure of personal data,
* safe usage in automated payment and onboarding flows.

***

## Failed Status vs Account Not Verifiable

It's important to understand the difference between a technical failure and an institution's inability to verify.

### Technical Failure: `status: "failed"`

**Meaning:** The verification process could not complete due to a **technical or connectivity issue**.

**Retry behavior:** ✅ **A retry may succeed**, depending on the `status_reason`.

**Example:**

```json theme={null}
{
  "id": "abc123ab-3171-4e97-92ec-a11e9fabc123",
  "status": "failed",
  "status_reason": "institution_timeout"
}
```

### Verification not applicable: `match_result: "account_not_verifiable"`

**Meaning:** The bank was successfully reached and processed the request, but **cannot verify this specific account** .

**Retry behavior:** ❌ **A retry will return the same result** - the bank has definitively responded that verification is not possible for this account.

**Example:**

```json theme={null}
{
  "id": "abc123ab-3171-4e97-92ec-a11e9fabc123",
  "status": "completed",
  "match_result": "account_not_verifiable",
  "status_reason": "verification_not_possible"
}
```

See [Error Handling](/documentation/core-concepts/error-handling) for additional details and retry strategies.

***

## Best Practices

<AccordionGroup>
  <Accordion title="When to auto-accept close_match">
    **Low-risk scenarios:**

    * Employee payroll (internal data)
    * Small supplier payments (less than 500 EUR)
    * Repeat customers with history

    **High-risk scenarios (require manual review):**

    * First-time large suppliers
    * Regulatory/KYC workflows
    * High-value transfers (more than 10,000 EUR)
  </Accordion>

  <Accordion title="Re-verification frequency">
    * **Employees:** Every 12 months
    * **Suppliers:** Before each first payment
    * **Customers:** At account opening only
  </Accordion>
</AccordionGroup>

***

## Next Steps

<Card title="Error Handling" icon="triangle-exclamation" href="/documentation/core-concepts/error-handling">
  Learn how to handle failed verifications and retry logic
</Card>