Migracja core banking – jak ograniczyć ryzyko podczas przenoszenia danych i funkcji?

Dlaczego migracja core bankingu jest jednym z najbardziej ryzykownych projektów IT w banku?

Core banking odpowiada za podstawowe operacje bankowe, w tym obsługę rachunków, produktów finansowych, sald, księgowań i historii transakcji. Jego działanie jest powiązane z kanałami cyfrowymi, systemami płatniczymi, kartowymi, kredytowymi, raportowaniem oraz procesami operacyjnymi banku.

Wymiana takiej platformy oznacza ingerencję w system, od którego zależy ciągłość usług i poprawność danych finansowych. Błąd może zostać wykryty nie tylko podczas migracji, lecz również po kilku dniach – na przykład podczas naliczania odsetek, zamknięcia okresu rozliczeniowego albo przygotowania raportu.

Największe źródła złożoności to:

• Duża liczba zależności: wiele aplikacji odczytuje dane z core bankingu lub inicjuje operacje, które muszą zostać w nim zaksięgowane.
• Wieloletnia historia danych: rekordy mogą pochodzić z różnych wersji produktów, modeli danych i reguł biznesowych.
• Ograniczone okna serwisowe: bank nie może dowolnie wstrzymywać dostępu klientów do podstawowych usług.
• Wymagania audytowe: konieczne jest zachowanie historii operacji, korekt i możliwości ich odtworzenia.
• Reguły biznesowe ukryte w systemie: część zachowania starej platformy może wynikać z konfiguracji, historycznych wyjątków lub kodu, który nie został w pełni udokumentowany.

Dlaczego problemem nie jest tylko migracja danych?

Nowy system może poprawnie przechowywać wszystkie przeniesione rekordy, a mimo to inaczej interpretować ich znaczenie. Przykładowo reguły naliczania odsetek, zaokrąglania kwot, pobierania prowizji czy obsługi dat wartości mogą różnić się od zasad obowiązujących w dotychczasowej platformie.

Podobne ryzyko dotyczy statusów rachunków, blokad środków, limitów, korekt transakcji i produktów historycznych. Zgodność techniczna struktur danych nie jest więc równoznaczna ze zgodnością finansową i operacyjną.

Dla CTO oznacza to konieczność równoległego zarządzania dwoma rodzajami migracji: migracją danych oraz migracją zachowania systemu.

Jakie ryzyka trzeba zidentyfikować przed rozpoczęciem migracji core banking?

Rejestr ryzyk powinien powstać przed wyborem ostatecznej strategii migracji. Każde ryzyko należy powiązać z konkretną kontrolą, właścicielem odpowiedzialności oraz sposobem potwierdzenia skuteczności tej kontroli.

Ryzyko powinno być analizowane także w wymiarze operacyjnym: kto obsłuży reklamację dotyczącą transakcji wykonanej przed migracją, jak zostanie odtworzona historia rachunku i który system będzie źródłem prawdy w okresie przejściowym?

Plan migracji powinien uwzględniać odporność operacyjną banku, zarządzanie ryzykiem ICT, wpływ na usługi krytyczne, scenariusze awaryjne oraz zależności od dostawców technologicznych. Konkretne kontrole i obowiązki należy dopasować do profilu instytucji oraz zakresu projektu.

Big bang czy migracja etapowa – którą strategię wybrać?

Nie istnieje jedna strategia właściwa dla wszystkich banków. Wybór zależy od możliwości podziału produktów i portfeli, architektury księgowej, zależności integracyjnych, dostępnego okna przełączenia oraz akceptowalnego ryzyka operacyjnego.

Big bang migration – jednorazowe przełączenie

W podejściu big bang bank przenosi główny zakres danych i funkcji do nowej platformy podczas jednego zaplanowanego przełączenia.

Zaleta: krótszy okres współistnienia dwóch platform i mniejsza potrzeba utrzymywania długotrwałych integracji przejściowych.

Ryzyko: duży zakres jednoczesnej zmiany. Jeśli po uruchomieniu nowego systemu pojawią się problemy, ich skutki mogą obejmować znaczną część działalności banku.

Big bang wymaga szczególnie wysokiej gotowości danych, testów, zespołów operacyjnych i procedur awaryjnych.

Phased migration – migracja etapowa

