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 National Check Digit Validation
- 3 100% Test Coverage, PI-tested
- 4 Compatible (Java 8+)
- 5 Immutable & Thread-safe
- 6 Zero Dependencies & Small Footprint
- 7 Simple & intuitive, Android-compatible API
- 8 Open Source & Free of Charge
Quick Start
Maven Dependency
<dependency>
<groupId>de.speedbanking</groupId>
<artifactId>iban-commons</artifactId>
<version>1.8.4</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.
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.
What’s New in 1.8.4
Country-Agnostic Random IBANs
Two new factory methods on RandomIban
generate valid IBANs without requiring a specific country:
- RandomIban.of() — any supported country
- RandomIban.ofSepa() — SEPA countries only
Iso3166Alpha2 Enum & BIC Validation
A new Iso3166Alpha2 enum
provides a type-safe representation of all registered ISO 3166 Alpha-2 country codes.
BIC country code validation is now backed by this enum, eliminating string-based lookups
and tightening correctness guarantees at compile time.
Reduced Bic Memory Footprint
The internal Bic representation
has been slimmed down by removing a redundant char[]
field and eliminating eager computation of the padded BIC-11 form.
Both are now derived on demand, reducing per-instance heap allocation
with no change to the public API.
Performance
Leading Throughput
Outperforms all tested libraries — reaching 7.2 M ops/s on valid IBANs and nearly 12 M ops/s on invalid ones, where fast-path rejection kicks in.
Up to 5.6× Faster
On the accept path, iban-commons is ~1.4× faster than Apache Commons, ~3.7× faster than iban4j, and ~5.6× faster than Garvelink.
Minimal GC Pressure
Only ~48 B/op for valid IBAN validation — 6× less than Apache Commons (~281 B/op) and 28× less than iban4j (~1,341 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-04-09
Valid IBANs — accept path
Invalid IBANs — rejection path
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 →
