pain.001.001.09:čo sa mení oproti verzii .03 a odkedy

Účtovný softvér alebo internet banking niekde spomenul „pain.001.001.09" a ty si zatiaľ posielal hromadné príkazy vo verzii .03. Otázka znie, čo sa medzi verziami mení, či to musíš riešiť teraz, a čo má naozaj spoločné s termínom 15. novembra 2026, o ktorom sa hovorí v súvislosti so štruktúrovanou adresou. Nižšie sú konkrétne rozdiely v XML, presne to, čo termín 15. 11. 2026 vyžaduje, a čo sme k dnešnému dňu vedeli a čo nevedeli overiť pre slovenské banky.

1. Čo sa v XML medzi .03 a .09 mení

Obe verzie sú v skratke pain.001.001, teda „Customer Credit Transfer Initiation" podľa ISO 20022. Číslo za druhou bodkou je verzia schémy. Zmien je viac, tieto štyri sa v hromadnom príkaze na úhradu prejavia najčastejšie.

Menný priestor (xmlns)

Koreňový element <Document> má v každej verzii iný menný priestor. Banka podľa neho pozná, akú štruktúru správy má očakávať.

.03  xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"
.09  xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09"

BIC banky sa volá BICFI

Kód banky platiteľa alebo príjemcu sa v .03 zapisuje do elementu <BIC>. V .09 sa ten istý údaj zapisuje do <BICFI>. Hodnota aj formát BIC kódu sú rovnaké, mení sa len názov elementu.

.03  <FinInstnId><BIC>TATRSKBX</BIC></FinInstnId>
.09  <FinInstnId><BICFI>TATRSKBX</BICFI></FinInstnId>

Dátum splatnosti je zabalený inak

V .03 je ReqdExctnDt obyčajný textový dátum. V .09 je to typ DateAndDateTime2Choice, teda samotná hodnota musí byť ešte raz zabalená v <Dt>, prípadne v <DtTm>, ak banka vyžaduje aj presný čas.

.03  <ReqdExctnDt>2026-11-20</ReqdExctnDt>
.09  <ReqdExctnDt><Dt>2026-11-20</Dt></ReqdExctnDt>

Adresa: PostalAddress6 verzus PostalAddress24

Adresa platiteľa aj príjemcu je v .03 typu PostalAddress6, v .09 typu PostalAddress24. Poradie hlavných polí (StrtNm, BldgNb, PstCd, TwnNm, Ctry) je v oboch rovnaké. PostalAddress24 pridáva len jemnejšie, nepovinné polia navyše (napríklad BldgNm, Flr, Room, TwnLctnNm) a obmedzuje počet riadkov voľného textu AdrLine na dva. Pre bežnú firemnú adresu v hromadnom príkaze v tom teda rozdiel prakticky nie je.

2. Termín 15. novembra 2026 sa týka adresy, nie verzie správy

Tu vzniká najviac zmätku. Termín 15. 11. 2026 pochádza z pravidiel SEPA úhrady (SEPA Credit Transfer rulebook), ktoré vydáva European Payments Council, vo verzii 1.1. Adresa platiteľa ani príjemcu nie je v SEPA úhrade povinná sama o sebe, súbor bez nej prejde aj po termíne. Pravidlo platí len pre súbory, ktoré adresu obsahujú: od 15. 11. 2026 v nich už nesmie byť zapísaná ako čistý voľný text. Musí mať aspoň mesto a dvojpísmenový kód krajiny vo vlastných poliach, buď plne štruktúrovane, alebo v takzvanej hybridnej podobe (dva riadky voľného textu plus mesto a krajina).

O verzii správy pain.001 tento termín nič nehovorí. Štruktúrovanú aj hybridnú adresu vie zapísať aj pain.001.001.03, cez PostalAddress6 popísanú vyššie. Ak teda tvoj účtovný softvér exportuje adresu s mestom a krajinou v samostatných poliach, termín 15. 11. 2026 spĺňaš aj bez toho, aby si menil verziu správy na .09.

