Załącznik nr 1 do RFP

WYMAGANIA W ZAKRESIE DOSTAWY, WDROŻENIA I SERWISU SYSTEMU FRONT OFFICE W BANKU OCHRONY ŚRODOWISKA S.A.

A. WYMAGANIA FUNKCJONALNE

Poniżej przedstawione są wymagania funkcjonalne w podziale na grupy:

Grupa I – wymagania funkcjonalne z obszaru pulpitu użytkowników oraz rejestracji transakcji,Grupa II – wymagania funkcjonalne z zakresu zarządzania pozycją płynnościową,Grupa III – wymagania funkcjonalne z obszaru zarządzania pozycją walutową,Grupa IV – wymagania funkcjonalne z obszaru zarządzania pozycją papierów wartościowych oraz stopą

procentową,Grupa V – wymagania funkcjonalne z obszaru obliczania wyniku spekulacyjnego FX,Grupa VI – wymagania funkcjonalne z obszaru obliczania wyniku na stopie procentowej,Grupa VII – wymagania funkcjonalne z zakresu zarządzania transakcjami klientowskimiGrupa VIII – wymagania funkcjonalne z obszaru zarządzania limitami kontrahenta oraz emitenta,Grupa IX – wymagania funkcjonalne z obszaru zarządzania i monitorowania ryzyka rynkowego,Grupa X – wymagania funkcjonalne z obszaru raportowania regulacyjnegoGrupa XI – wymagania dodatkowe z zakresu działania systemu.Grupa XII - Autodealing (opcjonalnie)

B. WYMAGANIA INTEGRACYJNEC. WYMAGANIA TECHNICZNE I TECHNOLOGICZNED. WYMAGANIA W ZAKRESIE WDROŻENIA

Strona 1 z 2

Słownik pojęć wykorzystywanych w dokumencie

Nazwa Opis Kontrahent Bank, instytucja finansowa będąca stroną transakcji, emitent papierów

wartościowych i CCP(Central Counterparty [kontrahent centralny])Klient Klient korporacyjny Banku obsługiwany przez Biuro Projektów

Strukturalnych(BPS)Dane rynkowe Dane dot. krzywych stóp procentowych, cen obligacji, kursów walutowych,

stawek referencyjnych. VaR Miara mówiąca o tym jaką maksymalną stratę w danym horyzoncie czasowym,

na zadanym poziomie ufności, Bank może ponieść na otwartych pozycjach wrażliwych na zmiany czynników rynkowych.

BPV Miara pokazująca jak zmieni się wycena transakcji przy zmianie stóp procentowych o 1 p.b.

Pozycja walutowa

Pozycja walutowa w każdej walucie wynikająca z otwartej pozycji walutowej Banku wg stanu na koniec dnia poprzedniego oraz wszystkich transakcji realizowanych w ciągu dnia przez dealera międzybankowego (w tym transakcji realizowanych na rynku międzybankowym oraz transakcji z dealerami klienta niebankowego) oraz pozycji oddziałowej

Pozycja walutowa oddziałowa

Pozycja walutowa w każdej walucie wynikająca z salda transakcji realizowanych w oddziałach/Centrach Korporacyjnych Banku (transakcje oddziałowe) lub innych operacji związanych z korektami księgowymi m.in.: dot. rezerw

Pozycja walutowa Banku

Pozycja walutowa w każdej walucie wynikająca z otwartej pozycji walutowej Banku wynikająca ze wszystkich transakcji (w tym międzybankowych oraz np. korekt księgowych). Pozycja walutowa Banku jest sumą pozycji dealerskiej i oddziałowej.

Pozycja całkowita

Maksimum z sum długich i krótkich pozycji netto we wszystkich walutach.

Def3000/TR System do obsługi transakcji w Back Office . Zintegrowany z systemami wewnętrznymi (główny system transakcyjny, księga główna, hurtownia danych), jak i zewnętrznymi (rozliczenia płatności i potwierdzeń, wyciągi, rozliczenia z depozytariuszem). Dostawcą jest firma Asseco Poland S.A.

Def3000/CL System rozliczający typu Payment Hub obsługujący płatności przychodzące i wychodzące Banku. Będacy interfejsem między systemami wewnętrznymi banku, a różnymi izbami rozliczeniowymi. Przetwarza (STP) komunikaty płatnicze SEPA, SWIFT, TARGET2 oraz SORBNET2 , płatności natychmiastowych, w szczególności płatności KIR-SRPN (Express Elixir). Dostawcą jest firma Asseco Poland S.A.

AM Administrator Merytoryczny, użytkownik z uprawnieniami do edycji parametrów systemu

DFO Departament Ryzyka Finansowego i OperacyjnegoBPS Biuro Projektów StrukturalnychDFA Departament Rynków Finansowych i AnalizNostro Monitor

Narzędzie informatyczne prezentujące saldo rachunków Nostro posiadanych przez Bank

Strona 2

Cel implementacji i funkcje systemu Front Office

System umożliwia ewidencjonowanie transakcji, utrzymywanie, monitorowanie i wycenę pozycji, informowanie o pozycji walutowej i stopy procentowej na tle obowiązujących limitów, pozwala na zarządzanie płynnością bieżącą, kalkulację wyniku, symulacje zmiany pozycji oraz wyniku, zarządzanie pozycją stopy procentowej, zasilanie danymi rynkowymi, obsługę limitów klientowskich oraz kontrahenta, komunikację poprzez odpowiednie interfejsy z powszechnie stosowanymi na rynku finansowym systemami, platformami tradingowymi oraz systemami wewnętrznymi Banku niezbędnymi do spełnienia wymagań względem systemu Front Office.

System obsługuje poniższe rodzaje instrumentów: FX Spot, Fx Forward, FX NDF, FX Swap, FX NDF SWAP, FX Options Lokaty, depozyty, REPO (zawierające również Cross Currency REPO), REVERSE REPO, Buy Sell Back, Sell Buy

Back IRS, Basis swap, CIRS, FRA, OIS, Obligacje skarbowe (stałokuponowe, zmiennokuponowe, zerokuponowe, indeksowane), bony skarbowe,

bony pienieżne, obligacje korporacyjne, emisje własne Linie kredytowe, pożyczki od instytucji finansowych

Raportowanie Generowanie raportów dotyczących danych o kontrahentach, zawartych transakcjach, ich wycenie, wykorzystania poszczególnych rodzajów limitów, w podziale na portfele, waluty i typy transkacji.Zapewnienie przechowywania historii zmian dokonanych na transakcjach, informacji o pierwotnej transakcji oraz przeprowadzonych modyfikacjach (np. zmiana nominału, stopy procentowej, kursu, dat itd.)

Import/eksport danychSystem umożliwi eksport/import:- danych o transakcjach- danych nt. wykorzystania limitów oraz wyliczanych wyników- innych wymaganych wyników/pozycji

Kontrola limitówAutomatycznie wyświetlane alerty dotyczące przekroczenia limitów w czasie rzeczywistym oraz przekroczenia dozwolonych paramentów transakcji.Raport podsumowujący dane o alertach wystosowanych w ciągu dnia.

Strona 3

A. WYMAGANIA FUNKCJONALNE

Grupa I - wymagania funkcjonalne z obszaru pulpitu użytkowników oraz rejestracji transakcji

Pulpit dealerski

L.p. Wymaganie Opis wymagań oczekiwanych od systemu1. Elementy pulpitu

