Wstęp
Musisz zrozumieć, że zatrudnienie firmy fintechowej nie jest tym samym, co zatrudnienie typowego zewnętrznego dostawcy oprogramowania lub usług programistycznych. Zatrudniając firmę fintechową, nie kupujesz po prostu kodu; kupujesz zdolność dostawcy do pomocy w zarządzaniu ryzykiem.
W wielu przypadkach gotowe produkty fintech (takie jak aplikacje bankowości mobilnej, portfele cyfrowe, bramki płatnicze, integracja z otwartą bankowością itp.) mogą być bardzo trudne do zbudowania lub zintegrowania i zawierają krytyczne funkcjonalnie punkty styku dotyczące interakcji finansowych, weryfikacji tożsamości i zaufania. Dlatego wybór dostawcy, który nie dostarczy produktu na czas, jest kosztowny. Wybór niekompatybilnego dostawcy może również stwarzać problemy, takie jak konieczność ponownego wdrożenia/integracji, problemy ze zgodnością, zagrożenia bezpieczeństwa i potencjalnie nieoczekiwane negatywne doświadczenia dla inwestorów.
Dlatego skrócenie procesu RFP jest bardzo ważne, ALE TYLKO JEŚLI wykorzystasz RFP do ustalenia, jak faktycznie działa dostawca (czyli nie pytając “czy wykonujecie QA?”, ale “prześlij mi kopię swojego procesu zapewnienia jakości (listę kontrolną wydania), wskaźnik usuwania defektów (liczbę defektów zgłaszanych po otrzymaniu produktu przez klienta) oraz metodę stosowaną do identyfikowania i zapobiegania lukom w zabezpieczeniach przed wysyłką”).
W tym poście znajdziesz:
- Przeszukiwalny bank pytań (do kopiowania i wklejania) dla Twojego RFP
- Wymagane dowody, które należy przedstawić dostawcy, aby nie zostały Ci jedynie obietnice od dostawców
- System punktacji (z uwzględnieniem wag i oceny “obowiązkowo zaliczone”)
- Kilka sygnałów ostrzegawczych, na które założyciele firm woleliby zwrócić większą uwagę.
Będziemy przedstawiać sprawdzoną metodę przykładową, która pomoże założycielom firm przejść przez ten proces, udostępniając szablony, listy kontrolne i dokumentację w formie FAQ.
Przewodnik po korzystaniu z RFP (niech nie będzie to tylko sterta papierów)
Zanim cokolwiek wyślesz do dostawców, wykonaj następujące trzy kroki:
1) Zdefiniuj problem na jednej stronie:
Czym jest produkt? Kim są klienci docelowi? Co dla Ciebie oznacza “MVP” w kontekście funkcjonalności? Jakie są wymogi regulacyjne? Jakie są Twoje wymagania dotyczące integracji? Jaki jest Twój harmonogram? Co odniesie sukces w ciągu 90 dni?
Jeśli przejdziesz od razu do “budowania”, zamiast uzyskać jasność co do problemu, koszt ukończenia projektu stanie się zgadywanką. Jeśli potrzebujesz dodatkowego kontekstu, oto przegląd naszego podejścia do odkrywania technologii finansowych i oczekiwanych rezultatów.
2) Proś o dane, a nie o opinię (proś o przykłady):
W przypadku każdej kategorii (bezpieczeństwo, dostawa, zapewnienie jakości, wsparcie) poproś potencjalnych dostawców o dostarczenie próbek danych, tj. przykładów systemów, które będą wykorzystywać, sposobów zarządzania sukcesem i jego pomiaru, a także przykładów sposobów zapewnienia zgodności.
3) Zastosuj jednolitą punktację dla dostawców we wszystkich kategoriach
Ryzyko braku systemu punktacji polegałoby na tym, że bardziej cenilibyśmy dostawcę ze względu na jego osobowość lub sposób mówienia niż za posiadanie ugruntowanego, godnego zaufania zespołu. Później dodamy naszą standardową rubrykę punktacji.
Bank pytań RFP dla dostawców technologii finansowych
Zestaw pytań, które można wykorzystać w projektach dowolnego typu i rozmiaru, pod warunkiem zachowania bezpieczeństwa, realizacji i zgodności (Na przykład: (jeśli Twój projekt ma mniejszy zakres, możesz napotkać jedynie kilka problemów).
A. Przegląd dostawców i dopasowania
- Jaki procent Twojej działalności dotyczy obecnie Fintech/Płatności?
- Jakie rodzaje produktów Fintech opracowałeś w ciągu ostatnich 24 miesięcy (portfele, pożyczki, bankowość, płatności, RegTech)?
- Kim są Twoi typowi klienci (start-upy, scale-upy, przedsiębiorstwa)?
- W jaki sposób obsługiwane są zmiany wymagań projektu w trakcie jego realizacji?
- Kto decyduje o FO dla Twoich produktów i czy potrafisz szybko podejmować decyzje?
Załącznik: Podaj jednostronicowy profil firmy i listę wszystkich produktów Fintech będących własnością Twojej firmy
B. Skład zespołu i model operacyjny
- Kto konkretnie będzie wchodził w skład naszego zespołu (role, staż pracy oraz lokalizacja/strefa czasowa)?
- Ilu członków naszego zespołu będzie pracować na pełen etat, a ilu będzie współdzielonych (QA, DevOps, Security)?
- Kto będzie odpowiedzialny za codzienne wykonywanie obowiązków (czy nie osoba kontaktowa ds. sprzedaży)?
- Jak radzisz sobie z ryzykami związanymi z kluczowym personelem (zarządzanie zasobami zapasowymi, dokumentacja, wdrażanie)?
- Jakie jest Twoje podejście do wykorzystania sztucznej inteligencji w projektowaniu i wdrażaniu produktów i w jaki sposób potwierdzasz skuteczność tego podejścia?
Załącznik: Przedstaw proponowany schemat organizacyjny przedstawiający zespół i jego zadania, a także schemat RACI pokazujący, kto za co odpowiada.
C. Podobne projekty i referencje
- Przedstaw dwa lub trzy porównywalne projekty (oba w podobnym obszarze zainteresowania i o podobnym stopniu złożoności), które obejmują podobne wyniki, a także ich oczekiwane produkty końcowe.
- Jakie najczęstsze błędy popełniono w niedawnym projekcie fintech i czego się z nich nauczyłeś?
- Prosimy o podanie co najmniej dwóch osób, które mogą udzielić referencji (najlepiej, jeśli spełniają podobne wymagania dotyczące zgodności i integracji).
- Jeśli nie mogą Państwo udostępnić nam publicznie studiów przypadku, czy możliwe jest udostępnienie nam prywatnego studium przypadku na podstawie umowy o zachowaniu poufności?
Znaczenie W przypadku technologii finansowych wymaga to doświadczenia wykraczającego poza samo pojęcie aplikacji; obejmuje ono znajomość skomplikowanych procedur i potencjalnych problemów, w tym przypadków skrajnych, ścieżek audytu, procedur przyjmowania/odbioru klienta, obciążeń zwrotnych, logiki rozliczeń, prostych przepływów między kontami oraz zależności od dostawców.
D. Proces dostawy i wskaźniki (w tej sekcji odzwierciedlona zostanie rzeczywistość)
- Podaj zarys harmonogramu realizacji zadań (sprinty, dema i daty wydania).
- Jak napisać kompletne i dokładne kryteria akceptacji?
- Jaką dokumentację będziesz dostarczać co tydzień (status, ryzyko, decyzje i notatki demonstracyjne)?
- Jak monitorujesz przewidywalność dostaw (planowanych i dostarczonych)?
- Jakich wskaźników używasz do oceny jakości i wydajności (np. czasu realizacji, czasu cyklu, wskaźnika usterek i niepowodzeń zmian)?
Załącz próbkę(i): tygodniowy raport o stanie, przykładowa tablica sprintu i przykładowa lista kontrolna wydania.
Wysokiej jakości partner z branży technologii finansowych powinien jasno wykazywać postępy w realizacji projektu poprzez bieżącą komunikację, a także dbać o to, aby związane z nim ryzyka były widoczne i otwarte, zamiast opierać się na komentarzach w stylu “aktualnie nad tym pracujemy”.”
E. Kontrola bezpieczeństwa i bezpieczny cykl życia oprogramowania (SSDLC)
Poproś wszystkich dostawców o wyraźne referencje; stwierdzenia w rodzaju “stosujemy najlepsze praktyki” nie wystarczą.
- Czy prowadzicie modelowanie zagrożeń? Jeśli tak, to kiedy? Kto konkretnie uczestniczy w ćwiczeniach z modelowania zagrożeń?
- Jakie zasady bezpieczeństwa kodowania lub listy kontrolne stosujesz podczas tworzenia oprogramowania?
- Jakiego rodzaju automatyczne testy bezpieczeństwa wykonujesz podczas ciągłej integracji i ciągłego dostarczania (CI/CD), w tym (1) statyczne testy bezpieczeństwa aplikacji (SAST), (2) dynamiczne testy bezpieczeństwa aplikacji (DAST), (3) skanowanie podatności na zależności i (4) skanowanie podatności na sekrety?
- W jaki sposób zarządzasz swoimi sekretami, w tym ich rotacją, przechowywaniem, dostępem i dziennikami audytu?
- Jaki jest proces ujawniania luk w zabezpieczeniach i czego klienci powinni oczekiwać w odniesieniu do umów o poziomie usług (SLA) dotyczących wdrażania poprawek?
- Jaka jest polityka rejestrowania danych w kontekście gromadzenia danych osobowych (PII) zarówno w środowiskach programistycznych (dev), jak i przejściowych?
- Jakie jest Twoje podejście do szyfrowania (danych w spoczynku i danych w ruchu) i zarządzania kluczami?
- Jakich metod używasz do ograniczania dostępu (np. wdrażanie zasad najmniejszych uprawnień, uwierzytelnianie wieloskładnikowe (MFA), kontrola dostępu oparta na rolach (RBAC) itp.)?
Dołącz zdezynfekowany Lista kontrolna cyklu życia oprogramowania (SDLC) i przykład raportu z testów bezpieczeństwa.
Jeśli chcesz uzyskać wiarygodne, niezależne źródło informacji na temat walidacji bezpieczeństwa aplikacji, Standard weryfikacji bezpieczeństwa aplikacji (ASVS) projektu Open Web Application Security Project (OWASP) jest dobrą alternatywą.
Warto również, aby Twój dostawca znał akceptowane ramy tworzenia bezpiecznych rozwiązań. Narodowy Instytut Norm i Technologii (NIST) Bezpieczne ramy programistyczne (SSDF) jest doskonałym źródłem wiedzy na temat przekazywania dostawcom terminów związanych z zamówieniami publicznymi.
F. Zgodność i gotowość regulacyjna (dopasowanie produktu)
Wybierz tylko te, o których wiesz, że mają zastosowanie (nie pytaj o rzeczy, które wykraczają poza zakres).
- W jakich środowiskach zgodności działałeś? (PSD2, PCI DSS, SOC 2, ISO 27001, GDPR itp.)
- Czy opracowałeś wzorce rozwoju zgodne z PSD2, takie jak przepływy silnego uwierzytelniania klienta, w postaci rzeczywistych produktów?
- W jaki sposób wspierasz gotowość do audytu po zebraniu dowodów w postaci rejestrów zmian, rejestrów dostępu i zatwierdzeń?
- W jaki sposób projektujesz pod kątem możliwości śledzenia, szczególnie w odniesieniu do tego, kto, kiedy i dlaczego dokonał zmian?
- Jakie jest Państwa doświadczenie w integracji dostawców usług KYC i AML? Jak sobie radzą Państwo z awariami i przestojami dostawców?
- W jaki sposób radzicie sobie z wymaganiami dotyczącymi miejsca przechowywania danych i wymaganiami regionalnymi (UE/Wielka Brytania/USA)?
Przytwierdzać istniejący pakiet dowodów audytu (zdezynfekowany) oraz przykład “dziennika decyzji” lub “dziennika zmian”.
G. Architektura, integracje i przetwarzanie danych
- Jakie jest Twoje standardowe podejście do architektury aplikacji fintech (monolit modułowy czy zorientowany na usługi)? Dlaczego?
- W jaki sposób radzisz sobie z idempotentnością i uzgadnianiem płatności i/lub przepływów w księdze głównej?
- Jakie jest Twoje podejście do integracji:
- Integracja bramki płatniczej
- Integracja z bankowością otwartą
- Powiadomienia, webhooki, ponowne próby i obsługa błędów
- W jaki sposób wersjonować interfejsy API i ograniczać ryzyko zmian powodujących przerwanie działania systemu?
- Jak definiujesz obserwowalność (logi, metryki, ślady) i jak przeprowadzasz debugowanie incydentów?
Przytwierdzać istniejący diagram architektury (oczyszczony) + lista kontrolna integracji.
H. Zapewnienie jakości, strategia testowania i gotowość do wydania
- Kto odpowiada za zapewnienie jakości? Czy jest to oddzielone od zespołu programistów?
- Jak wygląda Twoja piramida testowania w praktyce (jednostkowe/integracyjne/e2e)?
- Jak radzicie sobie z testami regresyjnymi, szczególnie w przypadku płatności i wdrażania?
- Jak zdefiniować “Gotowe” dla funkcji?
- W jaki sposób zarządzacie danymi testowymi (KYC, depozyt bankowy i płatności)?
- Jak się zabezpieczyć przed ryzykiem, że “kod demonstracyjny” zagrozi środowisku produkcyjnemu?
Proszę dołączyć następujące załączniki: Plan testów, lista kontrolna regresji i raport o błędach.
I. SLA, wsparcie, reagowanie na incydenty
- Czy zapewniacie wsparcie produkcji i konserwację? Na jakim poziomie?
- Jakie są umowy SLA dotyczące stopnia ważności (tj. celów reakcji i rozwiązania)?
- W jaki sposób monitorujesz produkcję i wysyłasz alerty?
- Jaki jest Twój proces reagowania na incydenty (tj. triaż, komunikacja, analiza przyczyn źródłowych, działania naprawcze)?
- Jaki jest Twój proces wdrażania/wycofywania i zatwierdzania zmian?
- Jaki jest Twój model dyżurów (np. godziny, weekendy, eskalacje)?
Proszę dołączyć następujące załączniki: Analiza postkrytyczna incydentu (usunięto); Arkusz wsparcia SLA.
J. Umowy handlowe, struktury cenowe i informacje zastrzeżone (w tym własność intelektualna)
- Jakie modele cenowe oferujecie? (np. stały, oparty na czasie i materiałach (T&M), hybrydowy)? Który z nich sugerujecie dla technologii finansowych i dlaczego?
- W jaki sposób radzisz sobie z prośbami o zmianę zakresu projektu, kompromisami i ponowną oceną swojej pracy?
- Kto będzie właścicielem praw własnościowych związanych z powstałym produktem pracy?
- Jaki jest okres gwarancji na świadczone usługi?
- Proszę wyjaśnić warunki rozwiązania umowy oraz zobowiązania dotyczące przeniesienia materiałów, takich jak dokumentacja, repozytoria, dane uwierzytelniające i podręczniki.
Notatka: Przekazanie materiałów powinno stanowić część realizacji zadania i koncentrować się na doprowadzeniu go do końca, a nie tylko na spełnieniu obietnicy.
K. Przeprowadzenie projektu pilotażowego (opcjonalne, ale skuteczne)
Zamiast traktować całą propozycję jako hazard, rozważ przeprowadzenie płatnego pilotażu (tzn. projektu pilotażowego).
- Utwórz harmonogramy 2–4 tygodniowe dla każdego pilota, które będą obejmować:
- Jak często będziemy dostarczać
- Rodzaj jakości, która zostanie dostarczona
- Jak dobrze będziemy współpracować
- Jak bardzo jesteśmy zdyscyplinowani w kwestii bezpieczeństwa
- W związku z tym w ramach każdego pilota można zapewnić następujące wyniki: rytm dostaw, punkt odniesienia jakości, współpracę i zgodność z wymogami bezpieczeństwa, a także
Przykład jak szybko można odróżnić stwierdzenie “Brzmi dobrze” od stwierdzenia “Niezawodna wysyłka”.”
Kryteria oceny (z wagami) + bramki obowiązkowe
Każda kategoria będzie miała skalę 1-5, gdzie:
- 1 = Niskie do przeważnie obiecujące
- 3 = Dopuszczalne, z pewnymi dowodami
- 5 = Silnie zweryfikowane z wyraźnymi artefaktami
Bramy, które należy przejść:
Jeśli nie przejdziesz żadnej z tych obowiązkowych bramek, nie będziesz mógł kontynuować korzystania z tej listy kontrolnej:
- Nie można jasno opisać bezpiecznego cyklu życia oprogramowania (SDLC) przy użyciu rzeczywistych elementów sterujących
- Brak prawdziwych odniesień do FinTech lub dowodów na odpowiednie doświadczenie
- Nie dostarczono żadnych artefaktów dostawy (nawet po ich oczyszczeniu) do przeglądu
- Brak identyfikowalnej własności lub odpowiedzialności za wyniki
| Kategoria | Waga | Jak wygląda “5” |
|---|---|---|
| Dopasowanie domeny Fintech | 15% | Wiele porównywalnych kompilacji; rozumie rzeczywiste ograniczenia |
| Zespół i własność | 15% | Jasno określone rozliczenie lidera, stabilny zespół, silne wsparcie QA/DevOps |
| Dyscyplina dostaw | 15% | Tygodniowe demonstracje, przewidywalny rytm, przejrzyste wskaźniki |
| Kontrola bezpieczeństwa | 20% | Modelowanie zagrożeń + skanowanie CI + dyscyplina tajności + dowody |
| Gotowość do zgodności | 15% | Poprzednia praca w odpowiednich systemach; procesy przyjazne dla audytu |
| Zapewnienie jakości i jakość wydania | 10% | Silna strategia testowania + definicja ukończenia + mała liczba błędów |
| Wsparcie i umowy SLA | 10% | Przejrzysty model powagi, proces incydentów, monitorowanie, główne przyczyny |
Wartość = ∑ (waga *(wynik/5))
Aby utworzyć wynik końcowy, należy zsumować wagę wszystkich wyników ∑ × (ocena / 5); wynik będzie stanowił ocenę w skali do 100.
Wskazówka dotycząca punktacji:
Po indywidualnym ocenieniu swoich produktów poświęć 30 minut na “kalibrację ocen” z udziałem interesariuszy, aby pomóc ustalić, co oznaczają oceny 3 i 5 w przypadku Twoich produktów.
Typowe błędy w zapytaniach ofertowych dotyczących technologii finansowych, których należy unikać
Unikaj tych typowych błędów, przygotowując zapytanie ofertowe (RFP) dla swojego projektu fintech
- Wybór dostawców wyłącznie na podstawie slajdów programu PowerPoint
- Brak żądania konkretnych rezultatów: przykładowych metryk, raportów i list kontrolnych
- Przecenianie prędkości, gdy należy wziąć pod uwagę bezpieczeństwo i zapewnienie jakości
- Brak określenia, która strona jest odpowiedzialna za zgodność (dostawca może przestrzegać zasad, ale zasady zarządzania i odpowiedzialność prawna nadal leżą po Twojej stronie)
- Nieuwzględnienie zależności od dostawców podczas planowania prac (dostawców KYC, banków i podmiotów przetwarzających płatności); należy zastanowić się, w jaki sposób dostawca przygotowuje się na wypadek awarii.
Często zadawane pytania
- Czy muszę złożyć wniosek o ofertę (RFP), jeśli moja działalność jest dopiero na wczesnym etapie?
Nie potrzebujesz ogromnego, skomplikowanego, 30-stronicowego dokumentu. Jeśli jednak nie ma standardowego zestawu pytań ani aktywnego procesu punktacji, będziesz dokonywać wyboru partnera na podstawie odczuć.
- Co oznaczają “praktyki bezpieczeństwa” i “dowody bezpieczeństwa”?
Praktyki to to, co deklaruje dostawca, a dowody potwierdzające te deklaracje można znaleźć w następujących miejscach: kontrole ciągłej integracji (CI), sprawdzone zestawy reguł, przykładowe raporty incydentów, procesy reagowania na incydenty oraz ślady audytu i/lub dzienniki.
- Czy powinienem zastosować stałą cenę czy płacić za przepracowane godziny?
Ogólnie rzecz biorąc, najlepszym sposobem fakturowania produktu, który często ulega zmianom, jest hybrydowa metoda rozliczania według stałej ceny w fazie odkrywania oraz metoda rozliczania według czasu i materiałów na podstawie tygodniowych wyników i projektów, które są wyraźnie kontrolowane.
- Co mam myśleć, jeśli dostawca twierdzi, że może zrobić wszystko?
W relacjach biznesowych zaufanie jest bardzo ważne. Godny zaufania dostawca podzieli się z Tobą informacjami na temat tego, co zrobi, a czego nie, jakie założenia trzeba będzie przyjąć, aby móc świadczyć swoje usługi, oraz jakie ryzyko dostrzega w świadczeniu tych usług.
Podejście Appricotsoft do oczekiwań wobec RFP (oto, co Ci pokażemy)
W Appricotsoft stawiamy na jasne oczekiwania i uczciwość. Bez dramatów, bez tajemnic. Bez “Zaufaj nam”. Sposób, w jaki pracujemy i angażujemy klientów, odzwierciedla to podejście.
Zazwyczaj w naszym zapytaniu ofertowym uwzględniamy następujące elementy:
- Tygodniowe dema – Tygodniowe pokazy, które pomogą Ci zdobyć zaufanie. Zobaczysz USA w akcji, a nie tylko aktualizację statusu.
- Pojedynczy punkt prawdy dla artefaktów – Nasz backlog z kryteriami akceptacji, dziennikiem decyzji, dziennikiem ryzyka, statusem, notatkami demonstracyjnymi, relacjami
- Odpowiedzialne korzystanie ze sztucznej inteligencji – Sztuczna inteligencja może pomóc w tworzeniu projektów i zminimalizować powtarzalność. Jednak to ludzie odpowiadają za rezultaty; wymagane są przeglądy, a wszelkie zmiany zakresu/architektury będą rejestrowane.
- Bezpieczeństwo jako część projektu – projekt z wbudowanym zabezpieczeniem, nie dodawaj zabezpieczeń na siłę (szczególnie do rozwoju aplikacji Fintech).
Jeśli chcesz uzyskać więcej informacji na temat tego, co rozumiemy pod pojęciem “wartości do przejścia” w partner ds. rozwoju technologii finansowych, jest to dobry dodatek do tego tekstu.
Wniosek
Skuteczne zapytanie ofertowe dotyczące technologii finansowych musi spełniać złożone obietnice.
Dostawca po prostu odpowie na Twoje zapytanie, przedstawiając dowody korzystania z systemu w postaci przykładów i metryk. Skorzystaj z powyższej listy pytań, a także ustal serię zaliczeń i punktów.
Jeśli jesteś w trakcie porównywania dostawców w zakresie rozwoju aplikacji Fintech (płatności, bankowość, portfel, bankowość otwarta i/lub KYC/AML) i chcesz uzyskać drugą opinię na temat swojego RFP lub odpowiedzi dostawców, Proszę o kontakt, niezależnie od tego, czy ostatecznie zdecydujesz się na współpracę z nami, czy nie.
