Repository navigation
tatra banka: analyse its notification e-mails and collect samples #24
Description
Tatra banka, 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 guide, read 2026-11-10, not checked in the bank itself:
- NASTAVENIA → B-mail → VYTVORIŤ NOVÝ; Email, tick Vklad and Výber with an amount. Slovak, EUR, IBAN, Europe/Bratislava; see #10.
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.
- 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.
- 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).
- 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.
- Accounts: personal and business, CZK and every other currency the bank keeps, a savings account if it notifies.
- 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 (nol=). The key's fingerprint gets pinned and added toKeyCheckLiveTest. - DNSSEC.
tatrabanka.sk: DS 2371, algorithm 13, checked 2026-11-10 through 1.1.1.1; DMARC p=reject. Signed, sowithDns()can validate the key, provided the e-mail is signed under this domain. - 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.
Activity
landsman commentedon Nov 10, 2026
Public samples (checked 2026-11-10), MIT: tomaj/bank-mails-parser has 25 Tatra banka fixtures (
tatrabanka,tatrabanka-cardpay,tatrabanka-statement, the last PGP-encrypted), and remp2020/crm-payments-module rawtatrabanka.eml,tatrabanka_simple.eml,tatrabanka_statement.eml. tomaj documents two B-mail formats and notes that Tatra takes the last number of the payer's message as the VS whenReferencia platitelais absent: exactly the free-text source this library refuses.landsman commentedon Nov 10, 2026
Signing, from the raw samples in remp2020/crm-payments-module/docs (December 2019, domains anonymised to example.com, selectors kept):
s=mta,c=simple/simple, senderb-mail@….That selector is still published (checked 2026-11-10):
mta._domainkey.tatrabanka.sk, RSA 2048, DNSSEC-secure (AD flag, zone signed with algorithm 13), fingerprintsOUiSq9+xyeXpczY9SzI+HLjzU4jZyfQUXGvxjtXmVc=, the same through 1.1.1.1 and 8.8.8.8. Likely the key to pin, but only a current real e-mail shows whether Tatra still signs with it (d=ands=).c=simple/simplemeans the body is hashed byte for byte, without relaxed whitespace: any re-wrap on the way breaks the signature, so the raw message matters even more than with Air Bank or Fio.landsman commentedon Nov 10, 2026
A parser from the public samples is in #48, no key pinned. A real e-mail would settle: that Tatra still signs with
mta(then pinsOUiSq9+xyeXpczY9SzI+HLjzU4jZyfQUXGvxjtXmVc=), the subject of a debit (Debet na ucteis assumed), and whether the variable symbol in the payer's reference is ever longer than ten digits.