Why a valid IBAN can still be rejected: what the check digits do and do not prove

Support tickets about a "valid IBAN rejected" usually come from a mismatch of expectations. The IBAN passed every check in the form, the payment was sent, and a day later it came back with a four-letter reason code. Both sides were right: the IBAN is structurally valid, and the bank could not or would not credit it.

The short version: IBAN validation proves that the string is self-consistent and has the shape its country prescribes. It does not prove that the account exists, that it is open, that the person you named holds it, that the bank accepts that type of payment, or that the account can hold the currency you are sending. Each of those is checked somewhere else, by someone else, and each has its own failure mode.

What MOD-97 proves, precisely

An IBAN's two check digits are computed over the whole number with the MOD 97-10 algorithm from ISO/IEC 7064. Move the first four characters to the end, replace letters with numbers (A = 10 to Z = 35), and the result divided by 97 must leave a remainder of 1. The arithmetic guarantees that any single wrong character, and almost any pair of swapped characters, changes the remainder. A format check on top of it confirms the length and the position-by-position pattern that the SWIFT IBAN Registry publishes for the country, and for some countries a national check digit inside the BBAN can be verified as well.

That is the whole claim. "Valid" means: no typo of the kinds the algorithm detects, and a layout a bank in that country could have issued. Nothing in the IBAN is looked up anywhere. Every IBAN our generator produces passes all of these checks and was never issued by any bank, which is the point of a generator and also the clearest illustration of the limit. If you want to see the layers individually, paste an IBAN into the validator: it reports characters, country, length, BBAN format, check digits and national check digits as separate results. The checklist for testing IBAN validation covers what to feed it.

The account does not exist, or is closed

The most common reason. The bank code may well exist (in realistic mode our generator uses real ones for 84 countries), the account number may have the right number of digits and a correct national check digit, and still no account carries that number, or it did and was closed.

When this happens inside SEPA, the payee's bank returns the credit transfer with an ISO 20022 reason code. The ones you will meet most often:

Note what AC01 says: the account identifier is incorrect or does not exist. A perfectly formed IBAN that nobody holds comes back as AC01, with the same code as a typo. The sending side cannot tell the two cases apart from the code alone, which is one of the reasons the name check described next was introduced.

The name does not match the account

Until recently, the name on a credit transfer was carried along and ignored: Article 88 of the second Payment Services Directive makes the unique identifier (the IBAN) the thing a payment is executed against, and a payer who gave a correct IBAN with the wrong name had no claim. That has changed in the euro area. Since 9 October 2025, Regulation (EU) 2024/886 requires payment service providers in euro-area Member States to check, before a payer authorises a euro credit transfer, whether the name and the IBAN match (Article 5c of Regulation (EU) No 260/2012 as amended). Providers in other Member States have until 9 July 2027.

The outcome is shown to the payer before authorisation: a match, a close match (the actual account name is displayed), no match, or a notice that the check could not be done. A no match does not block the payment. The payer may still authorise it, but has been told that the money may go to someone else, and the liability rules in Article 5c(8) apply. In practice, a business that pays a supplier whose legal name differs from the trading name on the invoice will see no match or close match and may hold the payment. The United Kingdom has run a comparable service, Confirmation of Payee, since 2020, keyed on sort code and account number rather than IBAN.

For a developer this means the payee name is checked against the account. Store the legal or commercial name of a company and the name and surname of a person as the bank holds them, and expect a payment to be questioned when your record says "ACME" and the account says "Acme Trading B.V.".

The bank is not reachable for that kind of payment

An IBAN tells you the country and, through the bank code, the institution. It does not tell you which payment schemes that institution participates in.

Inside the European Union, Article 3 of Regulation (EU) No 260/2012 requires a bank that is reachable for national euro credit transfers to be reachable for SEPA credit transfers from any Member State, and Article 9 forbids a payee from demanding that the payer's account be in a particular Member State (the rule against "IBAN discrimination"). So a euro SEPA credit transfer to any EU IBAN should arrive, and a payee who rejects your French IBAN because it is not German is in breach of Article 9.