dealera FX SpotPulpit zawierający w szczególności: Pozycję walutową w podziale na waluty Bieżące wykorzystanie limitów pozycji walutowej Bieżące wykorzystanie limitów kontrahenta(możliwość sprawdzenia

limitów danego kontrahenta oraz sprawdzenia wykorzystania limitów wszystkich kontrahentów z możliwością sortowania (wg np. bieżącego obciążenia)

Prezentację transakcji z uwzględnieniem podziału na typ i podtyp oraz transakcje pending

Monitoring FX VaR Prezentacja wyników FX dzienny, miesięczny, roczny (Year to Date) – w

odniesieniu do aktualnych kursów oraz aktualnego fixingu (opcjonalnie)

2. Elementy pulpitu dealera Fixed Income

Bieżące wykorzystanie limitów kontrahenta(możliwość sprawdzenia limitów danego kontrahenta oraz sprawdzenia wykorzystania limitów wszystkich kontrahentów z możliwością sortowania (wg np. bieżącego obciążenia)

Pozycja w papierach wartościowych (portfel tradingowy) z funkcją drill down (do poziomu transakcji).

Bieżąca pozycja BPV w podziale na papiery wartościowe i instrumenty pochodne, tenory, rodzaje krzywych, ze względu na walutę pozycji)

Bieżące wykorzystanie limitów BPV i VaR Bieżąca wycena transakcji portfela handlowego stopy procentowej Prezentację transakcji pending Prezentacja wyniku zrealizowanego (opcjonalnie) Koszt finansowania Możliwość zestawienia historycznych/dziennych zmian (wyceny

transakcji portfela handlowego, wyniku zrealizowanego, kosztów finansowania) od wybranej daty lub okresu dzienny, miesięczny, roczny w podziale na papiery wartościowe i instrumenty pochodne (opcjonalnie)

3. Elementy pulpitu dealera księgi bankowej

Pozycja w papierach wartościowych w podziale na portfele (Held to Collect and Sell oraz Held to Collect)

Bieżąca pozycja BPV w podziale na rodzaj papierów wartościowych oraz tenory

Bieżące wykorzystanie BPV dla papierów wartościowych w podziale na portfele (Held to Collect and Sell oraz Held to Collect)

Raport przepływów pieniężnych dla transakcji skarbowych w rozbiciu na walutę, poszczególne dni oraz tenory, z funkcją drill down (do poziomu transakcji)

Narzędzie do podglądu salda rachunków Nostro: podgląd salda bieżącego oraz z projekcji sald na minimum 5 dni roboczych (za pomocą interfejsu z Def3000/CL).

Wynik dzienny, miesięczny, roczny(Year to Date) w podziale na

Strona 4

papiery wartościowe i instrumenty pochodne, zrealizowany i niezrealizowany, dochód odsetkowy i koszt finansowania (opcjonalnie)

Bieżące wykorzystanie limitów kontrahenta(możliwość sprawdzenia limitów danego kontrahenta oraz sprawdzenia wykorzystania limitów wszystkich kontrahentów z możliwością sortowania (wg np. bieżącego obciążenia)

4. Pulpit dealera klientowskiego

Pulpit zawierający w szczególności: Blotter - wykaz transakcji zawartych w czasie rzeczywistym z podziałem

na typy transakcji - z wyszczególnieniem marży Wynik z tytułu marży za zadany okres (dzienny, miesięczny, roczny) w

podziale na pojedynczą transakcje, instrumenty, Klienta (opcjonlanie) Pozycja walutowa klienta na daną datę – prezentacja listy transakcji

składowych (opcjonalnie) Informacje o wybranym kontrahencie niebankowym, w szczególności

hasło identyfikacyjne, wykaz pełnomocników wraz z numerami telefonicznymi, wykaz podpisanych umów, kod LEI (możliwość importu danych z Def3000/TR).

Informacje o parametrach transakcji klientowskich typu średnia marża, aktywność, wolumen transakcji w walucie bazowej i kwotowanej (za wybrany okres),

Informacja dla wybranego kontrahenta na temat limitów, ich obciążenia oraz data ważności limitów

Prezentacja transakcji pending i simulated.5. Pulpit dealera

klientowskiego - Alerty

Automatycznie wyświetlane alerty dotyczące: przekroczenia limitu wynik na transakcji widoczny na fiszce przed jej zwalidowaniem. Ostrzeżenie przed wprowadzeniem transakcji z ujemną marżą. Ostrzeżenie przed zastosowaniem niestandardowego odchylenia od

rynku międzybankowego w warunkach transakcji (opcjonlanie) Ostrzeżenie przed wprowadzeniem daty waluty wcześniejszej niż data

zawarcia transakcji lub w dniu nie roboczym lub w dacie wykraczającej poza dostępny limit.

nieaktywnego kodu LEI przekroczenie dozwolonych paramentów transakcji generowanie raportów dotyczących: wykorzystania limitów kontrahenta w podziale np. na kontrahenta,

walutę czy kraj. wyniku na poszczególnym instrumencie, kliencie, użytkowniku

systemu w określonym zakresie czasowym.

Pulpit pracownika ryzyka finansowego

L.p. Wymaganie Opis wymagań oczekiwanych od systemu6. Konfiguracja

domyślnego pulpitu

Możliwość skonfigurowania własnego pulpitu użytkownika, w szczególności: wyświetlanie aktualnych wyników VAR, BPV, pozycja walutowa, wybranych ekspozycji limitów na tle limitów.

7. Alerty System automatycznie będzie wyświetlał alerty dotyczące przekroczenia limitu/limitów

8. Powiadomienie W sytuacji wystąpienia przekroczenia następuje wysłanie informacji do

Strona 5

email o przekroczeniu (Opcjonalnie)

zdefiniowanej listy adresatów email wraz ze szczegółami.

Rejestracja transakcji

L.p. Wymaganie Opis wymagań oczekiwanych od systemu9. Konfiguracja

trade ticketDla transakcji rejestrowanej manualnie, możliwość utworzenia szablonu trade ticket’u z automatycznie uzupełnianymi domyślnymi danymi transakcyjnymi np. typem transakcji, numerem referencyjnym, walutą/walutami, rachunkiem rozliczeniowym (SSI), datą rozliczenia transakcji, datą zapadalności transakcji, itp.Rejestracja transakcji zgodnie z wymaganymi prawnie danymi dotyczącymi EMIR,MIFID II (APA, ARM), SFTR (szczegółowy opis wymagań zawiera „Grupa X - wymagania funkcjonalne z obszaru raportowania regulacyjnego” )

Dla transakcji z kontrahentem niebankowym przenoszonych na księgę handlową (obecnie są to transakcje FX Spot, FX Forward, IRS), wprowadzanie kursu referencyjnego jako podstawy do obliczania marży wg algorytmu.

System ma umożliwiać wprowadzanie punktów swap (dla transakcji FX Forward z kontrahentem niebankowym) z desku międzybakowego do desku sales.

10. Import transakcji

Dla transakcji zawieranych w zewnętrznych systemach transakcyjnych i na platformach, automatyczny import transakcji do systemu F/O w czasie rzeczywistym.

Import z systemów tradingowych: Refinitiv(Thomson Reuters) w szczególności FXTrading, Bloomberg oraz platform w szczególności Goldman Sachs, Barclays, BNP, DB- Autobahn, CitiVelocity, Credit Agricole, Societe Generale.

11. Funkcje rejestracji transakcji

Funkcja: copy ticket, wskazania do rozliczenia dowolnego rachunku z wszystkich rachunków

Kontrahenta automatyczne wyliczanie liczby dni transakcji, automatyczne wyliczanie wyniku na transakcji z Kontrahentem

niebankowym względem kursu referencyjnego obsługa transakcji pending i simulated przy wprowadzaniu transakcji będzie możliwe wykonanie symulacji

wykorzystania limitów12. Dodawanie pól

do „trade ticketów” (opcjonalnie)

Dodawanie nowych pól do formatek transakcji (np. na potrzeby raportowania EMIR, MIFID II, SFTR, MIFIR).

Możliwość przesłania dodanych pól przez interfejs danych do def3000/TR. 13. Transakcje

pending (TP) dla typu transakcji FX Spot, IRS, papiery wartościowe

Transakcje te będą zastępowały tymczasowo realne transakcje FX Spot, FX Forward, IRS oraz papiery wartościowe które z jakiejś przyczyny nie mogą być jeszcze ostatecznie zarejestrowane. Ich zatwierdzenie przez dealera nastąpi w terminie późniejszym po uzupełnieniu brakujących danych, przy czym transakcje pending mają wpłynąć na pozycję walutową oraz stopy procentowej (utylizacja limitów) do czasu zatwierdzenia transakcji w systemie

Strona 6

przez dealera.14. Transakcje

symulowane Transakcje symulujące – mają na celu próbne wprowadzenie transkacji i sprawdzenia zachowania się pozycji/limitów.

Możliwość wprowadzenia kilku transakcji symulowanych i sprawdzenia wpływu na limity/pozycję/wyniki/VAR/BPV biorąc pod uwagę wszystkie transakcje symulowane (opcjonlanie).

15. Zmiany warunków transakcji

Modyfikowanie warunków transakcji: częściowe skracanie, wydłużanie, całkowity lub częściowy unwinding.

16. Transakcje referencyjne

Możliwość rejestracji transakcji referencyjnych do transakcji klientowskich np. w celu transferu pozycji na księgę handlową.Takie przejęcie powinno odbywać się po kursie referencyjnym, pobieranym automatycznie lub wpisywanym ręcznie (w zależności od wyboru przez Bank opcji zasilania danych rynkowych w ciągu dnia). Kurs referencyjny dotyczy stopy stałej przejmowanej transakcji.

Transakcje referencyjne powinny być tworzone automatycznie dla zdefiniowanych typów transakcji pochodnych (obecnie IRS) i zdefiniowanego przy oryginalnej transakcji kursu referencyjnego (stopa stała) – opcjonalnie.

17. Market Rate Conformity (opcjonalnie)

Informowanie podczas wprowadzania transakcji o niezgodności wprowadzanej ceny z aktualną ceną rynkową lub odpowiednim algorytmem.

18. Prowizje brokerskie

Konfiguracja prowizji brokerskich wg stworzonego algorytmu lub manualnie oraz wyliczanie kosztów brokerskich w podziale na transakcje i brokera i typ instrumentu

19. Eksport/Import danych

Eksport/import danych z programu Excel, w szczególności przepływów w transakcjach IRS i CIRS

20. Kwotowania od dealerów międzybankowych dla dealerów klientowskich(opcjonalnie)

System ma umożliwiać kwotowanie/streaming cen (FX spot) oraz kwotowania punktów swap(do forwardów z klientami) z desku międzybankowego dla desku sales. Dealer klientowski nie ma możliwości zmiany otrzymanego kwotowania. Możliwość korekty kwotowania posiada wyłącznie daeler międzybankowy.

21. Rejestracja transakcji REPO/REV REPO

System powinien posiadać możliwość rejestracji transakcji REPO/REV REPO z wpisaniem zabezpieczenia w postaci różnych papierów dłużnych

22. Daty Informowanie podczas wprowadzania transakcji o niezgodności wprowadzonych dat ( data waluty wcześniejsza niż zawarcia transakcji, dni świąteczne w różnych walutach, data poza limitem).

Rejestracja kontrahenta

Rejestracja (pierwotna) kontrahentów odbywa się w systemie def3000/TR.System F/O inicjuje import danych statycznych kontrahentów zarejestrowanych w def3000/TR.

Strona 7

Wybrane dane wymagane na poziomie rejestracji kontrahenta: nazwa długa, nazwa krótka ,BIC code przy bankach, numer wewnętrznie nadawany w Banku (modulo), kod LEI, typ kontrahenta, rachunki rozliczeniowe, profil MIFiD klienta, nazwisko pełnomocnika, numer telefonu, hasło, miejsce na notatkę/komentarz.

System ma umożliwiać usunięcie (w formie anonimizacji zgodnej z RODO) danych klientów po 5 latach od zakończenia świadczenia usługi poprzez zastąpienie wszystkich informacji o kliencie na kartotece klienta w systemie F/O

Grupa II – wymagania funkcjonalne z zakresu zarządzania pozycją płynnościową Banku

L.p. Wymaganie Opis wymagań oczekiwanych od systemu1. Informacja dot.

Płynności krótkoterminowej

Prezentację bieżącej prognozy sald na koniec dnia wszystkich rachunków Nostro w rozbiciu na poszczególne rachunki, z możliwością podglądu wszystkich przepływów na rachunkach w podziale na typy przepływów (m. in. przepływy wynikające z transakcji Money Market, FX SWAP, FX SPOT, na papierach wartościowych, Elixir, SEPA, transakcje wysokokwotowe(Sorbnet2), KDPW, transakcje z NBP itd.))

Dodatkowo oprócz danych transakcyjnych by pobierał dane zewnętrzne importowane z Def3000/CL (interfejs opisane w sekcji wymagania integracyjne.

Możliwość manualnego wprowadzenia kwot w systemie nie będących realnymi transakcjami (wraz ze zdefiniowanymi przez Bank podtypami).

Grupa III - wymagania funkcjonalne z obszaru zarządzania pozycją walutową

L.p. Wymaganie Opis wymagań oczekiwanych od systemu1. Waluty Sparametryzowanie walut obsługiwanych przez Bank.2. Pozycja walutowa Pozycja walutowa wyznaczana na bieżąco w systemie FO. Pozycja

tworzona będzie zarówno z transakcji wprowadzanych bezpośrednio do systemu FO przez dealerów (transakcje: międzybankowe, klientowskie, pending) jak i transakcji importowanych poprzez interfejs z systemu Def3000/CP (import transakcji opisany w pkt III.4).

Transakcje oddziałowe zawarte po godzinach pracy dealera będą wprowadzane rano ręcznie do systemu w celu wyrównania pozycji walutowej widzianej w systemie z poprzedniego dnia i pozycji całkowitej Banku.

Transakcje FX importowane z Def3000/CP powinny otrzymać kurs referencyjny z aktualnego kwotowania rynkowego (dostępnego poprzez powiązanie FO z np. Refinitiv(Reuters) z uwzględnieniem korekty tej stawki o odpowiedni wskaźnik/procent wpisywany w parametryzacji do systemu.

Pozycja walutowa będzie pokazywana dla wyznaczonych walut jak i dla grup (np. pozostałe waluty, wszystkie waluty razem). Raport pozycji walutowej powinien być dostępny w podziale na waluty oraz w przeliczeniu na PLN dla potrzeb określenia obciążenia limitów, które będą mogły być wyrażone w PLN oraz w walucie.

Strona 8

3. Raportowanie Możliwe będzie generowanie raportów dotyczących aktualnej pozycji walutowej wraz z podziałem na walutę oraz wielkość limitu.System umożliwi eksport wyników raportów do Excel.

4. Importowanie z Def3000/CP (opcjonalnie)

Transfer pozycji oddziałowej następuje w czasie rzeczywistym poprzez interfejs z systemu Def3000/CP do systemu F/O. Transfer następuje automatycznie w parametryzowanych godzinach pracy dealera.

5. Limity Wartość limitu podawana dla każdego rodzaju pozycji w podziale na waluty lub grupy walut. System powinien obługiwać zarówno limit podany w walucie, jak i w przeliczeniu na PLN (na PLN opcjonalnie).

Pozycja walutowa przy liczeniu ekspozycji na tle limitu jest przeliczana na PLN po kursie fixingowym dnia poprzedniego.

System umożliwi prowadzanie następujących typów limitów otwartych pozycji walutowych: limit całkowitej otwartej pozycji walutowej Banku uwzględniający

wszystkie waluty w przeliczeniu na PLN (opcjonalnie) limit otwartej pozycji walutowej w każdej walucie limit otwartej pozycji walutowej dla określonej grupy walut

(opcjonalnie) system umożliwi tworzenie nowych i edycję grup walut, objętych

jednym limitem (opcjonalnie)6. Pozycja walutowa

w grupie walut (opcjonalnie)

Na podstawie pozycji walutowych w poszczególnych walutach, system automatycznie (po wyznaczeniu pozycji w poszczególnych walutach) wyznacza pozycję walutową w grupach walut, dla których zdefiniowane zostały limity. Pozycja walutowa obejmująca więcej niż jedną walutę wyznaczana jest jako większa z dwóch wartości: sumy długich pozycji w poszczególnych walutach i sumy krótkich pozycji w poszczególnych walutach.

7. Pozycja walutowa całkowita we wszystkich walutach razem (opcjonalnie)

Na podstawie pozycji walutowych we wszystkich walutach, system automatycznie (po wyznaczeniu pozycji w poszczególnych walutach) wyznacza pozycję walutową we wszystkich walutach. Pozycja walutowa wyznaczana jest jako większa z dwóch wartości: sumy długich pozycji w poszczególnych walutach i sumy krótkich pozycji w poszczególnych walutach.

Grupa IV – wymagania funkcjonalne z zakresu zarządzania pozycją papierów wartościowych oraz stopy procentowej

L.p. Wymaganie Opis wymagań jakie oczekiwanych od systemu1. Blokada papierów Blokowanie wskazanych papierów wartościowych (np. pod linie

finansujące, REPO, itd.) wraz z określonym systemem kolejkowania FIFO lub Ceny Średniej

2. Kolejkowanie sprzedawanych papierów

Wybór sposobu sprzedaży papierów wartościowych: FIFO, Cena Średnia.

Umożliwienie symulacji zmiany wyniku na wybranym portfelu przy uwzględnieniu kolejkowania papierów.

3. Operacje na papierach wartościowych

Dokonywanie operacji typu Buy Sell Back, Sell Buy Back, Repo, Reverse Repo (z przemieszczeniem papierów oraz bez przemieszczenia) z zachowaniem wybranego sposobu sprzedaży (odpowiedniego

Strona 9

kolejkowania sprzedawanych papierów).4. Emisje Własne Rejestracja i zarządzanie pozycją emisji własnych Banku (również z opcją

call).5. Wycena papierów

wartościowychWycena papierów wartościowych zgodnie z MSSF 9 (np. bezpośrednie kwotowanie rynkowe, wg ESP.

6. ESP(Efektywna Stopa Procentowa)

System umożliwi wycenę instrumentów finansowych w skorygowanej cenie nabycia.

7. Symulacja wyniku portfela

Umożliwienie symulacji zmiany wyniku na wybranym portfelu/transakcjach z zachowaniem kolejkowania papierów wg FIFO (z uwzględnieniem istniejących blokad na papierach wartościowych).

Grupa V - wymagania funkcjonalne z obszaru obliczania wyniku FX (opcjonalnie)

L.p. Wymaganie Opis wymagań oczekiwanych od systemu1. Wyliczenie wyniku FX Wynik dzienny wyznaczany w czasie rzeczywistym na transakcjach wg

wskazanego przez Bank algorytmu.

Wynik na koniec dnia – generowany automatycznie wg zadanych przez użytkownika parametrów i wskazanego przez Bank algorytmu.

System umożliwi wyliczenie wyniku obliczając go w odniesieniu do: aktualnego kursu rynkowego, fixingu z dnia dzisiejszego (kurs fixingowy będzie znany danego dnia dopiero po godzinie 11:00).

2. Podział wyniku FX System powinien prezentować i wyliczać wyniki w podziale na: typ transakcji waluty umożliwi wyodrębnienie wyniku na każdej transakcji

W przypadku pozycji wynikających z transakcji zawartych w dniach poprzednich, drill down może być ograniczony do waluty.

3. Raportowanie Możliwe będzie generowanie raportów dotyczących aktualnego wyniku FX, pozycji walutowej w wymienionych podziałach.System umożliwi eksport wyników raportów do Excel.

Grupa VI - wymagania funkcjonalne z obszaru obliczania wyniku na stopie procentowej (opcjonalnie)

L.p. Wymaganie Opis wymagań oczekiwanych od systemu1. Prezentacja

wyników Prezentacja wyników „w ciągu dnia” oraz za dany okres w zakresie stopy procentowej w podziale na:

typ transakcji, łącznie z transakcjami „referencyjnymi” w przypadku papierów dłużnych w podziale na nazwę papieru kategorie 'w ciągu dnia' oraz 'na koniec dnia' na poziomie

pojedynczej transakcji dochód odsetkowy oddzielnie na pozycji na derywatach oraz

papierach dłużnych Wynik na koniec dnia – wynik odkładany za koniec dnia

2. Przeglądanie danych

Udostępniona funkcjonalność przeglądania danych historycznych dotyczących wyników. System umożliwi eksport do Excel.

Strona 10

historycznych

Grupa VII – wymagania funkcjonalne z zakresu zarządzania transakcjami klientowskimi

L.p. Wymaganie Opis wymagań oczekiwanych od systemu1. Zmiany

terminów na transakcjach

Możliwość modyfikowania warunków czynnej transakcji (w szczególności skracanie i wydłużanie transakcji pochodnych) oraz blokowanie środków na lokatach negocjowanych.

2. Historia zmian Zapewnienie przechowywania historii zmian wykonanych na transakcjach (np. zmiana nominału, stopy procentowej, kursu, dat itd.), informacji o pierwotnej transakcji (np. w przypadku skróceń/wydłużeń transakcji pochodnych)

3. Raportowanie Raport z zawartych transakcji: modyfikowanych, anulowanych, zablokowanych wysokości marż pojedynczych transakcji oraz zbiorczych zestawień, wraz z wyceną transakcji

4. Wynik klientowski

Wyznaczanie wyniku w podziale na: rodzaj transakcji nazwa klienta konkretną datę

Grupa VIII Zarządzanie limitami Kontrahenta

L.p. Wymaganie Opis wymagań jakie oczekiwanych od systemu1. Rodzaje limitów Zarzadzanie limitami:

rozliczeniowymi i przedrozliczeniowymi kontrahenta (bankowego, niebankowego, emitenta, CCP)

globalnymi na walutę, kraj, typ transakcji 2. Limit dealerski

(opcjonalnie)Przyznany poszczególnym dealerom limit na nominał transakcji w podziale na jej typ.

3. Kalkulacja obciążania limitów

Możliwe zdefiniowanie sposobu obciążania limitu: kwotą nominału, kwotą nominału z uwzględnieniem wagi ryzyka kwotą nominału z uwzględnieniem wagi ryzyka i wartości wyceny maksymalnym nominałem transakcji (nie sumą) limit dla pojedynczej transakcji tworzenie limitów na grupy (tzn. kilku kontrahentów obciąża jeden

limit, np. na kraj czy całą grupę finansową) zdefiniowanie innych reguł obciążania limitów wg zdefiniowanych

wzorów,

4. Podział kontrahentów

Wymagane oddzielne definiowanie i monitorowanie limitów w podziale na kontrahentów bankowych, niebankowych, emitentów i CCP.

5. Typy limitów Wymagane jest oddzielne definiowanie i monitorowanie limitów w podziale na rodzaje transakcji (dla każdego kontrahenta i klienta inne limity).Możliwość parametryzowania różnych typów limitów m.in. ze względu na: rodzaj transakcji, tenor, walutę (np. limity depozytowe, limity na transakcje pochodne FX, limity IRS itd.).W przypadku kontrahenta międzybankowego możliwość zdefiniowania limitów łącznych, które sumować będą obciążenie ze wskazanych limitów

Strona 11

kontrahenta. Możliwe konfigurowanie limitów kontrahentów niebankowych na indywidualnych zasadach.W przypadku limitu dla emitenta - obciążenie limitu emitenta po dacie rozliczenia kupna/sprzedaży papierów (przed dniem rozliczeniem, obciążony jest limit kontrahenta z którym została zawarta transakcja).W przypadku CCP - obciążony limit wskazanego CCP oraz ewentualnego pośrednika CCP (jedna transakcja będzie mogła obciążać w zależności od CCP nawet 2 podmioty).

6. Limity indywidualne

Możliwość sparametryzowania limitu indywidualnego dla transakcji. Będzie funkcjonował na zasadzie pozostałych rodzajów limitów (rozliczeniowy, przedrozliczeniowy, emitenta itd.), ale będzie przypisany do pojedynczej transakcji (np. jeden limit będzie przypisywany do pojedynczej transakcji IRS z klientem, który może teoretycznie mieć kilka tego typu transakcji).

7. Monitorowanie w ciągu dnia

Przy wprowadzaniu transakcji możliwe wykonanie symulacji wykorzystania limitu kontrahenta.Obciążenie limitów odświeżane na bieżąco (wraz z zawieranymi nowymi transakcjami, modyfikacją istniejących, ich anulowaniem oraz ewentualnymi zmianami danych rynkowych).

8. Raporty Generowanie raportów dotyczących aktualnego wykorzystania wszystkich zdefiniowanych limitów w systemie wraz z danymi dotyczącymi wielkości limitu, dat obowiązywania, aktualnego ich obciążenia, nazwy limitu itd.Każdy typ limitu powinien posiadać osobny raport, gdyż będą dla niego definiowane inne pola do wyświetlania.System umożliwi eksport wyników raportów do Excel. Obciążenie limitów odświeżana będzie w czasie rzeczywistym, wraz z zawieranymi transakcjami i zmianami danych rynkowych. Przy wprowadzaniu transakcji będzie możliwe wykonanie symulacji wykorzystania limitu kontrahenta.

9. Automatyzacja raportów

W ustalonym interwale w ciągu dnia (np. co godzinę) system wykonywać będzie export raportów obejmujący wykorzystanie limitów – dostępny również na żądanie.

Dodatkowo o konkretnie określonej godzinie system będzie również wykonywał export raportów (np. na koniec dnia).

10. Powiadomienie email o przekroczeniu (opcjonalnie)

W sytuacji wystąpienia przekroczenia następuje wysłanie informacji do zdefiniowanej listy adresatów email wraz ze szczegółami.

11. Transakcje poza systemowe (opcjonalnie)

System powinien obsługiwać transakcje dodatkowe (bez ewidencji księgowej) wprowadzane w celu obciążania limitów. Transakcje te obciążać będą zarówno limity związane z tymi transakcjami, jak i limity łączne kontrahenta.Transakcje mają wyłącznie charakter techniczny są sztuczne i nie muszą odzwierciedlać rzeczywistej transakcji . Ww. transakcje mogą mieć wspólny w systemie typ o nazwie zbliżonej z przeznaczeniem. Daty mają określać okres obowiązywania obciążenia limitu.

12. Cross Currency Repo (opcjonalnie)

Transakcje REPO powinny posiadać dodatkowe pole, mówiące o haircut z jakim trasnakcja ta została zabezpieczona papierami. Wartość obligacji zabezpieczających transakcje REPO są nominalnie wyższe od transakcji

Strona 12

REPO w przeliczeniu na PLN. Wartość REPO po przemnożeniu przez haircut (każda transakcja REPO z nawet tym samym kontrahentem może mieć inną wartość haircut) powinna generować obciążenie odpowiednich limitów.

Grupa IX - wymagania funkcjonalne z obszaru Zarządzania i monitorowania ryzyka rynkowego

L.p. Wymaganie Opis wymagania1. Definiowanie

modeli szacowania VaR.

Zaimplementowany model szacowania VaR (historyczny). System powinien umożliwić edycję parametrów modelu VaR.

2. Założenia do modelu VaR

Bank zakłada, że w modelu VaR zostanie zastosowana metoda symulacji historycznej. Parametry modelu: horyzont utrzymywania pozycji (np. 10 dni), który utylizować będzie

limit poziom istotności sposób wyznaczania elementu/wartości VAR przy określonym

poziomie istotności, poprzez interpolacje lub pobieranie konkretnej wartości wystąpienia (dla np. 99 percentyla z 250 dni roboczych nie będzie interpolowany, ale brana konkretna druga najwyższa zmiana)

długość okresu historii danych rynkowych (stóp procentowych/kursów walutowych)

sposób obliczania zmian czynników rynkowych (np. logarytmiczne/arytmetyczne stopy zwrotu)

W modelu dla instrumentów pochodnych zostanie uwzględniona metoda wyceny dual-curve (odrębna krzywa projekcyjna i dyskontowa).Dostępna będzie również metoda liczenia VaR metodą parametryczną.

3. Rodzaje VaR System wyznaczy następujące rodzaje miary VaR: VaR stopy procentowej – określający jaką maksymalną stratę, na

zadanym poziomie ufności, Bank może ponieść na otwartych pozycjach wrażliwych na ryzyko stopy procentowej

VaR walutowy - określający jaką maksymalną stratę, na zadanym poziomie ufności, Bank może ponieść na otwartych pozycjach wrażliwych na ryzyko zmian kursów walutowych

VAR łączny – łączny VAR stopy procentowej oraz VAR walutowegoObie wyliczane miary VAR powinny być kalkulowane oddzielnie. System nie powinien kalkulować VAR łącznego w żadnym podziale, czy też raporcie. O ile w dokumencie będzie wspomniane o wyliczeniu VAR bez podziału na walutowy i stopy procentowej, należy to rozumieć że chodzi o wyliczenie osobne dla obu typów VAR.

4. Podziały VAR stopy procentowej

Możliwe będzie liczenia VAR stopy procentowej w podziale na:1) księgę handlową

w tym dodatkowo w podziale na typy transakcji (wartość VAR w podziale na typy transakcji ma sumować się na wartość całej księgi handlowej)

instrument (w przypadku papierów wartościowych podział na typy oraz per instrument, per nazwa obligacji)

w tym możliwość zejścia z wyliczonym VAR do wartości składowej

Strona 13

per pojedyncza transakcja (będącej składową sumy VAR księgi handlowej)

2) typy transakcji w księdze handlowej (osobno policzony VAR dla każdego typu transakcji – nie sumuje się na księgę handlową z punktu 1)

3) księgę bankową4) łączny dla stopę procentową5) portfele (wewnętrzne zdefiniowane nazwy portfeli - adekwatne z

nazwami dla MSSF9 (np. PDS – portfel do sprzedaży)

Przykładowo opisana powyżej funkcjonalność ma dać możliwość sprawdzenia, że np. w ramach księgi handlowej i policzonego VAR, DS0727 obciąża VAR w wartości 20000, WZ1122 w wartości 30000, a instrumenty pochodne IRS w wartości 100000, co razem przekłada się na całkowitą wartość VAR księgi handlowej w wysokości łącznej 150000.

5. Podziały VAR walutowego

Możliwe będzie liczenie VAR walutowego w podziale na:1) księgę handlową w oparciu o pozycję walutową dealerską2) księgę handlową i bankową łącznie w tym dodatkowo:

