Przelewy IP/IP i IPZip

IP to IP (IPIP)

Przelewy IP to IP stanowią element procesu przekazywania waluty lub aktywów, zobowiązań i kapitałów z rachunków banków korespondentów albo danych pomiędzy różnymi instytucjami finansowymi lub systemami z wykorzystaniem adresów protokołu internetowego (IP). W kontekście transakcji finansowych adres IP jest unikalnym identyfikatorem liczbowym przypisanym każdemu urządzeniu podłączonemu do internetu i służy do kierowania informacji pomiędzy różnymi systemami. Przelewy IP to IP w bankowości polegają na bezpośredniej komunikacji między dwoma systemami z wykorzystaniem ich adresów IP w celu realizacji transakcji finansowej. Dodatkowo stosuje się specjalne metody uwierzytelniania i autoryzacji, które zabezpieczają integralność i bezpieczeństwo informacji.

Należy jednak pamiętać, że transfery IP-do-IP nie są powszechne ani zalecane w sektorze bankowym z wielu powodów, w tym ze względu na kwestie bezpieczeństwa, niezawodności i zgodności z przepisami. Poniższe punkty przybliżają kontekst tych zastrzeżeń:

1. Bezpieczeństwo: Przelewy IP to IP mogą być mniej bezpieczne w porównaniu z uznanymi sieciami bankowymi, takimi jak SWIFT czy ACH, które wdrażają wielowarstwowe zabezpieczenia, szyfrowanie i uwierzytelnianie. Bezpośrednia komunikacja między dwoma adresami IP może narażać dane wrażliwe na potencjalne zagrożenia, w tym włamania, phishing lub ataki typu man-in-the-middle.
2. Niezawodność: Stosowanie przelewów IP-to-IP nie gwarantuje niezawodności transakcji, ponieważ w sektorze bankowym nie obowiązują powszechnie uznawane standardy ani protokoły dla przelewów opartych na adresach IP. Może to prowadzić do potencjalnych problemów z przetwarzaniem, śledzeniem i uzgadnianiem transakcji.
3. Zgodność z przepisami: Banki i instytucje finansowe podlegają licznym regulacjom i wymogom, w tym politykom przeciwdziałania praniu pieniędzy (AML) oraz poznaj swojego klienta (KYC). Przelewy IP–IP mogą nie spełniać tych wymogów regulacyjnych, co potencjalnie naraża zaangażowane strony na ryzyko prawne i finansowe.

Zamiast przelewów między adresami IP banki i instytucje finansowe wolą korzystać ze sprawdzonych sieci, takich jak SWIFT, RTGS lub ACH/płatności natychmiastowe, oraz ze standardów komunikatów takich jak ISO 20022, aby zapewnić bezpieczne, niezawodne i zgodne z przepisami transfery środków między różnymi instytucjami.

Główne różnice między serwerami komunikacyjnymi a serwerami księgowymi/rachunków w bankach

W technologii bankowej serwery odgrywają kluczową rolę w zapewnieniu sprawnego przebiegu transakcji finansowych i prowadzenia ewidencji. Banki opierają się na dwóch podstawowych typach serwerów: serwerach komunikacyjnych oraz serwerach księgi głównej/rachunków. Choć oba są niezbędne, służą odmiennym celom i przetwarzają różne rodzaje danych.

Serwery komunikacyjne

Serwery komunikacyjne stanowią podstawę bezpiecznej wymiany danych między bankami a instytucjami finansowymi. Poniżej przedstawiono najważniejsze funkcje i cechy serwerów komunikacyjnych:

1. Bezpieczna wymiana danych: Serwery te umożliwiają bezpieczną wymianę danych, zapewniając, że wrażliwe informacje finansowe mogą być przekazywane między instytucjami bez naruszenia ich poufności.
2. Protokoły i standardy: Wykorzystują znormalizowane protokoły, takie jak SWIFT, Sepa czy ACH itp., do komunikacji międzybankowej, zapewniając jednolitość i niezawodność na różnych platformach.
3. Szyfrowanie i uwierzytelnianie: Aby zapewnić bezpieczeństwo, serwery komunikacyjne stosują zaawansowane metody szyfrowania oraz rygorystyczne protokoły uwierzytelniania, chroniące dane podczas transmisji.
4. Obsługa transakcji: Przede wszystkim obsługują zlecenia transakcji, komunikaty i dyspozycje, działając jako pośrednicy przekazujący informacje niezbędne do realizacji transakcji.
5. Brak przepływu środków: Co istotne, serwery te nie przenoszą środków ani nie aktualizują sald rachunków bezpośrednio; umożliwiają jedynie komunikację niezbędną do takich działań.

