Basic IBAN Validation: Fast Format and Structure Checks via API

Not every IBAN validation needs a full bank data lookup. When a user is filling out a payment form and you want to catch typos before they hit submit, you do not need to resolve the BIC or check SEPA participation. You need to know one thing: is this a structurally valid IBAN?

Edge's Basic IBAN Validation endpoint answers that question in milliseconds, at a cost of just 1 credit per request. It checks the format, verifies the length against country rules, and runs the MOD-97 checksum algorithm. If the IBAN passes all three checks, it is structurally sound. If it fails, you get specific details about what went wrong.

This article covers when to use basic validation, what it checks, how to integrate it into forms and pre-screening workflows, and when you should step up to full validation instead.

What Basic Validation Checks

The Basic IBAN Validation endpoint performs three layers of verification on every submitted IBAN.

1. Format Check

The first check confirms that the IBAN follows the correct overall format:

• Starts with exactly 2 uppercase letters (the ISO 3166-1 country code)
• Followed by exactly 2 digits (the check digits)
• Followed by up to 30 alphanumeric characters (the BBAN)
• Contains no spaces, hyphens, or special characters (though the API strips whitespace automatically)

This catches obvious errors like account numbers submitted without a country prefix, strings containing punctuation, or completely non-IBAN input.

2. Length Validation

Every IBAN country defines a fixed length for its IBANs. German IBANs are always 22 characters. British IBANs are always 22. French IBANs are always 27. Bahraini IBANs are always 22. Norwegian IBANs are always 15.

The basic validation endpoint checks the country code, looks up the expected length, and verifies that the submitted IBAN matches exactly. This catches truncated or padded IBANs — a common problem when data is copied from spreadsheets or PDFs where columns may clip long values.

Here is a sample of the country length rules the API enforces:

Country	Code	Length	Example
Germany	DE	22	DE89370400440532013000
United Kingdom	GB	22	GB29NWBK60161331926819
France	FR	27	FR7630006000011234567890189
Bahrain	BH	22	BH67BMAG00001299123456
Saudi Arabia	SA	24	SA0380000000608010167519
Netherlands	NL	18	NL91ABNA0417164300
Norway	NO	15	NO9386011117947
Switzerland	CH	21	CH9300762011623852957
Spain	ES	24	ES9121000418450200051332
Italy	IT	27	IT60X0542811101000000123456

3. MOD-97 Checksum Verification

The MOD-97 algorithm is the mathematical heart of IBAN validation. It uses the two check digits (positions 3-4) to verify the integrity of the entire number. The algorithm works by:

1. Moving the first four characters (country code + check digits) to the end of the string.
2. Converting all letters to numbers (A=10, B=11, ..., Z=35).
3. Computing the remainder when dividing by 97.
4. Confirming the remainder equals 1.

This check catches the errors that matter most in practice:

• Single-character typos. If any one character is wrong, the checksum will fail. The probability of a random single-character error passing the checksum is less than 1%.
• Transposition errors. Swapping two adjacent characters (a very common mistake when typing long numbers) is always caught.
• Missing or extra characters. Any change in length will also change the checksum result.

The MOD-97 algorithm cannot catch every possible error — if someone changes two characters in a way that happens to produce the same remainder, it will pass. But statistically, it catches over 99% of common transcription errors, making it an excellent first line of defense.

Making a Basic Validation Request

Using curl

curl -X POST https://api.edge.bh/v1/services/iban/validate-basic \
  -H "X-Api-Key: your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{"iban": "DE89370400440532013000"}'

Using JavaScript

const response = await fetch(
  'https://api.edge.bh/v1/services/iban/validate-basic',
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'your_api_key_here',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ iban: 'DE89370400440532013000' }),
  }
);

const result = await response.json();
console.log(result);

Success Response

{
  "valid": true,
  "iban": {
    "formatted": "DE89 3704 0044 0532 0130 00",
    "electronic": "DE89370400440532013000",
    "country_code": "DE",
    "check_digits": "89",
    "bban": "370400440532013000"
  },
  "country": {
    "name": "Germany",
    "iso": "DE",
    "iban_length": 22
  },
  "validations": {
    "format": true,
    "length": true,
    "checksum": true,
    "country_code": true
  }
}

Failure Response

When validation fails, the response tells you exactly which checks did not pass:

