SEPA SAF Fórum Proje k t SEPA Slov ensko Problémy 3 . 11 .2010 Andrej Révay, prezident SAF

1. SEPA SAF Fórum Projekt SEPA Slovensko Problémy 3.11.2010 Andrej Révay, prezident SAF Ivan Hečko, projektový manažér SEPA SR

2. Agenda: Detaily produktov a problémy • Technický detail medzinárodného clearingu • Produkt SCT • Produkt SDD • EK Regulation a otvorené problémy • ZOPS

3. TARGET 2 – debetuje sa Banka 1 a kredituje sa PM účet TARGET 2 – debetuje sa PM účet a kredituje sa Banka 2 prostriedky prostriedky PM účet v TARGET 2 Cyklus I: platba Cyklus II: príjem platby platobné správy platobné správy platobné správy Banka 2 príjemca Banka 1 platiteľ CSM 1 CSM 2 Vízia cieľového stavu – EACHA schéma (EACHA: European Automated Clearing Houses Association) Obrázok prevzatý z dokumentu EACHA: Transakcia SCT platby cez dva ACH

4. Vízia cieľového stavu – EACHA schéma EACHA Koncepcia: platby prechádzajúce medzi dvomi CSM idú cez dva cykly clearingu a zúčtovania, jeden cyklus v CSM1 a jeden v CSM2. Pre zúčtovanie využije účty TARGET2 [T2] Payment Module [PM] a vždy sa odohrá v TARGET2 – použijú sa zúčtovacie možnosti Ancillary System Interface, teda Cyklus I: iniciovaný CSM1, prostriedky sa debetujú z účtov vysielajúcich poskytovateľov platobných služieb a pripíšu sa na T2 PMúčet. Po úspešnej realizácii zúčtovania sa pošlú platobné správy z CSM1 do CSM2. Cyklus II: iniciovaný CSM2, prostriedky sa debetujú z T2 PM účtu a pošlú sa poskytovateľom platobných služieb príjemcov pripojených k CSM2. Po úspešnej realizácii zúčtovania CSM2 pošle platobné správy poskytovateľom platobných služieb príjemcov. Táto koncepcia znamená, že v čase medzi prvým a druhým cyklom zúčtovania prostriedky prešli spod kontroly poskytovateľov platobných služieb pripojených k CSM1 a sú uložené na účte TARGET2 PM. Zámerom je, aby prostriedky boli držané na tomto účte len v rámci dňa. Nenulové stavy „overnight“ sa nepredpokladajú.

5. Stav projektu – produkty – SCTSchéma SCT – SEPA Credit Transfer, t.j. platba. Schéma: štandardná, zhodná s našou – banka platiteľa posiela platbu do clearingu, správa o platbe príde do banky príjemcu, vyvolá sa vysporiadanie platby cez TARGET2. Znamená to, že v prípade produktu SCT z funkčného hľadiska SK platobný a clearingový systém EURO SIPS, ako systém pridružený TARGET2, je v plnom súlade s cieľovým stavom SEPA.

6. Stav projektu – produkty – SCTAdditional Optional Services - AOS SCT – SEPA Credit Transfer, t.j. platba. AOS: V rámci SCT bolo nutné zaujať stanovisko k našej platobnej informácii, ktorú predstavujú 3 platobné symboly (remittance information). V rámci projektu boli platobné symboly zachované, stále nie je jasný definitívny spôsob ich prenosu. Predbežne v poli End-to-end Identification ako v správach SWIFT. Požiadavka je registrovaná v EPC, nepredstavuje však AOS, treba len nájsť spôsob informovania zahraničných bánk o umiestnení a spôsobe zápisu symbolov.

7. Stav projektu – produkty – SDDSchéma SCT – SEPA Direct Debit, t.j. inkaso. Schéma SK: banka príiemcu posiela neúčtovnú položku výzvu na inkaso do clearingu, výzva príde do banky príjemcu, kontroluje sa súhlas s inkasom na účte dlžníka, ak existuje a je v súlade, vysiela sa platba príjemcovi. Zúčtovanie platby cez TARGET2. Schéma SEPA: Banka príjemcu vysiela účtovnú položku Inkaso do clearingu, Inkaso príde do banky dlžníka. Ak do dátumu splatnosti inkasa nie je inkaso zamietnuté (banka dlžníka alebo dlžník), inkaso sa priamo zúčtuje (TARGET2 – vyvolá platobný systém).

