Jak napisać RFP na system do weryfikacji tożsamości klientów [SZABLON]

Ktoś, kto pisze RFP na system KYC, ma już za sobą etap "czy w ogóle wdrażać". Ma budżet albo wniosek o budżet. Ma mandat wewnętrzny. Brakuje mu jednej rzeczy: dokumentu, który zamieni rozmowy z dostawcami w porównywalny, obronny przed zarządem i regulatorem proces zakupowy.

Ten artykuł pokazuje jak taki dokument napisać - z jakich sekcji powinien się składać, jak formułować wymagania żeby dostawcy nie mogli ich omijać deklaracjami, i jak porównywać oferty zanim wydasz złotówkę na wdrożenie.

Kluczowe wnioski:

• RFP na system KYC ma sens gdy porównujesz minimum 2-3 oferty i musisz formalnie uzasadnić wybór wewnętrznie lub przed regulatorem
• Dokument powinien zawierać osiem sekcji: kontekst organizacyjny, wymagania regulacyjne, funkcjonalne, techniczne, SLA, bezpieczeństwo, scoring i klauzulę PoC
• Wymagania twarde (dyskwalifikujące) i miękkie (punktowane) to fundamentalna różnica - ich mylenie to najczęstszy błąd formalny
• Scoring bez pilotażu na realnych danych jest hipotezą. PoC ją weryfikuje
• Dostawca odmawiający sandbox lub PoC przed umową roczną to sygnał ostrzegawczy
  
  

Co to jest RFP na system KYC i kiedy go pisać

RFP (Request for Proposal) w kontekście systemu weryfikacji tożsamości klientów to formalny dokument, który organizacja wysyła do wybranych dostawców, aby zebrać porównywalne oferty na podstawie jasno określonych wymagań technicznych, regulacyjnych i operacyjnych. Celem RFP jest zamiana nieformalnych rozmów handlowych w ustrukturyzowany proces zakupowy - z określonymi kryteriami, terminem i możliwością obiektywnego porównania ofert.

W kontekście eKYC to narzędzie szczególnie użyteczne, bo rynek weryfikacji tożsamości nie jest jednorodny. Dostawcy różnią się metodami identyfikacji, architekturą danych, certyfikatami i modelami SLA - a te różnice rzadko wychodzą na etapie demo. Wychodzą po wdrożeniu. RFP wymusza od każdego dostawcy odpowiedzi na te same pytania, co daje możliwość rzetelnego porównania.

Zanim zaczniesz pisać dokument, warto mieć już wypracowane kryteria, które chcesz sprawdzić - 7 kryteriów wyboru systemu do zdalnej weryfikacji tożsamości opisaliśmy tutaj. Ten artykuł jest kolejnym krokiem: jak przełożyć te kryteria na formalny dokument przetargowy.

Kiedy RFP ma sens, a kiedy wystarczy rozmowa handlowa

RFP nie jest konieczne w każdej sytuacji. Ma sens, gdy:

• porównujesz co najmniej 2-3 oferty i musisz uzasadnić wybór przed zarządem, komitetem zakupowym lub działem prawnym
• organizacja ma wewnętrzne regulacje zakupowe lub wymagania zamówień publicznych narzucające formalny proces przetargowy
• zakup przekracza próg, powyżej którego w firmie wymagana jest pisemna dokumentacja decyzji
• wybierasz system na umowę wieloletnią lub z istotną integracją techniczną, gdzie błędny wybór jest drogi do naprawienia

RFP jest zbędne gdy robisz proof of concept na małą skalę, kupujesz krótkoterminowo z opcją wyjścia, albo dostawca pochodzi z bezpośredniego polecenia przez zaufanego partnera i wymagania są proste.

Jakie organizacje powinny pisać RFP przy zakupie systemu KYC

Instytucje obowiązane w rozumieniu ustawy AML - banki, firmy leasingowe, ubezpieczyciele, instytucje płatnicze - zazwyczaj mają wewnętrzne wymogi zakupowe, które i tak wymuszają dokumentację procesu wyboru dostawcy. RFP jest w takim przypadku nie tylko dobrą praktyką, ale narzędziem ochrony: pokazuje, że wybór był przeprowadzony metodycznie, zgodnie z procedurą należytej staranności. Przy kontroli regulatora ten dokument mówi więcej niż wyjaśnienie "wybraliśmy najlepszą ofertę".

Z jakich sekcji składa się RFP na system KYC

