Banking · Azure · Omnichannel platform
Omnichannel banking on Microsoft Azure, private by default
An omnichannel banking platform on Azure: one controlled edge for every channel, workloads on AKS, and data services reached only through private endpoints.
Client context
Who this was for
The client is a banking and finance organisation building a modern, cloud-native application structure to serve its channels from a single platform. The platform had to carry complex business logic and high transaction volumes, and the rollout had to be smooth, with minimal downtime for services that customers and staff already depend on every day.
The engagement covered application architecture design, automated deployment and application performance optimisation. In practice that meant designing the application and network architecture together, because in a bank the questions of where a service runs and who is allowed to reach it are, for most purposes, the same question.
Engagement scope
What the engagement covered
- A modern, cloud-native application structure aligned with organisational needs and established industry practice
- A multi-tier architecture to support complex business logic and high transaction volumes
- A deployment strategy for a smooth rollout with minimal downtime
Challenge
The decision they faced
Channels that grow independently end up as separate systems behind one brand, each with its own entry point, its own identity model and its own route to the core. For a bank that is a security problem before it is an engineering one: every additional public endpoint is another place where traffic can reach data without passing a control.
The platform also had to reach systems that stay on premises, including directory services, internal APIs and databases, for both customer-facing applications and internal staff. The design question was how to give internet, mobile and staff traffic one governed path each, while keeping every data service off the public network entirely.
Solution architecture
How the platform fits together
The platform is split across four subscriptions on Microsoft Azure. The connectivity subscription owns the edge: Azure Front Door receives internet and mobile users and forwards them to an Application Gateway through its private endpoint. Internal staff and on-premises data centre services arrive over an ExpressRoute circuit and a Virtual Network Gateway, on HTTP(S) and non-HTTP(S) paths that include LDAP, API and SQL connections. Azure Firewall inspects both routes, and an Azure Private DNS Zone resolves private endpoint names.
Operator access is kept apart from customer traffic. Azure Bastion fronts the jump servers in the connectivity subscription, which also holds its own Key Vaults. Nothing in the application tier is administered directly from the internet, and every administrative session starts at Bastion, which gives one place to control and review privileged access.
In the omnichannel subscription, an internal load balancer receives HTTPS from the firewall and passes it to the application subnet. Azure Kubernetes Service (AKS) hosts the channel applications and a group of shared platform applications the diagram labels Fabric apps, and a Keycloak virtual machine provides application identity over LDAP to the on-premises directory. Azure Functions, Event Hub, a Storage account, PostgreSQL, MySQL, Key Vault and Container Registry are reached only through connection strings that resolve to private endpoints.
Two further subscriptions hold the shared controls. The management subscription runs Log Analytics, Azure Monitor, Microsoft Defender for Cloud and Network Watcher, so telemetry and posture live outside the workload they observe. The identity subscription holds Azure AD (now Microsoft Entra ID), Conditional Access, Azure Policy and its own Key Vaults. The connectivity VNet vnet-hk-connectivity-prod-001 peers to vnet-hk-omni-prod-001 for applications and to vnet-hk-omni-managedservice-prod-001 for managed services, each with a separate, non-overlapping address range.

