Niniejsza strona stanowi tłumaczenie udostępnione dla wygody Państwa. Wersja angielska jest wiążąca. Czytaj po angielsku

Alternatywne metody transferu

Server-to-Server (S2S)

Aktywacja usług S2S w IFB

Usługi Server to Server zostaną aktywowane na wniosek Klienta po uzyskaniu przez rachunek statusu rachunku w dobrej kondycji:

Utrzymuje saldo minimalne,
wykazuje stabilne, udokumentowane wyniki finansowe oraz
jest zgodna z legalną działalnością gospodarczą.

Ponadto rachunek musi posiadać

brak nierozwiązanych kwestii w zakresie compliance oraz
wszystkie transakcje muszą być zgodne z międzynarodowymi regulacjami finansowymi.

Ostateczna aktywacja podlega wewnętrznej weryfikacji i zatwierdzeniu przez nasz zespół ds. compliance i zarządzania ryzykiem.

Komunikat nie jest pieniądzem

Dlaczego żaden komunikat SWIFT, teleks ani serwer nie przenosi środków bez rozliczenia – w 90 sekund.

Zweryfikuj dokument za pomocą VL1 →

Otrzymali Państwo komunikat płatniczy, dowód płatności lub potwierdzenie? Prosimy zlecić jego weryfikację, zanim zaczną Państwo na nim polegać.

Przelewy typu Server to Server (S2S)

odnoszą się do części procesu przekazywania środków, aktywów, zobowiązań i kapitałów z ich rachunków nostro lub danych między różnymi bankami albo instytucjami finansowymi za pośrednictwem ich serwerów. Transfery te są realizowane przez zabezpieczone, szyfrowane połączenia i opierają się na sprawdzonych protokołach i standardach, które zapewniają bezpieczną i efektywną transmisję informacji. Transfery serwer–serwer w bankowości obejmują kilka elementów:

Sieci międzybankowe: Instytucje finansowe są ze sobą połączone za pośrednictwem sieci międzybankowych, takich jak Society for Worldwide Interbank Financial Telecommunication (SWIFT) lub sieć Automated Clearing House (ACH). Sieci te umożliwiają bankom wzajemną komunikację oraz przetwarzanie transakcji, takich jak przelewy środków i płatności.
Protokoły i standardy: Przelewy typu server-to-server opierają się na ustalonych protokołach i standardach, które umożliwiają komunikację i przetwarzanie transakcji. Przykłady obejmują standard ISO 20022 dla elektronicznej wymiany danych oraz system komunikatów SWIFT, który wykorzystuje określony format wymiany komunikatów finansowych między bankami.
Bezpieczne połączenia: Banki stosują bezpieczne, szyfrowane połączenia w celu ochrony poufności i integralności wrażliwych informacji przekazywanych podczas transferów między serwerami. Obejmuje to wykorzystanie technologii takich jak Secure Socket Layer (SSL) lub Transport Layer Security (TLS) do ustanawiania bezpiecznych kanałów komunikacji.
Uwierzytelnianie i autoryzacja: Banki stosują rygorystyczne procedury uwierzytelniania i autoryzacji w celu weryfikacji tożsamości stron uczestniczących w przelewie typu server-to-server. Może to obejmować wykorzystanie certyfikatów cyfrowych, kluczy kryptograficznych lub metod uwierzytelniania wieloskładnikowego, aby zapewnić, że transakcje mogą inicjować lub zatwierdzać wyłącznie upoważnione osoby lub systemy.
Przetwarzanie transakcji: Po wdrożeniu niezbędnych zabezpieczeń można przetwarzać transakcje między bankami. Zazwyczaj polega to na tym, że bank nadawcy inicjuje polecenie przelewu, bank odbiorcy weryfikuje i przyjmuje polecenie, a następnie oba banki aktualizują swoje rejestry, aby odzwierciedlić zrealizowany przelew.
Uzgodnienie i rozliczenie: Po zrealizowaniu przelewu typu server-to-server banki uzgadniają swoje zapisy i rozliczają wszelkie zaległe salda. Może to obejmować aktualizację ksiąg, uzgodnienie danych transakcyjnych oraz rozliczenie wszelkich nierozliczonych opłat lub kosztów związanych z przelewem.

