Każdy nowoczesny informatyczny system bankowy przeznaczony dla banku wielooddziałowego o charakterze uniwersalnym powinny charakteryzować co najmniej takie cechy jak: orientacja na klienta, pakietowy styl zaprojektowania, umożliwiający definiowanie produktów bankowych dla zmieniających się potrzeb i dla różnych banków, kompleksowość rozwiązania, czyli obsługa wszystkich istotnych funkcji finansowych banku, dostarczanie on-line i w czasie rzeczywistym informacji o pozycji klienta oraz banku.

Praktycznym sprawdzianem stopnia orientacji na klienta jest możliwość otrzymywania w trybie on-line (czyli np. z terminala) i w czasie rzeczywistym (a wiec w danej chwili tj. poza wsadowym przetwarzaniem podczas zamknięcia dnia) informacji o pozycji klienta w przekroju operacji zagranicznych oraz na krajowym rynku pieniężnym, lokat, kredytów, itp. z rachunkiem strat i zysków (odsetki zapłacone, odsetki uzyskane, odsetki za przeterminowane kredyty, odsetki naliczone, pobrane opłaty...), gwarancji udzielonych, gwarancji otrzymanych, limitów, kategorii kredytowej itp.

Istnieją dwa główne obszary obsługi bankowej: komercyjna (zwana niekiedy "hurtową" od teminu angielskiego "wholesale banking") i okienkowa ("detaliczna" od "retail banking").

Obsługa komercyjna dotyczy depozytów i kredytów na duże kwoty (w stosunku do przedsiębiorstw oraz banków, papierów wartościowych i realizowana jest zwykle przez centralę banku np. przez departament rynku pieniężnego).

Obsługa hurtowa (komercyjna) zawiera m.in.: kredyty komercyjne (dla przedsiębiorstw), operacje międzybankowe i inne operacje (deposits and placements) na rynku pieniężnym, papiery wartościowe, operacje zagraniczne, akredytywy, płatności zagraniczne.

Obsługa okienkowa odnosi się do ludności (głównie konta osobiste, depozyty terminowe, pożyczki i kredyty dla osób fizycznych) i zwykle wykonują ją oddziały.

Podkreślenie znaczenia architektury jako fundamentu systemu jest bardzo ważne. Zdając sobie sprawę ze złożoności zagadnienia można krytycznie oceniać zdarzające się stwierdzenia autorów systemów, że np. system zorientowany na konta księgowe można łatwo lub szybko "przerobić" na styl orientowania na klienta, a system zdecentralizowany zorientowany na oddziały można bez problemu przekształcić na kompleksowy system obsługi całego banku, zaś system ukierunkowany na usługi komercyjne (hurtowe) na obsługę detaliczną.

Istotnym (a może nawet czasem decydującym) uwarunkowaniem architektury użytkowej są pakiety narzędziowo-usługowe, takie jak systemy zarządzania bazą danych lub zintegrowane słowniki danych on-line (umożliwiające tworzenie relacji), generatory menu i formatek ekranowych, języki zapytań i generatory raportów, narzędzia do polonizacji itp. Od nich zależy elastyczność systemu w zakresie struktur danych i raportów oraz efektywność przetwarzania danych. Aby zapewnić systemowi rozwojowość należy stosować pakiety otwarte, spełniające wymagania standardów międzynarodowych).

Zakres funkcjonalny systemu (w szczególności podział na moduły) nie powinien być odwzorowaniem struktury organizacyjnej banku, gdyż ulega ona częstym zmianom z rozmaitych powodów (również niefunkcjonalnych).

Jest jednak pewien zakres funkcjonalny minimum. System przeznaczony dla banku uniwersalnego powinien realizować rozległy zakres usług krajowych i zagranicznych. Skoncentruję się na rozwiązaniach najciekawszych i mało upowszechnionych w naszym kraju.

Księgowość

Księgowość z istoty swojej powinna być wielowalutowa. Stosowanie odrębnych modułów (programów) dla waluty lokalnej (złotówek) i odrębnych dla dewiz - tak często występujące w systemach krajowych - nie powinno mieć miejsca. Zakres definiowania parametrów dla produktów bankowych powinien być wystarczająco szeroki, aby spełnić wymagania obsługi dowolnych walut.

Wielowalutowość pełna polega na tym, że:

- prowadzone sa odrębne księgi główne dla poszczególnych walut i odrębna księga główna dla waluty podstawowej

- kontrakty z klientem mogą być zawierane na dowolne waluty

- transakcje moga występować w innych walutach niż konto (rachunek) do którego się odnoszą, np. transze kredytu mogą być realizowane w dowolnej walucie bez względu na walutę w jakiej kredyt został udzielony