- w podziale na waluty stanowiące pozycję walutową Banku danego dnia lub zdefiniowane w parametryzacji - oba przypadki są akceptowane (wartość VAR w podziale na waluty ma sumować się na wartość całej księgi handlowej)

6. Tabela Typów transakcji

Podziały VAR (pkt. 4 i 5) powinny być określone w tabeli parametrycznej. Tabela ta powinna być dostępna do edycji. System umożliwi definiowanie nowych typów transakcji i ich kwalifikację do rodzaju ryzyka, portfela, podziału na księgę handlową i bankową. System umożliwi kwalifikację transakcji do więcej niż jednego rodzaju ryzyka w zależności od opracowanego modelu VaR.

7. Wyznaczanie VaR na bieżąco ‘w ciągu dnia’

System na bieżąco powinien wyznaczać VAR stopy procentowej dla księgi handlowej. Pozostałe podziałały określone w pkt.4 może wyznaczać tylko na koniec dnia. Z uwagi na czas wyliczenia, VAR wyliczany na bieżąco może być w oparciu o zmienności rynkowe wyznaczone na podstawie portfela kalkulowanego (i danych rynkowych) w poprzednim procesie pełnego przeliczenia VAR (np. procesu EOD).Przy wyliczaniu wartości VaR powinny być uwzględniać zmiany wynikające z bieżących zdarzeń ‘w ciągu dnia’ dot. transakcji zaliczanych do portfela handlowego takich jak :- Nowa transakcja - Modyfikacja istniejącej transakcji ( mające wpływ na wartość VaR)- Anulowanie transakcji- Zamknięcie transakcji

