Design of an Internet Banking System with AWS

Design of an Internet Banking System with AWS

by Fausto Iván Zamora Arias

In today’s digital era, online banking systems have become essential for delivering secure, efficient, and user-friendly financial services. This article presents a comprehensive design for a modern Internet Banking System, leveraging proven cloud technologies and architectural best practices. By breaking down the system through multiple levels of abstraction—from high-level context and container diagrams to detailed internal components—you’ll discover how each part interacts to provide seamless authentication, robust transaction handling, multi-channel notifications, and reliable data auditing. Whether you’re a developer, architect, or simply interested in fintech, this overview offers valuable insights into building scalable and secure banking solutions.

Level 1: Context Diagram

The system interacts with 7 main actors:

  • Bank Client: End user who accesses services through frontend applications.
  • Web Application (SPA): Single Page Application accessible from a web browser.
  • Mobile Application: Designed for smart devices (smartphones and tablets).
  • Online Banking System: Intermediary between frontend and backend, processing requests (e.g., transfers) and coordinating execution with the banking core and databases.
  • Banking Core: Manages critical data such as customer information, transactions, and historical movements.
  • Complementary System: Provides additional and specific customer data.
  • External Notification Service: Sends alerts and messages to the client through two cloud-based channels.

Level 2: Container Diagram

