Microservices layer
Summary
The microservice layer acts as the middle layer
client apps (e.g. AHS frontend) and the core Open Banking account aggregation services.
Provides modular services to handle
User/Client App Registration
Secure Authentication & Authorisation (OAuth 2.0)
Account Broker Service to abstract away complex consent handling
Consent Code Redirect URL service to process redirect callbacks from banks (ASPSPs)
Registration
Registration Request Initiated
A registration request is received via Registration API.
The request could be for
a user registering with the system
a client application registering to use the platform
Perform KYC Validation
KYC check is triggered for the incoming registration data (either user or company).
If KYC fails, the registration is rejected with appropriate error response.
If KYC passes, proceed to persist the data.
If User Registers (not client app)
The user’s details are saved into the User table.
The user is automatically associated with the default organisation (entry from Organisation table).
The response to the registration request includes:
Default Organisation Details
Generated UserID
System Deployment Phase – Default Client Setup
At system deployment, a default client entry is auto-populated into the Client table in the Registration Database.
This acts as a fallback organisation for new user registrations.
If Client App Registers
The client application's details are stored in the Client table.
No user-related data (like personal data of the client app's users) is stored or managed.
As a result, our platform is not liable for any user-related regulations such as GDPR.
Authentication and Authorisation (oAuth2.0)
Secure Channel Establishment
Every request from client app or user to Account Broker API must be over TLS 1.2 or above.
In production, enforce Mutual TLS (mTLS)
Client presents a certificate for authentication.
Server validates the client certificate and vice versa.
In staging/testing, allow one-way TLS (server certificate only).
Authentication & Token Issuance (OAuth 2.0 Flow)
Client or user authenticates with OAuth 2.0 Authorisation Server using appropriate grant type (e.g. client credentials or authorisation code).
On successful authentication, an Access Token is issued.
Token-Based API Access
For each request to the Account Broker API, the client/user must include the Access Token in the header.
The API verifies:
Token validity
Token scope and permissions
Expiry time
If valid, the request proceeds; else, access is denied with an appropriate error.
Final Secure Request Flow
Client App/User (TLS/mTLS)
Account Broker API (Validates OAuth 2.0 Token)
Core Open Banking Platform
ASPSP APIs (via secured Open Banking channels)
Account Broker
Client App Requests Account Data
Client app sends a request to Account Broker API to retrieve user bank data.
Broker API Checks Consent
Account Broker API checks for existing user consent in the Consent Database.
Consent is identified using Organisation ID + User ID + ASPSP ID
Consent Not Found
If no consent is found for the user
Account Broker API returns
HTTP 202 Accepted
Message: "Consent Required"
The request is halted until consent is granted and persisted.
Consent Found
If valid consent exists
The broker uses internally stored consent code and access token to call the core platform API.
This ensures client apps do not directly access or store consent tokens, maintaining security.
Core Platform Retrieves Account Data
Account Broker API forwards the request to
Core Platform Account-Aggregation-Consumer API
The core platform interacts with
ASPSP APIs using stored credentials and tokens
Response to Client App
The aggregated account data is returned back to the Client App via the Account Broker API.
Consent Code Redirect URL
1. Consent Request Initiated
Client App requests account access via Account Broker API.
Broker checks for consent
If not available, broker returns 202 Consent Required.
Broker initiates consent journey using ASPSP’s consent URL.
Consent request includes a service URL (redirect URI) pointing to Consent Callback Service.
2. User Authenticates with ASPSP
User is redirected to ASPSP’s authentication page.
Upon successful login and approval, ASPSP sends authorisation code to the embedded service URL (callback endpoint).
3. Callback Service Receives Authorisation Code
The Consent Callback Service receives the code from ASPSP.
It triggers a token exchange request to
core-platform/account-aggregation-consumer/consent API
Using the received authorisation code.
4. Token Stored on Core Platform
Core platform successfully exchanges code for access token.
Access token is persisted securely in the Consent Database.
Consent is linked to
Organisation ID
User ID
ASPSP ID
5. Ready for Account API Requests
Once consent and token are stored, Account Broker API can now
Seamlessly forward client app requests to the core platform.
Fetch account data from ASPSPs using valid stored tokens.