System przynajmniej raz dziennie powinien wykonać pełne przeliczenie VAR we wszystkich wyznaczonych w pkt. 4 i 5 podziałach.

8. Uruchomienie dodatkowego przetwarzania VaR

System powinien umożliwić wykonanie pełnego przetwarzania VAR (kompletne wyliczenie) „na żądnie”., które wykona dla aktualnych danych rynkowych, aktualnego portfela oraz parametryzacji.

9. Wyznaczanie VaR 'na koniec dnia'

System powinien samodzielnie odkładać raporty z tego wyliczenia lub dać możliwość wczytywania danych z tego wyliczenia w późniejszym terminie (np. następnego dnia roboczego) lub wskazać stały/ustalony moment dnia,

Strona 14

w którym dane te byłyby gotowe do pobrania. Efektem koniecznym do uzyskania ma być możliwość pobrania danych/raportu o wartości VAR w wymaganych podziałach za wskazanego dnia.

10. Dekompozycja VaR 'na koniec dnia' na poszczególne instrumenty/waluty/transakcje (opcjonalnie)

W przypadku wyliczenia ‘na koniec dnia’ system zgodnie z podziałami z pkt. 4 i 5, powinien w zależności od podziału mieć możliwość podania szczegółów wyliczenia tzw. drill down. W przypadku obligacji powinien dać możliwość zobaczenia VAR w podziale na nazwę papieru. W przypadku VAR walutowego na poziom pojedynczej waluty, a w przypadku transakcji pochodnych na stopę procentową, na poziom pojedynczej transakcji.

11. Wprowadzanie limitów VaR

System powinien mieć możliwość wprowadzania i parametryzacji limitów dla VaR ‘w ciągu dnia’ dla księgi handlowej.

12. Wprowadzanie limitów VaR ‘na koniec dnia (opcjonalnie)

System powinien mieć możliwość wprowadzania i parametryzacji limitów dla VaR ‘na koniec dnia’ dla księgi handlowej.

13. Symulacje utylizacji limitów

System umożliwi ręczne wprowadzenie transakcji hipotetycznej dla której wyznaczy VaR (transakcje symulowane). System powinien umożliwiać wprowadzenie więcej niż jednej transakcji hipotetycznej. System wyznaczy VaR dla: portfela składającego się tylko z transakcji wprowadzonych ręcznie portfela składającego się z aktualnych pozycji oraz dodatkowych

pozycji wprowadzonych ręcznie Powyższe wyznaczone wartości VaR będą widocznie na pulpicie wyłącznie dla użytkownika, który wprowadził hipotetyczną transakcję. Proces bieżącego (ani pełnego) przetwarzania VaR nie powinien uwzględniać hipotetycznej transakcji. System wskaże, czy po ewentualnym zawarciu transakcji limit VaR danego rodzaju byłby przekroczony.

14. Uwzględnienie dni wolnych od pracy

Przy wyznaczaniu VaR system pominie dni wolne od pracy przy kalkulacji zmian kursów walutowych/stóp procentowych.

15. Obsługa przekroczenia limitu

System automatycznie będzie informował o przekroczeniu limitu w ciągu dnia.

16. Powiadomienie email o przekroczeniu (opcjonalnie)

System wyśle powiadomienia mailowe do wybranych odbiorców w przypadku, gdy którykolwiek limit zostanie przekroczony. Treść maila powinna zawierać odpowiedni raport (m.in. wartość VAR na tle limitu, nazwę limitu itd.).

17. Backtest VAR (opcjonalnie)

System umożliwi przeprowadzenie backtestingu modelu VaR.System przeprowadzi dwa rodzaje backtestingu: historyczny i rewaluacyjny.Do celu stosowania backtestingu historycznego system wykorzysta wartości VaR ‘na koniec dnia’ wyliczone z ostatnich x dni roboczych (x – okres backtestingu ustawiany jako parametr w systemie, domyślnie 250 dni roboczych). Wartość VaR 1 dniowego ‘na koniec dnia’ porównywana jest z rewaluacyjnymi wynikami na pozycjach pierwotnych, objętych modelem wartości zagrożonej, z tytułu rzeczywistych zmian parametrów cenowych, obliczonych przy założeniu utrzymywania przez 24 godziny stałej wielkości i struktury pozycji pierwotnych.

Strona 15

Do celu stosowania backtestingu rewaluacyjnego system wykorzystuje wartości VaR ‘na koniec dnia’ wyliczone z ostatnich x dni roboczych (x jako parametr w systemie, domyślnie 250 dni roboczych). Wartość VaR 1 dniowego ‘na koniec dnia’ porównywana jest z wartością wyniku na działalności spekulacyjnej z dnia następnego ( odpowiednio jak wymienione w bulecie wyżej) , nie uwzględniającego transakcji zawartych w dniu, dla którego wyznaczany jest wynik. System prezentuje wyniki backtestingu historycznego i rewaluacyjnego na wykresie: odrębnie dla VaR stopy procentowej, VaR walutowego. Wykres obejmuje okres x dni roboczych (okres backtestingu ustawiany jako parametr w systemie) od wybranej daty raportowej. Na wykresie pokazana jest wartość VaR w danym dniu oraz wartość porównywanego wyniku spekulacyjnego. System wskazuje liczbę przekroczeń VaR – ile razy wystąpiło zdarzenie, że strata z działalności handlowej była wyższa od wartości VaR. Przekroczenia poziomu VaR pokazywane są na wykresie innym kolorem niż wartości wyniku nie powodujące przekroczenia VaR.System umożliwi eksport wykresu backtestu do Excel. System umożliwi pobranie danych na podstawie których został zbudowany wykres.

18. Stress-testy VAR (opcjonalnie)

