Update dependency schwifty to v2026.10.0 #78

Merged

tux merged 1 commit from renovate/schwifty-2026.x into main

2026-10-19 20:04:24 +02:00

renovate-bot commented

2026-10-19 17:17:36 +02:00

Collaborator

This PR contains the following updates:

Package	Update	Change
schwifty (changelog)	minor	`==2026.7.3` → `==2026.10.0`

Release Notes

mdomke/schwifty (schwifty)

`v2026.10.0`

Compare Source

Added

* Added the German checksum method ``95``, used by UniCredit Bank - HypoVereinsbank (bank code
  ``70020270``). It computes like method ``06``, but treats the account ranges the Bundesbank
  exempts from the check digit as valid. Account codes for this bank were not checked before.
* Added the German checksum methods ``A2`` and ``A3``. Both check the account number with
  method ``00`` first and fall back to method ``04`` (``A2``) or ``10`` (``A3``). Banks using
  them (e.g. Nassauische Sparkasse, Sparkasse Hannover) previously had their national check
  digit silently accepted without being verified.
* Added e-money institutions and banks that were missing from the bank registries: OpenPayd
  (MT — first Maltese registry), ClearBank and Bilderlings Pay (GB), Score and Secure Payment
  and Deblock (FR), bunq, Pecunia Cards and Financière des Paiements Électroniques (ES),
  Unlimit (CY), MyFin (BG), Revolut Bank (PT), Enpara Bank (TR), United Bank and Allied Bank
  (PK — first Pakistani registry), and the BIC for PrivatBank (UA).

Changed

