MMC: Standardy RTS w bankowości elektronicznej - najnowsze aspekty prawne

Transkrypt

1 Zapraszamy do zapoznania się z fragmentem prezentacji W razie zainteresowania jej pełną treścią, zapraszamy do kontaktu MMC: Standardy RTS w bankowości elektronicznej - najnowsze aspekty prawne Wpływ transpozycji PSD II na polskie regulacje dotyczące bezpieczeństwa płatności Warszawa dr Krzysztof Korus partner, radca prawny, ekonomista krzysztof.korus@dlklegal.com Warszawa Kraków

2 compliance dziś narzędzia realnego wzrotu bezpieczeństwa ochrona użytkownika TPP Agenda

3 Draft Regulatory Technical Standards specifying the requirements on strong customer authentication and common and secure communication under PSD2 This Regulation shall be binding in its entirety and directly applicable in all Member States. RTS

4 compliance SCA gdy: + SCA and STA SCA uzyskuje dostęp do swojego rachunku płatniczego w trybie online; inicjuje elektroniczną transakcję płatniczą; elektroniczne zdalne elementy, które dynamicznie łączą transakcję z określoną kwotą i określonym odbiorcą kanał zdalny ryzyko oszustwa / nadużyć realne ograniczenie fraudów czy trx?

5 kiedy ja jak się prowadzam wiem mam logowanie! płatność (kwota/odbiorca) riskies fraud przy braku SCA: PSD1 koszt operacyjny PSD2 non-compliance x silne uwierzytelnienie rekomendacja EBA, KNF: comply or explain

6 ART. 4 (30) PSD2 silne uwierzytelnianie klienta oznacza uwierzytelnianie w oparciu o zastosowanie co najmniej dwóch elementów należących do kategorii: 1. wiedza (coś, co wie wyłącznie użytkownik), 2. posiadanie (coś, co posiada wyłącznie użytkownik) i 3. cechy klienta (coś, czym jest użytkownik), niezależnych w tym sensie, że naruszenie jednego z nich nie osłabia wiarygodności pozostałych, które to uwierzytelnianie jest zaprojektowane w sposób zapewniający ochronę poufności danych uwierzytelniających SCA

7 Article 1 Authentication procedure and authentication code 1. ( ) the authentication procedure shall result in the generation of an authentication code that is accepted only once by the payment services provider each time that the payer, making use of the authentication code accesses its payment account online, initiates an electronic transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses. 2. The authentication code shall be characterized by security features including, but not limited to, algorithm specifications, length, information entropy and expiration time, ensuring that: (a) no information on any of the elements of strong customer authentication categorized as knowledge, possession and inherence can be derived from the disclosure of the authentication code; (b) it is not possible to generate a new authentication code based on the knowledge of another authentication code generated for the same payer; (c) the authentication code cannot be forged. STRONG CUSTOMER AUTHENTICATION Authentication procedure

8 . The strong customer authentication procedure shall include mechanisms to: a) limit the maximum time allowed to the payer to access its payment account online, where the access has been erformed through strong customer authentication ( time out ); b) exclude that any of the elements of strong customer authentication can be identified as incorrect, where the uthentication procedure has failed to generate an authentication code for the purposes of paragraph 1; c) determine the maximum number of failed authentication attempts that can take place consecutively within a given eriod of time and after which the access to an online payment account, the initiation of an electronic payment transaction r the possibility of carrying out any action through a remote channel which may imply a risk of payment fraud or other buse are temporarily or permanently blocked. Where the block is temporary the number of retries and the time period of he block shall be established taking into account the characteristics of the service provided to the payer and all the elevant risks involved. Where the block is permanent, a secured procedure must be established allowing the payer to egain access to and use the blocked electronic payment services; d) protect communication sessions against the capture of data transmitted during the authentication procedure or anipulation by unauthorised parties, including but not limited to by relying where applicable on HTTP over TLS. e) prevent, detect and block fraudulent payment transactions before the PSP s final authorisation. hese mechanisms shall take into account, but not be limited to:. parameterised rules, including black lists of compromised or stolen card data, i. signs of malware infection in the session and known fraud scenarios, ii. an adequate transaction history of the payer to evaluate its typical spending behavioral patterns, v. information about the customer device used,. a detailed risk profile of the payer and/or the payer s device, TIME OUT, MAX ATTEMPT, EX-ANTE

9 8.1. The application of strong customer authentication in accordance with Article 97(1) of PSD2 is exempted where: (a) the payer accesses exclusively the information of its payment account online, or the consolidated information on other payment accounts held, without disclosure of sensitive payment data. not exempted where: i. the payer accesses ( ) for the first time, ii. the payer accesses ( ) later than one month after the last day in which strong customer authentication was applied. (b) the payer initiates a contactless electronic payment transaction at a point of sale within the limits of both the following conditions: i. the individual amount of contactless electronic payment transaction does not exceed the maximum amount of 50 EUR; ii. the cumulative amount of previous non-remote electronic payment transactions initiated via the payment instrument offering a contactless functionality without application of strong customer authentication does not exceed 150 EUR. EXEMPTIONS: ACCOUNT ACCESS + PROXIMITY