Serwery rejestrów i rachunków

Serwery ksiąg i rachunków pełnią natomiast funkcję depozytariuszy dokumentacji finansowej banku. Ich główne cechy to:

1. Prowadzenie ewidencji finansowej: Serwery te przechowują i utrzymują podstawowe rejestry finansowe banku, zapewniając dokładne odnotowanie każdej transakcji.
2. Rejestrowanie transakcji: Rejestrują wszystkie transakcje, w tym obciążenia i uznania, oraz odpowiadają za aktualizowanie i przechowywanie bieżących sald rachunków.
3. Zarządzanie księgą główną: Serwery księgowe zarządzają księgą główną banku wraz z poszczególnymi rachunkami klientów, zapewniając pełny obraz kondycji finansowej.
4. Integralność danych: zapewnienie spójności i integralności danych jest niezbędne, ponieważ rejestry te mają kluczowe znaczenie dla rzetelnej sprawozdawczości finansowej i zgodności z przepisami.
5. Rygorystyczne środki bezpieczeństwa: Z uwagi na wrażliwość danych serwery księgowe zazwyczaj wykorzystują bardziej rygorystyczne środki bezpieczeństwa, w tym dodatkowe warstwy szyfrowania i ścisłą kontrolę dostępu.

Serwer komunikacyjny inicjuje i obsługuje transakcje, natomiast serwer księgowy ostatecznie rejestruje i odzwierciedla te transakcje po ich zwalidowaniu w księgach banku.

We współczesnych systemach bankowych funkcje te są często zintegrowane, a bezpieczne protokoły komunikacji wewnątrzbankowej działają wspólnie z systemami zarządzania księgami. Taka integracja zapewnia aktualizację danych w czasie rzeczywistym oraz spójność w całym ekosystemie finansowym banku, zwiększając zarówno efektywność, jak i bezpieczeństwo. Wiele banków korzysta z połączenia serwerów lokalnych i chmurowych, aby zrównoważyć wymogi dotyczące bezpieczeństwa, zgodności z przepisami i skalowalności.

Faktyczne przeniesienie aktywów, zobowiązań i kapitałów własnych: Przeniesienia papierów wartościowych są rejestrowane przez centralne depozyty papierów wartościowych (CDPW), które prowadzą prawną ewidencję własności; kredyty, środki trwałe i inne pozycje przechodzą na podstawie umów cesji lub przeniesienia, zgodnie z właściwym prawem. Obie te kwestie wykraczają poza zakres protokołów komunikacyjnych. Przeniesienie aktywów i kapitałów wpływa również na sprawozdania finansowe banków, zmieniając salda zobowiązań, aktywów i kapitałów własnych. Sprawozdawczość finansowa wobec właściwych organów nadzorczych oraz niezbędne aspekty compliance wykraczają poza możliwości transmisji danych w ramach protokołów i wymagają dodatkowych procesów finansowych i regulacyjnych.

Podsumowując, choć protokoły mają kluczowe znaczenie dla bezpiecznej i sprawnej wymiany informacji w transakcjach IPIP, pełny proces obejmuje dodatkowe systemy służące faktycznemu przepływowi waluty, aktywów, zobowiązań i kapitału, rozrachunkowi, rejestracji prawnej oraz sprawozdawczości finansowej, co zapewnia wykonanie całej transakcji zgodnie z regulacyjnymi standardami bankowymi.

Transfer IP ZIP

Bezpieczna plikowa transmisja instytucjonalnych dyspozycji płatniczych

Transfer IP ZIP najlepiej rozumieć jako bezpieczną, opartą na plikach metodę przekazywania ustrukturyzowanych instrukcji płatniczych oraz powiązanych danych transakcyjnych bezpośrednio między uwierzytelnionymi systemami instytucji za pośrednictwem sieci opartej na protokole internetowym (IP).