- limity i zabezpieczenia kredytów mogą być w dowolnej walucie, np. innej niż kredyt, zaś stopień wykorzystania limitów lub zabezpieczenia liczony jest w stosunku do waluty bazowej (lub lokalnej)

- opłaty i prowizje mogą być w innej walucie niż rachunki i transakcje

- operacje kantorowe wymiany walut (np. USD na DEM) powinny być realizowane automatycznie (mimo przechodzenia przez walutę bazową)

- relacje między walutami w transakcjach bezgotówkowych uzyskiwane są poprzez ich bezpośrednie odnoszenie (cross rate), niezależnie od odniesienia do waluty bazowej

- wskazywany jest stopień ryzyka dla poszczególnych walut (exposure to foreign currency rate risk)

- prowadzony jest rachunek strat i zysków w rozliczeniach między-walutowych (foreign currency profit and loss closing features)

- dla każdej waluty (lub kraju) prowadzony jest odrębny kalendarz dni dni świątecznych

- dla każdej waluty można zdefiniować odrębny format (np. jeny japońskie nie mają miejsc po przecinku)

- przeliczenia międzywalutowe kontrolowane są poprzez tzw. zakres (minimum, maksimum) tolerancji kursów walutowych

- możliwe jest wprowadzenie pozycji walutowych do preliminarzy (w module budżetowania).

W systemach zachodnich nie wyróżnia się odrębnych modułów aplikacyjnych dla waluty krajowej i dewiz. Rachunki, lokaty i kredyty z definicji powinny być wielowalutowe, nie mówiąc już oczywiście o operacjach zagranicznych.

Niektóre systemy mają jedynie dualną wielowalutowość, polegającą m.in. na odnoszeniu dowolnej waluty w stosunku do waluty bazowej (zwykle jest nią dolar amerykański w module operacji zagranicznych i waluta lokalna w innych aplikacjach).

Należy zwrócić uwagę na konta pozabilansowe odgrywające ważną rolę w operacjach zagranicznych (wysłanie i potwierdzenie transakcji typu forward znajduje odzwierciedlenie na kontach pozabilansowych, dopiero realizacja transakcji i jej rzeczywisty wynik finansowy przechodzi do kont bilansowych), gwarancjach, w kredytowaniu (limity, nieściągalne kredyty i odsetki), obliczaniu przepływu gotówki do przodu, operacjach na rynku pieniężnym dokonywanych w imieniu klientów (fiduciary deposits /placements) itp.

W niektórych systemach scentralizowanych i wysoce zorientowanych na klienta traci na znaczeniu analityka księgi głównej (w księdze tej znajdują się wtedy konta zagregowane oraz syntetyczne) i nie wymaga się obsługi księgi głównej w czasie rzeczywistym. Bowiem możliwe jest sięganie bezpośrednie do danych operacyjnych i specjalizowanych zbiorów pośrednich zasilanych na bieżąco lub na żądanie, pomijając maszynochłonne przetwarzanie danych księgowych.

Maszynochłonność ta wynika z bardzo dużego wolumenu ksiegi głównej (liczy ona przy dużym stopniu analityczności zwykle kilkadziesiąt tysięcy pozycji) oraz dużej liczby automatycznych księgowan (na jedną transakcję bankową przypada zwykle kilka - czasem ponad dziesięć - transakcji księgowych).

W większych bankach liczba księgowań dziennie przekracza znacznie milion, w związku z czym zrozumiały staje się fakt, że system może obciążać utrzymywanie księgi głównej w czasie rzeczywistym (powodując czasem spowolnienie przetwarzania obsługi okienkowej klientów).

Przetwarzania wsadowego na koniec dnia nie można wyeliminować nie tylko ze względu na bilansowanie dzienne i drukowanie wyciągów oraz naliczanie odsetek, lecz również potrzeby rewaluacji operacji zagranicznych (wg kursów walut na zamknięcie dnia).

Skarb

Zarządzanie skarbowością jest jednym z najważniejszych modułów z punktu widzenia zarządzania finansami banku i zawiera m.in.:

1. Obliczanie płynności (liquidity) przepływu gotówki (cash flow) na dowolny okres do przodu (nawet do 5 lat);

2. Analiza rozbieżności (rozwarcia, rozstępu) między wpływem i wypływem gotówki, między kosztami (odsetki płacone przez bank) i dochodami (odsetki uzyskane od klientów);

