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

Podobne dokumenty