Księga Główna jako wyzwanie podczas modernizacji systemu centralnego banku

Dlaczego banki wprowadzają nowoczesne systemy centralne? Jak integracja z Księgą Główną (General Ledger) różni się dla nowoczesnych systemów centralnych? Jakie wyzwania stoją przed bankami integrującymi nowoczesne systemy centralne z istniejącym GL? Kompleksowość tematu przybliża Aleksander Rujna, Lead Business Analyst w GFT.

Czym jest Księga Główna (GL)?

Na początku warto wyjaśnić co kryje się pod nazwą General Ledger i skrótem GL. Można to rozumieć na dwa sposoby. Pierwszy to zespół Księgi Głównej, zespół ludzi w każdej dużej organizacji. Odbywa się w nim weryfikacja wszystkich faktur, sprawdzanie danych finansowych w systemie, uzgadnianie sald, dokonywanie przelewów bankowych, udział w zamknięciach miesiąca, kwartału i roku. Drugi to Księga Głowna jako oprogramowanie, którego organizacja używa do ewidencjonowania swoich operacji finansowych. W tym artykule GL jest rozumiany jako oprogramowanie stosowane w banku do sporządzania raportów finansowych.

Czym są systemy centralne i jak je modernizować?

System centralny (core banking) to z kolei zintegrowany system informatyczny używany przez banki do zarządzania swoimi podstawowymi operacjami finansowymi i usługami. System ten obejmuje kluczowe funkcje, takie jak obsługa kont klientów, przetwarzanie transakcji, zarządzanie depozytami, kredytami a dzięki temu umożliwia też raportowanie finansowe. Oprócz tego, core banking umożliwia bankom śledzenie i zarządzanie informacjami o klientach, ich rachunkach, historii transakcji, limitach kredytowych i innych aspektach związanych z relacją z klientem. Daje on również bankom możliwość integrowania różnych kanałów komunikacji takich jak oddziały, bankowość internetowa, bankowość mobilna i bankowość telefoniczna, co z kolei pozwala klientom na dostęp do swoich kont i wykonywanie transakcji na różne sposoby.

Dlaczego banki wprowadzają nowoczesne systemy centralne? Modernizacja systemu core banking jest istotna z kilku powodów, które dotyczą efektywności operacyjnej banku, konkurencyjności na rynku i dostarczania lepszych usług klientom. Podstawowa bankowość powinna być stale udoskonalana, aby poprawiać jakość obsługi klienta. Mowa tu między innymi o wymianie, aktualizacji lub outsourcingu istniejących systemów bankowych oraz infrastruktury IT. Ubiegłoroczny raport GFT „Przyszłość systemów centralnych. Czy już czas na chmurę?” pokazuje, że firmy dodatkową motywacją do modernizacji systemów bankowych upatrują w możliwości lepszego dopasowania produktów i usług do potrzeb klientów oraz realizacji strategii rozwoju banków. Przedstawiciele banków oczekują, że wprowadzane zmiany przyczynią się do skrócenia czasu wdrożenia nowych usług, a także zmniejszenia kosztów utrzymania istniejących aplikacji IT.

Wyzwania

Doświadczenie rozmów z naszymi klientami pokazuje, że pierwszym wyzwaniem jest zbudowanie zrozumienia wśród decydentów w banku, że modernizacja systemu centralnego będzie wiązała się z integracją z systemem księgi głównej. Nie wiąże się to z zadowoleniem klienta, redukcją kosztów, unowocześnieniem technologii czy innymi korzyściami, które motywują banki do modernizacji, więc nie jest dyskutowane w momencie przekonywania decydentów do przeznaczenia pieniędzy na projekt. Gdy ten temat się w końcu pojawi to budzi obawy o wzrost kosztów. Koszty te zwykle stanowią małą część wyceny, pod warunkiem wzięcia pod uwagę wyzwań i zaadresowania ich na wczesnym stadium.

Cały proces księgowania w GL składa się z kilku etapów, sprawdźmy na czym polegają i jakie wyzwania pojawiają się w każdym z nich.

• Mapowanie transakcji

