Forum pytań i odpowiedzi PSD2

Wyszukaj ponad 40 pytań na takie tematy, jak uwierzytelnianie, dynamiczne łączenie zabezpieczeń aplikacji mobilnych i wiele innych

Jakie są kary, jeśli PSP nie będą zgodne z nowymi przepisami RTS do listopada 2018 r.?

PSD2 to europejska dyrektywa, którą muszą przyjąć wszystkie państwa członkowskie UE. Dostawcy usług płatniczych muszą spełniać wymogi PSD2, aby zostać prawnie uznanym za dostawcę usług płatniczych z prawem do świadczenia usług w UE.

Czy EUNB opublikuje przewodnik oceny RTS dotyczący SCA i CSC podobny do przewodnika EBC opublikowanego w 2014 r.?

Nie mamy informacji, które potwierdzają lub zaprzeczają, że EUNB wyda podobny przewodnik oceny.

Czy SMS jest zgodny z PSD2?

Jednym z celów EUNB w RTS było zachowanie neutralności technologicznej, aby zapewnić jak najwięcej miejsca na innowacje. Wyzwanie polegało na tym, aby nie określać zbyt nakazowo wymagań. Ostatecznie żadna konkretna technologia nie jest zakazana przez RTS, jednak niektóre z istniejących praktyk nie będą już w pełni zgodne z wymogami SCA. Możemy powiedzieć, że SMS może być postrzegany jako element posiadania, ponieważ zwykle może go odczytać tylko zamierzony odbiorca wiadomości SMS. Teoretycznie SMS spełnia wymóg posiadania elementu i dlatego może być używany jako element konstrukcyjny rozwiązania do podpisywania transakcji.

Aby spełnić wymagania dotyczące dynamicznego linkowania, oprócz kodu uwierzytelniającego wiadomość SMS musi zawierać informacje o płatności, tj. Kwotę pieniędzy i informacje o odbiorcy. Wymagania dotyczące dynamicznego linkowania wskazują również, że należy chronić poufność i integralność informacji o płatności. Może to oznaczać, że informacje o płatności muszą być zaszyfrowane. Jednak odszyfrowanie treści wiadomości SMS wymagałoby aplikacji na karcie SIM telefonu komórkowego lub na samym telefonie, co nie jest praktyczne.

W końcu korzystanie z SMS oznacza wysoki poziom bezpieczeństwa urządzenia użytkownika, ochronę przed oszustwami polegającymi na zamianie kart SIM, ochronę przed możliwym przechwyceniem i niewłaściwym użyciem SMS. W rzeczywistości są to obecnie bardzo trudne wyzwania. Różne właściwe organy mają obecnie różne opinie na temat korzystania z SMS. Kilka organów odradza korzystanie z SMS-ów, podczas gdy inne na to zezwalają. Monitorujemy te opinie i zaktualizujemy to FAQ, gdy zostanie podjęta jasna decyzja.

Czy telefon komórkowy i token można liczyć jako dwa kanały i być zgodne z PSD2?

Według PSD2 mechanizm uwierzytelniania musi być zbudowany z dwóch z trzech możliwych elementów uwierzytelniania, tj. Czegoś, co ma tylko użytkownik, czegoś, co zna tylko użytkownik, i czegoś, czym jest tylko użytkownik.

Kiedy użyjesz kodu uwierzytelniającego? Czy uważasz to za drugi czynnik?

Kod uwierzytelniający musi być zawsze używany do uwierzytelnienia użytkownika. Kod uwierzytelniający musi być generowany przez mechanizm uwierzytelniający, który jest zbudowany z dwóch z trzech możliwych elementów uwierzytelniających, tj. Czegoś, co ma tylko użytkownik, czegoś, co zna tylko użytkownik, i czegoś, czym jest tylko użytkownik.

Czy bezpieczny protokół 3D dla kart wystarcza na SCA, czy jest to obowiązkowe?

