IBAN Validation Loopholes: Rethinking Payment Channel Risk Controls

1. The Core Issue: A Validation Semantics Mismatch, Not a “Breakthrough”

A subscription service experienced payment-channel risk during a top-up flow. The issue appeared to be that an attacker could construct a fake IBAN from a particular country and complete a payment. However, the technical root cause was not a compromise of encryption or the payment network. The business system had treated IBAN format validation as account authenticity validation.

IBAN validity can be checked offline. It does not require contacting a bank, and it does not prove that an account exists, is active, or has authorized a debit. It is simply a deterministic modulo calculation.

The validation process can be summarized as follows:

1. Remove spaces and convert the IBAN to uppercase.
2. Move the first four characters—the country code and check digits—to the end.
3. Convert letters using A=10, B=11, through Z=35.
4. Treat the result as a large integer N and require N mod 97 = 1.

To generate a number, the check digits are first replaced with 00. After calculating the intermediate value N′, the check digits are computed as:

c = 98 - (N′ mod 97)

This algorithm is designed to detect input errors, not to prevent malicious construction. Anyone who knows the rules can generate an IBAN that is structurally valid within milliseconds.

The following example illustrates the validation principle:

def iban_to_int(iban: str) -> int:
    s = iban.replace(" ", "").upper()
    s = s[4:] + s[:4]
    digits = "".join(
        str(ord(ch) - 55) if "A" <= ch <= "Z" else ch
        for ch in s
    )
    return int(digits)
def is_valid_iban_format(iban: str) -> bool:
    return iban_to_int(iban) % 97 == 1
def make_iban(country: str, bban: str) -> str:
    base = country + "00" + bban
    rearranged = base[4:] + base[:4]
    digits = "".join(
        str(ord(ch) - 55) if "A" <= ch <= "Z" else ch
        for ch in rearranged
    )
    check = 98 - (int(digits) % 97)
    return country + f"{check:02d}" + bban

This code demonstrates that format validation is inexpensive and entirely offline. If a business system performs only the modulo 97 check, perhaps combined with a bank-code allowlist, it can reject obviously malformed input but cannot determine whether the account exists, whether the debit is authorized, or whether sufficient funds are available.

The attacker is therefore submitting a structurally valid but potentially empty payment instruction. The actual loss occurs when the business mistakenly grants entitlements before the payment has been successfully settled.

2. Why Some Country-Specific Conditions Are Easier to Abuse

German IBANs, for example, have a fixed length of 22 characters. Their structure consists of:

• A two-character country code
• Two check digits
• An eight-digit bank code
• A ten-digit account number

Characters 5 through 12 contain the bank code. Bank-code directories are publicly available from the central bank, so a generator can construct an IBAN containing a genuinely existing bank code. This may be enough to bypass a lightweight validation process implemented by a merchant.

In many systems, “IBAN validation” effectively means only:

• A modulo 97 check
• A bank-code allowlist

That is where validation ends.

Forensic investigation can also be difficult after the fact. In some jurisdictions, privacy requirements mean that disputed transactions do not provide detailed explanations. As a result, the recipient may have limited information when investigating a failed or disputed debit.

Direct debit channels can therefore have low verifiability at the front end and limited traceability at the back end. The resulting risk is concentrated in the gap between payment initiation and settlement.

This should not be interpreted as a vulnerability in one country’s banking system. It is the result of differences between payment systems in privacy rules, compliance requirements, and investigation procedures—differences that can be amplified by weak business logic.

3. How Compliance Requirements Limit Risk Controls

Regional payment regulations commonly include anti-IBAN-discrimination requirements. A recipient generally cannot reject a payment solely because the IBAN belongs to a particular country, nor can it require the payer to hold an account in a specific member state.

The purpose of these rules is to support an integrated regional market. From a risk-control perspective, however, they make selective action more difficult. Once a company enables regional direct debit, it may not be able to simply disable one country while continuing to accept others.

When a risk event occurs, the emergency response may therefore appear unnecessarily broad: the entire payment channel is taken offline.

Compliance constraints can eliminate the middle ground between fully enabled and fully disabled operation. If the incident occurs over a weekend, approval workflows and limited on-call coverage can extend the recovery time even further.

Engineering teams should understand that this is not merely a technical outage. The outcome is produced by the interaction of compliance rules, payment models, and incident-response procedures.

4. Root Cause: One Entitlement Flow for Two Different Payment Models