validate_bban=True now emits a NationalChecksumNotVerified warning when the country's
BBAN specification declares national check digits but no algorithm is registered to verify them
(35 of the 54 countries that declare check digits, e.g. HU and SE, which silently passed
before, #310). The digits are still accepted, since a missing algorithm must not reject an
otherwise valid IBAN, but the pass is no longer silent. Turn the warning into an error with
warnings.simplefilter("error", NationalChecksumNotVerified) to make the missing check fail
instead.
Removed support for deprecated Python version 3.10
Use Python 3.15 by default and in CI, with compatible Pydantic dependencies.
Registry generation scripts now use httpx2 instead of requests for HTTP downloads.
Simplified internal registry caching, character lookups, checksum helpers, and validation routines
for improved efficiency and cleaner code structure while preserving exact behavior.
Simplified the IBAN checksum validation. The redundant self.numeric % 97 == 1 test has
been dropped in favour of the stricter canonical ISO7064_mod97_10 comparison, which it
always implied. Behaviour is unchanged.
Updated the bank registries for Germany, Austria, Belgium and Poland.

Fixed

* Registry update scripts report a missing download link instead of an attribute or lookup error.
* Validating a pydantic model whose ``BIC`` field is not a string now reports a
  ``bic_format`` field error instead of letting the ``TypeError`` from ``BIC()`` escape,
  which is what the ``IBAN`` validator in the same library already does.
* The German checksum method ``63`` (used by Deutsche Bank) now accepts account numbers whose
  sub-account number ``00`` was left out and that were padded with leading zeros instead, so the
  check digit sits at position 10 (e.g. ``0001234566``), as the Bundesbank specification requires.
* ``IBAN.from_bban`` now normalizes whitespace and case before computing the checksum, matching
  the text constructors. Grouped BBANs and lowercase country codes no longer raise a raw
  ``KeyError`` during checksum calculation.
* The German checksum method ``99`` now accepts every account number from ``0396000000`` to
  ``0499999999`` without a check, as the Bundesbank specification requires. Previously only the
  two range boundaries were exempt, so valid account numbers in between (e.g. at UniCredit Bank -
  HypoVereinsbank) could be rejected.
* Added the Cypriot BIC ``OROACY2LXXX`` (ORO PAY LTD) to the manual registry (#&#8203;297).
* Eight-character BICs now fall back to their equivalent ``XXX`` registry entry for
  bank codes and names when an exact entry is absent. Exact matches still take priority.
* Eleven-character BICs now fall back to the eight-character institution entry when the
  registry holds no branch-specific record. An 11-character BIC denotes a branch of the
  institution its first eight characters identify, but not every national registry lists
  entries per branch (#&#8203;112).
* ``IBAN.bank`` (and with it ``IBAN.bank_name`` and ``IBAN.bank_short_name``) now
  resolve a bank code to the registry record flagged ``primary`` instead of whichever
  record happened to be read first. National registries list one record per branch, so
  the two could name a different institution than ``IBAN.bic`` does.
* ``BIC.from_bank_code`` now prefers BICs the registry marks as primary when a bank code
  maps to several equally generic BICs, before falling back to the alphabetical tie-break.
  For the French bank code 18719 this is the head office ``BFCORERXXXX`` rather than the
  Mayotte branch ``BFCOYTYTXXX``, which is no longer flagged primary. The German bank code
  48020151 now resolves to ``HAUKDEFFXXX``, the entry the Bundesbank file marks as the bank
  code's primary record, instead of the secondary ``LAMPDEDDXXX``.
* Updated the Slovenian bank registry, which could no longer be generated because Banka
  Slovenije moved its list of payment service provider identifiers. Bank codes added since
  the last update (e.g. ``02188``, NLB) now resolve, names keep their Slovenian characters,
  and the retired codes of SKB banka and Abanka are kept as aliases of OTP banka so IBANs
  still in circulation continue to resolve.
* Deep-copying an IBAN or BIC created with ``allow_invalid=True`` no longer raises a
  validation error. The copy preserves the original value and validation status.
* ``BBAN.validate_national_checksum`` no longer raises an ``AssertionError`` (or an
  ``IndexError`` under ``python -O``) for a BBAN shorter than the country spec; it now
  raises ``InvalidAccountCode``, as the other national methods already do.
* The German checksum methods that inspect the account code themselves (08, 63, 68, 76, 88 and 99)
  now also raise ``InvalidAccountCode`` for a BBAN that is too short to carry an account code,
  instead of leaking a raw ``ValueError`` or ``IndexError`` that ``except SchwiftyException``
  does not catch.
* Updated the Swiss bank registry, which could no longer be generated since SIX started
  emitting bank master records without a BIC. Retired IIDs of merged institutes (e.g. the
  former Credit Suisse codes, now UBS) are now kept as aliases of their successor, so IBANs
  still in circulation keep resolving.
* ``IBAN.generate`` and ``BBAN.random`` now work for countries whose BBAN specification has no
  component positions (e.g. aspirational countries like Comoros or Burkina Faso), via the new
  ``IBANSpec.has_positions`` check.

`2026.07.3`_ - 2026/07/23
-------------------------
Changed

BBAN.random now constructs a valid national checksum instead of repeatedly
generating random BBANs until one happens to validate. Each checksum algorithm can now
solve the components it is responsible for: the German methods splice a valid check
digit into the account code, Iceland fixes its embedded check digit, and the Czech and
Slovak methods adjust the account and branch codes to satisfy their mod-11 constraints.
As a result random BBANs are produced on the first attempt for effectively every
country and bank, rather than after up to 2000 brute-force retries.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [schwifty](https://github.com/mdomke/schwifty) ([changelog](https://github.com/mdomke/schwifty/blob/main/CHANGELOG.rst)) | minor | `==2026.7.3` → `==2026.10.0` | --- ### Release Notes <details> <summary>mdomke/schwifty (schwifty)</summary> ### [`v2026.10.0`](https://github.com/mdomke/schwifty/blob/HEAD/CHANGELOG.rst#2026100---20261019) [Compare Source](https://github.com/mdomke/schwifty/compare/2026.07.3...2026.10.0) Added ``` * Added the German checksum method ``95``, used by UniCredit Bank - HypoVereinsbank (bank code ``70020270``). It computes like method ``06``, but treats the account ranges the Bundesbank exempts from the check digit as valid. Account codes for this bank were not checked before. * Added the German checksum methods ``A2`` and ``A3``. Both check the account number with method ``00`` first and fall back to method ``04`` (``A2``) or ``10`` (``A3``). Banks using them (e.g. Nassauische Sparkasse, Sparkasse Hannover) previously had their national check digit silently accepted without being verified. * Added e-money institutions and banks that were missing from the bank registries: OpenPayd (MT — first Maltese registry), ClearBank and Bilderlings Pay (GB), Score and Secure Payment and Deblock (FR), bunq, Pecunia Cards and Financière des Paiements Électroniques (ES), Unlimit (CY), MyFin (BG), Revolut Bank (PT), Enpara Bank (TR), United Bank and Allied Bank (PK — first Pakistani registry), and the BIC for PrivatBank (UA). Changed ``` - `validate_bban=True` now emits a `NationalChecksumNotVerified` warning when the country's BBAN specification declares national check digits but no algorithm is registered to verify them (35 of the 54 countries that declare check digits, e.g. `HU` and `SE`, which silently passed before, [#310](https://github.com/mdomke/schwifty/issues/310)). The digits are still accepted, since a missing algorithm must not reject an otherwise valid IBAN, but the pass is no longer silent. Turn the warning into an error with `warnings.simplefilter("error", NationalChecksumNotVerified)` to make the missing check fail instead. - Removed support for deprecated Python version 3.10 - Use Python 3.15 by default and in CI, with compatible Pydantic dependencies. - Registry generation scripts now use `httpx2` instead of `requests` for HTTP downloads. - Simplified internal registry caching, character lookups, checksum helpers, and validation routines for improved efficiency and cleaner code structure while preserving exact behavior. - Simplified the IBAN checksum validation. The redundant `self.numeric % 97 == 1` test has been dropped in favour of the stricter canonical `ISO7064_mod97_10` comparison, which it always implied. Behaviour is unchanged. - Updated the bank registries for Germany, Austria, Belgium and Poland. Fixed ``` * Registry update scripts report a missing download link instead of an attribute or lookup error. * Validating a pydantic model whose ``BIC`` field is not a string now reports a ``bic_format`` field error instead of letting the ``TypeError`` from ``BIC()`` escape, which is what the ``IBAN`` validator in the same library already does. * The German checksum method ``63`` (used by Deutsche Bank) now accepts account numbers whose sub-account number ``00`` was left out and that were padded with leading zeros instead, so the check digit sits at position 10 (e.g. ``0001234566``), as the Bundesbank specification requires. * ``IBAN.from_bban`` now normalizes whitespace and case before computing the checksum, matching the text constructors. Grouped BBANs and lowercase country codes no longer raise a raw ``KeyError`` during checksum calculation. * The German checksum method ``99`` now accepts every account number from ``0396000000`` to ``0499999999`` without a check, as the Bundesbank specification requires. Previously only the two range boundaries were exempt, so valid account numbers in between (e.g. at UniCredit Bank - HypoVereinsbank) could be rejected. * Added the Cypriot BIC ``OROACY2LXXX`` (ORO PAY LTD) to the manual registry (#297). * Eight-character BICs now fall back to their equivalent ``XXX`` registry entry for bank codes and names when an exact entry is absent. Exact matches still take priority. * Eleven-character BICs now fall back to the eight-character institution entry when the registry holds no branch-specific record. An 11-character BIC denotes a branch of the institution its first eight characters identify, but not every national registry lists entries per branch (#112). * ``IBAN.bank`` (and with it ``IBAN.bank_name`` and ``IBAN.bank_short_name``) now resolve a bank code to the registry record flagged ``primary`` instead of whichever record happened to be read first. National registries list one record per branch, so the two could name a different institution than ``IBAN.bic`` does. * ``BIC.from_bank_code`` now prefers BICs the registry marks as primary when a bank code maps to several equally generic BICs, before falling back to the alphabetical tie-break. For the French bank code 18719 this is the head office ``BFCORERXXXX`` rather than the Mayotte branch ``BFCOYTYTXXX``, which is no longer flagged primary. The German bank code 48020151 now resolves to ``HAUKDEFFXXX``, the entry the Bundesbank file marks as the bank code's primary record, instead of the secondary ``LAMPDEDDXXX``. * Updated the Slovenian bank registry, which could no longer be generated because Banka Slovenije moved its list of payment service provider identifiers. Bank codes added since the last update (e.g. ``02188``, NLB) now resolve, names keep their Slovenian characters, and the retired codes of SKB banka and Abanka are kept as aliases of OTP banka so IBANs still in circulation continue to resolve. * Deep-copying an IBAN or BIC created with ``allow_invalid=True`` no longer raises a validation error. The copy preserves the original value and validation status. * ``BBAN.validate_national_checksum`` no longer raises an ``AssertionError`` (or an ``IndexError`` under ``python -O``) for a BBAN shorter than the country spec; it now raises ``InvalidAccountCode``, as the other national methods already do. * The German checksum methods that inspect the account code themselves (08, 63, 68, 76, 88 and 99) now also raise ``InvalidAccountCode`` for a BBAN that is too short to carry an account code, instead of leaking a raw ``ValueError`` or ``IndexError`` that ``except SchwiftyException`` does not catch. * Updated the Swiss bank registry, which could no longer be generated since SIX started emitting bank master records without a BIC. Retired IIDs of merged institutes (e.g. the former Credit Suisse codes, now UBS) are now kept as aliases of their successor, so IBANs still in circulation keep resolving. * ``IBAN.generate`` and ``BBAN.random`` now work for countries whose BBAN specification has no component positions (e.g. aspirational countries like Comoros or Burkina Faso), via the new ``IBANSpec.has_positions`` check. `2026.07.3`_ - 2026/07/23 ------------------------- Changed ``` - `BBAN.random` now constructs a valid national checksum instead of repeatedly generating random BBANs until one happens to validate. Each checksum algorithm can now `solve` the components it is responsible for: the German methods splice a valid check digit into the account code, Iceland fixes its embedded check digit, and the Czech and Slovak methods adjust the account and branch codes to satisfy their mod-11 constraints. As a result random BBANs are produced on the first attempt for effectively every country and bank, rather than after up to 2000 brute-force retries. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).

renovate-bot added 1 commit

2026-10-19 17:17:36 +02:00

Update dependency schwifty to v2026.10.0

PyTest / build (pull_request) Successful in 1m40s

Details

562d8ce945