SWIFT

Przelewy SWIFT i komunikacja za pomocą komunikatów MT i MX

SWIFT (Society for Worldwide Interbank Financial Telecommunication) to bezpieczna sieć komunikacyjna, która umożliwia instytucjom finansowym, takim jak banki, wysyłanie i odbieranie ustandaryzowanych komunikatów dotyczących transakcji finansowych, na przykład dyspozycji płatniczych i potwierdzeń. SWIFT nie prowadzi rachunków ani nie przekazuje środków; zapewnia wyłącznie bezpieczną i niezawodną platformę wymiany informacji.

Standardowe przelewy SWIFT wykorzystują szereg znormalizowanych typów komunikatów, określanych jako komunikaty MT (Message Type). Mają one z góry zdefiniowane formaty i pola, dzięki czemu instytucje finansowe mogą łatwo odczytywać i przetwarzać zawarte w nich informacje.

Komunikaty MX (ISO 20022) to nowszy standard komunikatów finansowych oparty na XML (eXtensible Markup Language). Zapewniają one bogatszy i bardziej ustrukturyzowany format, umożliwiający rozszerzoną wymianę danych oraz usprawnione przetwarzanie typu straight-through. Komunikaty MX stopniowo zastępują komunikaty MT w sieci SWIFT, co ma zapewnić lepszą interoperacyjność i obsługę danych.

Choć tradycyjne przelewy SWIFT stanowią od dziesięcioleci fundament płatności międzynarodowych, mają one pewne ograniczenia, w tym ograniczoną przejrzystość, dłuższy czas przetwarzania oraz niestrukturyzowane dane.

Swift 103+ STP (Straight Through Processing – przetwarzanie w pełni automatyczne)

Swift 103+ STP było dawnym formatem MT zoptymalizowanym pod kątem przetwarzania w trybie Straight Through Processing (STP); od zakończenia okresu współistnienia jego rolę przejęły wytyczne dotyczące stosowania pacs.008 STP. STP umożliwia przeprowadzenie całego procesu płatności, od zainicjowania do ostatecznego rozliczenia, drogą elektroniczną bez konieczności ręcznej interwencji.

Dodatkowe funkcje:

1. Znormalizowany format: Wymaga ścisłego przestrzegania znormalizowanego formatu, co ogranicza liczbę błędów i opóźnień.
2. Przetwarzanie zautomatyzowane: Transakcje są przetwarzane automatycznie, co zapewnia szybszą i sprawniejszą obsługę.
3. Ograniczenie interwencji ręcznej: Ograniczona zostaje potrzeba ręcznego wprowadzania i weryfikacji danych, co zmniejsza ryzyko błędów i opóźnień.
4. Szybszy rozrachunek: Transakcje są rozliczane szybciej niż przy zastosowaniu tradycyjnych metod.

Kwestie do rozważenia w przypadku STP:

1. Prawidłowe wprowadzanie danych: Dane muszą być wprowadzane dokładnie, aby uniknąć opóźnień lub odrzucenia.
2. Zgodność z wymogami dotyczącymi formatu: Banki muszą zapewnić ścisłe przestrzeganie wymogów formatu 103+ STP.
3. Oprogramowanie i systemy: Banki muszą dysponować odpowiednim oprogramowaniem i systemami, aby skutecznie obsługiwać przetwarzanie STP

Należy odróżniać przesyłanie komunikatów od rozrachunku. SWIFT przekazuje ustrukturyzowane komunikaty finansowe między instytucjami, lecz sam nie przemieszcza środków ani nie przechowuje sald. Potwierdzenie SWIFT, w tym komunikat pacs.008, jest ważne wyłącznie wówczas, gdy odpowiada rzeczywistej transakcji przetworzonej i uzgodnionej w systemach bankowych instytucji uczestniczących.

Samodzielnego dokumentu SWIFT, zrzutu ekranu ani komunikatu przedstawionego bez weryfikacji instytucjonalnej nie należy traktować jako dowodu zakończonego rozliczenia.

Przelewy SWIFT gpi.

SWIFT gpi (Global Payments Innovation):

Zainicjowany w 2017 roku SWIFT gpi to inicjatywa mająca na celu przezwyciężenie ograniczeń tradycyjnych przelewów SWIFT poprzez zwiększenie szybkości, przejrzystości i identyfikowalności płatności transgranicznych. SWIFT gpi wykorzystuje istniejące formaty komunikatów MT i MX w celu usprawnienia usług płatniczych. Kluczowe cechy SWIFT gpi obejmują:

• Szybsze płatności: gpi upraszcza procesy i ustanawia ściślejsze umowy o poziomie usług (SLA) między bankami, co skutkuje krótszym czasem realizacji transakcji, często w ciągu minut lub sekund.
• Śledzenie płatności: gpi Tracker umożliwia śledzenie transakcji w czasie rzeczywistym, zwiększając przejrzystość i ograniczając ręczne postępowania wyjaśniające.
• Przejrzystość opłat: Banki mogą z góry przekazywać klientom informacje o opłatach transakcyjnych, co pozwala na podejmowanie lepiej przemyślanych decyzji.
• Bogatsze dane: gpi umożliwia wymianę bardziej szczegółowych i ustrukturyzowanych informacji, co ułatwia uzgadnianie rozliczeń oraz zapewnienie zgodności z wymogami regulacyjnymi.

SWIFT gpi eliminuje ograniczenia tradycyjnych przelewów SWIFT, usprawniając płatności transgraniczne dzięki śledzeniu transakcji od początku do końca, szybszemu przetwarzaniu i bogatszym danym.

Kluczowe parametry dla podmiotów nieuczestniczących w SWIFT gpi

Gdy podmiot niebędący uczestnikiem SWIFT gpi (np. bank lub instytucja finansowa niezarejestrowana bezpośrednio w gpi) przesyła dyspozycję płatniczą do banku będącego uczestnikiem gpi, bank gpi może przekształcić ją do wymaganych formatów komunikatów SWIFT (pacs.008 dla przelewów na rzecz klienta, pacs.009 COV dla przelewów pokrycia oraz pacs.009 dla przelewów między instytucjami finansowymi). Przekształcenie to umożliwia przetwarzanie i śledzenie w sieci gpi, pod warunkiem że dyspozycja zawiera dane wystarczające do wypełnienia pól obowiązkowych i spełnia zasady gpi, w tym zasadę pełnej identyfikowalności od początku do końca (end-to-end).

