iban-commons | High-Performance IBAN Validation for Java

Why iban-commons?

Developed with a focus on Clean Code, Compatibility, and Performance, this library is designed for top-performance systems and headache-free operation.

1 Strict ISO 13616 Compliance
2 100% Test Coverage, PI-tested
3 Compatible (Java 8+)
4 Immutable & Thread-safe
5 Zero Dependencies
6 Small Footprint (~100 kB)
7 Simple & intuitive, Android-compatible API
8 Open Source & Free of Charge

Smooth Sailing

iban-commons

Quick Start

Maven Dependency

<dependency>
    <groupId>de.speedbanking</groupId>
    <artifactId>iban-commons</artifactId>
    <version>1.8.3</version>
</dependency>

Java Example

String s = "DE91100000000123456789";

if (Iban.isValid(s)) {
    System.out.println("Valid IBAN: " + s);
}

try {
    Iban iban = Iban.of(s);
    System.out.println("Country Code: " + iban.getCountryCode()); // DE
    System.out.println("Check Digits: " + iban.getCheckDigits()); // 91
    System.out.println("BBAN        : " + iban.getBban());        // 100000000123456789
} catch (InvalidIbanException ex) {
    System.err.println("Invalid IBAN: " + ex);
}

More Examples

What’s New in 1.8.3

Serialization Security

Iban and Bic now use the Serialization Proxy Pattern (Memento). Byte-stream injection attacks are blocked: deserialization always re-validates through the full ISO 7064 Mod 97-10 pipeline. Direct deserialization of raw instances throws InvalidObjectException.

SECURITY.md

Android Compatibility

New null-returning alternatives avoid java.util.Optional (requires Android API 24+) and java.time.YearMonth (requires API 26+):

Iban.tryParseOrNull(input)
Bic.tryParseOrNull(input)
IbanRegistry.getLastUpdateYear()
IbanRegistry.getLastUpdateMonth()

Feature Parity

All remaining gaps vs. alternative libraries are now closed. iban-commons leads on country coverage (120 vs. 111), BIC support, rich metadata, random IBAN generation, and validation error detail — now also matching on serialization hardening and Android-friendly API.

Performance

Leading Throughput

Outperforms all tested libraries — reaching 7.7 M ops/s on valid IBANs and 11 M ops/s on invalid ones, where fast-path rejection kicks in.

Up to 6.8× Faster

On the accept path, iban-commons is ~1.9× faster than Apache Commons, ~4.3× faster than iban4j, and ~4.8× faster than Garvelink.

Minimal GC Pressure

Only ~106 B/op for valid IBAN validation — 3× less than Apache Commons (~319 B/op) and 10× less than iban4j (~1,114 B/op).

Throughput Comparison

Operations per second (higher is better) — Intel i7-1165G7 @ 2.80 GHz, OpenJDK 21.0.7, Linux, single core (taskset -c 0)
Generational ZGC | -XX:-StackTraceInThrowable | JMH: 3 forks × 10 iterations × 2 s | 2026-03-01

Valid IBANs — accept path

iban-commons 106 B/op

7,721,430 ops/s

Apache Commons Validator 319 B/op

4,081,226 ops/s

iban4j 1,114 B/op

1,800,153 ops/s

garvelink-iban 882 B/op

1,608,650 ops/s

Invalid IBANs — rejection path

iban-commons 78 B/op

10,991,232 ops/s

Apache Commons Validator 165 B/op

9,166,116 ops/s

garvelink-iban 689 B/op

1,721,277 ops/s

iban4j 999 B/op

1,502,218 ops/s

Memory figures (B/op) from JMH gc.alloc.rate.norm profiler. All forks run with -XX:-StackTraceInThrowable to isolate algorithmic cost; exception-heavy libraries (iban4j, Garvelink) benefit from this flag on the rejection path — remove it for production-realistic numbers. Full methodology & raw data →

High-Performance IBAN processing:
iban-commons