Wstęp
Ogólnie rzecz biorąc, udany produkt bankowości mobilnej oferuje więcej niż tylko atrakcyjny interfejs użytkownika (tj. interfejs użytkownika), który wyświetla aktualne saldo (salda) użytkowników. Jest to raczej produkt zbudowany na zaufaniu. Użytkownicy zazwyczaj polegają na aplikacji bankowości mobilnej, wykonując wiele funkcji, takich jak sprawdzanie przelewów bezpośrednich, przelewanie pieniędzy między kontami, zamrażanie/blokowanie kart debetowych i/lub kredytowych w przypadku podejrzenia oszustwa, potwierdzanie dokonania płatności, kontakt z zespołem wsparcia banku oraz zarządzanie poufnymi danymi bankowymi i/lub osobistymi. Każdy ekran, każda czynność wykonywana za kulisami i każda decyzja podejmowana w celu udostępnienia zaktualizowanej wersji produktu bankowości mobilnej mają zatem znacznie większe znaczenie niż w przypadku praktycznie jakiegokolwiek innego produktu skierowanego do konsumentów.
Założyciele lub liderzy nowych produktów, którzy opracowują aplikację bankowości mobilnej, będą w pewnym stopniu podlegać tym zmianom (nawet jeśli nie zdają sobie z tego sprawy) podczas projektowania aplikacji. Muszą stworzyć aplikację bankową, która będzie prosta w obsłudze dla użytkowników końcowych; jednak zaplecze aplikacji musi być zaprojektowane precyzyjnie, bezpiecznie i musi przejść gruntowną ocenę zgodności z przepisami. Co więcej, projekt aplikacji bankowości mobilnej powinien nie tylko wyróżniać się nowoczesnym wyglądem, ale także minimalizować potencjalne ryzyko związane z bieżącą działalnością, sprzyjać przyszłemu rozwojowi i wspierać zasoby firmy w szybkim reagowaniu na pojawiające się problemy.
W Appricotsoft staramy się zachować tę równowagę: zachęcamy zespoły do szybkiego działania, gdy jest to konieczne, ale nie będziemy też stwarzać ryzyka „widmowego”, aby zaprezentować Państwu funkcjonalne demo. Ta filozofia znajduje odzwierciedlenie w naszym podejściu do tworzenia oprogramowania. Tworzymy wysokiej jakości produkty, z których jesteśmy dumni i dążymy do tego, aby być przykładem tego, czego ludzie powinni oczekiwać od dobrego oprogramowania. Nasz Unison Framework opiera się na tej samej zasadzie: sztuczna inteligencja może ułatwiać realizację, ale to ludzie są odpowiedzialni za swoje wyniki, decyzje i jakość.
W tym artykule opisano podstawowe moduły, których potrzebuje większość aplikacji bankowych, minimalne wymagania bezpieczeństwa, jakich należy się spodziewać przed uruchomieniem, a także ślady audytu, które mają znaczenie, jeśli chcesz działać z pewnością, a nie tylko nadzieją.
Ważna rola planowania modułów w bankowości
W przypadku większości produktów cyfrowych zespoły zazwyczaj zaczynają od minimalnej funkcjonalności (MVP) i z czasem ją rozwijają. W obszarze bankowości mobilnej może to powodować gwałtowny wzrost kosztów. Powód jest prosty: moduły nie są niezależnymi funkcjami. Na przykład konta wpływają na transakcje, transakcje na powiadomienia, karty na wsparcie, przelewy na kontrolę oszustw, a ustawienia na uwierzytelnianie, zaufanie na urządzeniu lub ścieżki wsparcia.
Gdy decyzje dotyczące modułów podejmowane są zbyt ogólnie, zespoły mogą w efekcie mieć do czynienia z:
- niespójne uprawnienia użytkownika
- niekompletna historia zdarzeń
- słabe narzędzia pomocnicze
- niejasny stan transakcji
- nieudolne radzenie sobie z nieudanymi płatnościami lub ponownymi próbami
- oraz mechanizmy bezpieczeństwa, które są ‘dołączane’ po podjęciu decyzji dotyczących architektury.
Z tego powodu dobry proces opracowywania aplikacji mobilnych w branży technologii finansowych musi zaczynać się od jasnego zdefiniowania modułów produktu i ich funkcji. Nie chodzi tu tylko o perspektywę interfejsu użytkownika, ale także o perspektywę procesów w tle, rejestrowania procesów i przeglądania wymagań dla zespołów operacyjnych.
Jeśli planujesz inicjatywy fintech na większą skalę, zapoznaj się z powiązanym wpisem Plan rozwoju aplikacji Fintech: skalowalność MVP zapewni Ci przegląd tego, w jaki sposób kolejność dostaw wpływa na budowanie zaufania i zgodność, a także na rozwiązania na większą skalę.
Znaczenie planowania modułów w bankowości
W przypadku wielu rodzajów produktów cyfrowych zespoły produktowe mogą wprowadzić na rynek uproszczoną wersję MVP, a następnie z czasem dodawać kolejne zadania. Jednak w obszarze bankowości mobilnej metoda ta może bardzo szybko okazać się kosztowna. Wynika to z faktu, że moduły mogą nie istnieć jako odrębne, niezależne elementy podczas tworzenia systemów bankowości mobilnej (np. konta wpływają na transakcje; transakcje wpływają na powiadomienia; karty wpływają na obsługę klienta/wsparcie; przelewy wpływają na kontrolę oszustw; a ustawienia wpływają na uwierzytelnianie, zaufanie do urządzeń i ścieżki odzyskiwania klienta).
Gdy zespoły zajmujące się rozwojem produktu podejmują luźne decyzje dotyczące modułu, rezultat jest często następujący:
- Niespójne uprawnienia użytkownika
- Brak historii zdarzeń
- Słabe narzędzia wsparcia
- Niejasne stany transakcji
- Słaba obsługa błędów/ponowne próby w przypadku nieudanych płatności
- Kontrola bezpieczeństwa jest dodawana domyślnie, a następnie podejmowane są decyzje po zakończeniu prac nad architekturą.
Dlatego tworząc niestandardową aplikację mobilną w kategorii finansowej, niezwykle ważne jest, aby rozpocząć proces rozwoju od jasnej definicji modułu produktu i związanych z nim obowiązków. Definicja modułu produktu obejmuje nie tylko sposób, w jaki użytkownik postrzega produkt (tj. bezpośrednio), ale także to, co dzieje się za kulisami (np. rejestrowanie działań) oraz informacje, które dział operacyjny będzie musiał przejrzeć w późniejszym czasie (np. historia transakcji).
Jeśli chcesz szerzej spojrzeć na inicjatywy związane z Fintech, polecamy lekturę naszego artykułu: Plan rozwoju aplikacji Fintech: od MVP do skalowania, który pokazuje, w jaki sposób plan realizacji może wpłynąć na zdolność instytucji finansowej do budowania zaufania, dostarczania zgodnych z przepisami produktów lub usług i ostatecznie skalowania swoich organizacji.
Główne moduły aplikacji bankowości mobilnej
1. Moduł Kont
Moduł Kont (podstawa produktu i wszystkich pozostałych Modułów Bankowych lub Modułów Usługowych). Moduł kont zazwyczaj składa się z:
- przegląd rachunków bieżących i oszczędnościowych,
- saldo bieżące i dostępne,
- transakcje zakończone i/lub będące w toku,
- dane konta, tj. IBAN lub dane dotyczące routingu,
- wyciągi z kont,
- oraz obsługa rachunków wspólnych i/lub walutowych (czasami).
Mimo że moduł kont wydaje się prosty w konstrukcji, w rzeczywistości udziela on odpowiedzi na następujące podstawowe pytania:
- Czy saldo jest wyświetlane jako “bieżące”, czy też jest opóźnione?
- Czy saldo pokazuje oczekujące autoryzacje karty?
- Czy należności i obciążenia są rozliczone, oczekujące, anulowane, zrealizowane czy poddawane przeglądowi?
- Czy użytkownik może eksportować wyciągi bez ryzyka?
- Czy zespół wsparcia technicznego może odtworzyć informacje widziane przez klienta w określonym momencie (data i godzina)?
Moduł Konta ma również kluczowe znaczenie dla określenia sposobu przepływu danych o koncie do bankowości mobilnej. W niektórych produktach aplikacja mobilna stanowi warstwę odczytu (Read) w ramach Rdzenia Bankowości. W innych jest to warstwa kompletnych działań (Complete Action), która koordynuje transakcje z różnymi transakcjami w Księdze Głównej. Decyzja projektowa podjęta w tym miejscu ma istotne implikacje dla szybkości przetwarzania działań, momentu odzwierciedlenia danych w Księdze Transakcji, ilości danych wymaganych do celów audytu, sesji i uzgadniania danych.
Dla kadry kierowniczej banku kluczowe pytanie jest zupełnie inne niż: “Czy użytkownicy widzą swoje saldo?”. “Czy możesz potwierdzić, że cokolwiek zostało zrobione i kiedy, a także podać wyjaśnienie, dlaczego klient zobaczył to, co zobaczył?”.”
2. Moduł transakcji
Moduł transakcji to miejsce, w którym można zbudować lub stracić zaufanie. Zazwyczaj składa się z:
- historia transakcji
- możliwości wyszukiwania i filtrowania
- szczegóły transakcji
- informacje o sprzedawcy
- wskaźniki statusu obsługujące zadania oczekujące/zakończone
- kategoria
- punkt wejścia do sporu/wsparcia
Przykładem słabej implementacji byłoby traktowanie historii transakcji jak długiej listy. Przykładem silnej implementacji byłoby zbudowanie historii transakcji jako systemu objaśnień, dzięki czemu użytkownicy mogliby w pełni zrozumieć swoją historię, bez konieczności zgadywania lub dezorientowania się. Przeglądając historię transakcji, użytkownicy powinni być w stanie łatwo zrozumieć, czy ich karta została obciążona, czy tylko autoryzowana, czy przelew bankowy został zainicjowany, przetworzony, czy odrzucony, a także czy zwrot został w pełni przetworzony, czy jest nadal w trakcie realizacji.
Z operacyjnego punktu widzenia transakcje powinny być powiązane z niezmiennymi identyfikatorami i zmianami stanu. Umożliwi to badanie incydentów, wyjaśnienie nieudanych działań i wyeliminowanie chaosu w obsłudze klienta spowodowanego przez użytkowników zgłaszających “zniknięcie pieniędzy”, podczas gdy w rzeczywistości transakcja nadal oczekuje na realizację.
Jest to również obszar architektury, który wymaga przemyślenia kwestii idempotencji, ponawiania prób przez dostawców i obsługi zduplikowanych zdarzeń. Każda z tych decyzji jest podejmowana na poziomie architektury nieco niższym od modułu transakcji, ale bezpośrednio wpływa na sposób, w jaki użytkownicy odbierają strumień transakcji.
3. Moduł kart
Moduł kart jest często najczęściej wykorzystywaną częścią aplikacji, ponieważ umożliwia klientom bezpośredni dostęp do zarządzania własnymi kartami. Typowa funkcjonalność dostępna dla klienta w module Karty może obejmować:
- Przeglądanie kart fizycznych i/lub wirtualnych
- Zamrażanie i/lub odmrażanie kart
- Aktywacja nowych kart
- Ustawianie limitów wydatków
- Zarządzanie korzystaniem z kart w trybie online i międzynarodowym
- Ujawnianie numeru karty w sposób bezpieczny, jeśli jest to dozwolone
- W niektórych przypadkach generowanie jednorazowych numerów kart wirtualnych
Moduł ten musi być intuicyjny, szybki i bardzo dobrze zabezpieczony. Czynności związane z blokowaniem, odblokowywaniem lub ujawnianiem numerów kart muszą być chronione silnymi regułami uwierzytelniania opartymi zarówno na ryzyku, jak i stanie sesji. Słabo zabezpieczony moduł kart stwarza znaczne ryzyko oszustw. Źle zaprojektowany moduł kart wywołuje panikę u użytkowników, ponieważ często korzystają z niego w sytuacjach stresowych (np. w przypadku podejrzenia oszustwa, zgubienia karty).
Dodatkowa ogólna zasada: wszelkie działania, które istotnie zmieniają dostępność karty lub ujawniają dane konta posiadacza karty, powinny być objęte ochroną logiczną i fizyczną, a wszystkie działania związane z poufnymi działaniami powinny być rejestrowane z odpowiednim kontekstem, aby ułatwić późniejszy przegląd.
4. Moduł transferowy
Transfery są zazwyczaj uważane za najbardziej ryzykowny rodzaj interakcji w ramach produktu. Różne rodzaje przelewów obejmują:
- Przelewy pomiędzy posiadanymi kontami,
- Przelewy krajowe,
- Przelewy międzynarodowe,
- Transfery peer-to-peer,
- Przelewy zaplanowane,
- Płatności cykliczne i
- Zarządzanie beneficjentami.
W tym module kluczowe znaczenie ma potrzeba przejrzystego zarządzania stanem, jednoznacznych potwierdzeń, kontroli oszustw, zarządzania limitami i możliwości precyzyjnego odzyskiwania. Sam komunikat “Transfer Failed” nie wystarczyłby użytkownikom; system musi znać status żądania, np. czy żądanie nigdy nie zostało zainicjowane, oczekuje na potwierdzenie od dostawcy, zostało zrealizowane, ale z powodu błędu ludzkiego musi poczekać na dalszą weryfikację przez użytkownika itp.
Największym błędem w projektowaniu produktu w odniesieniu do modułu transferów jest próba przekonania, że transfery są wykonywane synchronicznie, podczas gdy w rzeczywistości ekosystem bazowy tak nie działa. Opóźnienia mogą wynikać z dowolnego systemu bankowego, uruchamiania API przez dostawcę, przeprowadzania weryfikacji KYC, kontroli pod kątem sankcji lub oczekiwania na wszystkie inne zewnętrzne zgody przed wykonaniem żądanych działań przez użytkownika. W tym miejscu aplikacja powinna być szczera i zgodna z prawdą. W świecie technologii finansowych przejrzystość może wydawać się przyczyną opóźnień, jednak w rzeczywistości buduje większe zaufanie niż stwarza iluzję pewności.
Aby zapoznać się z dalszą powiązaną opinią na temat tego, w jaki sposób doświadczenie użytkownika (UX) będzie budować lub osłabiać zaufanie konsumentów do usług finansowych za pośrednictwem wzorców UX, które pomagają budować zaufanie za pomocą wzorców potwierdzania, wskaźników postępu i większej przejrzystości komunikatów dotyczących bieżącego statusu, co zmniejszy zamieszanie podczas wykonywania transakcji płatniczych lub finalizowania transakcji weryfikacyjnych, zapoznaj się z naszym poprzednim wpisem zatytułowanym “Wzorce UX budujące zaufanie”.
5. Moduł pomocniczy
Niewiele osób rozumie, jak cenne jest wsparcie przy projektowaniu aplikacji mobilnej. Bankowość jest doskonałym przykładem, gdzie wsparcie jest integralną częścią produktu, a nie tylko dodatkiem. Funkcje pomocnicze zwykle uwzględniane w aplikacji bankowości mobilnej obejmują:
- Czat/wiadomości w aplikacji
- Bezpieczne tworzenie biletów
- Rozpoczęcie sporu
- Dostęp do FAQ i centrum pomocy
- Ścieżki eskalacji
- Łączenie zidentyfikowanych przez użytkowników problemów z powiązanymi danymi, takimi jak identyfikatory transakcji itp.
Projektując moduł wsparcia tak, aby zminimalizować tarcie, klient powinien otrzymać jak najwięcej wsparcia w najtrudniejszych momentach. Na przykład, gdy klient dzwoni, aby zakwestionować transakcję, zgłasza zablokowanie karty debetowej lub nieautoryzowaną transakcję, aplikacja powinna automatycznie zawierać dostępne materiały referencyjne, aby szybko rozpocząć proces rozwiązywania problemu. Pomoże to wyeliminować większość korespondencji z zespołem wsparcia i skrócić czas rozwiązania problemu.
Kolejnym ważnym czynnikiem przy tworzeniu aplikacji bankowości mobilnej jest zgodność z przepisami i zarządzanie. Projekt bezpiecznego procesu wsparcia powinien uwzględniać fakt, że klienci nie będą wysyłać poufnych informacji do/za pośrednictwem niezabezpieczonych kanałów (poczty e-mail) oraz kierować ich do korzystania ze strukturalnych interakcji, które zapewnią zapis tego, co się wydarzyło.
6. Moduł ustawień
Moduł ustawień może mieć bardziej strategiczne znaczenie niż się wydaje. Zwykle obejmuje następujące elementy:
- dane osobowe
- preferencje powiadomień
- zaufane urządzenia
- preferencje językowe i regionalne
- ustawienia zabezpieczeń
- zmień hasło/kod dostępu
- preferencje biometryczne
- dostęp do dokumentów
- zamknięcie lub modyfikacja konta w zależności od okoliczności.
W tym module zidentyfikowano wiele wektorów ryzyka przejęcia konta. Wszelkie zmiany dotyczące adresu e-mail, numeru telefonu, haseł, danych biometrycznych i/lub zaufanych relacji między urządzeniami powinny być zabezpieczone poprzez uwierzytelnianie step-up (zweryfikowany użytkownik przed udzieleniem dostępu) i posiadać solidne rejestrowanie audytu (aby zapewnić, że wprowadzone zmiany zostały wprowadzone poprawnie). Ponadto aplikacja powinna w tym module oddzielić preferencje niskiego i wysokiego ryzyka dotyczące tożsamości/odzyskiwania. Dzięki temu uzyskano bardziej przejrzysty interfejs użytkownika (UX) oraz zastosowano istotne mechanizmy kontroli bezpieczeństwa.
7. Moduł powiadomień
Moduły powiadomień nie służą wyłącznie do interakcji, ale także tworzą warstwę bezpieczeństwa i zaufania w instytucjach bankowych (np. otrzymywanie alertów o wykonanej transakcji, użyciu karty lub zalogowaniu się z nowego urządzenia, powiadomień o statusie przelewu, powiadomień o statusie zgłoszenia pomocy technicznej i powiadomień o konieczności wykonania działania).
Dobre powiadomienia są terminowe, konkretne i zawierają wystarczającą ilość informacji, aby podjąć działania w przypadku oszustwa lub nieudanej transakcji. Słabe powiadomienia działają odwrotnie: tworzą niepotrzebnie zaszumione środowisko, udostępniają poufne dane widoczne na ekranach blokady urządzeń mobilnych i nie dostarczają jasnych instrukcji (czyli są niejasne).
Moduł powinien również zapewniać kanały dostarczania w oparciu o wymaganą szybkość wysyłania powiadomień. Na przykład, powiadomienia push najlepiej sprawdzają się do bardzo szybkiego wysyłania powiadomień. Natomiast wiadomości w aplikacji pomagają w długoterminowym śledzeniu.
Minimalny poziom bezpieczeństwa dla rozwoju aplikacji bankowości mobilnej
Aplikacja bankowa nie wymaga wszystkich zaawansowanych funkcji sterujących od pierwszego dnia, ale wymaga solidnego punktu odniesienia. Standardy branżowe, takie jak OWASP MASVS istnieją, aby pomagać zespołom w określaniu wymagań dotyczących bezpieczeństwa urządzeń mobilnych, a wytyczne NIST dotyczące tożsamości cyfrowej są również przydatne przy podejmowaniu decyzji dotyczących uwierzytelniania i zapewniania jakości.
Poniżej przedstawiamy praktyczne założenia bazowe, które zalecamy w przypadku aplikacji mobilnej bankowości gotowej do produkcji.
Silne uwierzytelnianie i kontrola sesji
Aplikacja powinna co najmniej obsługiwać:
- Uwierzytelnianie wieloskładnikowe jest wymagane ze względu na produkt i kontekst regulacyjny.
- koncepcje wiązania urządzeń lub zaufania do urządzeń, w stosownych przypadkach,
- bezpieczne zarządzanie sesjami,
- krótkotrwałe tokeny z bezpiecznymi wzorcami odświeżania,
- ponowne uwierzytelnianie w przypadku działań wrażliwych,
- i chronione przepływy odzysku.
Działania wrażliwe nie powinny opierać się na zasadzie “użytkownik jest już zalogowany” jako jedynej kontroli. Ujawnienie danych karty, dodanie beneficjenta, zmiana danych odzyskiwania, wyłączenie biometrii lub zatwierdzenie przelewu o dużej wartości powinno skutkować ściślejszymi kontrolami.
Bezpieczne uwierzytelnianie i przetwarzanie poufnych danych.
Dane uwierzytelniające i tokeny nigdy nie powinny być przechowywane na urządzeniu bezmyślnie. Korzystaj z bezpiecznego magazynu danych zatwierdzonego przez platformę, minimalizuj ryzyko ujawnienia poufnych informacji i unikaj osadzania poufnych informacji w pakiecie aplikacji. Decyzje dotyczące certyfikatów lub zaufania do sieci powinny być podejmowane rozważnie, a nie pozostawiane domyślnym ustawieniom bez weryfikacji. OWASP MASVS wyraźnie określa podstawowe wymagania bezpieczeństwa urządzeń mobilnych dotyczące bezpiecznego przechowywania danych, uwierzytelniania, sieci i ochrony kodu.
Szyfrowanie w tranzycie i w stanie spoczynku
To minimalna oczekiwana wartość bazowa, ale w praktyce zespoły wciąż popełniają błędy. Dane wrażliwe powinny być szyfrowane w trakcie przesyłania przy użyciu nowoczesnych konfiguracji TLS, a dane po stronie serwera powinny być szyfrowane w stanie spoczynku, zgodnie z wymaganiami infrastruktury i zgodności. Co równie ważne, należy przede wszystkim zminimalizować ilość danych przechowywanych na urządzeniu.
Autoryzacja wykraczająca poza stan logowania
Każda poufna czynność musi sprawdzać uprawnienia użytkownika, a nie tylko jego uwierzytelnienie. Jest to szczególnie istotne w przypadku bankowości firmowej, dostępu delegowanego, kont wspólnych, ról administracyjnych i działań wspomaganych przez dział wsparcia.
Kontrole chroniące przed oszustwami
Nie każdy produkt zostanie wprowadzony na rynek z pełnym modułem zabezpieczającym przed oszustwami, ale podstawowe kontrole powinny obejmować:
- kontrole prędkości,
- sygnały nietypowego urządzenia lub nietypowej sesji,
- logika limitu transferu,
- Monitorowanie powtarzających się nieudanych prób
- i alerty dotyczące podejrzanych zdarzeń.
Zabezpieczenia przed oszustwami powinny być widoczne w produkcie tylko wtedy, gdy są przydatne. Wewnętrznie jednak muszą być one wyraźne i możliwe do sprawdzenia.
Bezpieczne zwolnienie i dyscyplina operacyjna
Bezpieczeństwo to nie tylko lista funkcji na poziomie aplikacji. Zależy ono również od dyscypliny wydawniczej. Zgodnie z Unison Framework, jakość jest oczekiwana w codziennym dostarczaniu poprzez przegląd kodu, aktualizację testów w uzasadnionych przypadkach, zatwierdzenie odpowiedniego zakresu przez QA, jasną gotowość demonstracyjną oraz listy kontrolne wydań, a nie “naprawimy to po premierze”. Taki model operacyjny ma znaczenie w bankowości, ponieważ pośpieszne wydania szybko prowadzą do zadłużenia.
Jeśli chcesz uzyskać uzupełniającą perspektywę bezpieczeństwa, nasz post Bezpieczeństwo w projektowaniu: prawidłowe tworzenie aplikacji Fintech rozszerza koncepcję bezpiecznego cyklu życia oprogramowania (SDLC) na produkty fintech.
Ślady audytu wymagane od pierwszego dnia
Aplikacja bankowa, która ma ograniczoną lub żadną możliwość audytu, jest bardzo podatna na ataki.
Ta lista kontrolna przedstawia wymagania dotyczące ścieżki audytu, które powinni wdrożyć założyciele wyższego szczebla i ich zespoły.
Wydarzenia uwierzytelniania i dostępu użytkownika
Rejestrowanie zdarzeń uwierzytelniania i dostępu powinno obejmować:
- Pomyślne i nieudane logowania.
- Wyzwania związane z uwierzytelnianiem wieloskładnikowym i ich wyniki.
- Rejestracja nowego urządzenia i usuwanie zarejestrowanego urządzenia.
- Utworzono lub zmieniono hasło i/lub kody dostępu.
- Funkcje biometryczne są włączane lub wyłączane.
- Sesja wygasła, została anulowana lub odwołana.
- Zablokowanie konta z powodu następujących po sobie nieudanych prób logowania.
Wydarzenia związane ze zmianą środowisk wysokiego ryzyka
Rejestrowanie zdarzeń związanych ze zmianą ustawień wysokiego ryzyka powinno obejmować:
- Zmieniono adres e-mail i/lub numer telefonu.
- Dodano i/lub edytowano beneficjenta.
- Zmieniono limit transferu.
- Kod powiadomienia został zmieniony.
- Dodano, edytowano lub usunięto zaufane urządzenie.
- Zmieniono ustawienia możliwe do przywrócenia przez użytkownika.
- Zmieniono zgodę użytkownika w odpowiednich obszarach produktu.
Wydarzenia związane z ruchem pieniądza
Rejestrowanie zdarzeń przepływu środków pieniężnych powinno obejmować:
- Przelew utworzony (w dobrym stanie) i/lub nieprawidłowy.
- Wystąpił błąd walidacji (powód).
- Transfery zostały zatwierdzone (krok #).
- Stwierdzono oszustwo / uruchomiono regułę (powód).
- Złożono przelew do dostawcy.
- Odpowiedź dostawcy na żądanie transferu.
- Stany przejściowe.
- Prośby o anulowanie transferów.
- Cofnięcia transferów.
- Ostateczne rozstrzygnięcie potwierdzone lub odrzucone.
Wydarzenia związane z kontrolą kart
Rejestrowanie zdarzeń związanych z kontrolą kart powinno obejmować:
- Karta jest zamrożona lub odmrożona.
- Włączanie/wyłączanie kontroli kart (Internet, Międzynarodowe).
- Przepływ pracy oparty na pinach (jeśli ma zastosowanie).
- Odblokowanie karty (prośba o pokazanie szczegółów karty).
- Utworzono kartę wirtualną.
- Działanie w przypadku podejrzenia oszustwa na karcie użytkownika.
Wydarzenia związane z obsługą klienta i administracją
Rejestrowanie zdarzeń związanych z obsługą klienta i administracją powinno obejmować:
- Tworzenie spraw.
- Reakcje agentów na przypadki.
- Ręczna korekta konta.
- Wewnętrzna eskalacja spraw.
- Administrowanie funkcjami związanymi z obsługą klienta, dostępem lub transakcjami.
- Przeglądanie dokumentu w oparciu o proces badawczy (rozszerzone dane dotyczące obsługi klienta).
Wydarzenia systemowe i integracyjne
Rejestrowanie zdarzeń systemu i integracji powinno obejmować:
- Niepowodzenia w żądaniach zewnętrznego API (bramy) do systemu.
- Wygenerowano ponowne próby wykonania funkcji w systemie.
- Otrzymano żądania webhooków (dotyczące integracji z zewnętrznymi dostawcami).
- Podwójne przetwarzanie zdarzeń przez system.
- Podczas przetwarzania zdarzeń wystąpiło przekroczenie limitu czasu przetwarzania.
- Awarie w lokalizacjach położonych niżej, gdzie zdarzenia zostały zakończone lub potwierdzone.
Celem rejestrowania nie jest zebranie wszystkiego, co możliwe. Chodzi o zebranie odpowiednich dowodów w ustrukturyzowany sposób. Ślady audytu powinny być przeszukiwalne, opatrzone znacznikami czasu, odporne na manipulację, przechowywane zgodnie z polityką i o określonym zakresie, aby śledczy mogli odtworzyć historię bez zgadywania.
Często stosujemy się do jednej praktycznej zasady: jeśli działanie może mieć wpływ na pieniądze, dostęp, tożsamość lub zaufanie klienta, prawdopodobnie zasługuje na wyraźne zdarzenie audytowe.
Problemy, z którymi borykają się zespoły korzystające z produktów bankowych
Nawet doświadczone zespoły mogą wpaść w kłopoty podczas tworzenia produktów bankowych. Większość awarii nie wynika z katastrofalnych naruszeń bezpieczeństwa, lecz z niezamierzonych błędów projektowych, które ostatecznie doprowadzą do dużych wydatków w przyszłości.
Przykłady obejmują:
- Tworzenie modułów w postaci samodzielnych ekranów zamiast korzystania z nich jako części połączonego systemu operacyjnego, w którym wszystkie moduły komunikują się ze sobą.
- Traktowanie statusu transakcji jako części interfejsu użytkownika (UI), a nie części modelu transakcyjnego.
- Pominięcie uwierzytelniania “Step-up” w przypadku operacji wrażliwych.
- Niedocenianie potrzeby wsparcia i narzędzi administracyjnych.
- Rejestrowano zbyt mało danych, aby umożliwić zbadanie incydentów.
- Rejestrowanie zbyt dużej ilości danych bez żadnej organizacji może sprawić, że przeglądanie rejestrów stanie się trudniejsze, a nie łatwiejsze.
Oprócz wyżej wymienionych problemów, kolejnym częstym problemem jest projektowanie z myślą o dzisiejszych, szczęśliwych czasach. Co się dzieje, gdy transakcja w piaskownicy działa? Co się dzieje, gdy przełącznik blokowania karty w wersji demonstracyjnej działa? Gdy dostawca traci czas oczekiwania, klient ponownie instaluje aplikację, zmienia się numer telefonu komórkowego klienta lub obsługa klienta musi wyjaśnić sprawę reklamacji transakcji po 3 tygodniach? W takich sytuacjach dojrzałe produkty bankowe wyróżniają się na tle obiecujących prototypów.
Jak podchodzimy do tego w Appricotsoft
Oto jak tworzymy aplikacje bankowości mobilnej:
Firma Appricotsoft uważa, że stworzenie udanej aplikacji mobilnej do bankowości to coś więcej niż tylko stworzenie produktu MVP poprzez wyposażenie go w maksymalną możliwą liczbę funkcji. To również identyfikacja właściwych modułów, jasne zdefiniowanie obowiązków i wspieranie prostoty produktu poprzez dyscyplinę operacyjną.
Dlatego kierujemy się następującymi zasadami:
- Zapewnij widoczną dostawę za pośrednictwem cotygodniowych demonstracji
- Ustal jasne elementy zaległości i kryteria akceptacji
- Twórz jawne dzienniki decyzji i śledź ryzyko
- Wprowadź kontrolę jakości do naszych standardowych metod dostaw
- Prowadź otwarte dyskusje na temat kompromisów między zakresem, budżetem i harmonogramem
W związku z tym nasze podstawowe zasady są zbieżne z zasadami naszej działalności: jesteśmy autentyczni (uczciwi), bierzemy odpowiedzialność za nasze działania (rezultaty), jesteśmy ciekawi tego, kim jesteśmy (ciekawość) i dążymy do wykonywania wysokiej jakości pracy (naprawdę dobrej pracy, a nie tylko ukończonej), aby nasi klienci mieli dostęp do dostawcy, a nie tylko do dostawcy, który może zapewnić firmę zajmującą się tworzeniem aplikacji na iOS, firmę zajmującą się tworzeniem aplikacji na Androida lub firmę zajmującą się tworzeniem aplikacji wieloplatformowych, z których każda jest w stanie dostarczyć ekrany.
Poważnie traktujemy partnerstwo i rozumiemy, że trzy kluczowe aspekty tworzenia skutecznych aplikacji bankowości mobilnej muszą ze sobą współgrać: zaufanie, przejrzystość, audytowalność i dyscyplina w osiąganiu rezultatów. Poniższe słowa kluczowe są istotne w tym obszarze: firma zajmująca się tworzeniem aplikacji mobilnych, usługi tworzenia aplikacji mobilnych, tworzenie niestandardowych aplikacji mobilnych, tworzenie aplikacji bankowości mobilnej oraz szacowanie kosztów tworzenia aplikacji.
Ostatnie przemyślenia
Posiadanie aplikacji bankowej złożonej z wielu modułów nie zawsze oznacza, że będzie ona dobrze działać. Dobrą aplikację bankową definiuje interakcja między modułami w sposób bezpieczny, zrozumiały i możliwy do zweryfikowania.
Pomyśl o modułach, których oczekujesz od aplikacji bankowej, takich jak: Konta, Historia transakcji, Karty, Przelewy, Wsparcie, Ustawienia i Powiadomienia. Oprócz wyżej wymienionych modułów, każdy moduł musi spełniać lub przewyższać solidne standardy bezpieczeństwa, które obejmują: silne wymagania uwierzytelniania w celu uzyskania dostępu do aplikacji, bezpieczne przechowywanie danych, starannie zarządzaną autoryzację transakcji lub innych działań wrażliwych pod względem bezpieczeństwa, szyfrowany przepływ danych między wszystkimi stronami, odpowiednie mechanizmy kontroli oszustw oraz ścisłą dyscyplinę dotyczącą terminu i sposobu udostępniania oprogramowania do produkcji. Na koniec musisz gromadzić i utrzymywać odpowiednie ślady audytu działań podejmowanych przez Twoją aplikację, aby Twoja organizacja mogła udzielać merytorycznych odpowiedzi użytkownikom, organom regulacyjnym, partnerom lub innym interesariuszom, którzy będą potrzebować wyjaśnień.
W ten sposób powstaje fundament godnego zaufania produktu fintech. Jasno określając architekturę bezpieczeństwa produktu i oczekiwania wobec każdego z wymaganych modułów, partner fintech stworzył jasną ścieżkę komunikacji rozwoju swojego produktu ze światem zewnętrznym.
Jeśli chcesz opracować lub wdrożyć produkt bankowy lub fintech i szukasz partnera, który zapewni Ci strategię, projekt, rozwój i doświadczenie we wdrażaniu niezbędne do osiągnięcia sukcesu w Twojej aplikacji bankowej lub fintech, Appricotsoft pomoże Ci ustalić punkt odniesienia dla każdego z odpowiednich modułów, niezbędne wymagania bezpieczeństwa dla każdego modułu oraz odpowiednią metodę dostarczania dla wszystkich Twoich aplikacji bankowych lub fintech. Appricotsoft tworzy oprogramowanie, z którego jest dumny i wierzy, że udany proces rozwoju oprogramowania powinien zapewniać jasne, odpowiedzialne i trwałe rozwiązanie.