Z założenia system centralny odzwierciedla transakcje które są dokonywane przez klienta. Pierwszym wyzwaniem jest zrozumienie jak te same transakcje będą odzwierciedlone w księdze głównej. W zależności od wybranego systemu centralnego może się to dokonać poprzez nałożenie istniejących w nim kont na konta księgi głównej albo poprzez dodatkowy moduł, który stworzy bardziej skomplikowane mapowanie nie tylko na podstawie kont lokalnych (czyli planu kont w systemie centralnym), ale też na podstawie dodatkowych parametrów. Przykładem takich parametrów może być rodzaj produktu albo sektor klienta. Jest to proces, który zależy od rodzaju produktów, struktury systemu centralnego i planu kont GL. Podstawowym wyzwaniem jest stworzenie takich mapowań, ustalenie jakie parametry będą brane pod uwagę i jak zachowania produktu będą wyglądać w księdze głównej. W tym zadaniu powinni uczestniczyć eksperci z zespołu księgowości banku. W wyniku tego powinna zostać zaproponowana adekwatna i nowoczesna architektura, która umożliwi poprawne zaimplementowanie powyższych wymagań. Niezbędnymi elementami mogą być komponenty tzw. Master Data, które precyzyjnie opisują znaczenie danych w kontekście GL.

Dodatkowo powinien powstać proces, który określi w jaki sposób mapowania będą utrzymywane: jak będą wprowadzane zmiany i jak będą tworzone nowe w przypadku dodawania kolejnych produktów, kto będzie to robił po zakończeniu projektu, jak i kogo powiadamiać, że jakiegoś mapingu brakuje.

Przy mapowaniu transakcji należy zwrócić uwagę nie tylko na wymagania księgi główniej ale też te dotyczące raportowania regulacyjnego. Zgodnie z raportem GFT o systemach centralnych, banki uznają dostosowania regulacyjne, w tym raportowe, za ogromne wyzwanie stojące przed nimi. Wymagania w tym zakresie są ciągle rozbudowywane i są one sprawdzianem nie tylko dla danych zawartych w księdze głównej ale też tych które są odzwierciedlane w systemie centralnym. Najpopularniejsze systemy monolityczne zostały wprowadzone na długo przed pojawieniem się obecnych wymogów raportowych. Powoduje to, że banki często mają rozbudowane działy operacji, które zajmują się integracją i korygowaniem danych. Uwzględnienie w systemie centralnym wymiarów, które są niezbędne do raportowania regulacyjnego, pozwala na uniknięcie wielu godzin pracy działu operacji, często pracy skomplikowanej, a przez to podatnej na błędy. Niezależnie czy raportowanie regulacyjne wykorzystuje to samo oprogramowanie co księga główna, czy jest tworzone na podstawie danych zebranych (np. w osobnej bazie danych, hurtowni danych czy data lake) wzbogacanie danych o dodatkowe wymiary powinno zachodzić w jednym miejscu, tak aby ograniczyć ryzyko niezgodności.

• Wysłanie transakcji do księgi głównej

Po ustaleniu jak transakcje będą odzwierciedlane w księdze głównej należy rozważyć jak przebiegnie integracja. Nowoczesne systemy centralne są zdolne do przesyłania i prezentowania strumieniowego transakcji w czasie zbliżonym do rzeczywistego. Pozwala to na natychmiastowe odzwierciedlenie ich na kontach księgi głównej, tym samym można użyć jej do dodatkowych celów wymagających danych w czasie rzeczywistym. Przykładem może być zarządzanie aktywami i pasywami (asset and liabilities management), gdzie działanie w czasie rzeczywistym pozwala na oszczędności. Limitem jest tutaj zdolność oprogramowania GL do odbierania przetwarzanych strumieniowo transakcji. Choć takie rozwiązanie czy to używające API czy systemów kolejkowych stają się obecnie standardem to często istniejące systemy w bankach ich nie obsługują. W takim wypadku opcją jest przygotowanie pliku wsadowego. Najczęściej po zakończeniu procesów na koniec dnia, takich jak naliczenie odsetek i księgowanie przeterminowanego zadłużenia, następuje proces stworzenia pliku zawierającego balanse i transakcje zagregowane według wymiarów występujących w księdze głównej. Podstawową trudnością jest określenie momentu, w którym wszystkie transakcje dotyczące dnia poprzedniego zostały zaksięgowane. Działanie nowoczesnych systemów w czasie rzeczywistym rodzi problem jak zaimplementować w nich procesy wsadowe. Wymaga to analizy biznesowej i stworzenia mechanizmu wyzwalaczy, które powodują automatyczny start tworzenia pliku wsadowego gdy wszystkie potrzebne transakcje zostają przeprocesowane.

