Oszustwa BEC 2.0: deepfake audio, fałszywe faktury i jak ustawić weryfikację płatności

Nowa fala BEC: deepfake audio i fałszywe faktury – na czym polega zagrożenie

BEC (Business Email Compromise) to oszustwa, w których przestępcy manipulują procesem płatności w firmie, aby nakłonić pracowników do wykonania przelewu na konto kontrolowane przez atakujących. W wersji „2.0” nie chodzi już wyłącznie o przekonujący e-mail: coraz częściej wykorzystywane są deepfake audio (syntetyczny głos) oraz fałszywe lub podmienione faktury, które wyglądają jak prawdziwe dokumenty księgowe. Efekt jest ten sam: pieniądze opuszczają organizację w sposób „poprawny” z perspektywy banku, ale trafiają do niewłaściwego odbiorcy.

Kluczową zmianą jest to, że ataki BEC 2.0 są projektowane tak, aby ominąć intuicyjne mechanizmy ostrożności. Gdy pracownik słyszy znajomy głos lub widzi fakturę zgodną z dotychczasowym formatem, maleje skłonność do kwestionowania polecenia. Jednocześnie oszuści podnoszą realizm przekazu, łącząc kilka kanałów naraz (np. e-mail + telefon) i wykorzystując publicznie dostępne informacje o firmie, procesach czy relacjach z dostawcami.

Deepfake audio w kontekście BEC to użycie narzędzi generujących mowę, które potrafią naśladować barwę i sposób mówienia konkretnej osoby na podstawie krótkich próbek głosu (np. z nagrań konferencyjnych, webinarów, mediów społecznościowych). Taki „głos przełożonego” może wydawać polecenie pilnego przelewu, doprecyzować kwotę lub przekonać, że zmiana jest uzasadniona i „zatwierdzona”. To nie musi być długie, filmowe nagranie — czasem wystarczy kilkanaście sekund instrukcji, które uruchomią działania po stronie finansów.

Fałszywe faktury w BEC 2.0 nie zawsze są tworzone od zera. Częstym mechanizmem jest podmiana kluczowych danych w dokumencie, przede wszystkim numeru rachunku bankowego, danych płatniczych lub informacji o beneficjencie. Wizualnie faktura może wyglądać niemal identycznie jak wcześniejsze: ten sam układ, nazewnictwo, styl komunikacji, a nawet poprawne numery zamówień czy odniesienia do korespondencji. Dzięki temu ryzyko „wyłapania” oszustwa na pierwszy rzut oka znacząco spada.

Wspólną cechą tych ataków jest to, że uderzają w najsłabsze ogniwo procesu płatności: zaufanie do komunikacji oraz rutynę operacyjną. Zamiast łamać zabezpieczenia systemów finansowych, przestępcy wykorzystują luki w procedurach, brak konsekwentnej weryfikacji zmian danych płatniczych oraz presję czasu. To zagrożenie dotyczy zarówno dużych organizacji, jak i mniejszych firm, bo punktem wejścia bywa zwykła skrzynka e-mail, telefon służbowy albo faktura w obiegu.

• Atak jest „wiarygodny”: znany głos, znajome dokumenty i spójna narracja zwiększają skuteczność manipulacji.
• Cel jest konkretny: przelew na wskazany rachunek lub przekierowanie płatności na „zaktualizowane” dane.
• Wykorzystuje proces, nie technologię banku: transakcja bywa autoryzowana zgodnie z wewnętrznymi zasadami, które zostały sprytnie obejścia lub zmanipulowane.
• Skala szkody rośnie: oszuści dążą do wysokich kwot jednorazowo lub serii płatności, zanim nieprawidłowość zostanie zauważona.

W praktyce BEC 2.0 to połączenie socjotechniki i narzędzi, które obniżają koszt „udawania” wiarygodnej osoby lub dokumentu. Organizacje, które wcześniej polegały na rozpoznawaniu stylu pisania, „intuicji” lub nieformalnych potwierdzeniach, muszą zakładać, że głos i faktura nie są już dowodem autentyczności — są jedynie elementem scenariusza, który ma uruchomić płatność.

Typowe scenariusze ataku: podszycie pod zarząd, dostawcę i zmianę numeru rachunku

BEC 2.0 najczęściej nie polega na „włamaniu do banku”, tylko na manipulacji procesem: napastnik wykorzystuje zaufanie, rutynę oraz luki w obiegu informacji, aby skłonić firmę do wykonania przelewu na kontrolowane konto. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. Poniżej trzy najczęstsze scenariusze, które różnią się celem, punktem wejścia i tym, pod kogo atakujący się podszywa.

1) Podszycie pod zarząd (CEO/CFO fraud)

W tym wariancie celem jest szybkie wymuszenie płatności „z polecenia przełożonego”. Atakujący podszywa się pod osobę decyzyjną i naciska na pilność oraz poufność, często korzystając z nietypowych kanałów komunikacji.