8. Stav projektu – produkty – SDDSchéma a rozdiely Znamená to, že v prípade produktu SDD je jediná zložka schémy v zhode so SEPA schémou a tou je zúčtovanie cez TARGET2. Rozdiely: SDD je debetná schéma, ktorú nemáme v platobnom systéme SDD nepredpokladá že inkaso vyžaduje súhlas dlžníka – mandát na inkaso sa dáva príjemcovi (CMF) Na základe toho má dlžník právo na refund – vrátenie inkasa – okrem zvláštnych prípadov popísaných v ZOPS – to ale predpokladá, že si minimálne mesačne sleduje pohyby na účte

9. Stav projektu – produkty – SDDSchéma a rozdiely - CID Právo na refund, t.j. na vrátenie inkasovaných prostriedkov, ako aj registrácia Kreditorov v registri CID predstavuje „vylepšenie“ SEPA inkasa v očiach verejnosti z hľadiska bezpečnosti. Napriek tomu je táto forma inkasa stále kritizovaná zo strany BEUC, ktorá pravdepodobne dostane do novej Regulation prinajmenšom odporúčanie o zavedení ochrany účtov v zmysle našej ochrany. ►► Refund v praxi znamená, že ak dlžník požiada o vrátenie, jeho banka mu je povinná inkasované prostriedky vrátiť a jej zase je povinná ich vrátiť banka Kreditora. Až potom nastáva „reklamačné konanie“. Nositeľom rizika je teda banka Kreditora a z toho vychádza naša koncepcia správy a prideľovania CID cez banku Kreditora.

10. Stav projektu – produkty – SDDZmena – AOS pre SDD SK inkaso je založené na princípe DMF – debtor mandate flow – SDD na CMF – creditor mandate flow. SR teda v rámci prechodu na SDD rieši dva základné problémy: • Úprava produktu tak, aby vyhovoval klientom • Prenos zmlúv k DMF inkasu do prostredia CMF inkasa bez opätovného podpisovania – problém na úrovni EÚ • (Plus minimalizácia nákladov na úpravy informačných systémov) Riešenie: Zavádzajú sa tri stupne ochrany účtu: • Účet bez ochrany – možno inkasovať bez mandátu banke klienta • Účet s podmienenou ochranou – možno z neho inkasovať len ak je mandát na účte klienta • Z účtu nie je možné inkasovať

11. Stav projektu – produkty – SDDSK prechod na SEPA inkaso • Transformácia DMF na CMF DD: - Transformáciainkasnýchúčtov a transformáciazmlúv: • Inkasnéúčtyboli založené za predchádzajúcichlegislatívnych podmienok – ochranaúčtovprotiinkasubez autorizácie danej banke dlžníkabola ich súčasťou. Preto: • automatickákonverziatýchtoúčtovna účty s ochranou úrovne 2 • transformáciazmlúvdo prostredia CMF

12. Stav projektu – produkty – SDDSK prechod DMF na CMF Platiteľ - dlžník Zmluva o službách Inkasná firma – Príjemca (veriteľ) Obch. podmienky, Produkt, zmluva Obch. podmienky, Produkt, zmluva Mandát inkasa Tri typy ochrany účtov Banka príjemcu (veriteľa) Banka platiteľa (dlžníka) ACH Používajú služby

13. Globálne problémy s migráciou (1) Integrácia platobného priestoru Do konca roku 2009 nebola jasná koncepcia interoperability jednotlivých clearingov, resp. iného spôsobu prepojenia, napr. prostredníctvom STEP2 ako clearingu národných clearingov. Znamená to, že do toho času sa SEPA projekty riešili ako lokálne projekty SEPA (čo je v podstate nezmysel, vzhľadom na účel projektu). Nakoniec prevládla koncepcia EACHA popísaná v uvedenom dokumente(?). (2) Prechod na produkt SEPA inkaso – SDD Niektoré štáty po legislatívnej analýze oznámili, že ich inkaso nie je kompatibilné s SDD a všetky existujúce zmluvy o inkase je nevyhnutné znova podpisovať. To je napr. v Nemecku, kde je v priemere na domácnosť viac ako 16 zmlúv o inkase, nepoužiteľný postup. ČR ohlásila potrebu zmeny ústavy. U nás predbežná analýza (MF, NBS) oznámila predbežný uzáver – ak nebude v novej Regulation EK článok ktorý by zmenil súčasný stav, je to možné ošetriť VOP.

