Skip to main content
Tazamatch is available in sandbox by default. To test different verification scenarios, pass the account number / IBAN values shown below to POST /v3/verify/payee (with any name - name does not drive the outcome - and the BIC / sort code shown where applicable).
Country and currency have no effect on sandbox behaviour; only the account number / IBAN drives the response.

Match outcomes

For the corresponding account number / IBAN, the outcomes would be same as below.

account_exists variants

beneficiary_type not returned

matched_name_details - corrected & translated name

corrected_name is the suggested correct name; surface it to the payer for confirmation. translated_name is relevant for cross-script corridors (Korean, Chinese, Arabic).

additional_information - transaction activity

transaction_activity = false does not mean the account is inactive; it means no recent transaction activity was detected in the observed time period. A “returned false” case is only distinguishable from “not returned” when transaction_activity_started_at also accompanies it - the response omits the transaction_activity_details block entirely unless one of the two fields is present.

Combined scenarios

Multiple verified_information fields returned together in a single response. All rows have verification_status = valid.

Error scenarios

CreditorAccountFlagged means the account exists but has been flagged (e.g. suspected fraud/compliance hold) - block the payment; do not expose the raw flag reason to the payer. Only an unrecognised response code returns verification_status = failed; invalid and not_supported are the outcomes for every documented error code above.

HTTP error responses

These two cases simulate a technical failure during verification: an HTTP error is returned, no verification record is created, and no fee is charged - unlike every other case on this page, which returns HTTP 200 with a persisted record.