• Mechanizm: wiadomość e-mail/SMS/komunikator, a coraz częściej także deepfake audio lub „krótki telefon” z poleceniem wykonania przelewu.
• Cel: jednorazowy, wysoki przelew (np. „pilna płatność”, „zaliczka”, „zamknięcie transakcji”).
• Dlaczego działa: pracownik omija standardowe kroki, bo „to polecenie z góry” i „nie ma czasu na formalności”.

2) Podszycie pod dostawcę (vendor impersonation)

Ten scenariusz jest bardziej „operacyjny”: atakujący udaje kontrahenta i wplata się w normalny obieg faktur. Zamiast jednorazowej presji, stawia na wiarygodność i podobieństwo do codziennej korespondencji.

• Mechanizm: wiadomości udające dział rozliczeń dostawcy, dosyłanie „duplikatu” faktury, prośba o potwierdzenie salda lub „ponowne przesłanie” dokumentów.
• Cel: opłacenie sfałszowanej faktury lub przechwycenie płatności za prawdziwą fakturę.
• Dlaczego działa: proces jest rutynowy, a pracownicy zakładają, że e-mail „z fakturą” to zwykła praca, zwłaszcza przy dużej liczbie dokumentów.

3) Zmiana numeru rachunku (change of bank details / diversion)

To odmiana podszycia pod dostawcę, ale z bardzo konkretnym celem: przekierować płatności za realne usługi lub towary na nowe konto. Często atakujący czeka na moment, gdy faktura jest już zaakceptowana, i wtedy wprowadza „korektę danych”.

• Mechanizm: prośba o aktualizację danych płatniczych (np. „zmieniliśmy bank”, „nowy rachunek do rozliczeń”, „tymczasowe konto”), czasem z załączonym pismem lub „potwierdzeniem” rzekomo od banku.
• Cel: przejęcie płatności, które i tak miały zostać wykonane — dzięki temu kwoty i terminy wyglądają wiarygodnie.
• Dlaczego działa: zmiany danych dostawcy bywają obsługiwane poza głównym workflow faktury, a aktualizacja w systemie finansowym bywa traktowana jako czynność administracyjna.

W praktyce te scenariusze mogą się łączyć: podszycie pod zarząd zwiększa presję, a podszycie pod dostawcę dostarcza „dokumenty” i kontekst. Wspólnym mianownikiem jest próba obejścia standardowych ścieżek akceptacji i przeniesienia rozmowy na kanał, w którym łatwiej narzucić tempo i ograniczyć weryfikację.

3. Sygnały ostrzegawcze (red flags): język, presja czasu, nietypowe kanały i anomalie w fakturach

W BEC 2.0 (Business Email Compromise) atakujący coraz częściej łączą klasyczne podszycie mailowe z deepfake audio oraz spreparowanymi dokumentami. Dlatego „czerwone flagi” rzadko są pojedynczym, oczywistym błędem — częściej to zestaw drobnych niezgodności w treści, tonie komunikacji, sposobie kontaktu i danych na fakturze. Poniżej najczęstsze sygnały ostrzegawcze, które warto traktować jako powód do zatrzymania procesu i dodatkowej weryfikacji.

Język i styl komunikacji: drobne odchylenia, które mają znaczenie

• Nietypowa forma zwracania się (np. nagła zmiana z formalnej na poufałą lub odwrotnie), nienaturalne konstrukcje, kalki językowe.
• Zmiana „odcisku” komunikacyjnego: inne tempo, długość zdań, brak charakterystycznych zwrotów, inny sposób podpisu (np. brak stopki, skrócona stopka, brak standardowych danych).
• Wymijające odpowiedzi na proste pytania (np. o podstawę zmiany danych, numer zamówienia, potwierdzenie przez standardowy kanał).
• „Upraszczanie” formalności: prośby o pominięcie zwyczajowych kroków, „tylko tym razem”, „bo audyt/zarząd/kontrakt”.
• Nadmierna poprawność w krótkich komunikatach (zwłaszcza w SMS/komunikatorze) albo przeciwnie — nagłe literówki i chaos w wiadomości, gdy nadawca zwykle pisze inaczej.

Presja czasu i budowanie emocji: pośpiech jako narzędzie kontroli

• Silna presja na natychmiastowe działanie: „do końca dnia”, „w ciągu 30 minut”, „to pilne i poufne”.
• Straszenie konsekwencjami: kary umowne, wstrzymanie dostaw, utrata rabatu, „problemy na spotkaniu zarządu”.
• Odwołanie do tajemnicy: „nie angażuj innych”, „to poufna transakcja”, „nie wysyłaj do ogólnej skrzynki”.
• Próba przejęcia inicjatywy: atakujący sam narzuca kolejny krok („wyślę nowe dane, tylko wprowadź i potwierdź, że poszło”).

Nietypowe kanały kontaktu: zmiana medium i obchodzenie standardów

W BEC 2.0 sygnałem ostrzegawczym jest nie tylko „dziwny e-mail”, ale też przeskok na inny kanał lub nagła zmiana sposobu kontaktu, szczególnie przy finansach.

