Skip to main content

​
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_resultreturns one of four possible outcomes:

​
Match

{
  "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

{
  "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
Most close_match results are legitimate accounts with minor data entry errors.

​
No Match

{
  "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.

​
Unable to Verify

{
  "match_result": "unable_to_verify",
  "status_reason": "verification_not_possible"
}
Meaning: The bank was reached but couldn’t perform the verification. This does not indicate a technical failure of the API. Common reasons:
  • Account type doesn’t support verification, or the internal bank policy do not allow name matching on this specific account type (e.g., some savings or technical accounts).
  • Temporary bank system issue
Recommended actions:
  • Treat as elevated risk
  • Request additional confirmation or fallback verification

​
Decision Matrix

ResultRisk LevelRecommended Action
match✅ LowProceed (auto-approve)
close_match⚠️ MediumReview + user confirmation
no_match🔴 HighBlock + request new infos
unable_to_verify🟠 Medium-HighManual review

​
matched_name field

Ibantrack follows a data minimization by design approach, thematched_name is returned only when match_result is close_match and in a normalized form. It is never returned for match,no_match orunable_to_verify This ensures:
  • compliance with European data protection principles,
  • reduced exposure of personal data,
  • safe usage in automated payment and onboarding flows.

​
Failed Status vs Unable to Verify

status: "failed" = Technical error (bank unreachable, timeout) 
{
  "status": "failed",
  "status_reason": "institution_out_of_scope"
}
match_result: "unable_to_verify" = Bank responded but can’t verify 
{
  "status": "completed",
  "match_result": "unable_to_verify"
}
See Error Handling for retry strategies.

​
Best Practices

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)
  • Employees: Every 12 months
  • Suppliers: Before each first payment
  • Customers: At account opening only

​
Next Steps

Error Handling

Learn how to handle failed verifications and retry logic