Co to jest Open Banking?

Open banking zmienił sposób, w jaki dane finansowe i usługi bankowe mogą być wykorzystywane poza tradycyjnym środowiskiem bankowym. Pozwala klientom bezpiecznie udostępniać wybrane dane dotyczące rachunków lub inicjować płatności za pośrednictwem zewnętrznych dostawców, zazwyczaj poprzez regulowane API i za wyraźną zgodą klienta.

Dla firm open banking jest czymś znacznie więcej niż standardem technicznym. Tworzy nowe możliwości w obszarze płatności, lendingu, zarządzania finansami, onboardingu, weryfikacji i embedded finance. Firmy FinTech mogą wykorzystywać go do tworzenia nowych produktów finansowych, natomiast biznesy e-commerce i SaaS mogą dodawać funkcje finansowe bezpośrednio do istniejących customer journeys.

Koncepcja ma charakter globalny, ale open banking nie działa dokładnie tak samo na każdym rynku. Unia Europejska i Wielka Brytania odegrały istotną rolę w jego rozwoju, a regulacje pomogły stworzyć prawne i techniczne ramy bezpiecznego dostępu do danych bankowych oraz inicjowania płatności. Inne rynki wybrały odmienne modele, od systemów rozwijanych przede wszystkim poprzez regulacje po podejścia bardziej rynkowe.

Czym więc jest open banking w praktyce, jak działa i gdzie tworzy realną wartość biznesową? W tym artykule wyjaśniamy technologię, rolę API open banking, główne use case'y, bezpieczeństwo, regulacje oraz kwestie, które firmy powinny uwzględnić podczas budowania produktów opartych na open banking.

Spis treści

1. Czym jest open banking?
2. Jak działa open banking?
3. Czym jest API open banking?
4. Informacje o rachunku i inicjowanie płatności
5. Do czego wykorzystuje się open banking?
6. Płatności open banking
7. Open banking loans i lending
8. Czy open banking jest bezpieczny?
9. Open banking w Unii Europejskiej
10. Open banking w Wielkiej Brytanii
11. Open banking na świecie
12. Open banking a open finance
13. Co open banking oznacza dla firm FinTech, e-commerce i SaaS
14. Budowanie produktu z wykorzystaniem open banking
15. Wyzwania i ograniczenia open banking
16. Co dalej z open banking?
17. FAQ
18. Podsumowanie

1. Czym jest open banking?

Open banking to model, który pozwala klientom udzielić autoryzowanym zewnętrznym dostawcom dostępu do wybranych danych bankowych lub funkcji płatniczych. Dostęp ten jest zazwyczaj realizowany poprzez bezpieczne API i dopiero po udzieleniu przez klienta wyraźnej zgody.

W prostych słowach open banking pozwala rachunkowi bankowemu stać się częścią szerszego ekosystemu produktów cyfrowych. Klient może korzystać z aplikacji FinTech, checkoutu e-commerce, platformy lendingowej lub narzędzia do zarządzania finansami firmy, które łączy się z jego bankiem i wykorzystuje określone informacje lub funkcje płatnicze.

Najważniejsze jest to, że klient zachowuje kontrolę. Open banking nie oznacza, że banki publicznie udostępniają rachunki klientów. Oznacza, że klienci mogą zdecydować, który dostawca może uzyskać dostęp do określonych informacji, w jakim celu oraz, w zależności od usługi, na jak długo.

Może to obejmować dostęp do takich informacji jak saldo rachunku, historia transakcji lub dane rachunku. Może również pozwalać autoryzowanemu dostawcy na zainicjowanie płatności bezpośrednio z rachunku bankowego klienta.

Dla firm tworzy to warstwę infrastruktury finansowej, którą można zintegrować z produktami i usługami. Zamiast prosić klientów o ręczne przesyłanie wyciągów bankowych, wpisywanie danych finansowych czy wykonywanie oddzielnego przelewu bankowego, firma może stworzyć bardziej bezpośredni proces cyfrowy.

Open banking nie jest więc jednym konkretnym produktem. To model infrastrukturalny umożliwiający tworzenie wielu różnych produktów, w tym agregacji rachunków, inicjowania płatności, narzędzi do zarządzania finansami, lendingu, weryfikacji dochodu, integracji księgowych oraz embedded financial services.

Ważne jest również rozróżnienie open banking od starszych metod dostępu do bankowości internetowej. W nowoczesnych, regulowanych środowiskach open banking zewnętrzny dostawca zazwyczaj nie musi otrzymywać ani przechowywać hasła klienta do bankowości internetowej. Klient uwierzytelnia się bezpośrednio w swoim banku, a dostawca otrzymuje dostęp wyłącznie do konkretnych danych lub funkcji, które zostały autoryzowane.

To rozróżnienie ma znaczenie zarówno z perspektywy bezpieczeństwa, jak i produktu. Open banking jest projektowany wokół kontrolowanego dostępu, jasno określonych uprawnień oraz zdefiniowanych ról banków, zewnętrznych dostawców i klientów.

Z biznesowego punktu widzenia prawdziwą wartością nie jest samo API. Wartość wynika z tego, co firma może na nim zbudować: szybszy checkout, lepszą ocenę kredytową, automatyczną rekonsyliację, sprawniejszy onboarding lub produkt finansowy, który trudno byłoby zaoferować bez bezpośredniego dostępu do danych bankowych lub infrastruktury płatniczej.

2. Jak działa open banking?

Open banking działa poprzez stworzenie kontrolowanego połączenia pomiędzy bankiem, klientem i autoryzowanym zewnętrznym dostawcą. Klient decyduje, kiedy takie połączenie ma zostać utworzone i jaki rodzaj dostępu powinien zostać przyznany.

Typowy proces open banking rozpoczyna się w aplikacji zewnętrznego dostawcy. Może to być aplikacja FinTech, platforma lendingowa, checkout e-commerce lub narzędzie do zarządzania finansami. Klient wybiera opcję połączenia rachunku bankowego lub skorzystania z metody płatności opartej na rachunku bankowym.

Następnie użytkownik jest proszony o wybór banku i zatwierdzenie wymaganego dostępu. W większości regulowanych środowisk open banking uwierzytelnienie odbywa się bezpośrednio w banku. Zewnętrzny dostawca nie musi pozyskiwać danych logowania klienta do bankowości internetowej.

Po uwierzytelnieniu klienta bank sprawdza uprawnienia wymagane przez zewnętrznego dostawcę. Mogą one dotyczyć informacji o rachunku, inicjowania płatności lub obu tych funkcji. Następnie klient potwierdza zgodę.

Po udzieleniu zgody systemy komunikują się poprzez API. Bank może przekazać autoryzowane informacje o rachunku zewnętrznemu dostawcy lub przetworzyć żądanie zainicjowania płatności.

Uproszczony proces wygląda następująco:

Klient → aplikacja zewnętrznego dostawcy → zgoda klienta i uwierzytelnienie w banku → API banku → dane lub działanie płatnicze

Z perspektywy użytkownika proces może wyglądać prosto, ale w tle działa kilka warstw. Obejmują one uwierzytelnianie, autoryzację, komunikację API, zarządzanie zgodami, kontrole bezpieczeństwa oraz, na rynkach regulowanych, weryfikację, czy zewnętrzny dostawca posiada odpowiednie uprawnienia do świadczenia danej usługi.

Dokładny przebieg zależy od use case'u. Aplikacja do zarządzania finansami osobistymi może poprosić o dostęp do historii transakcji i sald. Pożyczkodawca może wykorzystać dane rachunku do weryfikacji dochodu i analizy cash flow. Firma e-commerce może wykorzystać open banking, aby umożliwić klientowi zapłatę bezpośrednio z rachunku bankowego.

Inicjowanie płatności działa inaczej niż dostęp do danych. Zamiast pobierać informacje zewnętrzny dostawca wysyła do banku klienta żądanie zainicjowania przelewu. Bank uwierzytelnia klienta, potwierdza płatność i realizuje ją poprzez odpowiednią infrastrukturę płatniczą.

Dostawcy open banking mogą łączyć się bezpośrednio z poszczególnymi bankami, ale wiele firm korzysta z agregatora lub dostawcy infrastruktury. Tacy dostawcy utrzymują integracje z wieloma bankami i udostępniają je poprzez jedną warstwę techniczną. Może to znacząco ograniczyć pracę integracyjną, szczególnie w przypadku produktów działających w kilku krajach.

Korzystanie z jednego API nie oznacza jednak, że każdy bank działa dokładnie w ten sam sposób. Wydajność API, procesy uwierzytelniania, dostępne dane, obsługa błędów i możliwości płatnicze mogą różnić się pomiędzy instytucjami i rynkami. Jest to jedno z głównych praktycznych wyzwań podczas budowania produktów open banking w dużej skali.

Z perspektywy produktu połączenie API jest tylko jednym elementem customer journey. Konwersja zależy od tego, jak dobrze użytkownik rozumie, dlaczego dostęp jest potrzebny, jak łatwo może znaleźć swój bank, jak płynny jest proces uwierzytelniania oraz co dzieje się w przypadku nieudanego połączenia.

Dlatego dobra implementacja open banking wymaga czegoś więcej niż integracji technicznej. Projekt produktu, architektura regulacyjna, coverage banków, user experience i niezawodność operacyjna mają bezpośredni wpływ na to, czy usługa działa dobrze w praktyce.

---

Myślisz o wdrożeniu open banking w swoim biznesie? 
z3x może pomóc Ci zdefiniować właściwy use case, wybrać odpowiednią technologię i model regulacyjny oraz przekształcić je w działający produkt.

---

3. Czym jest API open banking?

API open banking to interfejs techniczny, który pozwala bankom i autoryzowanym zewnętrznym dostawcom wymieniać dane lub instrukcje płatnicze w ustrukturyzowany i kontrolowany sposób. Jest to warstwa połączeniowa umożliwiająca działanie większości nowoczesnych usług open banking.

W praktyce API open banking może pozwolić zewnętrznej aplikacji poprosić bank o konkretne informacje lub wysłać żądanie zainicjowania płatności. Dokładne możliwości zależą od banku, rynku oraz frameworku regulacyjnego, w ramach którego świadczona jest usługa.

Na przykład API może zapewniać dostęp do danych rachunku, salda, historii transakcji lub innych informacji związanych z rachunkiem płatniczym. W przypadku płatności API może pozwalać dostawcy przesłać instrukcję płatniczą po uwierzytelnieniu klienta i zatwierdzeniu transakcji.

Samo API nie zapewnia stronie trzeciej nieograniczonego dostępu do rachunku bankowego klienta. Dostęp jest ograniczony przez uprawnienia udzielone przez klienta oraz zakres usługi, do której świadczenia dostawca jest uprawniony.

To ważne rozróżnienie. Z perspektywy produktu API open banking nie jest bezpośrednim połączeniem ze wszystkim, co bank wie o kliencie. Jest kontrolowanym interfejsem posiadającym określone endpointy, uprawnienia, zasady bezpieczeństwa i struktury danych.

Dla firm budujących produkty open banking jakość API ma bardzo duże znaczenie. Dokumentacja, uptime, czas odpowiedzi, obsługa błędów, procesy uwierzytelniania i spójność zwracanych danych mogą wpływać na końcowe customer experience.

Standaryzacja może ograniczyć część tych problemów, ale nie eliminuje ich całkowicie. Nawet na rynkach, gdzie open banking jest regulowany, różne banki mogą wdrażać wymagania w nieco inny sposób lub oferować różny poziom jakości API.

Jest to jeden z powodów, dla których wiele firm FinTech, SaaS i e-commerce korzysta z dostawcy infrastruktury open banking lub agregatora API. Zamiast budować i utrzymywać osobne integracje z wieloma bankami, integrują się z jednym dostawcą zarządzającym wieloma połączeniami bankowymi poprzez wspólne API.

Podejście to może ograniczyć złożoność techniczną i przyspieszyć wejście na rynek. Może również ułatwić ekspansję na kolejne banki lub kraje, chociaż firmy nadal muszą uwzględnić coverage, niezawodność, pricing, odpowiedzialności regulacyjne oraz jakość poszczególnych połączeń.

W przypadku większych lub bardziej wyspecjalizowanych produktów bezpośrednie integracje nadal mogą mieć sens. Decyzja pomiędzy bezpośrednimi integracjami bankowymi a agregatorem zależy od takich czynników jak zakres geograficzny, wolumen transakcji, wymagana funkcjonalność, wewnętrzne zasoby techniczne oraz poziom kontroli potrzebny firmie.

Z biznesowego punktu widzenia API open banking nie powinno być traktowane jako sam produkt. To infrastruktura. Wartość produktu wynika z doświadczenia, procesu lub usługi finansowej, które firma buduje na tej infrastrukturze.

4. Informacje o rachunku i inicjowanie płatności

Większość usług open banking można zrozumieć poprzez dwa podstawowe rodzaje funkcjonalności: dostęp do informacji o rachunku oraz inicjowanie płatności. Wykorzystują podobną infrastrukturę, ale rozwiązują inne problemy biznesowe i prowadzą do tworzenia innych rodzajów produktów.

Informacje o rachunku

Usługi dostępu do informacji o rachunku pozwalają autoryzowanemu dostawcy uzyskać dostęp do wybranych danych z rachunku bankowego klienta po udzieleniu przez niego zgody.

W zależności od rynku i dostępnego API może to obejmować dane rachunku, aktualne saldo, historię transakcji oraz inne informacje dotyczące rachunku płatniczego. Dostawca może następnie wykorzystywać te dane we własnym produkcie lub usłudze.

Na przykład aplikacja do zarządzania finansami osobistymi może wykorzystywać informacje o rachunkach, aby wyświetlać rachunki z kilku banków w jednym interfejsie. Platforma finansowa dla firm może wykorzystywać je do analizy cash flow lub wsparcia rekonsyliacji. Pożyczkodawca może wykorzystywać dane transakcyjne jako część weryfikacji dochodów lub oceny kredytowej.

Główną zaletą jest możliwość pobierania informacji finansowych bezpośrednio ze źródła zamiast ręcznego wprowadzania ich przez klienta. Może to ograniczać tarcie, poprawiać dokładność danych i umożliwiać bardziej zautomatyzowane podejmowanie decyzji.

Dostęp do informacji o rachunku nie jest jednak nieograniczony. Dostawca powinien otrzymywać wyłącznie dane wymagane do świadczenia usługi i w zakresie zatwierdzonym przez klienta. Zarządzanie zgodami jest więc centralnym elementem projektowania produktu.

Inicjowanie płatności

Inicjowanie płatności działa inaczej, ponieważ dostawca nie tylko pobiera informacje. Wysyła do banku klienta instrukcję zainicjowania płatności z rachunku klienta.

Klient zazwyczaj rozpoczyna proces w aplikacji merchanta, firmy FinTech lub dostawcy usługi. Użytkownik wybiera bank, uwierzytelnia się w nim i zatwierdza płatność. Bank następnie przetwarza instrukcję poprzez odpowiednią infrastrukturę płatniczą.

Tworzy to przepływ płatności account-to-account bez konieczności ręcznego kopiowania danych bankowych i tworzenia przelewu w osobnej aplikacji bankowej.

W przypadku e-commerce i innych biznesów cyfrowych może to stworzyć alternatywną metodę płatności w checkout. Dla firm FinTech ta sama funkcjonalność może być osadzona w takich produktach jak portfele, platformy inwestycyjne, usługi lendingowe czy aplikacje do zarządzania finansami.

Ekonomia i customer experience inicjowania płatności mogą znacząco różnić się od płatności kartowych. Płatności open banking mogą usuwać część warstw tradycyjnego card value chain, ale mają również własne wymagania operacyjne, wyzwania UX i ograniczenia zależne od rynku.

Dlatego inicjowania płatności nie należy oceniać wyłącznie jako technicznego payment rail. Firmy muszą uwzględniać konwersję, uwierzytelnianie, settlement, refundy, rekonsyliację, customer support oraz metody płatności, które użytkownicy już preferują na danym rynku.

Dostęp do informacji o rachunku i inicjowanie płatności można również łączyć. Produkt może najpierw analizować dane rachunku, a następnie pozwolić klientowi dokonać płatności w ramach tego samego procesu.

Takie połączenie jest szczególnie istotne w bardziej zaawansowanych produktach FinTech. Pozwala firmom przejść od samego odczytywania danych finansowych do budowania usług, które jednocześnie rozumieją sytuację finansową klienta i umożliwiają wykonanie działania na podstawie tych informacji.

5. Do czego wykorzystuje się open banking?

Open banking jest wykorzystywany wszędzie tam, gdzie firma potrzebuje bezpiecznego dostępu do danych rachunku bankowego lub chce umożliwić klientowi zainicjowanie płatności bezpośrednio z rachunku bankowego. Technologia może wspierać zarówno samodzielne produkty finansowe, jak i funkcje finansowe osadzone w usługach niefinansowych.

Najsilniejsze use case'y to zazwyczaj te, w których open banking usuwa ręczny etap procesu, poprawia dostęp do danych finansowych lub tworzy bardziej bezpośredni przepływ płatności. Wartość nie znajduje się więc w samym połączeniu, lecz w procesie, który dzięki niemu staje się szybszy, bardziej zautomatyzowany lub łatwiejszy w użyciu.

Agregacja rachunków

Agregacja rachunków pozwala użytkownikom łączyć rachunki z różnych banków i przeglądać je w jednym miejscu. Jest to jeden z najbardziej ugruntowanych use case'ów open banking.

Dla konsumentów może wspierać narzędzia do zarządzania finansami osobistymi i budżetowania. Dla firm może zapewniać skonsolidowany widok pozycji gotówkowych na kilku rachunkach i w kilku bankach.

