Aplikacja mobilna dla fintechu — bezpieczeństwo, płatności i wymogi regulacyjne

Fintech to dziś najszerzej rozumiana kategoria: neobank, aplikacja pożyczkowa, portfel kryptoaktywów, narzędzie do faktoringu, aplikacja ubezpieczyciela, kantor internetowy czy warstwa płatnicza w produkcie, który formalnie fintechem nie jest. Łączy je jedno — aplikacja dotyka cudzych pieniędzy i cudzej tożsamości, a to zmienia reguły gry na każdym etapie projektu.

W zwykłej aplikacji błąd oznacza zły UX. W aplikacji finansowej ten sam błąd oznacza stratę środków użytkownika, incydent zgłaszany do nadzoru albo wstrzymanie usługi. Dlatego projekt fintechowy zaczyna się nie od makiet, tylko od dwóch pytań: w jakim reżimie regulacyjnym działamy i czyją licencję wykorzystujemy.

Ten artykuł przeprowadza przez to, co realnie decyduje o powodzeniu takiego projektu: modele licencyjne, onboarding z KYC, silne uwierzytelnianie i biometrię, płatności (w tym BLIK, NFC i BLE), warstwy bezpieczeństwa aplikacji finansowej oraz koszty.

Uwaga. Stan regulacyjny opisujemy według wiedzy na lipiec 2026 r. Przepisy sektora finansowego zmieniają się szybko (PSD3/PSR, pakiet AML, AI Act, eIDAS 2), a interpretacje nadzorcze jeszcze szybciej. Przed decyzjami produktowymi zweryfikuj aktualny stan z prawnikiem specjalizującym się w prawie rynku finansowego.

Najpierw model licencyjny, dopiero potem backlog

Zakres pracy i budżet aplikacji fintechowej zależą przede wszystkim od tego, kto jest podmiotem regulowanym. W praktyce spotykamy cztery scenariusze:

• Własna licencja (bank, krajowa instytucja płatnicza, instytucja pożyczkowa, dostawca usług w zakresie kryptoaktywów). Pełna odpowiedzialność regulacyjna, najdłuższy proces, najwyższe wymagania wobec IT.
• Mała instytucja płatnicza (MIP) — lżejszy próg wejścia i uproszczone wymogi, ale z limitami obrotu. Częsty start dla polskiego fintechu, który później przechodzi na pełną licencję KIP.
• Model agencyjny / white-label (BaaS) — licencję ma partner (bank lub instytucja płatnicza), Ty budujesz warstwę produktową na jego API. Najszybsze wejście na rynek, ale Twoja architektura jest zakładnikiem możliwości partnera.
• Brak własnej licencji — produkt korzysta wyłącznie z gotowych bramek płatniczych i nie przechowuje środków użytkowników. Wtedy większość ciężaru regulacyjnego zostaje po stronie operatora płatności.

To rozstrzygnięcie ma bezpośrednie skutki techniczne: czy prowadzisz własny rejestr sald, czy musisz raportować transakcje, jakie masz obowiązki w zakresie ciągłości działania i jak wygląda audyt Twojego kodu. Decyzja o modelu przed rozpoczęciem prac potrafi zmienić budżet dwukrotnie.

Ramy regulacyjne, które dotykają warstwy mobilnej

Nie każdy przepis przekłada się na kod. Te przekładają się wprost:

PSD2 i silne uwierzytelnianie klienta (SCA)

Fundament płatności elektronicznych w UE. Wymaga uwierzytelnienia dwoma niezależnymi czynnikami z kategorii: coś, co wiesz (PIN), coś, co masz (urządzenie), czym jesteś (biometria). Do tego dochodzi dynamic linking — kod autoryzacyjny musi być powiązany z konkretną kwotą i odbiorcą, a użytkownik musi je widzieć w momencie zatwierdzania. To bezpośrednio kształtuje ekran potwierdzenia transakcji.

