de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Studium przypadku: Modernizacja architektury internetowego bankowości BigBank

Wprowadzenie

W dzisiejszych czasach, w świecie bankowości skupionej na cyfryzacji, instytucje finansowe stoją przed krytycznym wyzwaniem modernizacji swojej infrastruktury technologicznej, zachowując jednocześnie bezpieczeństwo, niezawodność oraz płynne doświadczenie dla klientów. Niniejsze studium przypadku analizuje projekt architektury systemu internetowego bankowości BigBank z perspektywy modelu C4, hierarchicznego frameworku do wizualizacji architektury oprogramowania, który dzieli projekt systemu na poziomy Kontekst, Kontenery, Komponenty i Kod.
Skupiając się na poziomieDiagram kontenerówpoziomie, analiza ujawnia, jak BigBank zorganizował architekturę wielowarstwową łącząc nowoczesne aplikacje internetowe i mobilne z systemami głównymi z dziedzictwa. Diagram wyróżnia wybrane technologie, protokoły komunikacji oraz przepływy danych, które pozwalają klientom indywidualnym bezpiecznie uzyskiwać dostęp do swoich kont przez różne kanały. Ten podejście architektoniczne pokazuje, jak tradycyjne instytucje bankowe mogą rozwijać swoje możliwości cyfrowe bez rezygnacji z sprawdzonych systemów jądrowych, oferując cenne wskazówki dla organizacji przeprowadzających podobne przeobrażenia cyfrowe.

1. Podsumowanie dla zarządu

To studium przypadku analizuje projekt architektury systemusystemu bankowości internetowejdla fikcyjnej instytucji finansowej „BigBank”. Celem projektu było zapewnienie klientom indywidualnym bezpiecznego, dostępnego i wielokanałowego dostępu do ich kont (poprzez internet i urządzenia mobilne), jednocześnie integrując się z istniejącą dziedziczną infrastrukturą jądrowej bankowości.

Architektura została zapisana przy użyciumodelu C4 (Diagram kontenerów), który wizualizuje wybrane technologie na najwyższym poziomie oraz sposób działania kontenerów systemu (aplikacje, bazy danych itp.).

C4 Model Container Diagram for Internet Banking System

2. Wyzwania biznesowe

  • Integracja z systemami dziedzicznymi:Bank posiada solidny, ale starszy „System bankowy główny”, który zawiera podstawową prawdę o danych klientów. Nowy system musiał ujawniać te dane bez natychmiastowego zastąpienia systemu głównego.

  • Dostęp przez wiele kanałów:Klienci żądali dostępu zarówno przez przeglądarki na komputerach stacjonarnych, jak i urządzenia mobilne.

  • Bezpieczeństwo:Przetwarzanie wrażliwych danych finansowych wymaga ścisłej uwierzytelniania oraz bezpiecznych kanałów komunikacji.

3. Rozwiązanie architektoniczne (Widok kontenerów C4)

Rozwiązanie zostało zaprojektowane jako system rozłączony, w którym warstwa prezentacji jest oddzielona od warstw logiki biznesowej i danych.

A. Warstwa interfejsu użytkownika (Frontendy)

System obsługuje trzy różne punkty wejścia dlaklienta indywidualnego:

  1. Aplikacja jednostronicowa (SPA):

    • Technologia: JavaScript i Angular.

    • Rola: Działa w przeglądarce internetowej klienta. Zapewnia pełny kompletny zestaw funkcji bankowości internetowej. Jest to dynamiczny, reagujący interfejs, który komunikuje się asynchronicznie z backendem.

  2. Aplikacja internetowa:

    • Technologia: Java i Spring MVC.

    • Rola: Działa jako punkt wejścia do doświadczenia internetowego. Dostarcza zawartość statyczną (HTML/CSS/JS) i hostuje aplikację jednostronicową. Służy jako „uruchamiacz” aplikacji Angular.

  3. Aplikacja mobilna:

    • Technologia: Xamarin (umożliwia rozwój dla wielu platform, prawdopodobnie iOS i Android).

    • Rola: Zapewnia „ograniczony zestaw” funkcji zoptymalizowanych pod urządzenia mobilne. Oznacza to, że złożone zadania (np. ustawianie międzynarodowych przelewów) mogą być ograniczone do pełnej aplikacji internetowej/SPA, podczas gdy typowe zadania (sprawdzanie salda) są dostępne na urządzeniach mobilnych.