Terminologia wymaga szczególnej precyzji.

Transmisja IP ZIP nie jest systemem rozliczeniowym, systemem rozrachunku, kanałem płatniczym ani niezależnym mechanizmem przekazywania wartości pieniężnej. Archiwum ZIP jest kontenerem transportowym. Połączenie IP jest kanałem komunikacyjnym. Informacje zawarte w archiwum stanowią dyspozycję, zbiór danych lub komunikat transakcyjny.

W związku z powyższym:

IP ZIP przekazuje informacje o płatności i dyspozycje płatnicze. Samo w sobie nie dokonuje rozrachunku środków.

Koncepcyjnie jest to porównywalne z rozróżnieniem stosowanym w odniesieniu do komunikatu ISO 20022 pacs.008 (FI-to-FI Customer Credit Transfer). Komunikat pacs.008 może zawierać wysoce ustrukturyzowane polecenie przelewu międzybankowego, jednak samego komunikatu nie należy utożsamiać z ostatecznym przepływem i rozliczeniem pieniądza banku centralnego, pieniądza banków komercyjnych ani sald na rachunkach korespondenckich.

Ta sama zasada dotyczy transmisji IP ZIP.

2. Plik ZIP jako bezpieczny kontener transakcyjny

Komponent ZIP służy przede wszystkim jako mechanizm kontenerowania i pakowania.

Zamiast przekazywać poszczególne elementy transakcji osobno, instytucja inicjująca może skompletować odpowiednie pliki w jeden kontrolowany pakiet.

W zależności od uzgodnionej dwustronnie specyfikacji taki pakiet może zawierać:

• ustrukturyzowane instrukcje płatnicze;
• komunikaty płatnicze w formacie XML;
• zbiory danych zgodne z ISO 20022;
• obiekty transakcji w formacie JSON;
• rekordy transakcji w formacie CSV lub o ustalonym formacie;
• własne pliki płatnicze dotyczące rozliczeń międzybankowych;
• informacje o dłużniku i wierzycielu;
• dane rachunku zleceniodawcy i beneficjenta;
• identyfikatory transakcji;
• informacje o walucie i kwocie;
• żądane daty wykonania i daty waluty;
• instrukcje banku korespondenta;
• dane banku pośredniczącego;
• informacje o płatności;
• informacje dotyczące trasowania rozliczeń;
• dokumentacji w zakresie compliance;
• referencje KYC lub KYB;
• informacje o źródle środków;
• manifesty transakcji;
• podpisy cyfrowe;
• skróty kryptograficzne (hashe);
• certyfikaty;
• znaczniki czasu;
• pliki uzgodnieniowe; oraz
• sumy kontrolne.

Archiwum może zatem zawierać zarówno podstawowe zlecenie płatnicze, jak i informacje dodatkowe niezbędne do uwierzytelnienia, zatwierdzenia, przetworzenia i uzgodnienia tego zlecenia.

Kompresja ma charakter techniczny i uboczny. Zasadniczym celem jest kontrolowane pakowanie i przesyłanie.

Archiwum ZIP nie powinno zatem nigdy być traktowane jako dowód, że środki w nim przedstawione istnieją, są dostępne, są wolne od obciążeń lub zostały rozliczone.

3. Ustrukturyzowane zlecenie płatnicze

Jeżeli pakiet IP ZIP jest odpowiednio zaprojektowany, zawarte w nim polecenie płatnicze może pełnić funkcję analogiczną do konwencjonalnych ustrukturyzowanych komunikatów finansowych.

Na przykład instytucja mogłaby przesłać instrukcję w formacie XML zawierającą pola odpowiadające informacjom zwykle zawartym w komunikacie ISO 20022 pacs.008, w tym:

• identyfikacja komunikatu;
• data i godzina utworzenia;
• liczba transakcji;
• informacje rozrachunkowe;
• agent zlecający;
• agent otrzymujący instrukcję;
• dłużnik;
• rachunek dłużnika;
• agent dłużnika;
• agent wierzyciela;
• wierzyciel;
• rachunek wierzyciela;
• kwota zlecona;
• waluta;
• strona ponosząca koszty (charge bearer);
• identyfikacja płatności;
• identyfikacja typu end-to-end; oraz
• informacje o płatności.

