Regulowane wdrożenia

Zgodność wbudowana w system.
Nie doklejona na końcu.

Budujemy produkty kryptowalutowe i fintechowe dla licencjonowanych zespołów. Obowiązki wynikające z MiCA, PSD2, AML i RODO kształtują architekturę od pierwszego dnia. Oznacza to mniej niespodzianek podczas audytu. Oznacza to również krótszą drogę do wdrożenia.

Naszymi klientami są VASP-y, PSP-y, EMI-e, neobanki i startupy kryptowalutowe działające w UE. Potrzebują jednego partnera, który rozumie zarówno blockchain, jak i przepisy.

Ramy regulacyjne

Przepisy, według których projektujemy

Każde z tych ram zmienia konkretne elementy budowy systemu. Poniżej znajdziesz informacje o tym, jak przekłada się to na kod, model danych i procedury operacyjne.

  • MiCA

    Rynki kryptoaktywów

    Wcześnie odwzorowujemy obowiązki licencyjne w systemie. Zabezpieczanie aktywów, ujawnianie informacji i raportowanie stają się realnymi usługami, a nie sloganami w prezentacji.

    Architektura gotowa na MiCA

  • PSD2

    Usługi płatnicze

    Silne uwierzytelnianie klienta, wyjątki SCA i przejrzyste ścieżki audytu. Przepływy płatności mają własną dokumentację dowodową.

    Szyny płatnicze

  • AML

    AML i Travel Rule

    Skrining, ocena ryzyka i komunikaty Travel Rule działają wewnątrz ścieżki transakcji. Nic nie odbywa się jako skrypt poboczny.

    Zgodność z AML / Travel Rule

  • RODO

    Ochrona danych

    Rezydencja danych w UE, dostęp na zasadzie niezbędnego minimum i zasady retencji. Zakres danych osobowych jest określany, zanim powstanie pierwszy schemat.

    Realizacja zgodna z RODO

  • PCI

    Gotowość do obsługi danych kart

    Przepływy danych kart pozostają, gdy to możliwe, poza Twoim rdzeniem systemu. Zakres się zmniejsza, a coroczny przegląd staje się znacznie tańszy.

    Gotowość do PCI DSS

  • SOC 2

    Gotowość mechanizmów kontrolnych

    Kontrola zmian, logowanie zdarzeń i przeglądy dostępu są częścią wdrożenia od początku. Twój audytor ocenia systemy, a nie obietnice.

    Gotowość do SOC 2

Zakres kontroli

Mechanizmy kontrolne, które zostawiają ślad

Mechanizm kontrolny, którego nikt nie potrafi udowodnić, nie jest mechanizmem kontrolnym. Dlatego każdy z nich działa razem z zapisem, który potwierdza jego działanie. Audytorzy oceniają system, a nie prezentację.

Tabela przedstawia bazowy zestaw mechanizmów kontrolnych, jaki stosujemy w projektach dotyczących aktywów cyfrowych. Zakres zmienia się w zależności od licencji i produktu. Więcej szczegółów na temat wdrożenia znajdziesz na naszych stronach dotyczących inżynierii zgodności oraz portfeli i przechowywania aktywów .

Bazowe mechanizmy kontrolne i dowody ich działania
#ObszarMechanizm kontrolnyDowód
01 Przechowywanie kluczy Podpisywanie MPC lub HSM, podzielone kworum Zapis ceremonii generowania kluczy, dziennik rotacji
02 Weryfikacja transakcji Kontrole przed nadaniem transakcji, z twardymi blokadami Ścieżka decyzyjna dla każdego przelewu
03 Środki klientów Wydzielone księgi, codzienna rekoncyliacja Raport rozbieżności, historia zatwierdzeń
04 Dostęp Role z przeglądem co kwartał Eksport przeglądu dostępów
05 Kontrola zmian Zweryfikowane merge'e, podpisane wydania Rejestr wydania dla każdego wdrożenia
06 Incydenty Poziomy istotności, uzgodnione okna reakcji Pisemny raport post-mortem

Metoda

Cztery bramki, jedna dyscyplina dostarczania

Prace zgodności są planowane, nie improwizowane. Każda faza ma właściciela i pisemny wynik.

  1. 01

    Bazowy zakres obowiązków

    Odkrycie wskazuje Twoją ścieżkę licencyjną i obowiązki. Zapisujemy, co ma zastosowanie, zanim zaplanujemy jakikolwiek kod.

  2. 02

    Bramka architektury

    Każdy obowiązek staje się kontrolą w projekcie. Towarzyszy mu model zagrożeń i mapa danych.

  3. 03

    Budowa oparta na dowodach

    Kontrole trafiają do produktu wraz z jego dostarczeniem. Logi, rejestry i raporty to funkcje, a nie późniejsze porządki.

  4. 04

    Utwardzanie i przekazanie

    Testujemy kontrole, a następnie przekazujemy runbooki. Twój zespół poradzi sobie z audytorem bez naszego udziału.

Pytania

O co pytają nas zespoły najpierw

Konkretne odpowiedzi dotyczące zakresu, zmian i istniejących systemów.

Czy udzielacie porad prawnych lub licencyjnych?

Nie. Jesteśmy inżynierami, nie kancelarią prawną. Budujemy to, co określą Wasi prawnicy i compliance officer. Przekładamy te obowiązki na architekturę, kontrole i dowody czytelne dla regulatora.

Co się dzieje, gdy przepisy zmieniają się w trakcie budowy?

Obowiązki są weryfikowane na każdej bramce fazy. Większość zmian trafia jako punktowa korekta w ramach już zatwierdzonego harmonogramu. Gdy zmiana wykracza poza zakres budowy, najpierw otrzymujecie pisemną ocenę wpływu.

Czy możecie pracować z naszą istniejącą platformą?

Tak. Większość projektów zaczyna się od systemu, który już istnieje. Analizujemy obecny projekt, znajdujemy luki, a następnie zamykamy je względem interfejsów należących do Waszego zespołu.

Przedstaw nam swój obszar zgodności

Prześlij ścieżkę licencyjną i produkt, który planujesz wdrożyć. Odpowiemy architekturą, lukami w kontrolach i kolejnością dostarczania. Do rozmowy dołączają architekci. Najpierw podpisujemy NDA.

Umów rozmowę wstępną [email protected]

Wolisz najpierw dowody? Przeczytaj nasze studia przypadków.