Specyfika informatycznych systemów dla bankowości

Bankowy system informatyczny aby był w stanie wspomagać kompleksowe i strategiczne działania banku, musi być wynikiem z góry założonej myśli konstrukcyjnej. Nie może więc powstawać w drodze przypadkowego tworzenia i "doklejania" kolejnych elementów. Z kolei myśl konstrukcyjna powinna być oparta na podstawach metodycznych. Bankowość ma pewną specyfikę, która musi znaleźć w tych podstawach odpowiednie odzwierciedlenie. Złożoność kompleksowego systemu dla banku uniwersalnego (wyrażana w tysiącach funkcji, intensywności i różnorodności transakcji w czasie rzeczywistym w bardzo dużych rozmiarach baz danych) oraz wysoki stopień ryzyka finansowego stowarzyszony z transakcjami, wymagają szczególnych metod projektowania.

Bankowy system informatyczny aby był w stanie wspomagać kompleksowe i strategiczne działania banku, musi być wynikiem z góry założonej myśli konstrukcyjnej. Nie może więc powstawać w drodze przypadkowego tworzenia i "doklejania" kolejnych elementów. Z kolei myśl konstrukcyjna powinna być oparta na podstawach metodycznych.

Bankowość ma pewną specyfikę, która musi znaleźć w tych podstawach odpowiednie odzwierciedlenie. Złożoność kompleksowego systemu dla banku uniwersalnego (wyrażana w tysiącach funkcji, intensywności i różnorodności transakcji w czasie rzeczywistym w bardzo dużych rozmiarach baz danych) oraz wysoki stopień ryzyka finansowego stowarzyszony z transakcjami, wymagają szczególnych metod projektowania.

W praktyce bankowej obok pojęć strukturalnych (pochodzących z tradycyjnych systemów informatycznych) takich jak podsystemy i moduły, stosuje się termin "produkty bankowe" (lub ściślej "typy produktów bankowych"), których w bankach uniwersalnych może występować nawet kilkaset. Przykładem typu produktu bankowego jest np. konto osobiste z limitem kredytowym, kredyt rewolwingowy, lokata terminowa 3- miesięczna, certyfikat depozytowy, operacja dealerska spot, akredytywa zagraniczna lub krajowa, obligacja roczna w pierwotnym obiegu, obligacja roczna we wtórnym obiegu itp. Produkty bankowe sa analizowane pod kątem zyskowności lub stopnia ryzyka podobnie jak klienci czy waluty. Produktom bankowym podporządkowane są transakcje, których sekwencja tworzy procesy. Dookoła produktu występuje więc specyficzne środowisko, obejmujące sekwencje transakcji oraz księgowań.

Już z powyższych rozważań wynika, że w bankowym systemie można wyróżnić pewne obiekty charakterystyczne: klient i jego rachunki, konta księgowe, waluta, limity, produkty bankowe, transakcje (rozumiana jako akcja, zdarzenie). Obsługa tych obiektów, a ściśle rzecz biorąc sposób ustalania relacji między nimi w przekroju całego systemu bankowego, decyduje o jakości architektury systemu. Wymienione obiekty jak nić przewodnia oplatają system bankowy, przechodząc przez wiele modułów aplikacyjnych. Nienależyte uwzględnienie któregokolwiek z tych elementów mocno obniża jakość systemu. Na przykład w niewielu systemach występuje możliwość definiowania transakcji i stowarzyszonych z nimi księgowań. W innych nie ma obsługi limitów, albo zawężone one są tylko do poszczególnych produktów.

Możliwość wyznaczania relacji w sposób elastyczny oraz zapewnienia zmienności obiektów (poprzez wprowadzanie parametrów) jest prawdopodobnie najtańszą i najszybszą metodą reorganizacji systemu bankowego i jego adaptacji do potrzeb rynku, nieporównywalnie lepszą od klasycznych zmian organizacyjnych w długim cyklu decyzyjnym (zlecenie oprogramowania nowych produktów, powoływanie nowych komórek organizacyjnych do obsługi nowych produktów, publikowanie regulaminów nie tyle dla klientów ile do szkolenia własnego personelu itp.) Skrócenie procesu decyzyjnego (przy równoczesnym lepszym zabezpieczeniu informacyjnym) oznacza również skrócenie drogi między klientem i bankiem.

Relacje na poziomie kont księgowych wyznaczane są stosunkowo prosto poprzez schematy księgowań oraz powiązania miejsc powstawania kosztów i dochodów. Do uzyskania innych relacji konieczne jest użycie np. relacyjnego albo hierarchicznego modelu danych oraz algorytmów.