• Prośba o potwierdzenie przez komunikator/SMS zamiast firmowej poczty lub systemu obiegu dokumentów.
• Połączenie telefoniczne bez zapowiedzi w sprawie płatności, zwłaszcza gdy to temat zwykle załatwiany mailowo.
• Deepfake audio jako „dowód”: głos brzmi wiarygodnie, ale rozmowa jest nienaturalnie krótka, z naciskiem na jedną instrukcję (przelew/zmiana danych) i bez miejsca na pytania.
• Adresy e-mail „prawie takie same”: drobne różnice w domenie, dodatkowy znak, inna końcówka (.com vs .pl), dopisek w nazwie.
• Przekierowanie na prywatne skrzynki („wyślij na mój alternatywny e-mail”) lub prośba o kontakt pod nowy numer telefonu bez kontekstu.

Anomalie w fakturach i danych płatniczych: to, co zwykle się nie zmienia

• Zmiana numeru rachunku (IBAN) lub banku — szczególnie gdy następuje „nagle” i bez formalnego uzasadnienia.
• Inny odbiorca płatności niż dotychczas (inna nazwa podmiotu, niepasujący adres, brak spójności z wcześniejszymi dokumentami).
• Rozjazdy w danych: NIP/VAT, adres, numer faktury, numer zamówienia/umowy — niby są, ale nie pasują do znanych wzorców lub wcześniejszych dokumentów.
• Niecodzienne pozycje lub opisy: ogólne sformułowania („usługa konsultingowa”, „opłata operacyjna”), brak specyfikacji, inne jednostki miary, brak osoby kontaktowej.
• Nietypowy termin płatności: skrócony „na już”, zmiana waluty, prośba o split payment/bez split payment wbrew praktyce.
• Format i jakość dokumentu: brak standardowych elementów firmowych, inne logo/krój pisma, podejrzane metadane PDF, skany o niskiej jakości zamiast plików źródłowych.

Tabela szybkiej oceny: co jest „normalne”, a co powinno zapalić lampkę

Minimalna zasada praktyczna: jeden sygnał to uwaga, kilka to stop

Pojedyncza niezgodność może wynikać z błędu lub pośpiechu, ale kumulacja (np. presja czasu + zmiana rachunku + kontakt z nowego kanału) powinna automatycznie uruchamiać ostrożność i wstrzymanie działania do czasu potwierdzenia. Najważniejsze jest zauważenie, że deepfake i dobre podróbki dokumentów nie eliminują „szumu” operacyjnego — to właśnie drobne odstępstwa najczęściej zdradzają próbę oszustwa.

Skutki biznesowe: straty finansowe, przestoje operacyjne, ryzyko prawne i reputacyjne

BEC 2.0 nie jest „tylko” incydentem e-mailowym. To zdarzenie biznesowe, które uderza jednocześnie w finanse, ciągłość działania oraz zaufanie interesariuszy. Deepfake audio i dobrze przygotowane fałszywe faktury zwiększają prawdopodobieństwo, że błąd zostanie popełniony szybko i bez typowych podejrzeń, a to przekłada się na szersze skutki niż jednorazowa utrata środków.

Straty finansowe: bezpośrednie i pośrednie koszty

Bezpośrednia strata to najczęściej nieautoryzowany przelew lub opłacenie faktury na podstawiony rachunek. W praktyce jednak koszt incydentu rośnie przez elementy towarzyszące, które trudno „cofnąć” księgowo:

• Utrata płynności (zamrożenie części budżetu operacyjnego, przesunięcia w cash flow, konieczność finansowania pomostowego).
• Koszty odzyskiwania środków (obsługa bankowa, działania windykacyjne, konsultacje zewnętrzne, obsługa incydentu).
• Straty na różnicach kursowych i opłatach (szczególnie przy płatnościach międzynarodowych i krótkich terminach).
• Nieplanowane koszty zakupów (awaryjne zakupy u innych dostawców, droższy transport, ekspresowe realizacje).

Przestoje operacyjne: gdy „pomyłka” blokuje procesy

Fałszywa płatność rzadko jest odosobniona — często wywołuje reakcję łańcuchową. Nawet jeśli kwotę uda się później odzyskać, firma może ponieść koszt w postaci czasu i utraconej produktywności. Doświadczenie Cognity pokazuje, że to właśnie konsekwencje operacyjne (a nie sama kwota przelewu) najszybciej eskalują w codziennej pracy po incydencie.

• Zatrzymanie dostaw i usług (dostawca nie widzi płatności, wstrzymuje wysyłkę, ogranicza kredyt kupiecki).
• Opóźnienia w realizacji projektów (brak materiałów, brak dostępu do usług, zmiana priorytetów operacyjnych).
• Zakłócenia w finansach (rekonsyliacja płatności, korekty księgowań, wyjaśnienia z audytem i kontrolingiem).
• Przekierowanie zasobów (dział finansów, IT, prawny i zarząd angażują się w wyjaśnianie sprawy kosztem pracy bieżącej).

Ryzyko prawne i zgodności: obowiązki, spory i odpowiedzialność