Te same dane mogą być również wykorzystywane przez zespoły finansowe, platformy księgowe i narzędzia treasury. Zamiast logować się do kilku systemów bankowych użytkownicy mogą uzyskać dostęp do wybranych informacji finansowych poprzez jeden interfejs.

Zarządzanie finansami osobistymi i firmowymi

Open banking może zapewnić platformom do zarządzania finansami dostęp do aktualnych danych transakcyjnych i sald rachunków. Pozwala im to oferować bardziej użyteczne i aktualne informacje.

Na przykład platforma finansowa dla firm może kategoryzować transakcje, monitorować cash flow oraz identyfikować zmiany w wydatkach lub przychodach. W przypadku MŚP może to zwiększyć automatyzację zarządzania finansami bez konieczności budowania złożonych integracji z każdym bankiem.

Dla zespołów produktowych dostęp do danych jest jednak tylko punktem wyjścia. To jakość kategoryzacji, analiz i rekomendacji decyduje o tym, czy produkt rzeczywiście tworzy wartość dla użytkownika.

Weryfikacja dochodu i rachunku

Open banking może być również wykorzystywany do weryfikacji informacji, które wcześniej klienci musieli dostarczać ręcznie.

Pożyczkodawca może poprosić klienta o połączenie rachunku bankowego zamiast przesyłania wyciągów bankowych z kilku miesięcy. Platforma FinTech może wykorzystać informacje o rachunku do potwierdzenia jego własności lub sprawdzenia, czy na rachunek regularnie wpływają dochody.

Może to przyspieszyć procesy onboardingu i weryfikacji. Może również ograniczyć ilość ręcznie wprowadzanych danych, które musi następnie sprawdzać zespół operacyjny.

Dokładny zakres dostępnych informacji zależy od rynku, banku i API. Firmy powinny więc projektować procesy weryfikacji wokół danych, do których mogą uzyskać wiarygodny dostęp, zamiast zakładać, że każde połączenie bankowe zwróci identyczne informacje.

Ocena kredytowa i lending

Pożyczkodawcy mogą wykorzystywać dane open banking jako jedno ze źródeł informacji w procesie oceny kredytowej. Historia transakcji może dostarczać danych dotyczących wzorców dochodów, regularnych wydatków, istniejących zobowiązań finansowych i ogólnego cash flow.

Może być to szczególnie przydatne wtedy, gdy tradycyjne dane kredytowe zapewniają jedynie ograniczony obraz sytuacji wnioskodawcy. Open banking może uzupełnić go o bardziej aktualny obraz zachowań finansowych.

Dane nie podejmują decyzji kredytowej samodzielnie. Nadal muszą być interpretowane poprzez modele ryzyka, polityki lendingowe, wymogi regulacyjne i własny proces underwritingowy pożyczkodawcy.

Ten use case omawiamy szerzej w sekcji dotyczącej open banking loans.

Księgowość i rekonsyliacja

Oprogramowanie księgowe i platformy finansowe mogą wykorzystywać open banking do automatycznego importowania danych o transakcjach bankowych.

Może to ograniczyć potrzebę ręcznego przesyłania plików lub okresowego eksportowania danych z bankowości internetowej. Transakcje mogą być dopasowywane do faktur, wydatków lub zapisów księgowych przy mniejszej ilości pracy manualnej.

To samo podejście może wspierać rekonsyliację w firmach otrzymujących dużą liczbę płatności. W takim przypadku wartość biznesowa wynika z automatyzacji operacyjnej, a nie z customer-facing experience open banking.

Płatności

Open banking może być również wykorzystywany do inicjowania płatności bezpośrednio z rachunku bankowego klienta.

Ma to szczególne znaczenie dla e-commerce, marketplace'ów, platform finansowych i innych biznesów cyfrowych. Klient może wybrać swój bank, uwierzytelnić się i zatwierdzić płatność bez ręcznego tworzenia przelewu bankowego.

Ten sam mechanizm może być również osadzony w aplikacjach FinTech. Może na przykład służyć do zasilenia rachunku inwestycyjnego, spłaty pożyczki lub przelania środków do innego produktu finansowego.

Embedded financial services

Open banking jest również ważnym elementem embedded finance.

Firma SaaS nie musi koniecznie stawać się pełnoprawną instytucją finansową, aby dodać do produktu użyteczne funkcje finansowe. Może wykorzystać infrastrukturę open banking do zapewnienia łączności z rachunkami, analizy transakcji, płatności czy dashboardów finansowych.

Jest to szczególnie istotne dla platform vertical SaaS. Platforma obsługująca restauracje, retailerów, freelancerów lub firmy logistyczne może już rozumieć operacyjny kontekst swoich klientów i dodać funkcjonalność finansową bezpośrednio do tego samego workflow.

W takich przypadkach open banking działa najlepiej wtedy, gdy funkcja finansowa stanowi część szerszego produktu, a nie oddzielną usługę. Użytkownik może nawet nie postrzegać open banking jako technologii. Po prostu widzi, że wcześniej ręczny proces finansowy odbywa się teraz wewnątrz oprogramowania, z którego już korzysta.

---

Budujesz produkt wykorzystujący open banking?
z3x może wesprzeć Cię od strategii i wyboru dostawcy, przez projekt produktu, integrację i compliance, aż po go-to-market.

---

6. Płatności open banking

Płatności open banking pozwalają klientowi zainicjować płatność bezpośrednio z rachunku bankowego poprzez zewnętrzną aplikację. Są powszechnie określane jako płatności account-to-account, czyli A2A.

Podstawowa koncepcja jest prosta. Zamiast wpisywać dane karty lub ręcznie tworzyć przelew bankowy klient wybiera swój bank, uwierzytelnia się w nim i potwierdza płatność.

Dla merchantów i firm FinTech tworzy to kolejną opcję płatności, którą można zintegrować z checkoutem lub product journey.

Jak działa płatność open banking

Typowa płatność open banking rozpoczyna się na stronie internetowej lub w aplikacji merchanta albo dostawcy usługi.

Klient wybiera metodę płatności open banking i swój bank. Następnie przechodzi przez proces uwierzytelniania banku, w którym może sprawdzić i zatwierdzić szczegóły płatności.

Dostawca inicjowania płatności przesyła instrukcję do banku poprzez odpowiednie API. Bank następnie realizuje płatność przy użyciu infrastruktury płatniczej dostępnej na danym rynku.

Z perspektywy klienta proces powinien wyglądać jak jedna spójna ścieżka checkoutu. W tle merchant, dostawca open banking, bank klienta i system płatniczy muszą jednak ze sobą współpracować.

Płatności open banking a płatności kartowe

Płatności open banking i płatności kartowe rozwiązują ten sam podstawowy problem, ale wykorzystują inną infrastrukturę.

Płatność kartowa zazwyczaj przechodzi przez ekosystem kartowy obejmujący kilku uczestników. Płatność open banking jest inicjowana z rachunku bankowego klienta i wykorzystuje zamiast tego infrastrukturę bankowych systemów płatności.

Może to zmieniać ekonomikę transakcji. W niektórych use case'ach płatności account-to-account mogą ograniczać liczbę pośredników i tworzyć bardziej bezpośredni przepływ pomiędzy płatnikiem a odbiorcą.

Porównanie nie powinno jednak kończyć się na koszcie transakcji. Karty oferują dojrzałą globalną sieć akceptacji, utrwalone zachowania konsumentów i dobrze rozwinięte procesy dotyczące między innymi refundów, sporów i płatności cyklicznych.

Płatności open banking mają inne mocne strony. Mogą być szczególnie atrakcyjne tam, gdzie użytkownicy są przyzwyczajeni do uwierzytelniania bankowego, wartości transakcji są stosunkowo wysokie lub bezpośredni przepływ account-to-account tworzy korzyści operacyjne.

Właściwy wybór zależy więc od produktu, segmentu klientów i rynku. Open banking powinien zazwyczaj być oceniany jako element payment mix, a nie uniwersalny zamiennik kart.

Płatności open banking w e-commerce

W e-commerce i płatnościach online open banking może zostać dodany jako metoda płatności w checkout.

Dobra implementacja powinna minimalizować liczbę kroków pomiędzy wyborem metody płatności a zakończeniem transakcji. Wybór banku, uwierzytelnienie i potwierdzenie wpływają na konwersję.

Jest to ważne, ponieważ skuteczność płatności nie jest wyłącznie kwestią techniczną. Technicznie prawidłowa integracja API może nadal osiągać słabe wyniki, jeśli klienci nie rozpoznają metody płatności, mają problem ze znalezieniem swojego banku lub porzucają proces uwierzytelniania.

Merchantci powinni więc analizować open banking w taki sam sposób jak inne metody płatności. Obejmuje to konwersję, payment success rate, koszt transakcji, settlement, customer support, refundy i rekonsyliację.

Business case może także różnić się pomiędzy segmentami klientów. Metoda płatności sprawdzająca się dobrze przy zakupach o wysokiej wartości lub transakcjach B2B może nie działać równie dobrze w przypadku niskokwotowych zakupów konsumenckich.

Płatności open banking w B2B

Płatności B2B są kolejnym istotnym use case'em.

Firmy często obsługują płatności faktur, zasilanie rachunków, płatności do dostawców i inne procesy, w których przelewy bankowe już są powszechne. Open banking może poprawić te procesy, wprowadzając inicjowanie płatności bezpośrednio do workflow oprogramowania.

Na przykład platforma księgowa lub fakturowa może pozwolić klientowi zainicjować płatność bez osobnego logowania do bankowości internetowej i ręcznego wpisywania danych płatności.

Może to ograniczyć błędy manualne i poprawić rekonsyliację, ponieważ płatność można powiązać z fakturą lub transakcją, która ją wygenerowała.

W produktach B2B takie korzyści operacyjne mogą być równie ważne jak sam koszt płatności.

Płatności cykliczne

Płatności cykliczne są bardziej złożone.

Tradycyjne inicjowanie płatności open banking było projektowane przede wszystkim wokół pojedynczych płatności wyraźnie zatwierdzanych przez klienta. Sprawdza się to dobrze przy jednorazowych zakupach, ale gorzej pasuje do modeli subskrypcyjnych i innych scenariuszy płatności cyklicznych.

Nowsze modele rozwiązują to ograniczenie. Na przykład w Wielkiej Brytanii Variable Recurring Payments pozwalają klientowi udzielić dostawcy zgody na inicjowanie płatności w ramach wcześniej uzgodnionych parametrów zamiast zatwierdzania każdej płatności oddzielnie.

Tworzy to możliwości dla takich use case'ów jak sweeping środków między rachunkami, płatności subskrypcyjne i inne powtarzalne transakcje. Przybliża również open banking do zastosowań tradycyjnie obsługiwanych przez karty lub Direct Debit.

Płatności cykliczne open banking nie są jednak równie dostępne na każdym rynku. Zespoły produktowe muszą rozumieć możliwości konkretnego kraju, banków i dostawców, z których planują korzystać.

Settlement, refundy i rekonsyliacja

Częstym błędem jest ocenianie płatności open banking wyłącznie na etapie checkoutu.

Produkt płatniczy działający w środowisku produkcyjnym musi również obsługiwać to, co dzieje się po kliknięciu przez klienta przycisku "zapłać". Merchant musi wiedzieć, czy płatność została skutecznie zainicjowana, czy środki dotarły i w jaki sposób transakcja powinna zostać zrekonsyliowana.

Refundy również wymagają odpowiedniego zaprojektowania. Proces zwrotu środków może nie odzwierciedlać pierwotnego przepływu płatności w taki sam sposób jak w środowisku kartowym.

Ma to szczególne znaczenie dla marketplace'ów, platform i firm przetwarzających duże wolumeny płatności. Status płatności, rekonsyliacja i obsługa wyjątków mogą tworzyć znaczną złożoność operacyjną, jeśli nie zostaną dobrze zaprojektowane.

Kiedy płatności open banking mają sens?

Płatności open banking mają największy sens wtedy, gdy rozwiązują konkretny problem komercyjny lub operacyjny.

Może to być obniżenie kosztów płatności, stworzenie lepszego doświadczenia dla przelewu bankowego, poprawa rekonsyliacji lub umożliwienie płatności wewnątrz szerszego produktu finansowego.

Mogą również być atrakcyjne przy transakcjach o wyższej wartości, gdzie ekonomika metody płatności staje się ważniejsza.

Dodawanie open banking wyłącznie dlatego, że technologia jest dostępna, rzadko jednak stanowi dobrą strategię produktową. Metoda płatności musi pasować do customer journey, lokalnych zachowań płatniczych i ekonomiki biznesu.

Dla firm FinTech, e-commerce i SaaS właściwe pytanie nie brzmi więc, czy płatności open banking są generalnie lepsze od kart lub innych metod płatności. Właściwe pytanie brzmi, gdzie zapewniają lepszy rezultat dla konkretnego klienta, rodzaju transakcji i rynku.

7. Open banking loans i lending, czyli produkty pożyczkowe oparte o open banking

Open banking stał się ważnym źródłem danych dla digital lending (pożyczek w świecie cyfrowym). Pozwala pożyczkodawcom uzyskiwać, za zgodą wnioskodawcy, dostęp do wybranych informacji o rachunku i wykorzystywać je jako część procesu oceny kredytowej.

Może to zwiększyć wykorzystanie danych w decyzjach kredytowych i ograniczyć ilość informacji, które wnioskodawcy muszą przekazywać ręcznie. Zamiast przesyłać wyciągi bankowe lub wpisywać dane dotyczące dochodów i wydatków do formularza, wnioskodawca może połączyć rachunek bankowy i pozwolić pożyczkodawcy bezpośrednio przeanalizować istotne informacje finansowe.

Termin open banking loans zazwyczaj odnosi się do produktów lendingowych (pożyczkowych), w których dane open banking są wykorzystywane podczas składania wniosku, czy underwritingu. Open banking nie tworzy osobnego rodzaju pożyczki. Zmienia sposób zbierania i wykorzystywania informacji w procesie udzielania pożyczki.

Weryfikacja dochodu

Jednym z najbardziej oczywistych use case'ów jest weryfikacja dochodu.

Dane transakcyjne mogą pomóc pożyczkodawcy identyfikować regularne wpływy wynagrodzenia, przychody biznesowe lub inne stałe źródła środków. Może to zmniejszyć zależność od dokumentów dostarczanych ręcznie i przyspieszyć proces weryfikacji.

W przypadku consumer lending może to oznaczać identyfikowanie wpływów wynagrodzenia i ich regularności. W przypadku SME lending analiza może być szersza i obejmować wpływy, wzorce przychodów oraz zmiany cash flow w czasie.

Wyzwaniem jest właściwa interpretacja danych transakcyjnych. Przelew otrzymywany co miesiąc nie musi automatycznie być wynagrodzeniem, podobnie jak przychód wpływający na rachunek firmowy nie musi oznaczać zysku lub dostępnej gotówki.

Dlatego kategoryzacja transakcji i analiza danych są kluczowymi elementami produktu lendingowego wykorzystującego open banking.

Affordability assessment, czyli automatyczna analiza wydatków

Open banking może również zapewniać bardziej szczegółowy obraz regularnych wydatków i zobowiązań finansowych wnioskodawcy.

Pożyczkodawca może analizować koszty mieszkaniowe, spłaty kredytów, subskrypcje, rachunki za media i inne regularne wydatki. W połączeniu z informacjami o dochodzie może to wspierać affordability assessment oparty na rzeczywistej aktywności rachunku.

Może być to bardziej użyteczne niż poleganie wyłącznie na informacjach zadeklarowanych przez klienta. Pozwala również automatyzować część procesu oceny.

Automatyzacja nie oznacza jednak prostoty. Dane transakcyjne mogą być niekompletne, nieregularne lub trudne do kategoryzacji. Wnioskodawcy mogą również korzystać z kilku rachunków bankowych, dlatego jeden połączony rachunek może nie przedstawiać pełnego obrazu ich sytuacji finansowej.

Zespoły produktowe nie powinny więc traktować połączenia open banking jako idealnego odzwierciedlenia finansów klienta.

Cash-flow underwriting, czyli ocena kredytowa

Open banking ma szczególne znaczenie dla underwritingu opartego na cash flow.

Tradycyjna ocena kredytowa często w dużym stopniu opiera się na danych biur informacji kredytowej, sprawozdaniach finansowych lub historycznych informacjach przekazywanych przez wnioskodawcę. Open banking może uzupełnić je o bardziej aktualny obraz tego, jak pieniądze rzeczywiście przepływają przez rachunek.

W przypadku SME lendera (pożyczkodawcy) może to obejmować wzorce przychodów, sezonowość, koncentrację wpływów, regularne wydatki i zmiany dostępnej płynności.

W przypadku consumer lending może dostarczać informacji o stabilności dochodu i zachowaniach wydatkowych.

Nie oznacza to, że dane open banking powinny zastępować tradycyjne informacje o ryzyku. W wielu przypadkach najsilniejszy model underwritingowy łączy kilka źródeł danych zamiast polegać wyłącznie na jednym.

Open banking i SME lending

SME lending jest jednym z obszarów, w których open banking może tworzyć znaczną wartość operacyjną.

Małe firmy nie zawsze dysponują tak rozbudowanym raportowaniem finansowym jak większe przedsiębiorstwa. Ich sytuacja finansowa może również szybko się zmieniać, dlatego aktualne dane transakcyjne i cash-flow mogą być szczególnie wartościowe.

Pożyczkodawca może wykorzystywać dane rachunku bankowego, aby lepiej zrozumieć obrót, regularne koszty i płynność. Może to wspierać szybszą wstępną ocenę i ograniczać ilość dokumentacji wymaganej od firmy.

Open banking może również pomóc pożyczkodawcom obsługiwać segmenty, w których tradycyjny underwriting jest kosztowny w relacji do wielkości pożyczki. Większa automatyzacja może poprawić ekonomikę obsługi mniejszych wniosków.

