Open Banking Core Platform
/
Micro Services
Glossary
Sequence Diagram
Decision Tree
Micro service
1
Architecture Overview
1.1
Resilience Layer
Distributes inbound requests from client apps (TPPs or users)
Ensures high availability and routing control across microservices
1.3
Analytics Layer
Log Data Lake
Reporting
Alarms
1.2
Core Platform Microservices
A&A Service (OAuth 2.0)
Account Consent Service
Account Redirect URI Service
Account Services
2
AWS cloud environment
2.1
Network Layer
VPC (Virtual Private Cloud)
CIDR block range: e.g., 10.0.0.0/16
Divided into public and private subnets across AZ1 and AZ2
Subnets
Public Subnets (1 per AZ)
Private Subnets (2 per AZ)
NAT Gateway
Provides outbound internet access to instances in private subnets
Bastion Host
Jump box for administrators to securely SSH into instances in private subnets
2.2
Application Layer
Auto Scaling Group (ASG)
Launches and manages a group of EC2 instances in Private Subnets
Ensures resilience and scalability by maintaining instance health and desired capacity
ECS or EC2 Microservices (per instance)
Represented by container icons
Likely hosting Open Banking APIs or business services
Horizontally scalable via ASG
Amazon EBS
Persistent block storage attached to each instance in the ASG
2.4
Security Services (Bottom Icons)
AWS KMS (Key Management Service)
Databases
Secrets
API tokens
AWS Secrets Manager
DB credentials
OAuth2.0 secrets
TLS certificates
AWS IAM
Manages fine-grained access control for users, roles, and services
Amazon SNS
Push notifications and alerting channel
2.3
Data Layer
Amazon Aurora (MySQL/PostgreSQL-compatible)
Hosted in Private Subnets
Core data for accounts, transactions, consents
Deployed across two AZs for high availability and disaster recovery
Real-time reads and writes with failover support
4
Security
4.1
Authentication Mechanisms
OAuth2.0 Authorization
Used across all services for token-based access control
Supports standard OAuth grant types including:

client_credentials (TPP-to-platform)
authorization_code (PSU consent and login)
API Key + Password
Required for premium service access or non-OAuth-enabled clients
Keys are securely stored (e.g., in AWS Secrets Manager)
4.3
Infrastructure Security
Services are only accessible from within secured cloud environments (e.g., private VPC subnets)
No public IPs are exposed for backend service containers or EC2 instances
Bastion hosts and NAT gateways are used to control and monitor administrative access.
4.2
Access Control
RBAC (Role-Based Access Control)
Users, services, and applications are granted permissions based on roles
Access to endpoints, environments, or data is strictly controlled via IAM roles and service policies
Security Group Rules
Each microservice instance is protected using AWS security groups
Control inbound/outbound traffic
5
Resilience & Scalability
5.1
Microservice Deployment on Kubernetes
The microservice layer will be deployed on Kubernetes (K8s) for better scalability, management, and fault tolerance.
Kubernetes provides robust features like
Automatic scaling of pods based on CPU utilization or custom metrics
Self-healing via automatic pod restarts in case of failures
Rolling updates to minimize downtime during deployments
5.3
Horizontal Scaling Based on Metrics
The Kubernetes cluster will scale automatically
CPU Utilization
Network Traffic
API request metrics
Scale individual endpoints as needed
Ensure each service receives the appropriate resources based on business demand
5.2
Traffic Distribution & Load Balancing
Initial Phase: Synchronous Requests
For the initial phase, traffic will be distributed to microservices via an API load balancer
API Gateway or Application Load Balancer (ALB) will handle traffic routing, ensuring even distribution across K8s pods.
Future Phase: Asynchronous Requests with Kafka
Kafka will handle asynchronous communication between services
This change will reduce costs and complexity as services scale, while also improving resilience by decoupling synchronous dependencies
7
Logging and monitoring
7.1
Logging Service Integration
The logging services (e.g., AWS CloudWatch, Google Cloud Logging, or Azure Monitor) are set up to automatically capture logs from all microservices.
Logging agents are deployed on microservices or nodes that send logs to these cloud logging services
7.3
Log Data Storage
Logs are centralized into a Log Data Lake or cloud-native storage
This log data is structured and stored to ensure easy retrieval for analysis and troubleshooting
7.4
Monitoring and Alerts
Real-time monitoring
Alerting systems
Alerts can be sent via email, SMS, or to monitoring dashboards
7.2
Logs Capturing
Service uptime
API request/response logs
Error logs and failure messages
User actions (e.g., consent requests, payment submissions)
Transactions and database interactions
8
Certificate and Password storage
8.1
Cloud-Specific Certificate and Password Storage Integration
The system uses cloud-native services such as AWS Secrets Manager, Google Cloud Secret Manager, or Azure Key Vault for securely storing certificates and passwords
These services provide high security, scalability, and manageability for sensitive data.
8.3
Access Control and Authentication
Role-Based Access Control (RBAC)
Authentication
8.4
Retrieving Certificates and Passwords
Services like Account Service or Payment Service may request certificates for SSL communication, or passwords for authentication processes.
The cloud storage service ensures that only authorized entities can access the credentials they need
8.7
Audit and Monitoring
Audit Logs
Monitoring
8.5
Lifecycle Management of Certificates and Passwords
Rotation
Expiration
Revocation
8.6
Encryption and Decryption of Data
Encryption
Decryption
Key Management
8.2
Storing Certificates and Passwords
Certificates
Passwords
Data is encrypted both at rest and in transit to ensure security
6
Database
6.1
Aurora Cluster Setup
Amazon Aurora will be used as the primary database layer for the platform
Aurora provides high performance and scalability, especially for relational workloads, and is fully managed by AWS
6.3
Load Testing for Sizing
Minimum number of writer and reader nodes
Writer nodes handle data manipulation operations like INSERT, UPDATE, and DELETE
Reader nodes distribute the load for read-heavy queries (e.g., SELECT)
Load testing helps ensure that
Database resources are aligned with actual traffic and usage patterns
The performance of the database is validated under expected traffic
6.2
Scaling Aurora Instances
Aurora instances will be scaled dynamically
Writer Nodes (primary instances) will handle the write-heavy operations
Reader Nodes (replicas) will handle read-heavy operations, improving query performance and availability.
Automatic scaling
Increased read traffic (via adding more reader nodes)
Write traffic spikes (by resizing writer nodes or scaling horizontally with read replicas)
3
List of Services
Code Redirect URI
Receives authorization code during PSU (user) login and redirects it to consent service.
Direct Debits
Returns details of direct debit mandates tied to the account
Scheduled Payments
Returns upcoming scheduled payments
Accounts
Retrieves user account summaries
Standing Orders
Lists active and historical standing orders
Statements
Delivers digital bank statements
Account Consent
Manages consent lifecycle (create, retrieve, revoke)
Beneficiaries
Provides data on payees linked to the user's account
Parties
Retrieves account holder (PSU) identity details.
Authentication and Authorisation
Provides OAuth2.0-based token issuance and validation
Balances
Fetches real-time and historical balance information for a user account
Offers
Fetches account-related offers (e.g., cashback, upgrades)
Transactions
Retrieves detailed transaction history for a user
Products
Lists products associated with the user's account (e.g., savings, loans)