Publicysta BS BLOG-a Janusz Kurczych: Kilka słów po BBI 2017

janusz-kurczych-png

Publicysta BS BLOG-a, współprowadzący debatę o PSD2 na BBI 2017, Janusz Kurczych podsumowuje konferencję:

Nie wiem jak dla innych, konferencja stała się dla mnie źródłem wielu przemyśleń i inspiracji. Warto pewne rzeczy przemyśleć i zapamiętać:
– Niedługo zacznie tykać licznik odliczający 18 miesięcy (zatwierdzenie RTS), po których świat bankowości elektronicznej nie będzie już taki sam.
-Wybór Polish API lub własne rozwiązanie – Biznes określa potrzeby, IT proponuje rozwiązanie, komórka bezpieczeństwa szacuje i akceptuje ryzyko. Pytaliśmy dostawców o wybór, nie znając wyboru biznesu. To biznes powienien określić jak wygląda jego wizja, a dostawcy powinni określić czy gotowi są na te rozwiązania. A dostawcy nadal nie znają wyboru biznesu. W panelu padły słowa, że w środowisku bankowym pojawiły się dwa podejścia do budowy API. Wspólny standard i otwarcie się na TPP, lub indywidualne API i utrudnianie dostępu TPP. Patrząc przez pryzmat trudności w dostęp20170928_093434ie banków spółdzielczych do PAYU i ciągła ich pogoń za komercją w celu udostępniania kolejnych form płatności („bo klienci tego chcą, bo inni to mają”) to chyba nie mamy innego wyjścia. Tak na dobrą sprawę to klient decyduje o tym jakie usługi powinien mieć bank. Bo decyzję o tym, żeby skorzystać z TPP podejmuje klient, a nie bank. Jak nie ma takich możliwości, to zmienia bank. A banki, które skupiają się wyłącznie nia działalności kredytowej zostaną bez depozytów i środków w formie osadów na rachunkach.
-Łączenie PSD2 z RODO – jak ognia z wodą, niezbadany teren z masą finansowych pułapek. Że istnieją narzędzia do automatyzacji procesu monitorowania i raportowania zagrożeń pod kątem RODO i że niektórzy ubezpieczyciele oferują już możliwość transferu ryzyk z tym związanych.
-Bank ma zapewnić udostępnienie API dla swoich klientów bankowości elektronicznej, a nie wszystkich.
20170928_091432-Nowa interpretacja – ograniczenie możliwości korzystania z haseł statycznych jako elementu uwierzytelniania (czekam na materiały źródłowe od Panelisty, bo taka interpretacja eliminowałaby wiedzę jako element uwierzytelniania).
– Spośród dostawców przybyłych na konferencję albo już testują rozwiązania na podstawie dostępnych materiałów roboczych (draftu Polish API, draftu RTS), albo są w trakcie tworzenia lub deklarują gotowość do prac. Wszyscy dostawcy spośród przybyłych dokonali inwentaryzacji dotychczasowych metod autoryzacji w bankowości elektronicznej i są gotowi do dostosowania ich do wymagań PSD2. Tylko nie wiem czy banki są świadome, że proces migracji na nowe formy autoryzacji to proces od 3 do 6 miesięcy.
Podsumowując – dzięki zaangażowaniu i doborowi prelegentów przez Alberta (specjalne podziękowania) udało nam się merytorycznie porozmawiać na tematy PSD2 i bezpieczeństwa bankowości internetowej. 20170928_093148Prezentacje nawzajem doskonale się uzupełniały pomimo tego, że nie wszystkie dotyczyły wprost PSD2. Dziękuję wszystkim prelegentom za merytoryczny wkład w konferencję i profesjonalne przygotowanie. No i uczestnikom za aktywny udział i liczne przybycie, utwierdzając organizatorów w przekonaniu, że warto było. Mam nadzieję, że być może na łamach BS Bloga uda nam się poprzez wzajemną dyskusję pogłębiać wiedzę na temat PSD2. Pozdrawiam wszystkich uczestników i liczę na komentarze, żebym wiedział że warto było się zaangażować.

Wideo-relacja: skrót z debaty na konferencji BBI 2017:

 

Powiązane wpisy