3D Secure jest rzeczywiście protokołem, który może być wykorzystywany przez dostawców usług płatniczych do budowy rozwiązania zgodnego z wymogami SCA dotyczącymi płatności kartowych.

Jaką kategorię trzech elementów SCA możesz podać OTP przez SMS? Czy to wiedza czy posiadanie?

Użytkownik otrzymuje wiadomość SMS normalnie na osobisty telefon, więc byłby to element posiadania.

Czy możesz wyjaśnić zakres PSD2? Czy to tylko płatności internetowe (oparte na przeglądarce online)? Jeśli nie, co jeszcze?

PSD2 obejmuje płatności oparte na przeglądarce i płatności mobilne.

Czy możesz nam powiedzieć więcej o tym, jak wdrażasz analizę zachowań? Czy to rozszerzenie DP4APPS SDK?

Uwierzytelnianie behawioralne OneSpan jest rozszerzeniem OneSpan Mobile Security Suite. Uwierzytelnianie behawioralne pozwala nie tylko dokładnie i bezproblemowo udowodnić tożsamość użytkownika, ale może także wykryć określone zachowania, na przykład ataki botów. Więcej informacji jest dostępnych tutaj.

Klienci OneSpan Mobile Security Suite mogą wykorzystać istniejącą implementację, dodając tylko nowe niezbędne komponenty rozwiązania. Aby osiągnąć najlepszą kombinację bezpieczeństwa i przyjazności dla użytkownika, ważne jest dziś połączenie wszystkich trzech elementów: 

  1. Bezpieczeństwo aplikacji mobilnych dzięki gromadzeniu danych urządzeń klienckich 
  2. Struktura uwierzytelniania wieloskładnikowego i biometrycznego oraz bezpieczny kanał dla bezpiecznej komunikacji 
  3. Oprogramowanie do analizy oszustw i ryzyka do analizy danych wejściowych użytkowników, urządzeń, zachowania i podejmowania decyzji w czasie rzeczywistym na wielu kanałach Pakiet rozwiązań OneSpan obejmuje wszystkie te obszary. 

 

Więcej informacji na temat Zgodność z PSD2 .

Czy istnieją jakieś wskazówki, czy weryfikacja przy użyciu danych biometrycznych powinna odbywać się po stronie serwera, czy po stronie klienta?

Regulacyjne standardy techniczne (RTS) dotyczące silnego uwierzytelniania klienta nie określają, czy weryfikacja biometryczna musi się odbywać po stronie klienta, czy serwera. Tak więc obie opcje są dozwolone.

Czy OneSpan otrzymał formalne zapewnienia od EBC dotyczące zgodności ich tokenów z PSD2 RTS?

W tej chwili nie ma formalnego programu certyfikacji dla konkretnych produktów w ramach PSD2. W związku z tym OneSpan nie może uzyskać formalnej gwarancji. Jednak OneSpan omawia zgodność swoich produktów w nieformalny sposób z właściwymi organami, aby upewnić się, że poprawnie interpretujemy RTS i aby nasze produkty były zgodne.

Czy zamierzasz oznaczyć każdy model tokena (np DP310) ze wskazaniem zgodności PSD2?

OneSpan obecnie nie planuje tego zrobić. Ponadto nie ma formalnego programu certyfikacji dla rozwiązań silnego uwierzytelniania w ramach PSD2.

Czy urządzenia sprzętowe do uwierzytelniania pin-pad OneSpan są zgodne?

Wymagania dynamicznego łączenia w RTS wskazują, że kod uwierzytelniający musi być obliczany na podstawie niektórych informacji o transakcji, w tym kwoty pieniędzy i informacji o odbiorcy (np. Numer rachunku bankowego odbiorcy).