Outside the EU the picture is different. The geographical scope of the SEPA schemes covers 41 countries as of 2025, including Switzerland, the United Kingdom, Monaco, San Marino, Andorra, the Vatican, Albania, Montenegro, North Macedonia, Moldova and Serbia, but participation there is by adherence of each institution to the scheme, not by law. A bank in a SEPA country that has not adhered to a scheme is not reachable through it. Instant transfers add another layer: the obligation to receive and send SEPA Instant Credit Transfers applies to euro-area providers (since 9 January and 9 October 2025 respectively) and later to the others; a bank that is not an SCT Inst participant will have your instant payment rejected even though a standard credit transfer to the same IBAN works.

Beyond SEPA entirely (the Gulf states, Brazil, Pakistan and the other IBAN countries), a payment travels as an international wire through correspondent banks. The IBAN is still the account identifier, but the rules, fees and required fields are those of the sending bank, and a rejection is more likely to come from a missing field than from the IBAN itself.

The BIC is missing or wrong

Within SEPA, you cannot be asked for a BIC: Article 5(7) of the same regulation has forbidden providers from requiring the BIC of the payer's or the payee's bank since 1 February 2016 for cross-border transactions (1 February 2014 for national ones). Providers derive it from the IBAN. For payments outside SEPA, banks generally still ask for the BIC, and a BIC that does not correspond to the bank identified by the IBAN produces RC01.

A frequent cause is a bank merger: the IBAN keeps working under the old bank code, the BIC on your record was retired, and the mismatch surfaces only on international payments. The IBANpedia article on IBAN and BIC explains how the two identifiers relate.

The currency or the account type does not fit

An IBAN carries no currency. Three countries are the exception: Mauritius, Seychelles and Guatemala embed a three-letter currency code in the BBAN (MU17BOMM0101101030300200000MUR ends in MUR). Everywhere else, a valid IBAN may belong to a euro account, a dollar account or a multi-currency account, and the IBAN gives you no way to know.

SEPA credit transfers are euro transfers. Sending euro to an account held in another currency is accepted by some banks and refused by others, and where it is accepted the payee's bank does the conversion on its own terms. Sending a currency other than euro requires an international payment even between two SEPA countries. Account type matters too: AG01 above is the code for an account that cannot receive credit transfers at all, which is how some savings, loan and custody accounts are configured.

Other reasons that have nothing to do with the number

A few rejections are triggered by rules around the payment. Providers that offer instant credit transfers must screen their customers against EU targeted financial restrictive measures at least once a day (Article 5d of the amended regulation), and a hit on either side stops the payment regardless of the IBAN. Missing payer or payee details required by anti-money-laundering rules send the payment back for regulatory reasons rather than account reasons. A validator cannot see any of this.

What to do when a valid IBAN is rejected

1. Read the reason code before touching the IBAN. AC01 and AC04 mean "ask the payee for current details"; RC01 means "fix the BIC or drop it"; AG01 means "this account cannot take transfers, ask for another one".
2. Re-validate the IBAN anyway, and compare it character by character with the source document. MOD-97 catches single errors, and a two-error typo that slips through is rare, but a wrong-but-valid IBAN copied from the wrong invoice is not.
3. Check the payment type against the destination: SEPA or international, instant or standard, euro or other currency.
4. If a name check (Verification of Payee, Confirmation of Payee) returned no match or close match, treat that as the finding. The IBAN is probably right; the name on your record is probably not the one on the account.
5. In test environments, remember that a generated IBAN is a valid string with no account behind it. Any check that reaches a bank will come back negative, and that is the correct result, not a bug in the generator or in your code. The test IBANs article explains what generated IBANs are for.

Sources

• Regulation (EU) No 260/2012, consolidated text (Article 3 reachability, Article 5(7) BIC, Article 5c Verification of Payee, Article 5d screening, Article 9 payment accessibility)
• Regulation (EU) 2024/886 of 13 March 2024 (instant payments, Verification of Payee, application dates)
• Directive (EU) 2015/2366 (PSD2), Article 88, incorrect unique identifiers
• EPC, SEPA Credit Transfer Rulebook and ISO 20022 External Code Sets (return and reject reason codes)
• EPC, List of SEPA Scheme Countries (EPC409-09)
• SWIFT IBAN Registry
• Pay.UK, Confirmation of Payee