BEC 2.0 dotyka nie tylko „bezpieczeństwa”, ale też obowiązków formalnych. Skala ryzyka prawnego zależy od tego, co dokładnie zostało naruszone: środki finansowe, dane, a czasem również relacje umowne.

• Spory z kontrahentami (kto ponosi odpowiedzialność za zapłatę na niewłaściwy rachunek, naliczone odsetki, kary umowne).
• Ryzyko naruszenia poufności (jeśli atak był poprzedzony przejęciem korespondencji, mogło dojść do ujawnienia danych handlowych lub danych osobowych).
• Obowiązki raportowe i wewnętrzne postępowania (konieczność udokumentowania zdarzenia, decyzji i działań naprawczych).
• Ryzyko kontroli (audyt wewnętrzny/zewnętrzny, weryfikacja skuteczności kontroli finansowych i procedur zakupowych).

Skutki reputacyjne: utrata zaufania i „efekt mrożący”

W BEC 2.0 reputacja cierpi nawet wtedy, gdy firma odzyska pieniądze. Kluczowy problem to wrażenie, że organizacja nie ma kontroli nad płatnościami i kanałami komunikacji.

• Spadek zaufania dostawców (zaostrzenie warunków płatności, skrócenie terminów, przedpłaty).
• Niepewność klientów i partnerów (obawy o bezpieczeństwo rozliczeń, konieczność dodatkowych potwierdzeń).
• Ryzyko wewnętrzne (spadek morale, wzrost obaw przed podejmowaniem decyzji finansowych, „paraliż” akceptacji).
• Wizerunek pracodawcy (poczucie braku bezpieczeństwa procesów, presja i obciążenie zespołów).

Mapa skutków: co rośnie najszybciej po incydencie

Najważniejsza różnica między „klasycznym” błędem księgowym a BEC 2.0 polega na tym, że atak jest celowy i zaprojektowany tak, by wykorzystać presję czasu oraz autorytet (np. głos przełożonego). Dlatego skutki obejmują nie tylko bilans finansowy, ale też stabilność procesów i zaufanie do sposobu podejmowania decyzji płatniczych.

5. Proces weryfikacji płatności: zasada dwóch kanałów, limity, callback na znane numery

W BEC 2.0 (z użyciem deepfake audio i „idealnie” wyglądających faktur) kluczowe jest rozdzielenie prośby o płatność od potwierdzenia jej poprawności. Proces weryfikacji ma być prosty, powtarzalny i odporny na presję czasu: nawet jeśli wiadomość lub rozmowa brzmi wiarygodnie, płatność przechodzi dopiero po spełnieniu kilku warunków kontrolnych.

Zasada dwóch kanałów (two-channel verification)

Dwa kanały oznaczają potwierdzenie krytycznych danych (odbiorca, numer rachunku, kwota, termin, tytuł płatności) w kanale innym niż ten, w którym pojawiła się prośba. Celem jest przerwanie scenariusza, w którym atakujący kontroluje jedną ścieżkę komunikacji (np. skrzynkę e-mail lub numer telefonu użyty w wiadomości).

• Gdy prośba przyszła e-mailem → potwierdzenie telefoniczne (callback) lub w firmowym komunikatorze, ale do osoby/organizacji zweryfikowanej wcześniej.
• Gdy prośba przyszła telefonicznie (w tym deepfake) → potwierdzenie e-mailem na znany adres z katalogu lub przez system obiegu dokumentów.
• Gdy prośba przyszła komunikatorem → potwierdzenie telefoniczne na znany numer lub w innym niezależnym kanale.

Praktyczna zasada: „nie potwierdzamy w odpowiedzi na wiadomość i nie dzwonimy na numer podany w tej wiadomości” — do potwierdzeń używa się danych kontaktowych z zaufanego źródła (np. wewnętrzna książka kontaktów, zatwierdzona kartoteka dostawcy).

Callback na znane numery: krótka, odporna metoda potwierdzenia

Callback polega na oddzwonieniu do osoby po stronie kontrahenta lub do właściwego interesariusza po stronie wewnętrznej (np. właściciela budżetu) na znany, wcześniej zatwierdzony numer. Jest to szczególnie skuteczne przeciwko deepfake, bo eliminuje ryzyko, że rozmawiasz z głosem podszytym „na żądanie” w rozmowie inicjowanej przez atakującego.

• Oddzwaniaj wyłącznie na numer z wewnętrznej bazy / podpisanej umowy / wcześniej zweryfikowanej kartoteki.
• W rozmowie potwierdzaj konkret: nazwę odbiorcy, ostatnie 4 cyfry rachunku, kwotę, powód zmiany (jeśli dotyczy) oraz termin.
• Jeśli rozmówca naciska na skróty („nie ma czasu, potwierdź tu i teraz”) — traktuj to jako powód do eskalacji, nie do przyspieszenia.

Limity i progi weryfikacji: kiedy wystarcza minimum, a kiedy potrzebna eskalacja

Limity sprawiają, że proces jest proporcjonalny: nie każda płatność wymaga takiego samego „tarcia”, ale każda musi przejść minimalny zestaw kroków. Najczęściej stosuje się progi zależne od kwoty, ryzyka oraz rodzaju zmiany (np. zmiana rachunku).