Dobrze napisany RFP to nie lista życzeń. To dokument, który musi zawierać wystarczająco dużo kontekstu, żeby dostawca mógł przygotować trafną ofertę, i wystarczająco precyzyjnych wymagań, żeby oferty dało się ze sobą porównać. Poniżej osiem sekcji, które powinny znaleźć się w każdym RFP na system eKYC.

1. Kontekst organizacyjny i zakres procesu

Dostawca nie zna twojej organizacji. Ta sekcja daje mu minimum kontekstu do przygotowania sensownej oferty.

Co opisać: branża i regulacje (czy jesteś instytucją obowiązaną wg AML?), szacowany wolumen weryfikacji miesięcznie i rocznie, typ weryfikowanych osób (B2C, B2B, oboje), czy klienci mogą być zagraniczni, systemy wymagające integracji (CRM, LOS, backoffice), obecne rozwiązanie jeśli je masz i powód zmiany, planowany termin wdrożenia i model rozliczenia jakiego szukasz.

Konkretny przykład - zamiast pisać "duży wolumen weryfikacji", napisz: "szacujemy 800-1 200 weryfikacji miesięcznie, sezonowy szczyt do 2 000 w Q4, segment: osoby fizyczne rejestrujące się do usługi leasingowej online". Różnica w szczegółowości przekłada się bezpośrednio na jakość ofert.

2. Wymagania regulacyjne i compliance

To sekcja, której nie można zbagatelizować - i której dostawcy często nie sprawdzają uważnie przed złożeniem oferty.

Co wymagać: potwierdzenie zgodności z ustawą AML (ze wskazaniem konkretnego artykułu dotyczącego identyfikacji), certyfikaty ISO 27001 lub SOC 2, gotowość do podpisania umowy powierzenia przetwarzania danych zgodnie z art. 28 RODO, przechowywanie danych wyłącznie na terenie EOG, deklarowany poziom pewności identyfikacji wg eIDAS.

Ważna zasada: nie pytaj "czy jesteś zgodny z RODO". Pytaj o konkretne dokumenty. Deklaracje bez dokumentów są bezwartościowe na etapie kontroli regulatora.

Grenke Polska, wdrażając zdalną identyfikację klientów zgodną z AML, wskazała wprost, że kluczowym kryterium wyboru było ograniczenie ryzyk przez udokumentowany raport po każdej weryfikacji. Pytanie o format i moc prawną raportu weryfikacji powinno znaleźć się w każdym RFP w tej kategorii.

3. Wymagania funkcjonalne - metody, raport, UX

Opisujesz tu co system ma robić z perspektywy klienta końcowego i twojego procesu operacyjnego.

Co uwzględnić: lista wymaganych metod weryfikacji tożsamości z podziałem na obowiązkowe i opcjonalne (wideoweryfikacja, bankowość elektroniczna, e-dowód, mObywatel), możliwość doboru metody per segment klienta, wymagania dotyczące raportu (ścieżka audytowa, timestamp, metoda, wynik, pieczęć kwalifikowana), ścieżka eskalacji dla nieudanych weryfikacji, wymagania UX (czas procesu, obsługa mobilna bez instalacji aplikacji, obsługa językowa).

Benchmark z rynku: BNP Paribas Leasing Solutions po wdrożeniu systemu weryfikacji tożsamości osiągnęła czas identyfikacji rzędu kilkudziesięciu sekund przy wymaganiach sprowadzonych do dowodu osobistego i kamery - dostępnych 24/7 bez udziału pracownika. Jeśli twój dostawca nie potrafi podać podobnych benchmarków z wdrożeń u klientów o podobnym profilu, to też jest informacja.

4. Wymagania techniczne i integracyjne

Ta sekcja mówi dział IT ile pracy ich czeka i czy dostawca jest gotowy im w tym pomóc.

Co uwzględnić: API RESTful z dokumentacją OpenAPI/Swagger dostępną publicznie lub na żądanie, dostępność środowiska sandbox przed podpisaniem umowy, obsługa webhooków do asynchronicznego odbioru wyników, wersjonowanie API z zagwarantowaną kompatybilnością wsteczną przez minimum 12 miesięcy, dostępne SDK.

Krytyczne pytanie dotyczące vendor lock-in: "Czy dodanie nowej metody weryfikacji wymaga nowej integracji technicznej po naszej stronie?" - jeśli tak, to przy każdej zmianie lub rozbudowie procesu twój IT wraca do punktu wyjścia. Jeśli dostawca oferuje model hubowy - jedno API, wielu sub-dostawców weryfikacji - ryzyko lock-in jest istotnie mniejsze. Szerzej o konsekwencjach tego wyboru przy zmianie dostawcy KYC.