Podstawowe nowe obiekty - klient, waluta, limity

Limity dotyczą kraju, regionu, branży, klienta (limit globalny - management limit - dla klienta i ew. jego macierzystej organizacji, limity przyznane dla kredytów, akredytyw, ujemnego salda na rachunku ror, itp.), dilera, waluty, typów transakcji (forex, rynek pieniężny, papiery wartościowe...) Przy okazji uwaga, iż suma limitów przyznanych może być większa od limitu globalnego, zaś limitów wykorzystanych powinna być mniejsza od niego. W systemie powinno być wiele list limitów, aby można było spełnić różnorodne wymagania banków. Limity powiązane są z zabezpieczeniami w tym blokowaniem depozytów, papierów wartościowych itp.

Obsługa limitów polega m.in. na:

- sygnalizacji przekroczeń limitów wg określonego schematu (kraj, waluta, klient, dilerzy, typy transakcji itp.) podczas wprowadzania transakcji

- bieżącej aktualizacji ich sald (w układzie limitów ustalonych, wykorzystanych i dostępnych), raportowaniu przekroczeń i wykorzystania limitów (na jakie cele zostały użyte)

- dostarczaniu analitycznych informacji do analizy przekroczeń limitów (wykaz wszystkich dokonanych transakcji wg podmiotu limitu, oddziałów, dilerów)

- raportowaniu limitów które tracą ważność itp.

Waluta i klient stanowią nieodłączny atrybut prawie każdego zdarzenia w systemie. Obliczanie pozycji klientów i walut wymaga ustalenia w architekturze systemu "ścieżek" dotarcia do wszystkich transakcji finansowych (czyli do wnętrza modułów aplikacyjnych). Wprowadzenie zmian projektowych dotyczących tych obiektów jest wobec tego bardzo pracochłonne i odpowiedzialne. Dlatego przed kupnem systemu trzeba ocenić na ile zaawansowana jest architektura systemu w zakresie orientacji na klienta, wielowalutowość, wielorakość limitów, definiowalność transakcji itp.

Zasady integracji

W czasie projektowania systemu powstają istotne problemy decyzyjne. Należy do nich m.in. podejście do integracji komponentów systemu. Ze względów czasowych i finansowych zwykle nie buduje się całego systemu od stanu zerowego lecz wykorzystuje się w nim specjalizowane pakiety aplikacyjne.

Nie można jednakże tworzyć systemu kompleksowego wyłącznie w drodze "dodawania" pakietów, gdyż "mimo, iż małe jest piękne", to "duże będące ich sumą" może okazać się tworem o niskiej wydajności (m.in. ze względu na pośrednictwo wielu mechanizmów interfejsowych) i trudnym do utrzymywania (każdy pakiet korzystać może z innej organizacji zbiorów, posiadać inną organizację menu i komunikację z użytkownikami itp.).

Szczególnie trudna sytuacja wystąpi w przypadku pakietów całkowicie autonomicznych, posiadających komplet swoich własnych danych (klientów, banków, walut, kont księgowych) i nie wyposażonych w odpowiednie łącza do innych aplikacji.

Integracja ich jest jeszcze bardziej utrudniona, jeśli przetwarzane są na różnych komputerach lub pod różnymi systemami operacyjnymi lub też używają różnych systemów zarządzania bazami danych. Realizowana jest ona wówczas poprzez mechanizmy importu i eksportu plików transakcyjnych, natomiast zbiory główne (bazy danych) takie jak informacje o klientach i rachunkach prowadzone są odrębnie w każdym module. Wprowadzenie kolejkowania transakcji w każdym module oraz ewentualna konwersja plików tekstowych transakcji na pliki formatowane zgodnie z wymaganiami modułu odbierającego na pewno będzie przyczyną spowolnienia systemu.

Równoległa eksploatacja nie powiązanych ze sobą pakietów aplikacyjnych może pogłębić (lub umocnić) dezintegrację organizacyjną banku, polegającą na tym, że poszczególne departamenty prowadzą "niezależną" działalność, korzystając z "własnych" źródeł informacji.

Zaniechanie integracji doprowadzi do rozchodzenia się poszczególnych zbiorów w zakresie tych samych informacji (np. jeśli każdy podsystem czy moduł będzie utrzymywał swoje własne zbiory). Stworzy to poważne trudności w uzyskiwaniu właściwych danych o pozycji banku i klientów.