Pôvodná verzia pravidiel z roku 2025 (verzia 1.0) uvádzala ako koniec neštruktúrovanej adresy 22. november 2026. Verzia 1.1 to opravila na 15. november 2026, aby to sedelo s termínom celoeurópskej výmeny SWIFT Standards MX. Časť webov o SEPA platbách preto stále cituje starší dátum 22. 11., platný je 15. 11. 2026.

3. Kto naozaj vypína .03, a odkedy

Toto je oddelená otázka od adresy vyššie: ktorú verziu správy tvoja banka na dávkový import prijme, si určuje výhradne banka sama. Tu je to, čo sme vedeli overiť priamo k 6. 9. 2026, a čo nie.

Nemecko. Nemecké sporiteľne (Sparkassen) a družstevné banky v sieti Atruvia (napríklad GLS Bank) verejne oznámili presný dátum, kedy prestanú pain.001.001.03 pri dávkových platbách prijímať: 14. november 2026. Rovnaký dátum sa uvádza aj ako termín celoodvetvovej výmeny SWIFT Standards MX. Je to teda overený príklad banky, ktorá .03 naozaj a k presnému dátumu vypína, len nie na Slovensku.

Komerční banka (ČR). Vlastná stránka Komerční banky k 6. 9. 2026 uvádza zmenu v spôsobe odovzdávania adresných údajov od 20. 6. 2026 a plánovanú verziu klienta MultiCash 5.0 s plnou kompatibilitou s pain.001.001.09. Konkrétny dátum, kedy by banka mala prestať .03 prijímať, sme na tejto stránke nenašli, hoci sa taký dátum v niektorých sekundárnych zhrnutiach na internete objavuje. Toto tvrdenie preto v článku nepoužívame, kým ho nenájdeme priamo v dokumente banky.

Slovensko. Pre Tatra banku, VÚB, Slovenskú sporiteľňu ani ČSOB sme k 6. 9. 2026 nenašli verejne publikovaný dátum prechodu na pain.001.001.09 ani dátum ukončenia príjmu .03. To neznamená, že sa nič nechystá, len že to žiadna z nich zatiaľ takto otvorene nezverejnila. Jediný spôsob, ako si to overiť s istotou, je opýtať sa priamo banky alebo sledovať jej internet banking a technickú dokumentáciu k dávkovým platbám.

Checklist

1. Termín 15. 11. 2026 rieš cez adresu, nie cez verziu správy: ak súbor PstlAdr platiteľa alebo príjemcu obsahuje, over, či má vyplnené aspoň TwnNm a Ctry vo vlastných poliach. Súbor bez adresy vôbec termín nerieši, adresa je nepovinná.
2. Ak tvoj súbor už dnes posiela adresu takto štruktúrovane, termín splníš aj v pain.001.001.03. Prechod na .09 nie je podmienkou.
3. Ak ti účtovný softvér alebo banka ponúkne export vo verzii .09, over v ňom tri veci: xmlns koreňového elementu, že kód banky je v <BICFI> nie v <BIC>, a že ReqdExctnDt obsahuje vnorený <Dt> alebo <DtTm>.
4. Neprepínaj verziu naslepo len preto, že si niekde čítal o termíne 15. 11. 2026. Zisti si u svojej banky, ktorú verziu pri dávkovom importe skutočne očakáva, ideálne priamo v jej internet bankingu alebo u technickej podpory.
5. Ak banka .03 zatiaľ prijíma aj po novembri 2026, nechaj si to písomne potvrdené alebo si to over opakovane. Táto oblasť sa v priebehu roka 2026 ešte mení.

Časté otázky

Overiť na vlastnom súbore

Kto si to chce overiť na vlastnom súbore, môže si XML nahrať do SEPA pain.001 Doctor, ktorý rozpozná verziu súboru a upozorní, ak adresa nemá vyplnené mesto alebo krajinu.