Uczestnicy niekorzystający z gpi zazwyczaj przekazują te parametry za pośrednictwem krajowych systemów płatniczych, interfejsów API lub formatów dotychczasowych, a bank korzystający z gpi uzupełnia je o elementy właściwe dla gpi (np. generuje UETR, jeśli nie został podany, choć jego przekazanie jest dla podmiotów niekorzystających z gpi opcjonalne). Dokładne wymogi mogą różnić się w zależności od jurysdykcji, waluty i umów dwustronnych, jednak podstawowe parametry wynikają z wytycznych CBPR+ (Cross-Border Payments and Reporting Plus) oraz standardów ISO 20022. Od zakończenia okresu współistnienia w dniu 22 listopada 2025 r. dyspozycje płatnicze w obrocie transgranicznym są wymieniane w formacie ISO 20022; odniesienia do pól MT podane poniżej mają charakter wyłącznie poglądowy.
1. Identyfikacja stron (dane dłużnika i wierzyciela)
Dane te identyfikują zleceniodawcę i beneficjenta, zapewniając zgodność z Zaleceniem FATF nr 16 dotyczącym wymogów tzw. travel rule.

• Dłużnik/Zleceniodawca: pełna nazwa, ustrukturyzowany adres (ulica, miasto, kod pocztowy, kraj) oraz identyfikacja rachunku (np. IBAN lub numer rachunku). W dawnych komunikatach MT 103/MT 202 COV odpowiada to polu 50a; w pacs.008/pacs.009 – elementom <Dbtr> i <DbtrAcct>.
• Wierzyciel/Klient beneficjent: pełne imię i nazwisko (nazwa), ustrukturyzowany adres oraz identyfikacja rachunku. Odpowiada polu 59a w dawnych komunikatach MT 103/MT 202 COV; elementom <Cdtr> i <CdtrAcct> w komunikatach pacs.008/pacs.009.
• Ostateczny dłużnik/wierzyciel (jeśli dotyczy): Jeżeli jest on inny niż główne strony, należy podać jego dane w celu zwiększenia przejrzystości (opcjonalnie, lecz zalecane dla śledzenia gpi). Odpowiada polom <UltmtDbtr>/<UltmtCdtr> w pacs.008/pacs.009.

Dlaczego jest to wymagane: Umożliwia prawidłowe kierowanie przelewów i kontrole regulacyjne; niekompletne dane mogą skutkować odrzuceniem lub opóźnieniem.

2. Informacje o agentach i trasowaniu
Określają instytucje finansowe uczestniczące w łańcuchu transakcji.

• Debtor Agent: BIC (Bank Identifier Code) lub inny identyfikator banku nadawcy. Odpowiada polu 52a w dawnym komunikacie MT 103; <DbtrAgt> w pacs.008/pacs.009.
• Bank wierzyciela: BIC banku odbiorcy. Odpowiada polu 57a w dawnych komunikatach MT 103/MT 202 COV; <CdtrAgt> w pacs.008/pacs.009.
• Agenci pośredniczący (jeżeli są znani): kody BIC wszelkich korespondentów (do 3 poziomów). Odpowiada polu 56a w dawnym komunikacie MT; <IntrmyAgt1-3> w pacs.008/pacs.009.
• Instructing/Instructed Agents: kody BIC bezpośredniego nadawcy/odbiorcy w łańcuchu. Pole opcjonalne, ułatwia rozliczenia metodą szeregową lub z pokryciem (cover).
• Poprzedni agenci przekazujący instrukcje (jeśli dotyczy): W przypadku łańcuchów wieloetapowych — do 3 poprzednich agentów.

Dlaczego wymagane: Zapewnia prawidłowe kierowanie przez pośredników; w pacs.009 COV należy używać BICFI zamiast nazw, aby zachować precyzję.

3. Szczegóły transakcji
Podstawowe elementy finansowe służące rozliczeniu.

• Kwota i waluta: Kwota rozliczenia międzybankowego oraz kod waluty ISO 4217 (np. USD, EUR). Odpowiada polu 32A dawnych komunikatów MT 103/MT 202 COV; <IntrBkSttlmAmt> w komunikatach pacs.008/pacs.009.
• Kwota zlecona (jeśli inna): Kwota pierwotna przed potrąceniami.
• Interbank Settlement Date (data rozrachunku międzybankowego): Data waluty rozrachunku. Odpowiada części pola 32A w MT; <IntrBkSttlmDt> w pacs.008/pacs.009.
• Metoda rozrachunku: należy wskazać, czy odbywa się przez RTGS (CLRG), pokrycie (COVE) czy agenta (INDA/INGA). Brak bezpośredniego odpowiednika w MT, lecz wynika to z kontekstu.

Dlaczego jest wymagane: Określa przedmiot przekazania wartości; obowiązkowe dla wszystkich formatów.

4. Identyfikatory referencyjne i śledzące
Zapewniają identyfikowalność, w szczególności w gpi.

• Identyfikator end-to-end: odniesienie łączące cały łańcuch (np. numer faktury lub identyfikator transakcji). <EndToEndId> w pacs.008/pacs.009.
• Identyfikator instrukcji: odniesienie nadawcy (ograniczone do 16 znaków w MT). Odpowiada polu 20 w dawnym formacie MT; <InstrId> w pacs.008/pacs.009.
• Unique End-to-End Transaction Reference (UETR): identyfikator UUID służący do śledzenia transakcji od początku do końca. Jest obowiązkowy w komunikatach pacs.008/pacs.009 oraz, w dawnych komunikatach MT 103/MT 202, w polu 121; jeżeli kanał inicjujący go nie dostarcza, generuje go pierwszy bank w łańcuchu korzystający z sieci Swift.
• Identyfikacja transakcji: Dodatkowy numer referencyjny wewnętrzny.

Dlaczego jest wymagane: Umożliwia śledzenie i powiązywanie w ramach gpi (np. pacs.008 z pacs.009 COV); UETR jest kluczowy dla uniwersalnych potwierdzeń.

5. Cel płatności i informacje o usłudze
Określa rodzaj płatności.