B. Warstwa logiki biznesowej (backend)

  • Aplikacja API:

    • Technologia: Java i Spring MVC.

    • Rola: To jest centralny układ nerwowy architektury. Działa jako Brama API lub Backend dla frontendu (BFF).

    • Funkcja: Dostarcza interfejs API JSON/HTTPS dla klientów internetowych i mobilnych. Obsługuje uwierzytelnianie, autoryzowanie oraz koordynację żądań danych.

C. Warstwa danych i integracji

  1. Baza danych:

    • Technologia: Schemat bazy danych Oracle.

    • Rola: Przechowuje dane specyficzne dla internetowego bankowości. Obejmuje informacje o rejestracji użytkownika, zahashowane dane uwierzytelniające (praktyka najlepsza w zakresie bezpieczeństwa), oraz dzienniki dostępu. Nie przechowuje nie rzeczywistych sald bankowych (są one w systemie głównym).

    • Komunikacja: Aplikacja API odczytuje/zapisuje dane do tej poprzez JDBC.

  2. System bankowy główny:

    • Rola: System źródłowy. Przechowuje podstawowe informacje bankowe (klienci, konta, transakcje).

    • Komunikacja: Aplikacja API komunikuje się z systemem głównym za pomocą XML przez HTTPS. Oznacza to, że system główny prawdopodobnie jest starszym usługą opartą na SOAP lub starszym systemem wymagającym wymiany strukturalnych danych XML.

  3. System poczty e-mail:

    • Technologia: Microsoft Exchange.

    • Rola: Obsługuje powiadomienia.

    • Komunikacja: Aplikacja API wysyła e-maile poprzez SMTP do serwera Exchange, który następnie dostarcza je do klienta.

4. Kluczowe przepływy danych i przebiegi użytkownika

Scenariusz 1: Logowanie za pomocą przeglądarki internetowej

  1. The Klient prywatny bankowości przechodzi do bigbank.com/ib używając HTTPS.

  2. Żądanie trafia do Aplikacja internetowa (Java/Spring MVC).

  3. Aplikacja internetowa dostarcza Aplikacja jednostronicowa (Angular) do przeglądarki klienta.

  4. Klient wprowadza dane logowania w aplikacji jednostronicowej.

  5. Aplikacja jednostronicowa wykonuje wywołanie interfejsu API (JSON/HTTPS) do Aplikacja interfejsu API.

  6. Aplikacja interfejsu API weryfikuje dane logowania w stosunku do Bazy danych (przez JDBC).

  7. Po pomyślnym zalogowaniu aplikacja jednostronicowa żąda sald kont. Aplikacja interfejsu API pobiera te dane z System bankowości główny (XML/HTTPS) i zwraca je do aplikacji jednostronicowej.

Scenariusz 2: Powiadomienie o transakcji mobilnej

  1. Klient dokonuje płatności przez Aplikację mobilną (Xamarin).

  2. Aplikacja wysyła żądanie do Aplikacja API.

  3. Aplikacja API przetwarza płatność za pomocą Mainframe.

  4. Aplikacja API wywołuje e-mail potwierdzający, wysyłając żądanie SMTP do System e-mailowy (Exchange).

  5. Klient otrzymuje powiadomienie e-mail.

5. Kluczowe aspekty techniczne i najlepsze praktyki

  • Oddzielenie odpowiedzialności: Diagram jasno oddziela dane specyficzne dla „Internet Banking” (baza danych Oracle) od danych „Bankowości Głównej” (mainframe). Zapobiega to bezpośredniemu dostępowi warstwy internetowej do podstawowego księgowania finansowego.

  • Translacja protokołów: Aplikacja API działa jako tłumaczy. Nowoczesne interfejsy front-endowe używają JSON, ale starszy backend używa XML. Aplikacja API zamyka tę przerwę.

  • Bezpieczeństwo: Dane logowania są przechowywane jako „hashowane” w bazie danych, co zapewnia, że nawet w przypadku naruszenia bazy danych hasła w postaci jawnej nie zostaną ujawnione. Wszystkie komunikacje zewnętrzne używają HTTPS.

  • Skalowalność: Dzięki wykorzystaniu aplikacji jednostronicowej (Angular) i rozdzielonego interfejsu API, front-end może być skalowany niezależnie od logiki backendu.