PSD2 przewiduje też wyłączenia od SCA (niskie kwoty, transakcje zaufane, analiza ryzyka transakcji) — świadome ich wykorzystanie realnie poprawia konwersję, więc warto zaplanować je jako część logiki produktu, a nie doklejać później.

DORA — odporność cyfrowa

Rozporządzenie o operacyjnej odporności cyfrowej sektora finansowego obowiązuje od stycznia 2025 r. i dla zespołów produktowych oznacza konkretne rzeczy: zarządzanie ryzykiem ICT, rejestr i klasyfikację incydentów z terminami zgłoszeń, testowanie odporności, a także wymogi wobec zewnętrznych dostawców IT — w tym software house'u, który buduje i utrzymuje aplikację. Umowa z wykonawcą musi zawierać klauzule wymagane przez DORA (prawo audytu, ciągłość działania, strategia wyjścia).

AML i przeciwdziałanie praniu pieniędzy

Instytucja obowiązana musi stosować środki bezpieczeństwa finansowego: identyfikację i weryfikację klienta, ustalanie beneficjenta rzeczywistego, weryfikację na listach sankcyjnych i PEP, monitorowanie transakcji oraz raportowanie podejrzanych operacji. W aplikacji przekłada się to na cały proces onboardingu i na mechanizmy blokad, które muszą działać także po założeniu konta.

RODO

Dane finansowe nie są formalnie „danymi wrażliwymi" w rozumieniu art. 9 RODO, ale dane biometryczne wykorzystywane do identyfikacji już tak. Stąd zasada: wzorzec biometryczny zostaje na urządzeniu, w bezpiecznym enklawie systemowej, a aplikacja dostaje wyłącznie wynik „potwierdzono / nie potwierdzono". Nigdy nie wysyłaj odcisku palca ani szablonu twarzy na serwer, jeśli nie masz na to twardej podstawy prawnej i oceny skutków (DPIA).

MiCA — jeśli dotykasz kryptoaktywów

Rozporządzenie MiCA reguluje emisję kryptoaktywów i świadczenie usług z nimi związanych w UE, wraz z obowiązkiem uzyskania zezwolenia. Jeśli Twoja aplikacja umożliwia przechowywanie, wymianę lub transfer kryptoaktywów, jest to pierwsza rzecz do sprawdzenia — łącznie ze statusem krajowych przepisów wykonawczych i nadzoru KNF.

Chmura, AI i tożsamość cyfrowa

Trzy tematy, które w 2026 r. najczęściej wracają na etapie architektury:

• Chmura obliczeniowa — sektor finansowy ma własne oczekiwania nadzorcze wobec outsourcingu chmurowego (szacowanie ryzyka, klasyfikacja informacji, lokalizacja danych, plan wyjścia). DORA je wzmocniła, nie zastąpiła.
• AI Act — systemy AI stosowane do oceny zdolności kredytowej czy scoringu klasyfikowane są jako wysokiego ryzyka, z obowiązkami w zakresie dokumentacji, jakości danych i nadzoru człowieka. Harmonogram stosowania tych przepisów przypada na 2026 r. — sprawdź aktualny status, bo terminy bywały przedmiotem korekt.
• eIDAS 2 i portfel tożsamości (EUDI Wallet) — europejski portfel tożsamości cyfrowej ma stać się akceptowanym sposobem potwierdzania tożsamości, także w sektorze finansowym. Dla fintechu to szansa na tańszy onboarding, ale i przyszły obowiązek integracji.

Onboarding i KYC — najtrudniejszy ekran w aplikacji fintechowej

Tu wygrywa się lub przegrywa produkt. Weryfikacja tożsamości jest jednocześnie wymogiem prawnym i największym miejscem porzuceń w lejku. Metody stosowane w Polsce:

• Selfie z badaniem żywotności (liveness) + OCR dokumentu. Standard rynkowy. Kluczowa jest odporność na deepfake i tzw. injection attacks — podstawienie spreparowanego strumienia wideo zamiast obrazu z kamery. To dziś realny wektor ataku, nie teoria.
• Odczyt e-dowodu przez NFC. Warstwa elektroniczna dowodu osobistego pozwala potwierdzić autentyczność dokumentu kryptograficznie. Najmocniejsza technicznie metoda weryfikacji dokumentu, wymaga jednak obsługi NFC i dobrego UX przykładania dokumentu.
• Weryfikacja przelewem (grosikowa) — prosta i tania, ale wolna i skuteczna tylko przy zgodności danych nadawcy.
• Zewnętrzne schematy tożsamości — mojeID, profil zaufany, BankID i w przyszłości EUDI Wallet. Wysoka konwersja u użytkowników, którzy już z nich korzystają.

Do tego dochodzi warstwa niewidoczna dla użytkownika: sprawdzenie list sankcyjnych i PEP, ustalenie beneficjenta rzeczywistego przy klientach firmowych, ocena ryzyka klienta i decyzja o zakresie wzmożonych środków bezpieczeństwa.

Praktyczna rada projektowa: rozdziel rejestrację od pełnej weryfikacji. Pozwól użytkownikowi wejść do aplikacji, zobaczyć wartość produktu i dopiero wtedy przejść KYC — z jasną informacją, czego nie może zrobić bez weryfikacji. Onboarding, który zaczyna się od żądania dowodu osobistego, traci znaczącą część użytkowników jeszcze przed pierwszym ekranem produktu.

Biometria i silne uwierzytelnianie — jak to działa naprawdę

Najczęstszy błąd w aplikacjach finansowych: potraktowanie biometrii jak hasła. Poprawny model jest inny — biometria jest kluczem do klucza.

Wygląda to tak: przy aktywacji urządzenia aplikacja generuje parę kluczy w sprzętowym magazynie (Android Keystore / iOS Secure Enclave), klucz prywatny nigdy go nie opuszcza, a dostęp do jego użycia jest chroniony biometrią systemową. Autoryzacja transakcji to podpisanie danych transakcji tym kluczem. System zwraca aplikacji tylko informację o powodzeniu — sam wzorzec biometryczny jest poza jej zasięgiem.

Co z tego wynika praktycznie:

• Powiąż klucz z urządzeniem (device binding). Konto działa na konkretnym, aktywowanym urządzeniu. Zmiana urządzenia to osobny, wzmocniony proces.
• Unieważniaj klucz po zmianie biometrii. Jeśli ktoś doda nowy odcisk palca lub twarz, klucz musi przestać działać (setInvalidatedByBiometricEnrollment na Androidzie, odpowiednie flagi w polityce dostępu na iOS). Bez tego biometria nie chroni przed osobą, która zna PIN do telefonu.
• Zaprojektuj fallback świadomie. PIN aplikacyjny jako alternatywa dla biometrii jest w porządku, ale nie może obniżać poziomu bezpieczeństwa najwrażliwszych operacji.
• Pokaż to, co podpisujesz. Ekran autoryzacji musi prezentować kwotę i odbiorcę, a podpisywane dane muszą być dokładnie tym, co użytkownik widzi. To istota dynamic linkingu i jednocześnie ochrona przed manipulacją.
• Nie ufaj samej biometrii przy zmianie parametrów bezpieczeństwa. Podniesienie limitów, dodanie zaufanego odbiorcy czy zmiana numeru telefonu powinny wymagać dodatkowego potwierdzenia i okresu karencji.

Płatności — BLIK, karty i zbliżeniowe

Warstwa płatnicza w fintechu zwykle łączy kilka kanałów naraz:

• BLIK — w Polsce praktycznie obowiązkowy dla płatności online i przelewów na telefon. Poza kodem 6-cyfrowym istotne są BLIK-owe płatności cykliczne, zwroty i przelewy na numer telefonu.
• Karty i portfele — Apple Pay i Google Pay to metody realizowane przez operatora płatności, nie osobni dostawcy; wymagają jednak własnej integracji i spełnienia wymogów platform.
• Przelewy i pay-by-link — zwykle przez agregatora (Przelewy24, PayU, Autopay) albo bezpośrednio przez API banku w modelu PSD2.
• Usługi PSD2 (AIS/PIS) — agregacja rachunków i inicjowanie płatności. Wymagają statusu regulowanego lub pośrednika, który go posiada, oraz certyfikatów kwalifikowanych.

Osobna sprawa to reguły sklepów. Za treści cyfrowe konsumowane w aplikacji Apple i Google wymagają swoich mechanizmów zakupowych, ale usługi finansowe i towary ze świata rzeczywistego rozliczasz własną bramką. Granica bywa nieoczywista przy produktach hybrydowych (np. abonament na funkcje premium w aplikacji finansowej), a jej błędna ocena kończy się odrzuceniem aktualizacji. Szczegółowo rozkładamy to w artykule o płatnościach w polskiej aplikacji mobilnej — BLIK, Przelewy24, Stripe i Apple Pay.

NFC, HCE i BLE — kiedy naprawdę są potrzebne

• NFC do płatności zbliżeniowych wymaga tokenizacji karty i emulacji karty po stronie hosta (HCE). Na Androidzie to dojrzały, otwarty mechanizm. Na iOS dostęp do HCE dla aplikacji płatniczych został udostępniony w Europejskim Obszarze Gospodarczym po zmianach wymuszonych przez DMA — na warunkach licencyjnych Apple, co warto zweryfikować przed obietnicą takiej funkcji w roadmapie.
• NFC do odczytu dokumentów (e-dowód, paszport) w KYC — nie wymaga żadnych zgód płatniczych i bywa najlepszym uzasadnieniem dla NFC w aplikacji fintechowej.
• Przyjmowanie płatności telefonem (SoftPOS / Tap to Pay) — telefon staje się terminalem. Wymaga certyfikacji i współpracy z akceptantem rozliczeń, ale otwiera całą kategorię produktów dla mikroprzedsiębiorców.
• BLE przydaje się przy integracji z terminalami płatniczymi, czytnikami i urządzeniami peryferyjnymi. To jeden z najbardziej niedoszacowywanych obszarów budżetu — testy wymagają fizycznego sprzętu, a zachowanie różni się między modelami telefonów.

Bezpieczeństwo aplikacji finansowej — warstwa po warstwie

Bezpieczeństwo aplikacji finansowej to nie jedna funkcja, tylko zestaw decyzji rozłożonych po całym stosie. Minimalny zakres, jaki stosujemy w projektach fintechowych:

Dane i klucze

• Klucze i tokeny wyłącznie w Keystore / Keychain, nigdy w preferencjach, plikach czy kodzie.
• Brak danych finansowych w logach, w zrzutach diagnostycznych i w kopiach zapasowych systemu.
• Automatyczne czyszczenie schowka po skopiowaniu numeru rachunku i zasłanianie ekranu na liście zadań.

Komunikacja

• TLS z certificate pinningiem i przemyślaną procedurą rotacji certyfikatów (pinning bez planu rotacji to gotowa awaria).
• Krótkie sesje, tokeny odświeżane, wylogowanie po bezczynności, unieważnianie sesji po stronie serwera.

Integralność środowiska

• Wykrywanie roota/jailbreaka, emulatorów, debuggerów i hookowania (Frida i podobne).
• Sprawdzanie integralności aplikacji przez usługi platformowe (Play Integrity, App Attest).
• Obfuskacja i zabezpieczenia runtime (RASP) — nie zatrzymają zdeterminowanego atakującego, ale podnoszą koszt ataku masowego.

Proces

• Weryfikacja względem OWASP MASVS i testy według MASTG jako wspólny język z audytorem.
• Pentest przed wejściem na produkcję i po każdej dużej zmianie w obszarze autoryzacji.
• Skanowanie zależności i SBOM — w regulowanym sektorze to element wymagań wobec dostawców.
• Osobny proces reagowania na incydenty z terminami zgodnymi z DORA.