• Kody celu i kategorii celu: kody ISO (np. SALA dla wynagrodzenia) wskazujące charakter transakcji. Wymagane na niektórych korytarzach płatniczych; <Purp> i <CtgyPurp> w komunikacie pacs.008.
• Kod poziomu usługi: Identyfikuje usługę gpi (np. G001 dla przelewu kredytowego klienta gpi); banki niekorzystające z gpi nie powinny podawać kodów właściwych dla gpi, chyba że uzgodniono inaczej. Odpowiada polu 23E w MT; <SvcLvl> w pacs.008/pacs.009.
• Local Instrument Code: Dla określonych schematów (np. przelewów wewnątrzgrupowych).

Dlaczego jest to wymagane: zapewnia zgodność z przepisami oraz pierwszeństwo przetwarzania; po migracji do ISO coraz częściej jest obowiązkowe.

6. Przekazy i dodatkowe instrukcje

• Informacje o płatności (Remittance Information): Niestrukturyzowane (do 140 znaków) lub strukturyzowane (np. dane faktury). Odpowiada polu 70 w dawnym MT 103; <RmtInf> w pacs.008/pacs.009.
• Instrukcje dla agentów: Np. /REC/ dla odbiorcy, /ACC/ dla rachunku lub instrukcje telefoniczne (PHOB). Odpowiada polu 72 w dawnym komunikacie MT; <InstrForNxtAgt>/<InstrForCdtrAgt> w pacs.008/pacs.009.
• Wskaźniki czasu rozliczenia: Żądane terminy (np. CLSTm dla czasu CLS).

Dlaczego jest wymagane: Zapewnia kontekst i instrukcje dotyczące obsługi; niezbędne dla metod pokrycia w pacs.009 COV.

7. Dane regulacyjne i dotyczące compliance

• Raportowanie regulacyjne: Kody lub dane szczegółowe (np. numer identyfikacji podatkowej, wskaźnik raportowania taki jak CRED/DEB). Odpowiada polu 77B w MT oraz elementowi <RgltryRptg> w pacs.008/pacs.009.
• Kody przyczyn zwrotu (w stosownych przypadkach): Np. AC04 dla rachunku zamkniętego, w komunikacie pacs.004 powiązanym z komunikatami pierwotnymi.

Dlaczego jest to wymagane: Spełnia obowiązki w zakresie AML/KYC i sprawozdawczości; obowiązkowe w regulowanych korytarzach płatniczych.

Zgodnie z dobrymi praktykami uczestnicy niekorzystający z gpi powinni tak ustrukturyzować dane, aby uniknąć ich obcięcia podczas konwersji MT na MX, oraz skonsultować szczegółowe potrzeby z bankiem uczestniczącym w gpi. Jeżeli płatność obejmuje metody cover, dane klientów transakcji bazowej muszą być identyczne we wszystkich komunikatach (np. od pacs.008 do pacs.009 COV).

Komunikaty płatnicze w SWIFT gpi

W ramach SWIFT gpi (Global Payments Innovation) pierwotne komunikaty płatnicze (np. pacs.008 dla przelewów klientowskich lub pacs.009 COV dla przelewów pokrycia) są uznawane za niezmienne po ich wysłaniu. Bank odbiorcy nie może bezpośrednio zmieniać ani modyfikować treści tych komunikatów, ponieważ komunikaty SWIFT zaprojektowano tak, aby zachować integralność i możliwość audytu w całym łańcuchu płatności. Wszelkie zmiany, korekty lub anulowania są realizowane za pomocą odrębnych komunikatów następczych, aktualizacji statusu w gpi Tracker lub dedykowanych usług, takich jak gSRP (gpi Stop and Recall Payment). Zapewnia to pełną identyfikowalność dzięki unikalnemu referencyjnemu numerowi transakcji end-to-end (UETR).

Banki odbiorcze (zazwyczaj działające jako agent wierzyciela lub pośrednik) mogą jednak odpowiadać na wnioski nadawcy o zmianę lub podejmować działania, które faktycznie prowadzą do modyfikacji wyniku płatności (np. zwroty lub wstrzymania). Mogą też w określonych warunkach zwracać się do nadawcy o wyjaśnienia lub zmiany. Procesy te podlegają regułom SWIFT, wytycznym dotyczącym praktyki rynkowej (np. opracowanym przez Payments Market Practice Group – PMPG) oraz wymogom regulacyjnym, przy czym priorytetem są automatyzacja, przejrzystość i zapobieganie nadużyciom.

Warunki, na jakich bank otrzymujący może żądać zmian lub je umożliwiać
Banki otrzymujące mogą żądać zmian (np. korekty danych) lub podejmować działania sugerujące potrzebę zmiany, gdy pierwotna płatność nie może zostać zrealizowana zgodnie z instrukcją. Odbywa się to zazwyczaj za pośrednictwem komunikatów zapytań (np. MT 195/199) lub odpowiedzi na żądania zainicjowane przez nadawcę. Do kluczowych warunków należą:

• Błędy w danych płatności: W razie nieścisłości, takich jak nieprawidłowy rachunek beneficjenta (np. rachunek zamknięty – kod AC04), błędna waluta (kod CURR), nieprawidłowe wskazanie agenta w ścieżce płatności (kod AGNT) lub problemy techniczne (kod TECH), bank odbiorcy może wstrzymać płatność i zażądać od nadawcy przekazania poprawionych danych lub wysłania nowej płatności. Pozwala to uniknąć jej całkowitego odrzucenia, umożliwiając jednocześnie wyjaśnienie sprawy.
• Brak możliwości zaksięgowania płatności: Zgodnie z kodem CUTA (Cancel Upon Unable to Apply), jeżeli płatność nie może zostać zaksięgowana z powodu niezgodności (np. rozbieżności nazwy lub rachunku albo niewystarczających danych), bank odbiorcy może zażądać od nadawcy anulowania lub szczegółów korekty w celu usunięcia nieprawidłowości.
• Podejrzenie nadużycia lub nieautoryzowanych transakcji: W przypadku nadużycia (kod FRAD) bank odbiorcy może samodzielnie wykryć nieprawidłowości i zainicjować zwrot środków bez uprzedniego wniosku nadawcy. Może również odpowiedzieć na wniosek nadawcy o odwołanie płatności, blokując środki i żądając zabezpieczenia odszkodowawczego (kod INDM), jeżeli środki zostały już zaksięgowane, aby ograniczyć ryzyko przed dokonaniem zwrotu.
• Płatności zduplikowane lub nienależne: Kody takie jak DUPL (płatność zduplikowana) lub UPAY (płatność nienależna) umożliwiają bankowi odbiorcy oznaczenie transakcji i zażądanie jej anulowania, jeżeli została dokonana błędnie lub bez podstawy.
• Kwestie regulacyjne lub dotyczące zgodności: Jeżeli płatność narusza lokalne przepisy, sankcje lub wymogi AML (kod LEGL), bank odbiorcy może ją odrzucić lub wstrzymać i zażądać od nadawcy dodatkowej dokumentacji lub korekt.
• Decyzje klienta lub beneficjenta: Jeżeli beneficjent odmawia przyjęcia płatności (kod CUST lub NOAS – brak odpowiedzi od beneficjenta), bank odbiorcy może zwrócić płatność i powiadomić nadawcę, ewentualnie prosząc o potwierdzenie zmian.
• Sprawy oczekujące na rozstrzygnięcie: W przypadku spraw oczekujących (kod PDCR), takich jak oczekiwanie na upoważnienie do obciążenia rachunku (RQDA) lub na odpowiedź kolejnego agenta (PTNA), bank otrzymujący może wstrzymać płatność i zwrócić się o dalsze instrukcje lub zmiany niezbędne do jej realizacji.

