Pierwszy “polski” dostawca usługi dostępu do rachunku z licencją na Litwie. Czym jest Account Information Service?

Bank Litwy jest ostatnio bardzo aktywny, jeżeli chodzi o wydawanie licencji bankom, jak i instytucjom płatniczym. W ostatnią środę opublikowana została informacja odnośnie przyznania przez naszego sąsiada licencji Account Information Service Provider’a podmiotowi z polskimi korzeniami (o procesie rejestracji w Polsce pisałem tutaj). Spółka Kontomatik UAB należąca do polskiego podmiotu będzie tym samym mogła świadczyć usługę w całej Unii Europejskiej. Czym jest usługa AIS i jakie obowiązki ciążą na instytucji, która chciałby zarabiać na udostępnianiu informacji o naszych rachunkach? Artykuł nie jest sponsorowany.

Usługa AIS została wprowadzona do unijnego prawa poprzez dyrektywę PSD2 (art. 4 pkt 13) oraz ustawę o usługach płatniczych (art. 3 ust. 6). Problematykę świadczenia samej usługi reguluje m.in. Dział IIIB UoP oraz przepisy Rozporządzenia 2018/389.

Na czym polega AIS?

Warto to wyjaśnić na przykładzie Kontomatik. Za pomocą usługi pożyczkodawca może w szybko sposób dokonać weryfikacji stanu finansów potencjalnego pożyczkobiorcy. Klient loguje się za pomocą odpowiedniej aplikacji do swojego banku (z użyciem jego danych uwierzytelniających). Następnie aplikacja agreguje dane dotyczące rachunku (lub rachunków), w tym ściąga dane dotyczące transakcji z określonego przedziału czasowego. W kolejnym kroku na podstawie uzyskanych danych firma, która ma udzielić pożyczki otrzymuje szeroki obraz potencjalnego klienta i może mu nadać odpowiedni scoring (punktację). Kontomatik stosując machine learning opracowuje profil klienta co znacznie przyśpiesza proces przyznawania pożyczki.

Innym przykładem będą aplikacje, które pozwalają na stworzenie obrazu naszego budżetu domowego, w tym prześledzenie jakie kategorie zakupów najbardziej obciążają nasze finanse, a nawet stworzenie przewidywanego obciążenia na najbliższy czas.

W ujęciu prawnym AIS to po prostu  usługę on-line, która polega na dostarczaniu skonsolidowanych informacji dotyczących rachunku lub rachunków prowadzonych w bankach. Opracowanie własne. IDU – indywidualne dane uwierzytelniające.

Jakie obowiązki musi spełniać AISP?

Poza wymogami organizacyjnym, które opisałem już w tym artykule, na AISP ciąży całkiem sporo obowiązków względem klientów, a także banków, w których klienci mają rachunki. Jest to związane z faktem, że dostęp do rachunków (wyłącznie on-line) odbywa się za pomocą tzw. API, czyli specjalnego interfejsu dostępowego, który jest udostępniany przez bank i do którego dostępu uzyskują uprawnione podmioty trzecie (TPP) – pisałem o tym tutaj. Wiąże się z tym m.in. konieczność posiadania odpowiednich certyfikatów eIDAS pozwalających na identyfikację względem banku czy odpowiednie zabezpieczenia, w tym w zakresie infrastruktury.

Sam dostęp do rachunku może odbyć się wyłącznie za wyraźną zgodą użytkownika (wykorzystanie indywidualnych danych uwierzytelniających oraz zaznaczony tick box wydają się spełniać ten wymóg). AISP musi również zapewnić, ze te indywidualne dane były w odpowiedni sposób chronione przed nieuprawnionym dostępem podmiotów trzecich, a także muszą być “transferowane” do banku za pomocą pośrednictwem bezpiecznych i wydajnych kanałów komunikacji. Jak już wspomniałem zakres wymogów jest dużo szerszy, ale to jest to bez wątpienia temat na odrębny artykuł.

Co może, a czego nie może AISP?

Przede wszystkim może wejść w posiadanie wyłącznie tych informacji, które dotyczą rachunku i związanych z tym rachunkiem (lub rachunkami) transakcji płatniczych. Nie może również żądać żadnych szczególnie chronionych danych dotyczących płatności powiązanych z tym rachunkiem, a także pod żadnym pozorem nie może używać, uzyskiwać ani przechowywać pobranych z banku danych do celów innych niż wykonanie określonej usługi dla klienta. Zakres tej usługi musi być więc określony w odpowiedniej umowie.

W kontekście API pojawiają się również dodatkowe zakazy i nakazy, szczególnie w kontekście tzw. środków awaryjnych (pisałem o tym tutaj). Przykładowo, jeżeli bank, w przypadku wystąpienia awarii interfejsu dostępowego, udostępnia AISP (i innym TPP) interfejs udostępniany w normalnych warunkach użytkownikom rachunków, to tacy dostawcy muszą zastosować takie środki, które zapewniają, ze nie będą mieli oni dostępu do danych (ani ich nie przechowywali bądź przetwarzali) niż niezbędne do konkretnej usługi. W praktyce oznacza to, że aplikacja pobierające dane musi “ściągać” tylko te dane, które normalnie pozyskiwane są dla usługi AIS.

Taki dostawca musi dodatkowo rejestrować wszystkie dane, do których uzyskał dostęp w ramach takiego środka awaryjnego. Jeżeli KNF zgłosi się po te dane, to musi on bez zbędnej zwłoki je udostępnić. AISP ma również obowiązek przekazać KNF uzasadnienie użycia takiego dostępu bezpośredniego, a także informować banki o tym fakcie. Istnieją również ograniczenia w zakresie dostępu do informacji o rachunkach. Jeżeli użytkownik nie żąda czynnie takich informacji, to AISP może je pozyskiwać nie częściej niż 4 razy na 24 godziny (z pewnymi wyjątkami).

Jaka jest przyszłość AISP?

Jest to temat nowy, ale na rynku widać coraz większe zainteresowanie tego typu usługami (pisał o tym chociażby fintek.pl). Wciąż jest wiele niewiadomych w zakresie zapewnienia bezpieczeństwa, co opóźnia nieco wejście na rynek nowych podmiotów. Ważna jest również świadomość potencjalnych klientów i możliwość biznesowego wykorzystania aplikacji. Wydaje się jednak, że potencjał jest. Wciąż czekam na takie podmioty zarejestrowane przez KNF.