System umożliwia na żądanie przeprowadzenie stress-testów VaR wg scenariuszy opracowanych w ramach przeglądu metody. Stress-testy wykonywane powinny być w oparciu o dane 'na koniec dnia'.Scenariusze stress-testów uwzględniać powinny zakłócenia: parametrów cenowych, siły związków korelacyjnych zmian parametrów cenowych, zmienności parametrów cenowych, poziomu płynności rynków, struktury i wielkości pozycji pierwotnych banku.System umożliwi podgląd wyników stress testów oraz ich eksport do Excel.System umożliwi użytkownikowi definiowanie/ modyfikację parametrów scenariuszy.

19. BPV System powinien wyznaczać BPV zarówno na bieżąco, jak i ‘na koniec dnia’ na wszystkich transakcjach wrażliwych na ryzyko stopy procentowej w księdze handlowej. Parametryzacja, które transakcje wchodzą w skład księgi handlowej będzie taki sam jak dla VAR.Wyliczenie bieżące może być oparte o krzywe z dnia poprzedniego.Wyliczenia na koniec dnia powinno być oparte o aktualne krzywe - wczytywane przed końcem dnia.Przy wyznaczaniu BPV system powinien uwzględniać bieżące (w ciągu dnia) zmiany w portfelu transakcji (nowe transakcje, zmiany istniejących, anulowania transakcji, zamknięcia).

20. Stress-testy BPV (opcjonalnie)

System umożliwia użytkownikowi definiowanie/modyfikację parametrów scenariuszy. System umożliwia podgląd wyników stress testów na pulpicie oraz eksport wyników do Excel. Scenariusze stress-testów uwzględniają zakłócenia: parametrów cenowych, siły związków korelacyjnych zmian parametrów cenowych, zmienności parametrów cenowych, poziomu płynności rynków, struktury i wielkości pozycji pierwotnych banku.

21. Wyznaczanie całkowitego BPV ‘na koniec dnia’

System powinien samodzielnie odkładać raporty z tego wyliczenia lub dać możliwość wczytywania danych z tego wyliczenia w późniejszym terminie (np. następnego dnia roboczego) lub wskazać stały/ustalony moment dnia, w którym dane te byłyby gotowe do pobrania. Efektem koniecznym do

Strona 16

uzyskania ma być możliwość pobrania danych/raportu o wartości BPV w wymaganych podziałach na: tenory, typy transakcji, walutę, krzywe projekcyjne, krzywe dyskontowe.

22. Wprowadzanie limitów BPV

Limit BPV ‘w ciągu dnia’ wprowadzany jest do systemu jako parametr.Limity zdefiniowane są:- limit otwartej pozycji BPV w podziale na typy transakcji (BPV liczony jest

osobno dla każdego tenoru oraz typu transakcji – suma tych wyliczeń podlega sprawdzeniu o limit)

- limit otwartej pozycji BPV łączny (BPV liczony jest osobno dla każdego tenoru oraz typu transakcji – suma tych wyliczeń podlega sprawdzeniu o limit)

23. Wprowadzanie limitów BPV ‘na koniec dnia’(opcjonalnie)

System powinien mieć możliwość wprowadzania i parametryzacji limitów dla BPV ‘na koniec dnia’ dla księgi handlowej.

24. Podziały wyznaczanego BPV

System przeliczać powinien BPV jednocześnie w poniższych podziałach (tak by otrzymać np. jaki BPV jest dla obligacji, na tenorze 3M w walucie PLN dla krzywej o nazwie xyz):- Waluty- Typ transakcji- Tenor krzywej stóp procentowych: ON, TN, SW, 1M, 3M, 6M, 1Y, 2Y, 3Y,

4Y, 5Y, 6Y, 7Y, 8Y, 9Y, 10Y, 15Y – w przypadku zmian tenorów krzywej stóp procentowych system wyznaczy BPV dla wszystkich tenorów nowej krzywej.

- Rodzaj krzywej dyskontowej- Rodzaj krzywej projekcyjnej

25. Selektywne wyznaczanie BPV

System powinien umożliwiać na żądanie użytkownika wyliczenie na dany moment BPV na pojedynczej transakcji/kilku transakcjach wybranej/wybranych ze wszystkich dostępnych w systemie transakcji na stopę procentową (także niezaliczających się do działalności spekulacyjnej). System umożliwi eksport wyników obliczeń do Excel (zgodnie z wymaganymi podziałami BPV).

26. Wyznaczanie BPV dla hipotetycznej transakcji

System powinien umożliwiać wprowadzenie hipotetycznej transakcji (dane transakcyjne niezbędne do wyznaczenia BPV) oraz na żądanie użytkownika wyznaczy jej BPV. System pokazuje jakie byłoby wykorzystanie limitu BPV po ewentualnym zawarciu tej transakcji oraz czy limit (dla obecnego portfela i nowej transakcji) byłby zachowany czy przekroczony. System umożliwi eksport wyników obliczeń do Excel (zgodnie z wymaganymi podziałami BPV).

27. Uruchomienie dodatkowego przetwarzania BPV

System powinien umożliwić wykonanie pełnego przetwarzania BPV (kompletne wyliczenie) „na żądnie”., które wykona dla aktualnych danych rynkowych, aktualnego portfela oraz parametryzacji.

28. Ustawienie limitów wewnętrznych(opcjonalnie)

System umożliwi ustawienie poziomu wewnętrznego limitu ostrzegawczego o bliskości przekroczenia limitu typu pozycji w walucie, na kontrahencie.

29. Obsługa przekroczenia limitu

System automatycznie będzie informował o przekroczeniu limitu w ciągu dnia.

Strona 17

30. Powiadomienie email o przekroczeniu BPV (opcjonalnie)

System wyśle powiadomienia mailowe do wybranych odbiorców w przypadku, gdy którykolwiek limit zostanie przekroczony. Treść maila powinna zawierać odpowiedni raport (m.in. wartość BPV w wymaganych podziałach na tle limitu, nazwę limitu itd.).Szablon maila o przekroczeniu powinien być parametryzowany/edytowalny.

Grupa X - wymagania funkcjonalne z obszaru raportowania regulacyjnego

Raportowanie transakcji zgodnie z wymogami regulacyjnymi

1. Udostępnienie danych do raportowania APA do eksportu

Udostępnienie wymaganych regulacją MIFID II danych transakcyjnych do eksportu z systemu w celu raportowania do APA: (ISIN, instrument type, asset class, asset sub class, quanity, quantity type, notional, notional currency, execution time, submission time, venue of execution, price, price notation, trade date, direction, report type, initial deferral flags, submitting party trade capacity, counterparty trade capacity, deferral flags, ISIN, submitting party LEI, reporting party LEI, counter party LEI oraz inne )

2. Raportowanie APA (opcjonalnie)

Automatyczne raportowanie transakcji do APA (raportowanie zgodnie z wymaganymi przepisami prawa, regulacją MIFID II z zachowaniem obowiązującego czasu przesłania raportu). Dowód zaraportowania archiwizowany, powiązany z transakcją pierwotną, z możliwością generowania raportów w systemie.Pola wymagane do raportowania APA: (ISIN, instrument type, asset class, asset sub class, quanity, quantity type, notional, notional currency, execution time, submission time, venue of execution, price, price notation, trade date, direction, report type, initial deferral flags, submitting party trade capacity, counterparty trade capacity, deferral flags, ISIN, submitting party LEI, reporting party LEI, counter party LEI oraz inne )

3. Przesyłanie danych do systemu Backoffice (Def3000/TR) za pomocą interfejsu na potrzeby raportowania ARM oraz EMIR

Pola do przesłania interfejsem: UTI, trading venue, godzina, minuta, sekunda, milisekunda zawarcia transakcji, kod ISIN SPOT, kod ISIN FORWARD, wskaźnik postransakcyjny OTC, identyfikator w systemie obrotu, stawka referencyjna, marża, short selling indicator.

Grupa XI – wymagania dodatkowe z zakresu działania systemu

L.p. Wymaganie Opis wymagania1. Wczytywanie

danych System z określonej lokalizacji pobierać będzie aktualne krzywe służące do wyceny instrumentów finansowych.

Strona 18

rynkowych oraz krzywych

Dodatkowo pobierać będzie z tej lokalizacji bezpośrednie kwotowanie rynkowe dla papierów wartościowych.Możliwe będzie również pobieranie innych danych rynkowych (np. kursy fixingowe).

W lokalizacji będą odkładane pliki excel w odpowiednim formacie. Każdorazowe pojawienie się pliku powinno skutkować wczytaniem danych i traktowaniem ich jako aktualne.

2. Tworzenie krzywych (opcjonalnie)

System powinien udostępniać własny mechanizm tworzenia krzywych stóp procentowych używanych do rynkowej wyceny instrumentów finansowych. Wybór czy Bank będzie korzystał z krzywych zasilanych poprzez opisane w pkt XI.1 pliki excel, czy też używał do tworzenia mechanizmów własnych systemu powinien podlegać parametryzacji.

System powinien dla każdej krzywej mieć możliwość zaznaczenia, czy tworzona jest przy pomocy danych rynkowych i systemu FO, czy też zasilana ze źródła zewnętrznego (pkt XI.1).

3. Połączenie z serwisem danych rynkowych Reuters/Bloomberg

System będzie podłączony do danych rynkowych od dostawcy Refinitiv(Reuters) lub Bloomberg (wybór dostawcy zależeć będzie od Banku).

4. Wycena transakcji

System obsługiwać będzie wyceny:- wycena rynkowa wynikająca z ceny instrumentu (np. papieru dłużnego)- wycena rynkowa wyliczana z krzywej (np. FX SWAP, FX FORWARD)- wycena rynkowa przy użyciu dwóch krzywych jednej do projekcji stóp procentowej a drugiej do dyskontowania przepływów tzw.dual-curve (np. IRS)- wycena liniowa- wycena wg. ESP

5. Podział wyniku Kalkulacja wyniku w podziale na zrealizowany i niezrealizowany.

6. Obsługa odcięcia wyniku wraz z danego końcem okresu

System umożliwia ustanowienie punktu odcięcia wyniku (np. na koniec dnia, miesiąca, roku). Od momentu odcięcia wynik naliczany jest na nowo.

7. Koszt finansowania (Cost of Carry)

Koszt finansowania policzony powinien być oddzielnie na pozycji dla instrumentów pochodnych oraz oddzielnie dla papierów dłużnych.

W ustawieniu początkowym kosztem finansowania byłaby stawka rynkowa Polonia (stawka O/N).

8. Wynik odsetkowy zrealizowany

System powinien raportować zrealizowany wynik odsetkowy na poszczególnych grupach instrumentów.

9. Pobieranie informacji z bazy danych systemu

System powinien bez przeszkód (zarówno licencyjnych jak i technicznych) umożliwiać pobieranie danych bezpośrednio z bazy danych systemu (m.in. informacje o transakcjach, limitach, aktualnych pozycjach, ekspozycjach limitów, VAR, BPV itd.).

W tym zakresie (danych wpisywanych do systemu oraz wyliczanych w ramach

Strona 19

wypisanych w dokumencie wymagań) system powinien umożliwiać dowolne korzystanie z danych.

10. Eksport danych do hurtowni danych

System powinien umożliwiać export danych do hurtowni danych za koniec dnia (tak jak w przypadku informacji wymaganych w pkt. XI.5)

11. Przeszacowywanie stóp referencyjnych