Możliwość komercyjna nie polega wyłącznie na szybszych decyzjach kredytowych. Lepszy przepływ danych może także poprawić customer experience i ograniczyć manualną pracę zespołów sprzedażowych, underwritingowych i operacyjnych.

Open banking nie zastępuje zarządzania ryzykiem kredytowym

Ważne jest, aby nie przeceniać możliwości open banking.

Dostęp do danych transakcyjnych nie prowadzi automatycznie do dobrej decyzji kredytowej. Pożyczkodawca nadal potrzebuje strategii kredytowej, modeli ryzyka, reguł decyzyjnych, kontroli fraudowych i odpowiednich procesów regulacyjnych.

Te same dane transakcyjne mogą również oznaczać różne rzeczy w różnych kontekstach. Nagły spadek salda rachunku może w jednym przypadku być sygnałem ryzyka, a w innym normalnym efektem sezonowości.

Pożyczkodawca musi więc rozumieć zarówno dane, jak i segment klienta.

Open banking należy traktować jako dodatkowe źródło wysokiej jakości informacji finansowych. Jego wartość zależy od sposobu, w jaki informacje te są włączane do całego procesu underwritingowego.

Product experience również ma znaczenie

Z perspektywy produktu pożyczkodawcy powinni również analizować to, co dzieje się, zanim dane trafią do modelu ryzyka.

Klienci muszą rozumieć, dlaczego są proszeni o połączenie rachunku bankowego i jakie informacje będą wykorzystywane. Jeśli wartość, którą otrzymują w zamian, nie jest jasna, część wnioskodawców może porzucić proces.

Wybór banku, uwierzytelnianie i niezawodność połączenia również wpływają na konwersję wniosku.

Pożyczkodawca może więc poprawić jakość underwriting, a jednocześnie stworzyć dodatkowe tarcie w customer journey. Właściwa implementacja musi równoważyć oba te aspekty.

W przypadku firm tworzących produkty pożyczkowe oparte o open banking najsilniejszym use case'em nie jest po prostu "więcej danych". Jest nim lepszy proces lendingowy oparty na szybszym dostępie do istotnych informacji finansowych, lepszej automatyzacji i customer journey, który nadal pozostaje łatwy do ukończenia.

---

Chcesz wykorzystać open banking do poprawy płatności, lendingu lub procesów finansowych?
Pomagamy firmom FinTech, e-commerce i SaaS projektować i wdrażać rozwiązania tworzące realną wartość biznesową.

---

8. Czy open banking jest bezpieczny?

Częste pytanie zarówno ze strony konsumentów, jak i firm brzmi: czy open banking jest bezpieczny?

W regulowanych środowiskach open banking model został zaprojektowany w taki sposób, aby zapewniać kontrolowany dostęp do danych bankowych i funkcji płatniczych zamiast dawać stronom trzecim nieograniczony dostęp do rachunku klienta. Dostęp zazwyczaj wymaga zgody klienta, odpowiedniego uwierzytelnienia oraz zdefiniowanego technicznego połączenia pomiędzy dostawcą a bankiem.

To fundamentalnie odróżnia open banking od zwykłego przekazania innej firmie danych logowania do bankowości internetowej.

Stwierdzenie, że open banking jest bezpieczny, nie oznacza jednak, że każda implementacja wiąże się z takim samym poziomem ryzyka. Bezpieczeństwo zależy od frameworku regulacyjnego, dostawcy, implementacji technicznej, procesu uwierzytelniania oraz sposobu obsługi danych klienta po ich pobraniu.

Klienci zachowują kontrolę nad dostępem

Zgoda jest jedną z podstawowych zasad open banking.

Dostawca powinien prosić o dostęp w konkretnym celu i do jasno określonego zakresu informacji lub funkcjonalności. Klient decyduje, czy taki dostęp zostanie przyznany.

Na przykład aplikacja do zarządzania finansami może poprosić o zgodę na dostęp do salda rachunku i historii transakcji. Dostawca płatności może poprosić o pozwolenie na zainicjowanie konkretnej płatności.

Są to różne uprawnienia. Połączenie rachunku w jednym celu nie powinno automatycznie zapewniać dostawcy nieograniczonego dostępu do innych funkcji.

Zasada ta ma znaczenie zarówno dla bezpieczeństwa, jak i zaufania klientów.

Uwierzytelnianie zazwyczaj pozostaje po stronie banku

W nowoczesnym open banking opartym na API klienci zazwyczaj uwierzytelniają się w swoim banku zamiast przekazywać dane logowania do bankowości internetowej bezpośrednio zewnętrznej aplikacji.

Użytkownik może zostać przekierowany do aplikacji bankowej lub środowiska uwierzytelniania banku albo uwierzytelnienie może odbywać się poprzez inny bezpieczny proces kontrolowany przez bank.

Zewnętrzny dostawca otrzymuje wynik oraz zatwierdzony dostęp, a nie hasło klienta do bankowości.

Znacząco zmienia to model bezpieczeństwa w porównaniu ze starszymi podejściami opartymi na udostępnianiu lub pozyskiwaniu danych logowania do bankowości internetowej.

Strong Customer Authentication w UE

W Unii Europejskiej Strong Customer Authentication (SCA) jest ważnym elementem frameworku bezpieczeństwa płatności.

Zazwyczaj wymaga uwierzytelnienia opartego na co najmniej dwóch niezależnych elementach z różnych kategorii, takich jak coś, co klient wie, posiada lub czym jest.

W praktyce może to obejmować kombinacje takie jak hasło lub PIN, posiadanie zarejestrowanego urządzenia oraz uwierzytelnienie biometryczne.

W przypadku produktów open banking wymagania dotyczące uwierzytelniania wpływają zarówno na bezpieczeństwo, jak i konwersję. Bardzo bezpieczny proces tworzący niepotrzebną złożoność może powodować porzucanie procesu przez klientów, natomiast źle zaprojektowany flow może wywoływać dezorientację lub brak zaufania.

Dlatego uwierzytelnianie nie jest wyłącznie zagadnieniem compliance. Jest również kwestią projektowania produktu.

Autoryzowani dostawcy i regulowany dostęp

Na rynkach, na których open banking został ustanowiony poprzez regulacje, dostawcy wykonujący regulowane działania mogą potrzebować odpowiedniego zezwolenia lub rejestracji.

Tworzy to formalne ramy określające, kto może uzyskiwać dostęp do danych bankowych lub inicjować płatności oraz na jakich warunkach.

Dla firm integrujących usługi open banking wybór dostawcy powinien więc obejmować więcej niż coverage API i cenę. Status regulacyjny, procesy bezpieczeństwa, operational resilience i sposób przetwarzania danych również powinny być częścią vendor due diligence.

Dostawca posiadający bardzo dobre API nadal może być słabym wyborem strategicznym, jeśli jego model regulacyjny nie pasuje do produktu firmy lub planów ekspansji.

Bezpieczeństwo API

API open banking jest projektowane w celu udostępniania konkretnych danych lub funkcjonalności poprzez kontrolowane interfejsy techniczne.

Uwierzytelnianie pomiędzy systemami, tokeny dostępu, certyfikaty, szyfrowanie i zarządzanie uprawnieniami mogą stanowić część architektury bezpieczeństwa.

Najważniejsze jest to, że dostęp przez API może być ograniczony. Dostawca może otrzymać uprawnienie do wykonywania konkretnych działań zamiast ogólnego dostępu do całego środowiska bankowego.

Dobrze zaprojektowane API pozwala również monitorować i kontrolować dostęp skuteczniej niż wiele starszych metod wymiany danych finansowych.

API nie są jednak automatycznie bezpieczne tylko dlatego, że są API. Słaba implementacja, nieprawidłowe uprawnienia, niebezpieczna infrastruktura lub słabe wewnętrzne kontrole bezpieczeństwa nadal mogą tworzyć ryzyko.

Co dzieje się z danymi po opuszczeniu banku?

Jest to jedno z najważniejszych pytań dotyczących bezpieczeństwa open banking.

Bank może zapewniać bezpieczne API i proces uwierzytelniania, ale zewnętrzny dostawca może następnie przechowywać, analizować lub przetwarzać pobrane informacje w swojej własnej infrastrukturze.

Firmy muszą więc analizować bezpieczeństwo danych w całym cyklu życia, a nie tylko podczas połączenia API.

Obejmuje to pytania o to, jakie dane są przechowywane, jak długo są przechowywane, kto może uzyskać do nich dostęp oraz czy wszystkie zbierane informacje są rzeczywiście potrzebne do świadczenia usługi.

Dla nabywców B2B wybierających dostawcę open banking pytania te powinny być częścią technicznego i compliance due diligence.

Open banking nie eliminuje ryzyka fraudowego

Open banking może poprawić bezpieczeństwo w niektórych częściach customer journey finansowego, ale nie eliminuje fraudu.

Oszuści nadal mogą wykorzystywać social engineering, podszywanie się pod inne osoby oraz zmanipulowane customer journeys, aby przekonać ludzi do zatwierdzenia transakcji lub udostępnienia informacji.

Płatność może zostać technicznie poprawnie uwierzytelniona, a jednocześnie klient może zostać oszukany i przekonany do jej wykonania.

Rozróżnienie to jest ważne dla firm budujących produkty płatnicze. Uwierzytelnienie potwierdza, że autoryzowany użytkownik wykonał określone działanie. Nie zawsze potwierdza, że sama transakcja jest legalna i uzasadniona.

Fraud prevention nadal wymaga więc monitoringu, kontroli ryzyka i odpowiedniej komunikacji z klientem.

Czy dostęp open banking można wycofać?

W zależności od rynku i usługi użytkownicy mogą zazwyczaj wycofać zgodę lub odłączyć usługę, której wcześniej przyznali dostęp do informacji o rachunku.

Zarządzanie zgodami powinno więc być traktowane jako część cyklu życia produktu, a nie jednorazowy etap onboardingu.

Użytkownicy powinni rozumieć, na co udzielili zgody i w jaki sposób dostęp może zostać zmieniony lub usunięty.

Dla zespołów produktowych jasne zarządzanie zgodami ogranicza również problemy customer support i zwiększa zaufanie.

Co użytkownicy powinni sprawdzić przed skorzystaniem z usługi open banking?

Użytkownicy powinni rozumieć, która firma prosi o dostęp, jakich informacji potrzebuje i dlaczego są one wymagane.

Powinni również uwierzytelniać się poprzez oczekiwane środowisko banku i zachować ostrożność, jeśli usługa niespodziewanie prosi ich o bezpośrednie przekazanie pełnych danych logowania do bankowości internetowej.

Na rynkach regulowanych użytkownicy mogą również sprawdzić, czy dostawca posiada odpowiedni status regulacyjny dla oferowanej usługi.

W przypadku firm obowiązują podobne zasady, ale na głębszym poziomie. Due diligence powinno obejmować regulacje, bezpieczeństwo informacji, przetwarzanie danych, niezawodność API, incident management oraz zależność dostawcy od innych firm infrastrukturalnych.

Czy open banking jest więc bezpieczny?

Open banking może zapewniać bezpieczny sposób dostępu do danych bankowych i inicjowania płatności, jeśli jest wdrożony w ramach silnego frameworku regulacyjnego i technicznego.

Jego model bezpieczeństwa opiera się na kontrolowanym dostępie, zgodzie klienta, uwierzytelnianiu bankowym i jasno określonych uprawnieniach zamiast nieograniczonego dostępu do rachunku.

Bezpieczeństwo nie powinno być jednak traktowane jako checkbox. Dostawca open banking, bank, firma budująca produkt i customer journey wspólnie tworzą końcowy model bezpieczeństwa.

Dla firm FinTech, e-commerce i SaaS oznacza to, że wybór dostawcy open banking wyłącznie na podstawie funkcjonalności lub ceny nie wystarcza. Bezpieczeństwo, setup regulacyjny, data governance i operational resilience powinny być analizowane na tym samym etapie co sama integracja API.

9. Open banking w Unii Europejskiej

Unia Europejska była jednym z najważniejszych rynków w rozwoju open banking. Jej model jest przede wszystkim regulacyjny, a banki i inni dostawcy usług płatniczych działają w ramach wspólnych zasad prawnych dotyczących dostępu do rachunków płatniczych i usług płatniczych.

Kluczową podstawą regulacyjną była zrewidowana Payment Services Directive, powszechnie znana jako PSD2. Stworzyła ona ramy prawne pozwalające zewnętrznym dostawcom oferować usługi dostępu do informacji o rachunku oraz inicjowania płatności w całej UE.

PSD2 nie stworzyła open banking jako produktu komercyjnego. Ustanowiła natomiast warunki regulacyjne umożliwiające nowym dostawcom dostęp do rachunków płatniczych i konkurowanie z usługami tradycyjnie świadczonymi przez banki.

AIS i PIS w ramach PSD2

Dwa pojęcia są szczególnie istotne dla zrozumienia europejskiego open banking.

Account Information Services, czyli AIS, pozwalają autoryzowanym dostawcom uzyskiwać za zgodą klienta dostęp do informacji z rachunków płatniczych. Jest to podstawa regulacyjna wielu usług agregacji rachunków, zarządzania finansami i data-driven FinTech.

Payment Initiation Services, czyli PIS, pozwalają autoryzowanym dostawcom inicjować płatności z rachunku płatniczego klienta. Stworzyło to podstawę regulacyjną dla wielu produktów płatniczych opartych na open banking.

Dostawcy oferujący takie usługi są powszechnie określani jako third-party providers, czyli TPP. Banki prowadzące bazowe rachunki płatnicze są zazwyczaj określane jako Account Servicing Payment Service Providers, czyli ASPSP.

Terminy te mogą brzmieć regulacyjnie, ale opisują prostą architekturę produktu. Bank prowadzi rachunek, strona trzecia dostarcza usługę dla klienta, a framework regulacyjny określa, w jaki sposób oba podmioty mogą ze sobą współpracować.

PSD2 zmieniła dostęp do infrastruktury bankowej

Przed PSD2 firma FinTech, która chciała uzyskać dostęp do informacji o rachunku bankowym klienta, często miała ograniczone możliwości. Dostęp mógł zależeć od bilateralnych relacji z bankami, dokumentów dostarczanych przez klienta lub metod technicznych, które nie były projektowane jako formalne interfejsy bankowe.

PSD2 zmieniła tę sytuację, tworząc regulowane prawo dostępu dla autoryzowanych dostawców. Banki musiały wspierać dostęp do rachunków płatniczych na potrzeby usług informacji o rachunku i inicjowania płatności na określonych warunkach.

Miało to strategiczne znaczenie dla rynku FinTech. Firma nie musiała już koniecznie posiadać umowy handlowej z każdym bankiem, zanim mogła zbudować usługę opartą na dostępie do rachunków płatniczych klientów.

Zmieniła się również rola banków. Rachunek mógł stać się warstwą infrastrukturalną dla produktów dostarczanych przez inną firmę.

PSD2 nie stworzyła jednego europejskiego API

Jednym z najważniejszych praktycznych aspektów jest to, że PSD2 stworzyła regulowany dostęp, ale nie jedno identyczne API open banking używane przez każdy bank w Europie.

Na rynku rozwinęły się różne standardy API i podejścia implementacyjne. Banki również w odmienny sposób interpretowały wymagania techniczne i regulacyjne.

W rezultacie dostawca działający w kilku krajach Europy nadal może doświadczać różnic w zachowaniu API, dostępnych danych, procesach uwierzytelniania, obsłudze błędów i niezawodności.

Jest to jeden z powodów, dla których agregatorzy open banking stali się istotnym elementem europejskiego ekosystemu. Abstrahują dużą część tej złożoności i zapewniają jedną warstwę integracyjną obejmującą wiele banków i krajów.

Abstrakcja nie eliminuje jednak bazowych różnic. Jeśli API banku działa słabo, dodanie agregatora pomiędzy bank a FinTech nie rozwiązuje automatycznie problemu.

Jest to ważna kwestia podczas planowania produktu działającego w wielu krajach. Stwierdzenie typu "obsługujemy open banking w Europie" mówi bardzo niewiele o rzeczywistym coverage i customer experience.

Strong Customer Authentication

PSD2 wprowadziła również Strong Customer Authentication, czyli SCA, jako ważny element europejskiego frameworku bezpieczeństwa płatności.

SCA wpływa na wiele customer journeys open banking, ponieważ klienci muszą się uwierzytelniać podczas uzyskiwania dostępu do rachunku lub autoryzowania określonych działań płatniczych.

Z perspektywy regulacyjnej zwiększa to bezpieczeństwo płatności. Z perspektywy produktu uwierzytelnianie bezpośrednio wpływa na konwersję.

Klient rozpoczynający płatność open banking może przechodzić pomiędzy interfejsem merchanta, dostawcą open banking i aplikacją bankową przed zakończeniem płatności. Każdy dodatkowy krok tworzy kolejny potencjalny punkt porzucenia procesu.

Dobra implementacja wymaga więc od zespołów produktowych zrozumienia zarówno wymogu regulacyjnego, jak i rzeczywistego doświadczenia uwierzytelniania oferowanego przez poszczególne banki.

Od PSD2 do PSD3 i Payment Services Regulation

UE przechodzi obecnie w kierunku kolejnej generacji frameworku usług płatniczych.

Komisja Europejska zaproponowała w 2023 roku nową Payment Services Directive, PSD3, oraz bezpośrednio obowiązujące Payment Services Regulation, PSR. Zakres zmian jest szerszy niż open banking, ale poprawa jego funkcjonowania jest wyraźną częścią pakietu.

Parlament Europejski i Rada osiągnęły 27 listopada 2025 roku wstępne porozumienie polityczne w sprawie PSD3 i PSR. Komisja ECON Parlamentu Europejskiego zatwierdziła następnie wynegocjowany tekst w maju 2026 roku. W momencie pisania tego artykułu pakiet nadal wymaga formalnego przyjęcia przez Parlament i Radę, zanim będzie mógł wejść w życie.