Nasze usługi S2S

Świadczymy usługi S2S wyselekcjonowanemu gronu Klientów – osobom o wysokim majątku netto oraz ugruntowanym podmiotom korporacyjnym – ze szczególnym naciskiem na dyskrecję, poufność i integralność instytucjonalną.

Wszystkie transakcje S2S są realizowane wyłącznie między bankami w pełni zintegrowanymi z międzynarodowym systemem bankowym, co zapewnia nie tylko bezpieczną wymianę uwierzytelnionych komunikatów S2S, lecz także skuteczne i terminowe rozliczenie środków. Kontrahenci, którzy nie posiadają takiej integracji, mogą być w stanie przesyłać komunikaty, lecz z natury rzeczy nie są w stanie zrealizować rozliczenia finansowego.

W przypadku transferów S2S środki nie mogą zostać „pobrane” z księgi banku ani z jego systemów centralnych, ponieważ systemy te są zawsze całkowicie odizolowane od dostępu z zewnątrz. W przeciwieństwie do plików cyfrowych przechowywanych w chmurze, na zwykłym serwerze lub komputerze, środki muszą być zawsze przekazywane w ramach bezpiecznego i regulowanego systemu globalnej bankowości, co zapewnia zarówno ich integralność, jak i zgodność każdej transakcji z przepisami.

Z doświadczenia wynika, że ponad 68% transakcji S2S przedstawianych Bankowi pochodzi od podmiotów niebędących bankami lub od banków niemających możliwości przekazywania środków.

Natomiast jesteśmy w stanie realizować transakcje bez ograniczeń co do kwoty, pod wyłącznym warunkiem rzetelnej weryfikacji instytucji inicjującej oraz możliwej do wykazania zdolności do rozliczenia transakcji.

Podmioty i uczestnicy weryfikacji Niepowiązane banki

Struktura przelewu walutowego typu Server to Server (S2S)

Komunikacja S2S między bankami

Komunikacja między serwerami banków jest realizowana z wykorzystaniem kombinacji bezpiecznych protokołów, ram regulacyjnych i standardów branżowych, które zapewniają poufność, integralność i dostępność danych. Komunikacja ta jest zazwyczaj obsługiwana z użyciem następujących protokołów i technologii:

1. SWIFT (Society for Worldwide Interbank Financial Telecommunication)

Przegląd: SWIFT zapewnia globalną sieć bezpiecznej i ustandaryzowanej wymiany komunikatów finansowych. Jest szeroko wykorzystywany w międzynarodowych przelewach bankowych.
Wykorzystywane protokoły: SWIFTNet korzysta z protokołów opartych na IP, takich jak SWIFTNet InterAct i SWIFTNet FileAct, które wykorzystują XML do formatowania komunikatów. Bezpieczną komunikację zapewnia protokół TLS (Transport Layer Security).

2. ISO 20022

Przegląd: ISO 20022 to międzynarodowy standard elektronicznej wymiany danych między instytucjami finansowymi. Zapewnia on wspólną platformę do opracowywania komunikatów w znormalizowanym formacie XML.
Wykorzystywane protokoły: Często wdrażane w oparciu o bezpieczne protokoły transportowe, takie jak HTTPS i TLS.

3. Protokół FIX (Financial Information Exchange)

Przegląd: FIX jest standardowym protokołem do elektronicznej wymiany transakcji papierami wartościowymi w czasie rzeczywistym.
Wykorzystywane protokoły: Komunikaty FIX są zazwyczaj przesyłane przez TCP/IP i mogą być zabezpieczone za pomocą TLS.

4. EBICS (Electronic Banking Internet Communication Standard)

Przegląd: Szeroko stosowany w Europie protokół EBICS służy do bezpiecznego przesyłania transakcji finansowych przez internet.
Stosowane protokoły: EBICS wykorzystuje HTTPS z TLS do bezpiecznej komunikacji oraz XML do formatowania komunikatów.

5. VPN (wirtualna sieć prywatna)

