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

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