W Polsce jednym z trzech pierwszych i najważniejszych użytkowników systemu SWIFT jest Bank Handlowy w Warszawie SA.

Właśnie on zainaugurował w 1988 r. pierwsze polskie połączenia ze SWIFT. Jeszcze 2 lata temu w liczbie wszystkich polskich transakcji SWIFT-owych udział BH SA sięgał niemal 60%. Nic więc dziwnego, że przez prawie 5 lat w centrali BH SA znajdował się tzw. mini procesor regionalny stanowiący węzeł tej sieci dla 7 użytkowników. Ale zmiany w bankowości zachodzą teraz szybko. W grudniu 1991 r. podpisano umowę ze stowarzyszeniem SWIFT o zorganizowaniu w Polsce osobnego węzła, tzw. SAP (SWIFT Access Point). Węzeł taki, zlokalizowany w Centrum Radiokomunikacji i Telekomunikacji (CRiT) w Warszawie, został uruchomiony w grudniu 1992 r., a całkowicie przejął czynności węzła z BH SA w styczniu br. Łączność z SAP zapewniają polskim bankom dwie linie dzierżawione do Zoeterwowde pod Amsterdamem prowadzące via Kopenhaga, a zastępczo przez Pragę.

Liczba krajowych użytkowników SWIFT-u wzrasta niemal lawinowo. O ile w 1988 r. było ich w Polsce zaledwie 3 (BH SA, Narodowy Bank Polski i Pekao SA), to teraz jest już 27 -w tym 24 użytkowników tzw. "żywych" (rzeczywistych). Liczba zgłoszeń oczekujących na rozpatrzenie jest znacznie większa, ale bank, żeby zostać przyjętym do grupy użytkowników sieci, musi spełniać szereg wymogów formalnych, a także dysponować odpowiednim sprzętem. Obecnie sieci SWIFT używają m.in. Bank Depozytowo-Kredytowy w Lublinie, Bank Gospodarki Żywnościowej, Bank Turystyki, Bank Przemysłowo-Handlowy w Krakowie, Bank Zachodni, Creditanstalt, Kredyt Bank, Powszechny Bank Kredytowy, Powszechna Kasa Oszczędności BP, RCB, Societe Generale oraz Wielkopolski Bank Kredytowy. zczególnie duży wzrost liczby użytkowników odnotowano w ostatnich latach.

Komu SWIFT?

Na takie pytanie odpowiedź nie jest niestety łatwa. Nie zawsze bowiem sama dzienna liczba dyspozycji płatniczych decyduje o tym, czy podłączać bank do tej sieci. Czasem wrto zainstalować terminal SWIFT nawet dla 150 transakcji dziennie. Choć jest to niewiele, jeśli zważyć, że objętość przeciętnego komunikatu wynosi ok. 300 znaków. Ważne jest natomiast, jaki typ klientów wyraża zapotrzebowanie na transakcje SWIFT, jaka jest przewidywana wielkość obrotów międzynarodowych oraz zyski czasowe (a więc pieniężne), wynikające z zainstalowania drogiej bądź co bądź innowacji (minimalne inwestycje wynoszą ok. 80-100 tys. USD).

Żeby nowa instalacja była nieco mniej kosztowna warto pamiętać, że SWIFT jest tylko jedną z wielu aplikacji. Jeśli więc kupujemy określony sprzęt, który umożliwi uruchamianie tej aplikacji, to warto przemyśleć inwestycję tak, żeby na tym samym sprzęcie równolegle można było wykonywać inne czynności. Pozwoli to na efektywniejszą amortyzację wysokich nakładów. Dlatego jeśli kupujemy komputer, na którym będzie instalowane oprogramowanie do transmisji SWIFT, to warto zdobyć rozeznanie, jakie inne pożyteczne aplikacje są dostępne dla komputera tego typu. Innymi słowy należy przeprowadzić typową, a jakże często bagatelizowaną kalkulację projektową.

Wdrożenie

Samo techniczne zainstalowanie terminala SWIFT i uruchomienie tramsmisji jest stosunkowo proste, jeśli już użytkownik (bank) zapewnił sobie połączenie z SAP za pomocą dzierżawionych lub komutowanych linii lokalnych. Doświadczeni fachowcy robią to w nie więcej niż 2 dni.

Na prawdziwe wdrożenie systemu należy jednak rezerwować o wiele więcej czasu. Gros pracy to przeszkolenie ludzi w zakresie samej techniki, a także nabycie pewnych nawyków związanych ze świadomością ryzyka nieuchronnie związanego z przekazami prowadzonymi elektronicznie. Na pełny okres wdrożenia włącznie z wystąpieniem do Telekomunikacji Polskiej SA o stałe lub komutowane łącze do SAP i oczekiwaniem, należy przewidzieć o wiele więcej czasu: co najmniej 8-10 miesięcy.

Zabezpieczenia

Sieć SWIFT umożliwia sprawne przesłanie do bardzo odległych miejsc na świecie niemal dowolnych kwot pieniędzy wg ustalonych taryf opłat zależnych od rodzaju przesyłanego komunikatu. Anulowanie przesłanych komunikatów jest możliwe dopiero u adresata. Centrum Operacyjne SWIFT w Holandii czy USA, nie ingeruje w przesyłane dyspozycje, a jedynie nadaje im kolejne numery identyfikacyjne. Odzyskanie takich wiadomości o transakcji, czy jej anulowanie w Centrum SWIFT jest operacją płatną i to wysoko. Dlatego też pełna weryfikacja danych "wysyłanych w świat" musi się odbywać w miejscu ich emisji, tj. w banku. Istnieją szczegółowe zalecenia SWIFT co do organizacji nadawania elektronicznych przekazów finansowych.