6. Zasady architektoniczne wdrożenia

6.1 Bezpieczeństwo i zgodność z przepisami

  • Komunikacja typu Zero-Trust: Wymuszaj wzajemne certyfikaty TLS (mTLS) dla połączeń między usługami wewnętrznych, szczególnie między aplikacją API a mainframe. Wszystkie punkty końcowe zewnętrzne muszą kończyć HTTPS przy użyciu nowoczesnych zestawów szyfrów.
  • Zarządzanie tożsamością i dostępem: Zaimplementuj OAuth 2.0 / OpenID Connect do uwierzytelniania. Przechowuj tylko zasolone, skrócone hasła (np. Argon2 lub bcrypt) w bazie danych Oracle. Wymuszaj uwierzytelnianie wieloskładnikowe (MFA) dla transakcji o wysokim ryzyku.
  • Zgodność od samego początku: Wyrównaj przepływy danych z wymogami PCI-DSS, RODO oraz lokalnymi przepisami bankowymi. Upewnij się, że dane osobowe (PII) i dane finansowe są szyfrowane w spoczynku i w trakcie przesyłania. Zachowaj niezmienne dzienniki dostępu w bazie danych w celu śledzenia audytowego.

6.2 Rozwój oparty na API i oparty na kontraktach

  • Zdefiniuj kontrakty wczesno: Użyj OpenAPI/Swagger do wersjonowania interfejsu API JSON/HTTPS udostępnianego przez aplikację API. Traktuj kontrakt jako jedyną prawdziwą źródłową informację dla zespołów SPA i mobilnych.
  • Idempotentność dla płatności: Wszystkie punkty końcowe płatności muszą obsługiwać klucze idempotentności, aby zapobiec powtórnym transakcjom podczas ponownych prób połączenia sieciowego.
  • Wzorzec Backend-for-Frontend (BFF): Jeśli wymagania mobilne i webowe znacznie się różnią, rozważ podział aplikacji API na specjalistyczne BFF, aby uniknąć nadmiernego pobierania lub niedoboru danych.

6.3 Strategiczna integracja z systemami dziedzicznymi

  • Warstwa antykorupcji: Aplikacja API powinna działać jako warstwa tłumaczenia między nowoczesnymi ładunkami JSON a schematem XML/HTTPS systemu głównego. Zapobiega to przenikaniu modeli danych z systemu dziedzicznego do kodu front-endowego.
  • Przekaźniki wyłączające i mechanizmy rezerwowe: Zaimplementuj wzorce odporności (np. Resilience4j lub Polly) wokół wywołań systemu głównego. Jeśli system dziedzicznego stanie się nieodpowiedni, płynnie przejdź do trybu tylko do odczytu lub do wyświetlania zapisanych sald.
  • Asynchroniczne przekazywanie obciążeń: Użyj kolejek komunikatów (np. RabbitMQ, Kafka) do operacji niekrytycznych, takich jak powiadomienia e-mailowe lub rejestrowanie audytu, aby uniknąć blokowania wątku żądań skierowanych do klienta.

6.4 Spójność danych i integralność transakcji

  • Zarządzanie transakcjami rozproszonymi: Ponieważ dane konta przechowywane są w systemie głównym, a dane sesji i uwierzytelniania w Oracle, użyj wzorca Saga lub transakcji kompensacyjnych, aby zapewnić spójność w przepływach płatności.
  • Spójność ostateczna tam, gdzie jest to odpowiednie: Wyświetlanie sald i ich prezentacja mogą być buforowane z krótkim TTL, aby zmniejszyć obciążenie systemu głównego, podczas gdy historie transakcji powinny być pobierane synchronicznie lub za pomocą przesyłania zdarzeń.
  • Ścisła ewolucja schematu: Skoordynuj zmiany w bazie danych z wersjonowaniem interfejsu API. Używaj migracji schematu zgodnych wstecz i okien deprecjacji, aby uniknąć uszkodzenia wydań aplikacji mobilnych.