Migracja etapowa polega na przenoszeniu kolejnych produktów, portfeli, grup klientów lub funkcji. Zakres pojedynczego przełączenia jest mniejszy, a organizacja może wykorzystać doświadczenia z wcześniejszych etapów.

Jednocześnie rośnie znaczenie architektury przejściowej. Bank musi wiedzieć, która platforma obsługuje konkretny rachunek, gdzie wykonywane są księgowania i jak zachować spójność danych pomiędzy systemami.

Migracja etapowa nie jest automatycznie bezpieczniejsza. Jeżeli nie można jednoznacznie rozdzielić odpowiedzialności za rachunki i operacje, współistnienie dwóch platform może zwiększać ryzyko.

Parallel run – równoległe porównywanie wyników

Parallel run oznacza wykonywanie wybranych procesów w starym i nowym środowisku w celu porównania rezultatów. Jest przydatny przy weryfikacji naliczania odsetek, reguł księgowych, opłat i raportów.

Nie powinien jednak oznaczać niekontrolowanego wykonywania rzeczywistych operacji finansowych w dwóch aktywnych systemach. Równoległe przetwarzanie wymaga zaprojektowania izolacji, symulacji lub innych mechanizmów eliminujących ryzyko podwójnego księgowania.

Porównanie strategii migracji

Alternatywą w określonych architekturach może być również strangler approach, czyli stopniowe zastępowanie funkcji starego systemu nowymi komponentami. Wymaga to możliwości izolowania usług oraz kontrolowanego przekierowywania ruchu. Podejście to nie rozwiązuje automatycznie problemów księgowych i migracji danych.

Jak przygotować dane do migracji core bankingu?

Przygotowanie danych powinno rozpocząć się od inwentaryzacji ich źródeł, znaczenia biznesowego i zależności. Sam eksport tabel z dotychczasowej bazy nie zapewnia wystarczającej wiedzy o tym, jak dane są wykorzystywane.

Inwentaryzacja i klasyfikacja danych

Zakres migracji może obejmować:

• Dane klientów i relacje między podmiotami.
• Rachunki i powiązane produkty finansowe.
• Salda oraz pozycje księgowe.
• Historię transakcji i korekt.
• Limity, blokady, zabezpieczenia i uprawnienia.
• Parametry produktów oraz reguły naliczania opłat.
• Dane archiwalne i audytowe.

Nie wszystkie dane muszą być przeniesione do tej samej warstwy systemu docelowego. Część historii może wymagać dostępności w odrębnym repozytorium. Taka decyzja musi jednak uwzględniać obowiązki retencyjne, potrzeby obsługi klientów, audyt i raportowanie.

Mapowanie danych między starym i nowym modelem

Mapowanie danych powinno opisywać nie tylko relację między polami, lecz również znaczenie każdej transformacji. Dla każdego krytycznego atrybutu warto określić źródło, regułę przekształcenia, oczekiwany format, walidację i właściciela biznesowego.

Najczęstsze problemy obejmują różnice w słownikach, brakujące wartości, odmienne modele rachunków, niespójne identyfikatory i różnice w sposobie zapisywania dat oraz walut.

Jeżeli nowy system wymaga wyliczenia wartości, która w starym była przechowywana bezpośrednio, należy udokumentować regułę obliczeniową i przetestować ją na reprezentatywnych przypadkach.

Data cleansing – kiedy poprawiać dane?

Problemy jakości danych należy wykrywać możliwie wcześnie. Nie oznacza to jednak, że dane finansowe można swobodnie modyfikować podczas migracji.

Każda korekta wpływająca na salda, historię operacji lub status produktu wymaga odpowiedniej podstawy, zatwierdzenia i ścieżki audytowej. Warto rozdzielić poprawki techniczne, takie jak ujednolicenie formatu, od zmian o znaczeniu finansowym lub prawnym.

Wczesne rozpoznanie problemów ogranicza liczbę wyjątków podczas cutover i koszt ręcznego wyjaśniania rozbieżności.

Jak zapewnić integralność sald, transakcji i danych księgowych?

To jeden z najważniejszych obszarów całego programu. Bank musi potwierdzić nie tylko kompletność migracji, lecz także zgodność finansową i biznesową danych po transformacji.

Kontrole powinny obejmować kilka poziomów:

1. Kompletność rekordów: czy wszystkie wymagane obiekty zostały przeniesione?
2. Integralność relacji: czy rachunki, klienci, produkty i transakcje pozostają prawidłowo powiązane?
3. Zgodność sald: czy wartości odpowiadają stanowi źródłowemu na ustalony moment?
4. Zgodność księgowa: czy agregaty i pozycje księgowe pozostają spójne?
5. Zgodność historii: czy zachowano transakcje, korekty i istotne powiązania?
6. Zgodność reguł: czy nowy system prawidłowo interpretuje dane i wykonuje operacje?

Dlaczego suma kontrolna danych nie wystarcza?

Zgodność liczby rekordów lub technicznych sum kontrolnych potwierdza jedynie określone właściwości danych. Nie dowodzi, że zachowano ich znaczenie biznesowe.

Przykładowo rachunek może zostać przeniesiony z prawidłowym identyfikatorem i saldem, ale z błędną konfiguracją naliczania odsetek. Techniczna walidacja migracji może wtedy zakończyć się sukcesem, mimo że przyszłe operacje będą niepoprawne.

Dlatego konieczne są uzgodnienia finansowe i testy funkcji biznesowych.

Jak obsługiwać transakcje w toku podczas przełączenia?

Cutover wymaga określenia punktu odcięcia danych i zasad obsługi operacji rozpoczętych przed przełączeniem. Dotyczy to między innymi transakcji oczekujących na zaksięgowanie, korekt, zleceń zaplanowanych oraz operacji przetwarzanych asynchronicznie.

Bank powinien wiedzieć, które operacje muszą zakończyć się w starym systemie, które mogą zostać przeniesione do nowego i jak uniknąć ich podwójnego wykonania.

Istotne są identyfikatory transakcji, mechanizmy idempotencji, kontrola kolejek oraz raporty uzgodnieniowe. Samo zatrzymanie interfejsu użytkownika nie oznacza, że wszystkie procesy finansowe zostały zakończone.

Jak dokumentować uzgodnienia danych?

Każda migracja próbna i produkcyjna powinna generować raporty obejmujące liczbę przeniesionych obiektów, wyniki walidacji, rozbieżności i status ich wyjaśnienia.

Raport powinien wskazywać właściciela akceptacji, moment wykonania kontroli oraz źródła danych użyte do porównania. Kryteria akceptacji muszą wynikać z rodzaju danych i wymagań banku. Nie należy zakładać dowolnej tolerancji dla krytycznych sald lub pozycji księgowych.

Jak przenosić funkcje biznesowe, a nie tylko dane?

Migracja core bankingu wymaga potwierdzenia, że nowa platforma poprawnie realizuje funkcje potrzebne do obsługi produktów i operacji bankowych. Samo odtworzenie danych nie zapewnia zgodności zachowania systemu.

Zakres testów funkcjonalnych powinien obejmować między innymi:

• Otwarcie, prowadzenie i zamknięcie rachunku.
• Naliczanie i księgowanie odsetek.
• Pobieranie opłat i prowizji.
• Obsługę blokad, limitów i dostępnych środków.
• Zmiany parametrów produktów.
• Zamknięcie dnia i inne procesy wsadowe.
• Korekty, reklamacje i operacje odwracające.
• Raportowanie oraz odtwarzanie historii operacji.

Jak wykryć różnice między logiką starego i nowego core?

Warto przygotować zestaw reprezentatywnych scenariuszy biznesowych i porównywać wyniki obu platform. Testy powinny obejmować zarówno standardowe przypadki, jak i sytuacje brzegowe: nietypowe daty, historyczne taryfy, zmiany oprocentowania, blokady czy korekty wcześniejszych operacji.

Różnice należy klasyfikować. Część będzie wynikała z błędu migracji, część z konfiguracji nowego systemu, a część z celowo zmienionych reguł biznesowych. Każda istotna różnica wymaga świadomej decyzji właściciela procesu.

Co zrobić z funkcjami, których nowy system nie obsługuje?

Bank może rozważyć trzy podejścia:

1. Konfigurację nowej platformy – jeśli brakującą funkcję można odtworzyć w ramach dostępnych możliwości systemu.
2. Rozwój dodatkowego komponentu – gdy potrzebna jest funkcjonalność niedostępna standardowo.
3. Pozostawienie wybranej usługi poza core – jeśli architektura i model operacyjny pozwalają na takie rozdzielenie.

