Załącznik nr 2 do OPZ - Wymagania szczegółowe Strona 1 z 4
Transkrypt
Załącznik nr 2 do OPZ - Wymagania szczegółowe Strona 1 z 4
Załącznik nr 2 do OPZ - Wymagania szczegółowe Lp Funkcjonalności Systemu do obsługi MSR 1 Wymagania ogólne System musi być zgodny ze stosowanymi na dzień zawarcia umowy uznanymi na rynku standardami technicznymi w zakresie dostarczanego oprogramowania, a także przyjętych 1.1 rozwiązań oraz gwarantujący Zamawiającemu możliwość jego dalszej rozbudowy i unowocześnienia, w przypadku Systemu w skład którego wchodzi baza danych (dostarczana przez Zamawiającego), Zamawiający musi posiadać nieograniczoną możliwość łączenia się z bazą danych 1.2 wraz z nieograniczoną możliwością z korzystania z danych i obiektów w niej się znajdujących, 1.3 System jest zbudowany w modelu klient-serwer. 1.4 dostęp do pełnej funkcjonalności, w szczególności Parametryzacji, oceny indywidualnej, jest wymagany za pomocą klienta pracującego w graficznym środowisku MS Windows (dostarczany przez Zamawiającego) lub za pośrednictwem przeglądarki internetowej co najmniej Microsoft Internet Explorer 9 lub nowszej lub FireFox 3.6 lub nowszej 1.5 W przypadku architektury dwuwarstwowej (tzw. gruby klient) System musi być dostosowany do korzystania ze środowiska Citrix Xen App (dostarczany przez Zamawiającego) 1.6 1.7 1.8 1.9 1.10 1.10.1 1.10.2 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22 1.23 1.24 1.25 1.26 1.27 1.28 1.29 1.30 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.8.1 3.8.2 4 4.1 4.2 interfejs użytkownika musi być intuicyjny i ergonomiczny (uporządkowanie pól zgodne z kolejnością i częstością wypełniania, optymalna liczba okien wymaganych do zrealizowania funkcji), wygląd ekranów oraz domyślne działanie typowych funkcji musi być jednolite (umieszczenie przycisków, opisy pól, treść podpowiedzi), w przypadku istotnych operacji (np. usuwanie danych, parametrów itp.) wymagane jest potwierdzenie zamiaru wykonania operacji, System umożliwia dostosowanie wyglądu interfejsu do Księgi Wizualizacji BGK Interfejs użytkownika posiada następujące cechy: ekrany posiadają jednolity wygląd (tj. np. uporządkowanie pól, umieszczenie przycisków, opisy pól w ustalonej konwencji), działanie typowych funkcji jest jednolite (np. wyszukiwanie, sortowanie, przeglądanie, drukowanie itp.) dostępnych z różnych ekranów, wymaganym językiem elementów interfejsu (np. menu, etykiet i komunikatów) jest język polski, komunikaty o błędach lub nieprawidłowościach działania muszą być sformułowane w sposób zrozumiały dla użytkowników Zamawiającego, obsługa interfejsu jest realizowana przy pomocy myszy i klawiatury, istnieje wbudowany kontekstowy plik pomocy dający użytkownikowi możliwość łatwego i szybkiego sięgania po potrzebne informacje, System posiada moduł pomocy niezależnie od pomocy kontekstowej moduł pomocy jest podzielony tematycznie na obszary związane z poszczególnymi funkcjonalnościami Systemu, dostęp do pomocy opisującej pełną informację na wybrany przez użytkownika temat dotyczący funkcjonalności Systemu, zawierającą możliwość wykorzystania wyszukiwania po słowach kluczowych (indeks) jest możliwy z poziomu interfejsu graficznego, System musi być w pełni skonfigurowany, a więc przygotowany do realizacji wszystkich wymaganych funkcjonalności, System umożliwia tworzenie zestawów parametrów wykorzystywanych do przetwarzania danych i wyznaczania wyników definiowanie parametrów musi być możliwe przez użytkowników nieposiadających wiedzy programistycznej definiowanie parametrów musi być możliwe przez interfejs graficzny System umożliwiająca jednoczesną pracę wielu operatorom System operuje na pełnych kwotach ekspozycji z dokładnością do groszy System obsługuje stopę dyskontową do co najmniej 4 miejsc po przecinku w wartościach procentowych System pozwala osobie z odpowiednimi uprawnieniami podgląd prac wykonywanych przez analityków w analizie indywidualnej. System posiada funkcjonalność akceptacji analizy indywidualnej przez innego użytkownika System pozwala na wpisywanie formuł obliczeniowych w polach danych np. w harmonogramach System pozwala na przenoszenie wpisanych formuł między polami. System musi zapewnić ślad audytorski – umożliwiający śledzenie dokonywanych operacji i zmian we wprowadzonych danych/parametryzacji, zawierający dokładny zapis zmian: datę, godzinę, użytkownika, treść zmiany (co i na co zmieniane) oraz blokować modyfikowalność tych zapisów (ślad audytorski winien być dostępny dla użytkownika i niemożliwy do zmiany przez użytkownika). istnieje możliwość definiowania parametrów poprzez wykorzystanie języka programowania obiektowego i/lub skryptowego (np. Java, C#, 4GL, SQL) i wykorzystania tych parametrów w Parametryzacji Wersjonowanie System będzie posiadał możliwość tworzenia wielu wersji Parametryzacji lub jej elementów Każda wersja będzie oznaczona co najmniej statusem, datą jej utworzenia/modyfikacji oraz identyfikatorem użytkownika wprowadzającego modyfikację/tworzącego wersję System będzie umożliwiał przypisanie jednej z wersji Parametryzacji lub jej elementu statusu „zatwierdzona” (produkcyjna), która jest zablokowanej do edycji. Wersja Parametryzacji o statusie „zatwierdzona” może funkcjonować tylko jedna. System będzie umożliwiał utworzenie nowej wersji Parametryzacji na podstawie już istniejącej, tj. utworzenia kopii wybranej Parametryzacji i zapisania jej jako nowej wersji ze statusem „robocza”. System posiada funkcjonalność wykonania kalkulacji w SK na wybranych danych, z wykorzystaniem wybranej wersji Parametryzacji. Wyniki kalkulacji będą zapisywane w bazie danych. System będzie posiadał mechanizm umożliwiający usuwanie wskazanej Parametryzacji wraz z wynikami kalkulacjami przeprowadzonymi na jej podstawie pod warunkiem, że nie była ona oznaczona jako „zatwierdzona”. System będzie umożliwiał jednoznaczne przypisanie wyników kalkulacji do wersji Parametryzacji i danych, na których kalkulacja była wykonana w taki sposób aby można było powtórzyć kalkulację w wybranym momencie System będzie blokował edycję i usunięcie wyników kalkulacji, która została przeprowadzona na podstawie Parametryzacji oznaczonej statusem „zatwierdzona” System umożliwia eksport i import Parametryzacji do/z pliku Konfiguracja źródeł danych System umożliwia pobranie danych z plików płaskich w formacje txt, csv, zapisanych zgodnie z kodowaniem UTF-8 i Windows-1250 System umożliwia określenie w konfiguracji jakie pliki (nazwy plików) obsługują wybraną grupę danych System umożliwia określenie ścieżki do katalogu plikami zasilającymi oraz katalogu z plikami archiwalnymi System przenosi wczytane pliki do zdefiniowanego w konfiguracji Systemu katalogu z plikami archiwalnymi System umożliwia zdefiniowanie wielu, niezależnych źródeł danych/plików dla poszczególnych grup danych System zapamiętuje konfigurację źródeł danych/plików System posiada interfejs graficzny umożliwiający realizację ww. zadań System posiada możliwość pobrania danych za pomocą interfejsów typu ODBC, OLE DB, ADO lub DAO z bazami danych zgodnych ze standardem SQL-92 i w ramach tej funkcjonalności: zapamiętanie konfiguracji połączenia ze źródłem danych posiada interfejs graficzny umożliwiający realizację ww. zadań Zasilanie danymi System umożliwia wielokrotne zasilenie danymi na wybraną datę do obszaru przejściowego (OP) Ponowne uruchomienie zasilania danymi na datę, która już wcześniej była przetwarzana przez System nie może spowodować usunięcia istniejących w bazie OP danych - System utworzy nową wersję zestawu danych umożliwiającą wykonanie przetworzenie w SK 4.3 System posiada możliwość uruchomienia pobierania danych ze źródeł zewnętrznych przez operatora, z wykorzystaniem interfejsu graficznego 4.4 System zawiera log przetwarzania danych, w którym rejestrowane są w szczególności: 4.4.1 uruchomienie przetwarzania 4.4.2 zakończenie przetwarzania 4.4.3 zatrzymanie przetwarzania powstałe w wyniku błędu 4.4.4 tworzenie nowej wersji Parametryzacji i zmiana statusu z "roboczy" na "zatwierdzony" 4.4.5 zatwierdzenie kalkulacji System zapisuje do logu informacje o poszczególnych etapach przetwarzania, a w przypadku wystąpienia błędu informację o charakterze błędu oraz dane umożliwiające 4.5 identyfikacje błędnych danych (np. identyfikator klienta, transakcji, numer linii w przetwarzanym pliku) 4.6 System wyświetla komunikat o wystąpieniu błędów oraz innych problemów w zasilaniu danymi 4.7 System posiada możliwość sprawdzenia logu przetwarzania dla wybranej daty 4.8 System posiada interfejs graficzny umożliwiający realizację ww. zadań 4.9 System umożliwia użytkownikowi modyfikację zakresu danych wejściowych oraz procesu zasilania i przetwarzania danych System posiada możliwość automatycznego pobierania danych ze źródeł zewnętrznych, zgodnie z harmonogramem określającym częstotliwość uruchomienia zasilania z 4.10 dokładnością do dnia tygodnia oraz godziny. 4.11 System umożliwia zasilanie danych słownikowych z pliku w formacie csv lub txt lub xls z wykorzystaniem 5 Spójność danych i jakość danych 5.1 System sprawdza czy na wskazaną datę wszystkie grupy danych są kompletne 5.2 System sprawdza czy pobrane dane są spójne z więzami integralności określonymi przez Zamawiającego na etapie Analizy 5.3 Uruchamianie przetwarzanie danych z OP do MD jest możliwe po stwierdzeniu kompletności danych W przypadku stwierdzenie niespójności danych, przetwarzanie danych do MD jest zatrzymywane (przetwarzanie do OP powinno być wykonane w całości w celu umożliwienia 5.4 analizy błędów w danych) 5.5 System zapisuje w logu przetwarzania informacje o pobraniu danych z poszczególnych plików lub o błędach przy pobieraniu danych 5.6 System posiada możliwość sprawdzenia logu przetwarzania dla wybranej daty 5.7 System będzie wykorzystywał wskaźniki opracowane w fazie Analizy do weryfikacji jakości danych, w szczególności następujące sumy kontrolne 5.7.1 5.7.2 5.7.3 5.8 5.9 5.10 5.11 5.12 5.13 6 6.1 wczytane zaangażowanie bilansowe portfela vs zaangażowanie bilansowe portfeli przetworzonych w analizie indywidualnej i kolektywnej wczytane rezerwy celowe portfela vs rezerwy celowe portfeli przetworzonych w analizie indywidualnej i kolektywnej wczytana liczba umów vs liczba umów przeanalizowana (w analizie indywidualnej, kolektywnej, IBNR) System będzie weryfikował czy wszystkie transakcje pobrane z plików zostały przetworzone w SK, W przypadku gdy liczba transakcji nie będzie zgodna System wyświetli stosowny komunikat System będzie weryfikował czy wszystkie wyniki przetworzone w SK posiadają parametryzację do KG, w przypadku gdy dla któregokolwiek wyniku nie będzie parametryzacji do KG System wyświetli stosowny komunikat operatorowi System będzie weryfikował czy transakcje generowane do KG bilansują się z uwzględnieniem agregacji określonej w parametryzacji , w przypadku braku bilansowania System wyświetli stosowny komunikat operatorowi System umożliwia użytkownikowi tworzenie i implementację własnych wskaźników sprawdzających jakość danych, które będą weryfikowane w trakcie zasilania System umożliwia implementację definicji algorytmów generujących terminarz określający przyszłe przepływy kontraktowe, oraz wyliczenie i zapamiętanie terminarzy wygenerowanych na podstawie tych algorytmów System umożliwia wyliczenie i zapamiętanie efektywnej stopy procentowej (ESP) dla wybranej grupy kontraktów Wyznaczanie odpisów indywidualnych z tytułu utraty wartości System kwalifikuje klientów do analizy indywidualnej na podstawie zadanych parametrów, w szczególności: Strona 1 z 4 Czy wymagane Waga (Pn) TAK TAK TAK TAK TAK TAK TAK TAK NIE 2 TAK TAK TAK TAK TAK NIE NIE NIE 2 2 2 NIE 2 TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK NIE 10 TAK TAK TAK TAK TAK TAK TAK TAK TAK NIE 4 TAK TAK TAK TAK TAK TAK TAK TAK NIE NIE 3 3 TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK NIE 10 NIE 3 NIE 5 TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK NIE 6 NIE 9 NIE 6 TAK Załącznik nr 2 do OPZ - Wymagania szczegółowe Lp 6.1.1 6.1.2 6.2 6.3 6.4 6.4.1 6.4.2 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 8 8.1 8.2 8.2.1 8.2.2 8.2.3 8.2.4 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 9 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.7.1 9.8 9.9 9.10 10 10.1 10.2 10.2.1 10.2.2 10.3 10.3.1 10.3.2 10.4 10.4.1 10.4.2 10.4.3 10.5 10.6 10.7 10.8 10.8.1 10.8.2 10.8.3 10.9 10.10 10.11 10.12 10.12.1 10.12.2 10.13 10.13.1 10.13.2 10.13.3 10.14 10.15 10.15.1 10.15.2 10.16 10.16.1 10.16.2 10.16.3 10.17 10.17.1 10.17.2 10.18 10.19 10.19.1 10.19.2 10.19.3 10.20 10.21 11 11.1 11.2 11.3 11.4 11.5 11.6 11.7 Funkcjonalności Systemu do obsługi MSR kwoty ekspozycji na klienta sparametryzowanej przez operatora flagi przesłanki utraty wartości zawartej w danych wejściowych System umożliwia wyszukiwanie klienta wg zdefiniowanych atrybutów (nazwa/fragment nazwy, regon, modulo) System umożliwia wybór klienta dla którego będzie przeprowadzana analiza System wspomaga analizę indywidualną w dwóch etapach: analizy przepływów pieniężnych z tytułu płatności ratalnych w ramach ekspozycji analizy przepływów pieniężnych z tytułu zabezpieczeń w ramach ekspozycji W analizie przepływów pieniężnych z tytułu płatności ratalnych w ramach ekspozycji oczekuje się co najmniej funkcjonalności: pracy na poziomie pojedynczej umowy pracy na poziomie pojedynczego klienta na podstawie wyboru przez operatora zasilenia danymi o umownych harmonogramach spłat, stanach księgowych i efektywnej stopie oprocentowania z pliku/bazy zewnętrznej generowania harmonogramu teoretycznego na podstawie zasilonych parametrów: daty końca transakcji i oprocentowania prezentacji zasilonych danych zdyskontowania wprowadzonych danych na datę analizy przy pomocy zadanej stopy procentowej możliwości modyfikowania harmonogramu umownego modyfikacji harmonogramu umownego "obok" harmonogramu pobranego ze źródła zewnętrznego możliwość porównywania wartości zdyskontowanych dla harmonogramu pierwotnego i zmodyfikowanego modyfikowanie harmonogramu na poziomie poszczególnych przepływów modyfikowanie harmonogramu wskaźnikiem np. obniżenie wszystkich przepływów o x% modyfikowanie dat przepływów rozbicie przepływów na część kapitałową i odsetkową lub pokazywanie kwoty łącznej przepływu modyfikowanie stopy procentowej używanej do dyskontowania dodawanie umów nie zasilonych ze źródła zewnętrznego usuwanie umów zasilonych ze źródła zewnętrznego możliwości wprowadzania uzasadnienia dla zaprojektowanych przepływów pieniężnych (pole tekstowe wymagalne) W analizie przepływów pieniężnych z tytułu zabezpieczeń w ramach ekspozycji oczekuje się co najmniej funkcjonalności: pracy na poziomie pojedynczego zabezpieczenia zasilenia danymi umownymi o zabezpieczeniach danej ekspozycji z pliku/bazy zewnętrznej takimi jak: rodzaj zabezpieczenia wartość zabezpieczenia domyślny wskaźnik korekty wartości zabezpieczenia domyślny okres odzysku zabezpieczenia korekta wartości zabezpieczenia w przedziale <0,1> prezentacji zasilonych danych zdyskontowania wprowadzonych danych na datę analizy przy pomocy zadanej stopy procentowej możliwości wprowadzenia harmonogramu odzysku z zabezpieczenia możliwość wygenerowania automatycznego harmonogramu odzysku z zabezpieczenia na podstawie domyślnych wartości możliwości modyfikacji danych o zabezpieczeniu pobranych ze źródła zewnętrznego możliwość dodawania zabezpieczeń możliwość usuwania zabezpieczeń Wymagania pozostałe przy wyznaczaniu odpisów System zapamiętuje zmiany użytkownika we wprowadzonych danych i przy uruchomieniu analizy ekspozycji w kolejnym okresie proponuje automatyczne zastąpienie informacji pobranych informacjami zmodyfikowanymi System zapamiętuje analizę z poprzedniego okresu i w kolejnym okresie proponuje przepływy z poprzedniej analizy pomniejszone o daty, które minęły System na bieżąco prezentuje wyliczoną utratę wartości dla ekspozycji System po każdej zmianie harmonogramu, stopy dyskontowej, wartości zabezpieczeń wylicza nową kwotę utraty wartości. System będzie umożliwiał wyliczenie różnicy pomiędzy rezerwą wyliczoną zgodnie z PSR a odpisem/rezerwą wyliczoną zgodnie z MSR, a wartość wyliczonej kalkulacji będzie przechowywana w bazie Systemu na poziomie szczegółowości dla poszczególnych ekspozycji System posiada interfejs graficzny dedykowany obsłudze ww. działań. System w przypadku ekspozycji w walutach obcych umożliwia przeprowadzenie kalkulacji w walucie ekspozycji lub w przeliczeniu na złotówki na podstawie zasilonych tabel kursowych pozwala przeliczać przepływy pieniężne oraz zabezpieczenia System prezentuje odpis oraz odsetki impairmentowe w walucie ekspozycji oraz w złotówkach: w przypadku ekspozycji walutowych System przelicza wyniki na złotówki na podstawie zasilonych tabel kursowych pozwala na zdefiniowanie księgowań w walucie ekspozycji lub w złotówkach Wyznaczenie odpisów kolektywnych z tytułu utraty wartości System wyznacza wartość odpisu IBNR zgodnie z MSR 39 System automatycznie wyznacza portfel kwalifikujący się do odpisu IBNR według zasady: wszystkie ekspozycje, dla których nie została oznaczona flaga utraty wartości wszystkie ekspozycje, których oznaczona została flaga utraty wartości, ale w analizie indywidualnej lub portfelowej nie stwierdzono utraty wartości System umożliwia podział portfela IBNR na subportfele według: algorytmów wpisanych w Systemu opierających się np. na kategoryzacji klienta lub produktu podziału wprowadzonego przez uprawnionego operatora System zapamiętuje podział ekspozycji i proponuje taki sam podział w kolejnym okresie: według takich samych algorytmów wpisanych w Systemu, o ile nie zostały one zmienione podział wprowadzony przez operatora dla ekspozycji nowych, którym nie można przypisać subportfela na podstawie algorytmu pyta o przypisanie do konkretnego portfela System oznacza na poziomie ekspozycji, do którego subportfela IBNR dana ekspozycja jest zakwalifikowana Odpis IBNR wyznaczany jest według wzoru Ekspozycja x PD x LGD System korzysta z zasilonych zewnętrznie parametrów PD i LGD do wyliczenia odpisu IBNR Parametry PD i LGD mogą być określone na poziomie: subportfela IBNR (wspólne dla subportfela) grupy ekspozycji z różnych subportfeli (wydzielone na podstawie znaczników klienta/ekspozycji) pojedynczego klienta lub ekspozycji (np. przypisane na podstawie ratingu) System przechowuje historyczne wartości wyliczeń IBNR na poziomie szczegółowości dla poszczególnych ekspozycji System wyznacza wartość odpisu kolektywnego dla ekspozycji ze stwierdzoną przesłanką utraty wartości zgodnie z MSR 39 System przypisuje ekspozycje do portfela kolektywnego według zasady: ekspozycje dla których stwierdzono przesłankę utraty wartości, a kwota ekspozycji na klienta nie przekracza kwoty progowej skutkującej zaklasyfikowaniem do analizy indywidualnej System umożliwia podział portfela kolektywnego na subportfele według: algorytmów wpisanych w Systemu opierających się np. na kategoryzacji klienta lub produktu podziału wprowadzonego przez uprawnionego operatora System zapamiętuje podział ekspozycji i proponuje taki sam podział w kolejnym okresie: według takich samych algorytmów wpisanych w Systemu, o ile nie zostały one zmienione podział wprowadzony przez operatora dla ekspozycji nowych, którym nie można przypisać subportfela na podstawie algorytmu pyta o przypisanie do konkretnego portfela System wykorzystuje w kalkulacji wartości parametrów PD, LGD i EAD zasilonych zewnętrznie i przypisanych do poszczególnych subportfeli Parametr LGD w analizie kolektywnej może być wyliczany w Systemie dla poszczególnych ekspozycji na podstawie algorytmu wykorzystującego: wartości i rodzaje zabezpieczeń dla ekspozycji parametrów korygujących wartości zabezpieczeń dla ekspozycji Parametry PD i LGD mogą być określone na poziomie: subportfela IBNR (wspólne dla subportfela) grupy ekspozycji z różnych subportfeli (wydzielone na podstawie znaczników klienta/ekspozycji) pojedynczego klienta lub ekspozycji (np. przypisane na podstawie ratingu) Parametr EAD wyznacza się w oparciu o następujący algorytm: dla ekspozycji bez części pozabilansowej - EAD = zaangażowanie bilansowe dla ekspozycji z częścią pozabilansową - EAD = zaangażowanie bilansowe + zaangażowanie pozabilansowe*CCF CCF przyjmuje wartość 0% dla ekspozycji warunkowych lub 100% dla ekspozycji bezwarunkowych Status ekspozycji określany jest automatycznie przez aplikację : ekspozycjom z tytułu gwarancji i nieodwołalnych linii kredytowych przypisuje się status bezwarunkowy ekspozycjom z tytułu kredytów bez klauzuli nieodwołalności przypisuje się status warunkowy operator z odpowiednimi uprawnieniami może zmieniać status każdej ekspozycji System będzie umożliwiał wyliczenie różnicy pomiędzy rezerwą wyliczoną zgodnie z PSR a odpisem/rezerwą wyliczoną zgodnie z MSR, a wartość wyliczonej kalkulacji będzie przechowywana w bazie Systemu na poziomie szczegółowości dla poszczególnych ekspozycji System posiada interfejs graficzny dedykowany obsłudze ww. działań. Rozpoznanie przychodów odsetkowych od należności z utratą wartości System posiada funkcjonalność wyliczania odsetek impairmentowych dla ekspozycji w przypadku których rozpoznano zdarzenie straty oraz dokonano odpisu wyznaczonego metodą indywidualną System posiada funkcjonalność wyliczania odsetek impairmentowych dla ekspozycji w przypadku których rozpoznano zdarzenie straty oraz dokonano odpisu wyznaczonego metodą kolektywną (z wyłączeniem portfela IBNR) Odsetki impairmentowe naliczane są od wartości odzyskiwalnej ekspozycji (tj. wartość księgowa brutto pomniejszona o wyliczony odpis) z zastosowaniem efektywnej stopy procentowej użytej do kalkulacji odpisu. System będzie przechowywał historyczne wartości wyliczeń odsetek impairmentowych na poziomie szczegółowości dla poszczególnych ekspozycji. System będzie umożliwiał wyliczenie różnicy pomiędzy odsetkami wyliczonymi zgodnie z PSR a odsetkami impairmentowymi wyliczonymi przez System (tzw. korekta odsetek impairmentowych (KOIM), gdzie KOIM to kumulatywna wartość różnicy pomiędzy wartością odsetek umownych i ESP naliczonych od momentu ostatniej kalkulacji odpisu a wartością odsetek impairmentowych naliczonych w tym okresie). System będzie przechowywał wartość wyliczonej różnicy (KOIM) w bazie Systemu na poziomie szczegółowości dla poszczególnych ekspozycji. System posiada funkcjonalność wyliczania odsetek impairmentowych oraz korekty odsetek impairmentowych na zadaną datę, np. koniec miesiąca, z uwzględnieniem zdarzeń które wystąpiły od ostatniego przeliczenia Strona 2 z 4 Czy wymagane TAK TAK TAK TAK Waga (Pn) TAK TAK TAK TAK TAK NIE TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK 4 TAK TAK TAK NIE NIE TAK TAK TAK TAK NIE TAK TAK TAK 3 3 3 NIE 10 NIE TAK TAK 10 TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK Załącznik nr 2 do OPZ - Wymagania szczegółowe Lp 11.8 11.9 12 12.1 12.2 12.3 12.3.1 12.3.2 12.3.3 12.3.4 12.4 12.5 12.5.1 12.5.2 12.5.3 12.5.4 12.5.5 12.5.6 12.5.7 12.5.8 12.6 13 13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 13.9 13.10 13.11 13.12 13.13 13.14 13.15 13.16 13.17 14 14.1 14.2 14.3 14.4 14.5 14.6 14.7 14.8 14.9 14.10 14.11 14.12 14.13 14.14 15 15.1 15.2 15.3 15.4 16 16.1 Funkcjonalności Systemu do obsługi MSR System posiada funkcjonalność wyliczania odsetek impairmentowych oraz korekty odsetek impairmentowych po wystąpieniu zdarzenia, np. zmiana efektywnej stopy procentowej System posiada interfejs graficzny dedykowany obsłudze ww. działań. Raporty System posiada możliwość uruchomienia i przeglądu raportów z poziomu interfejsu graficznego użytkownika 80% raportów generowanych przez System wykonuje się w czasie do 1 minuty System przedstawia zestawienie zbiorcze wszystkich obliczeń w podziale co najmniej: na portfele: IBNR, indywidualny, kolektywny na subportfele w portfelach IBNR, indywidualnym, kolektywnym na wybraną datę zapisaną w Systemu w porównaniu dla kilku data wybranych w Systemu System pozwala na raportowanie wartości przed i po obliczeniach System generuje raporty: -dotyczące rekoncyliacji danych dla KG: -zestawienie odpisów wg produktów -zestawienie odpisów wg metody oceny -zestawienie umów ocenianych indywidualnie z odpisem różnym od zera -raporty związane z rekomendacją R: -ekspozycje z przesłankami utraty wartości i zaksięgowanym odpisem -ekspozycje z przesłankami utraty wartości i bez zaksięgowanego odpisu -ekspozycje niezagrożone utratą wartości System umożliwia tworzenie przez użytkowników raportów ad-hoc z wykorzystaniem interfejsu graficznego Moduł księgowy System posiada moduł księgowy, który prowadzi ewidencję księgową danych wyliczonych w SK Moduł księgowy musi być zgodny z Ustawą o rachunkowości w zakresie wymaganym dla prowadzenia księgi pomocniczej System posiada słownik kont księgowych, na których prowadzona jest ewidencja księgowa wyliczonych w SK wartości i które są wykorzystywane do parametryzacji księgowań do KG Konto księgowe w Systemie to urządzenia księgowe, które musi być zgodne z zespołami wzorcowego planu kont dla Banków, służące do ewidencji operacji w porządku systematycznym System umożliwia zapisanie wprowadzonych/edytowanych wartości słownika kont System umożliwia prowadzenie kont bilansowych oraz wynikowych (gdzie obowiązuje zasada podwójnego zapisu) oraz kont pozabilansowych (dopuszczalny zapis operacji jednostronny /lub dwustronny, jeśli jednostronny nie jest dostępny) System musi zapewniać możliwość oznaczenia kont bilansowych, wynikowych, pozabilansowych (charakter konta) System musi zapewnić możliwość oznaczenia kont wynikowych jako przychody lub koszty System musi umożliwiać zdefiniowanie innych typów kont niż bilansowe, wynikowe, pozabilansowe (np. kont technicznych) System umożliwia przypisanie do konta księgowego wartości wyliczonej w SK, na podstawie jednego lub wielu atrybutów i zmiennych dostępnych w Systemie Przypisanie konta do wartości wyliczanej w SK jest realizowane za pomocą list wyboru, zawierających słowniki kont i opisu wartości wyliczonej w SK System musi umożliwiać automatyczne wykonywanie zapisów księgowych zgodnie z zdefiniowanymi zasadami w podziale na poszczególne ekspozycje System umożliwia, w procesie generowania księgowań do KG, definiowanie poziomu agregowania części wyników SK do poziomu konta księgowego, wg wybranych atrybutów (np. wg identyfikatora systemu źródłowego) wraz z jednoczesnym pozostawieniem pozostałych danych niezagregowanych System umożliwia definiowanie warunków z wykorzystaniem podstawowych operatorów logicznych i matematycznych System posiada interfejs graficzny dedykowany obsłudze ww. działań. System umożliwia wczytanie z pliku listy kont księgowych do słownika System będzie obsługiwał rozliczenie kosztów uzyskania przychodu dla celów podatkowych Interfejsy wyjściowe System będzie generował dane dla KG i BI do pełnych plików płaskich, o nazwach i formacie określonych w Fazie Analizy System umożliwia eksport wszystkich danych z zachowaniem identyfikatorów zawartych w danym źródłowych Plik(i) dla KG będą generowane zgodnie z Parametryzacją Plik(i) dla BI będą zawierały przynajmniej wynik kalkulacji wraz z przypisanym kontem księgowym oraz wartości wyznaczone w procesie kalkulacji System będzie umożliwiał operatorowi oznaczenie danych przeznaczonych do eksportu System umożliwia wielokrotne generowanie pliku zawierającego informacje dla KG i BI System umożliwia określenie ścieżki do katalogu w którym będą zapisywane pliki eksportu dla KG oraz osobno dla BI System będzie umożliwiał wielokrotne uruchomienie eksportu pliku dla KG i BI System będzie umożliwiał uruchomienie eksportu pliku dla KG dla wybranej daty danych System będzie zapisywał do logu informację o uruchomieniu eksportu danych do pliku dla KG Plik eksportu do KG, poza informacją o kontach księgowych i przypisanych im wartościom będzie zawierał identyfikatory systemów źródłowych, datę generowania pliku, oraz unikalny numer wersji eksportu. System posiada interfejs graficzny dedykowany obsłudze ww. działań. System powinien posiada definiowania przez użytkownika danych do nowych źródeł danych takich bazy danychponiższe i/lub pliki w formacie csv, txt, xls. System posiadać możliwość integracji zzakresu KG z wykorzystaniem Szynyzewnętrznych ESB Zamawiającego i musi spełniać wszystkie wymagania: - System umożliwia wymianę danych za pomocą interfejsu Web Service zgodny z WSDL 1.1 w standardzie Document/litera - żądania muszą przychodzić w standardzie SOAP 1.1/1.2 (wybór na etapie analizy), - wszystkie przesyłane struktury (XML) muszą być opisane w WSDL; zalecane opisanie restrykcji dla danych typu tekstowego oraz liczbowego - wszystkie przesyłane dane, muszą być zgodne z typem opisanym w WSDL, - nazwy parametrów/atrybutów muszą być krótkie, zapewniające minimalizację nadmiarowości komunikatów XML, - Web Service wykorzystuje niegeneryczne metody, parametry wywołań oraz wartości zwracane (za wyjątkiem tych, w których brak generyczności - obniżyłby funkcjonalność silnika ratingowego wymaganą przez Zmawiającego), - wszystkie metody w Web Service muszą zwracać jednoznaczny status a w przypadku wystąpienia błędu wyjątek powiązany z daną metodą, - zwracane wyjątki są opisane w WSDL (dedykowane dla danej metody Web Service lub wspólne), - wszystkie typy danych typu tekstowego oraz liczbowego muszą mieć opisane restrykcje (w tym typy generyczne), - każdy wyjątek musi zawierać co najmniej: kod błędu, charakter błędu, komunikat błędu (musi w sposób jednoznaczny i zrozumiały opisywać błąd, tak by bez dodatkowego nakładu pracy zidentyfikować dokładną przyczynę jego powstania), Uprawnienia System umożliwia przypisane poszczególnych funkcjonalności Systemu do zdefiniowanych Ról użytkowników (Zamawiający przewiduje, iż System będzie wykorzystywał role użytkowników opisane w OPZ) System jest zintegrowany z serwerem LDAP Zamawiającego (Microsoft Active Directory) w ten sposób, że Role w Systemie będą mapowane na grupy użytkowników zdefiniowane LDAP Zamawiającego Użytkownik może posiadać więcej niż jedną Rolę (być przypisanym do wielu grup LDAP) System posiada interfejs graficzny dedykowany obsłudze ww. działań. Licencje Wykonawca zapewni aktualizacje programów, poprawki i ostrzeżenia o zagrożeniach bezpieczeństwa, 16.2 Wykonawca zapewni certyfikację Systemu w trakcie trwania umowy serwisowej dla nowych wersji produktów innych firm (Oprogramowania) wykorzystywanych przez Aplikację, Wykonawca zapewni licencje na użytkowanie i kopiowanie nowych wersji, aktualizacji i poprawek do Oprogramowania wykorzystywanego przez Aplikację z wyjątkiem elementów oprogramowania dostarczanego przez Zamawiającego. Zamawiający wymaga nieograniczonego prawnie i technicznie dostępu do korzystania z danych gromadzonych przez System, z wykorzystaniem standardowych dla bazy danych 16.4 metod, narzędzi i języka SQL. 17 Bezpieczeństwo System będzie rejestrował i umożliwiał przeprowadzenie analiz logowania użytkowników do Systemu, zarówno lokalnie przez osoby odpowiedzialne za pracę tych aplikacji, jak i 17.1 poprzez wysyłanie tych logów do centralnego systemu gromadzenia i przetwarzania logów (SIEM) ) i analizę pod kątem możliwości wystąpienia incydentów naruszenia bezpieczeństwa środowiska teleinformatycznego. 16.3 Czy wymagane TAK TAK TAK NIE NIE NIE NIE NIE TAK TAK TAK TAK TAK TAK TAK TAK TAK NIE 10 TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK NIE NIE 4 6 TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK NIE 8 NIE 10 TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK 17.3 TAK Strona 3 z 4 2 2 2 2 2 TAK TAK 17.2 Logi generowane w poszczególnych elementach Systemu powinny być gromadzone lokalnie, niezależnie od procesu przesyłania logów do centralnego systemu SIEM Logowanie/rejestrowanie zdarzeń powinno być tak skonfigurowane, aby umożliwiać dostęp lokalny do zarejestrowanych zdarzeń przez okres co najmniej tygodniowy 17.4 W zależności od platformy systemowej ,gromadzone będą 17.4.1 logi systemowe Unix/Linux OS 17.4.2 logi messages, syslog, sulog z działania usługi cron 17.4.3 logi systemowe Windows OS 17.4.4 logi Security, Application i System 17.5 Log będzie zawierał następujące parametry zdarzeń: 17.5.1 czas zdarzenia z dokładnością co najmniej do 1 sekundy lub większą, zgodnie z dokładnością dostarczaną przez poszczególne platformy/technologie; 17.5.2 miejsce wygenerowania zdarzenia - nazwa/identyfikator systemu, adres IP; 17.5.3 element systemu generujący log – nazwa/identyfikator aplikacji/programu/procesu; 17.5.4 nazwa/identyfikator użytkownika/właściciela aplikacji/programu/procesu powiązanego ze zdarzeniem; 17.5.5 nazwa/identyfikator obiektu, który został zmodyfikowany lub do którego nastąpił dostęp; opis zdarzenia zawierający niezbędne informacje o zdarzeniu, w zależności od jego rodzaju, w szczególności informacje umożliwiające zapewnienie rozliczalności działań 17.5.6 użytkowników 18 Monitorowanie Systemu 18.1 System będzie posiadał mechanizm służący do monitorowania Systemu oraz połączeń Systemu 18.2 Mechanizm monitorowania Systemu musi zapewnić: 18.2.1 możliwość monitorowania liczników wydajnościowych, określonych przez Wykonawcę 18.2.2 możliwość weryfikacji dostępności serwisów w kontekście użytkownika/systemu końcowego. 18.2.3 możliwość diagnostyki wydajności systemu 18.2.4 możliwość tworzenia raportów wydajnościowych oraz raportów pokazujących dostępność aplikacji w zadanym w parametrach raportu zakresie czasowym możliwość zintegrowania z systemami monitoringu posiadanymi przez Bank, tj. Naios oraz MS SCOM przynajmniej w postaci interfejsu programistycznego (API lub 18.2.5 WebService) po stornie aplikacji, dającego możliwość pobrania danych wydajnościowych Waga (Pn) TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK TAK Załącznik nr 2 do OPZ - Wymagania szczegółowe Lp 18.3 19 19.1 19.2 19.3 Funkcjonalności Systemu do obsługi MSR Wykonawca musi umożliwić Zamawiającemu wdrożenie lub dostarczyć gotowe rozwiązanie pozwalające na niezależne od Wykonawcy monitorowanie systemowych parametrów poziomu świadczenia Usługi Bieżącego Utrzymania, w szczególności pomiar dostępności, pojemności i ciągłości systemu. Rozwiązanie to będzie wykorzystywane przez Zamawiającego. Zamawiający posiada system monitorowany oparty o oprogramowanie Nagios. Minimalnym wymaganiem jest udostępnienie testowego użytkownika umożliwiającego logowanie do aplikacji i wykonania operacji potwierdzającej prawidłowe działanie systemu lub dostarczonej usługi. Eksploatacja i opis architektury: Wymagane jest rozdzielenie zarządzania technicznego Systemem od zarządzania parametryzacją merytoryczną Systemu, konfiguracją przebiegiem procesów, dostępem do danych merytorycznych, System musi zapewnić audytowalność wprowadzanych zmian, poufność, autoryzację i niezaprzeczalność realizacji usług, Poszczególne elementy składające się na konfigurację Systemu (np. pliki konfiguracyjne, biblioteki, skrypty) muszą być oznaczone w sposób jednoznaczny (wersjonowanie kolejnych zmian elementów konfiguracji), pozwalający na wycofanie nietrafnej zmiany lub korekty Systemu, 19.4 19.5 19.6 19.7 19.8 19.9 19.10 20 20.1 System musi mieć możliwość przełączania automatycznego między środowiskiem podstawowym i zapasowym z wykorzystaniem serwisów klastrowych Microsoft, System musi umożliwiać wprowadzanie parametrów technicznych wymaganych do poprawnej pracy aplikacji użytkownikom przypisanym do określonej roli, Wymagane parametry oraz ich wartości muszą być opisane w dokumentacji eksploatacyjnej Systemu, Pola wartości parametrów muszą posiadać kontrolę formatu i wartości danych wprowadzanych dla danego parametru, Instalacja, aktualizacja lub wgranie poprawek do Systemu musi być możliwa do wykonania przez użytkowników przypisanych do określonych ról, Znane błędy które mogą wystąpić podczas aktualizacji powinny być opisane w dokumentacji, Wykonawca będzie rekomendował Zamawiającemu instalację przetestowanych uaktualnień Oprogramowania, Opis komunikacji zdarzeń (alertowanie): Podstawowe funkcjonalności w zakresie komunikacji zdarzeń: System posiada możliwość informowania użytkowników o wystąpieniu zdarzeń z wykorzystaniem komunikatów ekranowych oraz e-maili wysyłanych do określonej grupy 20.2 odbiorców, Zdarzenia związane z obsługą Systemu poprzez interfejs graficzny, w szczególności wpływające na prawidłowe działanie Systemu, Parametryzacji i elementów powiązanych 20.3 (zmiana, usunięcie, import, eksport) muszą być poprzedzone stosownym komunikatem wymagającym od użytkownika potwierdzenia lub umożliwiającym anulowanie operacji, 20.4 Istnieje możliwość konfigurowania/definiowania przez użytkownika: 20.4.1 klasyfikacji komunikatów (techniczny, biznesowy), 20.4.2 kategorię komunikatu (błąd krytyczny, błąd procesowy, ostrzeżenie, informacja), 20.4.3 grupy odbiorców komunikatów z zależności o klasyfikacji komunikatu, 20.4.4 treści komunikatu, 20.4.5 wymagana jest możliwość konfigurowania zdarzeń, które powodują przesłanie określonego komunikatu e-mailem i/lub SMS, Strona 4 z 4 Czy wymagane Waga (Pn) TAK TAK TAK TAK TAK TAK TAK TAK TAK NIE TAK 2 TAK TAK NIE NIE NIE NIE TAK 3 3 3 3