To rozróżnienie jest ważne. PSD3 i PSR nie powinny być jeszcze opisywane jako obowiązujący framework prawny zastępujący PSD2.

Co PSD3 i PSR mogą zmienić w open banking

Jednym z celów nowego frameworku jest ograniczenie przeszkód, z którymi zewnętrzni dostawcy nadal spotykają się podczas uzyskiwania dostępu do rachunków płatniczych.

Wynegocjowane regulacje odnoszą się do barier w dostępie open banking i mają zapobiegać dyskryminowaniu autoryzowanych dostawców open banking przez podmioty prowadzące rachunki. Wprowadzają również silniejsze narzędzia umożliwiające klientom monitorowanie i zarządzanie uprawnieniami przyznanymi stronom trzecim.

Jest to istotne, ponieważ pierwsza faza europejskiego open banking pokazała, że sam regulowany dostęp nie wystarcza. Znaczenie ma również jakość tego dostępu.

Technicznie dostępne API ma ograniczoną wartość komercyjną, jeśli uwierzytelnianie jest zawodne, dane są niekompletne albo klient wielokrotnie nie jest w stanie ukończyć połączenia.

Kolejna faza regulacyjna coraz bardziej dotyczy więc poprawy funkcjonowania open banking w praktyce, a nie jedynie ustanawiania prawa dostępu do rachunku.

Europa jest jednym rynkiem prawnie, ale nie zawsze operacyjnie

Dla firmy wchodzącej na rynek europejski kuszące jest traktowanie UE jako jednego regionu open banking.

Z perspektywy strategii regulacyjnej wspólny europejski framework daje oczywiste korzyści. Z perspektywy produktu i go-to-market poszczególne rynki nadal powinny być jednak analizowane osobno.

Coverage banków, zachowania klientów, krajowa infrastruktura płatnicza, preferowane metody płatności i wydajność API mogą znacząco różnić się pomiędzy państwami.

Najsilniejsi dostawcy łączą więc skalowalność regulacyjną z lokalną wiedzą rynkową.

Jeśli FinTech chce uruchomić płatności open banking w kilku państwach europejskich, pytanie nie powinno dotyczyć wyłącznie tego, czy dostawca API technicznie obsługuje te kraje. Firma powinna również wiedzieć, które banki są objęte usługą, jak klienci się uwierzytelniają, jakie payment rails są wykorzystywane, w jaki sposób potwierdzane są płatności i jak dana metoda konkuruje z istniejącymi lokalnymi metodami płatności.

W tym miejscu regulowany dostęp staje się problemem produktowym i go-to-market.

10. Open banking w Wielkiej Brytanii

Wielka Brytania jest jednym z najbardziej rozwiniętych rynków open banking, ale jej rozwój przebiegał inaczej niż w Unii Europejskiej.

Podczas gdy europejski open banking był napędzany przede wszystkim przez PSD2, Wielka Brytania połączyła regulacje usług płatniczych z programem opartym na polityce konkurencji, skupionym na standaryzacji i implementacji.

Różnica ta jest istotna. Wielka Brytania nie tylko wymagała od banków zapewnienia dostępu. Opracowała również znacznie bardziej ustandaryzowany framework techniczny dotyczący sposobu, w jaki taki dostęp powinien działać.

Podejście oparte na standardach

Brytyjski framework open banking został zbudowany wokół wspólnych standardów API, profili bezpieczeństwa, wymagań customer experience i wytycznych operacyjnych.

Stworzyło to większą spójność pomiędzy uczestniczącymi bankami i zewnętrznymi dostawcami niż na wielu rynkach europejskich.

Dla firm produktowych standaryzacja ma praktyczną wartość. Ogranicza liczbę różnic specyficznych dla poszczególnych banków, które trzeba obsługiwać, i ułatwia tworzenie customer journeys działających podobnie w różnych instytucjach.

Nie oznacza to, że każde połączenie bankowe jest identyczne ani że wszystkie problemy integracyjne znikają. Wspólne standardy tworzą jednak silniejszą podstawę interoperacyjności.

Jest to jeden z głównych powodów, dla których Wielka Brytania jest często traktowana jako odrębny rynek open banking, a nie po prostu kolejna implementacja europejskich regulacji płatniczych.

Od compliance regulacyjnego do infrastruktury komercyjnej

Pierwsza faza brytyjskiego open banking mocno koncentrowała się na tworzeniu dostępu i zapewnieniu istnienia wymaganej infrastruktury.

Rynek stopniowo przesuwał się jednak w kierunku innego pytania: w jaki sposób ta infrastruktura może wspierać komercyjnie zrównoważone produkty?

Zmiana ta ma znaczenie.

Regulacyjne API może spełniać wymóg dostępu, nie tworząc jednocześnie rentownego modelu biznesowego dla każdego uczestnika. Długoterminowy rozwój open banking wymaga zachęt dla banków, firm FinTech, dostawców płatności i firm infrastrukturalnych do inwestowania w nowe usługi.

Wielka Brytania coraz bardziej rozwija więc model łączący wspólne standardy z komercyjnymi schematami budowanymi na ich podstawie.

FCA oczekuje, że przyszły framework będzie obejmował wspólną warstwę standardów oraz konkurencyjną warstwę komercyjnych schematów open banking. Planowany Future Entity ma stać się głównym podmiotem odpowiedzialnym za ustanawianie standardów, podczas gdy operatorzy komercyjnych schematów będą mogli rozwijać usługi wykorzystujące wspólną infrastrukturę.

Future Entity

Struktura instytucjonalna brytyjskiego open banking również się zmienia.

Open Banking Limited odgrywało centralną rolę we wdrażaniu systemu, ale Wielka Brytania pracuje nad nowym długoterminowym modelem governance.

FCA wskazała, że pod warunkiem wprowadzenia odpowiednich przepisów Future Entity ma stać się głównym podmiotem ustanawiającym standardy dla brytyjskich API open banking. Oczekiwane obowiązki obejmują wspólne standardy, monitoring wydajności API, certyfikację i usługi katalogowe.

Proces projektowania trwał w 2026 roku przy udziale branży w tworzeniu nowej instytucji.

To coś więcej niż zmiana organizacyjna. Governance określa, kto ustala standardy, kto monitoruje wydajność i w jaki sposób mogą rozwijać się komercyjne usługi open banking.

Dla firm budujących produkty na brytyjskim open banking transformacja ta ma znaczenie, ponieważ ekosystem przechodzi od struktury implementacyjnej stworzonej dla początkowej fazy open banking do trwałej infrastruktury.

Data (Use and Access) Act i długoterminowy framework

Data (Use and Access) Act 2025 stworzył nowe uprawnienia dla schematów Smart Data w Wielkiej Brytanii, w tym frameworków takich jak open banking.

Zapewnia to podstawę prawną dla kolejnego etapu governance open banking oraz potencjalnie szerszych modeli udostępniania danych.

Brytyjski rząd rozwija obecnie długoterminowy framework regulacyjny, który wykorzysta te uprawnienia. W lipcu 2026 roku HM Treasury opublikowało konsultację dotyczącą modernizacji regulacji usług płatniczych, obejmującą przyszłą strukturę regulacyjną open banking i proponowaną rolę FCA.

Kierunek ten ma znaczenie dla firm FinTech. Brytyjski open banking odchodzi od frameworku w dużej mierze zależnego od pierwotnego środka z zakresu polityki konkurencji w stronę trwałego modelu regulacyjnego i komercyjnego.

Variable Recurring Payments

Variable Recurring Payments, czyli VRP, są jednym z najważniejszych obszarów rozwoju brytyjskiego open banking.

VRP pozwala klientowi autoryzować dostawcę do wykonywania serii płatności w ramach uzgodnionych parametrów. Różni się to od standardowej płatności open banking, w której klient zazwyczaj zatwierdza każdą płatność oddzielnie.

Pierwotna implementacja skupiała się na sweeping, czyli przesuwaniu środków pomiędzy rachunkami należącymi do tego samego klienta. Rynek rozszerza się obecnie w stronę komercyjnych Variable Recurring Payments, powszechnie określanych jako cVRP.

Komercyjne VRP mogą wspierać takie use case'y jak płatności za media, płatności za usługi finansowe i inne transakcje cykliczne. FCA i Payment Systems Regulator aktywnie wspierają rozwój modelu komercyjnego, między innymi poprzez prace nad strukturą cenową powstającej UK Payments Initiative.

Ma to strategiczne znaczenie, ponieważ płatności cykliczne historycznie były jednym z ograniczeń inicjowania płatności open banking.

Jeśli open banking będzie w stanie obsługiwać niezawodne komercyjne płatności cykliczne, może konkurować w szerszym zakresie zastosowań obecnie obsługiwanych przez karty i Direct Debit.

Płatności open banking stają się kategorią produktową

Wielka Brytania pokazuje również, w jaki sposób płatności open banking mogą rozwijać się poza obszar compliance regulacyjnego.

Dostawcy konkurują dziś jakością checkoutu, coverage banków, konwersją płatności, rekonsyliacją, narzędziami dla merchantów i warunkami komercyjnymi.

Zmienia to krajobraz konkurencyjny.

Bazowe API bankowe staje się infrastrukturą. Zróżnicowanie przenosi się do warstwy produktowej zbudowanej powyżej.

Dla merchantów decyzja nie polega więc wyłącznie na tym, czy "akceptować open banking". Muszą oceniać dostawców w taki sam sposób jak inne rozwiązania płatnicze.

Obejmuje to konwersję, rozpoznawalność wśród klientów, coverage banków, settlement, refundy, rekonsyliację, kontrole fraudowe, nakład pracy integracyjnej i warunki komercyjne.

Wielka Brytania zmierza również w stronę open finance

Długoterminowa ambicja jest szersza niż dostęp do rachunków płatniczych.

Data (Use and Access) Act zapewnia szerszy framework Smart Data, a FCA wskazała, że rola Future Entity może w przyszłości rozszerzyć się na open finance.

Open finance rozszerzyłby udostępnianie danych poza podstawowy zakres open banking na inne obszary usług finansowych.

Docelowo mogłoby to obejmować takie produkty jak oszczędności, inwestycje, emerytury, ubezpieczenia i lending. Brytyjski rząd już opisuje open finance jako kolejny etap open banking, oparty na bezpiecznym dostępie do szerszego zakresu danych finansowych.

Dla firm FinTech tworzy to znacznie większą potencjalną przestrzeń produktową. Zamiast łączyć się wyłącznie z rachunkami płatniczymi przyszłe usługi mogą budować pełniejszy obraz finansowy konsumenta lub firmy.

Open banking w UE i Wielkiej Brytanii są podobne, ale niezamienne

Dla firm działających międzynarodowo najważniejsze jest to, że open banking w UE i Wielkiej Brytanii nie powinny być traktowane jako ta sama implementacja.

Oba rynki wspierają regulowany dostęp do informacji o rachunku i inicjowanie płatności. Oba mocno opierają się na API i zgodzie klienta.

Ich standardy, struktury regulacyjne, rozwój rynku i modele komercyjne są jednak różne.

Produktu dobrze działającego w Wielkiej Brytanii nie można po prostu skopiować do kilku państw UE, zakładając, że customer experience, wydajność API i zachowania płatnicze pozostaną takie same.

Działa to również w drugą stronę.

Skuteczna strategia open banking zaczyna się więc od use case'u i rynku docelowego, a nie od dostawcy technologii. API może być globalne, ale produkt nadal musi działać lokalnie.

11. Open banking na świecie

Open banking jest dziś koncepcją globalną, ale nie istnieje jeden globalny model open banking.

Poszczególne kraje stworzyły różne zasady dotyczące sposobu udostępniania danych finansowych, instytucji zobowiązanych do uczestnictwa oraz rodzajów usług, które mogą być świadczone. Niektóre rynki rozpoczęły rozwój od regulacji, inne od umów komercyjnych i standardów branżowych.

Dla firm budujących międzynarodowe produkty FinTech rozróżnienie to ma znaczenie. API open banking działające w jednym kraju nie musi automatycznie zapewniać tych samych danych, customer journey czy funkcjonalności w innym.

W praktyce globalne modele open banking można ogólnie podzielić na regulacyjne, rynkowe i hybrydowe.

Open banking oparty na regulacjach

Na rynkach regulacyjnych przepisy prawa lub wymagania regulacyjne ustanawiają prawa i obowiązki dotyczące dostępu do danych finansowych.

Unia Europejska jest wyraźnym przykładem. PSD2 stworzyła framework, w ramach którego autoryzowani zewnętrzni dostawcy mogą uzyskiwać za zgodą klienta dostęp do informacji o rachunku płatniczym oraz inicjować płatności.

Wielka Brytania również posiada silną podstawę regulacyjną, choć jej implementacja kładzie większy nacisk na wspólne standardy techniczne i governance.

Modele regulacyjne mogą przyspieszać rozwój rynku, ponieważ banki nie mogą po prostu zdecydować, czy chcą uczestniczyć. Reguły tworzą framework, na którym mogą budować nowi uczestnicy rynku.

Regulacje nie gwarantują jednak dobrego środowiska produktowego.

Bank może technicznie zapewniać dostęp, a jednocześnie oferować API lub customer journey uwierzytelniania o słabej jakości. Dlatego jakość API, standaryzacja i zasady implementacyjne stają się ważne po ustanowieniu początkowego frameworku regulacyjnego.

Open banking oparty na rynku

Inne rynki historycznie w większym stopniu opierały się na relacjach komercyjnych pomiędzy bankami, firmami FinTech, agregatorami danych i dostawcami technologii.

Ważnym przykładem są Stany Zjednoczone. Udostępnianie danych finansowych przez lata rozwijało się tam poprzez prywatne integracje i porozumienia branżowe zamiast poprzez mandat open banking w stylu PSD2.

Kierunek regulacyjny ewoluował. Sekcja 1033 Consumer Financial Protection Act ustanawia prawa konsumentów dotyczące dostępu do danych finansowych, a Consumer Financial Protection Bureau opublikowało w 2024 roku Personal Financial Data Rights rule. CFPB następnie rozpoczęło proces ponownego rozważenia części tych zasad, co oznacza, że amerykański framework nadal się zmienia.

Pokazuje to ważny aspekt globalnego open banking.

Rynek może już posiadać rozbudowaną łączność z danymi finansowymi bez takiej samej architektury regulacyjnej jak w Europie. Komercyjne API, sieci danych i standardy branżowe mogą rozwijać się zanim regulacje stworzą formalny framework open banking.

Z perspektywy firmy produktowej rezultat na poziomie interfejsu użytkownika może wyglądać podobnie. Klient łączy rachunek bankowy i pozwala stronie trzeciej uzyskać dostęp do informacji finansowych.

Za tym interfejsem prawa, standardy techniczne, relacje komercyjne i podział odpowiedzialności pomiędzy uczestnikami mogą jednak wyglądać zupełnie inaczej.

Australia i Consumer Data Right

Australia przyjęła jeszcze inne podejście.

Open banking został wprowadzony jako część szerszego Consumer Data Right, czyli CDR. CDR pozwala konsumentom wyrazić zgodę na udostępnienie danych akredytowanym stronom trzecim i został zaprojektowany jako framework, który może wykraczać poza bankowość.

Strategicznie różni się to od traktowania open banking wyłącznie jako inicjatywy sektora płatniczego.

Bankowość staje się jednym z elementów szerszego modelu przenośności danych. Ta sama podstawowa koncepcja może potencjalnie zostać zastosowana do kolejnych branż i innych rodzajów danych konsumenckich.

Dla firm FinTech taka szersza architektura może tworzyć możliwości wykraczające poza tradycyjną agregację rachunków czy inicjowanie płatności.

Oznacza to również, że firmy wchodzące do Australii muszą rozumieć specyficzne dla CDR wymagania dotyczące akredytacji, zgód i udostępniania danych, zamiast zakładać, że zastosowanie mają europejskie modele open banking.

Brazylia i open finance

Brazylia jest kolejnym interesującym przykładem, ponieważ jej framework wyraźnie rozwinął się w kierunku open finance, a nie tylko open banking.

Bank Centralny Brazylii opisuje Open Finance jako system mający poprawić konkurencję i efektywność w kredycie i płatnościach poprzez umożliwienie klientom udostępniania informacji finansowych pomiędzy autoryzowanymi instytucjami.

Zakres wykracza poza podstawowe informacje o rachunku płatniczym na szerszy zakres produktów i usług finansowych. Obejmuje to między innymi inwestycje, ubezpieczenia i emerytury.

Brazylia pokazuje więc, w jaki sposób rynek może stosunkowo szybko przejść od łączności z rachunkami bankowymi do szerszego ekosystemu danych finansowych.

Dla firm produktowych tworzy to większą szansę. Ten sam framework zgód klienta może potencjalnie wspierać produkty łączące dane z kilku obszarów jego życia finansowego.

Ten sam termin może oznaczać różne rzeczy

Termin "open banking" jest często używany tak, jakby opisywał jedną konkretną technologię.

W rzeczywistości może opisywać kilka powiązanych modeli.

Na jednym rynku open banking może przede wszystkim oznaczać regulowany dostęp do rachunków płatniczych. Na innym może obejmować szerszy zakres produktów finansowych. Jeszcze gdzie indziej nadal może w dużej mierze zależeć od komercyjnych relacji dotyczących udostępniania danych pomiędzy prywatnymi firmami.

Funkcjonalność płatnicza również może się różnić.

Niektóre frameworki silnie koncentrują się na dostępie do danych. Inne łączą udostępnianie danych z inicjowaniem płatności. Bardziej zaawansowane rynki rozwijają również funkcjonalność płatności cyklicznych i szerszego dostępu do danych finansowych.