Kluczowe jest rozróżnienie, że struktura danych nie determinuje mechanizmu rozrachunku.

Technicznie prawidłowa instrukcja płatnicza może zostać odebrana, uwierzytelniona i przyjęta przez system odbiorczy, podczas gdy odpowiadający jej rozrachunek finansowy pozostaje niezrealizowany.

Zatem:

Otrzymanie dyspozycji ≠ otrzymanie środków

Instrukcja uwierzytelniona ≠ środki rozliczone

Pomyślny import pliku ≠ uznanie rachunku beneficjenta ostatecznymi środkami

Potwierdzenie przyjęcia przez serwer ≠ potwierdzenie rozliczenia

To rozróżnienie ma fundamentalne znaczenie dla sposobu, w jaki IFB traktuje alternatywne metody transferu.

4. Protokoły transmisji

Transmisje instytucjonalnych plików IP ZIP powinny odbywać się wyłącznie w kontrolowanym i uwierzytelnionym środowisku komunikacyjnym.

W zależności od dwustronnych ustaleń technicznych transmisja może odbywać się z wykorzystaniem technologii takich jak:

SFTP

Secure File Transfer Protocol over SSH zapewnia szyfrowany transport, uwierzytelnianie serwera oraz kontrolowane uwierzytelnianie użytkowników.

W przypadku łączności instytucjonalnej uwierzytelnianie kluczem publicznym powinno co do zasady być preferowane wobec uwierzytelniania wyłącznie za pomocą hasła.

FTPS

Protokół FTP może być zabezpieczony za pomocą TLS tam, gdzie wymaga tego starsza infrastruktura, pod warunkiem wdrożenia odpowiedniej weryfikacji certyfikatów, standardów szyfrowania i kontroli dostępu.

HTTPS / REST API

Pakiet może być przekazywany za pośrednictwem uwierzytelnionego punktu końcowego HTTPS lub architektury API z wykorzystaniem TLS oraz odpowiedniego uwierzytelniania na poziomie aplikacji.

Mutual TLS

W przypadku połączeń instytucjonalnych o podwyższonym poziomie zabezpieczenia wzajemny TLS (mTLS) umożliwia obu stronom wzajemne uwierzytelnianie się za pomocą certyfikatów cyfrowych.

Zapewnia to istotnie silniejszą ochronę przed nieuprawnionymi punktami końcowymi niż samo jednostronne uwierzytelnianie serwera.

VPN

Zanim nastąpi transmisja na poziomie aplikacji, między uczestniczącymi instytucjami można ustanowić szyfrowany, prywatny tunel za pomocą sieci VPN typu site-to-site opartej na IPSec lub równoważnej.

Dedykowana prywatna łączność

Jeżeli wolumeny transakcji, wymogi bezpieczeństwa lub profile ryzyka instytucji to uzasadniają, łączność za pośrednictwem dedykowanych lub prywatnych sieci może uzupełniać transmisję przez publiczny Internet lub ją zastępować.

Dokładny protokół musi zostać uzgodniony dwustronnie przed uruchomieniem operacyjnym.

5. Uwierzytelnianie punktów końcowych

Instytucja odbierająca musi ustalić, że przekaz pochodzi od instytucji, którą rzekomo reprezentuje.

Odpowiednie mechanizmy kontrolne mogą obejmować:

• instytucjonalne certyfikaty cyfrowe;
• pary kluczy SSH (publiczny/prywatny);
• certyfikaty mutual TLS;
• dane uwierzytelniające API;
• ograniczenie dostępu do wskazanych adresów IP (IP allow-listing);
• uwierzytelnianie VPN;
• sprzętowe moduły bezpieczeństwa;
• przypinanie certyfikatów (certificate pinning) tam, gdzie jest to właściwe;
• wieloskładnikowe uwierzytelnianie administracyjne;
• kontrolowane rachunki usługowe;
• mechanizmy kontroli dostępu oparte na rolach; oraz
• rozdzielenie środowisk produkcyjnych i testowych.

Sam adres IP nie stanowi wystarczającego dowodu tożsamości instytucji.

