Options

The default options are fine for most use cases. IbanNet however does have a limited set of options:

• Registry
• Custom post-validation rules

Registry

IbanNet is by default using rules as defined by the SWIFT registry to validate strictly according to the ISO 13616](https://www.iso13616.org/ standard. SWIFT is the official registration authority for national IBAN formats.

Disclaimer: IbanNet is not endorsed or sponsored by SWIFT, or in any way affiliated. This library merely uses the specification as provided publicly by SWIFT.

Other registry providers

IbanNet also supplies a registry provider based on data from Wikipedia. The patterns defined on Wikipedia however are less exact in comparison to SWIFT, and some information is missing. This library only offers this provider as an alternative or supplement, and should only be used in cases where you really need have support for countries that are defined on Wikipedia, but not officially acknowledged by SWIFT.

Configure providers through the options:

var validator = new IbanValidator(new IbanValidatorOptions
{
    Registry = new IbanRegistry
    {
        Providers =
        {
            new SwiftRegistryProvider(),   // Preferred
            new WikipediaRegistryProvider()  // If country not available in SWIFT, use Wikipedia.
        }
    }
});

If multiple providers are registered, IbanNet will pick the ruleset for a specific country from the first provider that supports the given country.

Roll your own IIbanRegistryProvider

If you wish to extend or override validation patterns defined by the built-in providers, implement IIbanRegistryProvider. For examples of such an implementation, you can look at the source code of the built-in providers.

Custom post-validation rules

To apply additional validation logic, implement IIbanValidationRule and a custom error result. Custom rules will always be executed 'after' built-in validation has succeeded, so in that respect you can be sure the IBAN is valid when the rule executes. What extra logic is applied is up to you.

Use cases could be to verify banks, branch codes, etc. or for example to reject certain countries:

class CountryNotAcceptedError : ErrorResult
{
    public CountryNotAcceptedError(string countryCode)
        : base($"Bank account numbers from country '{countryCode}' not accepted.")
    {
    }
}

class RejectCountryRule : IIbanValidationRule
{
    private readonly ISet<string> _rejectedCountryCodes;

    public RejectCountryRule(IEnumerable<string> rejectedCountryCodes)
    {
        _rejectedCountryCodes = new HashSet<string>(rejectedCountryCodes);
    }

    public ValidationRuleResult Validate(ValidationRuleContext context)
    {
        if (_rejectedCountryCodes.Contains(context.Country.TwoLetterISORegionName))
        {
            // Return custom error if not valid.
            return new CountryNotAcceptedError(context.Country.TwoLetterISORegionName);
        }

        // Success.
        return ValidationRuleResult.Success;
    }
}

Register the rule through the options:

var validator = new IbanValidator(new IbanValidatorOptions
{
    Rules =
    {
        // Reject IBAN's from NL and GB.
        new RejectCountryRule(new [] { "NL", "GB" })
    }
});

Note: you can also implement these types of extra validation through FluentValidation or DataAnnotations, but this is up to you. If you do not want to impose a specific dependency on any of these validation frameworks, implementing a custom rule may be a good idea.