Integracja powinna następować głównie poprzez stosowanie wspólnych zbiorów (klientów, bankow, rachunków Nostro, walut, kursów wymiany, stóp procentowych, itp), co jest najłatwiejsze do uzyskania jeśli w jądrze systemu zainstalowany będzie otwarty i odpowiednio sprawny relacyjny system zarządzania bazą danych. Operacje importu/eksportu danych powinny dotyczyć jedynie transakcji, a nie baz danych (dostęp do nich powinien być realizowany bezpośrednio). Stosunkowo łatwo jest integrować pakiety obsługujące operacje zagraniczne, pod warunkiem, że przestrzegane są w nich standardy komunikatów SWIFT.

Kompleksowe rozwiązania w systemie bankowym dlatego są trudne, gdyż muszą zapewnić odpowiedni "rozpływ" danych w trybie czasu rzeczywistego do wielu "pozycji": klienta oraz jego rachunków debetowych i kredytowych, typów produktów, limitów, walut, banków, dilerów itd.

Stopień złożoności modelu danych obejmujący nie tylko wiele obiektów lecz również wiele wyjątków algorytmicznych stanowi znaczne utrudnienia dla zastosowań pakietów typu case wspomagających projektowanie

Szczególnie zaawansowanej integracji wymaga zaplecze operacyjne dla potrzeb bieżącego zarządzania (zwane niekiedy middle-office) obejmujące m.in.: obliczanie on-line pozycji klienta, rachunek (na żądanie) strat i zysków dla stóp procentowych, dynamiczne raportowanie przepływu pieniędzy (dynamic cash flow) z projekcją na żądaną liczbę dni, miesięcy czy lat, inne żądania informacji w trybie on-line (dotyczące niezrównoważenia pomiędzy pobieranymi i płaconymi odsetkami, 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 pkt), informacje bieżące na temat ryzyka płynności (m.in. limitowanie wypływu gotówki w danym okresie dla danej waluty), raportowanie dochodowości poszczególnych typów produktów, przewidywany bilans księgowy na koniec bieżącego okresu rozliczeniowego.

Wydajnośći elastyczność