{
  "valid": false,
  "iban": {
    "electronic": "DE89370400440532013099"
  },
  "country": {
    "name": "Germany",
    "iso": "DE",
    "iban_length": 22
  },
  "validations": {
    "format": true,
    "length": true,
    "checksum": false,
    "country_code": true
  },
  "errors": [
    "MOD-97 checksum verification failed — the IBAN contains a transcription error"
  ]
}

Notice how the format, length, and country code checks all passed — the IBAN looks correct on the surface. But the checksum failed, indicating that one or more characters are wrong. This is the exact scenario basic validation is designed to catch: an IBAN that looks plausible but contains a subtle error.

When to Use Basic Validation

Real-Time Form Validation

The primary use case for basic validation is catching errors as users enter IBANs in your web or mobile forms. When a user tabs out of the IBAN field or clicks submit, fire a basic validation request. If it fails, show an inline error before the form is submitted.

// React example: validate on blur
function IbanInput({ value, onChange, onValidation }) {
  const validateIban = async () => {
    if (!value || value.length < 5) return;

    try {
      const res = await fetch(
        'https://api.edge.bh/v1/services/iban/validate-basic',
        {
          method: 'POST',
          headers: {
            'X-Api-Key': process.env.NEXT_PUBLIC_API_KEY,
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({ iban: value.replace(/\s/g, '') }),
        }
      );
      const data = await res.json();
      onValidation(data);
    } catch {
      // Network error — do not block the user
      onValidation(null);
    }
  };

  return (
    <input
      type="text"
      value={value}
      onChange={(e) => onChange(e.target.value)}
      onBlur={validateIban}
      placeholder="DE89 3704 0044 0532 0130 00"
    />
  );
}

At 1 credit per request, the cost of validating every IBAN entry on blur is negligible. And it prevents bad data from ever entering your system.

Pre-Screening Before Full Validation

If you process large volumes of IBANs and want to minimize the cost of full validation (which includes bank data lookup at 3 credits per IBAN), use basic validation as a pre-screen. Run all IBANs through basic validation first at 1 credit each. Only send the ones that pass basic validation to the full validation endpoint.

For IBANs that fail basic validation, you already know they are invalid — there is no point paying for a bank data lookup on an IBAN with a bad checksum.

async function efficientValidation(ibans) {
  // Step 1: Basic validation (1 credit each)
  const basicResults = await Promise.all(
    ibans.map(async (iban) => {
      const res = await fetch(
        'https://api.edge.bh/v1/services/iban/validate-basic',
        {
          method: 'POST',
          headers: {
            'X-Api-Key': apiKey,
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({ iban }),
        }
      );
      return { iban, result: await res.json() };
    })
  );

  const structurallyValid = basicResults.filter((r) => r.result.valid);
  const structurallyInvalid = basicResults.filter((r) => !r.result.valid);

  // Step 2: Full validation only for structurally valid IBANs (3 credits each)
  // Or use the bulk endpoint for 2 credits each
  const fullResults = await validateFull(
    structurallyValid.map((r) => r.iban)
  );

  return { fullResults, structurallyInvalid };
}

This two-stage approach is most cost-effective when you expect a significant portion of your IBANs to fail basic validation — for example, when processing user-submitted data or imported files from unreliable sources.

Quick Data Quality Assessment

When you receive a file of bank account data from a partner, client, or legacy system, run a quick basic validation pass to gauge data quality before investing in full validation. If 40% of the IBANs fail basic checks, you know the dataset needs cleanup before it is worth running through full validation.

Mobile and Offline-First Applications

Basic validation's speed (typically under 50ms response time) and low credit cost make it ideal for mobile applications where you want to validate input without noticeable latency. If connectivity is intermittent, you can even implement the format check and length check client-side and defer only the MOD-97 verification to the API.

Basic vs. Full Validation: When to Upgrade

Basic validation tells you the IBAN is structurally sound. Full validation tells you it corresponds to a real bank account at a real financial institution. Here is when you need which:

Scenario	Basic	Full
Form input validation (catch typos)	Yes	Optional
Pre-screening imported data	Yes	Follow up
Before executing a payment	No	Yes
Payment onboarding (store bank details)	No	Yes
Payroll processing	No	Yes
KYC/compliance verification	No	Yes
Data quality assessment	Yes	Optional

The rule of thumb: if money will move based on this IBAN, use full validation. If you are just catching typos or screening data quality, basic validation is sufficient.

For comprehensive validation that includes bank data lookup, BIC resolution, and SEPA detection, see our complete IBAN validation guide. For batch processing, the Bulk IBAN Validation API gives you full validation at a reduced per-IBAN cost.

Formatting the IBAN for Display

The basic validation response includes both electronic and formatted versions of the IBAN. The electronic format (DE89370400440532013000) is what you should store in your database and use in API calls. The formatted version (DE89 3704 0044 0532 0130 00) groups characters into blocks of four for readability and should be used only for display purposes.

A common UX pattern is to auto-format the IBAN as the user types, inserting spaces after every four characters. This makes it easier for users to read and verify what they have entered:

function formatIbanInput(value) {
  const cleaned = value.replace(/\s/g, '').toUpperCase();
  const groups = cleaned.match(/.{1,4}/g);
  return groups ? groups.join(' ') : '';
}

Always strip spaces before sending the IBAN to the API. The Edge API does handle whitespace gracefully (it strips it server-side), but it is good practice to send clean input.

Error Messages for Users

When basic validation fails, use the validations object to show specific, helpful error messages rather than a generic "Invalid IBAN":

function getIbanErrorMessage(validations) {
  if (!validations.format) {
    return 'Please enter a valid IBAN starting with a 2-letter country code (e.g., DE, GB, FR).';
  }
  if (!validations.country_code) {
    return 'The country code is not recognized. Please check the first two letters.';
  }
  if (!validations.length) {
    return 'The IBAN length is incorrect for this country. Please check that no characters are missing or extra.';
  }
  if (!validations.checksum) {
    return 'The IBAN contains a typo. Please double-check each character carefully.';
  }
  return 'The IBAN is invalid. Please verify and re-enter it.';
}

Specific error messages dramatically improve form completion rates. A user who sees "The IBAN length is incorrect for this country" knows to count their characters. A user who sees "Invalid IBAN" has no idea what to fix.

Getting Started

Basic IBAN Validation is available on all Edge plans, including the free tier. Sign up on the Edge dashboard, generate an API key, and start validating IBANs in minutes.

For use cases that also involve validating other data types alongside IBANs — such as email addresses or phone numbers during customer onboarding — explore our Email Validation API and Phone Validation API.

Frequently Asked Questions

How much does basic IBAN validation cost?

Basic IBAN validation costs 1 credit per request. This makes it the most cost-effective validation option in Edge's IBAN service suite. By comparison, full validation (which includes bank data lookup) costs 3 credits per request, and bulk validation costs 2 credits per IBAN. If you only need to verify format and checksum — for example, in a form validation scenario — basic validation gives you what you need at one-third the cost of full validation.

What is the response time for basic validation?

Basic validation typically responds in under 50 milliseconds. Because it does not perform a bank directory lookup (which is the most time-consuming part of full validation), it is significantly faster. This makes it ideal for real-time form validation where users expect instant feedback.

Does basic validation catch all IBAN errors?

Basic validation catches all structural errors: wrong format, incorrect length, and checksum failures (which cover typos and transpositions). It does not catch errors that require external data, such as an IBAN with a bank code that does not correspond to any real institution, or an IBAN where the BBAN structure does not match the country's specific rules. For those checks, you need full validation. In practice, basic validation catches the vast majority of real-world input errors because most mistakes are typos, and the MOD-97 checksum detects over 99% of single-character errors.

Does the basic endpoint return bank name or BIC?

No. Basic validation only returns the parsed IBAN components (country code, check digits, BBAN) and the validation results. It does not perform a bank directory lookup, so bank name, BIC/SWIFT code, and branch information are not included. If you need bank data, use the full validation endpoint or the Bulk IBAN Validation API.

Can I use basic validation for compliance purposes?

Basic validation can be part of a compliance workflow — it verifies that the IBAN is structurally valid — but it is generally not sufficient on its own for regulatory compliance. Compliance requirements like KYC and PSD2 typically require verification that the IBAN corresponds to a real financial institution, which requires full validation. Use basic validation as a pre-screen and follow up with full validation for records that need compliance-grade verification.

Should I implement basic validation client-side instead of using the API?

You can implement format and length checks client-side to provide instant feedback without an API call. However, the MOD-97 checksum requires careful implementation to handle the large-number arithmetic correctly (IBANs can produce numbers with 38+ digits). The API handles this reliably and also stays updated with country length rules as new countries adopt IBAN. A good hybrid approach is to do format checks client-side for instant feedback and call the API on form submission for the authoritative checksum verification.