Ponadto płatnik musi zostać poinformowany o tych informacjach o transakcji. Wreszcie, poufność, integralność i autentyczność informacji o transakcji muszą być przez cały czas chronione. W oparciu o te wymagania możemy powiedzieć o korzystaniu z urządzeń sprzętowych do uwierzytelniania PIN-pad:

  • To urządzenie zapewnia bardzo wysoki poziom bezpieczeństwa posiadania i wiedzy 
  • To urządzenie umożliwia użytkownikowi końcowemu wprowadzenie danych dotyczących kwoty i odbiorcy oraz włączenie ich w generowanie unikalnego kodu uwierzytelniającego 
  • Użytkownik jest świadomy działań na takim urządzeniu. Dlatego sprzętowe urządzenie Digipass z PIN-pad, jeśli jest używane z trybem podpisywania danych transakcji, jest zgodne z wymogami dynamicznego łączenia.

Czy dynamiczne linkowanie jest takie samo jak podpisywanie transakcji?

Tak to jest. Termin „dynamiczne łączenie” jest używany przez PSD2 i RTS w SCA.

Czy to oznacza, że OneSpan dostarcza dynamiczne łączenie, a nie oddzielną jednostkę, taką jak PSP?

Obowiązkiem PSP jest przeprowadzenie silnego uwierzytelnienia użytkowników. OneSpan może dostarczać PSP produktów i usług umożliwiających silne uwierzytelnianie.

RTS wymaga separacji kanałów między aplikacją, która będzie korzystała z transmisji OTP i transmisji OTP. Jak oceniasz zgodność 1AA?

Ostateczna wersja RTS nie wymaga już segregacji kanałów. Jak wskazano w komentarzach do końcowego projektu RTS, ten język został usunięty z projektu RTS, ponieważ był mylący.

W jaki sposób spełniasz wymóg z art. 2 ust. 2 A), gdy klient dokonuje kilku płatności na rzecz różnych odbiorców?

W przypadku płatności masowych kod uwierzytelniający należy obliczać na podstawie łącznej kwoty wszystkich płatności łącznie oraz na podstawie numerów rachunków wszystkich beneficjentów.

Czy OneSpan ma rozwiązania do generowania dynamicznego linkowania w przypadkach, gdy klienci nie chcą używać smartfonów?

Dziś OneSpan zapewnia rozwiązania uwierzytelniające dla ponad 2000 banków na całym świecie, z różnymi przypadkami użycia, potrzebami biznesowymi, grupami użytkowników i wymogami regulacyjnymi. Jest to możliwe, ponieważ OneSpan oferuje bardzo szeroki zakres rozwiązań, które mogą zaspokoić wszystkie możliwe potrzeby. Na przykład OneSpan zapewnia bardzo proste w obsłudze urządzenia zgodne z PSD2 z dużymi ekranami, przyciskami, a nawet poleceniami głosowymi dla starszych użytkowników: Digipass 301

Opcjonalnie w przestrzeni SWYS popularną opcją jest użycie jednego z zaawansowanych urządzeń z solidną gumową klawiaturą: Digipass 770

To urządzenie nie wymaga dokładnego wprowadzania danych przez użytkownika, wymaga jedynie akceptacji klienta i krótkiego wprowadzenia kodu PIN. Badania akceptacji użytkowników przeprowadzone przez klientów OneSpan wykazują bardzo wysoki wskaźnik adopcji i istotny spadek liczby zgłoszeń od pomocy technicznej po przejściu na tę technologię.

Czy w przypadku uwierzytelniania SMS za pomocą procesu 3DS nadal musimy podawać szczegóły płatności, gdy ACS generuje OTP i dystrybuuje ją na zarejestrowany numer telefonu komórkowego?

Nasza interpretacja wymagań dynamicznego łączenia w ostatecznym projekcie RTS jest taka, że informacje o płatności muszą być zawarte w wiadomości SMS w celu uwierzytelnienia płatności.

Mamy sprzętowy Digipass 275 z 5 liczbami, które mogą być użyte jako odpowiedź na wyzwanie dla dynamicznego łączenia. Czy jest to zgodne z dynamicznym łączeniem?

Jest to najprawdopodobniej zgodne z ostatecznym projektem RTS.

Czy OneSpan Go 6 Digipass jest zgodny z RTS w zakresie wymogu dynamicznego łączenia dla płatności o wysokiej wartości?