Zabezpieczenia zaczynają się od uprawnień przebywania w pomieszczeniu z zainstalowanymi terminalami SWIFT. Dalej następuje co najmniej podwójne hasło wejścia do samej aplikacji SWIFT-u, a następnie cała kaskada kodów i szyfrów. Klucze kodowe służą do identyfikacji banku. Następną zaporę stanowią szyfry, dzięki którym informacja zostaje całkowicie utajniona. Zalecane przez stowarzyszenie SWIFT szwajcarskie urządzenia szyfrujące STEN (w cenie ok. 15 tys. USD) muszą się znajdować zarówno w banku, jak i w węzłach komunikacyjnych SAP. Urządzenia owe są zbudowane w ten sposób, że szyfrowaniu podlega pełen tekst komunikatu. Sam szyfr jest ustalany maszynowo, bez ingerencji człowieka, a podstawą do ustalania zarówno tablic szyfrów, jak i czasów ich obowiązywania odpowiadają generatory losowe. Dlatego nawet sami konstruktorzy tych maszyn nie są w stanie złamać ich szyfrów. Jak by tego było jeszcze mało, sieć SWIFT działa wg swojego własnego protokółu przekazywania danych, co niewątpliwie stanowi dodatkowe utrudnienie dla poszukiwaczy łatwych łupów.

Warstwę zabezpieczeń równie ważną jak szyfrowanie, stanowią rutynowe mechanizmy chroniące przed skutkami ludzkiego roztargnienia, a takżę zawodnością samego sprzętu i jego oprogramowania. Służy do tego m.in. backup transakcji SWIFT-owych na koniec dnia, czy wreszcie techniki minimalizacji prawdopodobieństwa awarii sprzętu, realizowane przez podwojenie zasadniczych elementów instalacji (komputerów, modemów, zasilania, itd.).

Wszystkie omówione zabezpieczenia są zalecane przez stowarzyszenie SWIFT. Są one traktowane bardzo poważnie zarówno przez wytwórców sprzętu, jak i użytkowników. Użytkownik, który nie dostosuje się do zaleceń musi się liczyć z mniejszym czy większym ryzykiem nieodwracalnych awarii, a nawet czasami brakiem obsługi w systemie SWIFT. Producenci oprogramowania SWIFT-owego i pracownicy SAP odmawiają np. pomocy telefonicznej (hot line), jeżeli sprawdzą, że użytkownik nie posiada podwójnej instalacji sprzętowej.

Sprzęt i oprogramowanie

Wiele polskich i zagranicznych systemów bankowych jest reklamowanych jako przystosowane do pracy z siecią SWIFT. Niestety ma to niewiele wspólnego z rzeczywistością, a już na pewno bardzo mało z zaleceniami stowarzyszenia SWIFT, dotyczących prowadzenia transakcji przez jego sieć. Modułom, w które jest wyposażona większość polskich banków, brak kompleksowości - mają szanse służyć jedynie do generacji przekazów SWIFT niektórych typów. Zaprojektowane są niestety bez spełnienia podstawowych wymogów co do ograniczenia dostępu przez osoby nieuprawnione. Niedopuszczalne są bowiem nierzadkie jeszcze aktualnie sytuacje, kiedy dyskietki z komunikatami SWIFT-owymi wędrują przez zbyt wiele rąk postronnych pracowników. Na generację całej gamy przekazów jedynie w sieci lokalnej, którą wędrują do akceptu na wydzielonym terminalu, na razie rodzimi twórcy nie zdobyli się.

Stowarzyszenie SWIFT homologowało kilkanaście aplikacji dla prowadzenia SWIFT-owych transakcji. Zalecany jest też określony sprzęt komputerowy, pochodzący od dostawców ze światowej czołówki producentów komputerów (por. ramka). Lista dostawców jest aktualizowana zapewne z niejakim opóźnieniem, o czym może świadczyć obecność Wanga - ongiś potentata, dziś chronionego przed wierzycielami przez przepisy amerykańskiej ustawy upadłościowej.

Oprogramowanie autorstwa belgijskiej STS (SWIFT Terminal Services) ST400 jest przeznaczone dla rodziny komputerów DEC pracujących pod systemem VMS, od najmniejszego VAX 3100 aż po największy w rodzinie VAX 10000. Analogiczne oprogramowanie STS ST200 działa na komputerach Unisys/Burroughs (B/38, B/39) pod systemem operacyjnym CTOS (dawniej również na komputerach produkowanych przez NCR). Stosunkowo rzadko już dzisiaj używana jest aplikacja ST500 przeznaczona dla wychodzących z użycia komputerów mainframe IBM Seria/1.

Innym przykładem oprogramowania aplikacyjnego SWIFT dla DEC VMS jest FASTWIRE (firmy Logica, W. Brytania) oraz STACHEM (francuskiej firmy Steria). Z kolei IBM opracował oprogramowanie Merva 2, które działa na IBM PS/2 (pod OS/2). Interesujące przejścia ze SWIFT-em odnotował Siemens- Nixdorf. Jego aplikacje pracujące pod Unixem utraciły homologację, bowiem stowarzyszenie SWIFT uznało, iż system operacyjny Unix nie zapewnia dostatecznych narzędzi do poawaryjnego odtwarzania danych. Są natomiast wysoko cenione środowiska, które na poziomie systemu operacyjnego zapewniają wysokie bezpieczeństwo danych. Dlatego dużo zyskują systemy: CTOS, OS/2 oraz VMS z shadowingiem, tj. systemowym podwojeniem (mirroringiem) dysków. Jak widać, są preferowane systemy zapewniające kontrolę równoległej pracy kilku aplikacji i nadzór nad dostępem użytkowników.