5. SLA, dostępność i ciągłość działania

Weryfikacja tożsamości jest zazwyczaj ścieżką krytyczną w onboardingu. Godzinna awaria w peaku sprzedażowym oznacza klientów, którzy rejestracji nie skończą i nie wrócą.

Co wymagać: deklarowany uptime z historycznym dowodem za ostatnie 12 miesięcy, latencja API w percentylach p50/p95/p99, czas reakcji na incydenty krytyczne i poważne, mechanizm kredytów SLA za naruszenia dostępności, dostępność wsparcia technicznego (24/7 vs. 8x5).

Kluczowa zasada: nie przyjmuj deklaracji uptime bez potwierdzenia historycznym raportem. Dostawca, który nie ma takich danych lub odmawia ich udostępnienia, sygnalizuje problem.

6. Bezpieczeństwo danych i lokalizacja przetwarzania

Wymagania twarde dla większości organizacji przetwarzających dane KYC: dane osobowe i biometryczne przetwarzane wyłącznie na terenie EOG, szyfrowanie w tranzycie (TLS 1.2 lub wyższy) i w spoczynku (AES-256 lub równoważne), regularne testy penetracyjne przez niezależny podmiot minimum raz w roku, notyfikacja o naruszeniu danych w ciągu 24 godzin od wykrycia, podpisanie umowy powierzenia przetwarzania danych przed uruchomieniem środowiska produkcyjnego - nie "po uruchomieniu, jak już przejrzy prawnik".

7. Kryteria oceny ofert i scoring

Ta sekcja mówi dostawcom jak będą oceniani - i dyscyplinuje twój zespół do obiektywnego porównania odpowiedzi.

Przykładowy podział wagowy:

• zgodność regulacyjna i certyfikaty: 30%
• funkcjonalność i metody weryfikacji: 25%
• integracja techniczna i API: 20%
• SLA, dostępność i bezpieczeństwo: 15%
• model cenowy i TCO (całkowity koszt posiadania): 10%

Zwróć uwagę na wagę ceny. 10% to mało - celowo. Najtańsza weryfikacja per-unit może być najdroższa gdy uwzględnisz koszty integracji, utrzymania i potencjalnej migracji. Compliance Manager i CTO zazwyczaj się z tym zgadzają od razu. CFO wymaga uzasadnienia - dlatego warto priorytetyzację wpisać jawnie do RFP, żeby wszyscy rozumieli ją na wejściu.

8. Warunki pilotażu i proof of concept

To sekcja, której brakuje w większości RFP - i jest to błąd, który firmom wychodzi bokiem po podpisaniu umowy.

RFP powinno zawierać klauzulę wymagającą przeprowadzenia PoC na realnych lub syntetycznych danych przed wejściem w życie umowy głównej. Klauzula powinna określać zakres pilotażu, czas trwania (zazwyczaj 10-14 dni roboczych), konkretne progi sukcesu (np. completion rate min. 85%, mediana czasu weryfikacji poniżej 3 minut), konsekwencje nieosiągnięcia progów (prawo do rezygnacji bez kosztów lub wydłużenia PoC).

Dostawca, który odmawia PoC lub uzależnia go od podpisania umowy rocznej z góry, to sygnał ostrzegawczy. Dobry dostawca ma dane z wdrożeń, może odtworzyć warunki twojego procesu w sandboxie i wie, że weryfikacja na realnych danych jest mu na rękę. O tym jak przeprowadzić pilotaż systemu KYC i jakie pytania stawiać - szczegółowo w osobnym artykule.

Jak formułować wymagania w RFP - konkretne wskazówki

Wymagania twarde vs. miękkie - czym się różnią

Wymaganie twarde to warunek konieczny - jego brak dyskwalifikuje ofertę bez dalszej analizy. Wymaganie miękkie jest preferowane, ale jego brak obniża scoring, nie eliminuje dostawcy.

Mylenie tych kategorii jest najczęstszym błędem technicznym w RFP na KYC. Jeśli wszystko jest "wymaganiem twardym", dostawcy albo deklarują spełnienie rzeczy, których nie spełniają, albo wypada każdy, kto był szczery. W obu przypadkach tracisz wartość z procesu.

Zasada praktyczna: wymaganie twarde powinno być weryfikowalne dokumentem lub w trakcie PoC - nie oświadczeniem. "Dostawca posiada certyfikat ISO 27001" to wymaganie twarde weryfikowalne certyfikatem. "System jest bezpieczny" - to nie jest wymaganie w żadnej kategorii.

