Procedura udostępniania informacji do SInF zgodnie z obecnym brzmieniem ustawy polega na kilku czynnościach, są to:

• Dostosowanie danych, które mają być przesłane do Systemu Informacji Finansowej pod względem formatu i ich weryfikacji (sprawdzenia ich semantyki oraz składni). Dane te, a zatem informacje o rachunkach otwartych i zamkniętych w danej instytucji finansowej muszą być odpowiednio przygotowane do wysyłki.
• Informacje te muszą być następnie umieszczone w systemie (na przykład w module SInF Reporter) i dostosowane do wymaganego formatu.
• Dane muszą zostać podpisane i zatwierdzone za pomocą odpowiedniego certyfikatu.
• Przygotowane i dostosowane pod kątem formatu i odpowiednio podpisane dane są następnie wysyłane szyfrowaną komunikacją.
• Ostatnim krokiem jest wygenerowanie potwierdzenia poprawnego złożenia określonych danych.

Powyższe zadania można wykonać na kilka sposobów – są to właśnie modele wdrożeniowe, w ramach których zaimplementowany może zostać moduł SInF Reporter. Wyróżniamy 3 główne modele oraz jeden alternatywny.

Model pierwszy SInF Reporter

Pierwszym modelem w jakim może zostać zaimplementowany moduł SInF Reporter jest tak zwany desktop. Jest to nic innego jak dostęp do aplikacji SInF Reporter, do której użytkownik otrzymuje dostęp pobierając ją z poziomu przeglądarki. Po pobraniu takiej aplikacji, konieczne jest załadowanie do niej odpowiednich certyfikatów, wymaganych do prawidłowej wysyłki danych do KIR. Za pomocą takiej aplikacji można wykonać wszystkie wyżej wymienione czynności wysłania komunikatu do KIR, a dodatkowo dane w żaden sposób nie wychodzą poza bezpieczną infrastrukturę zarządzaną przez organizację.

Model drugi SInF Reporter

Drugim modelem wdrożenia modułu SInF Reporter jest tak zwane rozwiązanie on-premise (rozwiązanie to ma również określenie „mode one”). Polega ono na tym, że oferowana przez Inteca aplikacja SInF Reporter, rozmieszczana jest na serwerach instytucji zoobowiązanej. Aplikacja ta wystawia API do wysyłania informacji o rachunkach. W rozwiązaniu tego typu mamy do czynienia z pewną automatyzacją, dzięki której, posiadając już system, w którym zdefiniowane są rachunki możemy je powiązać z naszym rozwiązaniem. Efektem tego jest możliwość wysyłania informacji o rachunkach do STIR w sposób zautomatyzowany. Następnie połączenie z KIR, wysyłka danych oraz uzyskanie potwierdzenia odbywa się w ramach infrastruktury aplikacji SInF Reporter. Dzięki temu rozwiązaniu nie ma konieczności manualnego wypełniania danych, rzecz jasna w ramach aplikacji jest do nich pełen wgląd, jednakże automatyzacja tego procesu w znacznym stopniu ogranicza manualną prac

Model trzeci SInF Reporter

Trzecim modelem jest rozwiązanie podobne do punktu drugiego – modelu on-premise, jednak częściowo zmodyfikowane (tak zwany on-premise „mode two”). Tak jak w przypadku modelu z punktu drugiego, podstawą do implementacji tej metody jest obecność systemu, który posiada informację o prowadzonych rachunkach. Podobnie również, aplikacja rozmieszczana jest na serwerach instytucji zobowiązanej. Różnicą między „mode one” a „mode two” jest to, że w przypadku „mode two” oferujemy rozwiązanie, które wykonuje pracę integracyjną do systemu klienta, na którym zlokalizowane są dane o rachunkach. W przypadku Modelu on premise „mode one”, to po stronie instytucji zobowiązanej leży implementacja wysyłki danych do API SInF Reportera, natomiast model on premise „mode two” odwracą tą rolę. Inteca integruje się ze wskazanym miejscem przechowywania danych o rachunkach. Jest to szczególnie pomocne, gdy organizacja wdrażająca nie ma rozbudowanego działu IT.

Model alternatywny SInF Reporter

Istnieje również pewien alternatywny model na którym można by oprzeć implementację aplikacji SInF Reporter. Model ten polegałby na umieszczeniu aplikacji SInF Reporter na zewnętrznej, zabezpieczonej chmurze. W takiej formie, wszystkie pięć elementów importu danych do KIR (dostosowanie danych, formatowanie ich, podpisanie i szyfrowanie, a także uzyskanie potwierdzenia) byłyby wysyłane bezpośrednio z zabezpieczonej chmury. Niestety, obecnie z racji wrażliwości tych danych i regulacji wynikających z komunikatu KNF dotyczącego chmury obliczeniowej, taki transfer danych jest objęty ścisłymi restrykcjami. Z technicznego punktu widzenia taki model realizacji transferu danych za pomocą chmurowej aplikacji SInF Reporter jest jak najbardziej możliwy, jednak problem stanowi spełnienie wymogów przez samą chmurę. Zgodnie z wymogami KNF informacje wrażliwe, a takimi właśnie są informacje o rachunkach umieszczone na takiej chmurze podlegają także osobnym regulacjom, gdyż jest to tak zwany outsourcing chmury obliczeniowej szczególny. Rozwiązanie takie jest zatem wyzwaniem nie tyle pod kątem technicznym, co proceduralnym, gdyż spełnienie licznych wymogów stawianych chmurze obliczeniowej są obecnie bardzo trudne do spełnienia. Warto zatem skupić się na pozostałych modelach opisanych w poprzednich punktach, które zarówno z technicznego jak i proceduralnego punktu widzenia są w pełni dostępne i osiągalne.

Przedstawione powyżej główne modele SInF Reporter są w pełni gotowe do implementacji u klientów.

Rozwiązania te zgodnie z obecną literą projektu ustawy o SInF w całości spełniają wymogi stawiane na jednostkach finansowych w tym zakresie. Warto podkreślić, że finalne brzmienie ustawy o Systemie Informacji Finansowej nie jest jeszcze znane, jednak na bieżąco monitorujemy ten aspekt i jesteśmy gotowi do dokonania ewentualnych zmian lub aktualizacji proponowanych rozwiązań.