Tworzy to praktyczny problem dla firm kupujących infrastrukturę open banking.

Dostawca może reklamować coverage obejmujący wiele krajów, ale "coverage" może oznaczać różne rzeczy. Może odnosić się do możliwości połączenia przynajmniej z częścią banków, dostępu do określonych danych rachunku lub inicjowania konkretnych rodzajów płatności.

Nie są to równoważne możliwości.

Globalne coverage powinno być analizowane na poziomie banku

Dla międzynarodowej firmy FinTech, e-commerce lub SaaS ocena open banking wyłącznie na poziomie kraju często nie jest wystarczająco szczegółowa.

Firma powinna wiedzieć, które banki są rzeczywiście podłączone, jakie typy rachunków są wspierane i które pola danych są niezawodnie dostępne.

W przypadku płatności analiza powinna również obejmować uwierzytelnianie, potwierdzanie płatności, settlement, refundy i lokalną infrastrukturę płatniczą.

To samo dotyczy zachowań klientów.

Technicznie doskonała płatność open banking może nadal mieć słabe wyniki komercyjne, jeśli klienci na danym rynku zdecydowanie preferują inną lokalną metodę płatności. Na innym rynku bezpośrednie płatności bankowe mogą być już dobrze znane i wymagać mniejszej zmiany zachowań.

Dlatego ekspansja open banking jest zarówno projektem infrastrukturalnym, jak i projektem go-to-market.

Open banking staje się częścią infrastruktury finansowej

Pomimo różnic pomiędzy rynkami ogólny kierunek jest podobny.

Dane finansowe stają się bardziej przenośne, klienci zyskują większą kontrolę nad tym, w jaki sposób mogą być wykorzystywane, a usługi finansowe coraz częściej są budowane pomiędzy kilkoma instytucjami zamiast wewnątrz jednego banku.

Tworzy to możliwości dla firm FinTech, ale również dla platform e-commerce, biznesów SaaS, pożyczkodawców i marketplace'ów.

Ważnym pytaniem strategicznym nie jest więc to, czy dany kraj "ma open banking".

Firma musi zrozumieć, co open banking faktycznie zapewnia na danym rynku, jak dojrzała jest infrastruktura oraz czy te możliwości rozwiązują istotny problem jej klientów.

12. Open banking a open finance

Open banking i open finance są ze sobą ściśle powiązane, ale nie są tym samym.

Open banking koncentruje się głównie na dostępie do danych i usług bankowych, w szczególności informacji związanych z rachunkami płatniczymi oraz możliwości inicjowania płatności.

Open finance rozszerza tę samą podstawową zasadę na znacznie szerszy zakres produktów finansowych.

Zamiast łączyć się wyłącznie z rachunkami bieżącymi lub innymi rachunkami płatniczymi klient mógłby pozwolić autoryzowanym dostawcom uzyskać dostęp do informacji z kilku obszarów swojego życia finansowego.

Może to obejmować oszczędności, inwestycje, emerytury, ubezpieczenia, kredyty hipoteczne i inne produkty lendingowe.

Open banking jest punktem wyjścia

Open banking pokazał, że dane finansowe przechowywane przez jedną instytucję mogą być bezpiecznie wykorzystywane przez innego dostawcę za zgodą klienta.

Stworzyło to nową architekturę produktową.

Bank prowadzący rachunek nie musi koniecznie dostarczać końcowej usługi dla klienta. FinTech lub inny autoryzowany dostawca może wykorzystać bazowe dane lub infrastrukturę do stworzenia innego produktu.

Open finance rozwija tę architekturę dalej.

Jeśli zasada działa dla danych rachunku bankowego, ten sam model można potencjalnie zastosować do portfeli inwestycyjnych, polis ubezpieczeniowych, produktów emerytalnych, pożyczek i innych informacji finansowych.

Rezultatem może być znacznie pełniejsza warstwa danych finansowych.

Co może obejmować open finance?

Dokładny zakres zależy od frameworku regulacyjnego i rynku, ale open finance może potencjalnie obejmować takie obszary jak:

• oszczędności;

• inwestycje;

• emerytury;

• ubezpieczenia;

• kredyty hipoteczne;

• kredyt konsumencki;

• lending biznesowy;

• inne aktywa i zobowiązania finansowe.

Najważniejszą różnicą nie jest po prostu liczba dostępnych API.

Open finance może pozwalać produktowi rozumieć znacznie większą część sytuacji finansowej klienta.

Aplikacja open banking może znać saldo i historię transakcji rachunku bieżącego. Aplikacja open finance mogłaby potencjalnie łączyć te informacje z danymi o oszczędnościach, inwestycjach, zadłużeniu, ubezpieczeniach i emeryturach.

Tworzy to zupełnie inne możliwości produktowe.

Od danych transakcyjnych do profilu finansowego

Dane open banking są szczególnie przydatne do zrozumienia przepływu pieniędzy.

Historia transakcji może pokazywać, jakie środki wpływają na rachunek, gdzie są wydawane i jak zmienia się cash flow.

Open finance może potencjalnie dodać informacje dotyczące aktywów, zobowiązań, ochrony i długoterminowych produktów finansowych.

Dla platformy wealth może to oznaczać możliwość zrozumienia inwestycji posiadanych w innych instytucjach. Dla pożyczkodawcy może stworzyć szerszy obraz zobowiązań finansowych i aktywów klienta.

Dla platformy do zarządzania finansami może umożliwić dashboard wykraczający poza bieżącą bankowość.

Wartość produktu wynika z połączenia tych różnych źródeł danych w coś użytecznego.

Samo wyświetlanie większej ilości informacji finansowych nie tworzy automatycznie lepszego produktu.

Open finance może zmienić dystrybucję finansową

Konsekwencje wykraczają poza dashboardy finansowe.

Jeśli klienci mogą łatwo przenosić swoje dane finansowe pomiędzy dostawcami, dystrybucja staje się bardziej konkurencyjna.

Firma mogłaby potencjalnie analizować istniejące produkty finansowe klienta i identyfikować sytuacje, w których inny produkt może być lepiej dopasowany.

Może to wpływać na takie obszary jak lending, wealth management, ubezpieczenia i oszczędności.

Instytucja posiadająca produkt nie musiałaby już koniecznie kontrolować całej relacji z klientem.

Jest to podobne do tego, co open banking już zrobił w płatnościach i dostępie do informacji o rachunkach, ale zastosowane do znacznie większej części usług finansowych.

Dla incumbentów tworzy to zarówno ryzyko, jak i możliwości. Mogą stracić część kontroli nad dystrybucją, ale jednocześnie sami mogą wykorzystywać zewnętrzne dane finansowe do budowania lepszych produktów.

Open finance w Unii Europejskiej

Unia Europejska pracuje nad szerszym frameworkiem udostępniania danych finansowych poprzez proponowane Financial Data Access Regulation, powszechnie znane jako FIDA.

Komisja Europejska opisuje FIDA jako framework open finance mający umożliwiać odpowiedzialny dostęp do danych klientów w szerszym zakresie usług finansowych, wykraczającym poza rachunki płatnicze.

Propozycja jest ważna, ponieważ PSD2 przede wszystkim otworzyła dostęp do danych rachunków płatniczych. FIDA ma znacznie rozszerzyć udostępnianie danych finansowych w całym sektorze finansowym.

W momencie pisania tego artykułu FIDA nadal znajduje się w procesie legislacyjnym UE i nie powinna być traktowana tak, jakby pełny framework open finance już funkcjonował w całej Unii.

Dla firm planujących przyszłe produkty finansowe kierunek jest jednak jasny. Europejska infrastruktura danych finansowych wychodzi poza płatności i rachunki bieżące.

Open finance w Wielkiej Brytanii

Wielka Brytania podąża w tym samym ogólnym kierunku.

Jej organy określają open finance jako rozszerzenie zasad ustanowionych przez open banking. Trwają prace nad use case'ami oraz przyszłymi podstawami regulacyjnymi potrzebnymi do wsparcia szerszego udostępniania danych finansowych.

Jest to szczególnie istotne, ponieważ Wielka Brytania posiada już stosunkowo dojrzałą infrastrukturę open banking.

Standardy, mechanizmy zgód, łączność API i ugruntowany ekosystem dostawców tworzą podstawę, którą potencjalnie można rozszerzyć na kolejne sektory finansowe.

Transformacja nadal będzie jednak wymagała nowych rozwiązań komercyjnych, regulacyjnych i technicznych.

Dane inwestycyjne nie są tym samym co dane dotyczące transakcji bankowych. Ubezpieczenia, emerytury i lending mają inne struktury danych, ryzyka klientów, cykle życia produktów i wymagania regulacyjne.

Open finance nie może więc po prostu skopiować API open banking i zastosować ich do każdego produktu finansowego.

Open finance oznacza bardziej złożone zarządzanie zgodą

Wraz ze wzrostem zakresu danych finansowych zgoda staje się coraz ważniejsza.

Udostępnienie przez klienta salda rachunku bieżącego dla konkretnej usługi jest stosunkowo łatwe do zrozumienia.

Dostawca proszący o dostęp do danych bankowych, inwestycyjnych, ubezpieczeniowych, emerytalnych i kredytowych tworzy znacznie szerszą relację opartą na danych.

Zespoły produktowe muszą wyjaśniać, jakie informacje są wymagane i dlaczego.

Zbieranie każdego dostępnego punktu danych tylko dlatego, że API na to pozwala, nie jest dobrą strategią open finance.

Uprawnienia powinny być powiązane z jasną korzyścią dla klienta.

Wpływa to również na zaufanie. Im bardziej wrażliwy i kompleksowy staje się profil finansowy, tym większe znaczenie mają bezpieczeństwo, transparentność i data governance.

Open finance jest szansą dla embedded finance

Open finance może również znacząco rozszerzyć możliwości embedded finance.

Platforma niebankowa mogłaby potencjalnie lepiej rozumieć sytuację finansową klienta i integrować bardziej dopasowane usługi finansowe z istniejącym workflow.

Na przykład biznesowa platforma SaaS mogłaby łączyć dane operacyjne ze swojego systemu z informacjami finansowymi uzyskanymi za zgodą klienta.

Mogłoby to wspierać lepszy lending, narzędzia cash-flow, produkty ubezpieczeniowe czy financial planning.

Najsilniejsze możliwości mogą pojawić się w produktach wertykalnych, w których platforma już rozumie kontekst klienta.

Ogólny feed danych finansowych ma sam w sobie ograniczoną wartość. Dane finansowe połączone ze specyficznymi dla danej branży danymi operacyjnymi mogą być znacznie bardziej użyteczne.

Open banking i open finance nie powinny być traktowane jako produkty

Oba terminy opisują modele infrastrukturalne, a nie kompletne propozycje dla klienta.

Firma nie tworzy wartości tylko dlatego, że podłączy kolejne API.

Tworzy ją wtedy, gdy to połączenie poprawia decyzję, usuwa tarcie, automatyzuje proces lub umożliwia stworzenie produktu, którego wcześniej nie dało się efektywnie dostarczyć.

Jest to szczególnie ważne w miarę przechodzenia branży w stronę open finance.

Bardziej dostępne dane stworzą więcej możliwości, ale sprawią również, że sam dostęp będzie coraz mniej wyróżniający.

Przewaga konkurencyjna będzie w coraz większym stopniu wynikała z tego, jak firmy interpretują dane, integrują je ze swoimi produktami i wykorzystują do tworzenia lepszego customer experience.

Open banking otworzył dostęp do części relacji finansowej. Open finance ma rozszerzyć tę samą zasadę na znacznie większy obszar usług finansowych.

Dla FinTech, SaaS i innych biznesów cyfrowych ekspansja ta może tworzyć znaczące możliwości. Najwięcej nie skorzystają jednak koniecznie firmy mające dostęp do największej ilości danych. Będą to firmy, które dokładnie wiedzą, jakich danych potrzebują i jaki problem chcą dzięki nim rozwiązać.

13. Co open banking oznacza dla firm FinTech, e-commerce i SaaS

Open banking jest często omawiany jako temat bankowy lub regulacyjny, ale jego wpływ komercyjny jest znacznie szerszy.

Dla biznesów cyfrowych tworzy sposób na osadzanie danych finansowych i funkcjonalności płatniczej bezpośrednio w produktach, które nie są tradycyjnymi produktami bankowymi. Może to zmieniać customer journeys, modele operacyjne i ekonomikę niektórych usług.

Możliwości są inne dla firm FinTech, e-commerce i SaaS, ale podstawowa zasada jest podobna. Open banking może usuwać procesy manualne, poprawiać dostęp do informacji finansowych i sprawiać, że usługi oparte na bankowości stają się częścią szerszego cyfrowego doświadczenia.

Najważniejsze pytanie nie brzmi, czy firma technicznie może podłączyć się do API open banking. Prawdziwe pytanie brzmi, czy to połączenie tworzy lepszy produkt lub lepszy model biznesowy.

Co open banking oznacza dla firm FinTech

Dla firm FinTech open banking może stać się kluczowym elementem infrastruktury produktowej.

Może wspierać agregację rachunków, płatności, lending, personal finance, business finance, onboarding, weryfikację i embedded financial services.

FinTech budujący aplikację do zarządzania finansami może wykorzystywać dane open banking do analizy sald rachunków i transakcji. Pożyczkodawca może wykorzystywać tę samą infrastrukturę do wspierania underwriting. Firma płatnicza może wykorzystywać inicjowanie płatności do tworzenia doświadczenia account-to-account.

Ta sama technologia wspiera więc bardzo różne propozycje produktowe.

Dlatego strategia open banking powinna zaczynać się od problemu, który firma chce rozwiązać, a nie od listy dostępnych endpointów API.

Dobry zespół produktowy powinien najpierw zdefiniować rezultat dla klienta. Dopiero później zdecydować, jakie dane, uprawnienia i dostawcy są potrzebni do jego osiągnięcia.

Open banking może ograniczać tarcie w onboardingu

Produkty finansowe często wymagają od klientów dostarczania informacji, które już istnieją w innym miejscu.

Firma może zostać poproszona o przesłanie wyciągów bankowych. Konsument może być zobowiązany ręcznie wpisać dane rachunku, informacje o dochodach lub dane transakcyjne.

Open banking może zastąpić część tych kroków bezpośrednim połączeniem ze źródłem.

Może to przyspieszyć onboarding i ograniczyć ręczną pracę związaną z weryfikacją.

Wprowadzenie połączenia open banking może jednak również stworzyć nowe tarcie. Klient może musieć wybrać bank, uwierzytelnić się i zatwierdzić dostęp.

Zespół produktowy powinien więc porównywać cały customer journey, a nie tylko liczbę ręcznych pól usuniętych z formularza.

Open banking może poprawiać decyzje finansowe

Dostęp do danych rachunków bankowych może również poprawiać decyzje podejmowane wewnątrz produktu.

Platforma lendingowa może korzystać z aktualnych danych cash-flow. Aplikacja do zarządzania finansami może wykorzystywać bieżące informacje o rachunku. Platforma finansowa dla firm może używać danych transakcyjnych do identyfikowania zmian płynności.

Przewaga konkurencyjna nie wynika z samego dostępu do danych.

Wielu dostawców może uzyskiwać dostęp do podobnych informacji.

Przewaga wynika z tego, jak dobrze firma potrafi interpretować dane i powiązać je z użytecznym działaniem dla klienta.

Ma to szczególne znaczenie w miarę upowszechniania infrastruktury open banking. Podstawowy dostęp staje się coraz mniej wyróżniający, a większego znaczenia nabierają analityka, projekt produktu i logika decyzyjna.

Co open banking oznacza dla firm e-commerce

Dla firm e-commerce najbardziej widocznym use case'em open banking są płatności.

Open banking może zapewniać opcję płatności account-to-account obok kart, portfeli i lokalnych metod płatności.

W niektórych przypadkach może to poprawiać ekonomikę płatności lub tworzyć bardziej bezpośredni przepływ płatniczy.

Merchantci powinni jednak unikać traktowania open banking jako metody płatności, która automatycznie działa lepiej od kart.

Business case w dużym stopniu zależy od rynku, segmentu klienta, wartości koszyka i istniejącego payment mix.

Na rynkach, na których klienci często korzystają już z bankowych metod płatności, adopcja może być łatwiejsza. Na innych wprowadzenie nowej opcji w checkout może wymagać większej edukacji klientów.

Konwersja checkoutu ma większe znaczenie niż możliwości techniczne

Merchant może posiadać technicznie poprawną integrację open banking i nadal osiągać słabe wyniki komercyjne.

Klient musi rozumieć metodę płatności, rozpoznawać proces wyboru banku i poprawnie przejść uwierzytelnianie.

Jeśli flow jest zbyt długi lub nieznany, konwersja może ucierpieć.

Dlatego firmy e-commerce powinny testować open banking na podstawie rzeczywistych metryk płatniczych.

Ważne wskaźniki obejmują wybór metody w checkout, ukończenie płatności, success rate dla poszczególnych banków, abandonment, czas settlementu i jakość procesu refundów.

Niska opłata transakcyjna nie rekompensuje metody płatności, która obniża konwersję.

Open banking może wspierać transakcje o wyższej wartości

Płatności open banking mogą być szczególnie interesujące przy zakupach o wyższej wartości.

Ekonomika akceptacji kart staje się bardziej widoczna wraz ze wzrostem wartości transakcji, podczas gdy bezpośrednie płatności bankowe mogą oferować inną strukturę kosztów.

Może to sprawić, że open banking warto ocenić w takich sektorach jak turystyka, usługi motoryzacyjne, elektronika, edukacja, usługi profesjonalne czy B2B commerce.

Koszt płatności nigdy nie powinien być jednak analizowany w oderwaniu od innych czynników.