Jak opisać wymagany poziom pewności weryfikacji

Zamiast pisać "wysoki poziom bezpieczeństwa weryfikacji", odwołaj się do eIDAS Level of Assurance (LoA):

• LoA Low (niski) - weryfikacja o niskim ryzyku, np. potwierdzenie adresu email
• LoA Substantial (znaczny) - typowy wymóg dla sektora finansowego przy standardowych transakcjach, wymaga silnego uwierzytelnienia
• LoA High (wysoki) - wymagany dla wysoce wrażliwych operacji, kryptograficzne potwierdzenie tożsamości

Twoje wymagania dotyczące LoA wynikają z regulacji lub własnej analizy ryzyka. Jeśli nie wiesz jaki poziom jest wymagany dla twojego procesu - to pytanie do prawnika lub regulatora, nie do dostawcy. Dostawca może doradzić, ale nie może tej decyzji za ciebie podjąć i nie powinien.

Jak zapisać wymagania dotyczące RODO i lokalizacji danych

Złe sformułowanie: "Dane przetwarzane zgodnie z RODO."

Dobre sformułowanie: "Dostawca przetwarza i przechowuje wszelkie dane osobowe, w tym dane biometryczne, wyłącznie na serwerach zlokalizowanych na terytorium Europejskiego Obszaru Gospodarczego. Dostawca zobowiązuje się do podpisania umowy powierzenia przetwarzania danych (art. 28 RODO) przed uruchomieniem środowiska produkcyjnego. Dostawca wskazuje lokalizację serwerów i dostawcę infrastruktury w odpowiedzi na niniejszy RFP."

Pierwsze sformułowanie podpisze każdy dostawca bez mrugnięcia okiem. Drugie zobowiązuje do konkretnych działań i jest weryfikowalne przed podpisaniem umowy.

Scoring ofert - jak porównywać odpowiedzi dostawców

Gdy dostawcy odpowiedzą na RFP, masz prawdopodobnie trzy dokumenty różnej długości, różnym stopniu szczegółowości i różnymi akcentami. Bez uprzednio ustalonego scoringu porównujesz je intuicyjnie - a to oznacza, że wygrywają ci, którzy lepiej sprzedają na papierze, niekoniecznie ci, którzy lepiej spełniają wymagania.

Arkusz scoringowy powinien: przypisywać każdemu kryterium wagę procentową zgodną z tą podaną w RFP, oceniać każde kryterium w skali 1-5 (1 = nie spełnia, 5 = wybitnie przekracza oczekiwania), mnożyć ocenę przez wagę i sumować wyniki dla każdego dostawcy.

Ważna uwaga: scoring jest punktem wyjścia do decyzji o tym, u którego dostawcy przeprowadzić PoC - nie do wyboru dostawcy. MHC Mobility, firma zarządzająca flotą ponad 13 500 pojazdów w regionie CEE, zebrała po wdrożeniu 90% pozytywnych opinii od klientów na temat nowego procesu. Takie liczby nie wynikają z analizy dokumentów - wynikają z testu na realnych użytkownikach. Scoring na papierze jest hipotezą. PoC ją weryfikuje.

Rekomendacja: oceniaj sekcje odpowiednio do kompetencji. Zgodność regulacyjna i bezpieczeństwo danych - compliance lub prawnik wewnętrzny. Integracja techniczna i API - IT lub architekt systemów. UX i completion rate - produkt lub sprzedaż. Model cenowy i TCO - finanse. Żaden single-reviewer nie oceni wszystkiego rzetelnie.

Najczęstsze błędy w RFP na system KYC

