Z czym mierzył się klient i dlaczego to było krytyczne?
Bank odnotował wyraźny wzrost ataków socjotechnicznych typu remote access scam. Klienci działali pod presją i w kontakcie z osobą podszywającą się pod pracownika banku lub „wsparcie techniczne”, a w tle uruchamiano zdalny pulpit, stopniowo przejmując kontrolę nad urządzeniem.
Dla banku wszystko wyglądało poprawnie: prawidłowe logowanie, znane urządzenie, sesja zgodna z profilem użytkownika. Nadużycia działy się jednak poza infrastrukturą banku - na urządzeniu klienta - już po zalogowaniu, w trakcie legalnej sesji.
Bank często dowiadywał się o fraudzie dopiero po fakcie, bo systemy nie widziały jednoznacznych anomalii. Mimo istniejących mechanizmów wykrywania przejęć sesji, ich skuteczność była nierówna (różnice między Windows/macOS i narzędziami zdalnego dostępu).
W efekcie zespół fraudowy często wiedział, że „coś jest nie tak”, ale nie miał jednoznacznego sygnału, który pozwalałby podjąć decyzję z pełnym przekonaniem. To prowadziło do opóźnionych reakcji, eskalacji „na wszelki wypadek” i rosnącej liczby manualnych weryfikacji. Koszt operacyjny rósł, a ryzyko blokowania legalnych klientów było realne.
Co wdrożyliśmy i jak to działało w praktyce?
Bank zdecydował się na wdrożenie Remote Desktop Detection for Web jako precyzyjnego sygnału, uzupełniającego istniejący stack antyfraudowy.
Rozwiązanie wykrywało obecność zdalnego pulpitu, a przede wszystkim moment faktycznego przejęcia kontroli nad sesją użytkownika. Działało w czasie rzeczywistym i niezależnie od systemu operacyjnego, obejmując zarówno Windows, jak i macOS oraz przeglądarki mobilne.
Gdzie był wykorzystywany sygnał:
- na stronie logowania,
- przed transakcjami wysokiego ryzyka,
- przy krytycznych akcjach w sesji.
Decyzja o miejscu użycia sygnału była elastyczna i dopasowana do polityki banku.
Detekcja działała od pierwszego dnia po wdrożeniu dzięki różnorodnym mechanizmom (Active/Passive) - bez tygodni uczenia profilu użytkownika. Model privacy by design nie bazuje na danych identyfikujących ani biometrii, co zwykle upraszcza wewnętrzną akceptację compliance w banku.
Od strony integracji rozwiązanie wymagało minimalnego zaangażowania zespołu IT. Jedna linijka JavaScript, brak ingerencji w architekturę, brak zmian w istniejących systemach antyfraudowych. Testy, aktualizacje i utrzymanie pozostały po stronie PREBYTES, co realnie odciążyło zespół banku.
Rozwiązanie nie zastąpiło istniejących narzędzi - wzmocniło je precyzyjnym sygnałem.
Jak bank używał sygnału?
W zależności od poziomu ryzyka bank mógł automatycznie wylogować użytkownika, podnieść risk score lub przekazać jasny, zrozumiały sygnał do zespołu fraudowego. To nie był kolejny generyczny alert, ale konkretna informacja, dlaczego dana sesja jest ryzykowna.
Dzięki temu decyzje przestały opierać się na domysłach.
Jakie były rezultaty i co to zmieniło na co dzień?
Pierwsze efekty były widoczne bardzo szybko, ale największa zmiana zaszła w codziennej pracy zespołu fraudowego.
Zespół przestał reagować wyłącznie po fakcie i zgadywać, czy doszło do przejęcia kontroli nad urządzeniem i nadużycia. Pojawiła się pewność decyzji w czasie rzeczywistym i spójność działań w całym zespole. Liczba manualnych case’ów znacząco spadła, a legalni użytkownicy przestali być niepotrzebnie blokowani.
Z perspektywy klientów ochrona pozostała całkowicie niewidoczna. Bankowość działała bez opóźnień, nie było potrzeby instalowania czegokolwiek ani wyrażania dodatkowych zgód. Poziom bezpieczeństwa wzrósł bez kosztu dla UX.
Efekty po wdrożeniu:
- 97% spadek liczby potwierdzonych fraudów typu remote access scam w kanale web (vs okres sprzed wdrożenia)
- znaczące ograniczenie liczby manualnych analiz / case’ów dzięki jednoznacznemu sygnałowi w czasie rzeczywistym
- brak niepotrzebnego blokowania legalnych użytkowników (spadek false positives / eskalacji „na wszelki wypadek”)
- brak wpływu na UX i wydajność bankowości
- ROI osiągnięte w ciągu 3 miesięcy