6.5 Obserwowanie i doskonałość operacyjna

  • Śledzenie rozproszone: Wstrzykuj identyfikatory korelacji na punkcie wejścia Web/Mobile i przekazuj je przez aplikację API, wywołania systemu głównego i system e-mailowy, aby umożliwić śledzenie żądań od początku do końca.
  • Strukturalne rejestrowanie i metryki: Rejestruj wszystkie próby uwierzytelnienia, wywołania interfejsu API oraz interakcje z systemem głównym z jednolitymi poziomami poważności. Eksportuj metryki do bazy danych czasu szeregu do wykresów w czasie rzeczywistym.
  • Sprawdzanie stanu i sondy gotowości: Udostępnij /health i /ready punkty końcowe w aplikacji API do koordynowania płynnych wdrożeń i skalowania automatycznego w środowiskach kontenerowych.

7. Wskazówki i triki na rzeczywistych sukcesach

7.1 Opanowanie przepływu pracy modelowania C4

  • Jeden poziom abstrakcji na diagram: Utrzymuj diagramy kontenerów ściśle na poziomie kontenerów. Przenieś szczegóły technologiczne, klasy lub tabele baz danych do diagramów komponentów/kodu, aby uniknąć zamieszania.
  • Automatyzacja generowania diagramów: Używaj narzędzi takich jak Structurizr, C4-PlantUML lub Mermaid do generowania diagramów z kodu lub konfiguracji. Zapewnia to, że diagramy rozwijają się razem z systemem.
  • Link do dokumentacji: Wstaw diagramy C4 do rekordów decyzji architektonicznych (ADRs) i wiki wdrażania. Oznacz każdy kontener zespołami odpowiedzialnymi, SLA i ścieżkami wdrażania.

7.2 Optymalizacja wydajności i opóźnień

  • CDN dla zasobów statycznych: Przenieś pakiety Angular/JavaScript, CSS i obrazy z aplikacji internetowej do CDN. Zmniejsza to obciążenie serwera źródłowego i poprawia czas ładowania stron na całym świecie.
  • Optymalizacja ładunku dla urządzeń mobilnych: Aplikacje Xamarin powinny żądać tylko niezbędnych pól. Zaimplementuj GraphQL lub parametry wyboru pól w API, aby zmniejszyć rozmiar ładunku JSON w sieciach komórkowych.
  • Pule połączeń i utrzymanie połączenia: Dostroj pule połączeń JDBC dla bazy danych Oracle i pule klientów HTTP dla wywołań mainframe, aby uniknąć nadmiernego przetwarzania połączeń w godzinach szczytowych w bankowości.

7.3 Wytrzymałość i obsługa błędów

  • Wytrzymałość zgodna z zasadą stopniowego obniżania jakości: Jeśli system e-mail jest niedostępny, umieszczaj żądania SMTP w kolejce zamiast kończyć transakcję użytkownika niepowodzeniem. Powiadom zespoły operacyjne poprzez alerty, a nie użytkowników.
  • Ograniczanie szybkości i przepustowości: Zastosuj adaptacyjne limity szybkości w aplikacji API, aby chronić mainframe przed szczytowym ruchem w dni płac, a także w okresach wahań rynku.
  • Powtarzaj z wykładniczym odstępowaniem: Zaimplementuj inteligentne ponowne próby dla błędów tymczasowych (np. przekroczenie czasu połączenia, błędy 5xx), ale nigdy nie ponawiaj wywołań płatności idempotentnych bez jawnego klucza idempotentności.

7.4 Testowanie przez granice rozproszone

  • Testowanie kontraktów: Użyj Pact lub Spring Cloud Contract, aby zweryfikować, czy klienty SPA/urządzenia mobilne i aplikacja API przestrzegają ustalonych schematów JSON, zapobiegając awariom integracji podczas niezależnych wdrożeń.
  • Podwójniki testowe dla systemów dziedziczonych: Symuluj lub przypomnij system bankowy główny w pipeline’ach CI/CD. Użyj zarejestrowanych par żądań/odpowiedzi XML, aby przetestować logikę tłumaczenia interfejsów API bez dotykania głównych systemów produkcyjnych.
  • Lekka inżynieria chaosu: Okresowo wprowadzaj opóźnienia lub awarie w niekrytycznych ścieżkach (np. dostarczanie e-maili, rejestrowanie) w celu zwalidowania zachowań awaryjnych oraz progów ostrzegawczych.