Frontend: User Applications

  • SPA (Single Page Application) and Mobile App: Users interact via browser (SPA) or smartphone (app).
  • SPA uses ReactJS, deployed with Amazon CloudFront.
  • Mobile app recommended frameworks: React Native (preferred for JavaScript/TypeScript consistency) or DotNet MAUI (for C#/fintech environments).
SPA Key Points:
  • Developed in ReactJS.
  • Deployed on Amazon CloudFront for global distribution and low latency.
Mobile App Key Points:
  • Recommended: React Native (consistency, Meta support, ongoing updates).
  • Shares logic with SPA, facilitating cross-platform development.
  • Alternative: .NET MAUI (C#, ideal for fintech/banking teams).

Authentication and Onboarding

  • Separate containers for Authentication and Onboarding (registration).
  • Both use Amazon Cognito for user storage and authentication.
  • Shared user/client database for movements, activities, and audit.
Authentication:
  • Managed by Amazon Cognito (credential storage and validation).
Onboarding:
  • Independent flow, integrated with Cognito.
  • Records additional data in shared database (for movements and audit).

Backend for Frontend (BFF)

  • Executes logic accessible only via bank's internal network/VPC.
  • Communicates with frontend using JWT from authentication.
  • Performs interbank transactions, updates client data, and maintains frequent user cache.
Function:
  • Exposes internal bank APIs (protected by JWT).
  • Operates within bank’s VPC for security.
Capabilities:
  • Executes interbank transactions (via Banking Core).
  • Updates client data and maintains cache of frequent users.

Data Persistence (BFF)

  • Two solutions for user data: Redis (fast key-value, in-memory) and DynamoDB (fast by primary/secondary key; optimal for reconciliation).
  • Redis: Ultra-fast in-memory key-value storage.
  • DynamoDB: Optimal for user ID lookups and data reconciliation.

Notification Microservice

  • Microservice focused on notifications, fed by BFF logic.
  • Listens to SQS for events/messages from Banking Core, publishes to SNS and Firebase Cloud Messaging.
  • Supports multichannel notification requirements (SMS, email, push).
Architecture:
  • Listens to Amazon SQS for Banking Core events (e.g., deferred transfers).
  • Publishes messages to:
    • Amazon SNS: Multichannel (SMS, email, push).
    • Firebase Cloud Messaging (FCM): Real-time push to SPA and mobile app.

Audit and Data Consolidation Service

  • Aggregates data from Banking Core, BFF, and clients in a relational database.
  • Two options: Scheduled ETL (AWS Glue) every 6 hours, or DynamoDB Streams for real-time data transformation to PostgreSQL.
Objective:
  • Aggregate data in relational DB (e.g., PostgreSQL).
Implementation Options:
  • Scheduled ETL (AWS Glue): Serverless processing every 6 hours.
  • Real-Time Streams: DynamoDB to PostgreSQL, immediate data replication.

Level 3: Internal Architecture

Frontend: Architecture and Controllers

  • Two applications: SPA (ReactJS, AWS CloudFront, S3) and Mobile App (React Native or DotNet MAUI).
  • Four controllers:
    • Authentication: Login via username/password or biometric.
    • Banking Operations: Update, transfer, movement, client profile.
    • Image Processing: Photos/images for Rekognition.
    • Notifications: Real-time via Firebase Cloud Messaging.
Technical Justification:
  • Single Responsibility Principle (SOLID) for controller separation.
  • FCM for cross-platform notifications, Rekognition for AI-based identity.

Authentication and Onboarding Microservice

  • Lambda-based microservice for user authorization and biometric onboarding (Amazon Cognito API for JWT/auth).
  • Auth flows divided into lambdas: Auth Challenge Definition, Creation, Verification, Biometric Logic, Rekognition Controller.
  • Separate flows for authentication and onboarding, sharing core logic.
Standard Authentication Flow:
  1. User enters credentials on frontend.
  2. Frontend sends request to authentication service (Amazon Cognito).
  3. Cognito returns access token.
  4. Token used in other apps (e.g., BFF).
Biometric Onboarding Flow:
  1. User registers and uploads photo via frontend.
  2. Photo sent to authorization service and stored in Cognito user pool & S3.
  3. Rekognition compares photo, indexes in DynamoDB (Facial ID Table).
  4. Frontend requests authentication with photo/email; Cognito triggers lambdas for challenge/verification.
  5. Upon successful verification, JWT token is issued for use with BFF.
Considerations:
  • Amazon Cognito stores login/authentication data.
  • Frontend should monitor onboarding/auth steps via Google Analytics.

Backend for Frontend (BFF): Orchestration Layer

  • Microservice logic, implemented as AWS Lambdas.
  • Uses Authorizer Lambda (validates JWT via Cognito OAuth 2.0 secret).
  • API Gateway to expose lambdas securely.
  • Business lambdas for transfers, balance inquiries, profile updates (all interact with Banking Core).
  • Persistence: DynamoDB (write) & Redis (frequent reads, cache).
Key Pattern: CQRS (Command Query Responsibility Segregation).
  • Writes: DynamoDB
  • Reads: Redis

Notification System: Asynchronous Events

  • Uses Amazon SNS (email/SMS) and Firebase Cloud Messaging (in-app notifications).
  • Banking Core publishes messages to SQS, notification lambda transforms and delivers to SNS/FCM.
  • DynamoDB ("Notifications DB") logs all message deliveries.
Advantages:
  • Multichannel notifications (SMS, email, push).
  • Decoupled architecture—Banking Core doesn’t need to know final destinations.

Audit: Data Consolidation

  • Strategies for audit database covering all client interactions.
  • Assumes all services have own microservice DBs except Banking Core (hosted in AWS RDS).
  • Recommended solutions: CDC (Change Data Capture) with DynamoDB Streams, or ETL with AWS Glue.
CDC Option:
  • DynamoDB Streams capture changes.
  • Lambdas transform and load into Aurora PostgreSQL.
  • Strength: Real-time, ideal for immediate reconciliation.
ETL Option:
  • Scheduled job (e.g., every 6 hours) via AWS Glue.
  • Extracts data from DynamoDB/RDS, transforms to S3, loads into Aurora.
  • Strength: Cost-effective for non-critical real-time data.
Recommendation:
  • Use CDC for transactions (movements).
  • Use ETL for historical reports.

Architecture with AWS concepts

graph TD %% Level 1: Actors subgraph Actors A1[Bank Client] A2[Web Application] A3[Mobile Application] A4[Online Banking System] A5[Banking Core] A6[Complementary System] A7[External Notification Service] end %% Level 2: Containers subgraph Frontend FE1[SPA \n ReactJS] FE2[Mobile App\n React Native] end subgraph Authentication AU1[Auth Microservice AWS Lambda] AU2[Onboarding Microservice AWS Lambda] AU3[Amazon Cognito] AU4[User/Client Database] end subgraph BackendForFrontend BFF1[BFF API Gateway] BFF2[BFF Lambdas] BFF3[DynamoDB User Transactions] BFF4[Redis Cache] end subgraph BankingCore BC1[Banking Core API] BC2[Core Database\n RDS/PostgreSQL] BC3[SQS Notification Queue] end subgraph Notifications N1[Notification Microservice\nLambda] N2[Amazon SNS] N3[Firebase Cloud Messaging] N4[DynamoDB\nNotifications DB] end subgraph Audit AU5[Audit Microservice] AU6[DynamoDB Streams/Glue ETL] AU7[Amazon Aurora\nPostgreSQL] end %% Level 1: Actor Connections A1-->|Uses|FE1 A1-->|Uses|FE2 FE1-->|Initiates|AU1 FE1-->|Initiates|AU2 FE2-->|Initiates|AU1 FE2-->|Initiates|AU2 %% Auth flows AU1-->|Authenticates|AU3 AU2-->|Registers|AU3 AU3-->|Stores/Validates|AU4 AU3-->|Provides JWT|FE1 AU3-->|Provides JWT|FE2 %% BFF flows FE1-->|API Calls JWT|BFF1 FE2-->|API Calls JWT|BFF1 BFF1-->|Routes|BFF2 BFF2-->|Executes|BC1 BFF2-->|Reads/Writes|BFF3 BFF2-->|Reads|BFF4 BFF2-->|Triggers|N1 %% Banking Core BC1-->|Processes|BC2 BC1-->|Publishes Events|BC3 %% Notifications N1-->|Subscribes|BC3 N1-->|Publishes|N2 N1-->|Publishes|N3 N1-->|Records|N4 N2-->|Sends|A1 N3-->|Sends|FE2 N3-->|Sends|FE1 %% Audit flows AU5-->|Collects|AU6 AU6-->|Extracts Data|BFF3 AU6-->|Extracts Data|N4 AU6-->|Extracts Data|BC2 AU6-->|Transforms|AU7 %% Complementary system A6-->|Provides Data|BC1

Comments

Post a Comment

Popular posts from this blog

Analysis of dark patterns in League of Legends and Star Wars:Battlefront II with the usage of Loot Boxes

The following analysis was done originally as an assignment for the Introduction to Game Research course at University of Gothenburg, first section fall 2019. The Darkness of a game design and its consequences revealed: Analysis of dark patterns in League of Legends and Star Wars:Battlefront II with the usage of Loot Boxes In some video games there are practices that are ethically questionable, which makes them go against what the player expects from the games. These practices of going against the player are called Dark Patters   (Staffan Björk) . As they are ethically questionable, I think it is good to identify (reveal) some of these patterns in games, which are currently very much played, and also reveal their current consequences. In specific, my analysis is going to consist in how League of Legends   (RIOT games, 2009) and Star Wars: Battlefront II   (Electronic Arts, 2017) have some characteristis that could mean that they are ussing the Grinding , M...
Read more

Kerstin's Fate developer diary

Image
Kertin's Fate developer diary Kertin's Fate Design: Kertin's Fate is a platform game directed and writed by Ivan Zamora, as part of Yao's Story games. The gameplay design for the game is based on the GNS model. Although GNS is based on role gaming, I decided to use the modes concept to direct design goals. The goal by ussing GNS is to "Focus on a gamism experience while narrating the game". Whit this goal, the game is not intended to advocate for simulationism, however things would change during testing. Moreover, for general gameplay I decided to stick with some common gameplay patterns. The game is designed by the following game play design patterns: Value of effort Luck Revoke Roles Character Levels Critical Failure Critical Success Items Gameplay Mastery  Time Limits On the other hand, to design character development I divided the experience according to the MDA framework, focusing mechanics as methods/actions. Mechanics: Jump/ double jump Sword attack Att...
Read more

Exploring LLMs with Ollama and Llama3

Image
I am going to use NodeJs and Windows 11 , however everything here should be the same for Linux or Mac , I just like my Windows machine for personal use. Steps to install the LLMs: 1) Install OLLAMA : this can be done by going to the ollama website https://ollama.com/ or using curl liek this: curl -fsSL https://ollama.com/install.sh | sh 2) Pull LLama3 with OLLAMA Ollama works something like a package manager but for LLMs , so to download LLAMA3 use the following command: ollama pull llama3 3) After doing so you can use Llama3 on your terminal ollma run llama3 "make a helloe world in C++" Steps to use it on usefull scenarios: 1) setup a nodejs/nmp project mkdir personal-llama cd personal-llama npm init -y we need to install ollama which is a client for the ollama server that we are running on the same machine sqlite3 because I want to have some personal data inside the ollama so it can execute responses based on me. chalk for nice l...
Read more