10 8.2. The application of strong customer authentication in accordance with Article 97(2) of PSD2 is exempted where: (a) the payer initiates online a credit transfer where the payee is included in a list of trusted beneficiaries previously created by the payer with its account servicing payment services provider. not exempted where: the payer creates for the first time or subsequently amends the list of trusted beneficiaries (b) the payer initiates online a series of credit transfers with the same amount and the same payee. not exempted where: the payer initiates the series of credit transfers for the first time or amends the series of credit transfers. (c) the payer initiates online a credit transfer where the payer and the payee are the same natural or legal person and the payee s payment account is held by the payer s account servicing payment services provider; (d) the payer initiates a remote electronic payment transaction where all the following conditions are met: i. the individual amount ( ) does not exceed the maximum amount of 10 EUR; and ii. the cumulative amount ( ) does not exceed 100 EUR. EXEMPTIONS: CT+ REMOTE

11 Art. 74 Odpowiedzialność płatnika za nieautoryzowane transakcje płatnicze 1.Na zasadzie odstępstwa od art. 73 płatnik może być zobowiązany do poniesienia strat związanych z wszelkimi nieautoryzowanymi transakcjami płatniczymi, do maksymalnej wysokości 50 EUR, będących skutkiem posłużenia się utraconym lub skradzionym instrumentem płatniczym lub przywłaszczenia instrumentu płatniczego. Akapit pierwszy nie ma zastosowania, gdy: (a) płatnik nie miał możliwości stwierdzenia utraty, kradzieży lub przywłaszczenia instrumentu płatniczego przed płatnością, z wyjątkiem sytuacji gdy płatnik działał w nieuczciwych zamiarach; lub (b) utrata została spowodowana działaniami lub brakiem działań ze strony pracownika, agenta lub oddziału dostawcy usług płatniczych lub podmiotu świadczącego na jego rzecz usługi w ramach outsourcingu. Płatnik ponosi wszelkie straty związane z nieautoryzowanymi transakcjami płatniczymi, jeżeli płatnik poniósł je, działając w nieuczciwych zamiarach lub dopuszczając się celowego lub rażącego zaniedbania co najmniej jednego z obowiązków określonych w art. 69. W takich przypadkach nie ma zastosowania maksymalna kwota, o której mowa w akapicie pierwszym. W przypadku gdy płatnik nie działał w nieuczciwych zamiarach ani nie zaniedbał celowo swoich obowiązków, o których mowa w art. 69, państwa członkowskie mogą ograniczyć odpowiedzialność, o której mowa w niniejszym ustępie, biorąc pod uwagę w szczególności charakter indywidualnych danych uwierzytelniających oraz konkretne okoliczności, w których dany instrument płatniczy został utracony, skradziony lub przywłaszczony. 2 W przypadku gdy dostawca usług płatniczych płatnika nie wymaga silnego uwierzytelnienia klienta, płatnik nie ponosi żadnych szkód finansowych, chyba że płatnik działał w złej wierze. W przypadku gdy odbiorca lub dostawca usług płatniczych odbiorcy nie akceptują silnego uwierzytelnienia klienta, zwracają PSD szkody II odpowiedzialność finansowe wyrządzone dostawcy usług płatniczych płatnika.

12 73.1. Państwa członkowskie zapewniają, aby bez uszczerbku dla art. 71 w przypadku nieautoryzowanej transakcji płatniczej dostawca usług płatniczych płatnika dokonywał na rzecz płatnika zwrotu kwoty nieautoryzowanej transakcji płatniczej, bezzwłocznie, a w każdym razie nie później niż do końca następnego dnia roboczego, po odnotowaniu danej transakcji lub po otrzymaniu stosownego zgłoszenia, z wyjątkiem sytuacji gdy dostawca usług płatniczych płatnika ma uzasadnione podstawy, by podejrzewać oszustwo, i poinformuje na piśmie o tych podstawach odpowiedni organ krajowy. W stosownych przypadkach dostawca usług płatniczych płatnika przywraca obciążony rachunek płatniczy do stanu, jaki istniałby, gdyby nie miała miejsca nieautoryzowana transakcja płatnicza. Obejmuje to również zapewnienie, by data waluty w odniesieniu do uznania rachunku płatniczego płatnika nie była późniejsza od daty obciążenia tą kwotą. zwrot D+1

13 centrum dowodzenia

14 P A D z e s t a w i e n i e szok TOiP

15 identyfikacja rejestrowanie analiza priorytetyzacja wyszukiwanie powiązań podejmowanie działań naprawczych usuwanie przyczyn komu zgłosić?? właściwym vs. właściwym stosownie do kompetencji GIIF GIODO KNF NBP soft law

16 Dyrektywa 2002/58/WE Dyrektywa PSD II Rozporządzenie o ochronie danych osobowych Dyrektywa NIS Istniejąca procedura obowiązek notyfikacji incydentów

17 Dyrektywa 2002/58/WE Dyrektywa PSD II Rozporządzenie o ochronie danych osobowych Dyrektywa NIS W przypadku poważnego incydentu operacyjnego lub incydentu związanego z bezpieczeństwem KNF wpływ na interesy finansowe użytkownika istotne szczegóły ocena znaczenia EOG MS CA bezpiecz. systemowe informacja + łagodzenie skutków EBA ECB ocena znaczenia ECB ESCB Klient Obowiązek notyfikacji incydentów

18 dlk.legal ul. Ogrodowa 58, , Warszawa ul. Królowej Jadwigi 237, Kraków T: dlk.legal Follow us on