Bankowość, skarb i łączność ISO 20022
Płatności wychodzące, wyciągi przychodzące, uzgadniane automatycznie w każdej walucie
Zespoły skarbu nadal ręcznie przepisują płatności i dopasowują wyciągi
Wiele zespołów skarbu wprowadza płatności do portali bankowych, zbiera wyciągi w różnych formatach od każdego banku i uzgadnia rachunki w arkuszach na koniec miesiąca. Każdy ręczny krok to opóźnienie, koszt i ryzyko oszustwa lub błędu.
Banki przechodzą też na ISO 20022, międzynarodowy standard komunikatów finansowych, który niesie bogatsze, ustrukturyzowane dane niż starsze formaty SWIFT MT. Systemy, które nie umieją go tworzyć i czytać, zostają za swoimi bankami.
Co się zmienia
Przetwarzanie straight-through (STP)
Zatwierdzone serie płatności opuszczają ERP jako podpisane pliki lub wywołania API, a wyciągi wracają w postaci, którą ERP dopasowuje samodzielnie.
Szybsze zamknięcie
Wielowalutowe uzgadnianie działające codziennie, zamiast ręcznych wysyłek CSV i korekt w arkuszach na koniec miesiąca.
Każdy wyjątek z osobą
Odrzucone płatności i niedopasowane pozycje trafiają do kolejki wyjątków komunikatów niedoręczonych z przyczyną, nigdy nie ginąc w skrzynce pocztowej.
Co dostarczamy
Łączność host-to-host i bezpośrednia z bankiem
Połączenia przez SFTP, EBICS i SWIFT oraz API bankowości otwartej i bezpośrednie API banków, wybierane dla każdego banku i kraju.
Generowanie plików płatności
Pliki płatności ISO 20022 pain.001 tworzone z Państwa serii płatności, walidowane pod kątem wariantu każdego banku i podpisywane lub szyfrowane zgodnie z jego wymaganiami.
Obsługa statusów i odrzuceń
Raporty statusu pain.002 odczytywane z powrotem, więc każda płatność ma status przyjętej, odrzuconej lub oczekującej wraz z kodem przyczyny banku.
Pobieranie wyciągów
Wyciągi camt.053 i MT940 na koniec dnia oraz raporty intraday zbierane, sprawdzane pod kątem luk i duplikatów i wczytywane do ERP.
Komunikaty międzybankowe dla banków i fintechów
Komunikaty pacs dla przelewów i ich statusów między instytucjami finansowymi, połączone z księgami bankowości rdzeniowej.
Wielowalutowe uzgadnianie
Reguły dopasowania rozliczające automatycznie pozycje otwarte w walutach i na rachunkach oraz kierujące resztę do kolejki wyjątków.
Dowody testów bankowych i instrukcje operacyjne
Przypadki testowe każdego banku uruchamiane i rejestrowane dla Państwa audytorów oraz alerty o brakujących plikach, nieudanych przelewach i wygasających kluczach lub certyfikatach.
Jak pracujemy
Zmapować banki i przepływy
Spisujemy Państwa banki, rachunki, typy płatności i obecne kroki ręczne oraz uzgadniamy, które przepływy idą pierwsze.
Określić każdy format
Pracujemy na podstawie przewodnika wdrożenia każdego banku i piszemy mapowanie, w tym podpisywanie, szyfrowanie i nazewnictwo plików.
Zbudować konektory
Budujemy eksport płatności, import statusów, import wyciągów i dopasowanie, z automatycznymi testami każdego formatu.
Testować z każdym bankiem
Uruchamiamy uzgodnione przypadki testowe w środowisku testowym banku i poprawiamy wszystko, co odrzuci jego walidacja.
Wdrażać bank po banku
Przełączamy banki jeden po drugim, z obecnym procesem gotowym jako rezerwą, dopóki nowy się nie sprawdzi.
Monitorować i wspierać
Obserwujemy przelewy, klucze i wygasanie certyfikatów oraz planujemy zmiany formatów zapowiadane przez banki.
Prosimy przewinąć w bok, aby zobaczyć cały rysunek.
ERP do banku: płatności na zewnątrz, wyciągi do środka
Zatwierdzone płatności opuszczają ERP jako podpisane pliki ISO 20022 kanałem host-to-host. Raporty statusów i wyciągi wracają tą samą drogą i są dopasowywane do otwartych pozycji. Odrzucenia i niedopasowane linie trafiają do Państwa zespołu wraz z przyczyną.
- Ścieżka główna
- Asynchroniczny
- Ścieżka wyjątku
Przepływ w 10 krokach
Przepływ krok po kroku
- Od ERP do Warstwa integracji: Zatwierdzone zlecenie płatnicze przez REST/JSON · IDoc (ścieżka główna).
- Od Warstwa integracji do Bezpieczny kanał bankowy: Podpisany i szyfrowany plik płatności przez ISO 20022 pain.001 · OpenPGP (ścieżka główna).
- Od Bezpieczny kanał bankowy do Bank: Dostarczony do banku przez SFTP H2H (ścieżka główna).
- Od Bank do Bezpieczny kanał bankowy: Raporty statusów i wyciągi przez pain.002 · camt.053 · MT940 (asynchroniczny).
- Od Bezpieczny kanał bankowy do Warstwa integracji: Zebrane i zweryfikowane przez SFTP H2H (asynchroniczny).
- Od Warstwa integracji do Silnik uzgadniania: Linie wyciągu przez camt.053 (asynchroniczny).
- Od Silnik uzgadniania do ERP: Dopasowane zapisy zaksięgowane przez REST/JSON (ścieżka główna).
- Od Warstwa integracji do Zespół skarbowości i finansów: Odrzucone płatności z kodem przyczyny przez pain.002 RJCT (ścieżka wyjątku).
- Od Silnik uzgadniania do Zespół skarbowości i finansów: Niedopasowane linie: różnica uzgodnieniowa (ścieżka wyjątku).
- Od Zespół skarbowości i finansów do ERP: Poprawione i przesłane ponownie (ścieżka wyjątku).
Prosimy przewinąć w bok, aby zobaczyć cały rysunek.
Open banking: dane i płatności za zgodą klienta
Klient udziela zgody, konektor przechowuje tokeny, a każde wywołanie banku jest autoryzowane i rejestrowane. Gdy zgoda wygaśnie lub zostanie wycofana, aplikacja prosi klienta o nową, zamiast po cichu zawieść.
- Ścieżka główna
- Asynchroniczny
- Ścieżka wyjątku
Przepływ w 7 krokach
Przepływ krok po kroku
- Od Klient do Państwa aplikacja lub platforma: Udziela zgody (ścieżka główna).
- Od Państwa aplikacja lub platforma do Konektor bankowości otwartej: Żądania dotyczące rachunku i płatności przez REST/JSON (ścieżka główna).
- Od Konektor bankowości otwartej do API banków lub agregator: Autoryzowane wywołania API przez OAuth 2.0 · FAPI · REST (ścieżka główna).
- Od API banków lub agregator do Konektor bankowości otwartej: Salda, transakcje i status płatności przez REST/JSON · webhook (asynchroniczny).
- Od Konektor bankowości otwartej do ERP lub księga: Znormalizowane transakcje przez REST/JSON (ścieżka główna).
- Od API banków lub agregator do Konektor bankowości otwartej: Zgoda wygasła lub została wycofana przez HTTP 401 · 403 (ścieżka wyjątku).
- Od Konektor bankowości otwartej do Państwa aplikacja lub platforma: Klient poproszony o odnowienie zgody (ścieżka wyjątku).
Standardy, formaty i kanały
Budujemy na podstawie przewodnika wdrożenia każdego banku, a nie samego standardu. Wymienienie produktu nie oznacza partnerstwa z jego dostawcą.
- Standardy i kanały bankowe
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- Swift
- EBICS
- SFTP (H2H)
- OpenPGP
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
Sprawdzone na produkcji
Dla banku i regionalnego konglomeratu klasy Tier-1 z regionu Zatoki połączyliśmy SAP S/4HANA z regionalną infrastrukturą bankową przez ISO 20022. Płatności są podpisywane, wyjątki trafiają do kolejek komunikatów niedoręczonych, a uzgadnianie na wszystkich rachunkach bankowych jest automatyczne.
Jak zacząć
Jasne wymagania dotyczące banków i formatów trafiają prosto do oferty. Kilka banków, krajów lub nieudokumentowany interfejs dziedziczony zwykle zaczyna się od Blueprint Studio lub Brownfield Diagnostic Bridge.
Co dalej
Sesja przeddoradcza
To bezpłatna 30-minutowa konsultacja wstępna online: omawiamy Państwa cele, systemy i ograniczenia.
Ocena gotowości
To bezpłatna 48-godzinna ocena gotowości: główny architekt sprawdza projekt pod kątem 6-punktowej definicji gotowości i rekomenduje dopasowaną ścieżkę.
Wybór ścieżki
Projekty gotowe zakresowo otrzymują wiążącą ofertę w ciągu 3–5 dni roboczych. Projekty na etapie koncepcji zaczynają się w Blueprint Studio. Działający system, który zawodzi, nie ma dokumentacji lub wymaga integracji, zaczyna się od diagnostyki: 1–2 tygodnie. Blueprint Studio i diagnostyka mają stałą opłatę podaną w ofercie.
Dostarczanie w pięciu etapach
Mobilizacja, sprinty z demonstracjami na żywo, integracja i utwardzanie, odbiór i uruchomienie produkcyjne, a następnie usługi zarządzane. Po starcie następuje okres gwarancji, a następnie opcjonalne wsparcie i utrzymanie.
Projekty z ustalonym rezultatem i całodobowe usługi zarządzane
Dostarczanie o stałym zakresie, oparte na kamieniach milowych, ze wskazanymi liderami realizacji oraz całodobowe usługi zarządzane aplikacjami pod nadzorem SLA.
Osadzeni specjaliści i wzmocnienie strategiczne
Inżynierowie główni i specjaliści nearshore i na miejscu oraz osadzeni architekci rozwiązań, transformacji, PQC i integracji.
Pytania i odpowiedzi
Czym jest ISO 20022 i dlaczego ma znaczenie?
ISO 20022 to międzynarodowy standard komunikatów finansowych. Jego komunikaty XML niosą ustrukturyzowane dane, takie jak pełne nazwy, adresy i szczegóły tytułu płatności, których starsze formaty SWIFT MT nie przenoszą. Banki i systemy płatności na niego przeszły, więc pliki płatności i wyciągów na nim oparte lepiej się uzgadniają i częściej przechodzą kontrole zgodności.
Z jakimi formatami i kanałami bankowymi pracują Państwo?
Używamy pain.001 do płatności, pain.002 do statusów, camt.052, camt.053 i camt.054 do raportów rachunków oraz komunikatów pacs między bankami. Odczytujemy też wyciągi MT940 i MT942, które wiele banków nadal wysyła. Transport to host-to-host SFTP, EBICS, SWIFT lub API banków. Każdy bank ma własny wariant każdego formatu, więc budujemy na podstawie jego przewodnika wdrożenia.
Z jakimi systemami ERP można połączyć banki?
SAP S/4HANA, Oracle Fusion Cloud ERP i NetSuite, Microsoft Dynamics 365, Odoo i Sage, a także systemy skarbu i systemy niestandardowe. Gdy ERP ma własny moduł komunikacji bankowej, konfigurujemy go i rozszerzamy, zamiast budować obok.
Jak chronią Państwo pliki płatności?
Pliki płatności są podpisywane i szyfrowane zgodnie z wymaganiami każdego banku i przesyłane wyłącznie uzgodnionym kanałem. Klucze i certyfikaty przechowujemy w Państwa sejfie kluczy lub module bezpieczeństwa sprzętowego (HSM), nigdy w kodzie. Pliki są walidowane przed wysłaniem, a każdy przelew jest rejestrowany, więc można prześledzić, kto zatwierdził i wysłał każdą płatność.
Co się dzieje, gdy pozycja wyciągu nie pasuje?
Trafia na listę przeglądu z prawdopodobnymi kandydatami i przyczyną braku dopasowania, taką jak inna kwota lub brak referencji. Państwa zespół zamyka ją tam, a reguły można dostroić, aby ten sam przypadek pasował następnym razem. Nic nie jest księgowane bez zatwierdzonego dopasowania.
Co wyznacza tempo integracji bankowej?
Głównie bank, nie kod. Każdy bank ustala własne kroki onboardingu, okna testowe i zatwierdzenia, a niektóre wymagają umów lub wymiany kluczy przed testami. Po etapie mapowania dajemy Państwu plan dla każdego banku i zaczynamy testy z tym, który jest gotowy pierwszy.
Co się dzieje, gdy bank zmienia format?
Banki zapowiadają zmiany formatów z wyprzedzeniem, jak wiele zrobiło przy przejściu z SWIFT MT na ISO 20022. Śledzimy te komunikaty dla banków, z którymi jesteśmy połączeni, oceniamy wpływ i planujemy zmianę oraz jej testy z bankiem przed terminem.
Gotowi do budowy? Prosimy poprosić o ofertę.
Prosimy przesłać wymagania lub RFP. Nasi architekci je weryfikują i zwracają wiążącą ofertę o stałym zakresie.
Co dalej
Ocena gotowości
To bezpłatna 48-godzinna ocena gotowości: główny architekt sprawdza projekt pod kątem 6-punktowej definicji gotowości i rekomenduje dopasowaną ścieżkę.
Wiążąca oferta
Najpierw walidacja architektury bez ponoszenia kosztów, a następnie wiążąca oferta o stałym zakresie w ciągu 3–5 dni roboczych: kamienie milowe, architektura, struktura zespołu i SLA. Na życzenie podpisujemy z Państwem umowę o zachowaniu poufności (NDA), zanim przekażą Państwo wymagania.
Mobilizacja
Po podpisaniu umowy nasze zespoły inżynierskie rozpoczynają Sprint 0 w ciągu 5–10 dni roboczych od podpisania umowy.
Dostarczanie w pięciu etapach
Mobilizacja, sprinty z demonstracjami na żywo, integracja i utwardzanie, odbiór i uruchomienie produkcyjne, a następnie usługi zarządzane. Po starcie następuje okres gwarancji, a następnie opcjonalne wsparcie i utrzymanie.