We wszystkich przypadkach wnioski muszą być ustrukturyzowane w sposób umożliwiający automatyzację (np. zawierać UETR, oryginalne odniesienia, takie jak pola 20/32A/50/59, oraz określone kody w polu 79 komunikatów), aby wspierać przetwarzanie typu straight-through. W przypadku uznania rachunku środkami może być wymagane zawarcie dwustronnych umów odszkodowawczych, a bank odbiorcy nie ma obowiązku przyjmowania wniosków, jednak musi nadawać priorytet wnioskom pilnym (np. związanym z oszustwem).

Zaangażowane procesy

• Odpowiedź na wezwania do zwrotu inicjowane przez nadawcę: Nadawca (bank dłużnika) zazwyczaj inicjuje wezwanie do zwrotu za pomocą MT 192/292 (lub odpowiedników ISO 20022, takich jak camt.056) za pośrednictwem usługi gSRP, przesyłane kolejno lub bezpośrednio do banku odbiorcy. Bank odbiorcy musi niezwłocznie potwierdzić odbiór i odpowiedzieć za pomocą MT 196/296 (lub MT 199/299, jeśli komunikat jest ustrukturyzowany), stosując kody takie jak CNCL (anulowano), RJCR (odrzucono z podaniem przyczyny) lub PDCR (w toku). W przypadku akceptacji środki są zwracane za pomocą pacs.004 (zwrot płatności).
• Niezależne działania banków odbierających: W przypadku wykrycia nadużycia wewnątrz banku odbierającego może on zwrócić środki za pomocą komunikatu pacs.004 ze szczegółowymi, ustrukturyzowanymi informacjami, powiadamiając o tym za pośrednictwem Trackera, co umożliwia bieżącą aktualizację statusu.
• Wnioski o zmianę lub wyjaśnienie: banki odbiorcze wykorzystują komunikaty zapytań (np. MT 195/295) w celu wystąpienia o zmiany, takie jak uzupełnienie szczegółów. Jest to częste w przypadku płatności wstrzymanych.
• Integracja z Trackerem: Wszystkie działania są aktualizowane w czasie rzeczywistym w gpi Tracker, dostępnym za pośrednictwem interfejsów API lub GUI, co zapewnia widoczność dla wszystkich stron. Członkowie gpi muszą przestrzegać obowiązkowych zbiorów zasad dla gCCT (Customer Credit Transfer), gCOV (Cover) i gSRP.
• Ograniczenia i czynniki powodzenia: Zmiany nie są gwarantowane; powodzenie zależy od etapu płatności (łatwiej przed uznaniem rachunku), współdziałania beneficjenta oraz jurysdykcji. W przypadku uznania rachunku zwrot wymaga zgody beneficjenta lub zobowiązania do zwolnienia z odpowiedzialności. Przepisy prawa zawsze mają pierwszeństwo przed wytycznymi.

Praktyki te dotyczą przede wszystkim członków gpi, ale banki niebędące członkami gpi mogą uczestniczyć za pośrednictwem bramek (gateways). Aktualne szczegóły należy sprawdzać w oficjalnych regulaminach SWIFT, ponieważ procesy ulegają zmianom (np. w związku z migracją do ISO 20022).

Rozdzielenie komunikatów i rozrachunku w SWIFT gpi

SWIFT gpi obsługuje przede wszystkim dyspozycje płatnicze i ich śledzenie za pośrednictwem komunikatów (np. formaty ISO 20022, takie jak pacs.008 dla przelewów klientowskich, pacs.009 dla przelewów finansowych, lub starsze MT 103/MT 202), natomiast faktyczny przepływ środków następuje oddzielnie, na poziomie rozrachunku. Rozrachunek odbywa się zazwyczaj w ramach relacji bankowości korespondencyjnej (rachunki nostro/vostro), kompensaty dwustronnej lub mechanizmów rozliczeniowych i rozrachunkowych (CSM), takich jak systemy rozrachunku brutto w czasie rzeczywistym (RTGS) (np. T2, dawniej TARGET2, w Europie, Fedwire w USA lub CHAPS w Wielkiej Brytanii). Moduł gpi Tracker zapewnia wgląd w status komunikatu w czasie rzeczywistym, jednak transfer środków opiera się na tych podstawowych systemach.

Okres współistnienia dla transgranicznych poleceń płatniczych zakończył się 22 listopada 2025 r.: polecenia płatnicze, takie jak MT103 i MT202, zostały zastąpione komunikatami ISO 20022 (MX), takimi jak pacs.008 i pacs.009, natomiast pozostałe kategorie MT są wycofywane w późniejszych terminach. Poniżej wyjaśniono, w jaki sposób zwroty i zwolnienia blokad następują na poziomie rachunku, rozliczeń i rozrachunku.