7.5 Dokumentacja jako żywy artefakt

  • Diagramy wersji z kodem: Przechowuj diagramy C4 w tym samym repozytorium Git co kod źródłowy. Traktuj dokumentację architektury jak kod, który wymaga przeglądu i weryfikacji w CI.
  • Utrzymuj mapę kontekstu systemu: Przechowuj zaktualizowany diagram kontekstu C4 obok diagramu kontenera w celu śledzenia zależności zewnętrznych (np. wykrywanie oszustw przez trzecią stronę, systemy raportowania regulacyjnego).
  • Przeprowadzaj kata architektoniczne: Przeprowadzaj kwartalne sesje przeglądu diagramów z zespołami wielodyscyplinarnymi (dev, ops, bezpieczeństwo, produkt), aby zweryfikować założenia, zidentyfikować węzły zatyczki i skonsolidować strategie modernizacji.

Te wytyczne i praktyczne wskazówki zapewniają praktyczny szablon dla zespołów implementujących, skalujących lub modernizujących podobne architektury bankowości internetowej. Łącząc dyscyplinarną modelowanie C4 z odporystą praktyką inżynieryjną, organizacje mogą zapewniać bezpieczne, wysokiej wydajności cyfrowe doświadczenia bankowe, jednocześnie bezpiecznie łącząc nowoczesne wzorce chmurowe z dziedzicznymi systemami jądrowymi.

 

8. Narzędzia: Przyspieszanie modelowania C4 za pomocą Visual Paradigm

Dokumentowanie i utrzymanie złożonej architektury, takiej jak system bankowości internetowej BigBank, wymaga solidnych i elastycznych narzędzi. Visual Paradigm oferta kompleksowej, natywnej obsługi hierarchii pełnego modelu C4, umożliwiając zespołom architektonicznym tworzenie, współpracę nad i rozwijanie diagramów z precyzją i wydajnością.

8.1 Dlaczego Visual Paradigm do modelowania C4?

Visual Paradigm wyróżnia się jako rozwiązanie typu enterprise dla modelowania C4 dzięki:

  • Pełna obsługa hierarchii: Natywnie twórz wszystkie sześć kluczowych typów diagramów C4 — Kontekst systemu, Kontener, Komponent, Obraz systemu, Dynamiczny i Wdrożenie — w jednym, zintegrowanym środowisku. [1, 2, 6, 7]

  • Dostępność na wielu platformach: Pracuj bezproblemowo na Stacjonarnym (wersja 16.3 i nowsza), Online (dostęp przez przeglądarkę) oraz opartym na AI platformach, zapewniając elastyczność dla rozproszonych zespołów i różnych preferencji w pracy. [4, 16, 18]

  • Projektowanie zorientowane na architekturę: Elementy to bogate, semantyczne obiekty — nie tylko kształty wizualne. Obsługa niestandardowych atrybutów, stereotypów i wartości oznaczonych umożliwia diagramom przenoszenie istotnych metadanych do zarządzania, analizy wpływu i automatycznego dokumentowania. [8, 12]

8.2 Kluczowe funkcje dla studium przypadku BigBank

Do dokumentowania architektury BigBank Visual Paradigm zapewnia skierowane możliwości:

Funkcja Zastosowanie w architekturze BigBank
Generowanie diagramów z wykorzystaniem sztucznej inteligencji Szybko utwórz początkowy diagram kontenera, opisując system w języku naturalnym (np. „SPA komunikuje się z aplikacją API, która łączy się z bazą danych Oracle i głównym komputerem”). Generator AI tworzy strukturalne punkt wyjścia do dalszej poprawy. [5, 13]
Możliwość ponownego wykorzystania elementów i spójność Zdefiniuj kontener „Aplikacja API” raz, a następnie używaj go w diagramach kontekstowych, kontenerów, komponentów i wdrażania. Aktualizacje są automatycznie propagowane, zapewniając spójność architektoniczną i zmniejszając obciążenie utrzymania. [8, 12]
Integracja z C4-PlantUML Dla zespołów, które preferują modelowanie oparte na kodzie, użyj zintegrowanegoC4-PlantUML Studio do pisania diagramów jako tekstu, z natychmiastowym renderowaniem wizualnym i pełnym wsparciem semantyki C4. Idealne do kontroli wersji architektury wraz z kodem źródłowym. [12, 15]
Widoki dynamiczne i wdrażania Modeluj interakcje w czasie działania (np. „Użytkownik loguje się przez SPA”) za pomocą diagramów dynamicznych, a mapuj kontenery na infrastrukturę (np. „Aplikacja API wdrożona w AWS ECS”) za pomocą diagramów wdrażania – kluczowe dla gotowości operacyjnej i przekazania do DevOps. [5, 9, 11]
Współpraca i szablony UżyjVisual Paradigm Online do współczesnego edytowania diagramów w czasie rzeczywistym z zespołami zabezpieczeń, backendu i frontendu. Wykorzystaj gotowe szablony modelu C4, aby przyspieszyć wdrażanie i zapewnić standardy diagramów. [4, 17]