Merchantci muszą również uwzględniać oczekiwania dotyczące ochrony klienta, refundy, procesy operacyjne i znajomość danej metody płatności wśród klientów.

Najlepszą metodą płatności jest ta, która działa dla całego procesu komercyjnego, a nie tylko dla samej transakcji.

Co open banking oznacza dla firm SaaS

Firmy SaaS mogą mieć jedne z najbardziej interesujących możliwości wykorzystania open banking, ponieważ funkcjonalność finansowa może zostać osadzona bezpośrednio w istniejących workflow biznesowych.

Platforma SaaS ma już relacje z klientami, dane operacyjne i zdefiniowany use case.

Open banking może dodać do tego środowiska warstwę finansową.

Platforma księgowa może importować transakcje. Platforma fakturowa może inicjować płatności. Narzędzie do zarządzania firmą może dostarczać informacje o cash flow. Produkt vertical SaaS może wykorzystywać dane finansowe do wspierania lendingu lub innych embedded financial services.

Może to zwiększać wartość podstawowego oprogramowania bez zmuszania firmy do stawania się tradycyjną instytucją finansową.

Vertical SaaS ma szczególną przewagę

Firmy vertical SaaS często lepiej rozumieją konkretny segment klientów niż ogólny dostawca finansowy.

Platforma obsługująca restauracje może rozumieć zamówienia, dostawców, zatrudnienie i wzorce przychodów. Platforma logistyczna może znać trasy, faktury i koszty floty. Platforma dla freelancerów może rozumieć umowy, billing i nieregularne dochody.

Open banking dodaje dane finansowe do istniejącego kontekstu operacyjnego.

Połączenie może być bardziej wartościowe niż którykolwiek z tych zbiorów danych osobno.

Tworzy to możliwości dla bardziej dopasowanych narzędzi cash-flow, produktów working capital, płatności i automatyzacji finansowej.

Najsilniejsze produkty embedded finance często zaczynają się właśnie od takiej przewagi operacyjnej.

Open banking może zmienić model biznesowy

Open banking nie jest wyłącznie decyzją dotyczącą funkcjonalności.

Może również wpływać na sposób generowania przychodu przez firmę.

Platforma SaaS może zacząć od przychodów subskrypcyjnych, a później dodać przychody z płatności, finansowania lub innych usług finansowych.

FinTech może wykorzystać open banking do ograniczenia kosztów pozyskania klienta lub kosztów operacyjnych. Platforma e-commerce może wykorzystać go do poprawy ekonomiki płatności lub rekonsyliacji.

Modele te mogą być atrakcyjne, ale zmieniają również zakres odpowiedzialności firmy.

Usługi finansowe wprowadzają zagadnienia regulacyjne, operacyjne i ryzyka, które mogą nie występować w pierwotnym produkcie.

Firmy powinny więc oceniać możliwość przychodową razem z konsekwencjami regulacyjnymi i operacyjnymi.

Open banking może wspierać ekspansję rynkową, ale jej nie automatyzuje

Dostawcy infrastruktury często umożliwiają połączenie z bankami w wielu krajach poprzez jedną integrację techniczną.

Może to tworzyć wrażenie, że ekspansja międzynarodowa staje się prosta.

W rzeczywistości różnice lokalne nadal mają znaczenie.

Firma musi rozumieć coverage banków, zachowania płatnicze, uwierzytelnianie, regulacje i oczekiwania klientów na każdym rynku.

Ta sama funkcja open banking może posiadać inną value proposition w poszczególnych krajach.

Dlatego ekspansja open banking powinna być traktowana jako decyzja go-to-market, a nie tylko rollout API.

Najlepsze produkty open banking ukrywają infrastrukturę

Klientów zazwyczaj nie interesuje to, że produkt wykorzystuje open banking.

Interesuje ich szybszy onboarding, prostsza płatność, szybsza decyzja kredytowa lub automatyczny dostęp do informacji finansowych.

Open banking działa najlepiej wtedy, gdy infrastruktura znika wewnątrz customer journey.

API jest ważne dla firmy budującej produkt, ale rzadko powinno być główną value proposition prezentowaną końcowemu użytkownikowi.

Dla firm FinTech, e-commerce i SaaS przewaga konkurencyjna wynika więc z execution produktowego.

Wygrywać nie muszą firmy posiadające najwięcej połączeń bankowych. Będą to te, które wykorzystają te połączenia do rozwiązania wartościowego problemu lepiej niż istniejące alternatywy.

14. Budowanie produktu z wykorzystaniem open banking

Zbudowanie produktu open banking jest bardziej złożone niż podłączenie API.

Skuteczna implementacja wymaga decyzji dotyczących projektowania produktu, technologii, regulacji, operacji i go-to-market.

Wiele projektów rozpoczyna się od pytania technicznego, na przykład którego dostawcę należy zintegrować. W praktyce decyzja ta powinna pojawić się później.

Pierwszym krokiem powinno być zdefiniowanie use case'u i dokładne zrozumienie, co open banking powinien robić wewnątrz produktu.

Zacznij od problemu klienta

Zespół produktowy powinien potrafić wyjaśnić, dlaczego połączenie open banking jest potrzebne.

Czy celem jest skrócenie onboardingu? Poprawa underwriting? Inicjowanie płatności? Automatyzacja rekonsyliacji? Stworzenie dashboardu finansowego?

Brzmi to oczywiście, ale jest jedną z najważniejszych decyzji w projekcie.

Infrastruktura open banking może wspierać wiele funkcji i łatwo jest zintegrować więcej danych, niż produkt rzeczywiście potrzebuje.

Jasno określony use case znacznie ułatwia późniejsze decyzje dotyczące uprawnień, dostawców, regulacji i UX.

Sprawia również, że value proposition staje się bardziej zrozumiała dla klienta.

Określ, jakie dane i funkcjonalności są naprawdę potrzebne

Po zdefiniowaniu use case'u firma powinna określić minimalny zakres danych lub funkcji płatniczych potrzebnych do jego realizacji.

Pożyczkodawca może potrzebować historii transakcji i danych rachunku. Produkt do zarządzania finansami osobistymi może potrzebować sald i transakcji z kilku rachunków. Produkt checkoutowy może potrzebować wyłącznie inicjowania płatności.

Zbieranie dodatkowych danych powinno mieć jasno określony cel.

Więcej danych zwiększa złożoność, wymagania bezpieczeństwa i obawy klientów.

Może również tworzyć niepotrzebną zależność od pól API, które nie są równie niezawodne we wszystkich bankach.

Dobra architektura produktowa zaczyna się od minimalnego użytecznego zakresu.

Bezpośrednie integracje czy agregator?

Jedną z pierwszych ważnych decyzji technicznych jest wybór pomiędzy bezpośrednimi integracjami z bankami a agregatorem open banking.

Bezpośrednie integracje mogą zapewniać większą kontrolę.

Firma może zarządzać indywidualnymi połączeniami bankowymi, optymalizować konkretne flow i ograniczać zależność od pośrednika.

Koszt może być jednak znaczący.

Każdy bank może wymagać oddzielnej pracy integracyjnej, testów, monitoringu i utrzymania.

Staje się to coraz trudniejsze wraz z ekspansją produktu na kilka państw.

Agregator zapewnia jedno API łączące wiele banków.

Może to skrócić czas implementacji i uprościć ekspansję.

Trade-off polega na tym, że firma uzależnia się od coverage agregatora, jego wydajności, modelu komercyjnego i decyzji technicznych.

Nie istnieje jedna uniwersalna odpowiedź.

Dla wielu firm agregator jest praktycznym punktem startowym. Większe lub bardziej wyspecjalizowane biznesy mogą później tworzyć bezpośrednie połączenia z krytycznymi bankami lub rynkami.

Oceniaj dostawców szerzej niż na podstawie prezentacji sprzedażowej

Dostawcy open banking często reklamują dużą liczbę obsługiwanych banków i krajów.

Liczby te są użyteczne, ale nie pokazują całego obrazu.

Firma musi rozumieć, co "obsługa" naprawdę oznacza.

Czy dostawca wspiera informacje o rachunkach, płatności czy jedno i drugie? Jakie rodzaje rachunków są objęte usługą? Jakie pola danych są dostępne? Czy połączenia wykorzystują oficjalne API? Jak często zawodzą?

W przypadku płatności ocena powinna być jeszcze szersza.

Zespoły powinny testować wybór banku, uwierzytelnianie, potwierdzanie płatności, informacje o settlement i rekonsyliację.

Najlepszy dostawca na papierze może nie oferować najlepszego customer experience w bankach, które są najważniejsze dla danego biznesu.

Coverage banków powinno odpowiadać bazie klientów

Lista setek banków nie jest automatycznie lepsza od mniejszej, ale bardziej odpowiedniej sieci.

Najważniejsze pytanie brzmi, jaka część rzeczywistej bazy klientów jest objęta usługą.

Jeśli 80% klientów firmy korzysta z dziesięciu banków, te dziesięć połączeń ma większe znaczenie niż długi ogon instytucji, które rzadko pojawiają się w produkcie.

Coverage powinno więc być analizowane w odniesieniu do rzeczywistej lub oczekiwanej dystrybucji klientów.

Jest to szczególnie istotne podczas ekspansji rynkowej.

Dostawca może deklarować ogólnokrajowy coverage, a jednocześnie działać słabo z jednym lub dwoma bankami dominującymi na danym rynku.

Zespoły produktowe powinny identyfikować takie ryzyka przed launch'em.

Architektura regulacyjna powinna być ustalana wcześnie

Produkty open banking mogą obejmować działania regulowane.

Firma musi więc rozumieć, czy będzie działać na podstawie własnej licencji, jako agent czy w modelu regulowanego partnera.

Właściwa struktura zależy od rynku i świadczonej usługi.

Decyzja ta wpływa na więcej niż compliance.

Może wpływać na wybór dostawcy, umowy, komunikację z klientem, onboarding flows i tempo przyszłej ekspansji.

Firma, która najpierw zbuduje produkt, a dopiero później zacznie myśleć o architekturze regulacyjnej, może odkryć, że preferowany model operacyjny nie jest możliwy.

Regulacje powinny więc być częścią architektury produktu od samego początku.

Zgoda jest częścią user experience

Zgoda jest wymagana z powodów regulacyjnych i bezpieczeństwa, ale jest również elementem konwersji.

Klienci muszą rozumieć, na co się zgadzają i dlaczego.

Komunikat typu "połącz swój bank" może nie wystarczyć.

Produkt powinien wyjaśniać, jakie informacje będą dostępne i co klient otrzyma w zamian.

Ma to szczególne znaczenie w lendingu i produktach data-driven.

Klient może być gotowy udostępnić historię transakcji, jeśli oznacza to brak konieczności przesyłania dokumentów lub szybszą decyzję.

Value exchange powinien być jasny przed rozpoczęciem uwierzytelniania.

Uwierzytelnianie może zdecydować o konwersji

Uwierzytelnianie jest często kontrolowane przez bank klienta, ale firma produktowa nadal odpowiada za cały customer journey.

Użytkownik może przechodzić z aplikacji do środowiska bankowego, a następnie wracać.

Jeśli przejście jest niejasne, konwersja może spadać.

Zespoły produktowe powinny testować uwierzytelnianie bank po banku.

Doświadczenie może różnić się pomiędzy mobile i desktop, pomiędzy bankami oraz pomiędzy metodami uwierzytelniania.

Deep linki, redirecty i przełączanie pomiędzy aplikacjami powinny być dokładnie testowane.

Konwersja open banking jest często determinowana właśnie przez te praktyczne szczegóły, a nie przez samą specyfikację API.

Niezawodność musi zostać zaprojektowana w produkcie

API bankowe i połączenia open banking mogą zawodzić.

Połączenia mogą timeoutować. Banki mogą być tymczasowo niedostępne. Uwierzytelnianie może się nie zakończyć. Dane mogą dotrzeć później niż oczekiwano.

System produkcyjny musi zakładać, że takie problemy będą się zdarzać.

Produkt powinien posiadać jasne stany błędów, mechanizmy ponawiania i procesy wsparcia.

W niektórych use case'ach mogą być również potrzebne metody fallback.

Pożyczkodawca może pozwolić na przesłanie dokumentów, jeśli połączenie z rachunkiem się nie powiedzie. Merchant może zaoferować inną metodę płatności, jeśli bank nie jest w stanie dokończyć transakcji.

Celem nie jest wyeliminowanie każdej awarii.

Chodzi o to, aby jedno nieudane połączenie bankowe nie psuło całego customer journey.

Nie należy zakładać wysokiej jakości danych

Open banking zapewnia ustrukturyzowany dostęp do informacji finansowych, ale nie oznacza to, że dane są zawsze gotowe do bezpośredniego użycia.

Opisy transakcji mogą się różnić. Nazwy merchantów mogą być niespójne. Kategorie mogą być niedostępne. Podobne transakcje mogą wyglądać inaczej w poszczególnych bankach.

Produkty zależne od interpretacji potrzebują więc dodatkowej warstwy danych.

Może ona obejmować enrichment, kategoryzację, normalizację lub własną analitykę.

Ma to szczególne znaczenie w lendingu i zarządzaniu finansami.

Wartość komercyjna często powstaje właśnie w tej warstwie interpretacyjnej, a nie w surowej odpowiedzi API.

Produkty płatnicze wymagają projektowania operacyjnego

Podczas budowania płatności open banking zespoły produktowe muszą myśleć szerzej niż tylko o inicjowaniu płatności.

Muszą wiedzieć, kiedy płatność można uznać za udaną, w jaki sposób monitorowany jest settlement i jak obsługiwane są płatności nieudane lub opóźnione.

Refundy również wymagają jasnego procesu.

Pierwotna płatność może przechodzić przez open banking, ale refund może wymagać innego mechanizmu.

Rekonsyliacja jest kolejnym krytycznym obszarem.

Merchantci i platformy muszą powiązać przelew bankowy z właściwym klientem, zamówieniem lub fakturą.

Ma to coraz większe znaczenie wraz ze wzrostem wolumenu płatności.

Kontrole fraudowe nadal mają znaczenie

Uwierzytelnianie open banking nie eliminuje fraudu.

Klient może poprawnie się uwierzytelnić, a jednocześnie zostać zmanipulowany do wykonania oszukańczej płatności.

Dla produktów płatniczych oznacza to, że transaction monitoring i kontrole fraudowe nadal muszą istnieć wokół przepływu open banking.

Produkty lendingowe mierzą się z innymi ryzykami.

Dane open banking mogą ograniczać niektóre formy manipulowania dokumentami, ale pożyczkodawca nadal potrzebuje weryfikacji tożsamości, fraud detection i kontroli ryzyka.

Infrastruktura zmienia część ryzyk. Nie eliminuje ich.

Pomyśl o wsparciu operacyjnym przed uruchomieniem

Open banking tworzy nowe rodzaje pytań do customer support.

Użytkownicy mogą pytać, dlaczego ich banku nie ma na liście, dlaczego połączenie wygasło lub dlaczego uwierzytelnianie się nie powiodło.

Zespoły support powinny rozumieć takie scenariusze.

Potrzebują również narzędzi pokazujących wystarczającą ilość informacji do zdiagnozowania problemu bez ujawniania wrażliwych danych bankowych.

Zespoły operacyjne powinny być zaangażowane przed launch'em, a nie dopiero po pojawieniu się problemów klientów.

To samo dotyczy zespołów finansowych i rekonsyliacyjnych w produktach płatniczych.

Technicznie działająca integracja nie jest gotowa do produkcji, dopóki biznes nie jest w stanie jej operacyjnie obsługiwać.

Przetestuj ekonomikę use case'u

Model komercyjny również powinien być testowany na wczesnym etapie.

Dostawcy open banking mogą pobierać opłaty za połączenie, wywołanie API, płatność, aktywnego użytkownika lub według innego modelu cenowego.

Koszty te należy porównać z wartością generowaną przez produkt.

W przypadku płatności oznacza to porównanie pełnej ekonomiki z alternatywnymi metodami.

W lendingu może oznaczać pomiar tego, czy automatyzacja obniża koszt underwriting lub poprawia jakość approval.

W SaaS pytanie może dotyczyć tego, czy funkcja finansowa zwiększa przychody subskrypcyjne, retencję lub tworzy nowe źródło przychodów.

Technicznie wartościowa funkcja nadal może mieć słaby business case.

Zbuduj model dla jednego rynku, zanim założysz globalną skalowalność

Z perspektywy API infrastruktura open banking może wyglądać globalnie.

Zachowanie produktu zazwyczaj jest lokalne.

Launch na jednym rynku pozwala firmie zrozumieć wydajność banków, uwierzytelnianie, zachowania klientów i problemy operacyjne przed dodaniem kolejnych warstw złożoności.

Gdy model zacznie działać, ekspansja może stać się łatwiejsza.

Każdy kolejny rynek nadal powinien być jednak traktowany jak oddzielny launch produktowy i go-to-market.

Firma powinna ponownie zweryfikować lokalne banki, regulacje, płatności i oczekiwania klientów.

Globalnego coverage API nie należy utożsamiać z globalnym product-market fit.

Implementacja open banking jest projektem cross-functional

Najsilniejsze produkty open banking nie są budowane wyłącznie przez zespoły technologiczne.

Product, engineering, compliance, risk, operations, finance i zespoły komercyjne często muszą współpracować.

Proporcje zależą od use case'u.

Aplikacja do zarządzania finansami może mocno koncentrować się na jakości danych i UX. Produkt lendingowy może wymagać większego zaangażowania risk i compliance. Produkt płatniczy może wymagać dużo pracy wokół rekonsyliacji i operacji.

Dlatego open banking powinien być traktowany jako część architektury produktu i modelu biznesowego, a nie jako izolowany projekt integracyjny.

Połączenie techniczne można często zbudować stosunkowo szybko.