Ze względu na wymaganie wysokiej przepustowości (nawet setki tysięcy transakcji dziennie) projektanci muszą wybrać sprawną technologię przetwarzania transakcyjnego np. OLTP (On-Line Transaction Processing) z semantyką ACID (Atomicity,Consistency, Isolation, Durability), która w połączeniu z systemem zarządzania bazą danych powinna zapewnić systemowi odpowiednio wysoką przepustowość i niezawodność w warunkach dużej liczby równoczesnych (współbieżnych) użytkowników i transakcji. Dostateczna wydajność systemu jest warunkiem działania systemu w czasie rzeczywistym (co najmniej liczenie salda klienta oraz generowanie księgowań związanych z daną transakcją. W systemach scentralizowanych, ze względu na konieczność zminimalizowania obciążenia sieci, księgowania powinny być generowane w węźle centralnym a nie w punkcie rejestracji (np. oddziałach).

O elastyczności systemu świadczyć może wiele rozwiązań. Wymienimy ważniejsze z nich:

- technika definiowania menu na poziomie użytkownika (user defined) świadczy o elastycznej technice wywoływania funkcji/procedur/programów, co w niebagatelnym stopniu sprzyja rozwojowi systemu i dopasowywania go do potrzeb poszczególnych banków

- technika definiowania produktów i transakcji (definicje produktów przechowywane w odrębnym pliku a nie w kodach źródłowych)

- technika formułowania zapytań, tworzenia raportów, itp. (a w szczególności możliwość operowania w środowisku wielu zbiorów wchodzących w relacje pomiędzy sobą oraz w środowisku wielu modułów)

- elastyczność tworzenia tzw. kluczy dostępu takich jak nr klienta, nr konta księgowego itp. (niektóre systemy ograniczają je do automatycznie tworzonego numeru seryjnego).

Elastyczność systemu decyduje o pracochłonności tzw. kastomizacji, czyli dostosowania systemu do potrzeb

użytkowników. Niekiedy odróżnia się ją od tzw. lokalizacji, której zadaniem jest polonizacja komunikacji z użytkownikami (czyli menu, ekrany danych i komunikaty po polsku, polskie nagłówki i tytuły w tabulogramach) oraz zdefiniowanie produktów i transakcji.

W przypadku projektowania systemów scentralizowanych należy przewidzieć odrębny moduł aplikacyjny dla sytuacji, kiedy oddział zostaje pozbawiony łączności z centralną bazą danych. Awaryjne oprogramowanie z udziałem lokalnych danych daje zwykle możliwość okienkowej obsługi (front office) w ograniczonym zakresie i bez możliwości tzw. zamknięcia dnia. Zakres obsługi obejmuje głównie transakcje kasowe, oparte na saldzie rachunku klienta danego oddziału albo na zaufaniu (dla klientów zewnętrznych dla których brak informacji o saldach).

System zarządzania siecią powinien automatycznie rozsyłać po wszystkich oddziałach listy oddziałów znajdujących się w stanie awarii, aby stosowały one zasadę ograniczonego zaufania do klientów.

W kwestii wyboru pomiędzy systemem scentralizowanym i rozproszonym pomocny może być wniosek, iż w przypadku centralizacji najważniejszym czynnikiem staje się wysoka niezawodność sieci zaś przy rozproszeniu - jej duża przepustowość.

Zabezpieczenia systemu

Bankowy system informatyczny można zabezpieczyć różnorodnymi środkami, począwszy od inicjującego dostępu do systemu komputerowego, skończywszy na ograniczeniach związanych z realizacją elementarnych funkcji aplikacyjnych.

Zwykle nie wystarcza zabezpieczenie na poziomie systemu operacyjnego ograniczające dostęp do aplikacji poprzez hasło oraz nadające prawo do czytania, pisania, kopiowania, usuwania poszczególnych plików danych i programów. System operacyjny powinien rejestrować ślady logowania się do systemu. Na poziomie systemu operacyjnego aplikacja (oprogramowanie, pliki, bazy danych, tablice) powinna być chroniona przed jej usunięciem i zmianami, poza koniecznymi przypadkami w zakresie instalacji i reinstalacji aplikacji przez administratora systemu.

W ramach aplikacji zabezpieczenie polegać może na bardzo szczegółowym rozpisaniu (np. poprzez generowanie menu) dla poszczególnych użytkowników uprawnień wykonywania poszczególnych funkcji i przywoływania poszczególnych transakcji, uprawnień modyfikacji zawartości określonych pól itp. Ponadto na poziomie typów transakcji (do ich wprowadzania i autoryzacji) przydzielane są hasła i/lub limity kwotowe dla różnych grup personelu (kierowników, dysponentów, kasjerów i dilerów).

Hasła powinny być zmienne (np. co 3 miesiące), zaś ich ewidencja niezwykle staranna i prowadzona przez niewielką liczbę zaufanych osób. Możliwe jest dzielenie haseł pomiędzy np. dwie osoby (każda z nich zna część hasła - czyli do wykonania czynności niezbędna jest obecność obu tych osób).

System powinien utrzymywać automatycznie dziennik wejść do aplikacji, z podaniem daty i momentu wejścia, identyfikatora użytkownika, użytej klasy zabezpieczenia, nazw użytych funkcji i programów, adresu terminala i węzła, z którego nastąpiło wejście, itp.

Według amerykańskich standardów opracowanych przez Departament Obrony (Department of Defence National Computer Security Center) szczelność (zabezpieczenie) aplikacji oceniana jest na czterech poziomach (trusted computing base):

- grupa D (oznacza jedynie minimalne zabezpieczenie)

- grupa C (np. C2 narzuca kontrolowany dostęp)

- grupa B (wymaga dokładnego zabezpieczenia dostępu do systemu)

- grupa A (oznacza najwyższy stopień zabezpieczenia w zastosowaniach specjalnych).

Kryteria powyższe zwane są potocznie Pomarańczową Księgą TCSEC (Trusted Computer System Evaluation Criteria Orange Book) lub NCSC Lavender Book. W większości systemów bankowych występuje poziom zabezpieczenia C2, co wydaje się niewystarczające.

Wymagane jest również utrzymywanie śladów (audit-trail) po każdej operacji w celu umożliwienia cofania do źródła (od wyniku do transakcji wejściowej), aby uzyskać informacje: kto wprowadził, kiedy (data, godz, minuta), z jakiego oddziału i terminala, jakie księgowania zostały wygenerowane na podstawie transakcji wejściowej, z jakiej aplikacji nastąpiło wejście i z jakiego poziomu zabezpieczenia. Uprawnienie wykonania operacji bankowej powinno być kontrolowane poprzez limity kwotowe lub stowarzyszone z autoryzacją przez inną osobę.

Orientacja na klienta

Orientacja na klienta świadczy o nowoczesności systemu bankowego. Polega ona przede wszystkim na integrowaniu informacji o kliencie w skali całego systemu. W stosunku do zwykłych rozwiązań oznacza to rezygnację z fragmentarycznych informacji o klientach w poszczególnych modułach aplikacyjnych na rzecz wspólnej bazy danych o klientach, z której korzystają wszystkie moduły aplikacyjne, znajdujące się zarówno w centrali banku jak i w oddziałach. Oznacza to również przeciwdziałanie dublowaniu tych samych informacji w różnych miejscach i uproszczenie procedur aktualizacyjnych (aktualizuje się jedno miejsce przechowywania informacji).

Dzięki temu eliminowane jest wielokrotne wprowadzanie tych samych danych oraz uzyskuje się możliwość dogodnego, np. z ogólnego menu, uzyskania informacji o kliencie niezależnie od tego w jakim oddziale banku i w jakich transakcjach (i produktach) występował. Znając identyfikator klienta można więc np. otrzymać listę jego rachunków (debetowych, kredytowych) w banku, listę transakcji (od dowolnej daty akceptowanej przez archiwum operacyjne) na każdym z nich, itp.

Praktycznym sprawdzianem stopnia integracji informacji o klientach jest możliwość otrzymywania w trybie on-line (czyli np. z terminala) i w czasie rzeczywistym (a więc w danej chwili tj. poza wsadowym przetwarzaniem podczas zamknięcia dnia) informacji o pozycji klienta w przekroju operacji zagranicznych i 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.

Świadectwem zaawansowanej orientacji systemu na klienta może być np. raport pokazujący pozycję klienta do przodu (np. dzień po dniu na miesiąc od daty bieżącej) lub z datami wstecznymi. Informacje te pobierane są wtedy nie z księgi głównej lecz ze zbiorów operacyjnych (na podstawie efektywnych dat transakcji/dat waluty) w operacjach forwardowych, przewidywanych lub aproksymowanychstóp oprocentowania i kursów wymiany, itp.).

