[mo22]

When a response message contains both a generic 9xxx error for a dialog that is not open yet (such as 9050) and a later 9075, the generic PIN/auth handling runs first. It blocks the PIN and raises FinTSClientPINError before the explicit strong-customer-authentication response is inspected, so callers report a wrong PIN where the bank asked for SCA.

This change pre-scans the HIRMG/HIRMS response set while processing a message and lets the explicit 9075 handling take precedence over the generic handling for unopened dialogs. Explicit PIN-related return codes still block the PIN as before.

Tested with:

uv run --with pytest pytest tests/test_client.py::test_sca_required_takes_precedence_over_unopened_dialog_error
uv run --with pytest pytest tests/test_client.py

[raphaelm]

How do you end up with these weird linebreaks in your GitHub PR description, did you write the PRs yourself or are they AI-generated?

[mo22]

Fair question, and sorry for the mess. The patch and the PR text were AI-generated (Claude Opus, with a review pass by a second model), and I checked the change before filing. The "\n" sequences are literal escapes from the way the agent passed the description to gh, not line breaks. I've replaced the description with a cleaned-up version and fixed the same problem in #215.

The bug itself is real: when a dialog that is not open yet gets a generic 9xxx (for example 9050) and a 9075 in the same message, the first code blocks the PIN and raises FinTSClientPINError. The caller is told the PIN is wrong, when the bank actually asked for strong customer authentication. I've been running the same pre-scan as a local subclass since May. Happy to change the approach if you'd prefer it done differently, or to close the PR if you don't want this in the library.

If it's easier to talk it through, you can reach me at mm@mxs.de, and I'm happy to do a voice or video call (Google Meet) during the day, CET.