3. Ocena ryzyka na podstawie stopnia wykorzystania (w tym przekroczeń) limitów , spłacalności kredytów, itp. z uwzględnieniem specyfiki poszczególnych transakcji (np.dla opcji ryzyko obliczane jest na podstawie róznicy między otwartymi pozycjami długo- i krótkoterrminowymi, dla FRA na podstawie sumy kapitału transakcji które jeszcze nie osiągnęły daty waluty itp.;

4. Opłacalność opłat i stóp procentowych;

5. Codzienne raportowanie pozycji banku (treasury position): ogólnej, wg walut oraz dla kombinacji walut wg rachunków NOSTRO/VOSTRO, departamentów (z podaniem kursu średniego) itp.

Moduł zarządzania skarbowością jest podstawą dla systemu informowania kierownictwa, w którym na szczególną uwagę zasługują:

- Przewidywanie wyników finansowych banku

a. "Projekcje" do przodu przepływu gotówki, strategie finansowe w zakresie inwestycji kapitałowych i zasilania finansami (funding operations) m.i. dostarczanie informacji do decyzji w zakresie wyboru krótko- lub długoterminowych długów albo wierzytelności, prezentacja stop procentowych niwelujących rozwarcie (tzw.break-even rate) i działań niezbędnych dla polepszenia płynności finansowej typu czy pożyczać pieniądze od kogoś, czy udzielać więcej kredytów.

b. Raportowanie typu "co stanie się jeśli", np. zmieni się stopa procentowa dla kredytów komercyjnych albo rozwarcie (gap) zwiększy się o 1%.

- Zarządzanie ryzykiem

a. Analiza dochodowości i ryzyka sali dealerskiej (m.in. poprzez rewaluację operacji typu forward i swap); arbitrażu i zabezpieczeń (hedging).

b. Analiza udzielanych kredytów (pod kątem stopnia spłacalności i zdolności kredytowej klientów).

c. Analiza wykorzystania (w tym przekroczen) limitów.

d. Sygnalizacja kredytów, dla których zabezpieczenie spadło poniżej wymaganego poziomu (np. w przypadku gdy zabezpieczeniem były lokaty dewizowe i nastąpił spadek kursów w stosunku do waluty kredytu lub waluty bazowej albo lokalnej).

e. Raportowanie zabezpieczeń, których termin ważności upłynął lub upłynie w ciągu najbliższych dni.

Informacje dla kierownictwa powinny być przentowane zarówno na ekranie, jak i na raportach, również w postaci graficznej. Zaawansowany moduł zarządzania skarbem (skarbowością) jest podstawą sprawnej obsługi informacyjnej kierownictwa.

Technologia

Architekturę systemu od strony technologicznej można przedstawić następująco:

FRONT-OFFICE (obsługa okienkowa)

a. Obsługa detaliczna klientów, czyli moduł dysponencko-kasowy (gotówkowe operacje na rachunkach, rozliczenie kas).

b. Sala dealerska (dealing room) (operacje dealerskie zagraniczne i na rynku pieniężnym, operacje dealerskie wewnętrzne - między departamentami banku).

W ramach obsługi okienkowej wygenerowana zostaje transakcja bankowa. Klient lub dealer otrzymuje pisemne jej potwierdzenie (świadectwo operacji), zaś kasjer jest komputerowo wspomagany (i kontrolowany) w zakresie rozliczenia gotówki w kasie.

Transakcja bankowa zostaje zarejestrowana w dzienniku chronologicznym transakcji danego dysponenta, niezależnie od jej wysłania do centrum przetwarzania.

BACK-OFFICE (zaplecze wsadowe)

a. Wprowadzanie transakcji nieoperacyjnych (nie wchodzących do obsługi okienkowej).

b. Weryfikacja transakcji i ewentualne skasowanie - najlepiej poprzez rewersję - nie zaakceptowanych transakcji dealerskich z pozostawieniem pełnych informacji śladowych dla potrzeb audytowych).

c. Uzupełnianie transakcji dealerskich o niekwotowe informacje szczegółowe niezbędne do rozliczeń (settlements details), od wprowadzenia których diler może być zwolniony w celu zwiększenia jego wydajności.

d. Uzgodnienie rachunków NOSTRO (na żądanie i ew. w procedurach zamknięcia dnia).

e. Zamknięcie dnia:

- naliczanie odsetek na kontach odsetkowych

- naliczenie opłat (za utrzymywanie rachunków, za transakcje itp.) i obciążenie nimi rachunków klientów

- realizacja stałych zleceń

- ew. rozpoczęcie lub usunięcie blokad terminowych

- przetwarzanie kont uśpionych

- wykonanie przerzutów międzyrachunkowych dla rachunków typu sweep

- rewaluacja operacji dealerskich wg kursu zamknięcia dnia

- generowanie rewersyjnych (stornujących) rewaluacji (przeszacowań ) dla dnia poprzedniego (lub księgowanie różnic)

- ostateczne aktualizacje zbiorów głównych i operacyjnych