Każda opcja wpływa na koszty utrzymania, odpowiedzialność za dane i liczbę integracji. Decyzja powinna być podjęta przed cutover, a nie dopiero po wykryciu braku funkcji na produkcji.

Jak przygotować integracje z systemami zależnymi od core bankingu?

Core banking rzadko działa w izolacji. Zmiana jego interfejsów, modelu danych lub sposobu obsługi operacji może wpłynąć na wiele usług, nawet jeśli ich interfejsy użytkownika pozostają bez zmian.

W inwentaryzacji należy uwzględnić:

• Bankowość internetową i mobilną.
• Systemy płatnicze i rozliczeniowe.
• CRM i systemy obsługi klienta.
• Systemy kredytowe.
• Systemy kartowe.
• AML i monitoring transakcji.
• Hurtownie danych i raportowanie.
• Systemy back-office oraz narzędzia operacyjne.

Szczególnej uwagi wymagają integracje płatnicze, w których zmiana systemu core banking może wpływać na mapowanie danych, obsługę statusów transakcji i wymianę komunikatów. Jeżeli bank równolegle dostosowuje swoje systemy do standardu opisanego w artykule ISO 20022 w integracjach płatniczych, warto skoordynować zakres zmian, scenariusze testowe i harmonogram przełączenia. Pozwala to ograniczyć ryzyko, że poprawnie zmigrowany core banking będzie wymagał dodatkowych zmian w przepływach płatniczych.

Jak wykorzystać API i warstwę integracyjną do ograniczenia ryzyka?

Stabilne kontrakty API, adaptery i warstwa oddzielająca systemy zależne od szczegółów implementacji core bankingu mogą ograniczyć zakres zmian wymaganych w całym środowisku.

Przykładowo kanał mobilny może nadal korzystać z tego samego kontraktu odczytu salda, podczas gdy adapter kieruje zapytanie do nowej platformy. Takie podejście nie eliminuje konieczności testów, ale zmniejsza liczbę komponentów wymagających bezpośredniej modyfikacji.

Właśnie dlatego integracja systemów bankowych jest istotnym elementem programu migracyjnego. Pozwala uporządkować zależności, zdefiniować kontrakty danych i przygotować architekturę przejściową bez niekontrolowanego mnożenia połączeń point-to-point.

Jak zapewnić prawidłowy routing w migracji etapowej?

W migracji etapowej system musi jednoznacznie ustalać, która platforma odpowiada za dany rachunek, produkt lub operację. Routing powinien wynikać z kontrolowanych reguł i aktualnego statusu migracji, a nie z przypadkowych wyjątków w kodzie poszczególnych aplikacji.

Szczególnej uwagi wymagają operacje obejmujące obiekty obsługiwane przez różne platformy. Trzeba określić sposób ich przetwarzania, księgowania i uzgadniania oraz odpowiedzialność za ewentualne błędy.

Podczas migracji trzeba również zweryfikować zależności między core bankingiem a systemami obsługującymi kredyty. Zmiana sposobu udostępniania danych o rachunkach, saldach i spłatach może wpływać na uruchamianie kredytów, harmonogramy spłat oraz obsługę zobowiązań. Dlatego architektura Digital Lending i procesów kredytowych powinna zostać uwzględniona w analizie zależności, testach end-to-end i planie cutover.

Jak testować migrację core bankingu przed uruchomieniem?

Testy powinny potwierdzać zarówno poprawność techniczną migracji, jak i gotowość operacyjną banku. Jednorazowy test transferu danych nie wystarcza do podjęcia decyzji produkcyjnej.

Migracje próbne i dry runs

Migrację należy wykonywać wielokrotnie w kontrolowanych środowiskach, wykorzystując reprezentatywne dane i powtarzalne procedury.

Każda próba powinna dostarczać informacji o czasie ekstrakcji, transformacji i ładowania danych, liczbie błędów, wynikach uzgodnień oraz czasie potrzebnym na obsługę wyjątków.

Ważne jest również potwierdzenie, że kolejna próba daje przewidywalne wyniki i nie wymaga nieudokumentowanych działań manualnych.

Testy end-to-end

Testy E2E powinny obejmować całe procesy biznesowe, a nie wyłącznie pojedyncze interfejsy.

