Wstęp
Sposób, w jaki rozwijasz swoją aplikację fintech, powinien być dostosowany do uruchomienia w regulowanym środowisku. Zgodność z przepisami nie powinna być dodawana jako nowy proces w połowie procesu dostarczania. Ponadto, nigdy nie należy czekać do momentu tuż przed uruchomieniem aplikacji, aby podjąć decyzje dotyczące zgodności, ponieważ podejmowanie decyzji dotyczących zgodności na późnym etapie dostarczania zazwyczaj wiąże się z największą ilością przeróbek, takich jak przeprojektowanie lub modyfikacja przepływów danych, przepisanie lub modyfikacja reguł dostępu, przebudowa/raportowanie, wymiana dostawców i wyjaśnianie luk, których nie da się już zlokalizować.
Dlatego doświadczone zespoły traktują zgodność z przepisami jako kwestię produktu i dostawy, jednocześnie bardzo ważną. To nie tylko obowiązek zadowolenia audytora, ale także chęć stworzenia produktu, który będzie skalowalny, będzie w stanie przejść proces due diligence, wytrzymać dochodzenie i zdobyć zaufanie partnerów, organów regulacyjnych i klientów.
Jeśli rozwijasz nowy produkt fintech, wchodzisz na rynek w nowym kraju lub nawiązujesz nową relację z dostawcą usług bankowych, płatności, usług KYC (Know Your Customer), przeciwdziałania praniu pieniędzy lub oszustwom, musisz zaplanować działania z wyprzedzeniem, aby uniknąć straty czasu i utraty wiarygodności. Właściwym sposobem na wczesne planowanie jest poznanie swoich danych, mechanizmów kontroli, dostawców i uwzględnienie identyfikowalności jako elementu codziennych działań.
To właśnie jest nasze podejście do tworzenia aplikacji fintech w Appricotsoft. Preferujemy przewidywalność dostaw, widoczne ryzyko, jasno określony proces decyzyjny oraz jakość wbudowaną w nasz proces pracy, a nie odkładaną na sam koniec. To samo podejście znajduje odzwierciedlenie w naszym Unison Framework: sztuczna inteligencja może przyspieszyć realizację, ale to ludzie nadal są odpowiedzialni za wyniki, ponoszą odpowiedzialność i podejmują decyzje.
Znaczenie wczesnego planowania zgodności dla regulowanych firm Fintech
W wielu projektach programistycznych zespoły często mają możliwość wydania minimalnego produktu gotowego do wdrożenia (MVP), otrzymania informacji zwrotnej na jego temat, a następnie wprowadzenia ulepszeń w zakresie zarządzania. Jednak w przypadku regulowanych technologii finansowych, sekwencja wprowadzania produktu na rynek przed zapewnieniem zarządzania może być ryzykowna. MVP o stosunkowo ograniczonym rozmiarze może obejmować połączenie z danymi tożsamości, danymi transakcji, danymi konta, instrukcjami płatności, komunikacją z klientami, dziennikami wsparcia, odciskami palców urządzeń i/lub wynikami weryfikacji zewnętrznej. Każdy z tych procesów ustanawia podstawę wymagań dotyczących zgodności związanych z dostępem, przechowywaniem, identyfikowalnością, reagowaniem na incydenty i dostawcami zewnętrznymi.
Nie oznacza to jednak, że wszyscy założyciele muszą mieć wdrożony kompleksowy program zgodności, zanim napiszą pierwszą linijkę kodu. Oznacza to jednak, że należy przeprowadzić odpowiednią ilość dochodzeń w celu ustalenia ram do zajmowania się kluczowymi pytaniami dotyczącymi:
- Jakie dane zbieramy, generujemy, przechowujemy i udostępniamy?
- Które systemy i/lub dostawcy korzystają z tych danych?
- Jakie zdarzenia muszą być rejestrowane i możliwe do śledzenia?
- Jakie środki kontroli bezpieczeństwa będą wymagane podczas pierwszego uruchomienia?
- Która z decyzji będzie później wymagała dokumentacji/dowodów?
Pytania te wpływają nie tylko na sposób projektowania technologii, ale także na to, jak technologia priorytetyzuje zaległości, jak dobiera dostawców, jak definiuje zakres kontroli jakości, jak definiuje gotowość do wydania, a nawet jak definiuje użyteczność. Wprowadzenie procesu myślowego skoncentrowanego na zgodności z przepisami złagodzi również tradycyjną frustrację w branży fintech, gdzie wielu interesariuszy zaangażowanych w rozwój produktu (produkt, technologia, zgodność z przepisami, operacje) odkrywa alternatywne wersje rzeczywistości w końcowych fazach projektu.
Jeśli Twój zespół już o tym myślał kompromisy architektoniczne, to właśnie tutaj planowanie staje się praktyczne. Nasz wcześniejszy artykuł na temat wyboru architektury dla fintech wyjaśnia, dlaczego realia biznesowe i regulacyjne powinny kształtować decyzje techniczne od samego początku, a nie odwrotnie.
Cztery najważniejsze obszary planowania
1. Mapowanie danych – poznaj swój cykl życia przed skalowaniem
Mapowanie danych to jeden z najczęściej pomijanych aspektów procesu rozwoju aplikacji fintech. Zespoły programistyczne regularnie definiują funkcje przed przemyśleniem wykorzystania danych, ale w przypadku produktów regulowanych zazwyczaj powinno być odwrotnie.
Mapa danych powinna odpowiadać na następujące pytania:
- Jakie dane trafiają do systemu?
- Skąd to się bierze?
- Dlaczego jest to potrzebne?
- Gdzie jest przechowywany?
- Kto ma do niego dostęp?
- Którzy dostawcy to otrzymują?
- Jak długo dane będą przechowywane?
- Co spowoduje usunięcie, eksport lub przegląd?
Oprócz definiowania pól profilu klienta, mapy danych powinny również reprezentować przepływy informacji, a nie tylko gromadzić je w formularzach. Na przykład, transakcja generuje metadane płatności, sygnały oszustwa, zdarzenia wsparcia, kontekst urządzenia, aktualizacje webhooków, rekordy uzgodnień i alerty wewnętrzne. Jeśli takie przepływy informacji nie zostaną odpowiednio wcześnie udokumentowane, mogą stać się niewidoczne i ograniczone do zgodności z przepisami, ponieważ będą ukrywane w logach, narzędziach wsparcia, narzędziach analitycznych, systemach LS i usługach firm trzecich.
Założyciele mogą utworzyć prostą “roboczą” tabelę z następującymi kolumnami, aby śledzić dane w trakcie całego procesu rozwoju:
- Element danych
- Cel działalności gospodarczej
- System rekordów
- Zaangażowany procesor/dostawca
- Role, które mają dostęp
- Długość retencji
- Jakiekolwiek wymagania dotyczące audytu/rejestrowania
- Informacje o jakimkolwiek ryzyku
Nie ma potrzeby tworzenia zbędnych specyfikacji w tych tabelach; one po prostu muszą istnieć i zawierać aktualne informacje.
Mapowanie danych usprawnia również podejmowanie decyzji produktowych. Czasami planowana funkcja staje się znacznie bardziej przejrzysta, gdy uświadomimy sobie, jakie dane regulacyjne wprowadza. Czasami pozornie nieszkodliwe zdarzenie analityczne powinno zostać usunięte lub zanonimizowane. Czasami integracja z dostawcami staje się nieuzasadniona, gdy zrozumiemy, jak bardzo zwiększa ona ryzyko ujawnienia danych.
2. Dzienniki audytu: jeśli to ma znaczenie, zostanie to wyjaśnione w przyszłości
Wiele zespołów zajmujących się technologiami finansowymi nie wie, jaki typ pliku dziennika jest potrzebny w przypadku produktów objętych regulacjami. Wiele zespołów błędnie założyło również, że samo rejestrowanie “wszystkiego” w nieskończoność wystarczy. Jednak ideą rejestrowania jest zachowanie dowodów w przypadkach, gdy podjęto istotne działanie lub decyzję.
Produkty podlegające regulacjom muszą przechowywać dowody następujących zdarzeń:
- Kto sprowokował zdarzenie
- Co zostało zmienione
- Kiedy dokonano zmiany?
- Skąd rozpoczęto akcję?
- Dlaczego zdarzenie miało miejsce, jeśli można to ustalić
Dokładniej rzecz ujmując, przykłady takich ”wydarzeń” będą obejmować:
- Zmiany w uprawnieniach użytkownika
- Decyzje wymagające ręcznego przeglądu
- Decyzje o zatwierdzeniu wypłat
- Wprowadzono aktualizacje statusów kont
- Zwroty dokonane w płatnościach
- Wprowadzono aktualizacje konfiguracji
- Zmiany w regułach wprowadzonych w narzędziach do wykrywania oszustw lub pomiaru ryzyka
- Dostęp przyznany użytkownikowi administracyjnemu, który zawiera poufne informacje
Zespoły często mylą pliki dziennika obserwowalności z plikami dziennika audytu, ponieważ oba mają podobne funkcje, ale zupełnie różne cele. Obserwowalność to ciągła analiza systemów po wdrożeniu w odniesieniu do ich wydajności i raportowania błędów, podczas gdy dzienniki audytu służą do rekonstrukcji podjętych działań i wykazania kontroli nad wcześniej udokumentowanymi informacjami.
Kluczową kwestią jest wczesne określenie, które zdarzenia na poziomie domeny powinny być niezmienne i posiadać odpowiednio ustrukturyzowane pliki dziennika. W przeciwnym razie większość zespołów programistycznych, które opóźniają decyzję o wyczyszczeniu plików dziennika zdarzeń, będzie musiała tworzyć niepełne pliki dziennika, co doprowadzi do niespójnego formatowania i luk między systemami.
Dobre organizacje fintech, rozważając sposób dostarczenia produktu użytkownikom końcowym, będą na bieżąco rejestrować następujące elementy: działania użytkowników, a także wszystkie działania związane z dokumentacją, w tym rejestry decyzji, notatki o wydaniach, rejestry zatwierdzeń i historię zmian.
3. Należyta staranność wobec dostawców: Twoja postawa wobec zgodności obejmuje Twoich partnerów
Branża FinTech opiera się na współpracy z wieloma dostawcami, takimi jak KYC, AML, ocena oszustw, wydawanie kart, połączenia z otwartą bankowością, wiadomości, analizy, hosting danych, przetwarzanie dokumentów itp. Relacje z dostawcami mogą przyspieszyć wprowadzanie produktów na rynek, ale narażają również założycieli na ryzyko wynikające z zależności od zewnętrznych dostawców.
Najczęstszym pytaniem, jakie zadają założyciele firm, jest to, czy ich dostawca jest “zgodny z przepisami”; lepiej zadać sobie pytanie: “Czy dostawca spełnia moje wymagania dotyczące produktu, profilu ryzyka, regionu geograficznego i dowodów?”
Należy wziąć pod uwagę następujące kwestie podczas należytej staranności dostawców:
- Jakiego rodzaju dane przetwarza Dostawca?
- Gdzie działa Sprzedawca i gdzie przechowywane są dane?
- Jakie środki kontroli bezpieczeństwa są tam stosowane?
- Jakie zobowiązania dotyczące czasu sprawności podejmują, a jakie zobowiązania dotyczące incydentów?
- Jakie procesy będą stosowane w przypadku awarii Dostawców?
- Czy obsługują audytowalność?
- Jak łatwo będzie wymienić Dostawcę, jeśli zajdzie taka potrzeba?
Przeprowadzając due diligence dostawcy, kluczowe jest sprawdzenie, czy dostawca ma odpowiednie kompetencje biznesowe i kontrolne w stosunku do firmy FinTech. Na przykład, szybka integracja niekoniecznie jest dobrą decyzją, jeśli dostawca tworzy nieprzejrzystość w zakresie przechowywania danych, osłabia zdolność firmy do reagowania na incydenty lub nie udostępnia historii zdarzeń w przypadku wystąpienia incydentu.
Zaleca się ustalenie oczekiwań dotyczących planowania awaryjnego na wczesnym etapie procesu. Na przykład, jeśli mój dostawca KYC ulegnie pogorszeniu, jaka będzie procedura? Jeśli moja bramka płatności ma sporadyczne problemy, jakie jest rozwiązanie awaryjne/kolejka/ponowne próby/przełączenie awaryjne/pauza? Jeśli moje narzędzie do wykrywania oszustw generuje fałszywe alarmy, komu przyznam uprawnienia do ich obejścia i jak będą one rejestrowane?
Są to pytania dotyczące produktów i operacji, a nie tylko kwestii zaopatrzenia.
Nasze wytyczne dotyczące przetargów na technologie finansowe porusza podobny temat z punktu widzenia kupującego: silne zespoły potrafią wyjaśnić nie tylko swoje możliwości techniczne, ale także to, w jaki sposób wspierają identyfikowalność, dowody, integracje i ryzyko związane z dostawcami w rzeczywistej dostawie.
4. Kontrola bezpieczeństwa przed rozpoczęciem prac rozwojowych
Bezpieczeństwo w regulowanych firmach FinTech nie powinno być jedynie ogólną obietnicą, lecz powinno stanowić podstawę wydania.
Poziom bazowy jest zazwyczaj definiowany przez:
- Mechanizm tworzenia modelu uwierzytelniania/autoryzacji
- Wdrażanie zasady najmniejszych uprawnień
- Utworzenie oddzielnych środowisk produkcyjnych i programistycznych
- Wdrażanie procedur mających na celu zachowanie i zabezpieczenie tajemnic
- Korzystanie z szyfrowania w stanie spoczynku i podczas przesyłania
- Wdrażanie kontroli działań administracyjnych
- Spójność w procesie bezpiecznego kodowania i procesie przeglądu kodu bezpieczeństwa
- Posiadanie ustalonego procesu postępowania w przypadku luk w zabezpieczeniach
- Ustalanie minimalnych oczekiwań dotyczących procedur tworzenia kopii zapasowych/odzyskiwania
- Utworzenie metody ustalania właściciela reakcji na incydent.
Celem opracowywania i wdrażania mechanizmów bezpieczeństwa nie jest koniecznie zapewnienie bezpieczeństwa w całym przedsiębiorstwie w pierwszym tygodniu. Chodzi o jasne zdefiniowanie minimalnego poziomu zabezpieczeń niezbędnego do bezpiecznego tworzenia produktu.
Standard Weryfikacji Bezpieczeństwa Aplikacji (ASVS) projektu Open Web Application Security Project (OWASP) to dobry zestaw ustrukturyzowanych wymagań weryfikacji bezpieczeństwa aplikacji, które można wdrożyć w organizacji. Ramy Cyberbezpieczeństwa NIST (CSF) 2.0 (National Institute of Standards & Technology) to rekomendowane ramy do myślenia o ryzyku w kategoriach rezultatów, a nie pojedynczych, odizolowanych technicznych mechanizmów kontroli.
Nie ma powodu, dla którego miałbyś wprowadzać powyższe ramy do swojej listy zadań słowo w słowo. Mogą one jednak posłużyć jako dobry punkt wyjścia do przekształcenia zasady “Dbamy o bezpieczeństwo” w konkretne wymagania, a także listy kontrolne.
Podstawowy schemat przepływu procesu zgodności z projektem
Poniższe kroki przedstawiają efektywny i prosty przepływ pracy w zakresie opracowywania aplikacji fintech w branży regulowanej.
Krok 1: Określ kontekst regulacyjny i środowisko operacyjne aplikacji
- Definicja rynków docelowych dla produktu,
- Struktura lub projekt produktu
- Jak poruszają się pieniądze
- Rodzaje klientów i sposób, w jaki korzystają z aplikacji
- Role wewnętrzne
- Wszystkie wymagane integracje zewnętrzne (złącza lub API)
Wszystko to pomoże ustalić prawidłowy zakres, dzięki czemu będziesz mieć do dyspozycji odpowiednią ilość informacji i kontroli do przetworzenia.
Krok 2: Utwórz prosty i lekki przepływ/mapę danych
Przed rozpoczęciem jakiejkolwiek znaczącej, szczegółowej implementacji, zdefiniuj główne przepływy danych. Zidentyfikuj w dokumencie dane wrażliwe, systemy granic, punkty styku z dostawcami i użytkowników operacyjnych. Zadbaj o to, aby dokument był na tyle prosty, aby można go było łatwo utrzymać.
Krok 3: Zidentyfikuj kontrolę zdarzeń krytycznych
Zidentyfikuj wszystkie zdarzenia dotyczące użytkowników, administratorów, systemów i dostawców, które zostaną zarejestrowane lub sprawdzone po fakcie. Zamiast opierać się na założeniach, stwórz dla każdego z nich konkretne elementy rejestru zaległości.
Krok 4: Utwórz klasyfikację dostawców dla każdego ze swoich dostawców
W przypadku każdego kluczowego dostawcy konieczne będzie rejestrowanie celów, danych i powiązanych ryzyk w następujący sposób:
- Cel sprzedawcy i jego wpływ
- Dane, których będzie dotykał sprzedawca
- Poziom zależności
- Rodzaj ryzyka operacyjnego
- Założenia dotyczące planów awaryjnych
Utworzenie informacji o każdym dostawcy pomoże Ci zapobiec ryzyku związanemu z danym dostawcą, które mogłoby pozostać ukryte w Twojej niewidocznej architekturze.
Krok 5: Utwórz linię bazową kontroli wydania
Zanim Twój zespół przyspieszy pracę, musisz stworzyć bazę minimalnych zabezpieczeń i zgodności dla pierwszej wersji produkcyjnej. Minimalne wymagania powinny obejmować zarządzanie dostępem, rejestrowanie aktywności i przechwytywanie danych, obsługę poufnych informacji, proces zatwierdzania wersji oraz odpowiedzialność za incydenty.
Krok 6: Wprowadź możliwość śledzenia do swoich produktów końcowych
Użyj swoich artefaktów, aby utworzyć zapis swoich decyzji, obejmujący następujące kwestie:
- Zaległości obejmują kryteria akceptacji.
- Zapis każdej decyzji podjętej w związku z Twoim wnioskiem.
Krok 7: Przeprowadzaj walidację na bieżąco, nie tylko na końcu
Zgodność z projektem to nie jeden warsztat. To nawyk wdrażania. Ponowne sprawdzenie mapy danych przy każdej zmianie funkcji. Ponowne sprawdzenie założeń dostawcy przy rozszerzeniu zakresu. Ponowne sprawdzenie kontroli wydania przed każdym większym wydaniem.
Ten rodzaj rytmu szczególnie dobrze wpisuje się w cotygodniowe demonstracje i transparentne planowanie. Interesariusze, którzy regularnie widzą działające oprogramowanie, mogą również wcześniej wychwycić luki w zakresie ryzyka i zarządzania. To jeden z głównych powodów, dla których wierzymy, że przewidywalność dostaw zależy od przejrzystych decyzji, a nie tylko od szybkiej realizacji.
Błędy popełniane przez założycieli i kadrę kierowniczą wyższego szczebla
Najczęstszy błąd w planowaniu Zakłada, że zgodność to głównie dokumentacja. Dokumentacja ma znaczenie, ale nie jest sednem problemu. Prawdziwym problemem jest to, czy zachowanie systemu, przepływ pracy zespołu i konfiguracja dostawcy zapewniają dowody, kontrolę i przejrzystość.
Drugi błąd próbuje rozwiązać wszystko za pomocą jednej, wielkiej fazy zgodności. W rzeczywistości regulowany fintech korzysta bardziej z etapowego dojrzewania:
- najpierw jasny zakres,
- silne kontrole bazowe po drugie,
- głębsza formalizacja w miarę rozwoju produktu.
Trzecim błędem jest wybór dostawców wyłącznie na podstawie jakości wersji demonstracyjnej lub szybkości integracji. W przypadku produktów regulowanych przejrzystość operacyjna ma równie duże znaczenie, co funkcjonalność.
Czwarty błąd pomija audytowalność w backlogu produktu. Jeśli tworzysz tylko funkcje widoczne dla klienta i odkładasz na później kwestię śledzenia, Twój wewnętrzny zespół pracuje w ciemno.
Piąty błąd traktuje bezpieczeństwo jako kwestię czysto techniczną. W branży fintech bezpieczeństwo to również dyscyplina procesowa: kto co zatwierdza, jak śledzone są zmiany, jak eskalowane są incydenty i jak weryfikowany jest dostęp.
W jaki sposób Appricotsoft wspiera planowanie na sformalizowanym rynku
Podejście Appricotsoft do planowania rynku regulowanego jest proste. Zamiast polegać na taktycznym, teoretycznym narzucaniu się założycielom, naszym celem jest wspieranie zespołów w podejmowaniu trafnych decyzji na odpowiednio wczesnym etapie cyklu rozwoju, aby po wprowadzeniu na rynek mogły je wdrożyć bez opóźnień spowodowanych koniecznością zapewnienia zgodności z przepisami.
Aby osiągnąć ten cel:
- Przekładamy to, co należy zrobić, na konkretne elementy zaległości,
- Uznajemy, co można wyraźnie postanowić,
- Identyfikujemy/komunikujemy ryzyko,
- Wykorzystujemy sztuczną inteligencję, aby zwiększyć szybkość i spójność procesu, mając jednocześnie jasną tożsamość właściciela.
- Sprawdzamy jakość w trakcie rozwoju produktu, zamiast zakładać, że możemy ją “naprawić” po jego zakończeniu.
Działania te są zgodne z podejściem Appricotsoft do rozwoju oprogramowania. Cenimy uczciwość, odpowiedzialność i jakość ponad teatralność. Naszym celem jest tworzenie oprogramowania, które z dumą nazywamy naszym, a sam proces rozwoju oprogramowania jest czymś, na czym klienci mogą polegać.
Jeśli planujesz wprowadzenie na rynek regulowanego produktu fintech, pomocne mogą okazać się dwie powiązane lektury:
- Wybór architektury rozwoju aplikacji Fintech: monolit, mikrousługi czy architektura sterowana zdarzeniami?
- Rozwój aplikacji Fintech: wzorce UX budujące zaufanie
Oto zewnętrzne punkty odniesienia warte dodania do zakładek:
Wniosek
Czas poświęcony na planowanie zgodności z przepisami podczas faz opracowywania aplikacji najlepiej wykorzystać zanim produkt stanie się zbyt skomplikowany ze względu na liczbę dostawców lub presję wywieraną na zespół związaną z koniecznością uruchomienia aplikacji.
Nie musisz odpowiadać na każde pytanie audytowe pod koniec pierwszego dnia. Potrzebujesz jednak sformalizowanego początku, w którym zmapujesz dane, zidentyfikujesz, co należy zarejestrować, odpowiednio zweryfikujesz wszystkich dostawców, wprowadzisz jasne, podstawowe zasady bezpieczeństwa i wbudujesz identyfikowalność w produkt końcowy.
Oto, co w praktyce oznacza zgodność z zasadami projektowania. To nie biurokracja ani strach, ale lepsze planowanie produktów, które będą działać na rynku, gdzie produkt jest budowany na zaufaniu, kontroli i przejrzystości.
Jeśli tworzysz produkt na regulowanym rynku i szukasz partnera, który zapewni Ci myślenie oparte na produktach, zdyscyplinowany rozwój i praktyczne planowanie zgodności, Appricotsoft jest w stanie pomóc Ci zbudować odpowiednie podstawy od samego początku.