Stworzenie wokół niego niezawodnego, zgodnego regulacyjnie i komercyjnie skutecznego produktu jest znacznie trudniejszą częścią.

15. Wyzwania i ograniczenia open banking

Open banking tworzy istotne możliwości, ale ma również praktyczne ograniczenia.

Koncepcja regulacyjna jest stosunkowo prosta: klienci mogą pozwolić autoryzowanym dostawcom uzyskiwać dostęp do informacji o rachunku lub inicjować płatności. Zbudowanie na tej infrastrukturze niezawodnego produktu komercyjnego jest znacznie trudniejsze.

Wyzwania pojawiają się na kilku poziomach. Obejmują wydajność API, coverage banków, uwierzytelnianie, jakość danych, adopcję klientów, ekonomikę, fraud, regulacje i złożoność operacyjną.

Dla firm analizujących open banking zrozumienie tych ograniczeń jest równie ważne jak zrozumienie korzyści.

Dostępność API nie oznacza jakości API

Bank może technicznie udostępniać API open banking, ale nie oznacza to, że połączenie zawsze zapewni doświadczenie wymagane przez produkt produkcyjny.

API mogą różnić się dostępnością, czasem odpowiedzi, obsługą błędów i spójnością zwracanych danych. Procesy uwierzytelniania również mogą działać inaczej w różnych bankach.

Staje się to szczególnie istotne dla firm działających w kilku krajach.

Agregator może uprościć warstwę techniczną, ale nie jest w stanie całkowicie usunąć problemów wynikających z bazowej infrastruktury bankowej.

Jeśli konkretne połączenie bankowe jest niestabilne, klienci tego banku nadal mogą doświadczać nieudanych połączeń lub płatności.

Zespoły produktowe powinny więc monitorować wydajność API na poziomie poszczególnych banków.

Open banking nadal jest fragmentaryczny pomiędzy rynkami

Nie istnieje globalny standard open banking.

UE, Wielka Brytania, USA, Australia, Brazylia i inne rynki wypracowały różne podejścia regulacyjne i techniczne.

Nawet w Unii Europejskiej PSD2 nie stworzyła jednej identycznej implementacji API używanej przez każdy bank.

Tworzy to złożoność dla produktów międzynarodowych.

Firma może współpracować z jednym dostawcą infrastruktury i technicznie mieć dostęp do kilku krajów, ale dostępne dane, doświadczenie uwierzytelniania i funkcjonalność płatnicza mogą nadal różnić się na każdym rynku.

Wymagania regulacyjne również mogą być różne.

Dlatego ekspansja open banking powinna być planowana kraj po kraju, nawet jeśli dostawca technologii oferuje globalne API.

Coverage banków może być mylące

Dostawcy open banking często opisują swoje usługi liczbą obsługiwanych banków lub krajów.

Liczby te wymagają kontekstu.

Dostawca może technicznie obsługiwać bank, a jednocześnie oferować tylko część funkcjonalności potrzebnej produktowi. Informacje o rachunku mogą działać, podczas gdy inicjowanie płatności nie, albo niektóre typy rachunków mogą być niedostępne.

Coverage może również różnić się jakością.

Obsługa małego banku wykorzystywanego przez niewielu docelowych klientów ma mniejszą wartość komercyjną niż bardzo dobre połączenie z dominującym bankiem na rynku.

Firmy powinny więc oceniać coverage na podstawie własnej bazy klientów i wymaganych use case'ów, a nie tylko headline'owej liczby integracji.

Uwierzytelnianie tworzy tarcie

Open banking wymaga bezpiecznego uwierzytelniania i zgody klienta.

Są to niezbędne elementy modelu, ale mogą również dodawać kolejne kroki do user journey.

Klient może być zmuszony wybrać bank, opuścić pierwotną aplikację, uwierzytelnić się w aplikacji bankowej, a następnie wrócić do wykorzystywanej usługi.

Każde przejście tworzy możliwość porzucenia procesu.

Wpływ może znacząco różnić się pomiędzy bankami i urządzeniami.

Flow dobrze działający na mobile może zachowywać się inaczej na desktop. Jeden bank może oferować płynny proces app-to-app, podczas gdy inny wymaga kilku dodatkowych kroków.

Dlatego testy konwersji powinny być prowadzone na rzeczywistych customer journeys bankowych, a nie wyłącznie w sandboxie API.

Zrozumienie open banking przez klientów pozostaje wyzwaniem

Termin open banking jest dobrze znany w branży finansowej, ale wielu końcowych użytkowników nie potrzebuje ani nie chce rozumieć infrastruktury stojącej za daną usługą.

Klient może zawahać się, gdy zostanie poproszony o "połączenie banku", szczególnie jeśli powód nie jest jasny.

Dobre projektowanie produktu powinno wyjaśniać korzyść przed poproszeniem o dostęp.

Na przykład komunikat "połącz swój bank, aby automatycznie zweryfikować dochód" jest bardziej użyteczny niż przedstawianie samego open banking jako funkcji.

Ta sama zasada dotyczy płatności.

Klienci są bardziej skłonni ukończyć nieznany im wcześniej proces płatniczy, jeśli rozumieją, co się wydarzy, i rozpoznają środowisko uwierzytelniania swojego banku.

Zaufanie jest więc częściowo problemem technologicznym, a częściowo komunikacyjnym.

Zgoda może tworzyć powtarzające się tarcie produktowe

Zgoda jest jedną z fundamentalnych zasad open banking, ale zarządzanie nią w czasie tworzy dodatkowe wymagania produktowe.

Uprawnienia mogą wygasać, wymagać odnowienia lub zostać wycofane przez użytkownika.

Firma musi rozumieć, co dzieje się po utracie dostępu.

Produkt do zarządzania finansami osobistymi może przestać otrzymywać nowe transakcje. Platforma biznesowa może stracić widoczność cash flow. Usługa lendingowa może potrzebować zaktualizowanych danych na późniejszym etapie relacji z klientem.

Scenariusze te muszą być zaprojektowane jako część cyklu życia produktu.

Open banking nie powinien być traktowany jako jednorazowa integracja onboardingowa.

Dane są ustrukturyzowane, ale niekoniecznie czyste

Bezpośredni dostęp do informacji bankowych może usunąć część ręcznego wprowadzania danych, ale otrzymane dane nie zawsze są od razu użyteczne.

Opisy transakcji mogą być niespójne. Informacje o merchantach mogą być niepełne. Kategorie mogą się różnić lub w ogóle nie być dostępne.

Ten sam rodzaj transakcji może wyglądać inaczej w zależności od banku i infrastruktury płatniczej.

Tworzy to dodatkową pracę dla firm wykorzystujących dane open banking w analityce, lendingu lub zarządzaniu finansami.

Normalizacja, kategoryzacja i enrichment mogą stać się oddzielnymi elementami architektury produktowej.

W wielu data-driven produktach open banking właśnie ta warstwa interpretacyjna jest miejscem, w którym powstaje duża część realnego IP.

Open banking nie zapewnia pełnego obrazu sytuacji finansowej

Dostęp do jednego rachunku bankowego nie musi pokazywać pełnej sytuacji finansowej klienta.

Konsument może korzystać z kilku rachunków bieżących, kart kredytowych, platform inwestycyjnych i produktów lendingowych.

Firma może posiadać rachunki w kilku bankach albo wykorzystywać oddzielne rachunki dla różnych podmiotów i walut.

Ma to szczególne znaczenie w lendingu.

Pożyczkodawca nie powinien zakładać, że analiza jednego połączonego rachunku zapewnia pełny obraz dochodów, wydatków, zadłużenia lub płynności.

Open finance może z czasem ograniczyć część tych problemów, rozszerzając zakres dostępnych danych finansowych, ale infrastruktura ta nadal rozwija się na wielu rynkach. Proponowany w UE framework Financial Data Access ma właśnie rozszerzyć udostępnianie danych poza rachunki płatnicze na szerszy zakres usług finansowych.

Inicjowanie płatności nie rozwiązuje całego procesu płatniczego

Open banking może umożliwić zainicjowanie płatności account-to-account, ale merchantci potrzebują znacznie więcej niż samego payment initiation.

Potrzebują statusu płatności, rekonsyliacji, informacji o settlement, refundów, customer support i obsługi wyjątków.

Płatność musi również działać komercyjnie wewnątrz checkoutu.

Tańsza metoda płatności niekoniecznie jest lepsza, jeśli klienci z niej nie korzystają lub jeśli konwersja jest znacząco niższa.

Dostawcy płatności open banking coraz częściej muszą więc konkurować całym merchant experience, a nie tylko dostępem do payment rail.

Dla większych biznesów e-commerce sprawia to, że open banking staje się problemem optymalizacji płatności, a nie wyłącznie problemem technologicznym.

Refundy i spory wymagają przemyślanego projektowania

Karty posiadają dojrzałe procesy dotyczące refundów, chargebacków i sporów.

Płatności open banking wykorzystują inną infrastrukturę i nie odtwarzają automatycznie tych samych mechanizmów.

Może to być zaletą w niektórych modelach biznesowych, ale może również tworzyć wyzwania operacyjne.

Merchantci potrzebują jasnego procesu zwracania środków i identyfikowania rachunku, na który refund powinien zostać przesłany.

Oczekiwania klientów również mają znaczenie.

Produkt płatniczy powinien zapewniać odpowiedni poziom ochrony i wsparcia nawet wtedy, gdy bazowy payment rail działa inaczej niż karty.

Ma to szczególne znaczenie przy wprowadzaniu płatności open banking do konsumenckiego e-commerce.

Płatności cykliczne nadal się rozwijają

Jednorazowe inicjowanie płatności jest stosunkowo dobrze rozwinięte, ale płatności cykliczne nadal są bardziej złożonym obszarem.

Wielka Brytania osiągnęła znaczący postęp dzięki Variable Recurring Payments, które pozwalają autoryzowanym dostawcom wykonywać płatności w ramach parametrów zatwierdzonych przez klienta. Wielka Brytania rozwija również komercyjne schematy VRP, aby rozszerzyć model poza pierwotne use case'y sweeping.

Funkcjonalność ta nie jest jednak równie rozwinięta na wszystkich rynkach open banking.

Firma SaaS lub subskrypcyjna nie może więc zakładać, że rozwiązanie płatnicze open banking zapewni takie same możliwości płatności cyklicznych w każdym kraju.

Wpływa to na modele biznesowe zależne od subskrypcji, rat lub powtarzalnych płatności klientów.

Nadal trzeba analizować lokalną infrastrukturę płatniczą.

Fraud nie znika

Open banking może poprawić bezpieczeństwo dostępu do rachunków bankowych, ale nie eliminuje fraudu płatniczego.

Klient może poprawnie się uwierzytelnić i nadal zostać zmanipulowany do zatwierdzenia oszukańczej transakcji.

Ma to szczególne znaczenie w przypadku authorised payment fraud i social engineering.

Brytyjski framework regulacyjny wyraźnie uwzględnia potrzebę ochrony bezpieczeństwa i integralności płatności account-to-account open banking przy jednoczesnym zarządzaniu ryzykiem fraudowym i financial crime.

Dla firm oznacza to, że uwierzytelnianie bankowe nie może zastąpić fraud management.

Transaction monitoring, analiza behawioralna, komunikacja z klientem i kontrole operacyjne nadal mogą być wymagane.

Regulacje tworzą zarówno dostęp, jak i złożoność

Open banking istnieje częściowo dlatego, że regulacje stworzyły dostęp do infrastruktury finansowej, do której wcześniej stronom trzecim trudno było dotrzeć.

Jednocześnie regulacje finansowe tworzą odpowiedzialności.

Firma musi rozumieć, które działania są regulowane, który podmiot je świadczy i w ramach jakiej licencji lub modelu partnerskiego działa produkt.

Staje się to bardziej złożone, gdy zaangażowanych jest kilka krajów.

FinTech może szybko skalować technologię, podczas gdy ekspansja regulacyjna odbywa się według innego harmonogramu.

Wybór dostawcy, kontraktowanie i strategia wejścia na rynek powinny więc od początku uwzględniać architekturę regulacyjną.

Zależność od dostawcy jest ryzykiem strategicznym

Korzystanie z agregatora może znacząco ograniczyć nakład pracy developmentowej, ale tworzy również zależność od innej firmy infrastrukturalnej.

Jeżeli dostawca zmieni ceny, usunie konkretne połączenie lub doświadczy poważnej awarii, produkt może zostać bezpośrednio dotknięty.

Zmiana dostawcy również może być trudna, gdy integracja staje się głęboko powiązana z logiką produktową, flow zgód i procesami operacyjnymi.

Vendor selection powinien więc uwzględniać długoterminowe dopasowanie strategiczne.

Firmy działające w dużej skali mogą również rozważać strategie multi-provider albo bezpośrednie integracje dla szczególnie ważnych rynków.

Jest to podobne do innych decyzji dotyczących krytycznej infrastruktury finansowej.

Wygoda podczas pierwszej integracji nie powinna być jedynym kryterium.

Ekonomika nie działa dla każdego use case'u

Open banking jest czasami przedstawiany jako z definicji tańsza infrastruktura finansowa.

To zbyt duże uproszczenie.

Ekonomika zależy od use case'u, cen dostawcy, wolumenów transakcji, kosztów integracji, procesów operacyjnych i alternatyw już dostępnych na rynku.

Dostawca płatności może pobierać opłatę za transakcję. Dostawca danych może pobierać opłatę za połączony rachunek, wywołanie API lub aktywnego użytkownika.

Firma musi również uwzględniać wewnętrzne koszty engineering, compliance, customer support i operacji.

Właściwym porównaniem jest pełna ekonomika, a nie cena API.

Open banking jest infrastrukturą, a nie strategią

Być może największe ograniczenie ma charakter koncepcyjny.

Open banking sam w sobie nie tworzy product-market fit.

Firma może posiadać doskonałe coverage banków, niezawodne API i silny setup regulacyjny, a mimo to zbudować produkt, którego klienci nie potrzebują.

Open banking powinien więc być traktowany jako infrastruktura umożliwiająca realizację value proposition.

Pytanie komercyjne zawsze powinno pojawić się jako pierwsze: jaki problem klienta można łatwiej rozwiązać dzięki dostępowi do danych finansowych lub funkcjonalności płatności bankowych?

Jeśli nie ma na nie dobrej odpowiedzi, dodanie open banking nie naprawi produktu.

16. Co dalej z open banking?

Open banking wchodzi w inną fazę rozwoju.

Pierwsza faza dotyczyła przede wszystkim dostępu: tworzenia zasad, API i infrastruktury technicznej umożliwiającej stronom trzecim łączenie się z rachunkami bankowymi.

Kolejna faza coraz bardziej dotyczy tego, co można zbudować na tej infrastrukturze.

Obejmuje to szerszy dostęp do danych finansowych, bardziej zaawansowane modele płatności, lepsze zachęty komercyjne i głębsze osadzanie funkcjonalności finansowej w produktach cyfrowych.

Open banking zmierza w stronę open finance

Najważniejszym długoterminowym kierunkiem jest przejście od open banking do open finance.

Open banking przede wszystkim otworzył dostęp do rachunków płatniczych. Open finance rozszerza tę samą zasadę na szerszy zakres produktów finansowych.

W Unii Europejskiej proponowany framework Financial Data Access, FIDA, ma stworzyć zasady kontrolowanego przez klienta udostępniania danych w usługach finansowych poza rachunkami płatniczymi.

Może to znacząco zwiększyć zakres danych dostępnych dla aplikacji finansowych.

Zamiast rozumieć wyłącznie transakcje na rachunku bieżącym produkty mogą w przyszłości łączyć informacje o inwestycjach, oszczędnościach, ubezpieczeniach, emeryturach, pożyczkach i innych relacjach finansowych.

Rezultatem może być znacznie bogatsza warstwa danych finansowych.

Więcej danych nie stworzy automatycznie lepszych produktów

Open finance udostępni więcej informacji, ale dostęp do większej ilości danych nie oznacza automatycznie tworzenia większej wartości.

Firmy będą musiały zdecydować, które informacje rzeczywiście poprawiają ich produkt.

Pożyczkodawca może skorzystać na lepszym obrazie zobowiązań i cash flow. Platforma wealth może skorzystać na widoczności inwestycji utrzymywanych w innych instytucjach.

Platforma SaaS może połączyć informacje finansowe z danymi operacyjnymi już dostępnymi w jej systemie.

Najsilniejsze produkty prawdopodobnie będą wykorzystywały tylko część dostępnych danych i stosowały je do jasno zdefiniowanego problemu klienta.

Dostęp do danych będzie coraz bardziej stawał się infrastrukturą. Interpretacja będzie źródłem przewagi.

Płatności wyjdą poza transakcje jednorazowe

Drugim ważnym kierunkiem jest rozwój bardziej elastycznych płatności account-to-account.

Tradycyjne inicjowanie płatności działa dobrze, gdy klient jest obecny i zatwierdza pojedynczą transakcję.

Wiele cyfrowych modeli biznesowych wymaga jednak większej elastyczności.

Subskrypcje, rachunki za media, spłaty pożyczek, zasilanie rachunków i inne powtarzalne płatności wymagają mechanizmu, który może działać w ramach uprawnień zatwierdzonych wcześniej.

Variable Recurring Payments są jedną z odpowiedzi na ten problem.

W Wielkiej Brytanii VRP już wspierają use case'y sweeping, podczas gdy branża rozwija komercyjną infrastrukturę VRP dla szerszego zakresu płatności. UK Payments Initiative Ltd została utworzona w grudniu 2025 roku jako należący do branży schemat skoncentrowany początkowo na komercyjnych VRP.

FCA również wskazała VRP jako ważny element kolejnego etapu brytyjskiego open banking.

Jeżeli komercyjnie opłacalne cykliczne płatności account-to-account osiągną większą skalę, zakres use case'ów płatności open banking znacząco się rozszerzy.