Podobnie posiadanie punktu końcowego, danych logowania do serwera, poświadczeń API lub hasła do archiwum ZIP nie stanowi o własności środków, do których się one odnoszą.

6. Szyfrowanie

Poufność powinna być co do zasady zapewniana na więcej niż jednym poziomie.

Szyfrowanie transmisji

Kanał komunikacji powinien być szyfrowany z użyciem odpowiednio skonfigurowanego, współczesnego protokołu, takiego jak TLS lub SSH.

Chroni to informacje w trakcie przesyłania.

Szyfrowanie ładunku danych

W razie potrzeby sam pakiet transakcyjny może być dodatkowo szyfrowany.

Zapewnia to ochronę informacji finansowych niezależnie od kanału transmisji i może istotnie ograniczyć narażenie w miejscach, w których pliki są tymczasowo przechowywane, przesyłane przez infrastrukturę pośredniczącą, archiwizowane lub przetwarzane asynchronicznie.

Szyfrowanie danych w spoczynku

Pliki oczekujące na przetworzenie powinny być chronione w kontrolowanych środowiskach przechowywania, z odpowiednimi ograniczeniami dostępu i szyfrowaniem danych w spoczynku.

Szyfrowanie zapewnia jednak poufność. Nie potwierdza natomiast ważności finansowej transakcji.

7. Integralność kryptograficzna

Instytucja odbierająca musi być również w stanie ustalić, czy przesłany pakiet został zmieniony po jego utworzeniu.

W związku z tym dla pakietu lub poszczególnych plików wchodzących w jego skład można wygenerować kryptograficzny skrót (hash).

Na przykład:

Oryginalny pakiet transakcji
→ wygenerowanie skrótu kryptograficznego
→ przesłanie pakietu
→ niezależne obliczenie skrótu przez system odbiorcy
→ porównanie obliczonego skrótu ze skrótem przesłanym lub podpisanym

Niezgodność oznacza, że otrzymany pakiet nie jest kryptograficznie identyczny z pakietem pierwotnie uwierzytelnionym.

Do weryfikacji integralności mogą być wykorzystywane współczesne kryptograficzne funkcje skrótu, takie jak algorytmy z rodzin SHA-2 lub SHA-3, odpowiednio do sposobu wdrożenia.

8. Podpisy cyfrowe

Podpis cyfrowy pełni zasadniczo inną funkcję niż szyfrowanie.

Szyfrowanie chroni poufność.

Haszowanie pomaga w zapewnieniu integralności.

Prawidłowo wdrożony podpis cyfrowy może pomóc w ustaleniu:

1. autentyczność – pakiet został podpisany przy użyciu odpowiedniego klucza prywatnego;
2. integralność - podpisane dane nie zostały później zmienione; oraz
3. rozliczalność – podpis może zostać powiązany z odpowiednim poświadczeniem instytucjonalnym, z zastrzeżeniem obowiązujących ram PKI i ładu korporacyjnego.

Instytucja odbierająca powinna zweryfikować podpis w oparciu o odpowiedni zaufany certyfikat lub klucz publiczny, zanim dyspozycja transakcji zostanie skierowana do przetwarzania płatności.

Prywatne klucze podpisujące powinny być odpowiednio chronione, najlepiej w ramach instytucjonalnej infrastruktury zarządzania kluczami oraz, w uzasadnionych przypadkach, sprzętowych modułów bezpieczeństwa (Hardware Security Modules).

9. Ochrona przed powtórzeniem i duplikacją

Przesyłanie plików finansowych wymaga mechanizmów kontrolnych zapobiegających wielokrotnemu składaniu tej samej prawidłowej dyspozycji.

Odpowiednio zaprojektowana architektura powinna zatem uwzględniać unikalne identyfikatory transakcji oraz odpowiednie mechanizmy kontrolne, takie jak:

• unikalne identyfikatory komunikatów;
• unikalne identyfikatory transakcji;
• znaczniki czasu;
• numery sekwencyjne;
• identyfikatory plików;
• wykrywanie zduplikowanych komunikatów;
• mechanizmy kontroli idempotentności;
• rejestry statusów przetwarzania; oraz
• uzgodnienie z wcześniej przetworzonymi dyspozycjami.