„Kręgosłup” procesu: trzy krótkie pytania kontrolne

Aby proces był łatwy do zastosowania przez finanse i osoby akceptujące, warto przyjąć proste pytania, które uruchamiają dodatkowe kroki:

• Czy zmieniono dane płatnicze? (rachunek, beneficjent, kraj, waluta) → jeśli tak, uruchom dwa kanały + callback.
• Czy kwota przekracza próg? → jeśli tak, wymagana dodatkowa akceptacja i/lub callback.
• Czy kanał i ton komunikacji są nietypowe? (nagła pilność, prośba o poufność, „zrób to teraz”) → jeśli tak, wstrzymaj i eskaluj weryfikację.

Minimalny zapis weryfikacji (dla audytu i spójności)

Nawet prosta weryfikacja powinna zostawić ślad: kto potwierdził, kiedy, jakim kanałem i co dokładnie potwierdzono. To nie tylko porządek — to element odporności na BEC, bo utrudnia obchodzenie procesu „na gębę”.

• Data/godzina, osoba weryfikująca, kanał (telefon/e-mail/system), wynik (OK/odrzucone), zakres potwierdzonych danych.

// Przykładowy minimalny rekord (format dowolny, np. w systemie lub notatce)
{
  "payment_id": "...",
  "verified_by": "...",
  "verification_method": "callback_to_known_number",
  "confirmed": ["beneficiary", "iban_last4", "amount", "due_date"],
  "timestamp": "...",
  "outcome": "approved"
}

Tak ustawiony proces (dwa kanały + callback + limity) tworzy spójne „bezpieczne domyślne ustawienia” dla płatności: proste w rutynie, a jednocześnie trudne do obejścia w sytuacjach, które BEC 2.0 wykorzystuje najczęściej.

6. Kontrole i narzędzia: lista zaufanych rachunków, workflow akceptacji, monitoring zmian danych dostawcy

W BEC 2.0 skuteczne zabezpieczenia nie opierają się na jednej „magicznej” kontroli, tylko na zestawie prostych, powtarzalnych mechanizmów, które utrudniają wprowadzenie fałszywych danych do procesu płatności. Trzy filary to: lista zaufanych rachunków, workflow akceptacji oraz monitoring zmian danych dostawcy. Każdy z nich ogranicza ryzyko na innym etapie: od wprowadzania danych, przez akceptację, po wykrywanie anomalii.

Lista zaufanych rachunków (allow-list)

To kontrola, która sprowadza kluczowe pytanie do zera-jedynkowego: czy płatność idzie na rachunek, który już znamy i wcześniej zatwierdziliśmy? W praktyce chodzi o utrzymanie centralnej, kontrolowanej listy numerów rachunków przypisanych do konkretnych dostawców oraz waluty/kraju, a następnie blokowanie (lub kierowanie do weryfikacji) płatności poza listą.

• Zastosowanie: ograniczenie ryzyka „podmiany rachunku” w fakturze lub e-mailu, nawet jeśli dokument wygląda poprawnie.
• Kluczowy efekt: płatność na nowy rachunek staje się wyjątkiem wymagającym dodatkowego kroku, a nie „normalną” czynnością.
• Dobre praktyki narzędziowe: powiązanie listy z systemem finansowo-księgowym/ERP, wersjonowanie wpisów, audyt kto i kiedy dodał/zmienił rachunek.

Workflow akceptacji (zatwierdzanie wieloetapowe)

Workflow porządkuje to, kto może przygotować płatność, kto ją zatwierdza i w jakiej kolejności. Jego celem jest zmniejszenie ryzyka, że pojedyncza osoba „przepchnie” przelew na podstawie sfałszowanej prośby (np. deepfake audio lub pilny e-mail).

• Zastosowanie: przelewy o podwyższonym ryzyku (wysokie kwoty, nowy odbiorca, zmiana danych dostawcy, nietypowa waluta/kraj).
• Kluczowy efekt: rozdzielenie obowiązków (separation of duties) i stworzenie śladu audytowego decyzji.
• Narzędzia: moduły akceptacji w bankowości elektronicznej, ERP/workflow, systemy ticketowe, podpis elektroniczny dla zatwierdzeń.

Monitoring zmian danych dostawcy (vendor master data)

Wiele ataków BEC nie zaczyna się na etapie faktury, tylko wcześniej: od próby zmiany danych w kartotece dostawcy (np. numeru rachunku, adresu e-mail do faktur, danych kontaktowych). Monitoring ma wykrywać takie zdarzenia i traktować je jako sygnały wysokiego ryzyka.

• Zastosowanie: wykrywanie podejrzanych modyfikacji przed wykonaniem płatności oraz szybka reakcja, gdy w systemie pojawia się „nowe” konto.
• Co monitorować: zmiany numeru rachunku, dane kontaktowe, adres do korespondencji, domeny e-mail, częstotliwość i serię zmian, zmiany tuż przed terminem płatności.
• Narzędzia: logi zmian w ERP, alerty e-mail/SIEM, raporty dzienne zmian w kartotece, reguły DLP/antyphishing dla wiadomości z prośbami o zmianę danych.