Płatności open banking będą coraz bardziej komercyjne

Wczesny model open banking był silnie kształtowany przez wymagania regulacyjne.

Kolejna faza wymaga zrównoważonych modeli komercyjnych.

Banki potrzebują powodów, aby inwestować w infrastrukturę wykraczającą poza minimalne compliance. Dostawcy open banking potrzebują modeli biznesowych pozwalających dalej rozwijać produkty. Merchantci potrzebują jasnych korzyści ekonomicznych lub związanych z customer experience.

Wielka Brytania jest wczesnym przykładem tej transformacji.

Przyszły framework ma łączyć wspólne standardy z komercyjnymi schematami rozwijającymi usługi na ich podstawie.

Może to zmienić konkurencję w open banking.

Dostawcy będą coraz częściej konkurować nie tylko dostępem, ale również konwersją, value-added services, narzędziami risk, rekonsyliacją, user experience i warunkami komercyjnymi.

Dla merchantów i firm FinTech powinno to sprawić, że open banking będzie coraz bardziej przypominał dojrzały rynek infrastrukturalny.

Lepsza wydajność API stanie się ważniejsza niż sam dostęp

Pierwsze pytanie regulacyjne dotyczyło tego, czy zewnętrzni dostawcy mogą uzyskać dostęp do rachunków bankowych.

Kolejne pytanie brzmi, czy dostęp ten jest wystarczająco niezawodny dla komercyjnych produktów działających w dużej skali.

Rozróżnienie to ma fundamentalne znaczenie.

Połączenie działające przez większość czasu może wystarczyć dla osobistego dashboardu finansowego. Może jednak nie wystarczyć dla metody płatności konkurującej bezpośrednio w checkout e-commerce.

To samo dotyczy lendingu i business finance.

Wraz ze wzrostem komercyjnego znaczenia open banking wydajność API, jakość uwierzytelniania i dostępność usług będą coraz częściej oceniane według standardów oczekiwanych od innej krytycznej infrastruktury finansowej.

Regulatorzy również zmierzają w tym kierunku. W Wielkiej Brytanii planowany Future Entity ma odgrywać rolę w obszarze standardów i monitorowania jakości oraz spójności technologii open banking.

Łączność z bankami będzie coraz mniej wyróżniająca

Dziś liczba podłączonych banków nadal może być ważnym selling pointem dostawców infrastruktury.

Z czasem podstawowa łączność prawdopodobnie stanie się bardziej ustandaryzowana.

Jeżeli kilku dostawców może łączyć się z tymi samymi dużymi bankami, samo połączenie traci wartość jako element wyróżniający.

Konkurencja przesuwa się wtedy wyżej w stacku.

Dostawcy mogą wyróżniać się poprzez data enrichment, analitykę, optymalizację płatności, narzędzia fraudowe, rekonsyliację, developer experience i specjalizację na konkretnych rynkach.

Ten sam proces zachodził już w innych obszarach infrastruktury finansowej.

Gdy łączność staje się dostępna dla wielu firm, wartość przesuwa się w stronę usług budowanych wokół niej.

Data enrichment będzie coraz ważniejszy

Surowe dane transakcyjne mają ograniczoną wartość, jeśli produkt nie jest w stanie ich zrozumieć.

Tworzy to możliwości dla dostawców specjalizujących się w kategoryzacji, identyfikacji merchantów, analizie cash flow i modelowaniu zachowań finansowych.

W lendingu lepszy enrichment może poprawiać dane wejściowe do underwriting.

W zarządzaniu finansami może poprawiać budżetowanie i prognozowanie.

W SaaS dane finansowe mogą być łączone z fakturami, zamówieniami, inventory lub innymi informacjami operacyjnymi.

Tworzy to znacznie bogatszą warstwę produktową niż zwykła agregacja rachunków bankowych.

Przewaga konkurencyjna może w coraz większym stopniu wynikać z tego, co dzieje się po otrzymaniu danych z banku.

Open banking i embedded finance będą coraz bardziej się przenikać

Open banking ułatwia integrowanie możliwości finansowych w produktach niebankowych.

Embedded finance sprawia, że możliwości te stają się częścią szerszego customer journey.

Oba modele naturalnie się więc przenikają.

Platforma vertical SaaS może wykorzystywać open banking do łączenia rachunków bankowych, rozumienia cash flow i inicjowania płatności bez prezentowania open banking jako widocznego produktu.

Platforma e-commerce może używać go jako elementu checkoutu lub zarządzania finansami merchanta.

Marketplace może łączyć płatności, rekonsyliację i finansowanie.

W każdym z tych przykładów klienci mogą nigdy nie określać usługi jako open banking.

Prawdopodobnie będzie to jeden z najważniejszych kierunków dla całej branży.

Open banking staje się bardziej wartościowy wtedy, gdy przestaje być oddzielną funkcją i staje się infrastrukturą wewnątrz innego produktu.

Open banking może stać się częścią bardziej zautomatyzowanych produktów finansowych

Dostęp do aktualnych danych finansowych tworzy również możliwości większej automatyzacji.

Platforma finansowa dla firm może reagować na zmiany cash flow. Pożyczkodawca może aktualizować część swojego obrazu ryzyka przy użyciu bardziej aktualnych informacji. Produkt treasury może automatyzować działania finansowe na podstawie zdefiniowanych wcześniej reguł.

Możliwości płatności cyklicznych mogą rozszerzyć to jeszcze bardziej, pozwalając produktom nie tylko obserwować informacje finansowe, ale również wykonywać działania w ramach parametrów zatwierdzonych przez klienta.

Przesuwa to open banking od samej łączności w stronę automatyzacji finansowej.

Najważniejszym ograniczeniem nadal pozostaje kontrola klienta.

Bardziej zautomatyzowane produkty wymagają jasnych uprawnień, limitów ryzyka i zrozumiałej zgody.

Celem powinno być usuwanie niepotrzebnej pracy manualnej, a nie eliminowanie transparentności.

Model regulacyjny nadal będzie ewoluował

Regulacje open banking nie są jeszcze zakończonym procesem.

W UE framework usług płatniczych wychodzi poza PSD2 poprzez proponowane PSD3 i Payment Services Regulation, natomiast FIDA ma stworzyć szerszy framework open finance.

W Wielkiej Brytanii trwają prace nad Future Entity oraz strukturami komercyjnymi wspierającymi kolejny etap rynku.

Inne kraje rozwijają własne modele.

Dla firm działających międzynarodowo monitoring regulacyjny nadal będzie więc częścią strategii produktowej.

Ogólny kierunek może być podobny, ale implementacja nadal będzie różnić się pomiędzy rynkami.

Kolejna konkurencja będzie odbywać się ponad warstwą API

Open banking rozpoczął się od rozwiązania problemu infrastrukturalnego.

Banki posiadały dane finansowe i możliwości płatnicze. Strony trzecie potrzebowały kontrolowanego sposobu dostępu do nich.

W miarę upowszechniania takiego dostępu sama infrastruktura staje się mniej wyróżniająca.

Kolejna faza konkurencji będzie coraz bardziej odbywać się w warstwie produktowej.

Który pożyczkodawca podejmie najlepszą decyzję na podstawie danych finansowych? Który merchant stworzy najbardziej płynny checkout account-to-account? Która platforma SaaS potrafi przekształcić informacje bankowe w użyteczną automatyzację?

Pytania te są ważniejsze niż liczba dostępnych endpointów API.

Open banking stanie się mniej widoczny

Najbardziej dojrzałymi produktami open banking mogą ostatecznie być te, w których klienci w ogóle nie myślą o open banking.

Po prostu zobaczą, że informacje finansowe pojawiły się automatycznie, płatność wymagała mniej kroków albo decyzja finansowa została podjęta szybciej.

Jest to normalny etap rozwoju infrastruktury.

Użytkownicy nie muszą rozumieć architektury technicznej stojącej za przetwarzaniem kart, cloud computingiem czy telekomunikacją, aby korzystać z produktów zbudowanych na tych technologiach.

Open banking może podążyć tą samą drogą.

Technologia staje się infrastrukturą, a klient doświadcza efektu.

Dla firm FinTech, e-commerce i SaaS jest to prawdopodobnie najważniejszy kierunek do zrozumienia.

Szansa nie polega już po prostu na "wykorzystaniu open banking". Chodzi o budowanie produktów, w których open banking sprawia, że coś staje się zauważalnie szybsze, łatwiejsze, tańsze lub bardziej inteligentne, nie stając się przy tym samym produktem.

17. FAQ

Czym jest open banking w prostych słowach?

Open banking pozwala klientom przyznawać autoryzowanym zewnętrznym dostawcom dostęp do wybranych danych rachunku bankowego lub funkcji płatniczych.

Zazwyczaj odbywa się to poprzez bezpieczne API i dopiero po udzieleniu zgody przez klienta.

W praktyce open banking można wykorzystywać do łączenia rachunków bankowych z aplikacjami FinTech, inicjowania płatności, weryfikowania dochodu, analizowania cash flow lub automatyzowania procesów finansowych.

Jak działa open banking?

Open banking zazwyczaj łączy trzy strony: klienta, zewnętrznego dostawcę i bank.

Klient rozpoczyna proces w aplikacji zewnętrznego dostawcy, wybiera swój bank i zatwierdza wymagany dostęp.

Bank uwierzytelnia klienta, a następnie komunikuje się z dostawcą poprzez API.

W zależności od usługi dostawca może otrzymać informacje o rachunku albo wysłać żądanie zainicjowania płatności.

Czym jest API open banking?

API open banking to interfejs techniczny umożliwiający bankom i autoryzowanym zewnętrznym dostawcom wymianę danych lub instrukcji płatniczych w ustrukturyzowany sposób.

Może zapewniać dostęp do takich informacji jak saldo, transakcje i dane rachunku albo pozwalać dostawcy zainicjować płatność.

Dokładna funkcjonalność zależy od rynku, banku i frameworku regulacyjnego.

API open banking należy traktować jako infrastrukturę. Wartość biznesowa wynika z produktu lub customer experience zbudowanych na tej infrastrukturze.

Czy open banking jest bezpieczny?

Na rynkach regulowanych open banking jest projektowany wokół zgody klienta, kontrolowanych uprawnień, bezpiecznego uwierzytelniania i zdefiniowanego dostępu pomiędzy bankami a autoryzowanymi dostawcami.

Klienci zazwyczaj uwierzytelniają się bezpośrednio w swoim banku zamiast przekazywać hasło do bankowości internetowej zewnętrznemu dostawcy.

Bezpieczeństwo zależy jednak również od dostawcy, implementacji technicznej, data governance i zachowania klienta.

Open banking ogranicza część ryzyk związanych ze starszymi metodami udostępniania danych finansowych, ale nie eliminuje fraudu, cyber risk ani słabej implementacji.

Czym są płatności open banking?

Płatności open banking pozwalają klientom inicjować płatności bezpośrednio z rachunku bankowego poprzez aplikację zewnętrznego dostawcy.

Zazwyczaj są to płatności account-to-account.

Zamiast ręcznie tworzyć przelew bankowy klient wybiera swój bank, uwierzytelnia się i zatwierdza płatność wewnątrz payment journey.

Dla merchantów open banking może stanowić kolejną opcję checkout obok kart, portfeli i lokalnych metod płatności.

Czym są open banking loans?

Open banking loans to produkty lendingowe (pożyczkowe), w których dane open banking są wykorzystywane jako element procesu wnioskowania lub oceny kredytowej.

Pożyczkodawca może wykorzystywać dane rachunku bankowego do weryfikacji dochodu, analizy wydatków, zrozumienia cash flow lub wsparcia affordability assessment.

Open banking może ograniczać konieczność ręcznego przesyłania wyciągów bankowych i pomagać automatyzować część underwriting.

Nie zastępuje jednak zarządzania ryzykiem kredytowym. Pożyczkodawca nadal potrzebuje odpowiednich modeli ryzyka, polityk lendingowych, kontroli fraudowych i procesów regulacyjnych.

Czy open banking jest tym samym co open finance?

Nie.

Open banking koncentruje się przede wszystkim na dostępie do danych bankowych i usług płatniczych, szczególnie tych dotyczących rachunków płatniczych.

Open finance rozszerza tę samą zasadę na szerszy zakres produktów finansowych.

Może to obejmować inwestycje, oszczędności, emerytury, ubezpieczenia, kredyty hipoteczne i inne formy lendingu.

Open banking można więc traktować jako część szerszego modelu open finance.

Czy wszystkie banki wspierają open banking?

Nie, nie w taki sam sposób.

Wsparcie zależy od kraju, frameworku regulacyjnego, banku i rodzaju rachunku.

Na niektórych rynkach banki mają obowiązek zapewniać określone rodzaje dostępu. Na innych łączność w większym stopniu zależy od umów komercyjnych lub standardów branżowych.

Nawet tam, gdzie open banking jest szeroko dostępny, jakość API, zakres danych i funkcjonalność płatnicza mogą znacząco różnić się pomiędzy bankami.

Firmy budujące produkty na kilku rynkach powinny więc analizować coverage na poziomie poszczególnych banków zamiast przyjmować je jako założenie.

Czy klienci muszą udostępniać hasło do bankowości internetowej?

W nowoczesnym open banking opartym na API klienci generalnie nie powinni być zobowiązani do przekazywania danych logowania do bankowości internetowej bezpośrednio zewnętrznemu dostawcy.

Uwierzytelnianie zazwyczaj odbywa się w środowisku banku.

Dostawca otrzymuje zatwierdzony przez klienta dostęp lub autoryzację płatności, a nie nieograniczony dostęp do rachunku bankowego.

Jest to jedna z kluczowych różnic pomiędzy regulowanym open banking opartym na API a starszymi metodami uzyskiwania dostępu do danych finansowych.

Czy open banking może być wykorzystywany w e-commerce?

Tak.

Najczęstszym use case'em e-commerce jest inicjowanie płatności account-to-account.

Merchant może dodać open banking jako metodę płatności i pozwolić klientom płacić bezpośrednio z ich rachunków bankowych.

Open banking może również wspierać rekonsyliację, weryfikację rachunku i inne procesy finansowe.

To, czy ma to sens komercyjny, zależy od rynku, segmentu klienta, wartości transakcji i istniejącego payment mix.

Czy firmy SaaS mogą wykorzystywać open banking?

Tak.

Firmy SaaS mogą wykorzystywać open banking do dodawania funkcjonalności finansowej do istniejących produktów.

Przykłady obejmują automatyczny import transakcji, analizę cash flow, weryfikację rachunku, płatności i embedded lending.

Może to być szczególnie wartościowe dla platform vertical SaaS, które już posiadają dane operacyjne dotyczące konkretnego segmentu klientów.

Najsilniejsze use case'y zazwyczaj łączą dane bankowe z workflow, którym produkt SaaS już zarządza.

Czy open banking może zastąpić karty?

Nie w każdym use case'ie.

Płatności open banking mogą konkurować z kartami przy części transakcji, ale oba modele mają inne mocne strony.

Karty oferują dojrzałą globalną akceptację, ugruntowane modele płatności cyklicznych oraz dobrze rozwinięte procesy refundów i sporów.

Open banking może zapewniać bezpośrednie płatności account-to-account, inną ekonomikę transakcji i silną integrację z uwierzytelnianiem bankowym.

Dla większości merchantów lepszym pytaniem nie jest to, czy open banking powinien całkowicie zastąpić karty, ale gdzie może poprawić istniejący payment mix.

18. Podsumowanie

Czym więc jest open banking?

W swojej podstawowej formie open banking jest modelem pozwalającym klientom bezpiecznie udzielać autoryzowanym stronom trzecim dostępu do wybranych danych bankowych lub funkcji płatniczych. API, zgoda klienta i uwierzytelnianie tworzą techniczną i regulacyjną podstawę takiego dostępu.

Znaczenie open banking jest jednak znacznie większe jako infrastruktury niż jako samodzielnej koncepcji.

Może wspierać płatności, lending, agregację rachunków, zarządzanie finansami, weryfikację, księgowość, rekonsyliację i embedded financial services. Ta sama infrastruktura może więc tworzyć wartość w FinTech, e-commerce, SaaS i wielu innych cyfrowych modelach biznesowych.

Rynek również staje się coraz bardziej dojrzały.

Pierwszy etap open banking koncentrował się na stworzeniu dostępu do rachunków bankowych. Kolejny dotyczy poprawy niezawodności, rozszerzenia funkcjonalności płatniczej, budowania zrównoważonych modeli komercyjnych i przechodzenia w stronę szerszego open finance.

Dla firm zmienia to pytanie strategiczne.

Nie wystarczy już pytać, czy open banking jest dostępny albo czy integracja API jest technicznie możliwa.

Firmy muszą rozumieć, jaki problem klienta chcą rozwiązać, jakie dane lub możliwości płatnicze są potrzebne, jak usługa będzie działać na konkretnym rynku i czy ekonomika uzasadnia produkt.

Muszą również uwzględniać regulacje, coverage banków, customer experience, bezpieczeństwo, jakość danych, procesy operacyjne i zależność od dostawcy.

To właśnie tutaj znajduje się duża część rzeczywistej złożoności.

Skuteczny produkt open banking rzadko jest więc wyłącznie projektem API. Jest jednocześnie projektem produktowym, regulacyjnym, technologicznym i go-to-market. Najsilniejsze implementacje to zazwyczaj te, w których klienci prawie nie zauważają infrastruktury.

Po prostu otrzymują szybszą płatność, prostszy onboarding, lepszy obraz finansów, bardziej zautomatyzowany workflow albo szybszą decyzję. Właśnie tutaj open banking tworzy realną wartość: nie poprzez eksponowanie infrastruktury bankowej, ale poprzez umożliwianie budowania lepszych produktów finansowych.