Przegląd: sieci VPN zapewniają bezpieczną komunikację punkt–punkt przez internet poprzez tworzenie szyfrowanych tuneli.
Stosowane protokoły: powszechnie stosowane protokoły to IPsec (Internet Protocol Security) oraz SSL/TLS.

6. Standardy API (Application Programming Interface)

Przegląd: interfejsy API umożliwiają sprawną integrację i komunikację między systemami bankowymi.
Stosowane protokoły: Interfejsy API typu REST wykorzystują zazwyczaj HTTPS z TLS do bezpiecznej transmisji danych. Standardy Open Banking, takie jak PSD2 w Europie, nakładają obowiązek stosowania bezpiecznych interfejsów API w celu uzyskiwania dostępu do danych bankowych.

7. SFTP (Secure File Transfer Protocol)

Przegląd: SFTP służy do bezpiecznego przesyłania plików między bankami.
Wykorzystywane protokoły: SFTP działa w oparciu o SSH (Secure Shell), co zapewnia szyfrowanie i bezpieczną transmisję danych.

8. Blockchain i DLT (technologia rozproszonego rejestru)

Przegląd: Nowe technologie, takie jak blockchain, zapewniają zdecentralizowane i bezpieczne przetwarzanie transakcji.
Stosowane protokoły: Konkretne protokoły zależą od platformy blockchain, np. Hyperledger Fabric, Ethereum. Bezpieczeństwo zapewniają metody kryptograficzne.

Względy bezpieczeństwa i regulacyjne

Uwierzytelnianie i autoryzacja: stosowane są mechanizmy takie jak uwierzytelnianie dwuskładnikowe, podpisy cyfrowe oraz kontrola dostępu oparta na rolach.
Szyfrowanie: dane przechowywane i przesyłane są szyfrowane przy użyciu silnych algorytmów kryptograficznych (np. AES, RSA).
Compliance: przestrzeganie wymogów regulacyjnych, takich jak RODO (ogólne rozporządzenie o ochronie danych), PSD2 (druga dyrektywa w sprawie usług płatniczych) oraz innych standardów regionalnych.

Alternatywna łączność

Bezpośrednie łącza prywatne: Niektóre banki wykorzystują łącza dzierżawione lub sieci MPLS (Multiprotocol Label Switching) do bezpośredniej, wysoce bezpiecznej komunikacji. Rozwiązanie powszechne w środowiskach o wysokich wymogach bezpieczeństwa.
Rozwiązania chmurowe: banki coraz częściej korzystają z dostawców usług chmurowych o solidnych ramach bezpieczeństwa w komunikacji międzybankowej. Rozwiązanie to jest coraz powszechniejsze i podlega przepisom dotyczącym outsourcingu i odporności operacyjnej, takim jak DORA w UE.

Protokoły transmisji dla S2S

FIX (Financial Information eXchange): Standard komunikatów dla obrotu papierami wartościowymi: zleceń, transakcji i alokacji. Przenosi dane transakcyjne, nie płatności.
EBICS (Electronic Banking Internet Communication Standard): Standard bezpiecznej wymiany plików między klientami korporacyjnymi a ich bankami, stosowany głównie w Niemczech, Francji, Szwajcarii i Austrii.
Zengin: System Zengin jest japońską krajową siecią przelewów międzybankowych; format pliku Zengin służy do realizacji przelewów krajowych i poleceń zapłaty.
AS2 (Applicability Statement 2): Bezpieczny, podpisany transport dokumentów biznesowych (EDI, XML) przez Internet, z potwierdzeniami dostarczenia.
SNMPv3: Monitorowanie i zarządzanie urządzeniami sieciowymi z uwierzytelnianiem i szyfrowaniem. Protokół ten służy do zarządzania infrastrukturą; nie przenosi transakcji.
Kerberos: Oparte na biletach uwierzytelnianie sieciowe, dzięki któremu klienci i usługi mogą wzajemnie potwierdzać swoją tożsamość.
OAuth 2.0: Delegowana autoryzacja za pomocą tokenów o ograniczonym dostępie; podstawa większości interfejsów API otwartej bankowości.
SFTP i SCP przez SSH: Szyfrowane przesyłanie i kopiowanie plików między serwerami, powszechnie stosowane dla plików płatności i wyciągów.