1. Wymagania techniczne pisane przez IT bez udziału compliance. Efekt: wybrano system z doskonałym API, który nie spełnia wymogów AML w zakresie dokumentacji procesu identyfikacji. Problem wychodzi przy pierwszej kontroli, nie przy demo. O tym jak unikać błędów systemowych w procesie KYC - w tym artykule.
   
   
2. Brak klauzuli PoC. Bez prawa do pilotażu kupujesz "na papierze". Różnica między tym co dostawca deklaruje, a tym co działa u twoich klientów na twoich dokumentach, wychodzi dopiero po integracji - kiedy zmiany są kosztowne.
   
   
3. Cena per-weryfikacja jako główne kryterium. Najtańsza weryfikacja per-unit może kosztować dwa razy tyle po uwzględnieniu: kosztów integracji, utrzymania, wsparcia technicznego i ewentualnej migracji. Całkowity koszt posiadania (TCO) to właściwa miara - nie cena z oferty.
   
   
4. Brak wymagań dotyczących formatu i mocy prawnej raportu. "Raport weryfikacji" różni dostawcy rozumieją bardzo różnie. Jeden dostarcza PDF zabezpieczony pieczęcią kwalifikowaną z pełną ścieżką audytową. Inny - podsumowanie w panelu administratora. Przy pierwszym sporze lub kontroli ta różnica jest krytyczna. Wymagaj wzoru raportu przed podpisaniem umowy.
   
   
5. Pominięcie UX klienta końcowego. Decyzja zakupowa zapada na podstawie demo dla osób kupujących - nie dla klientów, którzy będą przechodzić weryfikację. Nikt nie testuje jak wygląda proces na starszym telefonie z Android 10 i słabym połączeniem. Efekt: completion rate po wdrożeniu niższy niż zakładano, wyższy koszt akwizycji i klienci porzucający wniosek w połowie.
   
   
6. Odpowiedź na RFP bez sygnatury osoby technicznej po stronie dostawcy. Jeśli odpowiedź na pytania o architekturę API i lokalizację danych pisze wyłącznie handlowiec, nie masz żadnej gwarancji, że deklaracje są prawdziwe. Wymagaj w RFP, żeby dokument był podpisany przez osobę techniczną po stronie dostawcy.
   
   

Najczęściej zadawane pytania

Czy każda firma kupująca system KYC musi pisać RFP?

Nie. RFP ma sens przy formalnym procesie zakupowym, zakupie na umowę wieloletnią lub konieczności uzasadnienia wyboru wewnętrznie. Przy pilotażu na małą skalę lub zakupie na polecenie sprawdzonego partnera z prostymi wymaganiami - RFP może być nadmiarem procedury.

Ile ofert powinno trafić do RFP na system KYC?

Optymalnie 2-4 dostawców. Mniej niż 2 to nie jest porównanie. Więcej niż 5 generuje dużą pracę przy analizie odpowiedzi i zazwyczaj nie przynosi lepszego wyboru niż rzetelnie przeprowadzone porównanie 3 dostawców.

Jak długo trwa proces RFP dla systemu weryfikacji tożsamości?

Przy dobrze napisanym dokumencie: 2-3 tygodnie na odpowiedzi dostawców, 1-2 tygodnie na analizę i scoring, 2-4 tygodnie na PoC. Łącznie 6-9 tygodni od wysłania do decyzji. To długo - ale zdecydowanie mniej niż naprawa błędnego wyboru po 12-miesięcznej umowie z pełną integracją.

Co powinien zawierać szablon RFP dla systemu KYC?

Strona tytułowa z terminami, instrukcja wypełnienia, sekcja kontekstu organizacyjnego (do wypełnienia), wymagania regulacyjne (checklist TAK/NIE/komentarz), wymagania funkcjonalne i techniczne z podziałem na twarde i miękkie, tabela SLA z kolumnami dla kilku dostawców, sekcja bezpieczeństwa, arkusz scoringowy z wagami i klauzula PoC gotowa do wklejenia do umowy.

Czy dostawca systemu KYC ma obowiązek podpisać umowę powierzenia przetwarzania danych?

Tak, jeśli przetwarza dane osobowe w imieniu twojej organizacji. Wynika to bezpośrednio z art. 28 RODO. Dostawca, który odmawia podpisania DPA lub uzależnia to od "późniejszych negocjacji", to sygnał ostrzegawczy. DPA powinno być warunkiem uruchomienia środowiska produkcyjnego, nie opcją.

Jak oceniać odpowiedzi dostawców jeśli nie mam wiedzy technicznej?

Podziel scoring według kompetencji: zgodność regulacyjna i bezpieczeństwo - compliance lub prawnik, integracja i API - IT lub architekt, UX i completion rate - produkt lub sprzedaż, model cenowy - finanse. Żaden single-reviewer nie oceni wszystkich obszarów rzetelnie. Scoring działa wtedy, gdy różne osoby oceniają to, na czym się znają.

Jeśli piszesz RFP i chcesz zweryfikować wymagania z ekspertem, który wdrażał systemy weryfikacji tożsamości w sektorze finansowym i leasingowym, umów bezpłatną konsultację z ekspertem Autenti. Możemy przejrzeć draft wymagań i wskazać co warto doprecyzować przed wysłaniem do dostawców.

👉 Pobierz szablon RFP na system eKYC (weryfikacja tożsamości online)