Figure 1 — Application architecture: every channel enters through one controlled edge, and every data service is reachable only through a private endpoint.
Open full-size image: Figure 1 — Application architecture: every channel enters through one controlled edge, and every data service is reachable only through a private endpoint.Approach
What we did
01
Channel entry and edge design
We started from the edge, because every later decision depends on where traffic is allowed to enter. Internet and mobile users reach Azure Front Door, which forwards only to the Application Gateway private endpoint, while staff and data centre traffic arrive over ExpressRoute. Azure Firewall sits on both paths, so there is one inspection point to reason about rather than one per channel, and the application tier has no public address at all.
02
Network and address planning
We planned the connectivity, application and managed-service virtual networks together, each with its own non-overlapping address range, and peered them through the connectivity hub. Separating the application subnets from the private-endpoint network keeps data services behind a boundary that application teams cannot widen by accident. An Azure Private DNS Zone, working alongside the on-premises DNS servers, lets cloud and on-premises clients resolve private endpoint names in the same way.
03
Application platform on AKS
We designed the multi-tier application structure around Azure Kubernetes Service, with channel applications and shared platform applications deployed as separate workloads behind an internal load balancer. Images are pulled from Container Registry over a private endpoint, and asynchronous work is handed to Event Hub and Azure Functions, so a slow downstream system delays a message rather than a customer request.
04
Identity and secrets
We kept identity in two layers. Keycloak on a dedicated virtual machine handles application sign-in and connects to the on-premises directory over LDAP. Microsoft Entra ID with Conditional Access governs access to the Azure platform itself. Secrets and connection strings sit in Key Vault behind private endpoints, which keeps them out of application configuration and off the public network.
05
Deployment and operations
We automated deployment so the platform could roll out with minimal downtime, and based performance work on evidence rather than guesswork. Azure Monitor and Log Analytics collect telemetry centrally, Microsoft Defender for Cloud reports security posture, and Network Watcher diagnoses connectivity across the peered networks. Administrative access runs only through Azure Bastion and the jump servers.
Outcome
What changed
We delivered a scalable, secure and efficient application architecture on Microsoft Azure. Every channel enters through one controlled edge and every data service is reachable only through a private endpoint, which gave the bank a platform it can explain to auditors as clearly as to engineers. The new structure improved performance, reduced deployment times and improved the experience for users across channels.
The modular design separates channel applications, shared platform applications and managed data services, so each can be maintained, scaled or extended without reopening the network design. That leaves the organisation positioned for continued growth and future expansion on the same foundation rather than a new one.
Technology stack
What it was built with
- Cloud
- Microsoft Azure
- Edge and networking
- Azure Front DoorApplication GatewayAzure FirewallExpressRoute
- Compute
- Azure Kubernetes ServiceAzure Functions
- Data and messaging
- Event HubPostgreSQLMySQL
- Identity and secrets
- KeycloakMicrosoft Entra IDAzure Key Vault
- Observability
- Azure MonitorLog Analytics
Architecture gallery
Supporting diagrams

Figure 2 — Network architecture: one connectivity hub peered to separate application and managed-service virtual networks, each with its own planned address range.
Open full-size image: Figure 2 — Network architecture: one connectivity hub peered to separate application and managed-service virtual networks, each with its own planned address range.Lessons learned
What we would carry forward
- Putting Azure Firewall on both the internet and ExpressRoute paths adds routing work, but it gives one place to answer what can reach the application tier. We would make the same choice again, and design the route tables around it from the start rather than retrofit them later.
- Private endpoints only work when name resolution is designed with them. Planning the Azure private DNS zones alongside the on-premises DNS servers early avoids the failure where a service resolves one way from staff networks on ExpressRoute and another way inside Azure.
- Keeping Keycloak for application identity while Microsoft Entra ID governs the platform gives each layer a clear owner. The trade-off is two identity systems to operate, which is acceptable when the boundary between them is written down and the LDAP connection to on-premises is monitored like any other dependency.
More case studies
Other programmes
A governed Azure foundation a bank could build on
We designed and built an Azure landing zone for a bank: governance, hub-and-spoke networking, security policy and Terraform-delivered infrastructure.
We delivered a scalable, secure and efficient Azure landing zone that accelerated the bank's cloud adoption. Application teams deploy into subscriptions that already carry networking, policy, monitoring and backup, which…
- Azure
- Terraform
- Azure DevOps
Security gates inside every pipeline, not after them
A DevSecOps delivery platform with GitLab, Jenkins and Argo CD on GKE, where every quality and security check is a pipeline gate owned by a named team.
The platform is designed to let teams release more often without letting security and quality review fall behind. Because checks run inside the pipeline and every failure reaches its owner…
- Jenkins
- Argo CD
- GKE
- GitLab
Next step
Start from the platform you have today
Tell us what you run, what is holding back the next release or workload, and who owns it. An engineer replies with questions and a proposed first step.