System automatycznie wstawi nową stawkę referencyjną (LIBOR,EURIBOR itd.) do transakcji, która wymagać będzie przeszacowania. System umożliwie również manualną zmianę tej staweki.

Grupa XI - Autodealing (opcjonalnie)

L.p. Wymaganie Opis wymagań oczekiwanych od systemu1. Dostęp do aplikacji Zapewnienie funkcjonalności jednokrotnego logowania tzn.

klient wywołuje aplikację autodealing z poziomu bankowości internetowej

2. Parametryzacja ogólna Adresów email pracowników Banku na który będą wysyłane:

o Informacje o zdefiniowaniu nowego klienta o potwierdzenia o realizacji transakcjio pop’up dla klienta z potwierdzeniem zawarcia

transakcji Godziny graniczne wykonywania transakcji – transakcje

zawarte poza tymi godzinami realizowane są na rachunkach klienta jako pierwsze w dniu następnym

Rodzajów zawieranych transakcji np. FX SPOT, FX ORDER Pary walut w których dopuszczone jest zawieranie

transakcji powyższych transakcji Minimalna kwota dla danego typu transakcji oraz dla danej

pary walutowej Czas na podjęcie decyzji przez klienta o realizacji transakcji Marże - parametryzacja marży w zakresie :

o Wartości zawieranej transakcji – dla kwotowań automatycznych. Transakcje powyżej zdefiniowanych zawsze kwotowane są przed dealera

o Pojedynczego klienta lub grupy klientów

3. Parametryzacja klienta W aplikacji powinna być możliwość parametryzowania: Adresów email na który będą wysyłane potwierdzenia

zawarcia transakcji Rodzaju transakcji udostępnionych klientowi Pary walut – jeżeli są ograniczone w stosunku do

ogólnie zdefiniowanych dla transakcji Rachunków wykorzystywanych do zawierania transakcji

4. Kalendarz Aplikacja powinna utrzymywać kalendarz z oznaczeniem dni wolnych i świąt

5. Kursy walutowe Prezentacja bieżących kursów dla par walutowych udostępnionych klientowi, z wyraźnym oznaczeniem jakiej pary walutowej dotyczą np. EUR/PLN. Wzrost

Strona 20

prezentowanego kursu powinien być oznaczony zielonym kolorem natomiast spadek czerwony

Prezentowane kursy powinny być odświeżane z częstotliwością nie mniejszą niż 2 sekundy – zasilanie z zewnątrz z pliku xls, html, innymi lub za pomocą usług web service.

Strona 21

6. Wykresy prezentacja wykresów wybranych przez klienta. Klient powinien mieć możliwość dokonania wyboru wykresu w zakresie:

Pary walutowej rodzaju wykresów (świecowy lub liniowy), zakresu prezentowanych danych (maksymalnie do 2

lat), interwałów (ciągły, 5min, 15min, 1h, dzienny,

tygodniowy)

7. Dostępne środki Prezentacja klientowi stanu środków dostępnych do zawarcia transakcji w zakresie:

Środków na zdefiniowanych rachunkach Dostępnego limitu na zawieranie transakcji z datami

przyszłymi8. Zawiercie transakcji FX

Spot Możliwość zawierania transakcji z zakładki kursy Po wyborze rodzaju transakcji (Kup lub Sprzedaj)

automatycznie podstawiają się zdefiniowane rachunki w odpowiednich walutach

Kwota (powinna podstawiać się automatycznie w zależności od wyboru strony transakcji na danej parze) z możliwością jej modyfikacji (zwiększenie, zmniejszenie)

Data rozliczenia (możliwość wpisania daty lub wyboru z kalendarza) w przypadku dat na jutro lub spot konieczność posiadania limitu), w przypadku wyboru daty wypadającej w dzień wolny lub święto powinien pojawiać się komunikat np. „Nieprawidłowa data”

Pasek upływu czasu do podjęcia decyzji określony przez Bank czas na zrealizowanie, zaakceptowanie przez klienta transakcji, po upływie czasu kurs będzie już nieaktualny)

Informacja o minimalnej kwocie uprawniającej do wysłania zapytania o kurs do dealera.

Komunikacja z klientem (czat) – dealer oraz klient mogą wymieniać się wiadomościami w trakcie zawierania transakcji. Czat jest aktywny od momentu wysłania zapytania o kurs do dealera do momentu odrzucenia lub zaakceptowania oferty przez klienta

Przyciski do zatwierdzenia warunków transakcji, do anulowania oraz do wysłania zapytania o kurs do dealera. Przycisk wyślij zapytanie do dealera powinien być aktywny w przypadku gdy klient spełnia minimalne warunki do negocjacji z dealerem

Po zawarciu transakcji pojawia się informacja „transakcja została zawarta sprawdź potwierdzenie na liście transakcji”

W przypadku braku środków na zawarcie lub dostępnego limitu zabezpieczenia transakcji powinny się pojawiać odpowiednie komunikaty informujące klienta np. brak środków / wolnego limitu na zabezpieczenie transakcji

Strona 22

mail do klienta potwierdzający zawarcie transakcji jeżeli taki zostanie przez klienta podany i zdefiniowany

9. Historia transakcji możliwość wyboru zakresu danych prezentowanej historii (daty od do – wybór z kalendarza lub wpisanie daty w określone pola),

możliwość wyszukiwania transakcji po ID, możliwość wyboru zakresu dat prezentowanych danych, możliwość wybory zakresu kwot prezentowanych danych, możliwość wyboru typu transakcji (spot, order), możliwość wyboru statusu transakcji (oczekująca,

zrealizowana, rozliczona), możliwość wyboru pary walutowej, historia powinna obejmować dane od pierwszej zawartej

transakcji na platformie walutowej z poziomu historii klient powinien mieć możliwość

generowania potwierdzenia danej transakcji w formacie pdf.

odświeżanie historii zawartych transakcji w czasie rzeczywistym

możliwość pobrania potwierdzenia transakcji bezpośrednio z historii

10. Panel dealera Panel dla dealera powinien umożliwiać przeglądanie bazy klientów, generowanie raportów przeglądanie macierzy marż danego klienta, odbierania zapytania o kurs walutowy możliwość komunikowania się z klientem podczas ustalania

warunków transakcji, wyłączenie możliwości automatycznego zawierania

transakcji walutowych na platformie przez klientów.

11. Raporty dostępne z poziomu dealera

Raport prezentujący wszystkie zawarte transakcjeRaport aktywności klientówRaport podziału na grupy klientówRaport (dziennik zdarzeń)

12. Komunikaty Aplikacja powinna prezentować komunikaty przekazywane przez dealera.

13. Integracje z innymi systemami

Pobieranie informacji o bieżących saldach na rachunkach klienta.

Sprawdzanie pokrycia środków oraz ich blokada w systemie centralnym środków na rachunku waluty sprzedawanej – dla transakcji zawieranych do wysokości środków na rachunkach

Aktualizacja w systemie centralnym limitu - dla transakcji

Strona 23

zawieranych na daty przyszłe Przekazywanie on-line do systemu centralnego zawartych

transakcji Zasilanie platformy kursami spotowymi powinno odbywać

się za pomocą plików tworzonych przez Bank transakcje z autodealingu przechodzą on line na pozycję

walutowa banku

B. WYMAGANIA INTEGRACYJNE

Lp. Nazwa wymagania Opis wymagania 1. def3000/TR Interfejs działający w dwie strony z systemem back-office Def3000/TR

obejmujący m.in.:a) Transmisję danych transakcyjnych:

nowe transakcje, edycja danych zawartych transakcji (np. skrócenie, wydłużenie

itp.) anulowanie

b) Transmisja danych statycznych kontrahentów z def3000 TR do systemu F/O: nazwa krótka, długa, kod BIC SSI (standard settlement instructions) lista z dostępnymi rachunkami rozliczeniowymi hasło identyfikacyjne wykaz pełnomocników, numery telefoniczne, identyfikator rodzaju podpisanej umowy, kod LEI.

2. def3000/CL Interfejs z def3000CL do systemu F/O obejmujący funkcjonalność transmisji danych o zleceniach klientowskich wysokokwotowych w PLN (SORBNET2 – system rozliczeń w Polsce) oraz o zleceniach klientowskich w walutach obcych (status zrealizowany)Dotyczy wszystkich zleceń poza Elixirem i EuroElixirem (systemy rozliczeń w Polsce).

3. def3000/CP Interfejs pobierający informacje z systemu tworzącego pozycję walutową Banku. System F/O pobierać będzie z tego systemu dane, dotyczące pozycji walutowej wynikłej z transakcji zawieranych poza systemem F/O (pozycja oddziałowa).

4. def3000/CB (opcjonalnie)

Interfejs z def3000/CB na potrzeby funkcjonalności „autodealingu” w zakresie pobierania bieżącego salda klienta oraz w zakresie blokady środków na rachunku klienta do wysokości zawieranej transakcji oraz księgowania on-line zawartych transakcji.

5. Reuters FXTrading (Refinitiv)

Import transakcji

6. Reuters Eikon (Refinitiv)

Interfejs online w celu pobierania aktualnych danych rynkowych.

7. Bloomberg Import transakcji.8. Bloomberg Interfejs online w celu pobierania aktualnych danych rynkowych.

Strona 24

9. Markitwire import transakcji10. FXALL, Goldman

Sachs, Barclays, BNP, DB- Autobahn, CitiVelocity, Credit Agricole, Societe Generale, Deutsche Autobahn

import transakcji

11. APA Eksport danych12. Hurtownia danych Eksport danych z systemu F/O do hurtowni danych Banku na koniec

dnia, dotyczący m.in. : pozycji walutowej, pozycji stopy procentowej, VAR, BPV, ekspozycji na tle limitów (wszystkie dane dotyczące limitów i ekspozycji), kontrahentów i parametryzacji, transakcji, wyceny.Szczegółowa lista danych zostanie ustalenia z dostawcą w zależności od zaoferowanego zakresu wdrożenia.

C. WYMAGANIA TECHNICZNE I TECHNOLOGICZNE

I.II.

III.IV.V.

VI.VII.

VIII.IX.X.

XI.XII.

XIII.XIV.XV.

XVI.XVII.

XVIII.XIX.XX.

XXI.XXII.

XXIII.XXIV.XXV.

XXVI.XXVII.

XXVIII.

Strona 25

XXIX.XXX.

XXXI.XXXII.

XXXIII.XXXIV.XXXV.

XXXVI.XXXVII.

XXXVIII.XXXIX.

XL.XLI.

XLII.XLIII.XLIV.XLV.

XLVI.XLVII.

XLVIII.XLIX.

L.LI.

LII.LIII.LIV.LV.

LVI.LVII.

LVIII.LIX.LX.

LXI.LXII.

LXIII.LXIV.LXV.

LXVI.LXVII.

LXVIII.LXIX.LXX.

LXXI.LXXII.

Strona 26

LXXIII.LXXIV.LXXV.

LXXVI.LXXVII.

LXXVIII.LXXIX.LXXX.

LXXXI.LXXXII.

LXXXIII.LXXXIV.LXXXV.

LXXXVI.LXXXVII.

LXXXVIII.LXXXIX.

XC.XCI.

XCII.XCIII.XCIV.XCV.

XCVI.XCVII.

XCVIII.XCIX.

C.C.1. Budowa Systemu Front Office (zwany dalej: Systemem)