Instytucja odbierająca powinna odrzucić, odizolować lub zbadać zduplikowane instrukcje zgodnie z uzgodnioną procedurą operacyjną.

10. Walidacja pliku

Pomyślne odebranie pliku powinno uruchamiać walidację, a nie automatyczny rozrachunek.

Bezpieczne środowisko przetwarzania może poddać pakiet kilku kolejnym kontrolom:

Etap 1 – Walidacja transportu

Potwierdzenie, że przesyłka dotarła autoryzowanym kanałem.

Etap 2 – uwierzytelnienie punktu końcowego

Potwierdzenie systemu nadawczego oraz uprawnień instytucjonalnych.

Etap 3 – Kontrole w zakresie złośliwego oprogramowania i bezpieczeństwa plików

Kontrola archiwum i zawartych w nim plików przed wprowadzeniem do infrastruktury płatniczej.

Etap 4 – Weryfikacja kryptograficzna

Weryfikacja skrótów (hashów), podpisów i certyfikatów.

Etap 5 – Weryfikacja strukturalna

Potwierdzenie, że pliki są zgodne z uzgodnionym schematem, konwencjami nazewnictwa, kodowaniem znaków i specyfikacją danych.

Etap 6 – Walidacja semantyczna

Potwierdzenie, że obowiązkowe pola płatności są obecne i wewnętrznie spójne.

Etap 7 – Walidacja transakcji

Weryfikacja waluty, kwoty, rachunków, informacji o routingu, referencji transakcji i instrukcji rozrachunkowych.

Etap 8 – Walidacja zgodności

Mechanizmy kontrolne w zakresie AML, sankcji, KYC/KYB, monitorowania transakcji oraz inne obowiązujące mechanizmy kontrolne.

Etap 9 – Weryfikacja rozliczenia

Potwierdzenie, że istnieje faktyczny mechanizm, za pośrednictwem którego można rozliczyć odpowiadającą wartość finansową.

Dopiero po zakończeniu tych czynności kontrolnych dyspozycja powinna zostać przekazana do realizacji zgodnie z procedurami obowiązującymi w instytucji ją przyjmującej.

11. Potwierdzenie odbioru nie jest rozrachunkiem

Środowisko IP ZIP może generować kilka potwierdzeń technicznych.

Na przykład:

ACK – plik otrzymany

Wykazuje to wyłącznie, że punkt końcowy odbierający otrzymał pakiet.

ACK – plik uwierzytelniony

Potwierdza to, że mechanizmy uwierzytelniania zostały pomyślnie zrealizowane.

ACK – plik zwalidowany

Potwierdza to, że pakiet spełnił obowiązujące wymogi walidacji strukturalnej lub technicznej.

ACK – Instrukcja przyjęta

Może to potwierdzać, że dyspozycja płatnicza weszła do procesu przetwarzania w instytucji odbiorcy.

Żaden z tych stanów nie musi oznaczać:

ROZLICZONO

Rozliczenie wymaga odrębnego zdarzenia finansowego.

Rozróżnienie to jest porównywalne z konwencjonalnymi komunikatami finansowymi, w których skuteczne dostarczenie i przyjęcie komunikatu płatniczego należy odróżnić od ostatecznego rozrachunku zobowiązania pieniężnego leżącego u jego podstaw.

12. Rozliczenie transakcji bazowej

Po uwierzytelnieniu, zweryfikowaniu, przyjęciu i autoryzowaniu dyspozycji płatniczej IP ZIP wartość pieniężna będąca jej przedmiotem musi zostać rozliczona za pośrednictwem odpowiedniej infrastruktury finansowej.

W zależności od walut, instytucji i jurysdykcji, których dotyczy transakcja, rozrachunek może odbywać się za pośrednictwem:

• bankowość korespondencyjna;
• rachunki nostro/vostro;
• rachunki w banku centralnym;
• infrastruktura RTGS;
• uznane systemy rozliczeniowe;
• krajowe systemy płatnicze;
• infrastruktury płatności natychmiastowych;
• korespondenckie banki rozliczeniowe; lub
• inny, prawnie i operacyjnie uznany mechanizm rozrachunku.