The technical problem can be summarized in one sentence:

Card payments use an “authorization first” model, while direct debit uses an “initiate first, settle later” model, yet both paths shared the same entitlement-fulfillment logic.

Card payments generally follow an authorization model. Once authorization succeeds, the funds are effectively reserved, and the probability of a later settlement failure is relatively limited.

Direct debit follows a push-based or asynchronous model. After a transaction is created, it may remain in a processing state for several days. During that period, it can return errors such as:

• insufficient_funds
• account_closed
• branch_does_not_exist
• debit_not_authorized

If a business grants long-term entitlements as soon as the transaction is created, a later debit failure, return, or reversal creates a direct gap: the entitlement has already been consumed, but the funds have not arrived.

The correct design is to decouple payment state from entitlement state. Successful payment-object creation should provide only limited credit, a short trial, or a pending entitlement. Long-term access should be granted only after settlement succeeds or an appropriate risk-observation period has passed.

A simplified state model is:

Payment state:    CREATED -> PROCESSING -> SETTLED / FAILED / REVERSED
Entitlement state: NONE -> PENDING -> ACTIVE -> FROZEN / REVOKED

Example rules include:

• CREATED or PROCESSING: allow only temporary credit and prohibit high-value entitlements.
• SETTLED: grant the formal entitlement using an idempotency key.
• FAILED or REVERSED: freeze or revoke the entitlement and send the case for review.
• All state transitions must be idempotent, callbacks must be signature-verified, and scheduled reconciliation must provide a fallback.

5. Engineering Defenses: Layered Verification and Risk Segmentation

5.1 Do Not Stop at Format Validation

Account verification should not end with a valid IBAN structure. Depending on the payment method and available capabilities, additional controls may include:

• Account-holder name matching
• Retention of authorization evidence
• A small initial verification debit
• Bank responses or account-status queries

The available mechanisms vary by payment method, but the principle is consistent:

Format validity is input validation, not identity authentication.

5.2 Use Risk Scoring Instead of Country-Based Rejection

Compliance requirements may prohibit rejecting an IBAN solely because of its country code. They do not necessarily prevent risk scoring based on transaction and behavioral signals.

Potential risk factors include:

• Transaction amount
• Account age
• Verification status
• Device behavior
• Historical failure rate
• Dispute rate
• Concentration of submissions within the same bank-code range

High-risk combinations can be handled with delayed entitlement activation, transaction limits, or manual review instead of blanket country-based blocking.

5.3 Monitor for Generator-Like Patterns

Monitoring should identify patterns associated with automated IBAN generation or coordinated abuse. Examples include:

• A single device submitting many new IBANs within a short period
• A high concentration of submissions within the same bank-code range
• Unusually long processing durations
• Sudden changes in the distribution of failure codes
• Rising refund and dispute rates

For direct debit, the system should define a settlement observation period and delay the release of valuable entitlements. “Accepted for processing” must not be treated as equivalent to “funds received.”

5.4 Prepare Compliant Degradation Strategies

If regulations prevent country-specific shutdowns, the business should prepare alternative controls in advance. These may be based on:

• Risk level
• Transaction amount
• Verification status
• Time window

The incident plan should also cover:

• User communication during a full-channel suspension
• Order rollback
• Reconciliation
• Compensation for affected transactions

A pre-approved, compliant degradation plan is more effective than designing emergency controls after an incident has already occurred.

6. Conclusion

IBAN’s modulo 97 check is an error-detection mechanism, not a security mechanism.

The central failure in this type of incident is not that the mathematics was broken. It is that the business interpreted “format-valid” as meaning that the account was real, the debit was authorized, and the funds would settle. The risk was amplified because card authorization and direct debit initiation shared the same entitlement logic, while anti-IBAN-discrimination requirements limited fine-grained emergency actions and privacy rules made post-transaction investigation more difficult.

For engineering teams, the key defenses are:

• Decouple payment state from entitlement state.
• Delay valuable entitlement fulfillment for direct debit.
• Use layered account verification.
• Replace country-based rejection with risk scoring.
• Monitor for abnormal generation and submission patterns.
• Enforce idempotency and callback verification.
• Use reconciliation as a final safeguard.
• Prepare compliant degradation and recovery procedures.

“Validation,” “authorization,” “settlement,” and “entitlement” are four different concepts. Treating them as separate layers is essential to prevent a structurally valid but financially empty payment instruction from passing through the business logic.