Każdy z tych protokołów zabezpiecza wymianę danych lub dostęp do systemów. W transakcjach S2S obejmujących transfer waluty, aktywów, zobowiązań i kapitału własnego banku wymienione protokoły są konieczne, lecz niewystarczające do zakończenia transakcji finansowych:

Faktyczny transfer środków: Protokoły te skutecznie przekazują szczegóły transakcji, lecz nie obsługują samego przepływu środków. Do transferu środków niezbędne są systemy takie jak bankowość korespondencyjna, rozrachunek brutto w czasie rzeczywistym (RTGS) oraz płatności natychmiastowe. Fizycznie przemieszczają one środki między rachunkami, kończąc transakcję finansową, chyba że środki znajdują się już na rachunku nostro-vostro i wymagają jedynie przesunięcia z tego rachunku. Poza transmisją danych konieczny jest faktyczny rozrachunek środków, który zapewnia ich przepływ w czasie rzeczywistym oraz prawidłowe odzwierciedlenie transakcji w systemach bankowych.

Faktyczne przeniesienie aktywów, zobowiązań i kapitałów: w transakcjach dotyczących aktywów, zobowiązań i kapitałów kluczowe jest zapisanie tych przeniesień w CSD. Centralne depozyty papierów wartościowych odpowiadają za prowadzenie prawnej ewidencji własności papierów wartościowych, a proces ten wykracza poza zakres początkowych protokołów komunikacyjnych. Przeniesienie aktywów i instrumentów kapitałowych wpływa również na sprawozdania finansowe banków, zmieniając salda aktywów, zobowiązań i kapitału. Sprawozdawczość finansowa wobec właściwych organów nadzorczych oraz niezbędne aspekty compliance wykraczają poza możliwości protokołów w zakresie transmisji danych i wymagają dodatkowych procesów finansowych i regulacyjnych.

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

Minimalne procedury połączenia

Aby połączyć serwery dwóch różnych banków w celu jednorazowego przesłania informacji, wymagane jest kilka szczegółowych kroków i informacji. Poniżej przedstawiamy szczegółowe omówienie:

1. Informacje o sieci

Adresy IP: należy uzyskać publiczne lub prywatne adresy IP obu serwerów.
Porty: Należy określić, które porty będą używane do komunikacji (np. port 22 dla SFTP, port 443 dla HTTPS).

2. Uwierzytelnianie i autoryzacja

Dane uwierzytelniające: wymiana bezpiecznych danych dostępowych. Nazwa użytkownika i hasło: należy zapewnić ich bezpieczne przekazanie. Klucze SSH: w przypadku korzystania z SSH należy bezpiecznie przekazać klucze publiczne. Klucze API: w przypadku komunikacji opartej na API należy bezpiecznie przekazać klucze API.
Certyfikaty: Do szyfrowania połączeń należy stosować certyfikaty SSL/TLS.

3. Protokoły przesyłania danych

Wybór protokołu: Należy wybrać protokół w zależności od wymogów bezpieczeństwa i funkcjonalności. FTP/SFTP: bezpieczny protokół przesyłania plików; HTTP/HTTPS: do komunikacji internetowej; punkty końcowe API: w przypadku korzystania z usługi sieciowej
Reguły zapory sieciowej (firewall): Należy skonfigurować zapory sieciowe tak, aby umożliwiały ruch przez wskazane porty. Przykład: otwarcie portu 22 dla adresu IP w zaporze sieciowej Serwera A.

4. Kwestie bezpieczeństwa

Szyfrowanie: Należy zapewnić szyfrowanie danych w trakcie transmisji. Można stosować protokoły takie jak SFTP, HTTPS lub wdrożyć szyfrowanie na poziomie samych danych.
Kontrola dostępu: należy ograniczyć dostęp do niezbędnego personelu i systemów oraz skonfigurować role i uprawnienia użytkowników.

5. Koordynacja techniczna