Porównanie: co zabezpiecza i kiedy działa

Minimalny zestaw reguł, który daje szybki efekt

• Domyślnie płać tylko na rachunki z listy zaufanych; wyjątki wymagają formalnej akceptacji.
• Automatyczna eskalacja dla: nowego rachunku, zmiany rachunku w ostatnich dniach, płatności na nietypowy kraj/walutę, nietypowej kwoty.
• Codzienny/tygodniowy raport zmian w kartotece dostawców z obowiązkowym przeglądem przez inną osobę niż ta, która wprowadza zmiany.
• Nieusuwalny ślad audytowy: kto wprowadził zmianę, kto zatwierdził, z jakiego powodu i na podstawie jakiego zgłoszenia.

Te kontrole nie muszą być skomplikowane technologicznie, ale muszą być konsekwentnie egzekwowane w systemach, w których powstaje i zatwierdza się płatności oraz dane dostawców. Dzięki temu nawet przekonująca faktura lub wiarygodnie brzmiąca prośba nie wystarczy, by środki trafiły na konto atakującego.

Wzór procedury dla finansów: kroki, role i dokumentowanie weryfikacji

Poniższy wzór procedury ma ujednolicić sposób działania działu finansów przy zleceniach płatności oraz przy zmianach danych płatniczych dostawców. Kluczowe jest rozdzielenie ról, jednoznaczne „punkty stop” (kiedy płatność wstrzymać) oraz ślad audytowy pokazujący, kto, kiedy i na podstawie jakich informacji podjął decyzję.

Kroki procesu (od faktury do przelewu)

• Rejestracja dokumentu: przyjęcie faktury/żądania płatności i zapis w systemie z datą wpływu, kanałem otrzymania oraz danymi kontrahenta.
• Weryfikacja merytoryczna: potwierdzenie, że zakup/usługa były zamówione i odebrane, a kwota oraz warunki odpowiadają umowie lub zamówieniu.
• Weryfikacja danych płatniczych: sprawdzenie zgodności rachunku bankowego z danymi referencyjnymi (np. kartą dostawcy, umową, wcześniejszymi płatnościami). Jeśli rachunek jest nowy lub zmieniony — uruchomienie ścieżki „zmiana danych” i wstrzymanie płatności do czasu zakończenia weryfikacji.
• Ocena ryzyka transakcji: zastosowanie prostych kryteriów (np. kwota, nowy odbiorca, nietypowa waluta/kraj, pilność, nietypowy kanał). Wynik oceny decyduje o wymaganym poziomie akceptacji.
• Akceptacja płatności: zatwierdzenie przez osoby uprawnione zgodnie z progami i zasadą rozdziału obowiązków (inicjacja ≠ akceptacja ≠ wykonanie).
• Wykonanie przelewu: realizacja w bankowości elektronicznej przez osobę inną niż inicjująca/akceptująca (o ile to możliwe organizacyjnie) oraz zapis identyfikatora transakcji.
• Potwierdzenie i archiwizacja: dołączenie potwierdzenia przelewu do sprawy oraz zamknięcie zadania w systemie z kompletem dowodów weryfikacji.
• Obsługa wyjątków: jeśli pojawia się sprzeczność danych, presja czasu lub prośba o odstępstwo — uruchomienie eskalacji, udokumentowanie decyzji i utrzymanie blokady do czasu rozstrzygnięcia.

Ścieżka „zmiana danych płatniczych dostawcy”

Każda prośba o zmianę numeru rachunku, beneficjenta, adresu rozliczeniowego lub kanału fakturowania powinna być traktowana jako zdarzenie podwyższonego ryzyka. Minimalny wzór postępowania:

• Rejestracja wniosku o zmianę: zapis źródła (e-mail, portal, pismo), daty, zakresu zmiany i osoby zgłaszającej.
• Niezależne potwierdzenie: potwierdzenie zmiany u dostawcy poprzez kanał niezależny od wiadomości z wniosku (np. kontakt na numer z umowy lub z wcześniej zweryfikowanej bazy).
• Aktualizacja danych w systemie: wprowadzenie zmian przez osobę odpowiedzialną za bazę dostawców oraz wymóg drugiej autoryzacji (zasada „czterech oczu”).
• Okres przejściowy (jeśli stosowany): dodatkowa ostrożność przy pierwszej płatności na nowe dane, z pełnym potwierdzeniem i dodatkową akceptacją.
• Zamknięcie sprawy: zapis, kto potwierdził, jakim kanałem, kiedy i jakie dowody zostały dołączone.

Role i odpowiedzialności (RACI w praktyce, bez nadmiaru formalizmów)

