Requesting

Verify that an IBAN belongs to the payee you intend to pay, before initiating a transfer. This is the requesting side of Verification of Payee (VOP): you query the account-holding PSP through Qombo, in line with the EPC VOP scheme — and you also get extra IBAN insights from Qombo to assess fraud risk.

Endpoints

What you send

• iban — the IBAN to verify.
• party — who you expect to own it:
  • an individual name, or a firstName + lastName pair, or
  • one or more company identifiers in companyIds (e.g. FR_SIREN, LEI, EU_VAT), optionally combined with a name.
• Bulk wraps a data[] array of { id, iban, party }, plus an optional optout (enabled, duration in hours) to avoid re-sending a request for the same payee within a chosen window.

What you get back

• matchStatus — success or error (and not_sent in bulk when opt-out applied).
• matchCode — the VOP result, e.g. MTCH (match), CMTC (close match), NMTC (no match).
• additionalMatchCode — present when a secondary check was run.
• matchedName — the name returned on a close match.
• testsPerformed — the checks Qombo executed for this request.
• Qombo IBAN insights — ibanSeen (how many times this IBAN was checked on Qombo), ibanMinAge (oldest check), and whitelistedParty when the IBAN is on a whitelist.

📘

Match codes and identifiers

The full list of match codes is in the API reference. For the accepted company identifier types and their formats, see company identifiers.

Best practices

• Verify at beneficiary creation — call this endpoint when a new beneficiary is added in your customer's interface.
• Revalidate at first payment — before processing a first payment, either send a fresh request or reuse the previous result, based on your risk strategy.

Following these reduces misdirected payments and fraud while keeping the user experience smooth.