Sposób zwrotu środków na poziomie rachunku, rozliczeń i rozrachunku
Zwroty są inicjowane po pomyślnym złożeniu wniosku o odwołanie (za pośrednictwem usługi gSRP – gpi Stop and Recall Payment) lub po niezależnym wykryciu nieprawidłowości (np. oszustwa, błędów). Usługa gSRP wykorzystuje komunikat camt.056 (Payment Cancellation Request) przesyłany przez nadawcę, na który odpowiada się komunikatem camt.029 (Resolution of Investigation). Po zaakceptowaniu zwrot środków jest realizowany za pomocą nowej dyspozycji płatniczej, która odwraca przepływ, obciążając rachunek banku odbiorcy i uznając rachunki w całym łańcuchu. Nie jest to zmiana pierwotnego komunikatu, lecz odrębna transakcja.

Główne metody rozliczeń i procesy zwrotów
Metody rozliczeń określają sposób dokonywania zwrotów:

• CLRG (rozliczenie za pośrednictwem infrastruktury rynkowej): Rozrachunek za pośrednictwem systemu RTGS lub CSM (np. za pośrednictwem banku centralnego). Zwroty wykorzystują komunikat pacs.004, zawierający polecenie dla infrastruktury rynkowej obciążenia rachunku agenta odbierającego i uznania rachunku poprzedniego agenta, często w czasie rzeczywistym lub w tym samym dniu.
• INGA (Instructing Agent Settles First): Nadawca rozlicza środki przed wysłaniem komunikatu. Zwroty za pośrednictwem pacs.004 obciążają rachunek instytucji wykonującej dyspozycję po rozrachunku.
• INDA (Instructed Agent Settles on Receipt): Odbiorca dokonuje rozrachunku po otrzymaniu komunikatu. Jeżeli rozrachunek nie nastąpi, komunikat odrzucany jest za pomocą pacs.002 (środki nie są przesuwane); jeżeli rozrachunek nastąpił, zwrot realizowany jest za pomocą pacs.004.
• COVE (metoda pokrycia): Stosowana w przypadku płatności o wysokiej wartości z przelewem pokrycia (pacs.009 COV). Zwroty przebiegają odwrotnym łańcuchem: pacs.004 od banku beneficjenta z powrotem do banków pośredniczących, z odpowiednim obciążeniem i uznaniem rachunków korespondentów.

Procedura zwrotu krok po kroku na poziomie rozrachunku

1. Inicjowanie i akceptacja: Nadawca składa wniosek o zwrot (np. za pomocą camt.056 z UETR). Odbiorca odpowiada (camt.029) i akceptuje wniosek, jeżeli środki są dostępne lub nie zostały jeszcze uznane na rachunku beneficjenta (łatwiej przed uznaniem). Jeżeli środki zostały już uznane, może być wymagana zgoda beneficjenta lub zobowiązanie odszkodowawcze.

2. Instrukcja zwrotu środków: odbiorca wystawia komunikat pacs.004 (Payment Return) lub dotychczasowy MT 103/MT 202 z kodami zwrotu (np. RETN). Komunikat ten zawiera:

• Oryginalne odniesienia (UETR, End-to-End ID, Instruction ID).
• Odwrócone role: dotychczasowy wierzyciel staje się dłużnikiem, a dotychczasowy agent dłużnika staje się wierzycielem.
• Szczegóły rozrachunku: pierwotna kwota i data rozrachunku międzybankowego, kurs wymiany (jeśli występuje wymiana walut), opłaty (jeśli zostały potrącone).
• Kod przyczyny zwrotu (np. AC04 dla zamkniętego rachunku, FRAD dla oszustwa).
• Pole Settlement Account (jeżeli występuje w pierwotnym komunikacie) służące wskazaniu rachunku do uznania.

3. Realizacja rozliczenia:

• Komunikat pacs.004 powoduje obciążenie rachunku nostro/vostro banku odbierającego (prowadzonego u poprzedniego agenta lub MI).
• Środki są uznawane wstecz, krok po kroku, wzdłuż całego łańcucha, przy użyciu tej samej metody rozrachunku (np. przelewu RTGS w CLRG).
• W przypadku zwrotu częściowego należy wpisać „PART” w polu Additional Information wraz z proporcjonalnie obliczoną kwotą.
• Tracker aktualizuje status (np. „Zwrócono”) w czasie rzeczywistym, widoczny za pośrednictwem API lub interfejsu graficznego.

4. Ostateczne uznanie rachunku: Rachunek pierwotnego nadawcy zostaje uznany, często po potrąceniu opłat. W przypadku rozliczenia za pośrednictwem CSM rozrachunek ma charakter atomowy; w układach dwustronnych może obejmować kompensowanie (netting) na koniec dnia.

5. Powiadomienia po zwrocie: Należy użyć komunikatów camt.053/054 (wyciąg z rachunku / powiadomienie o obciążeniu lub uznaniu), aby potwierdzić aktualizację ksiąg. Nie stosuje się kolejnego pacs.004 w celu „zwrotu zwrotu”: w takim przypadku należy użyć zapytań.
Zwroty są w miarę możliwości zautomatyzowane, jednak w przypadku wymogów zgodności lub zablokowania środków może być konieczna interwencja ręczna. Odzyskanie środków nie jest gwarantowane; zależy przede wszystkim od tego, jak szybko wysłano wezwanie do zwrotu oraz czy środki zostały już zaksięgowane. Jeżeli rozrachunek nie nastąpił (np. odrzucenie przed rozrachunkiem), środki nie są przemieszczane: należy wówczas użyć komunikatu pacs.002.

W jaki sposób wstrzymane płatności są zwalniane (akceptowane) na poziomie rachunku, clearingu i rozrachunku

Wstrzymanie (hold) ma miejsce, gdy płatność nie może zostać natychmiast przetworzona (np. z powodu błędów, kontroli zgodności lub oczekiwania na wyjaśnienia), co powoduje przejście w stan „oczekujący” bez rozliczenia. Do czasu rozstrzygnięcia nie następuje obciążenie ani uznanie środków. Narzędzie gpi Tracker wyświetla statusy takie jak „On Hold” lub „Pending” (np. kod PDCR), a wyjaśnienie następuje za pomocą komunikatów zapytań (MT 195/199 lub camt.029).

Okoliczności prowadzące do blokad

• Niezgodności (np. rozbieżność między rachunkiem a nazwą – kod CUTA).
• Kontrole regulacyjne (np. sankcje – kod LEGL).
• Oczekiwanie na odpowiedź beneficjenta (kod NOAS) lub upoważnienie do obciążenia (RQDA).
• Godziny niedostępności lub przetwarzanie wsadowe w banku beneficjenta.