Zasadniczo tokeny Go nie generują kodów uwierzytelniających na podstawie informacji o płatnościach (takich jak kwota pieniędzy). Z tego powodu nie można go używać do dynamicznego łączenia, które jest zawsze wymagane w przypadku płatności powyżej 500 euro.

W jaki sposób rozwiązania sprzętowe, takie jak tokeny OTP, zapewniają dynamiczne łączenie z pojedynczymi transakcjami?

Zasadniczo użytkownicy mogą wprowadzać informacje dotyczące płatności, takie jak kwota pieniędzy i numer konta beneficjenta, do tokenów sprzętowych. Może się to zdarzyć za pomocą klawiatury tokena, kabla USB lub skanując kod wizualny. Token sprzętowy może następnie użyć informacji o płatności do obliczenia kodu uwierzytelniającego zgodnie z wymaganiami dotyczącymi dynamicznego łączenia.

Czy zasilacz musi zobaczyć szczegóły płatności (kwota i konto) na tokenie? To, co widzisz, jest tym, co podpisujesz?

„Zobacz, co podpisujesz” na tokenach sprzętowych można wykorzystać do spełnienia wymogu dynamicznego łączenia, ale nie jest to jedyna opcja. Bardzo prawdopodobne jest również wyświetlanie danych w aplikacji mobilnej.

Czy mógłbyś bardziej szczegółowo określić wiele możliwości podpisywania / autoryzacji transakcji? Czy dynamiczne linkowanie pozwala na wiele transakcji / beneficjentów?

Ostateczny projekt RTS stanowi, że w przypadku płatności masowych kod uwierzytelniający musi być obliczony na podstawie całkowitej kwoty pieniędzy płatności, a także informacji o beneficjentach różnych płatności.

Czy dynamiczne linkowanie jest nadal konieczne w przypadku płatności poniżej 30 euro w przypadku wdrożenia rozwiązania do monitorowania transakcji?

Nie, dynamiczne łączenie nie jest wymagane w przypadku płatności poniżej 30 EUR, o ile łączna kwota lub liczba wcześniejszych transakcji elektronicznych płatności zdalnych zainicjowanych przez płatnika, ponieważ ostatnie zastosowanie silnego uwierzytelnienia klienta nie przekracza odpowiednio 100 lub 5 EUR kolejne indywidualne zdalne transakcje płatności elektronicznych.

Jeśli stosowane są wyjątki, czy to prawda, że SCA można pominąć, a nie tylko dynamiczne łączenie?

To także nasze zrozumienie.

Jaka jest opinia OneSpan na temat RTS dla bankowości korporacyjnej?

RTS na SCA zapewniają minimalne wymagania bezpieczeństwa dla uwierzytelniających użytkowników. W przypadku bankowości korporacyjnej użytkownicy zazwyczaj dokonują płatności w stosunkowo wysokich kwotach. Dlatego oczekujemy, że banki będą chronić swoje aplikacje bankowości korporacyjnej za pomocą mechanizmów uwierzytelniania, które są silniejsze niż wymagane przez RTS na SCA.

Jakie są wymagania, jeśli klient ma już listę beneficjentów posiadającą certyfikat SA, ale musi dokonać przelewu pieniężnego o innej wartości?

Jak wskazano w art. 13 ostatecznego projektu RTS, SCA nie jest wymagany w przypadku płatności na rzecz zaufanych beneficjentów. Dokładne warunki znajdziesz w samym artykule.

RTS umożliwia uwierzytelnianie jednoskładnikowe dopiero po pierwszej próbie. 2FA należy następnie stosować co 9 dni. To różni się od tego, co zalecałeś w przeszłości. Proszę wytłumacz?