• Operacje na rachunkach i zmiany sald.
• Płatności i księgowanie transakcji.
• Naliczanie odsetek oraz opłat.
• Zamknięcie dnia i przetwarzanie wsadowe.
• Integracje z kanałami cyfrowymi.
• Raportowanie i eksport danych.
• Obsługę błędów, ponowień i korekt.
• Scenariusze awaryjne oraz odtwarzanie usług.

Testy wydajności i odporności

Nowa platforma powinna zostać sprawdzona przy wolumenach odpowiadających rzeczywistemu obciążeniu oraz przy scenariuszach szczytowych. Testy muszą uwzględniać również procesy wsadowe, kolejki, opóźnienia integracyjne i zachowanie po awarii komponentów.

Wydajność należy porównywać z uzgodnionym poziomem usług, a nie wyłącznie z wynikiem laboratoryjnym.

User Acceptance Testing

Właściciele procesów bankowych powinni potwierdzić, że system prawidłowo obsługuje rzeczywiste scenariusze operacyjne. Dotyczy to szczególnie produktów historycznych, wyjątków i procesów wykonywanych rzadziej niż standardowe transakcje.

Akceptacja techniczna bez akceptacji biznesowej nie powinna być traktowana jako wystarczający warunek uruchomienia.

Jak zaplanować cutover i plan awaryjny migracji core banking?

Cutover to kontrolowane przełączenie obsługi określonych danych i funkcji ze starej platformy na nową. Jest momentem, w którym przygotowania techniczne, uzgodnienia finansowe i gotowość operacyjna muszą zostać połączone w jeden plan.

Co powinien zawierać plan cutover?

Plan powinien być szczegółowym runbookiem, a nie wyłącznie harmonogramem na poziomie projektu. Musi określać kolejność działań, odpowiedzialności, zależności, kryteria akceptacji i procedury komunikacji.

• Okno przełączenia i harmonogram operacji.
• Właścicieli poszczególnych kroków.
• Punkt odcięcia danych i obsługę transakcji w toku.
• Kontrole przed uruchomieniem.
• Kryteria go/no-go.
• Procedury komunikacji i eskalacji.
• Monitoring po przełączeniu.
• Scenariusze awaryjne i odpowiedzialność za decyzje.

Czy rollback core bankingu zawsze jest możliwy?

Nie. Po rozpoczęciu produkcyjnego przetwarzania nowych transakcji prosty powrót do starej platformy może być niemożliwy bez ryzyka utraty lub zdublowania operacji.

Dlatego plan awaryjny powinien rozróżniać kilka sytuacji:

• Rollback przed uruchomieniem produkcyjnym: powrót do starej platformy, zanim nowy system zacznie przyjmować rzeczywiste operacje.
• Kontrolowane wycofanie przełączenia: możliwe tylko przy spełnieniu określonych warunków dotyczących stanu danych i transakcji.
• Forward recovery: naprawa błędów i przywracanie poprawnego działania nowego systemu bez cofania całej migracji.
• Ograniczenie funkcjonalności: czasowe wyłączenie wybranych operacji, jeśli jest to konieczne do ochrony integralności danych.

Każdy scenariusz wymaga wcześniejszego przetestowania. Sam zapis „w razie problemów przywrócimy stary system” nie jest wystarczającym planem awaryjnym.

Jak ustalić kryteria go/no-go?

Decyzja o uruchomieniu powinna opierać się na wcześniej zatwierdzonych kryteriach, a nie na presji terminu.

Przykładowe warunki:

• Uzgodniono krytyczne salda i pozycje księgowe.
• Wyjaśniono lub formalnie rozstrzygnięto rozbieżności zgodnie z zasadami banku.
• Zakończono wymagane testy procesów i integracji.
• Potwierdzono gotowość operacyjną zespołów.
• Sprawdzono dostępność usług zależnych.
• Przetestowano procedury awaryjne.
• Potwierdzono gotowość monitoringu i obsługi incydentów.

Warto wyznaczyć osobę lub komitet uprawniony do podjęcia decyzji go/no-go oraz określić, które niespełnione kryteria bezwzględnie blokują przełączenie.

Jak monitorować nowy core banking po migracji?