Konfiguracja sieci: Należy skonfigurować ustawienia sieciowe, takie jak NAT (Network Address Translation), jeśli jest to wymagane. Przykład: skonfigurowanie NAT w celu mapowania wewnętrznych adresów IP na zewnętrzne adresy IP.
Testowanie: Należy przeprowadzić test w celu sprawdzenia łączności i prawidłowości transferu danych. Należy zweryfikować zarówno łączność, jak i integralność danych.

6. Przygotowanie danych

Format pliku: Uzgodnienie formatu przekazywanych danych (np. CSV, JSON, XML).
Rozmiar danych: Należy zadbać o to, aby obie strony znały rozmiar danych i mogły je odpowiednio przetwarzać. Przykład: jeżeli rozmiar pliku przekracza określone limity, należy rozważyć podział danych lub zastosowanie kompresji.

Przykładowe kroki bezpiecznego transferu plików z użyciem SFTP:

Wymiana publicznych kluczy SSH: Należy w bezpieczny sposób udostępnić publiczny klucz SSH każdego serwera i dodać go do autoryzowanych kluczy drugiego serwera.

- Serwer A: Dodaj klucz publiczny Serwera B do `~/.ssh/authorized_keys`.

- Serwer B: Dodać klucz publiczny serwera A do pliku `~/.ssh/authorized_keys`.

2. Konfiguracja zapór sieciowych: należy otworzyć port 22 na obu serwerach, aby umożliwić ruch SFTP.

- `iptables -A INPUT -p tcp -s 203.0.113.5 --dport 22 -j ACCEPT`

- `iptables -A INPUT -p tcp -s 192.168.1.10 --dport 22 -j ACCEPT`

3. Zainicjowanie transferu: Do przesłania plików należy użyć protokołu SFTP.

- Na serwerze A: `sftp user@203.0.113.5`

- Na serwerze B: `sftp user@192.168.1.10`

- Polecenia w ramach SFTP: `put localfile` lub `get remotefile`

4. Weryfikacja: Po zakończeniu transferu należy zweryfikować integralność pliku.

- Porównaj sumy kontrolne: `sha256sum localfile` oraz `sha256sum remotefile`

Faktyczny transfer środków: Protokoły te doskonale nadają się do przekazywania szczegółów transakcji, takich jak komunikaty i instrukcje, lecz nie umożliwiają rzeczywistego przepływu środków.

W przypadku fizycznego transferu środków niezbędne są systemy takie jak bankowość korespondencyjna, Real-Time Gross Settlement (RTGS) oraz Real-Time Payments (RTP).

W bankowości korespondencyjnej środki są przekazywane między rachunkami prowadzonymi w różnych bankach.
W systemie RTGS transfer środków następuje pomiędzy rachunkami rozliczeniowymi prowadzonymi w banku centralnym (bankach centralnych).
Podobnie w systemie RTP środki są przekazywane między rachunkami rozliczeniowymi.

Systemy te mają kluczowe znaczenie dla faktycznego przekazania aktywów pieniężnych. Dlatego bank wysyłający musi nie tylko dysponować możliwościami komunikacji server-to-server, ale także być w pełni zintegrowany z systemem bankowym.

Dwa odrębne poziomy:

Poziom instrukcji i poziom faktycznego transferu środków

Przelew środków do nas w trybie S2S

Aby rozwiać część wątpliwości dotyczących compliance w sytuacji, gdy komunikat pacs.008 został do nas przesłany w trybie S2S, a nie przez SWIFT, Państwa bank wysyłający mógłby rozważyć uwzględnienie poniższych dodatkowych informacji w komunikacie pacs.009 COV w ramach przekazu środków między bankami korespondentami, o ile format na to pozwala:

Informacje o zleceniodawcy: Należy podać dane zleceniodawcy, podobnie jak w polu 50 w MT103. Mogą one obejmować nazwę, adres i numer rachunku.
Dane beneficjenta: Należy podać dane beneficjenta, odpowiadające polu 59 w MT103. Powinny one zawierać nazwę beneficjenta, adres i numer rachunku.
Tytuł płatności: Należy wyraźnie wskazać powód transakcji, co może rozwiać część wątpliwości związanych z przeciwdziałaniem praniu pieniędzy (AML).
Informacje do celów sprawozdawczości regulacyjnej: jeżeli wymaga tego Państwa jurysdykcja, należy podać kody lub identyfikatory służące do celów sprawozdawczości regulacyjnej.
Odniesienie do S2S pacs.008: Wyraźna wzmianka, że pacs.009 COV jest powiązany z S2S pacs.008, może dostarczyć bankowi pośredniczącemu odpowiedniego kontekstu.
Dane kontaktowe: Należy podać szczegółowe dane kontaktowe działu compliance lub menedżera transakcji odpowiedzialnego za tę płatność, na wypadek gdyby bank odbiorcy potrzebował niezwłocznych wyjaśnień.
Szczególne instrukcje dotyczące obsługi: wszelkie dodatkowe instrukcje dla banku odbiorcy, które mogą ułatwić identyfikację i prawidłowe przetworzenie przekazanych środków.
Informacje o opłatach i kosztach: W przypadku braku komunikatu SWIFT pacs.008 warto wyjaśnić, kto poniesie koszty związane z transakcją, aby uniknąć nieporozumień.
Dodatkowe identyfikatory: należy podać wszelkie dodatkowe identyfikatory transakcji, które mogą powiązać komunikat pacs.009 COV z komunikatem S2S pacs.008, takie jak numery faktur lub wewnętrzne identyfikatory transakcji.

Uwaga dotycząca Compliance
Uwzględnienie dodatkowych informacji w komunikacie pacs.009 COV może nie wyeliminować w pełni ryzyk związanych z Compliance, w szczególności kontroli AML i CFT (przeciwdziałanie finansowaniu terroryzmu), które zazwyczaj realizowane są na podstawie komunikatu SWIFT pacs.008; należy zapewnić, aby zmodyfikowany komunikat pacs.009 COV nadal spełniał obowiązujące standardy i umowy międzybankowe.

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:

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.
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.
Szyfrowanie i uwierzytelnianie: Aby zapewnić bezpieczeństwo, serwery komunikacyjne stosują zaawansowane metody szyfrowania oraz rygorystyczne protokoły uwierzytelniania, chroniące dane podczas transmisji.
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.
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:

Prowadzenie ewidencji finansowej: Serwery te przechowują i utrzymują podstawowe rejestry finansowe banku, zapewniając dokładne odnotowanie każdej transakcji.
Rejestrowanie transakcji: Rejestrują wszystkie transakcje, w tym obciążenia i uznania, oraz odpowiadają za aktualizowanie i przechowywanie bieżących sald rachunków.
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.
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.
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 współdziałają z systemami prowadzenia ksiąg. Integracja ta zapewnia aktualizacje w czasie rzeczywistym i spójność w całym ekosystemie finansowym banku, zwiększając zarówno efektywność, jak i bezpieczeństwo.

Warstwy bankowości

Co można przekazywać między bankami?

Aktywa banku:

Środki pieniężne i ekwiwalenty środków pieniężnych: Są to środki, do których dostęp jest natychmiastowy lub niemal natychmiastowy. Obejmują gotówkę, depozyty w innych bankach oraz wysoce płynne papiery wartościowe, takie jak bony skarbowe.
Inwestycje/papiery wartościowe: są to instrumenty finansowe, w które bank inwestuje w celu osiągnięcia zwrotu, takie jak obligacje rządowe i korporacyjne, akcje oraz inne papiery wartościowe.
Kredyty i pożyczki: Są to środki, których bank udziela swoim klientom i które generują przychody odsetkowe. Mogą obejmować pożyczki osobiste, kredyty hipoteczne, kredyty komercyjne, salda kart kredytowych oraz debety na rachunku.
Środki trwałe: Są to składniki majątku rzeczowego stanowiące własność Banku, takie jak budynki, grunty, wyposażenie i meble.
Aktywa niematerialne: Obejmują one aktywa o charakterze niefizycznym, takie jak oprogramowanie, patenty, znaki towarowe oraz wartość firmy (goodwill).
Pozostałe aktywa: Mogą obejmować m.in. naliczone odsetki należne, aktywa z tytułu odroczonego podatku dochodowego oraz pochodne instrumenty finansowe.