Artykuł 10 ostatecznego projektu RTS stanowi, że dostawcy usług płatniczych nie są zwolnieni z zastosowania silnego uwierzytelnienia klienta w odniesieniu do płatników, którzy chcą zapytać o swoje saldo lub zapoznać się z historią płatności z ostatnich 90 dni, jeżeli spełniony jest jeden z poniższych warunków :

  • Użytkownik usług płatniczych po raz pierwszy uzyskuje dostęp do swojego salda konta lub historii płatności od pierwszych 90 dni z ust. 1
     
  • Ostatni raz użytkownik usług płatniczych uzyskał dostęp do swojej historii płatności online z ostatnich 90 dni w ust. 1 i silne uwierzytelnienie klienta miało miejsce ponad 90 dni temu.

Czy płatności można umieścić na białej liście? Jeśli sprawdzimy miejsce docelowe na białej liście, a następnie zezwolimy na płatności bez DL do tego miejsca docelowego, czy powinno to wystarczyć?

Artykuł 13 ostatecznego projektu RTS pozwala dostawcy usług płatniczych nie przeprowadzać silnego uwierzytelnienia klienta, jeśli płatnik zainicjuje transakcję płatniczą, w której odbiorca znajduje się na liście utworzonych wcześniej zaufanych beneficjentów. Szczegóły w art. 13.

Czy osłonę aplikacji mobilnej OneSpan należy ponownie pakować za pomocą aplikacji bankowości mobilnej za każdym razem, gdy aktualizowana jest wersja?

Istnieją dwie części tego pytania:

  • Za każdym razem, gdy PSP ma wypuścić swoją aplikację mobilną na rynek aplikacji, należy chronić aplikację. Dobrą wiadomością jest to, że owijanie ekranów aplikacji zajmuje kilka sekund, a zatem nie wpływa na cykle wydawania aplikacji na PSP.
     
  • Ponieważ rozwiązanie OneSpan Mobile App Shielding jest regularnie aktualizowane w celu ochrony przed ewoluującymi zagrożeniami mobilnymi, zaleca się również, aby PSP chronili swoje aplikacje najnowszą wersją, aby zapewnić najwyższy możliwy poziom ochrony.

Czy osłona aplikacji obejmuje ochronę przed klonowaniem?

OneSpan Mobile Security Suite zapewnia funkcję wiązania urządzenia, która zapewnia ochronę przed klonowaniem aplikacji mobilnych.

Czy potrzebujesz osłony aplikacji mobilnej podczas korzystania z rozwiązania SMS? Aplikacja SIM?

Urządzenie mobilne, do którego dociera SMS, może również zawierać aplikację uwierzytelniającą (w scenariuszu 1aa lub 2aa), w której należy wprowadzić SMS. Tę aplikację należy chronić za pomocą osłony aplikacji mobilnej.

Czy są jakieś dodatkowe obawy dotyczące bezpieczeństwa związane z implementacją APP2APP w porównaniu z wypychaniem?

Naszym zdaniem są to dwa równie bezpieczne podejścia, które ostatecznie opierają się na tej samej technologii bezpiecznego kanału komunikacji. Widzimy, że są optymalne przy różnych modelach użytkowania. Wiele banków wdroży aplikację uwierzytelniającą, która działałaby w następującej konfiguracji: 

Gdy transakcja zostanie zainicjowana w aplikacji bankowości mobilnej, połączenie komunikacyjne App2App zostanie nawiązane w kierunku aplikacji uwierzytelniającej zainstalowanej na tym samym urządzeniu. Zapewnia to możliwość automatycznego przełączania między dwiema aplikacjami, co poprawia komfort użytkowania. 

Gdy transakcja zostanie zainicjowana w przeglądarce internetowej z innego urządzenia (komputera lub tabletu), powiadomienie PUSH zostanie wysłane do aplikacji uwierzytelniającej zainstalowanej na urządzeniu mobilnym użytkownika. Alternatywnie, przy prawie takim samym doświadczeniu użytkownika, można zastosować proces skanowania optycznego i podpisywania. 

Więcej informacji o rozwiązaniach Cronto można znaleźć tutaj: Znak Cronto

W przypadku aplikacji App2App z bezpiecznym kanałem komunikacji wymiana danych między aplikacjami odbywa się za pośrednictwem zaplecza w postaci zaszyfrowanej.