Z punktu widzenia technologii przetwarzania wyszukiwanie informacji o kliencie odbywa się bez konieczności wchodzenia do menu poszczególnych modułów czy też wybierania zespołów kont księgowych (jak to jest w przypadku orientacji systemu na konta księgowe), czy też wybierania poszczególnych oddziałów banku (jak to miałoby miejsce w systemach zdecentralizowanych).

W zależności od przyjętej technologii i systemu zarządzania bazą danych historyczne i bieżące dane o pozycji klienta mogą być trzymane w polach operacyjnej bazy danych (albo w zbiorze specjalnym pośrednim lub w zbiorze zwanym customer portfolio) lub być też obliczane każdorazowo na ządanie.

W przypadku przechowywania informacji w zbiorach otrzymujemy informacje natychmiast lecz "płacimy" za to zwiększonym zapotrzebowaniem na pamięć dyskową oraz bardziej pracochłonną aktualizacją zbiorów. W drugim przypadku dane wynikowe uzyskuje się poprzez każdorazowe czytanie odpowiednich plików źródłowych (w tym transakcyjnych), w związku z czym ze względu na znaczną chłonność mocy obliczeniowych zwykle jest to wykonywane dopiero podczas zamykania dnia.

Wspólna baza danych o klientach (zrealizowana jako jeden lub kilka zbiorów danych) - jak również ich rachunki - znajdować się powinna w centrum obliczeniowym i być dostępna w trybie on-line dla oddziałów. Wyodrębnienie kilku zbiorów dla klientów może być spowodowane różnymi przyczynami. Zwykle jest nią typ podmiotu (osoba fizyczna, firma, bank) wymagający specyficznych dla siebie pól danych.

Czasem wydziela się również pliki klientów nie będących klientami banku lecz klientami klientów banków lub ich bankami korespodentami. W ten sposób przewciwdziała się "zaśmieceniu" wspólnych baz danych klientami przypadkowymi (np. przy obsłudze przelewów zagranicznych). Klienci jednorazowi mogą być wprowadzani do płatności bezpośrednio z klawiatury i lokowani w zbiorach historycznych - poza główną bazą danych - do ewentualnego powtórnego wykorzystania.

Orientacja na klienta oznacza również usprawnienie z nim łączności. Istnieją systemy bankowe, w których rezygnuje się z papierowej emisji wyciągów bankowych na rzecz przesyłania ich poprzez pocztę elektroniczną na stacje robocze u klienta.

Niekiedy klient jest zintegrowany z systemem poprzez wysunięty terminal (lub własny komputer typu PC w ramach tzw. home banking) z uprawnieniami przeszukiwania stanu i historii własnych rachunków, składania zleceń przelewów, przeglądania kursów walut i prowizji, zgłaszania zastrzeżeń czeków, składania wniosku o wystawienie książeczki czekowej, żądania przesłania papierowego wyciągu z konta, umówienia spotkań biznesowych z pracownikami banku, żądania regulaminów określonych produktów bankowych itp.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200