1. System powinien opierać się o niezawodne i wydajne rozwiązania technologiczne, zapewniające wysoką wydajność, bezpieczeństwo danych i możliwość integracji z innymi systemami. System powinien zawierać możliwość rozbudowy o dodatkowe moduły i funkcjonalności biznesowe uwzględniające zmiany legislacyjne w zakresie działania lub funkcjonalności Systemu. System powinien być parametryzowany przez administratora biznesowego. W ramach projektowania powinny być dostępne narzędzia umożliwiające projektowanie/definiowanie/modyfikowanie:a) ról użytkowników;b) kalendarzy i terminarzy (przypomnienia, lista zadań do wykonania);c) wzorów dokumentów i komunikatów z uwzględnieniem reguł biznesowych;d) raportów, analiz.

2. Wymagana jest funkcjonalność umożliwiająca zarządzanie użytkownikami i uprawnieniami, która powinna zapewniać kontrolę uprawnień do Systemu oraz do elementów Systemu.

3. System powinien umożliwiać samodzielną pracę pracowników Banku, bez udziału konsultantów Oferenta lub innych podmiotów zewnętrznych, także przy dokonywaniu zmian elementów, procesów, itp.

Strona 27

C.2.Wymagania w zakresie architektury i technologii1. System powinien być wykonany w technologii 3-warstwowej (interfejs użytkownika BackOffice,

logika biznesowa, warstwa danych).2. System powinien komunikować się z innymi aplikacjami co najmniej za pomocą usług WebService,

szyny danych ESB lub innych np. API.3. System powinien działać pod kontrolą systemów AIX 7.2, MS Windows Serwer 2016/2019, Red

Hat Linux 8.x (preferowane). Dopuszcza się również inne systemy Linux np. CentOS, pod warunkiem świadczenia wsparcia serwisowego.

4. Serwer bazy danych powinien korzystać z technologii Oracle 19c, MS SQL 2016/2017, IBM DB2 i nowsze (preferowane). Dopuszcza się oferty bazujące na innych systemach np. PostgreSQL, MySQL pod warunkiem świadczenia wsparcia serwisowego.

5. W przypadku korzystania przez System z serwera www powinien korzystać z technologii WebSphere 8.5.5/9.0, Weblogic 12.2.x, JBoss 7.x EAP i nowsze (preferowane). Dopuszcza się również inne serwery aplikacyjne np. WildFly, Tomcat pod warunkiem świadczenia wsparcia serwisowego.

6. System powinien umożliwiać uwierzytelnianie użytkowników przy pomocy dostępnego w Banku Active Directory.

7. System powinien wykonywać wszelkie zapytania, obliczenia, przetwarzania itd. po stronie serwera. Na stacji użytkownika powinien być prezentowany tylko wynik.

8. W przypadku korzystania przez System z serwera www powinien udostępniać interfejs użytkownikowi za pomocą przeglądarki WWW (Internet Explorer 11 i wyższe, MS Edge, Mozilla Firefox 46 i wyższe, Google Chrome, przy pomocy bezpiecznego protokołu wymiany danych z zastosowaniem technologii HTML w wersji co najmniej 5 oraz CSS w wersji co najmniej 3.

9. Dopuszczalna wielkość apletów, bibliotek i innych elementów aplikacji niezbędnych do jej poprawnego działania ściąganych na stację użytkownika nie powinny przekroczyć 500kB.

10. Oferta powinna zawierać opis możliwych do implementacji rozwiązań Disaster Recovery dla aplikacji z uwzględnieniem:a) integracji z centralnym systemem wykonywania kopii zapasowych Symantec Netbackup 7.7.3

i wyższej,b) redundancji infrastruktury sprzętowej, połączeń telekomunikacyjnych do ośrodka

podstawowego i zapasowego,c) wykorzystania rozwiązań klastrowych w trybie active-active.

11. System powinien umożliwiać integrację z systemem archiwizacji Vault 12 i wyższej.12. System powinien być dostępny w godzinach operacyjnych 24/7/365. System powinien być

zbudowany w architekturze wysokiej dostępności.13. System będzie korzystał z Data Center Banku: głównego i pomocniczego. 14. System będzie umożliwiał wykorzystanie istniejącej w Banku infrastruktury sieciowej (np. firewall,

switche, load balancery) i sprzętowej (platforma wirtualizacyjna np. VMware, IBM PowerVM,). Przedstawiona architektura powinna spełniać wymogi wydajnościowe dla Systemu oraz wymogi techniczne i organizacyjne określone w niniejszym dokumencie, przy czym architektura techniczna powinna w szczególności wskazywać protokoły sieciowe i sposoby wymiany danych zarówno poszczególnych modułów Systemu między sobą, jak i Systemu z aplikacjami, systemami, bazami zewnętrznymi.

15. Oferent powinien przedstawić architekturę techniczną proponowanego rozwiązania specyfikując:a) serwery,b) łącza telekomunikacyjne,c) inne urządzenia wymagane do działania Systemu,d) zajętość przestrzeni dyskowej w perspektywie na rok, 2, 5 lat,e) wymagania licencyjne.

Strona 28

16. Dostawca zaproponuje parametry infrastruktury technicznej dla oferowanego systemu zapewniające jego optymalną pracę dla środowiska produkcyjnego (wraz z instancją zapasową failover), testowego oraz szkoleniowego.

17. Dostawca wyspecyfikuje oprogramowanie bazodanowe i systemowe niezbędne do działania systemu.

18. Dostawca w ofercie przedstawi analizę wielkości ruchu sieciowego generowanego przez oferowany system („od” i „do” użytkownika), które będą podlegać weryfikacji przez Bank na etapie realizacji projektu.

19. Dostarczony system będzie przetestowany wewnętrznie przez Dostawcę przed przekazaniem do Banku.

20. Dostarczony System musi umożliwiać realizację w zakresie zarządzania zmianami w procesach w następujący sposób: Przygotowanie wersji testowej na środowisku Dostawcy, przeniesienie wersji testowej procesów na środowisko testowe, przeniesienie wersji procesów ze środowiska testowego na środowisko produkcyjne w określonej dacie. Przenoszenie wersji procesów pomiędzy środowiskami Banku musi odbywać się bez udziału Wykonawcy Systemu - realizowane jako funkcja administracyjna

21. Komunikaty o błędach lub nieprawidłowościach działania Systemu powinny być prezentowane w języku polskim lub angielskim, przy czym w wypadku komunikatów zapisywanych w logach aplikacji, powinna być możliwa parametryzacja stopnia logowania zdarzeń w sposób granularny.System musi umożliwiać pracę w trybie pełnoekranowym przy minimalnej rozdzielczości 1024x768 i skalować się do rozdzielczości urządzenia.

22. Obsługa Systemu powinna być możliwa zarówno przy pomocy myszy jak i klawiatury.23. Konfiguracja Systemu dotycząca aspektów technicznych powinna być parametryzowana przez

administratora technicznego, dotyczy to w szczególności katalogu głównego aplikacji, ścieżek, dysków, adresów internetowych, numerów portów i nazw baz danych.

24. System powinien pracować poprawnie w środowisku sieciowym, biorąc pod uwagę następujące czynniki, które mogą dotyczyć zarówno komunikacji Systemu z aplikacjami zewnętrznymi, jak i komunikacji między komponentami Systemu:a) ograniczone pasmo sieciowe, w tym pasmo ograniczone filtrem gubiącym pakiety, straty

pakietów;b) zrywanie połączeń;c) duże obciążenie sieci.

25. Komunikacja z innymi systemami:a) System powinien zapewniać możliwość wymiany danych również za pomocą

eksportów/importów z wykorzystaniem plików co najmniej w formacie XML/CSV – dla wymiany zbiorów danych (np. eksport danych z hurtowni) oraz bezpośrednio z baz danych typu Oracle, MS SQL.

b) Zapytania SQL; System powinien umożliwiać pobieranie danych za pomocą zapytań bezpośrednio z bazy danych Systemu w trybie online.

c) System powinien umożliwiać zapis logów do systemu klasy SIEM.d) System powinien być zbudowany zgodnie z architekturą SOA; System powinien udostępniać

usługi sieciowe, z których docelowo będą mogły korzystać systemy Banku. System będzie komunikował się z systemami w Banku, systemy te zostaną zdefiniowane na etapie analizy projektu.

C.3. Wymagana wydajnościowe1. Rozwiązanie powinno zapewniać możliwość budowy klastrów wydajnościowych i

niezawodnościowych.

Strona 29

2. Skalowalność rozwiązania winna zapewnić poprawną pracę Systemu dla przewidywanej liczby użytkowników i spodziewanej ilości przetwarzanych danych oraz możliwość skalowania infrastruktury Systemu wraz z jego rozwojem (skalowalność bez konieczności upgrade sysytemu).

3. W zakresie niezawodności rozwiązania, System powinien oferować możliwość automatycznej (np. w razie awarii instancji głównej) i ręcznej migracji na inny serwer, z bezstratnym przeniesieniem wymaganych do pracy krytycznych danych (logów transakcyjnych, komunikatów w systemie kolejkowym, statystyk, logów, itp.). Ta funkcjonalność powinna działać niezależnie od protokołów warstwy transportowej. Rozwiązanie powinno zawierać mechanizmy przełączania na instancję zapasową w razie awarii instancji głównej (fail - over).

4. System powinien zapewnić możliwość partycjonowania bazy danych w celu zapewnienia wyższej wydajności obsługi danych aktualnych z zachowaniem dostępu do zarchiwizowanych danych, np. z podziałem na lata ubiegłe (wymaganie opcjonalne - w przypadku, gdy oferowany system nie zapewnia partycjonowania bazy danych wymagane jest przedstawienie zastosowanych rozwiązań technicznych gwarantujących brak obniżenia wydajności dla przyrastających danych).

C.4. Wymagana dotyczące funkcji kontrolnych Systemu oraz warunków technicznych uwzględniających bezpieczeństwo Systemu.1. System powinien zapewniać następujące funkcje kontrolne: ścieżka audytu.2. Mechanizm audytowy powinien monitorować działania operatora lub administratora z zakresu

archiwizowania, czyszczenia, zmian konfiguracji oraz innych operacji ważnych – pełny audyt z możliwością konfigurowania.

3. Powinien istnieć zapis audytowy pokazujący, czy były próby nieautoryzowanego wejścia do Systemu lub aplikacji.

4. System powinien mieć moduł zarządzania logami zapisującymi logowania, wylogowania z datą, czasem, identyfikatorem użytkownika i komputera, z którego nastąpiło logowanie.

5. Nazwa, lokalizacja i rotacja plików logów oraz poziom logowania powinny być konfigurowalne, w szczególności mechanizm rotowania logów powinien mieć możliwość ustawienia rotowania logów z częstotliwością dobową, a także przy przekroczeniu zadanego rozmiaru logu, zaś sam proces rotowania nie powinien wymagać ani powodować zatrzymania aplikacji, a stary log nie powinien być nadpisywany nowym.

6. Powinna istnieć możliwość monitorowania przetwarzania danych.7. System powinien mieć opcję monitorowania wszelkich działań użytkowników i/lub

administratorów (użytkowników uprzywilejowanych).8. System powinien zapewniać bezpieczeństwo danych zgodnie z obowiązującym prawem polskim i

europejskim oraz spełniać wymagania w zakresie niezawodności, a w szczególności realizować niżej wymienione funkcje:a) dostęp do danych, operacji i produktów powinien być ograniczony do użytkowników

