Usługa inicjowania transakcji płatniczej - XS2A PIS, PSD2
•
0 likes•9,090 views
Prezentacja Tomasza Klecora - Partnera kancelarii Legal Geek - o usługach typu PIS czyli Payment Initiation Services. Prezentacja przedstawia czym są usługi XS2A oraz jakie obowiązki ma PISP - dostawca usługi inicjowania transakcji płatniczej wprowadzona przez PSD2
Recommended
More Related Content
Similar to Usługa inicjowania transakcji płatniczej - XS2A PIS, PSD2
Similar to Usługa inicjowania transakcji płatniczej - XS2A PIS, PSD2 (20)
Usługa inicjowania transakcji płatniczej - XS2A PIS, PSD2
- 2. O prelegencie Tomasz Klecor Partner Zarządzający w Legal Geek Tomasz specjalizuje się w regulacji usług płatniczych. Jest miłośnikiem innowacji i motoryzacji, właścicielem własnoręcznie odrestaurowywanego oldtimera. Legal Geek jest nowoczesną firmą prawniczą, której usługi dedykowane są sektorów FinTech, IT oraz e-commerce. Naszą misją jest dostarczanie profesjonalnej obsługi prawnej w sposób przystępny i zrozumiały. Skupiając się na wybranych obszarach prawa zapewniamy naszym Klientom obsługę ekspercką oraz Law-how® niezbędne do prowadzenia działalności w bezpieczny i optymalny sposób. Pracujemy i żyjemy blisko morza – dlatego nasze umysły są szeroko otwarte, a nasze usługi globalne.
- 3. O czym dziś będziemy rozmawiać? 1) Czym w ogóle jest ten PIS? 2) „PIS” przed PSD2 – co było jak PSD2 nie było? 3) Przykłady usług PIS 4) Regulacja PIS w UE 5) Kto to jest PISP i kto może nim zostać? 6) Przebieg transakcji PIS 7) Może i nie może – rola PISP 8) PIS a RODO 9) Czy ASP może utrudniać życie TPP? 10)Podsumowanie
- 4. Usługi typu XS2A – biznesowa istota PSD2 XS2A (access to account – dostęp do rachunku) dla każdego rachunku dostępnego online
- 5. XS2A – Payment Initiation Services (PIS) Payment Initiation Services Czyli PIS
- 6. XS2A – Payment Initiation Services (PIS) TPP (third party provider) może inicjować transakcję płatniczą
- 7. XS2A – Payment Initiation Services (PIS)
- 8. Co było jak PSD2 nie było?
- 9. Co było jak PSD2 nie było?
- 10. Co było jak PSD2 nie było?
- 11. Co było jak PSD2 nie było?
- 12. Co było jak PSD2 nie było?
- 13. Droga do PIS Uregulowanie usługi w ramach regulacji wspólnotowej
- 14. PSD2 == PIS
- 17. Kto to jest PISP? Użytkownik usługi płatniczej (PSU) Podmiot prowadzący rachunek płatniczy, np. bank (ASP) Payment Initiation Service Provider (PISP) - czyli ten, który inicjuje transakcję z rachunku prowadzącego przez innego dostawcę
- 18. PIS – jako usługa w e-bankowości
- 19. PIS – jako „bramka płatnicza”
- 20. Przebieg transakcji PIS – „zwykły przelew”
- 21. Przebieg transakcji PIS – bez akceptanta PISP PŁATNIK ASP bank płatnika ASP odbiorcy
- 22. Przebieg transakcji PIS – bez akceptanta PISP PŁATNIK ASP bank płatnika ASP odbiorcy
- 23. Przebieg transakcji PIS – bez akceptanta PISP PŁATNIK ASP bank płatnika ASP odbiorcy 3B. Transfer środków
- 24. Przebieg transakcji PIS – bez akceptanta PISP PŁATNIK ASP bank płatnika ASP odbiorcy 3B. Transfer środków
- 25. Przebieg transakcji PIS – bez akceptanta PISP PŁATNIK ASP bank płatnika ASP odbiorcy 3B. Transfer środków
- 26. Przebieg transakcji PIS – bez akceptanta PISP PŁATNIK ASP bank płatnika ASP odbiorcy 3B. Transfer środków
- 27. Przebieg transakcji PIS – bramka płatnicza
- 28. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie
- 29. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie
- 30. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie
- 31. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie 4B.Autoryzacjapłatnika
- 32. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie 4B.Autoryzacjapłatnika 5B. Transfer środków
- 33. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie 4B.Autoryzacjapłatnika 5B. Transfer środków
- 34. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie 4B.Autoryzacjapłatnika 5B. Transfer środków 7.Udostępnienie środków
- 35. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie 4B.Autoryzacjapłatnika 5B. Transfer środków 7.Udostępnienie środków
- 36. Przebieg transakcji PIS – w modelu z akceptantem PISP PŁATNIK konsument ASP bank płatnika AKCEPTANT merchant ASP bank merchanta 1. Zakup w e-sklepie 4B.Autoryzacjapłatnika 5B. Transfer środków 7.Udostępnienie środków
- 37. Kto może być PISP? - KIP - Bank - UIP (o ile jest PISP w kraju rejestracji)
- 38. Bank jako TPP – tak!
- 39. Bank jako TPP – tak!
- 40. Kto nie może być PISP? - MIP - BUP
- 41. PIS – bez umowy z ASP ASP nie może wymagać dodatkowej umowy z TPP
- 42. Dostępność! PIS dla KAŻDEGO rachunku dostępnego online
- 43. Taka sama lista rachunków PISP ma dostęp do tych samych rachunków, które widzi użytkownik logując się samodzielnie
- 44. Przebieg transakcji PIS ASP musi udostępnić interfejs dostępowy API, jednak nie ma wymogu stosowania jednego i tego samego API
- 45. Wybór użytkownika To PSU definiuje transakcję, tj. określa: - Odbiorcę - kwotę
- 46. Wybór użytkownika PISP nie może zmieniać kwoty transakcji, odbiorcy, ani żadnych innych danych transakcji
- 47. Zakaz „dotykania” środków PISP nie może wejść w posiadanie środków użytkownika
- 48. Dowolna transakcja Za pomocą PISP mogą być realizowane takie same transakcje jak dostępne bezpośrednio
- 49. Dane uwierzytelniające PISP zapewnia aby indywidualne dane uwierzytelniające nie były dostępne dla podmiotów innych niż użytkownik i dostawca prowadzący rachunek oraz aby były one przekazywane za pośrednictwem bezpiecznych i wydajnych kanałów
- 50. Informacje o użytkowniku PISP zapewni aby informacje o użytkowniku uzyskane w trakcie świadczenia usług inicjowania transakcji płatniczej, były dostarczane tylko odbiorcy i wyłącznie za zgodą użytkownika
- 51. Informacje o użytkowniku PISP nie może przechowywać danych szczególnie chronionych
- 53. Informacje o użytkowniku PISP nie może żądać od użytkownika innych danych niż niezbędne do realizacji transakcji
- 54. Informacje o użytkowniku PISP nie może używać, uzyskiwać ani przechowywać danych do celów innych niż wykonanie usługi inicjowania transakcji płatniczej świadczonej na podstawie umowy z użytkownikiem lub zgody użytkownika
- 55. Informacje o użytkowniku PISP przekazują dostawcom usług płatniczych prowadzącym rachunek te same informacje, których żąda się od użytkownika usług płatniczych, gdy ten bezpośrednio inicjuje transakcję płatniczą
- 56. Identyfikacja i komunikacja PISP jest obowiązany identyfikować siebie wobec dostawcy prowadzącego rachunek i porozumiewać się z dostawcą prowadzącym rachunek, płatnikiem i odbiorcą w sposób bezpieczny, zgodnie z wymogami określonymi w RTS
- 57. Identyfikacja i komunikacja Uwierzytelnienie może być dokonane przy użyciu certyfikatu kwalifikowanego (eIDAS), przy czym certyfikat musi zawierać dodatkowe atrybuty: 1) Rolę dostawcy usług, np. ASP, AISP, PISP; 2) Nazwę właściwego organu nadzoru
- 58. Czy ASP może utrudnić życie PIS? ASP nie może dyskryminować i rozróżniać sytuacji TPP względem zleceń składanych bezpośrednio – chyba, że jest to obiektywnie uzasadnione koniecznością spełnienia wymogów z RTS
- 59. Zakaz dyskryminacji ASP nie może utrudniać – np. nie może uniemożliwiać wykorzystania danych uwierzytelniających wydanych klientowi ASP, w celu korzystania ze zwykłych usług
- 60. Zakaz dyskryminacji ASP musi umożliwić TPP zrobienie tego co może zrobić użytkownik, np. nie może ograniczyć transakcji PIS tylko do przelewów zwykłych (blokując ekspresowe) czy ograniczyć pobieranie historii rachunków tylko do rachunków w PLN (chyba, że ograniczenia wynikają z przepisów).
- 61. Podsumowanie
- 62. Legal Geek LegalGeek.pl tomasz@legalgeek.pl +48 797 711 924 Linkedin.com/in/tomaszklecor/