9 komentarze na temat “Publicysta BS BLOG-a Janusz Kurczych: Kilka słów po BBI 2017

  1. Jarek

    Zachęcam, żeby na BLOGu który dotyczy Banków Spółdzielczych, a nie tylko działki IT używać bardziej zrozumiałego języka… Określenia RTS, API, TPP naprawdę niewiele mówią przeciętnemu czytelnikowi a bez ich zrozumienia powyższy tekst jest „niestrawny”

  2. Janusz Kurczych

    Przepraszam za brak rozwinięcia skrótów – ale oprócz API są to pojęcia biznesowe a nie informatyczne:
    RTS – Regulatory Technical Standards – Regulacyjne standardy techniczne dotyczące w tym przypadku wymagań implementacji dyrektywy PSD2.
    API – Application Programming Interface – interfejs programistyczny aplikacji
    TPP – third party providers – trzecia strona – dostawca który będzie mógł świadczyć usługi informacyjne lub inicjowania płatności.
    Polecam np. w tym temacie stronę:
    http://www.dlklegal.com/nowe-uslugi-platnicze-w-psd2-5

  3. PPP

    Czy bank, który jest w jakimkolwiek zrzeszeniu powinien sobie zawracać głowę tym całym API w kontekście PSD2 ?

  4. Janusz Kurczych

    Oczywiście – każdy bank udostępniający dostęp do rachunku poprzez bankowość internetową musi udostępnić taki dostęp innym podmiotom poprzez interfejs API. To analogia do rynku telekomunikacyjnego gdzie operator łącz musi je udostępnić innym podmiotom które pragną świadczyć usługi telekomunikacyjne.

  5. PPP

    Chyba źle się wyraziłem bo miałem na myśli to, że np. BS jest w Zrzeszeniu. Zrzeszenie może wynegocjować od dostawcy API lepsze ceny dla kilkudziesięciu banków naraz. Po drugie BSy mają przeważnie bankowość internetową w outsorcingu. Nad czym więc tak informatycy debatują? Może rzeczywiście w wielu BSach informatycy mają realny wpływ na takie rzeczy to przepraszam.

  6. Janusz Kurczych

    W takim kontekście pytanie jest dobrze postawione. Osobiście jestem zwolennikiem jednego wspólnego standardu typu Polish API. Tak aby dostawcy usług zainteresowali się inicjowaniem płatności także z rachunków klientów banków spółdzielczych. A czemu informatycy debatują?
    1. Bo nie debatuje biznes, a powinien już budować model biznesowy i przygotować klientów na zmiany.
    2. Bo wymagania dotyczące silnego uwierzytelnienia spowodują, że możemy zapomnieć o obsłudze autoryzacji/logowania w dotychczasowym modelu i będzie potrzeba zmian umownych i przygotowania klientów na zmiany. Tokeny, listy tan, zdrapki pójdą w odstawkę. Zalogowanie się do systemu bankowości elektronicznej będzie wymagało oprócz podania identyfikatora także hasła statycznego i jednorazowego. Do autoryzacji transakcji będzie można używać tylko smsów lub tokenów z klawiaturą lub tokenów programowych. Ogólnie urządzeń które oprócz kodu wyświetlą szczegóły autoryzowanej transakcji.
    3. Że bank będzie musiał posiadać system monitoringu antyfraudowego który ma wykrywać i zapobiegać transakcjom fraudowym jeszcze przed ich autoryzacją.
    4. Że z tych działań Bank musi sporządzać coroczny raport i przeprowadzać audyty.
    A co do outsoursingu – proszę wskazać mi na dzień dzisiejszy system, który spełnia już te wymagania?
    Debata dotyczyła wyłącznie budowaniu świadomości tego co nas czeka.

  7. janusz kurczych

    Hmm.. nad czym więc tak informatycy debatują?
    Kolega miał okazję skorzystać z oferty, uczestniczyć w konferencji i zobaczyć nad czym. A wedle mojej wiedzy opartej na rozmowach z uczestnikami warto było. Konferencja nie była skierowana do informatyków i uczestniczyli w niej również członkowie zarządów banków.Ogólnie dla osób, które mają świadomość, jakie wyzwania niesie ze sobą PSD2.
    Głównym zadaniem konferencji było przybliżenie uczestnikom wiedzy o czekających nas zmianach. I wymiana własnych doświadczeń i przemyśleń w tym zakresie. I nie chodzi tu bynajmniej o API. W zakresie API bank ma udostępnić swoim klientom bankowości elektronicznej ten kanał dostępu, więc główne zadanie w tym zakresie będzie spoczywać na dostawcach systemów bankowości elektronicznej. I stąd debata, aby poznać stopień przygotowania naszych dostawców, przynajmniej tych, którzy dotarli na debatę. W aspekcie działania w grupie akurat w pełni się zgadzam z kolegą – powinien być jeden wspólny standard interfejsu nawet nie tylko dla wszystkich banków spółdzielczych, ale wszystkich banków w Polsce. Powtarzam STANDARD, bo nie ma kogoś takiego mitycznego jak zewnętrzny dostawca api. To będzie dotychczasowy dostawca bankowości internetowej+ ewentualnie dostawca systemu corowego implementujący ten standard u siebie. I tu pojawia się rola BIZNESU, aby wymusić na wszystkich dostawcach jednolity STANDARD, ale jakoś żadnej inwencji w środowisku banków spółdzielczych nie zauważyłem w tym zakresie. Oprócz zasługujących na wielką pochwałę działań Krajowego Zrzeszenia Banków Spółdzielczych popularyzującego wiedzę na temat PSD2 (szkolenia i konferencje), popularyzujących tworzący się standard Polish API i aktywnego udziału w pracach legislacyjnych nad nowelizacją Ustawy o usługach płatniczych będącą przeniesieniem dyrektywy PSD2 na rynek krajowy.
    Ale gdyby chodziło wyłącznie o API…
    Kolega (sądząc po wpisie) jest pewnie świadomy, jakie konsekwencje finansowe niosą za sobą zapisy PSD2 dotyczące silnego uwiwrzytelniania. Każdy klient bankowości elektronicznej logując się do systemu, oprócz identyfikatora będzie musiał podać hasło statyczne (WIEDZA) i kod jednorazowy (POSIADANIE). I to już prawdopodobnie od wejścia w życie nowelizacji ustawy, czyli zgodnie z wymogami unijnymi 13.01.2018 r. Tokeny bez klawiatury, listy tan, zdrapki może sobie kolega z chwilą wejścia ustawy wyrzucić do kosza. Pozostaną sms (których koszt musi bank wziąć na siebie – bo w przeciwnym wypadku klienci założą sobie w banku podstawowy rachunek płatniczy), albo token z klawiaturą, lub aplikacja na komputer lub smartfona z funkcją push (żeby te kody wysyłać) lub podpis elektroniczny. Czyli koszty, koszty koszty… Dlaczego? Bo silne uwierzytelnie przy inicjowaniu płatności musi być dynamicznie powiązane z kwotą transakcji i adresatem. Migracja klientów na nowe formy autoryzacji to chyba też nie będzie zadanie dla informatyków. Zapisy umowne, wymiana środków autoryzacji. Niemożność przejścia na smsy (brak zasięgu), niechęć klientów do zmiany form autoryzacji. A czas nieubłaganie płynie a niedostosowanie to konsekwencje finansowe (brak silnegu uwierzytelniania – cała odpowiedzialność za fraudy spoczywa na banku). Przerabialiśmy już to w Banku, więc wiem o czym mówię – proszę zapomieć, że uda się to krócej niż w przeciągu pół roku. I żadne działania zrzeszeniowe czy dostawców nie pomogą. Wracając do dostawców, nie na nich spoczywa obowiązek dostosowania tylko na banku, bo to on odpowiada za konsekwencje używania niezgodnych z prawm narzędzi, a dostawca nadal będzie je dostarczał póki będzie popyt.
    Byłbym zapomniał o kolejnym ustawowym wymogu – monitoringu transakcji klientów w bankowości elektronicznej przyporządkowujący wagę ryzyka do transakcji i wymóg ostrzegania o możliwości wystąpienia transakcji fraudowej PRZED jej zainicjowaniem przez klienta. No i o obowiązku sprawozdawczym w zakresie tego procesu i konieczności corocznych audytów w tym zakresie. I znów koszty, koszty koszty…
    Sarkastycznie stwierdzę…. ma kolega rację, po co Ci informatycy o tym gadają. Przecież to ich nie dotyczy. Lepiej żyć w błogiej nieświadomości.
    A może wyłączyć zupełnie klientom bankowość elektorniczną. Zredukuje się trochę kadry informatycznej. Wpisze się na budynkach placówek TRADYCYJNY BEZPIECZNY BANK….

  8. PPP

    Dziękuję za tak obszerny wywód. Przekonał mnie Pan. W idealnym świecie informatyk powinien przedstawić Zarządowi swoje sugestie, obawy,wytyczne i zorganizować spotkanie z dostawcami. Inna sprawa, że nadal uważam że od tego jest też Zrzeszenie które z informatykiem z banku zrzeszonego za dużo rozmawiać nie będzie.

  9. Janusz Kurczych

    W idealnym świecie = zgodnie z zapisami rekomendacji D ?
    Akurat w przypadku Zrzeszenia BPS ten dialog rozwija się i to bardzo pozytywnie. Nie mogę nic powiedzieć na ten temat w przypadku Zrzeszenia SGB. Ja akurat uczestniczę jako jeden z kilku informatyków w rozmowach na temat RODO, STIR/CMO, Split Payment, PSD2. Chętnie służę pomoca w przekazaniu danych kontaktowych do osób z Banku Zrzeszającego, jeśli ktoś chciałby się zaangażować z Banków Spółdzielczych w ten dialog.