• Osoba rejestrująca / AP (Accounts Payable): przyjmuje dokumenty, nadaje sprawie identyfikator, inicjuje weryfikacje i pilnuje kompletności załączników.
• Właściciel biznesowy / osoba merytoryczna: potwierdza zasadność kosztu, zgodność z umową/zamówieniem oraz odbiór towaru/usługi.
• Opiekun danych dostawcy (Vendor Master): odpowiada za tworzenie i zmianę danych kontrahenta w systemie oraz za prawidłowe udokumentowanie wniosków o zmianę.
• Akceptant finansowy: zatwierdza płatność zgodnie z progami i wynikiem oceny ryzyka; w razie wątpliwości inicjuje eskalację.
• Wykonawca płatności: realizuje przelew wyłącznie po spełnieniu warunków proceduralnych; wstrzymuje płatność przy brakach lub niespójnościach.
• Osoba eskalacyjna (np. kierownik finansów): podejmuje decyzje w sprawach wyjątkowych, zatwierdza odstępstwa i uruchamia działania następcze po incydencie.
• IT/Security (w roli wspierającej): wspiera analizę podejrzanych wiadomości/załączników i pomaga zabezpieczyć dowody w razie incydentu.

Dokumentowanie weryfikacji: co musi znaleźć się w śladzie audytowym

Dokumentacja ma umożliwić odtworzenie decyzji bez domysłów. Minimalny zestaw informacji w każdej sprawie:

• Identyfikator sprawy (numer w systemie) oraz powiązane dokumenty (faktura, zamówienie, umowa, protokół odbioru).
• Źródło i kanał otrzymania faktury/wniosku (np. e-mail, EDI, portal), data i godzina.
• Dane beneficjenta: nazwa, rachunek, waluta, kraj banku oraz informacja, czy rachunek był już używany i kiedy ostatnio weryfikowany.
• Wynik weryfikacji: krótka notatka „co sprawdzono” i „z czym porównano” (np. umowa, poprzednie płatności, karta dostawcy).
• Decyzje i akceptacje: kto zatwierdził, kiedy, w jakiej kolejności oraz na jakiej podstawie.
• Weryfikacja zmian (jeśli dotyczy): dowód niezależnego potwierdzenia (np. zapis kontaktu, notatka z rozmowy, potwierdzenie przez portal) oraz kto wprowadził i kto zatwierdził zmianę w systemie.
• Potwierdzenie wykonania: identyfikator transakcji bankowej i data realizacji.
• Odstępstwa i eskalacje: uzasadnienie, osoba decyzyjna, zakres odstępstwa i działania kompensujące.

Punkty stop i zasady odstępstw

Procedura powinna jasno wskazywać sytuacje, w których pracownik finansów ma obowiązek wstrzymać płatność do czasu wyjaśnienia:

• prośba o zmianę rachunku lub beneficjenta bez pełnego potwierdzenia,
• brak spójności między fakturą a danymi referencyjnymi,
• nietypowa pilność lub nacisk na „natychmiastowy przelew”,
• nietypowy kanał komunikacji w porównaniu do standardu współpracy,
• braki w dokumentach źródłowych (umowa/zamówienie/odbiór).

Odstępstwa od procedury powinny być rzadkie, czasowe i zawsze udokumentowane: kto je zatwierdził, dlaczego oraz jakie zabezpieczenia zastosowano zamiast standardowej weryfikacji.

8. Skrypty rozmów weryfikacyjnych: potwierdzenie płatności, zmiana danych dostawcy, eskalacja podejrzeń

Skrypty rozmów weryfikacyjnych mają jeden cel: zabezpieczyć decyzję o przelewie przed manipulacją (w tym deepfake audio) i przed zmianami danych, które mogą kierować środki do oszusta. Poniższe propozycje to krótkie, praktyczne wzory wypowiedzi do użycia w rozmowie telefonicznej lub wideorozmowie. Różnią się zastosowaniem: inne pytania zadaje się przy potwierdzeniu płatności, inne przy zmianie danych dostawcy, a jeszcze inne w sytuacji, gdy pojawiają się sygnały alarmowe i trzeba bezpiecznie przerwać proces.

Skrypt A: Potwierdzenie płatności (autoryzacja przelewu)

Kiedy używać: gdy ktoś prosi o pilny przelew, dopłatę, zaliczkę, rozliczenie końcowe lub „jednorazową” płatność poza standardowym rytmem. Skrypt ma potwierdzić, że zlecenie jest realne i zgodne z ustaleniami.

• Otwarcie i ramy rozmowy: „Dzwonię, aby potwierdzić dyspozycję płatności. Zanim przejdziemy dalej, zweryfikuję kilka informacji zgodnie z procedurą.”
• Weryfikacja kontekstu: „Jakiej sprawy dotyczy płatność: numer zamówienia/umowy, zakres i termin? Co jest podstawą do zapłaty?”
• Weryfikacja kwoty i waluty: „Proszę potwierdzić kwotę i walutę oraz czy płatność ma być jednorazowa czy w transzach.”
• Weryfikacja danych odbiorcy na poziomie ogólnym: „Na jaki odbiorca ma być płatność: nazwa podmiotu i kraj? Czy dane odbiorcy są identyczne jak w dotychczasowych rozliczeniach?”
• Wymuszenie spójności decyzji: „Kto zatwierdził tę płatność i z jakim uzasadnieniem biznesowym? Czy jest dokument potwierdzający (np. akceptacja, protokół, zamówienie)?”
• Zamknięcie: „Dziękuję. Przekażę do realizacji po zakończeniu weryfikacji zgodnie z naszymi zasadami.”