Proces zwolnienia na poziomie rozrachunku
1. Powiadomienie o wstrzymaniu: Odbiorca wysyła pacs.002 (aktualizacja statusu) lub MT 199 z kodem oczekiwania, wstrzymując środki na rachunku przejściowym/escrow, jeżeli rozrachunek został zrealizowany częściowo (np. w metodach cover).
2. Rozstrzygnięcie: Nadawca przekazuje poprawki/wyjaśnienia (np. w odpowiedzi MT 195 lub camt.029). Po rozstrzygnięciu odbiorca „daje zielone światło”, przetwarzając pierwotną instrukcję.
3. Realizacja rozrachunku:

• Oryginalny komunikat pacs.008/pacs.009 zostaje zwolniony z blokady.
• Środki są rozliczane wskazaną metodą: obciążenie rachunku nadawcy, uznanie rachunku odbiorcy (np. za pośrednictwem RTGS w CLRG), a następnie ostateczne uznanie rachunku beneficjenta.
• Etap po stronie beneficjenta (od banku odbiorcy do klienta końcowego) jest często miejscem, w którym dochodzi do opóźnień, szczególnie na rynkach z kontrolą przepływów kapitałowych lub ograniczoną infrastrukturą.
• Status w trackerze zmienia się na „Credited” lub „Completed”, a komunikat pacs.002 (Payment Status Report) to potwierdza.

4. W przypadku niezwolnienia środków: Jeżeli sprawa pozostaje nierozstrzygnięta (np. po upływie terminu), należy dokonać zwrotu za pomocą pacs.004, jak wyżej, albo odrzucić transakcję za pomocą pacs.002 (bez rozrachunku).

Zasady gpi wymagają, w miarę możliwości, uznania rachunku tego samego dnia; według danych Swift z 2018 r. niemal 50% płatności gpi zostało uznanych w ciągu 30 minut, a prawie 100% w ciągu 24 godzin. Czynniki takie jak kontrola przepływu kapitału czy godziny, w których bank nie pracuje, mogą wydłużyć okres wstrzymania środków, jednak gpi stawia na automatyzację, aby go ograniczyć.

SwiftNet Instant

SwiftNet Instant. Jest to platforma komunikacyjna działająca w czasie rzeczywistym, o niskich opóźnieniach, dostępna 24/7, która wspiera bezpieczną wymianę przepływów płatności natychmiastowych pomiędzy mechanizmami rozliczeniowymi i rozrachunkowymi (CSM) a ich uczestnikami.

Klienci mogą łączyć się z SwiftNet Instant za pośrednictwem posiadanej infrastruktury łączności i bezpieczeństwa Swift, w tym urządzeń VPN, łączy dzierżawionych i modułów sprzętowych do zabezpieczeń kryptograficznych (HSM). Integrację ze środowiskiem informatycznym banku zapewnia Alliance Gateway Instant (AGI).

Wszystkie strony uczestniczące w łańcuchu płatności natychmiastowych mogą korzystać z komunikatów AGI i SwiftNet Instant. Zastosowania obejmują inicjowanie płatności za pośrednictwem usługi nakładkowej, komunikację uczestnika pośredniego z uczestnikiem sponsorującym lub otrzymanie przez przedsiębiorstwo potwierdzenia płatności.

SWIFT Instant łączy się z krajowymi systemami płatności natychmiastowych, umożliwiając przetwarzanie transakcji w czasie rzeczywistym, zarówno w kraju, jak i za granicą, z wykorzystaniem standardu ISO 20022. Systemy te stanowią element trwających działań na rzecz modernizacji i uproszczenia procesów płatniczych w sektorze finansowym.

SWIFT Direct Debit

Polecenie zapłaty w systemie SWIFT to metoda płatności umożliwiająca przedsiębiorstwom i osobom fizycznym pobieranie środków z rachunków bankowych dłużników w wielu walutach i w różnych państwach. W odróżnieniu od polecenia zapłaty SEPA, które zostało zaprojektowane specjalnie dla obszaru SEPA i jest ograniczone do transakcji denominowanych w euro, polecenie zapłaty w systemie SWIFT ma zasięg globalny i obsługuje szeroki zakres walut.

Proces inicjowania transakcji polecenia zapłaty w systemie SWIFT obejmuje zazwyczaj następujące etapy:

1. Umowa między wierzycielem a dłużnikiem: Wierzyciel i dłużnik muszą mieć uprzednio zawartą umowę określającą warunki transakcji polecenia zapłaty. Umowa ta może również obejmować ustanowienie mandatu lub upoważnienia, umożliwiającego wierzycielowi pobieranie płatności z rachunku bankowego dłużnika.
2. Wymiana komunikatów: Bank wierzyciela inicjuje polecenie zapłaty, wysyłając do banku dłużnika komunikat SWIFT – w standardzie ISO 20022 jest to pacs.003 (polecenie zapłaty klienta) lub pacs.010 (polecenie zapłaty instytucji finansowej), dawniej MT 104 lub MT 204. Komunikat ten zawiera szczegóły transakcji, takie jak kwota, waluta, dane rachunku dłużnika oraz wszelkie inne niezbędne informacje.
3. Weryfikacja i autoryzacja: Bank dłużnika weryfikuje szczegóły transakcji, sprawdza dostępność środków na rachunku dłużnika oraz potwierdza autoryzację transakcji. Jeżeli wszystko jest w porządku, bank dłużnika obciąża rachunek dłużnika kwotą transakcji.
4. Przekaz środków: środki są rozliczane między bankiem dłużnika a bankiem wierzyciela za pośrednictwem rachunków korespondenckich lub systemu rozliczeniowego i rozrachunkowego.
5. Potwierdzenie: po otrzymaniu środków bank wierzyciela przesyła wierzycielowi potwierdzenie, informując go o pomyślnym zrealizowaniu polecenia zapłaty.

Warunki wstępne zainicjowania transakcji polecenia zapłaty w systemie SWIFT są następujące:

1. Rachunki bankowe: Zarówno wierzyciel, jak i dłużnik muszą posiadać rachunki bankowe w instytucjach finansowych należących do sieci SWIFT.
2. Umowa i upoważnienie: aby można było realizować transakcje polecenia zapłaty, między wierzycielem a dłużnikiem musi istnieć uprzednia umowa i upoważnienie (mandat).
3. Formaty komunikatów SWIFT: Wierzyciel i jego bank muszą stosować właściwe formaty komunikatów: pain.008 do zainicjowania polecenia zapłaty, pacs.003 lub pacs.010 pomiędzy bankami.
4. Opłaty bankowe: Wierzyciel i dłużnik powinni mieć świadomość wszelkich opłat związanych z transakcjami polecenia zapłaty w systemie SWIFT, ponieważ opłaty te mogą się różnić w zależności od banków i krajów uczestniczących w transakcji.

RMA w międzybankowej komunikacji SWIFT

W bankowości i finansach bezpieczna i sprawna komunikacja między bankami ma zasadnicze znaczenie. Kluczową rolę odgrywa tu SWIFT (Society for Worldwide Interbank Financial Telecommunication), za pośrednictwem którego przekazywana jest większość międzynarodowych komunikatów między bankami. Zasadniczym elementem zapewniającym bezpieczeństwo i selektywność tej komunikacji jest aplikacja Relationship Management Application (RMA).

Czym jest RMA?

Relationship Management Application (RMA) to aplikacja SWIFT, która pozwala instytucjom finansowym określać, którzy kontrahenci mogą wysyłać do nich komunikaty SWIFT, i zapewnia, że komunikacja w sieci SWIFT jest ograniczona wyłącznie do uwierzytelnionych użytkowników. RMA stanowi podstawową warstwę bezpieczeństwa w zarządzaniu komunikacją międzybankową, ponieważ odfiltrowuje nieautoryzowane komunikaty i ogranicza ryzyko nadużyć.

Znaczenie RMA

Dla banków prowadzących działalność w obszarze finansów międzynarodowych, takich jak IFB, narzędzie RMA jest niezbędne. Nie tylko wzmacnia ono protokoły bezpieczeństwa, lecz także zapewnia zgodność z globalnymi przepisami bankowymi. Zarządzając tym, które instytucje mogą przesyłać do nich komunikaty, banki mogą zapobiegać nieuprawnionym żądaniom informacji i dyspozycjom finansowym, chroniąc zarówno własne interesy, jak i interesy swoich klientów.

Jak działa RMA

Proces RMA obejmuje kilka kluczowych etapów:

1. Nawiązanie relacji RMA: Zanim dwa banki będą mogły wymieniać informacje za pośrednictwem SWIFT, muszą wzajemnie uzgodnić ustanowienie RMA. Porozumienie to przypomina cyfrowy uścisk dłoni i oznacza wzajemne zaufanie oraz zgodę na komunikację.
2. Wymiana kluczy: każdy bank przesyła upoważnienie RMA za pośrednictwem aplikacji RMA, które kontrahent akceptuje. RMA zastąpiło wcześniejszą dwustronną wymianę kluczy (BKE); same komunikaty są uwierzytelniane za pomocą SWIFTNet PKI (Public Key Infrastructure).
3. Konfiguracja ustawień RMA: Każdy bank wykorzystuje narzędzie RMA do konfiguracji uprawnień oraz określenia, jakie typy komunikatów są akceptowane od drugiego banku. Może to być ujęte szeroko lub precyzyjnie dostrojone tak, aby obejmowało określone typy komunikatów i ich podklasy.
4. Aktywacja i monitorowanie: po skonfigurowaniu i aktywowaniu ustawień RMA banki mogą monitorować wiadomości przychodzące pod kątem zgodności z ustanowionymi uprawnieniami. RMA udostępnia również narzędzia umożliwiające zmianę lub cofnięcie uprawnień, jeżeli wymagają tego potrzeby biznesowe lub względy bezpieczeństwa.

Zastosowania praktyczne

Dla IFB, który specjalizuje się w inwestycjach i zarządzaniu majątkiem osób o wysokiej wartości netto oraz podmiotów korporacyjnych, RMA zapewnia szereg korzyści:

• Zwiększone bezpieczeństwo: Kontrolując ruch komunikatów, IFB może zabezpieczyć transakcje Klientów i informacje wrażliwe przed nieuprawnionym dostępem.
• Efektywność operacyjna: Usprawniona komunikacja z zaufanymi podmiotami zapewnia szybsze przetwarzanie prawidłowych komunikatów, skracając czas reakcji i zwiększając zadowolenie klientów.
• Zgodność z przepisami: RMA ułatwia przestrzeganie międzynarodowych regulacji bankowych, które nakładają obowiązek ścisłej kontroli wymiany informacji w celu przeciwdziałania przestępstwom finansowym, takim jak pranie pieniędzy i oszustwa.

RMA i MT799. Banki mogą wykorzystywać komunikat MT799 do wystąpienia o nawiązanie relacji RMA lub do jej uzgodnienia, o ile kanał komunikacji na to pozwala. Samo upoważnienie RMA jest udzielane w systemie RMA; sam komunikat MT799 nie aktywuje żadnego uprawnienia. Jeżeli brakuje upoważnienia RMA wymaganego dla MT799, nie można go ominąć poprzez bezpośrednie wysłanie komunikatu MT799. Ustawienia uzgadnia się wówczas za pomocą funkcji komunikacji RMA w portalu Relationship Management Portal firmy Swift, przeznaczonej do koordynacji z kontrahentami przed wymianą upoważnień, lub innym dozwolonym kanałem. Określenie „RMA przez MT799” może zatem opisywać towarzyszącą korespondencję bankową; techniczne upoważnienie RMA stanowi odrębny etap.

W skrócie

Dla IFB skuteczne wdrożenie RMA jest nie tylko wymogiem technicznym, lecz także strategicznym atutem w jego działalności globalnej. Umacnia zaangażowanie Banku w zakresie bezpieczeństwa i zgodności z przepisami, a jednocześnie zwiększa efektywność jego sieci komunikacyjnych. W miarę jak otoczenie międzynarodowych finansów będzie ewoluować, narzędzia takie jak RMA pozostaną niezbędnym instrumentarium banków dbających o najwyższe standardy integralności operacyjnej i obsługi klientów.

RMA stanowią podstawę bezpiecznej i selektywnej komunikacji międzybankowej, zapewniając, że każda wiadomość przesyłana za pośrednictwem sieci SWIFT spełnia najwyższe standardy bezpieczeństwa i jest w pełni uwierzytelniona. Dla banków takich jak IFB zrozumienie i zarządzanie RMA ma kluczowe znaczenie dla zabezpieczenia ich działalności i budowania zaufania wśród globalnych partnerów.