Czy uniwersalna platforma Windows (UWP) i tablety z systemem Windows są realną platformą rozwiązań dla SCA w konfiguracji 2AA 1AA? Czy piaskownica różni się w systemach iOS i Android?

Techniki piaskownicy w Universal Windows Platform (UWP) są podobne do Androida i iOS. UWP przyjęło wiele koncepcji z Androida i iOS. Windows 10 Mobile pozwala na uruchamianie tylko aplikacji UWP, więc mechanizmy piaskownicy mają porównywalną siłę jak Android i iOS tutaj. Standardowy system Windows 10 umożliwia uruchamianie zarówno aplikacji UWP, jak i zwykłych aplikacji Windows, więc piaskownica jest słabsza niż Android lub iOS.

Kiedy transakcja zostanie zainicjowana z APP TPP, który z przedstawionych przypadków użycia najprawdopodobniej zostanie wykorzystany?

Gdy użytkownik korzysta z aplikacji TPP, najprawdopodobniej widzimy jeden z następujących trzech przypadków użycia: 

  • Powiadomienie PUSH z banku do aplikacji uwierzytelniającej dostarczonej przez instytucję finansową. Nie wymaga to szczególnej integracji między stronami.
     
  • App2App komunikacja między aplikacją TPP a aplikacją uwierzytelniającą zapewnianą przez instytucję finansową. Wymaga to minimalnej integracji usługi uwierzytelniania między TPP a instytucją finansową. 
     
  • Wbudowane ramy bezpieczeństwa mobilnego w aplikacji TPP. Oznacza to, że TPP nie będzie polegać na wdrożeniu uwierzytelnienia przez instytucję finansową, ale zapewni własne. 

We wszystkich trzech opcjach TPP i instytucje finansowe będą musiały gromadzić dane wejściowe z urządzeń użytkownika i przeprowadzać dokładną analizę w wielu aplikacjach, kanałach i punktach końcowych w celu pełnej oceny ryzyka. Najlepszą opcją jest wdrożenie dedykowanego oprogramowania do zarządzania ryzykiem, takiego jak OneSpan Risk Analytics, które zapewnia: 

  • Wykrywanie wyrafinowanych oszustw w czasie rzeczywistym 
     
  • Przetwarzanie dużych ilości punktów danych w celu wykrycia nietypowych zachowań użytkowników, podejrzanych transakcji i nietypowej nawigacji w aplikacji płatniczej 
     
  • Dokładna ocena ryzyka i ograniczanie zagrożeń na wszystkich popularnych urządzeniach mobilnych (np. Telefonach komórkowych i tabletach) 
     
  • Operacje niewidoczne dla użytkowników końcowych, ograniczające oszustwa i zapewniające najlepszą możliwą obsługę
     

Jeśli używane jest uwierzytelnianie dwóch aplikacji, czy obie aplikacje mobilne muszą korzystać z systemu operacyjnego Sandboxing i osłony aplikacji mobilnych?

Piaskownica jest stosowana przez system operacyjny (np Android lub iOS) urządzenia mobilnego do każdej aplikacji działającej na urządzeniu. Do aplikacji uwierzytelniającej należy zastosować osłonę aplikacji mobilnej.

Czy digipass SDK jest dostępny / kompatybilny z nativescript?

Tak jest w tym przypadku.

Czy mógłbyś rozwinąć bezpieczną komunikację oferowaną przez OneSpan Mobile Security Suite? Co służy do zabezpieczenia? Co jest wymagane na serwerze?

Funkcja bezpiecznej komunikacji OneSpan Mobile Security Suite zapewnia możliwość stworzenia bezpiecznego kanału komunikacji między aplikacją a serwerem, chroniąc poufność, integralność i autentyczność wszystkich informacji o płatnościach. Pakiet OneSpan Mobile Security Suite zawiera zarówno zestawy SDK po stronie klienta, jak i serwera, aby ustanowić bezpieczny kanał. W ten sposób dostawcy usług internetowych mogą łatwo skonfigurować bezpieczny kanał bez konieczności samodzielnego zarządzania złożonością bezpiecznego kanału.