Zobowiązania banku:

Depozyty: Są to środki, które osoby fizyczne i przedsiębiorstwa przechowują w banku. Obejmują rachunki bieżące, rachunki oszczędnościowe i lokaty terminowe. Stanowią zobowiązania, ponieważ bank jest obowiązany zwrócić te środki deponentom na żądanie lub w określonym terminie zapadalności.
Środki pożyczone: Są to środki, które bank pozyskuje od innych instytucji finansowych, banku centralnego lub poprzez emisję dłużnych papierów wartościowych.
Papiery dłużne: Są to obligacje lub inne formy zadłużenia emitowane przez bank w celu pozyskania środków. Bank jest zobowiązany do spłaty kapitału i odsetek na rzecz obligatariuszy.
Pozostałe zobowiązania: obejmują takie pozycje jak naliczone koszty, zobowiązania handlowe, rezerwy z tytułu odroczonego podatku dochodowego, rezerwy na straty kredytowe oraz pochodne instrumenty finansowe.
Zobowiązania podporządkowane: Są to długi, które w razie upadłości banku zostaną spłacone dopiero po zaspokojeniu wszystkich pozostałych zobowiązań.

Kapitał własny banku:

Akcje zwykłe: Jest to kapitał własny, którego posiadaczami są właściciele banku. Przysługuje im prawo głosu i mogą otrzymywać dywidendy.
Akcje uprzywilejowane: Ten rodzaj kapitału własnego daje pierwszeństwo w roszczeniach do zysków i aktywów przed akcjami zwykłymi, lecz zazwyczaj nie wiąże się z prawem głosu.
Zyski zatrzymane: Są to zyski netto skumulowane przez bank na przestrzeni lat i przeznaczone na reinwestycję w działalność, zamiast na wypłatę dywidend.
Akcje własne: Są to akcje własne Banku, które zostały przez niego odkupione z rynku.
Pozostałe całkowite dochody: Są to zyski i straty z różnych inwestycji i instrumentów pochodnych, które nie zostały jeszcze zrealizowane.
Udziały mniejszościowe: Jest to część aktywów netto jednostki zależnej przypadająca na udziały kapitałowe, które nie należą, bezpośrednio ani pośrednio przez jednostki zależne, do jednostki dominującej.

Dropbox, OneDrive, WeTransfer itp.

Dropbox, OneDrive, WeTransfer i podobne platformy: są to oparte na chmurze rozwiązania do udostępniania i przechowywania plików. Zostały zaprojektowane w celu ułatwienia przesyłania i przechowywania plików cyfrowych przez internet. Należy jednak rozumieć ich rolę i możliwości we właściwym kontekście transakcji walutowych typu Server-to-Server (S2S), w szczególności w odniesieniu do przekazywania informacji finansowych podobnych do komunikatów pacs.008.

Rola w transakcjach S2S

Przekazywanie informacji: W transakcjach S2S informacje o transakcji, w tym dane, które mogłyby być zawarte w komunikacie SWIFT pacs.008 (standardowym formacie przekazywania informacji o płatnościach), muszą być bezpiecznie przekazywane między bankami. Teoretycznie do przesyłania dokumentów lub plików danych zawierających takie informacje mogłyby służyć usługi takie jak Dropbox czy OneDrive. Byłaby to jednak metoda niekonwencjonalna, ponieważ platformy te nie są przeznaczone przede wszystkim do bezpiecznej komunikacji bankowej ani transakcji finansowych.
Bezpieczeństwo i zgodność z przepisami: Instytucje finansowe z reguły korzystają z bezpiecznych, dedykowanych kanałów komunikacji do przesyłania wrażliwych danych finansowych. Kanały te spełniają rygorystyczne standardy regulacyjne, bezpieczeństwa i ochrony prywatności, którym usługi takie jak Dropbox czy OneDrive mogą nie w pełni odpowiadać, zwłaszcza w kontekście wysoce regulowanej ewidencji transakcji bankowych.