Uruchomienie nowej platformy nie kończy programu migracyjnego. Po cutover rozpoczyna się okres hypercare, czyli wzmożonego monitorowania i obsługi problemów występujących w środowisku produkcyjnym.

W tym okresie szczególnej uwagi wymagają:

• Codzienne uzgodnienia sald i transakcji.
• Monitoring błędów księgowych oraz integracyjnych.
• Kontrola kolejek i opóźnień przetwarzania.
• Weryfikacja raportów i procesów wsadowych.
• Analiza zgłoszeń klientów i zespołów operacyjnych.
• Priorytetyzacja incydentów według wpływu biznesowego.
• Kontrola wydajności i dostępności usług.

Kiedy można bezpiecznie wyłączyć stary system?

Wyłączenie legacy powinno nastąpić dopiero po spełnieniu uzgodnionych kryteriów. Bank musi potwierdzić stabilność operacji, poprawność danych, zakończenie wymaganych uzgodnień oraz dostępność informacji historycznych.

W niektórych przypadkach konieczne będzie pozostawienie odrębnego dostępu do danych archiwalnych lub określonych funkcji historycznych. Nie oznacza to jednak, że stary system powinien bezterminowo pozostawać aktywną platformą transakcyjną.

Plan decommissioningu warto przygotować jeszcze przed migracją. W przeciwnym razie bank może przez długi czas ponosić koszty dwóch środowisk i utrzymywać dodatkową złożoność operacyjną.

Jak mierzyć powodzenie migracji core bankingu?

Samo uruchomienie nowej platformy nie dowodzi sukcesu migracji. Należy potwierdzić poprawność danych, stabilność usług, skuteczność procesów oraz postęp w wyłączaniu starego środowiska.

Wskaźniki powinny mieć zdefiniowane źródła danych, właścicieli i częstotliwość raportowania. Warto ustalić poziom bazowy przed migracją, aby można było ocenić, czy nowa platforma utrzymuje lub poprawia wymagany poziom usług.

Checklista gotowości do migracji core bankingu

Przed zatwierdzeniem terminu produkcyjnego przełączenia warto przeprowadzić formalny przegląd gotowości. Poniższa lista może służyć jako punkt wyjścia do rozmowy między zespołami technologii, operacji, ryzyka i biznesu.

Przykładowy scenariusz migracji wybranego portfela rachunków

Przykład hipotetyczny: bank planuje przeniesienie wybranego portfela rachunków na nową platformę core banking.

1. Identyfikuje dane, produkty i integracje związane z portfelem.
2. Mapuje modele rachunków, sald i transakcji.
3. Przeprowadza migrację próbną.
4. Uzgadnia salda oraz historię operacji.
5. Testuje naliczanie opłat, księgowania i procesy biznesowe.
6. Wykonuje próbę generalną cutover.
7. Podejmuje decyzję go/no-go na podstawie wyników kontroli.
8. Przeprowadza kontrolowane przełączenie.
9. W okresie hypercare monitoruje rozbieżności, incydenty i dostępność usług.

Efekty należy mierzyć liczbą i wagą rozbieżności, czasem migracji, stabilnością usług oraz czasem rozwiązywania incydentów. Przykład nie przedstawia rzeczywistego wdrożenia ani wyników konkretnego banku.

Kiedy warto zaangażować partnera technologicznego w migrację core banking?

Migracja systemu centralnego wymaga połączenia wiedzy o procesach bankowych z kompetencjami architektonicznymi, integracyjnymi i programistycznymi. Partner technologiczny może być szczególnie pomocny wtedy, gdy wewnętrzne zespoły muszą równolegle utrzymywać bieżące systemy i przygotowywać nową architekturę.

Edge One Solutions może wesprzeć zespoły bankowe w obszarach takich jak:

• Analiza zależności i architektury integracyjnej.
• Rozwój backendu oraz adapterów do systemów bankowych.
• Integracje API i obsługa przepływów danych.
• Modernizacja wybranych komponentów legacy.
• Automatyzacja testów integracyjnych i end-to-end.
• Rozwój narzędzi wspierających walidację i monitoring.
• Wzmocnienie zespołów developerskich i QA.

Warto określić odpowiedzialność partnera za konkretne komponenty i rezultaty, a także sposób współpracy z właścicielami systemu core, zespołami operacyjnymi i dostawcą platformy docelowej.

FAQ – migracja core banking