14. Globálne problémy s migráciou (3) Integrácia platobného priestoru(2) Projekt SEPA sa predbežne sústredil na zjednotenie platobného priestoru. Rovnocennou zložkou tohto priestoru sú však aj výpisy z účtov, ktoré sú v podnikových systémoch spracovávané automaticky. Aj keď teda bude klient (podnik) schopný posielať do všetkých bánk rovnaké príkazy v XML podľa ISO 20022, bude rovnako potrebovať spracúvať zo všetkých týchto bánk rovnaké (XML) výpisy. SR: Za spolupráce SBA, ČBA a českej firmy Management Data (dodávateľ MultiCash), sa vytvára team na definovanie XML výpisov. Koordinuje sa s Rakúskom, ktoré je aj súčasťou podobného združenia nemecky hovoriacich krajín DACH (označenia Nemecko, Rakúsko, Švajčiarsko). Práce prebiehajú za podmienky, že výsledok nebude vlastníctvom Management Data, ale všeobecne odporúčaná a použiteľná štruktúra.

15. EK má pocit, že Projekt napreduje pomaly. Pritom používa kritérium % SEPA platieb / inkás. Neberie do úvahy ani bod (1) predošlého dvoj-slide, ktorého riešenie asi bolo v jej kompetencii. SEPA schémy a produktydefinované EPC vníma ako „monopol EPC“ a hodlá uvoľniť pole pre „ďalšie schémy, pričom všetky budú interoperabilné“. EPC a banky považujú schémy a datasety za technický podklad nevyhnutný pre interoperabilitu. EK Regulation proposal

16. EK Regulation proposal Náš názor (nám známe stanoviská bánk, resp. prevádzkovateľov clearingov): projekt dospel do stavu, kedy máme definovaný (technicky, doteraz len slovne) cieľový stav projektu - • schémy pre kreditnú transakciu (SCT) a debetnú transakciu (SDD) • datasety pre všetky typy transakcií v rámci uvedených produktov • schému interoperability clearingov

17. EK Regulation proposal EK Regulation, ktorá pripustí existenciu viacerých schém, bez definovania spôsobu zabezpečenia ich vzájomnej interoperability považujeme za ohrozenie projektu.

18. Stav projektu – produkty – SDDproblémy SDD • Právo na „refund with no questions asked“ • Cash flow v súvislosti s refundom inkasa • DPH v súvislosti s refundom inkasa • Prechod na SEPA inkaso (technický a účtovný) • Prechod na SEPA inkasolegislatívny (prenos platných zmlúv bez nového podpisovania, príslušné adekvátne VOP bánk a VOP podnikov, ...

19. ZOPS(1) DRUHÁ ČASŤ PLATOBNÉ SLUŽBY Práva a povinnosti pri poskytovaní a používaní platobných služieb § 3 (1) Poskytovateľ platobných služieb vykonáva platobné operácie na základe jednoznačného pokynu používateľa platobných služieb, ktorým je platobný príkaz v listinnej forme alebo elektronickej forme na vykonanie platobnej operácie. (2) Poskytovateľ platobných služieb odpíše finančné prostriedky z platobného účtu aj bez predloženia platobného príkazu a) pri výkone rozhodnutia alebo pri plnení inej povinnosti uloženej osobitným zákonom alebo na základe osobitného zákona,15) b) na úhradu všetkých cien a skutočných výdavkov za poskytnuté služby, na úhradu splatných debetných úrokov alebo v ďalších prípadoch, v ktorých je na to poskytovateľ platobných služieb oprávnený podľa rámcovej zmluvy alebo c) v prípadoch písomne dohodnutých medzi poskytovateľom platobných služieb a používateľom platobných služieb.

