In Part 1, we established the security foundations and edge architecture that protect financial workloads on Azure - covering secure ingress, layered WAF enforcement, and private network boundaries.

In Part 2, we move deeper into the platform - into the systems that process transactions, manage financial data, and integrate with legacy core platforms. This is where architectural decisions have the greatest impact on reliability, performance, and data integrity.

This installment explores how containerized microservices implement business logic, how different data stores serve distinct roles, and how modern cloud platforms integrate with decades-old on-premises and mainframe-based systems. We'll examine the critical distinction between authoritative and non-authoritative data, explore messaging patterns that ensure reliability, and understand how to connect cloud systems with mainframe-based core banking platforms.

The core business logic - the code that processes transactions, calculates interest, and handles transfers - runs on Azure Kubernetes Service (AKS).

Kubernetes orchestrates containers. Instead of deploying applications directly onto virtual machines, code is packaged into containers - self-contained units that include the application, runtime, libraries, and dependencies. Kubernetes then manages how these containers are deployed, scaled, healed, and upgraded across the platform.

For financial workloads, this model is not about trend-following - it directly addresses long-standing operational and reliability challenges.

Consistency across environments
A container that runs on a developer’s laptop runs the same way in test and production. This eliminates environment-specific surprises and the classic “it works on my machine” problem - an important control in regulated change management.

Efficient resource utilization
Containers are lightweight compared to full virtual machines. Multiple services can run securely on the same node, improving infrastructure utilization while maintaining isolation between workloads.

Built-in resilience
Kubernetes continuously monitors container health. If a container crashes, it is restarted automatically. If a node fails, workloads are rescheduled onto healthy nodes. From the application’s perspective, availability is maintained without manual intervention.

Fine-grained, service-level scaling
Not all banking functions scale the same way. Payment processing may spike at month-end, while account lookups remain steady. Kubernetes allows individual services to scale independently, ensuring capacity is added only where it’s needed.

A typical banking deployment on AKS might look like this:

Each service runs multiple instances, known as pods. When demand increases - for example, during peak payment periods - only the payment processing pods scale out. Account management and transaction history services remain unaffected, ensuring capacity is added precisely where it’s needed.

Importantly, the load balancer is internal-only. It has no public IP address and is reachable exclusively from within the Virtual Network, ensuring that backend services remain completely isolated from direct internet access.

In financial systems, reliability is paramount. When a customer transfers $10,000, that transaction must complete atomically and durably according to ACID principles (Atomicity, Consistency, Isolation, Durability). Crucially, this happens inside the database, not through a messaging system.

Messaging plays a different role.

Azure Service Bus provides the backbone for asynchronous communication between services - work that must happen after a transaction completes, but does not need to be part of the transaction itself.

Consider a customer initiating a money transfer:

The key point: the financial transaction is already complete and safe before any message is published.

This is why customers may receive confirmation emails a few seconds - or even minutes - after completing a transfer. The money movement happened instantly and atomically in the database; the follow-up actions are handled asynchronously.

If a downstream service fails - for example, if the notification service crashes or becomes overloaded - Service Bus retains the message. When the service recovers, it processes the backlog.

The customer’s money is never at risk. At worst, a confirmation email is delayed.

This decoupling is essential in banking systems. It prevents non-critical failures from impacting core transaction processing.

Service Bus supports several patterns commonly used in financial platforms:

Everything discussed so far - security, networking, and compute - means nothing if the data layer fails. This is where customer balances, transaction records, and account details live, and where correctness, durability, and auditability matter more than anything else.

Azure SQL Database (or any other RDBMS) handles structured, relational data - accounts, customers, ledgers, and transactions. More importantly, it serves as the authoritative source of truth for all financial data.

In financial architectures, this distinction is fundamental:

Azure SQL Database is where authoritative data lives. Every dollar amount, every balance, every transaction - if it matters legally and financially, it exists in SQL Database first. Other data stores may reflect this information, but they never replace it.

For banking and regulated financial systems, Azure SQL Database provides capabilities that are essential rather than optional:

Azure SQL Database delivers the consistency, durability, and auditability required for systems that manage money - making it the natural home for the most critical financial data in the platform.

While Azure SQL Database is the system of record for authoritative data such as balances and ledgers, Azure Cosmos DB addresses a different requirement: fast, globally distributed access to read-optimized, non-authoritative data.

Cosmos DB is designed for scenarios where low latency, flexible schemas, and global reach matter more than strict, cross-region transactional consistency.

In banking and financial platforms, Cosmos DB is typically used for:

Cosmos DB complements these systems by providing fast, globally distributed access to supporting data. Any data stored in Cosmos DB must be rebuildable from the authoritative source in Azure SQL Database if required.

Consider a bank operating across multiple continents:

This pattern delivers global performance without compromising financial correctness.

