GCC IBAN, Phone, VAT and ID Validator

Validate the identifiers that Gulf (GCC) businesses and developers handle every day, in bulk, with a clear machine-readable reason for every failure: IBANs (UAE, Saudi Arabia, Qatar, Kuwait, Bahrain, Oman, plus mod-97 for any other country), phone numbers (E.164 normalisation, mobile or fixed line), UAE TRN, Saudi VAT numbers, Emirates ID and Saudi national ID / Iqama.

The actor is pure computation. It makes no web requests, so it is fast, cheap, deterministic and never blocked.

Why use it

• One run covers six GCC countries and six identifier types; generic IBAN and phone Actors do not know the UAE TRN, the Saudi VAT format or the Emirates ID structure.
• Built for KYC pre-checks, supplier onboarding, invoice (ZATCA / FTA) pipelines, CRM clean-up and AI agents that need to reject typos before calling a paid API.
• Accepts Arabic-Indic digits and messy separators (spaces, dashes, brackets).

What it checks (and does not)

It checks format and check digits only. It does not confirm that an account exists, that a tax registration is active, that an ID was issued or that a phone line is live. For registry confirmation use the FTA, ZATCA, ICP or your bank.

Type	Rule applied	Reference
IBAN	country length (AE 23, SA 24, QA 29, KW 30, BH 22, OM 23), BBAN structure for those countries, ISO 7064 mod-97 for all countries	SWIFT IBAN Registry, https://www.swift.com/standards/data-standards/iban-international-bank-account-number
UAE TRN	15 digits (no public check digit, format only)	Federal Tax Authority, https://tax.gov.ae
Saudi VAT number	15 digits, first and last digit 3	ZATCA e-invoicing specifications, https://zatca.gov.sa
Emirates ID	15 digits 784-YYYY-NNNNNNN-C, plausible birth year, Luhn check digit	Structure as documented by community libraries (https://www.nuget.org/packages/EmiratesKit.Core); the ICP does not publish a formal specification, so treat this check as a typo filter
Saudi national ID / Iqama	10 digits, starts with 1 (citizen) or 2 (resident), Luhn check digit	Community-documented algorithm; not an official specification
Phone	E.164 country calling code (971, 966, 974, 965, 973, 968), national number length, mobile or fixed-line prefix	ITU-T E.164 and national numbering plans, https://www.itu.int/oth/T0202.aspx . Prefix tables are a best-effort summary; if a new number range is released, a valid number may be reported as unknown_prefix

Input

Field	Meaning
values	One value per line, up to 50,000
type	auto (default), iban, phone, uae_trn, ksa_vat, emirates_id, saudi_national_id
defaultCountry	Country for local phone numbers like 0501234567 (default AE)
includeBlank	Emit a blank record for empty lines (default off, blanks are skipped and not billed)

auto detects: letters + digits of IBAN length as IBAN; 15 digits starting 784 as Emirates ID; 15 digits starting and ending 3 as Saudi VAT; other 15 digits as UAE TRN; 10 digits starting 1 or 2 as Saudi ID; everything else as phone. A 15-digit Saudi VAT number and a UAE TRN cannot be told apart in all cases, so choose a fixed type for important batches.

Output example

Real output of the three-value input AE07 0331 2345 6789 0123 456, 050 123 4567, 300000000000003 (the first two records, trimmed):

{
  "input": "AE07 0331 2345 6789 0123 456",
  "type": "iban",
  "valid": true,
  "reason": null,
  "normalized": "AE070331234567890123456",
  "formatted": "AE07 0331 2345 6789 0123 456",
  "country": "AE",
  "details": { "check_digits": "07", "bban": "0331234567890123456", "gcc_country": true, "length_checked": true, "bank_code": "033" },
  "detected_type": true
}
{
  "input": "050 123 4567",
  "type": "phone",
  "valid": true,
  "reason": null,
  "normalized": "+971501234567",
  "formatted": "+971 50 123 4567",
  "country": "AE",
  "details": { "country_calling_code": "971", "national_number": "501234567", "line_type": "mobile", "e164": "+971501234567" },
  "detected_type": true
}

Failure reasons include bad_length, bad_checksum, bad_bban_structure, bad_format, non_digit_characters, must_start_and_end_with_3, must_start_with_784, implausible_birth_year, not_a_gcc_country_code, unknown_prefix, blank.

Pricing (pay-per-event)

Uses Apify's built-in apify-default-dataset-item event: one validated value is one result. The owner sets the price in Apify Console. Suggested: USD 2.00 per 1,000 results. Comparable IBAN and phone validators on the Apify Store list between about USD 0.05 and USD 10 per 1,000 (checked 21 Oct 2026, see apify/RESEARCH-2.md). Platform compute is tiny (256 MB, milliseconds per value).

Limits

Up to 50,000 values per run. Format and checksum only. No lookup, no personal-data enrichment. Output depends on the rules above, which can change when authorities change formats.

FAQ

Does a valid result mean the account or ID exists? No. It means the number is well-formed and its check digit matches.

Why is my real number unknown_prefix? Prefix tables are a summary of national numbering plans. Tell us and we will update; meanwhile use the length-only result in details.

Do you store or send the values anywhere? No network calls are made. Values stay in your run's dataset, which you control.

Is it affiliated with a bank or government? No.