Przeciwdziałanie nadużyciom (fraud)

• Odcisk urządzenia i wykrywanie nietypowych wzorców zachowania.
• Limity i okresy karencji dla nowego urządzenia oraz nowo dodanych odbiorców.
• Ochrona przed socjotechniką — dziś najczęstszym wektorem strat nie jest złamanie kryptografii, tylko przekonanie użytkownika, by sam zatwierdził transakcję. Pomagają: czytelne ekrany autoryzacji, ostrzeżenia kontekstowe i wykrywanie aktywnego udostępniania ekranu podczas transakcji.

Ile kosztuje aplikacja fintechowa

Projekt finansowy jest droższy od porównywalnej funkcjonalnie aplikacji nieregulowanej — nie z powodu liczby ekranów, tylko z powodu warstwy zgodności, testów i integracji. Orientacyjne widełki netto:

Największe pozycje, których nie widać w pierwszym szacunku: dostawca KYC (koszt licencji plus opłata za weryfikację), audyty i pentesty, środowiska testowe partnera płatniczego (dostęp do sandboxa bywa wąskim gardłem harmonogramu), obsługa incydentów i utrzymanie zgodności po starcie. Ogólną metodykę wyceny i rozkład budżetu opisaliśmy w artykule ile kosztuje aplikacja mobilna w 2026.

Jeśli słyszysz wycenę aplikacji bankowej na poziomie zwykłego MVP — najprawdopodobniej nie uwzględniono w niej compliance, testów bezpieczeństwa i utrzymania.

Checklista przed startem projektu

1. Ustal model licencyjny — własna licencja, MIP, agent czy BaaS. Reszta architektury z tego wynika.
2. Zmapuj obowiązki regulacyjne na konkretne wymagania funkcjonalne (SCA, AML, raportowanie, retencja).
3. Wybierz dostawcę KYC wcześnie — jego API i ograniczenia wpływają na cały lejek onboardingu.
4. Zaprojektuj model uwierzytelniania przed pierwszym ekranem: klucze w sprzęcie, device binding, fallback, dynamic linking.
5. Potwierdź dostępność kanałów płatniczych i wymagania sklepów dla Twojego modelu monetyzacji.
6. Zaplanuj bezpieczeństwo jako proces — MASVS, pentesty, reagowanie na incydenty, aktualizacje zależności.
7. Uzgodnij warunki umowy z wykonawcą pod kątem DORA: audyt, ciągłość działania, strategia wyjścia.
8. Zbuduj panel operacyjny od początku — obsługa klienta, blokady i reklamacje to część produktu, nie dodatek.

Podsumowanie

Aplikacja fintechowa różni się od zwykłej aplikacji nie liczbą funkcji, lecz tym, że każda z nich musi być obroniona przed nadzorcą, audytorem i atakującym jednocześnie. Model licencyjny wyznacza budżet, KYC decyduje o konwersji, silne uwierzytelnianie i biometria o zaufaniu, a warstwa bezpieczeństwa o tym, czy produkt przetrwa pierwszy poważny atak.

Dobra wiadomość: wszystkie te wymagania są przewidywalne. Zespół, który zna je przed startem, projektuje je jako architekturę — a nie dokleja jako poprawki po pierwszym audycie, gdy zmiany kosztują wielokrotnie więcej.

W Mobilesoft tworzymy aplikacje mobilne dla branż o wysokich wymaganiach bezpieczeństwa i zgodności, w tym dla sektora finansowego — od weryfikacji tożsamości i autoryzacji transakcji po integracje płatnicze i BLE. Jeśli planujesz taki projekt, pomożemy przejść przez wymagania techniczne i regulacyjne oraz realnie oszacować zakres. Skontaktuj się z nami, aby omówić szczegóły i otrzymać wycenę.