Swift Digital Blockchain Financial Instructions

We wrześniu 2025 roku Swift ogłosił, że wraz z ponad 30 instytucjami finansowymi rozpoczął projektowanie i budowę wspólnego rejestru cyfrowego. W dniu 9 lipca 2026 roku Swift oświadczył, że rejestr jest gotowy do początkowego użycia, a 17 banków przygotowuje się do pilotażu rzeczywistych transakcji z wykorzystaniem tokenizowanych depozytów: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB i Wells Fargo. Pierwsze zastosowanie skupi się na umożliwieniu składania międzybankowych dyspozycji transgranicznych w czasie rzeczywistym, przez całą dobę, 7 dni w tygodniu – co stanowi istotne udoskonalenie struktury międzynarodowego przetwarzania transakcji.

Pierwszy prototyp koncepcyjny został zbudowany we współpracy z Consensys. Rejestr zaprojektowano jako bezpieczny, niezmienny rejestr instrukcji finansowych między instytucjami, prowadzony w czasie rzeczywistym. Będzie on rejestrował, porządkował w sekwencji i walidował komunikaty transakcyjne, a jednocześnie egzekwował zasady operacyjne i zgodności za pomocą inteligentnych kontraktów. Kluczową zasadą jest interoperacyjność: rejestr będzie połączony zarówno z istniejącymi, jak i z nowo powstającymi infrastrukturami, zachowując cechy charakterystyczne Swift: odporność, zaufanie i zgodność z regulacjami.

Jak wyjaśnił Javier Pérez-Tasso, Prezes Zarządu Swift:
„Połączenie wspólnego rejestru z istniejącymi w Swift komunikatami, interfejsami API i standardem ISO 20022 tworzy jeszcze potężniejsze rozwiązanie – takie, które od samego początku może wbudować wymogi dotyczące ryzyka, kontroli i zgodności z przepisami w przepływy transakcji, umożliwiając jednocześnie całodobowe, międzybankowe dyspozycje transgraniczne w czasie rzeczywistym, z zachowaniem tego samego zaufania, bezpieczeństwa, odporności, skalowalności i doskonałości operacyjnej, z jakich słynie Swift. Wszystko to zgodnie z podejściem odpowiedzialnych innowacji, które zawsze stosowaliśmy.”

Rozszerzenie infrastruktury

Wspólna księga uzupełnia istniejącą infrastrukturę Swift, nie zastępując jej. Została zaprojektowana tak, aby rozszerzać możliwości koordynacji i interoperacyjności, umożliwiając instytucjom finansowym szybszą wymianę dyspozycji, z większą przewidywalnością i w skali rzeczywiście globalnej.

Podczas konferencji Sibos Pérez-Tasso podkreślił to dwutorowe podejście:
„Infrastruktury finansowe muszą nieustannie koncentrować się na podstawach: doskonałości operacyjnej, zgodności z przepisami i ładzie korporacyjnym. Jednocześnie muszą przygotowywać się na przyszłość. W Swift nasze podejście polega na innowacjach realizowanych na dwóch równoległych ścieżkach.”

Współpraca w całej branży

Instytucje finansowe z 16 krajów zostały zaangażowane od samego początku w kształtowanie projektu, zasad zarządzania i ścieżki rozwoju wspólnego rejestru. Ten wspólny wysiłek podkreśla powszechne przekonanie, że rozwój globalnej infrastruktury dla instrukcji międzybankowych wymaga skali i współpracy.

Perspektywy

Wspólny rejestr (shared ledger) jest naturalnym następstwem wcześniejszych prób Swift z aktywami cyfrowymi i częścią szerszego zobowiązania do interoperacyjności zarówno w sieciach publicznych, jak i prywatnych. Umożliwi to płynne przemieszczanie się między systemami regulowanej wartości stokenizowanej oraz tradycyjnych instrumentów.

Pérez-Tasso podsumował wizję następująco:
„To potężna platforma na przyszłość. A w przyszłości może okazać się jeszcze bardziej transformacyjna.”

Najczęściej zadawane pytania

Czym jest współdzielony rejestr Swift oparty na technologii blockchain?
Infrastruktura blockchain zapewniająca współdzielony zapis instrukcji finansowych między instytucjami w czasie rzeczywistym, umożliwiająca ciągłe, zgodne z regulacjami przetwarzanie transakcji transgranicznych.

Dla kogo?
Dla banków i instytucji finansowych, które muszą dostarczać szybsze i bardziej przejrzyste instrukcje transakcyjne, przygotowując się jednocześnie na cyfrową przyszłość.

Jakie są korzyści?

• Wgląd w instrukcje w czasie rzeczywistym oraz ich sekwencjonowanie
• Zautomatyzowane zapewnianie zgodności za pomocą inteligentnych kontraktów
• Interoperacyjność między sieciami tradycyjnymi i cyfrowymi
• Bezpieczna obsługa regulowanych przepływów wartości w formie tokenów

W jaki sposób rozwiązanie wpisuje się w platformę Swift?
Rozszerza zaufaną infrastrukturę Swift, wprowadzając możliwości cyfrowych dyspozycji przy zachowaniu odporności, bezpieczeństwa i zgodności z przepisami.

Jaki jest pierwszy przypadek użycia?
Przekazywanie w czasie rzeczywistym, całodobowo, międzynarodowych instrukcji transakcji międzybankowych.

Kto uczestniczy w projekcie?
Ponad 30 instytucji finansowych z 16 krajów współtworzyło projekt; 17 banków prowadzi pilotaż pierwszych transakcji w środowisku produkcyjnym.

Kiedy będzie dostępna?
Swift ogłosił gotowość rejestru do pierwszego użycia w dniu 9 lipca 2026 r. Banki pilotażowe przeprowadzają pierwsze transakcje produkcyjne w kontrolowanej fazie uruchomienia; ostateczny rozrachunek nadal przebiega w istniejących systemach. Funkcjonalność i dostępność mają zostać rozszerzone w późniejszym terminie.

Jeżeli chcą Państwo dowiedzieć się więcej o przekazywaniu środków za pośrednictwem systemu bankowości korespondencyjnej, prosimy o kontakt z naszym Dyrektorem ds. bankowości korespondencyjnej, M. Amri Elarisse