20. ZOPS(2) § 6 (3) Ak ide o inkaso, pri ktorom platiteľ a) udelil svoj súhlas s vykonaním platobnej operácie priamo svojmu poskytovateľovi platobných služieb, môže platiteľ odvolať takýto platobný príkaz a tým zároveň aj udelený súhlas najneskôr do konca pracovného dňa predchádzajúcemu dohodnutému dňu, keď majú byť finančné prostriedky odpísané z účtu, pričom nie je dotknuté právo na vrátenie finančných prostriedkov, ak nebolo podľa § 13 dohodnuté v rámcovej zmluve inak, alebo b) udelil svoj súhlas s vykonaním platobnej operácie priamo príjemcovi, môže platiteľ odvolať platobný príkaz na jednotlivú platobnú operáciu vykonávanú na základe takéhoto súhlasu najneskôr do konca pracovného dňa predchádzajúcemu dohodnutému dňu, keď majú byť finančné prostriedky odpísané z účtu, pričom nie je dotknuté právo na vrátenie finančných prostriedkov podľa § 13.

21. § 8 (1) Ak platiteľ udelil súhlas na vykonanie platobnej operácie, platobná operácia sa považuje za autorizovanú. Platiteľ môže autorizovať platobnú operáciu pred jej vykonaním alebo, ak sa na tom platiteľ a jeho poskytovateľ platobných služieb dohodnú, po vykonaní platobnej operácie. (2) Súhlas na vykonanie platobnej operácie alebo viacerých platobných operácií sa udeľuje vo forme dohodnutej v zmluve o poskytnutí jednorazovej platobnej služby alebo v rámcovej zmluve medzi platiteľom a jeho poskytovateľom platobných služieb. Ak takýto súhlas chýba, platobná operácia sa považuje za neautorizovanú. (3) Súhlas na vykonanie platobnej operácie môže platiteľ odvolať, najneskôr do okamihu, keď sa platobná operácia stáva neodvolateľnou podľa § 6. Súhlas na vykonanie opakujúcich sa viacerých platobných operácií možno odvolať, pričom od okamihu odvolania je nasledujúca platobná operácia považovaná za neautorizovanú. (4) Postup udelenia súhlasu na vykonanie platobnej operácie sa dohodne v zmluve o poskytnutí jednorazovej platobnej služby alebo v rámcovej zmluve medzi platiteľom a jeho poskytovateľom platobných služieb. ZOPS(3)

22. § 13 (1) (1) Platiteľ má nárok na vrátenie finančných prostriedkov od svojho poskytovateľa platobných služieb pri autorizovanej platobnej operácii vykonanej na základe platobného príkazu predloženého príjemcom alebo prostredníctvom príjemcu, ak a) v čase autorizácie nebola určená konkrétna suma platobnej operácie a b) suma platobnej operácie presahuje sumu, ktorú by mohol platiteľ odôvodnene očakávať vzhľadom na jeho zvyčajné predchádzajúce výdavky, podmienky uvedené v rámcovej zmluve a okolnosti súvisiace s platobnou operáciou. (2) Na žiadosť poskytovateľa platobných služieb poskytne platiteľ informácie o vykonanej platobnej operácii podľa odseku 1 v lehote podľa § 14 ods. 2; vrátenie finančných prostriedkov sa týka celej sumy vykonanej platobnej operácie vrátane súvisiacich poplatkov. (3) Ak ide o inkaso, v rámcovej zmluve možno dohodnúť, že platiteľ má nárok na vrátenie finančných prostriedkov od svojho poskytovateľa platobných služieb, aj keď nie sú splnené podmienky na vrátenie finančných prostriedkov podľa odseku 1 okrem inkasa podľa odseku 5. ZOPS(4)

23. § 13 (2) (5) V rámcovej zmluve možno dohodnúť, že platiteľ nemá nárok na vrátenie finančných prostriedkov podľa odseku 1, ak a) udelil svoj súhlas s vykonaním platobnej operácie priamo svojmu poskytovateľovi platobných služieb a b) informácie o konkrétnej sume budúcej platobnej operácie sa platiteľovi poskytli alebo sprístupnili dohodnutým spôsobom najmenej štyri týždne pred dátumom odpísania sumy platobnej operácie zo strany poskytovateľa platobných služieb alebo príjemcu, ak to bolo možné. ZOPS(5)

24. Ďakujeme za pozornosť Koniec