- generowanie transakcji rewersyjnych dla nieaktualnych już operacji pozabilansowych (wykazanych w dniu poprzednim )

- bilanse dzienne

- rachunek strat i zysków

- raporty dzienne i okresowe (w tym wg miejsc powstawania kosztów/dochodów)

- raporty wyjątków (exception reporting)

- raport odrzuconych transakcji

- raport transferu rachunków między klientami

- raport zapadalności (lokat terminowych, operacji zagranicznych do przodu itp.)

- raporty analityczne operacji zagranicznych wg dealerów

- raport księgowań na kontach pozabilansowych, wydruk wyciągów (pożądane jest łączenie kilku rachunków w jeden wyciąg, co redukuje koszty wysyłki i papieru)

- przeniesienie informacji do archiwum

- usunięcie nieaktualnych plików z raportami

- ewentualne reorganizacje i optymalizacje alokacji zbiorów

- wysłanie lokalnych baz danych do oddziałów

- wysłanie do oddziałów oprogramowania nowych i zmodyfikowanych produktów bankowych, o odpowiedniej dacie

startowej

- wykonanie procedur zamknięcia miesiąca (jeśli przetwarzany jest ostatni dzień miesiąca) np. dla modułu księgi głównej

- wykonanie procedur zamknięcia roku (jeśli przetwarzany jest ostatni dzień roku) (sporządzenie raportów rocznych, roczna archiwizacja danych, przygotowanie baz danych do przyjęcia informacji dotyczących nowego roku - poprzez zerowanie pól bieżących, wyzerowanie kont dochodów i kosztów po zaksięgowaniu na kontach wynikowych itp.)

- ustawienie systemu na następny dzień roboczy.

Uwaga: w systemach scentralizowanych poza powyzszymi czynnościami zamknięcia dnia realizowanymi w centrum obliczeniowym wykonywane jest również zamknięcie dnia w oddziałach oparte na informacjach przechowywanych w serwerach oddziałowych (są to głównie dzienniki operacji wg dysponentów-kasjerów). Obejmuje ono m.in. rozliczenie kas, raportowanie danych sumarycznych oddziału (kwoty zbiorcze wg typów transakcji i ilość transakcji).

MID-OFFICE (zaplecze operacyjne dla potrzeb bieżącego zarządzania)

a. Obsługa komercyjna (operacje wielkokwotowe na rynku pieniężnym);

b. Obliczanie on-line pozycji klienta;

c. Rachunek on-line (na żądanie) strat i zysków dla stóp procentowych (różnica między odsetkami otrzymanymi i

wypłaconymi);

d. Dynamiczne raportowanie przepływu pieniędzy (dynamic cash flow) z projekcją na żądaną liczbę dni, miesięcy czy lat;

e. Inne żądania informacji w trybie on-line (dotyczące limitów,niezrównoważenia typu gaps np. między interest

income i interest expense);

f. Symulacja efektów zmiany stóp procentowych - typu "co będzie jeśli..." - np. jeśli kurs operacji spot obniży się lub podniesie o 10 punktów;

g. Informacja bieżąca w zakresie ryzyka kredytowego;

h. Informacje bieżące na temat ryzyka płynności (m.in. limitowanie wypływu gotówki w danym okresie dla danej waluty);

i. Informacje pomocnicze do strategii inwestowania (krótko czy długoterminowo);

j. Raportowanie wypływu / wpływu kapitału i odsetek;

k. Raportowanie dochodowości poszczególnych typów produktów;

l. Analiza kosztów obsługi produktów;

m. Przewidywany bilans księgowy na koniec okresu bieżącego (miesiąca) uwzględniający stan faktyczny na dzień poprzedni oraz prognozowane dane (wprowadzone dodatkowo przewidywane kwoty do poszczególnych pozycji aktywów, pasywów oraz obliczone kwoty oparte na datach zapadalności, datach waluty itp.);

n. Operacyjny bilans księgowy on-line dnia bieżącego (oparty na zamknięciu poprzedniego dnia oraz transakcjach dokonanych do danej chwili).

Jak z powyższego zestawienia wynika, mid-office (middle office) ukierunkowany jest na obsługę potrzeb informacyjnych kierownictwa.

Im bardziej nowoczesny system bankowy (oraz większe wymagania kierownictwa banku !) tym większa jest rola zaplecza operacyjnego zwanego mid-office.

Ze wszech miar warto tę właściwość polecić naszym krajowym twórcom systemów. Przybliża ona jakościowo systemy bankowe do klasy systemów ekspertowych i stanowi etap przejściowy od baz danych do baz wiedzy, od działań lokalnych tylko operacyjnych do prawie optymalnych działań strategicznych w skali banku.