čsob sk: analyse its notification e-mails and collect samples #22

ČSOB in Slovakia, listed by Fakturoid as matched from its notification e-mails (overview, read 2026-11-10). Not read by this library yet.

What is known

From Fakturoid's overview, no bank guide, read 2026-11-10, not checked in the bank itself:

• Listed as supported for Slovak accounts, without a guide. Slovak, EUR, IBAN, Europe/Bratislava; see #10 for what a Slovak template changes.

What to collect

Raw .eml files, exported as the original message, never forwarded, from a real account. As many kinds as the bank can send, because every kind not seen is a template the parser does not know. Record each one in a samples table like fio-cz.md, with ❔ for what is still missing.

1. The settings form. Screenshots or a transcript of every notification setting the bank offers: channels (e-mail, SMS, push), formats and their previews, languages, directions, thresholds, balance alerts. The form decides the shape of every e-mail that follows.
2. Movements, one e-mail each: incoming from another bank, instant incoming, within the bank, outgoing, card payment (domestic and abroad), card refund, direct debit, standing order, ATM withdrawal, cash deposit, fee or interest, foreign payment (SEPA, SWIFT).
3. Fields: variable, constant and specific symbol, a message (with diacritics, and a long one), the counter-party's name and account, an amount of 1 000 and more, the balance.
4. Accounts: personal and business, CZK and every other currency the bank keeps, a savings account if it notifies.
5. Every format the form offers, including the ones that will be refused, so the library recognises them and says why.

What to check in the samples

• The signing domain, selector and key: d=, s=, RSA size, and that the whole body is signed (no l=). The key's fingerprint gets pinned and added to KeyCheckLiveTest.
• DNSSEC. csob.sk: DS none, the zone is not signed, checked 2026-11-10 through 1.1.1.1; DMARC p=reject. Not signed: if the e-mails are signed under this domain, withDns() refuses every one of them, and trusting this bank needs another answer (a pinned key without DNSSEC, say). Decide that before writing the parser.
• A transaction id to deduplicate on. A template without one is refused, as Fio's short format is.
• The direction stated twice (subject and body, or two lines), so the two can be required to agree.
• The receiving account in the body, so account() can be compared with the merchant's.

Then

.docs/<bank>.md with the samples table, a parser beside AirBank and FioCz, anonymised fixtures (development), and a setup section in setup.md.