Wskazówka: jeśli rozmówca próbuje skrócić weryfikację („nie mamy czasu”, „to tajne”, „zrób teraz”), odpowiedź powinna być stała i neutralna: „Rozumiem pilność, jednak płatność uruchamiamy dopiero po pełnej weryfikacji.”

Skrypt B: Zmiana danych dostawcy (rachunek bankowy, adres e-mail, osoba kontaktowa)

Kiedy używać: przy prośbie o zmianę numeru rachunku, danych firmy, adresu do wysyłki faktur lub osoby uprawnionej do ustaleń. Skrypt ma wyłapać sytuacje, w których oszust „przejmuje” korespondencję i podstawia nowe dane.

• Otwarcie: „Dzwonię w sprawie prośby o zmianę danych dostawcy. Muszę potwierdzić zmianę rozmową weryfikacyjną.”
• Minimalny zakres potwierdzenia: „Jakie dane mają ulec zmianie dokładnie: rachunek, adres e-mail do faktur, adres siedziby, osoba kontaktowa?”
• Uzasadnienie zmiany: „Z jakiego powodu następuje zmiana i od kiedy ma obowiązywać? Czy dotyczy wszystkich przyszłych płatności?”
• Kontrola spójności: „Czy mogą Państwo potwierdzić, czy w ostatnim czasie występowały zmiany w finansach/księgowości lub w obsłudze płatności po Państwa stronie?”
• Ustalenie dalszych kroków: „Zanim zmiana zacznie obowiązywać, potrzebujemy potwierdzenia zgodnie z procedurą. Do czasu zakończenia weryfikacji rozliczamy się na dotychczasowych danych.”
• Zamknięcie: „Dziękuję. Po weryfikacji damy informację zwrotną i dopiero wtedy wprowadzimy zmianę.”

Wskazówka: w tym scenariuszu szczególnie ważne jest, by rozmowa odbyła się z użyciem ustalonego, zaufanego kontaktu, a nie numeru podanego w wiadomości lub na nowej fakturze. Samo „potwierdzenie e-mailem” nie powinno kończyć procesu.

Skrypt C: Eskalacja podejrzeń (presja czasu, nietypowy kanał, podejrzenie deepfake)

Kiedy używać: gdy pojawia się niepokój: nienaturalny ton głosu, prośba o poufność, nietypowa pora, nowy komunikator, sprzeczne informacje lub nacisk na obejście zasad. Celem jest przerwanie ryzykownej ścieżki bez wywoływania konfliktu i szybkie skierowanie sprawy do właściwej weryfikacji.

• Bezpieczne zatrzymanie procesu: „Zatrzymuję realizację do czasu pełnego potwierdzenia. To standard przy płatnościach i zmianach danych.”
• Przekierowanie na właściwy kanał: „Oddzwonię na numer, który mamy zapisany w kontaktach/umowie, aby potwierdzić dyspozycję.”
• Neutralne nazwanie ryzyka bez oskarżeń: „Mamy obowiązek wykluczyć próbę podszycia. To dotyczy wszystkich, niezależnie od stanowiska i pilności.”
• Minimalizacja informacji: „Na tym etapie nie mogę podać szczegółów przelewu ani danych, dopóki nie potwierdzimy tożsamości i podstawy płatności.”
• Eskalacja: „Przekazuję sprawę do osoby odpowiedzialnej za bezpieczeństwo/finanse w celu weryfikacji. Wrócimy z informacją po sprawdzeniu.”
• Zamknięcie rozmowy: „Dziękuję za zrozumienie. Skontaktujemy się ponownie oficjalnym kanałem.”

Wskazówka: w rozmowie podejrzanej trzymaj się krótkich, powtarzalnych formuł. Im mniej improwizacji, tym mniejsze ryzyko, że zostaniesz wciągnięty w presję, manipulację lub ujawnisz informacje, które ułatwią obejście kontroli.

Jak korzystać ze skryptów w praktyce

• Stosuj konsekwentnie: te same sformułowania dla każdej pilnej płatności i każdej zmiany danych — wtedy „wyjątek” staje się łatwo zauważalny.
• Trzymaj się faktów: pytaj o elementy transakcji i uzasadnienie, a nie o „zapewnienia” rozmówcy.
• Ogranicz ujawnianie danych: nie podawaj w rozmowie szczegółów, które ktoś mógłby wykorzystać do uwiarygodnienia podszycia.
• Kończ na procedurze: jeśli pojawia się presja lub agresja, wracaj do formuły: „Realizacja po weryfikacji.”

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Analiza przeżycia (survival) w biznesie: churn, retencja i ‘czas do zdarzenia’ krok po kroku 18 kwietnia 2026

RStudio: reproducible reports — Quarto vs R Markdown w zespołach analitycznych 16 kwietnia 2026