8 Data Validators Your Software Probably Gets Wrong
A user enters a VIN with 18 characters. Your form accepts it. Three weeks later, your vehicle lookup API is returning nothing, and nobody can figure out why. The problem isn’t that the data looks wrong — it looks fine. The problem is your validation never ran the one check that matters.
This isn’t a hypothetical. Every engineering team has a version of it: data that slid through a form because the field wasn’t empty, then broke somewhere downstream, in the one place nobody was watching — in a payment, a compliance check, a logistics integration.
Bad data doesn’t usually crash your app. It slides through quietly and causes problems exactly where you can’t afford them — in payments, compliance, logistics, and integrations. The fix isn’t better QA. It’s validation that actually checks the format, the checksum, and the meaning of the data, not just whether a field is empty.
Here are eight validators from ElysiaTools that catch the problems most forms let slip through.
1. Credit Card Validator — The Luhn Algorithm Is Not Optional
Most form validation for credit card fields checks one thing: is it a number? That’s not validation — that’s a placeholder.
The Credit Card Validator runs the Luhn algorithm, a checksum formula invented in 1954 that’s still the industry standard for detecting typos in card numbers. Beyond the checksum, it identifies the card type — Visa, MasterCard, Amex, UnionPay, JCB — from the first digits. It also breaks the number down into its structural components: the MII (Major Industry Identifier), the IIN/BIN (the issuing bank range), and the check digit.
What this catches: typos that look valid. A card number ending in 4 instead of 3 will pass a “is it a number” check but fail the Luhn. So will reversing two consecutive digits. The validator catches both, and tells the user exactly which part of the number failed.
Use it before payment processing, not after.
2. ISBN Validator — Books Have Two Names, and Most Software Only Knows One
There are two ISBN formats in active use. ISBN-10 is 10 characters (digits plus an X as the check digit for values 10). ISBN-13 is 13 digits and always starts with 978 or 979. The two are convertible: any valid ISBN-10 can be converted to ISBN-13 by prefixing 978, and vice versa for the 978 prefix.
The ISBN Validator handles both formats, validates the checksum for each, and performs the conversion automatically. It also parses the structural components — prefix, registration group, registrant, publication, and check digit — so you can route books by publisher or region if your system needs it.
What this catches: 10-digit ISBNs entered without the hyphen being stripped, or 13-digit ISBNs missing the 978 prefix. The validator also flags invalid check digits — the most common typo in manually copied book identifiers.
3. SemVer Validator — Version Numbers Have Grammar, and Most Code Doesn’t Enforce It
Semantic Versioning (SemVer 2.0.0) is the dominant versioning convention for software packages, APIs, and libraries. The format — major.minor.patch[-prerelease][+build] — looks simple. The rules are not: no leading zeros, pre-release identifiers must be numeric-before-alphanumeric, build metadata doesn’t affect sort order, and the first digit of each segment can’t start with 0 unless the segment is a single 0.
The SemVer Validator parses a version string and returns a structured breakdown — major, minor, patch, pre-release labels, and build metadata — with validation against all SemVer 2.0.0 rules. It flags leading zeros, invalid identifier characters, and pre-release ordering violations.
What this catches: versions like 1.02.0 (leading zero on patch) or 2.0-beta.1 (misplaced hyphen) that will silently break sorting logic and package resolution in npm, pip, or any SemVer-compliant dependency manager.
4. VIN Validator — 17 Characters, One Valid Checksum, Zero Room for Error
The Vehicle Identification Number (VIN) is a 17-character string assigned to every motor vehicle. It’s not arbitrary: positions 1–3 identify the World Manufacturer Identifier (region, country, and maker). Position 9 is a checksum calculated using a weighted transliteration of all 17 characters. Positions 10 encodes the model year using a letter-code table. Positions 11–12 encode the plant. Position 13 is the serial number.
The VIN Validator checks length, character validity (three letters — I, O, and Q — are forbidden in VINs), checksum integrity, and decodes the manufacturer, country, model year, and plant from the character positions.
What this catches: 18-character strings accepted because a developer checked length >= 17. VINs with I/O/Q characters. Transposed digits that look plausible but fail the checksum. A VIN validator is non-negotiable in any logistics, insurance, or dealership system.
5. Passport Validator — Different Countries, Different Rules
Passport formats vary wildly by country. US passports are 9 digits. Japanese passports are 2 letters followed by 8 digits. Chinese passports start with a letter (E for regular, various prefixes for e-passports) followed by digits. Indian passports are 1 letter + 7 digits. Russian passports are 10 digits total. German passports are 4–11 alphanumeric characters. The rules are country-specific, and there’s no universal format to check against.
The Passport Validator accepts a country selection and validates the passport number format for any of 10 supported countries, returning the identified type, format description, and structural components.
What this catches: a Japanese passport number entered without the leading letters, or a US passport number with a letter in it. In any onboarding or travel booking system that accepts international documents, this validation prevents data that looks valid but is structurally wrong.
6. US EIN Validator — Nine Digits, Two Mean Something
The Employer Identification Number (EIN) is a 9-digit number assigned by the IRS for business tax purposes. It’s formatted as XX-XXXXXXX. But the first two digits encode the IRS “campus” that issued the number — Brookhaven, Andover, Fresno, and others. The US EIN Validator validates the format, parses the campus code, flags invalid campus codes, and warns about all-zero sequences.
What this catches: leading zeros from copy-paste errors, unknown campus codes, and all-zero sequences that suggest invalid data entering tax-adjacent workflows.
7. IBAN & SWIFT Validator — International Payments Have Two Names
International bank transfers use two different identifier systems. IBAN encodes country, check digits, bank code, and account number in up to 34 characters. SWIFT/BIC codes identify banks in 8 or 11 characters. Most systems handle one or the other, and most validation is just a length check. The IBAN & SWIFT Validator handles both, auto-detecting which is entered, running the modulo 97 checksum for IBAN, and flagging test codes (00) in SWIFT.
What this catches: wrong IBAN check digits (the entire account reference is wrong), SWIFT codes routing to test systems, and 8-character SWIFT codes entered where a branch-specific 11-character code is needed.
8. SWIFT Code Validator — The 8-Character Address That Identifies Every Bank
The dedicated SWIFT Code Validator parses the 4-letter bank code, 2-letter country code, 2-character location code, and optional 3-character branch separately. It interprets the location code’s second character to distinguish active participants, passive participants, and testing/billing codes.
What this catches: country prefix mismatches (bank code correct, country wrong), head-office-only routing where a specific branch was intended, and passive/test codes treated as active routing destinations.
The Real Fix Is Not More Regex
The pattern behind most data quality problems isn’t missing data. It’s data that looks right and isn’t. The solution isn’t stricter regex — it’s running the checksum algorithm, the format rule, the structural parser that actually defines correctness for that data type.
These eight validators — Credit Card, ISBN, SemVer, VIN, Passport, US EIN, IBAN & SWIFT, and SWIFT Code — are free at ElysiaTools. Run them before the data reaches the place where a typo becomes an incident.