8.3 Integracja praktycznego przepływu pracy

  1. Zacznij od kontekstu: Użyj diagramu kontekstu systemu, aby dopasować zainteresowane strony do granic BigBank i zależności zewnętrznych (główny komputer, system e-mailowy, Klienci).

  2. Przejdź do kontenerów: Utwórz diagram kontenerów (jak analizowano w tym studium przypadku), aby szczegółowo opisać wybory technologiczne i przepływy danych na poziomie ogólnym.

  3. Przejdź do komponentów: Dla złożonych kontenerów, takich jak „Aplikacja API”, wygeneruj diagram komponentów, aby rozłożyć wewnętrzne moduły (Usługa uwierzytelniania, adapter głównego komputera, Usługa powiadomień).

  4. Modeluj działanie i wdrażanie: Użyj diagramów dynamicznych do weryfikacji kluczowych ścieżek użytkownika i diagramów wdrażania do planowania dostarczania infrastruktury oraz strategii skalowania.

  5. Utrzymuj jako żywe dokumenty: Przechowuj diagramy w swoim repozytorium Git, łączy je z ADR i historiami użytkownika, a użyj wersjonowania Visual Paradigm, aby śledzić ewolucję architektury wraz z wydaniami kodu.

8.4 Rozpoczęcie pracy

Wykorzystując dedykowaną obsługę C4 w Visual Paradigm, zespół architektury BigBank może przekształcić statyczne diagramy w dynamiczne, wspólne i działające źródło prawdy – przyspieszając decyzje projektowe, poprawiając zgodność między zespołami i zapewniając, że architektura rozwoju bezpiecznie dopasowuje się do wymagań biznesowych.

Wnioski

Architektura systemu internetowego bankowości BigBank ilustruje praktyczny podejście do transformacji cyfrowej w sektorze usług finansowych. Wykorzystując diagram kontenerów C4, zaangażowane strony uzyskują jasne zrozumienie, jak różne technologie – od nowoczesnych frameworków JavaScript do starszych systemów głównych – współpracują, aby zapewnić spójne doświadczenie bankowe. Siła architektury polega na jej warstwowej separacji odpowiedzialności, gdzie aplikacja API pełni kluczową rolę warstwy integracji, tłumacząc między nowoczesnymi frontendami opartymi na JSON i starszymi backendami opartymi na XML.
Ten wzorzec projektowy oferuje kilka strategicznych zalet: chroni inwestycje w podstawową infrastrukturę bankową, umożliwia niezależne skalowanie aplikacji skierowanych do użytkownika oraz utrzymuje wysokie standardy bezpieczeństwa poprzez haszowanie poświadczeń i szyfrowane komunikaty. Ponadto, podejście wielokanałowe – wspierające przeglądarki internetowe, aplikacje jednostronicowe i urządzenia mobilne – pokazuje elastyczność wobec zmieniających się preferencji klientów.
Model C4 okazuje się nieoceniony w komunikowaniu tej złożonej architektury różnym odbiorcom – od technicznych programistów po stakeholderów biznesowych. Dzięki jasnej wizualnej reprezentacji kontenerów, technologii i interakcji wspiera on świadome podejmowanie decyzji dotyczące przyszłych ulepszeń, migracji technologii i integracji systemów. W miarę jak BigBank rozwija swoje oferty cyfrowe, ta podstawowa architektura pozwala instytucji na dostosowanie się do nowych technologii – takich jak otwarte interfejsy API bankowości, uwierzytelnianie biometryczne i personalizacja oparta na sztucznej inteligencji – jednocześnie utrzymując stabilność i bezpieczeństwo, które klienci oczekują od swojej instytucji finansowej.

Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文