posiadających określone role w Systemie;b) przydzielanie, usuwanie i zmiana uprawnień dla określonej roli;c) tworzenie kopii zapasowych (backup);d) wsparcie dla szyfrowania komunikacji interfejsu użytkownika z Systemem lub Systemu z

innymi aplikacjami (wewnętrznymi i zewnętrznymi);e) definiowanie i weryfikacja akceptowalnej siły hasła; f) konfigurowanie okresów ważności hasła, wymuszającą zmianę hasła co zadany okres;

Strona 30

g) przechowywanie wyłącznie zaszyfrowanych haseł w Systemie, hasła nie powinny być w jakimkolwiek przypadku wyświetlane podczas pisania;

h) monitorowanie i raportowanie nieudanych prób dostępu do Systemu/aplikacji;i) utrzymanie integralności danych wymienianych z innymi aplikacjami

i systemami;j) utrzymanie integralności danych w przypadku odzyskiwania danych po awarii;k) mechanizm gwarantujący, że wszystkie elementy pracy są przetwarzane do końca;l) łatwość użytkowania, konfiguracji i administracji,m) gwarancja realizacji praw osób, których dane przetwarzane są w Systemie w zakresie

określonym w RODO,n) posiadać funkcjonalność usuwania / anonimizacji danych osobowych po upływie okresu

retencji danych,o) przechowywania danych osobowych w postaci zaszyfrowanej.

9. Oferent powinien zapewnić możliwość oraz sposób wgrywania i usuwania krytycznych błędów Systemu.

10. System powinien spełniać następujące wymagania w zakresie konfiguracji i administracji:a) System powinien posiadać graficzną konsolę administracyjną, z pełną możliwością

wizualnego konfigurowania, monitorowania i zarządzania pracą i usługami Systemu; rekomendowany jest dostęp poprzez przeglądarkę internetową;

b) pożądane jest także, aby istniały inne metody konfiguracji, monitorowania i zarządzania, w tym zwłaszcza możliwość wykonywania skryptów konfiguracyjnych;

c) rozwiązanie architektoniczne powinno zapewnić możliwość łatwego przenoszenia konfiguracji pomiędzy różnymi środowiskami (np. deweloperskim, testowym i produkcyjnym); powinna być przy tym zapewniona kontrola integralności przenoszonej konfiguracji i jej walidacja;

d) System powinien posiadać bezawaryjne ustawienia domyślne – standardową reakcją na każde błędne żądanie powinna być odmowa działania; w efekcie, jeśli żądanie użytkownika zakończy się niepowodzeniem, System pozostanie bezpieczny.

C.5. Wymagania dotyczące szkoleń1. Oferta powinna obejmować przeprowadzenie szkoleń dla:

a) Użytkowników Systemu / Administratorów biznesowych (min. 2 dni szkoleniowe = 16 h),b) Administratorów i opiekunów Systemu – IT (min. 2 dni szkoleniowe = 16 h).

2. Każde szkolenie powinno zakończyć się testem sprawdzającym przyswojony materiał.3. Dodatkowe szkolenia Bank może zamówić w miarę potrzeb.4. Dla szkoleń dodatkowych Wykonawca w załączniku dotyczącym wynagrodzenia powinien

uwzględnić stawki za osobodzień związane z przygotowaniem szkoleń dodatkowych oraz ich przeprowadzeniem.

5. Szkolenia będą odbywały się w miejscu udostępnionym przez Zamawiającego. 6. W szkoleniach będzie uczestniczyć ustalona przez Bank liczba osób.

C.6. Wymagana dotyczące dokumentacji Systemu

Strona 31

1. Dokumentacja załączana do Systemu powinna zawierać:a) dokumentację powykonawczą:

specyfikację instalacyjno-wdrożeniową, opis architektury Systemu wraz z diagramem wdrożeniowym prezentującym

rozmieszczenie fizycznych składników systemu (artefaktów) i fizycznych elementów realizujących system (węzłów)

komponenty, użyte rozwiązania programistyczne, interfejsy z innymi systemami, zastosowane metody obliczeniowe wraz ze szczegółowym ich opisem, opis aspektów bezpieczeństwa zaimplementowanych w aplikacji.

b) specyfikację eksploatacyjną: dokumentację użytkownika:

o komplet informacji niezbędnych dla wszystkich grup biznesowych i operacyjnych Systemu,

o opis tabel bazodanowych, w tym tabel parametrycznych. dokumentację administratora:

o zasady zarządzania użytkownikami Systemu,o opis procedur operacyjnych,o opis procedur administracyjnych,o opis procedur instalacji,o opis środowiska Systemu,o opis procedur organizacyjnych,o opis procedur związanych z bezpieczeństwem Systemu (kopie zapasowe), w tym

opis procedur Backup/Recovery (BR) i Disaster Recovery (DR), o opis struktury baz danych,o dokumentację interfejsów.o zasady zarządzania danymi osobowymi (w tym w szczególności procesy

anonimizacji, psedoanonimizacji, realizacji do prawa bycia zapomnianym).c) dokumentację modelu danych, struktury bazy danych w tym w szczególności sposobu i

miejsca przechowywania w nim danych osobowych.

2. Dokumentacja powykonawcza powinna w szczególności spełniać następujące wymogi:a) specyfikować sposób instalacji z założeniem, że aplikacja działa zgodnie

z prawami dedykowanego użytkownika o minimalnych możliwych uprawnieniach; konieczne jest wyszczególnienie wszystkich potrzebnych praw do odczytu/zapisu zarówno do systemu plików jak i bazy danych;

b) specyfikować wszystkie dostępy sieciowe wymagane do poprawnej pracy produktu, nawet jeśli komponenty działają w obrębie pojedynczej maszyny; potrzebne informacje obejmują: protokół, porty (dla TCP, UDP), informacje dot. źródła i celu komunikacji (np. dla IP), informacje dotyczące kierunku nawiązywania sesji (np. TCP) lub opisu schematu komunikacji (np. UDP); w wypadku aplikacji wielokomponentowej z komunikacją opartą o protokoły TCP/UDP/IP należy założyć rozmieszczenie poszczególnych komponentów na różnych maszynach;

c) specyfikować wszystkie potrzebne komponenty systemowe oraz zasoby plikowe konieczne dla poprawnego działania aplikacji; dotyczy to również wszelkich podsystemów zewnętrznych (np. serwer poczty dla aplikacji wysyłającej maile) i bibliotek (np. ssl dla aplikacji wykorzystującej szyfrowanie);

d) specyfikować sposób instalacji przy założeniu fizycznej rozdzielności wszystkich komponentów składowych (dla aplikacji z komunikacją opartą o protokoły TCP/UDP/IP);

Strona 32

oznacza to, że instrukcja instalacyjna powinna uwzględniać to, że każdy ze składników pełnej instalacji: serwer aplikacyjny, baza danych oraz inne komponenty będą działać na innej maszynie fizycznej;

e) określać procedury włączania, wyłączania i upgrade oprogramowania;f) informować o zakresach koniecznych backupów, tak by można było odtworzyć

działającą aplikację przy założeniu korzystania wyłącznie z backupu i nośnika z plikami instalacyjnymi; w szczególności dotyczy to plików konfiguracyjnych i innych elementów niezbędnych do poprawnej pracy;

g) specyfikować procedury „odchudzania” i reindeksacji (jeśli to potrzebne) bazy danych poprzez wskazanie, które elementy bazy mogą być kasowane (archiwizowane) i które powinny być reindeksowane wraz z określeniem warunków wskazujących na potrzebę reindeksacji;

h) informować o koniecznych zadaniach okresowych potrzebnych do prawidłowego działania oprogramowania i bazy danych;

i) informować o koniecznych procedurach administracyjnych dla poszczególnych modułów Systemu;

j) określać procedury monitorujące (sposoby wykrywania problemów, klasyfikację problemów, sposób powiadamiania) oraz wskazywać, jakie informacje powinny być przekazywane do logów systemowych;

k) określać sposób postępowania w wypadku awarii poszczególnych modułów Systemu (np. baza danych, serwer aplikacji);

l) wyszczególniać wszystkie konfigurowalne zmienne techniczne i pozwalać na ich parametryzowanie (katalog Root aplikacji, ścieżki, dyski, adresy internetowe, nr-y portów, nazwa bazy danych);

m) nie zawierać opcji instalacyjnych dla nadmiarowego/niepotrzebnego oprogramowania (przykłady, Java SDK gdy wystarczy sam JRE, etc.);

n) zawierać opis sposobu konfigurowania opcji logowania;o) dokumentacja powinna być przygotowana w języku polskim.

3. Dokumentacja powinna umożliwiać przejęcie utrzymania Systemu przez własnych pracowników Banku lub podmiot zewnętrzny wybrany przez Bank.

4. Kolejne wersje dokumentacji powinny posiadać oznaczenie oraz metrykę zmian dokumentu (data wprowadzenia, osoby opracowujące i zatwierdzające).

C.7. Wymagana w zakresie serwisu i utrzymaniaBank oczekuje świadczenia przez Oferenta usług serwisowych w zakresie:

usuwania błędów oprogramowania, instalacji i parametryzacji nowych, przetestowanych wersji oprogramowania oraz asysty przy

ich instalacji, udzielania konsultacji i wsparcia w uzasadnionych przypadkach.

Umowa serwisowa musi zawierać mechanizmy kontrolne realizacji zgłaszanych ‘ticketów’ serwisowych, które umożliwią Bankowi odpowiedni nadzór nad realizowanymi naprawami.

W Ofercie prosimy przedstawić warunki oferowanego wsparcia wraz z ewentualnymi kosztami dalszego rozwoju Systemu na zlecenie Banku.

Strona 33

D. WYMAGANIA W ZAKRESIE WDROŻENIA

Mając na względzie doświadczenie Oferentów we wdrażaniu rozwiązań systemowych dla innych klientów, prosimy o przedstawienie rekomendacji odnośnie projektu wdrożenia. Oczekujemy również przedstawienia propozycji harmonogramu wdrożenia według najlepszych praktyk prowadzenia projektu.Oczekujemy przedstawienia środków oraz zasobów ludzkich niezbędnych do realizacji wdrożenia ze strony oferenta oraz oczekiwanych zasobów ze strony Banku. W szczególności prosimy o:1. propozycję harmonogramu wdrożenia z uwzględnieniem:

a) listy zadań, zakresu prac ze wskazaniem strony odpowiedzialnej za wykonanie poszczególnych zadań i prac,

b) planowanych etapów wraz z podaniem szacunkowych terminów rozpoczęcia i zakończenia prac,c) prezentację kluczowych członków zespołu wdrożeniowego i ich doświadczeń we wdrożeniach Systemu

w tym na rzecz innych banków w Polsce oraz UE i ich planowanego zaangażowania w projekt,d) określenie proponowanego planu zaangażowania personelu BOŚ S.A. (umiejętności, zaangażowanie

itd.),e) listę produktów projektu w powiązaniu z harmonogramem wraz z opisem.

2. Umowa zawierana będzie wg prawa polskiego w języku polskim jako wiodącym.3. Określenie nazwy, adresu i kraju siedziby podmiotu, którym BOŚ S.A. ewentualnie zawrze Umowę o

wdrożenie.4. Przedstawienie skróconej agendy warsztatów/szkoleń dla Systemów, dla których oferent oferuje usługi

wdrożeniowe.

Strona 34