Jeśli identyfikator aplikacji, odcisk palca i kod PIN muszą zostać połączone dla aplikacji, czy istnieje zalecenie dla algorytmu HMAC?

Zalecamy stosowanie standardowych algorytmów HMAC, takich jak HMAC-SHA256 lub HMAC-SHA3.

Aby zachować zgodność w sytuacji 2AA, czy obie aplikacje muszą być chronione osłoną aplikacji mobilnych? Czy tylko aplikacja do uwierzytelniania?

Aplikacja uwierzytelniająca musi być chroniona osłoną aplikacji mobilnej. Aplikacja bankowa może być chroniona, ale nie jest wymagana w ostatecznym projekcie RTS.

Jak postrzegasz wykorzystanie parametrów behawioralnych jako czynników uwierzytelniających?

Tak, widzimy to jako możliwy element inherence. Komentarze EUNB do ostatecznego projektu RTS również wskazują, że jest to możliwe.

Czy OneSpan ma rozwiązanie wykorzystujące czynnik „inherence” (biometria) jako element uwierzytelniania?

Tak, OneSpan Mobile Security Suite obsługuje uwierzytelnianie biometryczne na podstawie odcisków palców, skanowania twarzy i zachowania użytkownika.

Czy możesz omówić TRA dla płatności hurtowych?

W przypadku płatności masowych kod uwierzytelniający dla SCA należy obliczyć na podstawie łącznej kwoty wszystkich płatności łącznie oraz na podstawie numerów rachunków wszystkich beneficjentów. Nie ma szczegółowych przepisów dotyczących TRA dla płatności hurtowych.

Czy rozwiązanie zapobiegawcze OneSpan może gromadzić wszystkie rodzaje transakcji, w tym: bankowość elektroniczną, kartę, pozycję, bankowość mobilną, portfele itp.?

Tak, OneSpan Risk Analytics może być wykorzystywany do analizy transakcji dla różnych rodzajów kanałów płatności.

Czy rozwiązanie OneSpan jest rozwiązaniem chmurowym? A jeśli tak, prywatne czy publiczne?

OneSpan Risk Analytics jest dostępny na miejscu, a także w chmurze. Wersja w chmurze jest hostowana przez OneSpan.

Czy OneSpan Risk Analytics jest zgodny z wymogami RTS?

Tak, OneSpan Risk Analytics może przeprowadzać analizę ryzyka transakcji zgodnie z wymogami ostatecznego projektu RTS.

Czy wszyscy PSP wymagają TRA, nawet jeśli planują używać SCA do wszystkich transakcji? Jeśli tak, jakie jest uzasadnienie tego wymogu?

Rzeczywiście, PSP zawsze muszą używać TRA, nawet jeśli używają SCA. TRA zapewnia drugą warstwę bezpieczeństwa obok SCA. TRA jest przydatny do ochrony przed atakami socjotechnicznymi, w których przeciwnik próbuje przekonać prawdziwego użytkownika do potwierdzenia płatności za pomocą SCA, gdy płatność jest faktycznie nieuczciwa.

Czy dyrektywy lub wytyczne określają pewne mandaty dla rozwiązań 2AA i 1AA w przypadku utraty lub kradzieży nośnika fizycznego?

Ostateczny projekt RTS stanowi, że procedura uwierzytelniania powinna obejmować mechanizmy monitorowania transakcji w celu wykrycia prób użycia spersonalizowanych danych uwierzytelniających użytkownika usług płatniczych, które zostały zgubione, skradzione lub przywłaszczone. Dotyczy to wszystkich rozwiązań uwierzytelniających, nie tylko tych z kategorii 2aa lub 1aa.

Skontaktuj się z nami

Czy masz inne pytania dotyczące PSD2? Uzyskaj potrzebne informacje szybko.