• Rekoncyliacja

Bank jest zobowiązany wykazać, że stany kont w księdze głównej są monitorowane i uzgadniane. Wynika to z wymogów regulacyjnych i audytowych. System centralny jest jednym z wielu zawierających balanse, które powinny być uzgodnione. Ze względu na jego istotność dla podstawowej działalności i skomplikowanie, jego rekoncyliacja jest elementem, który powinien być brany pod uwagę już na wczesnym etapie projektu. Nowoczesne systemy centralne zwykle korzystają z mikroserwisów w warstwie integracji. Niesie to wiele korzyści biznesowych, ale tworzy też dodatkowe komplikacje. W przypadku integracji polegającej na przesyłaniu strumieniowym transakcji komplikacją jest sprawdzenie, że wszystkie wyemitowane transakcje zostały odpowiednio wczytane. Dopiero wtedy można rozpocząć proces porównywania balansów na poszczególnych kontach. W przypadku integracji poprzez plik wsadowy problemem jest stworzenie dodatkowej logiki, która nie duplikuje tej tworzącej plik tak, by porównanie miało wartość i pozwalało rzeczywiście wyłapać błędy. W przypadku wszelkich agregacji istotna jest możliwość śledzenia transakcji, które weszły w skład zagregowanych danych. Dodatkowo warto wziąć pod uwagę, że proces powinien być jak najbardziej zautomatyzowany. W idealnym świecie wszelkie pojawiające się różnice powinny być wyłapane na etapie zapewnienia jakości (quality assurance) projektu integracji.

• Obserwowalność (observability)

Obserwowalność to w przypadku tworzenia systemów rozproszonych zdefiniowanie stanu pożądanego i monitorowanie odchyleń, tak by można odpowiednio wcześnie wykryć odstępstwa i zareagować. Nowoczesne systemy centralne są tu dobrym przykładem. Zbudowana wokół nich architektura mikroserwisów pozwala na szybkie wprowadzanie nowych produktów (time to market) i bardzo dużą elastyczność. Z drugiej strony błąd w jednym z jej elementów może przenieść się na nieprawidłowe działanie innych więc ważne jest, żeby zintegrować observability w ramach całej infrastruktury, tak by móc monitorować proces od początku do końca. Księgowanie transakcji do GL jest jednym z logicznych końców procesu. Dlatego warto przewidzieć potencjalne zdarzenia z infrastrukturą i móc ustawić odpowiedni monitoring i alerty. Elementami observability są logi zdarzeń, metryki – takie jak zużycie mocy obliczeniowej albo pamięci, tracing czyli śledzenie procesowania żądania (np. pojedynczej transakcji) przez elementy systemu. Warto pamiętać, że oprogramowanie księgi głównej stanowi osobny komponent, często z oddzielnym działem odpowiedzialnym za jego utrzymanie i monitoring. Jedną z odpowiedzi na to jest procesowanie informacji zwrotnej do serwisów odpowiedzialnych za ładowanie danych tak, aby można rozszerzyć zaimplementowane w nich narzędzie observability do sprawdzania stanu całego połączenia.

Podsumowując, korzyści z wprowadzania nowoczesnych systemów centralnych dotyczą przede wszystkim lepszego dopasowania produktów do potrzeb klientów, szybszego uruchamiania nowych produktów i zmniejszenia kosztów utrzymania systemu. Podstawową różnicą dla integracji z Księgą Główną jest domyślny brak procesów wsadowych co pozwala na szybkie odzwierciedlenie danych w systemach raportowych, ale także tworzy wyzwania dla integracji. Pozostałymi wyzwaniami są: zbudowanie świadomości decydentów, stworzenie mapingu transakcji z uwzględnieniem raportowania regulacyjnego, opracowanie silnika księgowego, rekoncyliacja i integracja z narzędziami observability. Dla powodzenia projektu powinny być one zaadresowane już na etapie planowania.