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