Azure Cosmos DB supports multiple consistency models, allowing architects to balance correctness, latency, and global scale:

In practice, most financial platforms use session consistency for non-authoritative data. It offers an effective balance between user experience and performance, while preserving the integrity of authoritative financial records maintained elsewhere.

Azure Cache for Redis sits in front of primary databases, storing frequently accessed data in memory. Memory access is orders of magnitude faster than disk-based storage, making Redis ideal for accelerating read-heavy workloads.

In financial platforms, Redis is used to improve responsiveness, not to replace authoritative data stores.

When a customer checks their account balance:

This approach dramatically reduces database load while keeping customer-facing responses fast.

Cached balances are used only for read-only display and are refreshed aggressively using short time-to-live (TTL) values. Authoritative balances are always validated against the primary database for any transactional operation - transfers, withdrawals, or any action that modifies account state.

The cache exists to accelerate reads, never to participate in financial transactions.

For read-heavy scenarios such as balance checks and transaction history views, caching delivers significant performance improvements while reducing load on the primary database - without compromising data integrity.

Redis is also commonly used for session storage. When a customer logs in, session state is stored in Redis rather than on individual application instances. Because this state is in-memory and centrally accessible, customers remain logged in even when subsequent requests are served by different application servers.

This pattern improves scalability and resilience while maintaining a consistent user experience.

Here’s the reality: most banks do not run their core banking systems in the cloud. Account ledgers, loan processing engines, and settlement systems often live on mainframes or on-premises platforms that have evolved over decades. These systems are stable, heavily tested, and deeply embedded in regulatory and operational processes. Replacing them outright introduces unacceptable risk.

As a result, cloud-based banking platforms must integrate with these on-premises core systems - securely, reliably, and predictably.

Azure provides two primary connectivity options for this integration:

Azure ExpressRoute provides a dedicated, private connection between Azure and the bank’s on-premises network that does not traverse the public internet.

For production financial workloads, ExpressRoute is strongly recommended. When processing payments, updating ledgers, or querying core systems, reliability and determinism matter far more than setup speed or initial cost.

Azure VPN Gateway establishes an encrypted tunnel over the public internet between Azure and the bank’s data center.

VPN Gateway is often used as an initial connectivity option or as a backup path - but rarely as the primary connection for core banking traffic.

Before deploying any of the services described so far, production financial platforms establish a proper enterprise foundation using Azure Landing Zones (ALZ). This is not merely best practice - it is the architectural baseline that Microsoft, auditors, and financial regulators expect for regulated workloads.

Azure Landing Zones provide a structured, scalable subscription model with built-in governance, security, and compliance controls. Banks and regulated institutions rarely deploy workloads into a single, flat subscription. Instead, they adopt a multi-subscription architecture with clear separation of responsibilities and blast-radius control.

A production financial deployment typically uses the following subscription layout.

These subscriptions provide shared, organization-wide services:

Each workload is deployed into isolated subscriptions:

This separation delivers several critical benefits for regulated environments:

The Connectivity subscription establishes a hub virtual network that centralizes shared infrastructure:

Each application subscription deploys a spoke virtual network that peers with the hub. The banking or financial application - App Service, API Management, AKS - runs entirely within the spoke.

This model allows application teams to focus on building services, while networking and security controls are enforced centrally and consistently.

Regulators and auditors expect this level of organizational and architectural maturity. A well-implemented Azure Landing Zone demonstrates that the organization understands enterprise cloud governance, not just cloud deployment.

It marks the difference between “we are experimenting with the cloud” and “we are operating regulated financial workloads at scale.”

Landing Zones also make growth predictable. Launching a new digital service does not require redesigning networking or security - teams simply deploy a new spoke subscription that inherits established controls.

In this second part, we explored the internal mechanics of a production-grade financial system on Azure - from containerized microservices executing business logic to the deliberate separation of data responsibilities across multiple storage platforms.

We examined the critical distinction between authoritative financial data stored in Azure SQL Database and non-authoritative, supporting data served from systems such as Cosmos DB and Redis. We saw how Azure Service Bus enables reliable, asynchronous communication between services without compromising the atomicity and integrity of financial transactions.

We also looked beyond application code to the enterprise foundations that make these systems operable at scale. Azure Landing Zones establish the governance, security, and operational boundaries that regulators expect, while Azure ExpressRoute bridges modern cloud platforms with long-standing core banking systems. Together, these patterns allow banks to modernize customer-facing capabilities without taking on the risk of wholesale replacement of proven backend systems.

At this point, the functional architecture is complete - but a production banking system is not finished when it works. It is finished when it can withstand failure, be observed in real time, pass audits, and operate sustainably over time.

In Part 3, we complete the picture by focusing on:

Next: Part 3 - Operations, Compliance & Resilience

If you found this useful, tap Subscribe at the bottom of the page to get future updates straight to your inbox.