We create digital solutions that work for businesses
A single wrong character in bank details can delay a payment, cause a return, or send money to the wrong recipient. An IBAN should therefore be checked after every manual entry or copy from an invoice, contract, email, PDF, or message.
The technical check is fast: remove spaces, verify the country code and national length, reject invalid characters, and calculate the checksum. Yet this is only the first layer. A valid IBAN follows the expected format and mathematical rule; it does not prove that the account is active, belongs to the named business, or was supplied by an authorised person.
This guide covers both layers: format validation and safe beneficiary verification.
IBAN stands for International Bank Account Number. It follows ISO 13616 and combines a country code, two check digits, and a country-specific Basic Bank Account Number. This structure allows banks and payment systems to detect many input errors before processing a transfer.
An IBAN is not a card number. A payment card may be linked to a bank account, but its number, expiry date, and security code are not part of the IBAN. IBAN is also different from SWIFT/BIC: the former identifies an account in a standardised format, while the latter identifies a financial institution in international financial messaging.
Ukraine uses a 29-character IBAN beginning with UA. Electronic records must use Latin characters.
The format can be represented as:
UAkk bbbbbb aaaaaaaaaaaaaaaaaaa
| Part | Length | Meaning |
|---|---|---|
UA |
2 | Ukraine country code |
kk |
2 | check digits |
bbbbbb |
6 | bank code |
aaaaaaaaaaaaaaaaaaa |
19 | customer account number |
Spaces are added only for readability. Software normally validates and transmits the compact form. Because the check digits depend on the complete number, most single-character entry errors cause the checksum test to fail.
Remove spaces, hyphens, tabs, and line breaks. Convert Latin letters to uppercase. Do not replace lookalike characters by guessing: O and 0, or I and 1, are different values.
A Ukrainian IBAN begins with UA and contains exactly 29 characters. Other countries use different fixed lengths, so the Ukrainian rule must not be applied globally. SWIFT, the ISO 13616 registration authority, publishes the registry of national IBAN formats.
IBAN uses Latin letters A–Z and digits 0–9. Characters pasted from another alphabet may look identical but fail electronic processing.
The standard check uses MOD 97:
move the first four characters to the end;
convert letters to numbers, with A = 10, B = 11, and so on;
calculate the resulting number modulo 97;
a valid IBAN produces a remainder of 1.
Manual calculation is impractical. Use a bank application, an official banking service, or a reputable validator with a clear data policy. BB STUDIO also maintains a collection of free online tools for websites, domains, and routine digital tasks.
Before a first or high-value payment, compare the beneficiary name, company identifier, invoice, amount, currency, and payment reference. If bank details have changed, call a known number from the contract or official website instead of replying through the same email thread. A small test payment can be appropriate where fees and company policy allow it.
| A check can confirm | A check cannot confirm |
|---|---|
| national format | that the account is active |
| correct length | the legal account owner |
| permitted characters | the recipient’s integrity |
| valid checksum | support for a specific currency or transfer type |
| sometimes the bank code and name | that details were not replaced in an invoice or email |
This distinction matters. A malicious party can substitute its own technically valid IBAN for a supplier’s number. The checksum will pass because the replacement account is real in format; beneficiary verification is what exposes the mismatch.
The Ukrainian format includes a six-digit bank code. A current banking directory can map that code to a financial institution, and many validators do this automatically. It is a useful consistency check when an invoice names a different bank.
An open validator normally cannot reveal the person or company that owns the account. Your bank may display or verify beneficiary information while preparing a transfer, but coverage depends on the bank, payment rail, and applicable law. Treat websites promising to reveal any IBAN owner with caution.
Manual transcription frequently drops or duplicates a digit. A country-length check catches this before checksum calculation.
The UA prefix must use Latin letters. Take extra care with details extracted from scans, images, and OCR-processed PDFs.
Zero and O, or one and I, can be difficult to distinguish in some fonts. Copying from a trusted digital source is safer than retyping.
A pasted value may include a non-breaking space or line break. A well-designed form removes these before validation.
A correctly formatted account may no longer be used. Unexpected “our bank details have changed” messages require independent confirmation.
A valid IBAN does not guarantee that the account accepts the intended currency or international payment type. Confirm this with the beneficiary or bank.
Did the details come from a contract, invoice, verified portal, or an informal message?
Does the beneficiary name and company identifier match your documents?
Does a Ukrainian number begin with UA and contain 29 characters?
Does the checksum pass?
Does the embedded bank code match the named bank?
Were the details changed without prior agreement?
Are amount, currency, and payment reference correct?
Were new details confirmed through an independent channel?
Has the payment received the approval required by company policy?
Machine-readable payment details can be presented using a QR code generator. A QR code only reproduces the encoded content, so details should be checked both before generation and after scanning.
When customers or suppliers enter bank details into a form, validation should happen at two levels.
The interface can:
remove spaces and hyphens;
uppercase letters;
detect the country prefix;
enforce the country-specific length;
reject unsupported characters;
calculate MOD 97;
provide a specific, actionable error.
During professional website development, these rules should be documented together with requirements for data storage, logging, access, and revalidation.
Browser checks can be bypassed, so the server must repeat normalisation and checksum validation. Payment and payout systems also need an up-to-date format registry, graceful API failure handling, and a manual review route.
For checkout flows, an online store development team should test the whole payment journey: beneficiary, currency, transaction status, retries, duplicate prevention, and clear failure messages.
Do not send bank details to unknown analytics or advertising tools. Apply role-based access, an audit trail, and multi-factor authentication. Create unique credentials with a secure password generator and keep them in a password manager.
Payment integrations need updates and monitoring after launch. Ongoing website support can cover dependency changes, logs, error alerts, and regression tests.
“Invalid IBAN” gives the user no direction. Better messages include:
“A Ukrainian IBAN must contain 29 characters”;
“Use Latin letters only”;
“The checksum does not match; verify the bank details”;
“The format is valid, but confirm the beneficiary before payment.”
Clear feedback reduces retries and support requests. It is also a hallmark of thoughtful product work visible across BB STUDIO’s website portfolio.
For a bank, accounting platform, marketplace, or B2B service, a dedicated checker can attract qualified search traffic and reduce support demand. A bare input and button, however, are not enough. The page needs an understandable result, privacy explanation, mobile usability, limitations, and an appropriate next action.
An SEO strategy can connect the tool with supporting content and structured data while preventing duplicate pages from competing with one another. To estimate a checker, CRM integration, or payment workflow, contact BB STUDIO.
Reliable IBAN checking has two layers. Technical validation confirms country, length, characters, structure, and checksum. Operational verification confirms the beneficiary, source of the details, currency, payment reference, and any change through an independent channel.
A valid number reduces accidental input errors. It does not replace beneficiary verification. Businesses need both layers to reduce failed payments and invoice-redirection risk.
It has 29 characters: UA, two check digits, a six-digit bank code, and a nineteen-digit customer account number.
Yes. A bank app or reputable online validator can check format and checksum. Review the service’s data policy before submitting bank details.
No. It proves format and checksum only. Ownership requires verification through the bank, documents, and an independent contact with the beneficiary.
The Ukrainian format contains a six-digit bank code that can be matched to a current directory. This does not prove that the particular account is active.
Do not guess the missing or incorrect character. Obtain the details again from a trusted source and do not initiate payment until the discrepancy is resolved.
IBAN is designed to receive payments, but share only the information required for the transaction. Never send a PIN, password, one-time code, or card security code with it.
Web development
Analytics and Conversion
Design & UI/UX
Analytics and Conversion
Let’s create something amazing together 