14. Zasada bezpieczeństwa

IFB stosuje zasadnicze rozróżnienie wobec wszystkich alternatywnych metod transferu:

Bezpieczna transmisja dowodzi, że dane mogą być przesyłane w sposób bezpieczny. Nie dowodzi, że środki mogą zostać rozliczone.

• Szyfrowanie nie stanowi potwierdzenia posiadania środków.
• Podpis cyfrowy nie dowodzi posiadania środków.
• Saldo na serwerze nie stanowi dowodu posiadania środków.
• Plik transakcji nie stanowi dowodu posiadania środków.
• Pomyślne wczytanie pliku nie stanowi dowodu istnienia środków.
• Potwierdzenie techniczne nie dowodzi rozliczenia.

Rozstrzygające pytanie finansowe pozostaje niezmienne: czy instytucja inicjująca dysponuje zweryfikowaną płynnością oraz operacyjną ścieżką rozrachunku, zdolną do dostarczenia odpowiadającej jej wartości pieniężnej za pośrednictwem uznanej infrastruktury bankowej.

15. Ramy akceptacji IFB

IFB może rozważyć transmisje IP ZIP wyłącznie w odniesieniu do zatwierdzonych kontrahentów instytucjonalnych i zaakceptowanych klientów, po satysfakcjonującej weryfikacji technicznej, prawnej i w zakresie compliance.

Przed uruchomieniem połączenia produkcyjnego IFB może wymagać weryfikacji:

• instytucji inicjującej;
• upoważnienie instytucjonalne do przekazania transakcji;
• beneficjentów rzeczywistych i strony transakcji;
• źródło i legalność środków;
• cel ekonomiczny leżący u podstaw transakcji;
• infrastruktura wysyłająca i odbierająca;
• własność punktu końcowego;
• adresacja IP i architektura sieci;
• metodologia uwierzytelniania;
• certyfikaty i poświadczenia kryptograficzne;
• standardy szyfrowania;
• format pliku i schemat;
• struktura komunikatu płatniczego;
• metodologia identyfikacji transakcji;
• protokół potwierdzania odbioru;
• mechanizmy kontroli duplikatów i ponownego przesłania (replay);
• obsługa wyjątków;
• procedury uzgadniania;
• relacje korespondencyjne;
• rachunki rozliczeniowe;
• rozwiązania w zakresie płynności; oraz
• ostateczną ścieżkę rozrachunku.

Sama interoperacyjność techniczna nie jest wystarczająca.

IFB nie uzna pomyślnego przesłania pakietu IP ZIP za otrzymanie środków. Transakcja jest zakończona finansowo dopiero wtedy, gdy odpowiadająca jej wartość zostanie skutecznie rozliczona za pośrednictwem uzgodnionej infrastruktury bankowej lub rozliczeniowej, a rozliczenie to będzie możliwe do niezależnego uzgodnienia.

Zasada podstawowa

IP ZIP to bezpieczne przekazanie dyspozycji. Rozrachunek to przepływ odpowiadającej jej wartości finansowej.

Oba procesy mogą stanowić części tego samego przebiegu transakcji, nie są jednak tym samym zdarzeniem.

W terminologii bankowości instytucjonalnej:

Przesłanie komunikatu → uwierzytelnienie → walidacja → akceptacja → realizacja → rozrachunek → uzgodnienie

Dopiero zakończenie właściwego procesu rozrachunku potwierdza, że pieniężna część transakcji została wykonana.

Terminologię związaną z alternatywnymi lub dawnymi metodami przekazywania środków należy interpretować w kontekście infrastruktury bankowej. Terminy te mogą opisywać kanały komunikacji, wewnętrzne metody przetwarzania lub dawne praktyki, nie zastępują jednak wymogu korzystania z regulowanych instytucji, uznanych systemów płatniczych i formalnych procedur rozliczeniowych.

Każdy transfer, niezależnie od stosowanej terminologii, musi ostatecznie zostać przetworzony, rozliczony i uzgodniony w ramach ugruntowanego systemu finansowego.

Jeśli chcą Państwo dowiedzieć się więcej o sposobach przekazania środków lub aktywów na rachunki prowadzone w Banku, prosimy o kontakt z Marie Mayer.