How Fake IBANs Exposed a SEPA Direct Debit Risk Gap in Subscription Billing

The Incident in Brief: A Gap in Business Judgment, Not a Broken Cipher

A class of online subscription services offered SEPA direct debit for top-ups and membership activation. Attackers did not break cryptography or compromise the payment network. They submitted IBAN strings that were fully valid in format and constructed direct debit instructions that looked normal. The business side treated “IBAN format check passed” or “instruction submitted successfully” as “payment confirmed,” then released entitlements. That created a risk of financial loss.

The core issue is a state-machine mismatch. The payment channel reported only that an instruction had been initiated or accepted, while the business system treated it as settled. IBAN validity is a string-level self-check. It does not prove that the account exists, that the account holder authorized the debit, or that settlement will succeed. Treating format validation as payment confirmation is the most dangerous misconception in the chain.

IBAN Check Math: A Short Algorithm Can Produce a Format-Valid String

IBAN validity can be decided offline, without querying a bank. The core step is a modulo operation: move the first four characters—the country code and check digits—to the end, expand letters as A=10, B=11, through Z=35, and require the resulting integer N to satisfy N mod 97 = 1. To generate check digits, set them to 00, compute an intermediate value N′, then take c = 98 − (N′ mod 97).

Any team with basic programming skills can therefore generate an IBAN that is 100 percent valid in format within milliseconds. The following pseudocode is only for validation and testing:

def is_valid_iban(iban: str) -> bool:
    s = iban.replace(" ", "").upper()
    if len(s) < 5:
        return False
    rearranged = s[4:] + s[:4]
    digits = "".join(str(int(ch, 36)) for ch in rearranged)
    return int(digits) % 97 == 1

This function answers only whether a string satisfies the IBAN check rules. It does not answer whether the account exists, whether a debit mandate is authorized, or whether the payment will be returned. If a business system stops at a mod-97 check plus a bank-code allowlist, an attacker only needs a number whose bank code really exists and whose check digits are correct to bypass a large part of that lightweight validation.

Why German IBANs Were a Preferred Target

A German IBAN has a fixed length of 22 characters and a relatively simple structure: after the country code and check digits, positions 5 through 12 are an eight-digit bank code, followed by the account portion. Bank-code directories are published by the central-bank system and can be downloaded by anyone. For an attacker, the cost of generating a German IBAN that is both format-valid and tied to a real bank code is very low. For a defender that only checks format and a bank-code allowlist, it is almost impossible to distinguish a normal user from a constructed number.

Traceability after the fact matters as well. Public material from some payment service providers indicates that, under privacy rules, disputed German transactions may come with less additional reason detail, and chargeback evidence collection can be relatively limited. Within SEPA, the German direction can therefore combine weak front-end verifiability with weaker back-end traceability. Attackers chose that direction not because an algorithm was broken, but because business checks, dispute evidence, and compliance handling together created a lower-cost attack surface.

How SEPA Direct Debit Risk Differs from Card Payments

Card payments generally use an authorization model. After authorization succeeds, funds can be held or confirmed, and the merchant releases benefits only after a clear success state. Risk is handled relatively early. SEPA direct debit is “initiate first, settle later.” After the merchant submits an instruction, the channel may accept it before clearing and settlement. During that interval, a nonexistent account, an invalid mandate, insufficient funds, or a customer refusal can all lead to a return.

If both payment methods share one entitlement-release path, an accepted direct debit is treated like a successful card authorization. The correct approach is a separate state machine for each method, for example:

• initiated: the instruction has been submitted;
• accepted: the channel has accepted it;
• pending_settlement: waiting for settlement;
• settled: funds are confirmed received;
• returned: the payment was returned or failed;
• revoked: entitlements have been recovered or frozen.

Entitlement release should be bound to settled, or to a state confirmed by risk policy, not to initiated. For subscription activation, freeze a quota first and grant the benefit later, or delay release through a risk observation window, so the settlement cycle is decoupled from the entitlement lifecycle.

Compliance Constraints Make Incident Response Harder

SEPA rules generally include a prohibition on IBAN discrimination: a payee cannot refuse a payment solely because the payer’s IBAN belongs to a particular member state. The rule exists to keep the European payments market open, but it constrains risk control. A business cannot easily “turn off Germany and keep other countries.” If the whole direct debit channel shares one compliance and risk configuration, the middle ground shrinks, and the remaining choices are often all on or all off.

That helps explain why emergency action can look blunt: take the entire channel offline. Long weekend approval chains, thin on-call staffing, and slow cross-team decisions can stretch the exposure window further. Payment risk design must therefore consider not only whether a check is possible, but whether, after an incident, the business can roll out changes gradually, rate-limit by risk level, and degrade quickly within what compliance allows.

Engineering Fixes

First, use layered validation. Format checking is only the first layer. The second is bank-code and account-structure validation. The third is authorization-instruction and mandate checks. The fourth is account-name matching, risk scoring, and behavioral signals. The fifth is confirmation of settlement status. Passing any single layer should not directly trigger a high-value entitlement.

Second, decouple entitlement release from settlement. For direct debit, delay benefits or cap the amount. Raise the observation period for higher-risk countries, higher-risk bank codes, and abnormal registration behavior. The recovery path must be executable; do not only grant and never reclaim.

Third, give each payment method its own state machine and its own switches. Cards, direct debit, and other local methods should have separate rate limits, gradual rollout, circuit breakers, and entitlement policies. Emergency switches should degrade by payment method, risk level, transaction amount, and account age, rather than only shutting down the whole channel.

Fourth, monitor and audit. Focus on IBAN generation patterns, clustering on the same bank code, bulk registration in a short window, entitlement consumption speed, return rates, and the conversion rate from accepted instructions to settlement. General logging and alerting can record the payment-event flow and preserve a full audit trail of submission, state changes, entitlement grants, and recovery.

Fifth, review compliance and engineering together. A ban on country-based discrimination does not mean abandoning risk control. Differentiation can still use risk scores, mandate verification, account-name checks, and settlement delay. Emergency plans should be reviewed in advance by legal, compliance, risk, and engineering teams so an incident is not forced into a rushed choice between fully open and fully closed.

Conclusion

The lesson is not that the IBAN algorithm was cracked. It is that format validity was mistaken for payment confirmation. An IBAN is a self-checking string, and SEPA direct debit is initiated before it is settled. Entitlement release must be driven by settlement status and risk policy. For subscription top-ups, the security boundary is not string validation. It is the joint design of the payment state machine, the entitlement lifecycle, compliance constraints, and emergency switches. Only by governing acceptance, settlement, and entitlements separately can similar constructed-IBAN risk keep losses and response cost within an acceptable range.