Dlaczego środków nie można „pobrać” z tych platform
W świecie finansów koncepcja przechowywania pieniądza zasadniczo różni się od przechowywania pliku cyfrowego. Waluta, zwłaszcza w kontekście bankowości i transakcji elektronicznych, nie jest przechowywana jako namacalny byt, który można przenosić lub kopiować jak plik. Pieniądz istnieje natomiast jako zapis wartości na rachunkach finansowych prowadzonych przez instytucje bankowe.

Brak funkcjonalności bankowej: Platformy takie jak Dropbox, OneDrive i WeTransfer nie są systemami bankowymi. Nie posiadają funkcjonalności umożliwiającej przetwarzanie transakcji finansowych ani dostęp do sieci bankowych. Są w istocie cyfrowymi skrytkami do przechowywania danych i nie współdziałają z systemami bankowymi, takimi jak RTGS (Real-Time Gross Settlement), RTP (Real-Time Payments) czy sieci bankowości korespondencyjnej.
Brak bezpośredniego połączenia z instytucjami finansowymi: Te usługi udostępniania plików nie są powiązane z infrastrukturą bankową. Banki wykorzystują do przetwarzania i rozliczania płatności wyspecjalizowane, zabezpieczone protokoły i systemy (takie jak SWIFT w przypadku transakcji międzynarodowych). Infrastruktura usług przechowywania danych w chmurze nie współpracuje z tymi systemami bankowymi.
Waluta jako zapis wartości: W systemach bankowych waluta jest reprezentowana jako zapisy cyfrowe lub wpisy w księdze rachunku bankowego. Księgi te są prowadzone przez instytucje finansowe i odzwierciedlają kwotę środków zdeponowanych przez każdego klienta na jego rachunku. Zapisy te nie mają formy fizycznej ani materialnej, lecz stanowią cyfrowe odwzorowanie wartości.
Transakcje jako korekty zapisów w księgach: Gdy dochodzi do transakcji finansowej, na przykład przelewu waluty z jednego rachunku na drugi, nie następuje fizyczne przemieszczenie pieniądza. Transakcja jest realizowana poprzez korektę zapisów księgowych na odpowiednich rachunkach banków korespondentów, banku centralnego (banków centralnych) lub systemów rozliczeniowych RTP. System bankowy zmniejsza saldo na jednym rachunku i zwiększa saldo na drugim, odzwierciedlając transfer wartości, który zostanie rozliczony odrębnie. Uzgodnienie i rozliczenie ostateczne: Banki uczestniczące w transakcji dokonują jej uzgodnienia w celu zapewnienia poprawności. W przypadkach, gdy wykorzystywane są banki pośredniczące, każdy bank rozlicza swoją część transakcji w ramach relacji bankowości korespondencyjnej. Sprawozdawczość i prowadzenie dokumentacji: Banki prowadzą rejestry wszystkich transakcji na potrzeby compliance, audytu i sprawozdawczości.
Niezgodność z systemami przechowywania plików: Ponieważ waluta we współczesnych systemach bankowych jest reprezentowana jako zapisy księgowe w zabezpieczonej bazie danych banku, nie może być przechowywana ani przekazywana za pomocą konwencjonalnych systemów przechowywania i udostępniania plików, takich jak Dropbox, OneDrive czy WeTransfer itp. Platformy te mogą przechowywać i przesyłać pliki cyfrowe zawierające informacje o transakcjach (np. zestawienia transakcji, umowy lub odpowiedniki komunikatów SWIFT), nie mogą jednak przechowywać samej wartości pieniężnej.
Bezpieczeństwo i regulacje: zarządzanie środkami pieniężnymi w ramach tych ksiąg bankowych podlega rygorystycznym protokołom bezpieczeństwa, przepisom finansowym i nadzorowi. Banki korzystają z wysoce bezpiecznych, wyspecjalizowanych systemów do prowadzenia rachunków i ewidencjonowania zrealizowanych transakcji. Systemy te zapewniają integralność, poufność i dokładność danych finansowych, czemu nie są w stanie sprostać ogólne usługi przechowywania plików.

Czytaj więcej

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.