Modernization of Mutual Fund Platform on Azure

Case Study: Modernization of Mutual Fund Platform on Azure

1. Business Context

• Organization: Leading Asset Management Company

• Problem: Existing mutual fund transaction system built on .NET monolith with SQL Server hosted on-prem. Challenges:

  • High latency in processing SIP/STP/SWP transactions

  • Scalability issues during market peak hours

  • Complex integrations with distributors, RTA, and payment gateways

  • Compliance gaps (SEBI/RBI) and limited API exposure for partners

• Business Goal:

  • Transform into cloud-native, API-first architecture

  • Reduce transaction processing time from 3 hours to <15 minutes

  • Enable real-time portfolio view for customers/distributors

  • Achieve 99.99% availability and compliance

2. Vision & Objectives

• Vision: Build a secure, scalable, and cloud-native mutual fund platform with microservices and hybrid integration.

• Objectives:

  • Migrate core modules to Azure-based microservices (AKS + Service Bus)

  • API-first approach using Azure API Management for partner/retail consumption

  • Real-time integration with legacy systems (RTA, KYC, Payment)

  • Implement modern observability (Azure Monitor, Log Analytics)

  • Achieve SEBI compliance and adopt Zero Trust security

3. Current State Assessment

• Technology:

  • Monolithic .NET app with SQL Server (on-prem)

  • File-based integrations with RTA and payment gateways

  • No API exposure, limited message queue usage

• Pain Points:

  • Tight coupling of services (NAV calc, KYC, SIP processing)

  • Nightly batch jobs, no real-time insights

  • Manual reconciliation prone to errors

4. Target State Architecture (High-Level)

Cloud Platform: Azure

Core Components:

• Microservices (Spring Boot/.NET Core) on AKS

  • Services: Investor Onboarding, KYC, NAV Calculation, Order Management, Payment Gateway, Compliance Reporting

• API Management

  • REST APIs with OAuth2/JWT, rate limiting, and analytics

• Azure Service Bus

  • Event-driven architecture for trade order events, reconciliation

• Data Layer

  • Azure SQL Managed Instance (core transactions)

  • Azure Cosmos DB (real-time portfolio cache)

• Integration

  • Hybrid: REST (real-time) + Secure File Transfer (legacy RTA) + Database links

• Security

  • Azure AD, Managed Identities, Key Vault, NSGs, WAF (App Gateway)

• Observability

  • Azure Monitor, Application Insights, Log Analytics, Alerts

5. Step-by-Step Implementation

Phase 1: Foundation & Strategy

• Capability mapping (Investor onboarding, SIP/STP, Redemption, NAV publishing)

• Define principles: API-first, security-by-design, cloud-native, event-driven

• Choose deployment strategy: Hybrid cloud with active-active DR

Phase 2: Microservices Design

• Domain decomposition using DDD

• Create bounded contexts: Investor, Transactions, Compliance, Portfolio

• Define API contracts (OpenAPI spec)

• Implement async patterns using Azure Service Bus (e.g., trade order events)

Phase 3: Data & Integration

• Migrate SQL Server to Azure SQL MI (phased)

• Use Change Data Capture (CDC) for legacy sync

• Build hybrid integration with RTA using Azure Data Factory + Secure FTP

Phase 4: Security & Compliance

• Implement OAuth2/JWT via Azure AD + API Management

• Encryption: At rest (TDE), in transit (TLS 1.2)

• Build compliance workflows (SEBI reporting via automated extracts)

Phase 5: CI/CD & Observability

• Azure DevOps pipelines for AKS deployment

• Canary releases + Blue-Green for microservices

• Monitoring with Azure Monitor dashboards, App Insights for tracing

Phase 6: Migration & Cutover

• Parallel run: New microservices + legacy monolith

• Gradual traffic shift via Azure Front Door

• Final cutover during low transaction window

6. Risks & Mitigation

Top Risks:

• Data consistency during migration → Mitigate with CDC + dual writes

• Latency in hybrid integrations → Mitigate via async messaging + caching

• Regulatory non-compliance → Regular audits, encryption, logging

• Scalability during market peak → Auto-scaling AKS nodes + Service Bus partitioning

• Team skill gaps → Hands-on workshops + shadow mode transition

7. Outcome / Business Benefits

• Reduced transaction processing from 3 hrs → 10 mins

• 40% cost reduction via PaaS adoption (Azure SQL MI, Service Bus)

• 99.99% uptime with active-active deployment

• Enhanced partner experience via secure APIs (distributors, fintechs)

• Compliance adherence (SEBI, RBI) with automated reporting

8. Metrics / KPIs

• Latency: <200ms API response time

• Scalability: Handle 1M+ daily transactions during NAV window

• Cost Optimization: 30% infra savings vs on-prem

• Availability: 99.99% SLA met

• Compliance: 100% audit logs captured

9. Leadership & Governance

• Defined architecture review board (ARB) to ensure standards

• Mentored 10+ engineers on cloud-native design

• Established reference architecture and best practices for future programs

10. Key Learnings

• Incremental modernization is critical; big-bang leads to risks in BFSI

• Hybrid integration patterns essential for co-existence with RTAs

• Security must be baked into design (Zero Trust, RBAC, API Gateway policies)

• Event-driven architecture improves scalability and decoupling

Here’s a text-based architecture flow broken down persona-wise, so you can narrate step-by-step during interviews or use as a blueprint. I’ll cover four main personas relevant to this role:

1. Investor (Retail Customer)

2. Distributor / Partner (External APIs)

3. Operations Team (Internal Admin / Fund Manager)

4. Compliance & Risk Officer

   
   

For each, I’ll describe:

• Step-by-step interaction flow

• Services/components involved

• Key Azure services used

• Security and data flow considerations

• 
  

1. Investor Persona Flow (Retail Customer)

Use Case: Investor initiates mutual fund SIP purchase

Step-by-Step Flow:

1. Login / Authentication

   • Investor logs into web/mobile app.

   • Azure AD B2C handles authentication → issues JWT token.

   • API Gateway validates token before request routing.

2. Dashboard Load

   • API Gateway routes request → Portfolio Service (microservice on AKS).

   • Portfolio Service queries Azure Cosmos DB (real-time portfolio cache) + Azure SQL MI (transaction history).

3. SIP Purchase Initiation

   • Investor selects fund & amount → submits order via REST API.

   • API Gateway forwards to Order Management microservice.

4. KYC & Eligibility Check

   • Order Service triggers event to KYC Service (via Azure Service Bus).

   • KYC Service calls external KYC API (RTA) via hybrid integration (REST + file transfer fallback).

   • If already KYC-verified, proceed; else route to KYC completion microservice.

5. Payment Processing

   • Order Service integrates with Payment Gateway Service (microservice).

   • Uses Azure Key Vault for secure storage of payment credentials.

   • Calls third-party payment APIs → awaits confirmation.

6. Trade Confirmation & NAV Calculation

   • Successful payment → publish event to NAV Calculation Service via Service Bus.

   • NAV Service fetches real-time NAV feed (external RTA API) → calculates units allotted.

7. Portfolio Update & Notification

   • Portfolio Service updates Cosmos DB (real-time) + Azure SQL MI (transactional).

   • Sends confirmation to Notification Service → triggers email/SMS (via Azure Communication Services).

8. Monitoring & Logging

   • All services send telemetry to Azure Monitor + App Insights.

   • Logs persisted to Log Analytics workspace for compliance.

2. Distributor / Partner Persona Flow (External APIs)

Use Case: Distributor fetches investor portfolio & submits bulk orders

Step-by-Step Flow:

1. API Authentication

   • Distributor integrates via Azure API Management (APIM).

   • OAuth2 client credentials flow with role-based scopes (e.g., “bulk-order:write”, “portfolio:read”).

2. Bulk Order Submission

   • Distributor submits XML/JSON bulk order file via APIM endpoint.

   • API Gateway → Order Management Service (microservice).

3. Validation & Queuing

   • Order Service validates schema, formats → publishes event to Azure Service Bus.

   • Each order is processed asynchronously (avoids blocking).

4. KYC & Compliance Checks

   • Orders routed to Compliance Microservice → validates AML/SEBI rules.

   • Non-compliant transactions flagged for manual review (Operations dashboard).

5. Trade Execution

   • Valid orders trigger NAV Calculation Service → unit allocation.

6. Distributor Acknowledgment

   • Bulk status file generated → pushed via Secure FTP (Azure Data Factory) or API callback.

7. Observability

   • API Management provides usage analytics (rate limits, per-partner metrics).

3. Operations Team Persona Flow (Admin / Fund Manager)

Use Case: Fund Manager monitors daily NAV and reconciles transactions

Step-by-Step Flow:

1. Secure Login

   • Internal users authenticate via Azure AD (MFA + conditional access).

2. Operations Dashboard

   • Admin Portal (React app) calls APIs via API Management → Admin Microservices (Reporting, NAV, Reconciliation).

3. NAV Monitoring

   • NAV Calculation Microservice publishes daily NAV events to Service Bus.

   • Dashboard subscribes → displays real-time NAV updates.

4. Reconciliation

   • Reconciliation Service pulls transaction data from Azure SQL MI + RTA files (via Data Factory).

   • Generates exception reports for mismatched transactions.

5. Manual Intervention

   • Admin resolves flagged items → triggers reprocessing events.

6. Reporting

   • Compliance & operational reports generated → stored in Azure Data Lake + Power BI dashboards.

4. Compliance & Risk Officer Persona Flow

Use Case: Generate SEBI audit report for monthly submissions

Step-by-Step Flow:

1. Authentication

   • Officer logs in via Azure AD with RBAC (read-only + export privileges).

2. Data Access

   • Compliance Microservice fetches encrypted audit logs (Log Analytics + Azure SQL).

   • Only decrypted in-memory (compliance requirement).

3. Report Generation

   • Service applies SEBI reporting schema → generates PDF/Excel reports via Logic Apps.

4. Submission & Storage

   • Report sent to SEBI SFTP endpoint via Azure Data Factory pipeline.

   • Archived in Azure Blob Storage (immutable WORM policy enabled).

5. Alerting

   • Azure Monitor triggers alert if submission fails / SLA breach.

Security & Observability Across All Personas

• Security:

  • OAuth2/JWT via Azure AD & APIM

  • Managed identities for service-to-service auth

  • NSG + WAF for perimeter defense

  • Data encryption at rest (TDE) & transit (TLS)

• Observability:

  • Distributed tracing with App Insights

  • Centralized logs in Log Analytics

  • Real-time dashboards for API consumption, failures, latency

Hybrid Integration Points

• RTA Systems (Legacy):

  • File-based nightly NAV feeds (Azure Data Factory + Secure FTP)

  • REST APIs for real-time order status

• Payment Gateways:

  • Direct REST integration with fallback queue (Service Bus)

• On-Prem DB Links:

  • Azure SQL MI linked to legacy on-prem SQL for gradual migration

1. Why Azure SQL MI in BFSI Case

• Lift-and-shift from on-prem SQL Server: Maintains compatibility with existing stored procedures, SQL Agent jobs, and cross-database queries.

• Hybrid Connectivity: Supports VPN/ExpressRoute for secure connection to on-prem legacy systems and RTAs.

• Security & Compliance: Built-in encryption (TDE), VNET isolation, and certifications (PCI DSS, ISO 27001, RBI/SEBI-ready).

• PaaS Benefits: Automated backups, high availability (99.99%), patching — reduces ops burden.

2. Key Features Relevant to This Role

• Near 100% SQL Server Compatibility: Use same T-SQL, CLR, linked servers as on-prem.

• Native VNET support: Private IP for secure communication with AKS microservices.

• Automatic HA/DR: Built-in high availability + geo-replication for DR.

• Scale Up/Down: Compute and storage scale independently.

• Hybrid Scenarios: Supports log shipping, transactional replication to sync with on-prem DBs.

3. How It Fits in the Architecture Flow (Per Persona)

Investor Persona (Retail User)

• Real-time Transactions:

  • Order Management Service writes confirmed orders to Azure SQL MI.

  • Portfolio Service queries SQL MI for transactional history (SIP/STP/Redemption).

Distributor Persona

• Bulk Orders:

  • Distributor’s bulk files validated by Order Service → stored in SQL MI before processing.

  • Bulk acknowledgments generated using SQL MI stored procs.

Operations Persona

• NAV & Reconciliation:

  • Reconciliation Service pulls trades from SQL MI + RTA feeds to detect mismatches.

  • NAV Calculation Service stores daily NAV history in SQL MI.

Compliance Persona

• Audit & Reporting:

  • Compliance Service queries audit trails from SQL MI (immutable tables with temporal history).

  • Data exported to Power BI dashboards for SEBI/RBI reporting.

4. Hybrid Integration with Legacy Systems

• Linked Servers:

  • Azure SQL MI → On-prem SQL for partial data migration.

• Data Sync:

  • Azure Data Factory for nightly sync between MI and legacy DBs.

• Change Data Capture (CDC):

  • Track incremental changes for event-driven updates to microservices.

5. Security Implementation

• Always-on encryption (TDE + TLS 1.2)

• Private VNET endpoint (no public exposure)

• Azure AD authentication (Managed Identity for microservices)

• Row-Level Security (e.g., distributor can see only their investors)

6. Cost & Performance Optimization

• Choose General Purpose tier for transactional workloads; Business Critical for low-latency NAV calc.

• Auto-pause compute in non-trading hours (for DR/test environments).

• Partitioning for high-volume transaction tables (SIP orders, NAV history).

7. Role-Specific Talking Point

When asked “Why Azure SQL MI vs Azure SQL Database?”:

• SQL MI supports cross-database transactions, CLR, linked servers (needed for hybrid BFSI workloads).

• Easier lift-and-shift of existing SQL Server codebase (stored procs, Agent jobs).

• Full VNET support → aligns with BFSI zero-trust and private endpoint requirements.

1. Why Cosmos DB in Original Design

• Global distribution & multi-region writes (Active-Active) → supports disaster recovery + low latency for customers across regions.

• Multi-model support (JSON/document store) → natural fit for dynamic portfolio structures (fund holdings, asset allocations).

• Automatic scaling → handles unpredictable market peak traffic (NAV cut-off times).

• Change Feed → directly feeds events to microservices (Portfolio → Notification, Compliance).

• Guaranteed consistency levels (5 modes) → critical for BFSI to balance latency vs accuracy.

2. Why Redis Cache Could Be Considered Instead

• Ultra-low latency (<1 ms) for frequently accessed portfolio snapshots.

• Cost-efficient when used purely as an ephemeral cache (e.g., session-level portfolio view).

• Simple key-value store → ideal for caching computed NAV/portfolio balances per user.

• Integration with Azure Cache for Redis → PaaS service, supports persistence & clustering.

3. Comparison for BFSI Portfolio Use Case

Feature	Cosmos DB	Redis Cache
Data Model	JSON docs, hierarchical portfolios	Key-value pairs (flat structure)
Durability	Fully persistent (transactional)	Ephemeral (persistent option costs more)
Global Distribution	Native multi-region, active-active	Geo-replication (premium tier only)
Real-Time Updates	Change Feed → event-driven microservices	Pub/Sub (manual implementation)
Latency	~10ms (multi-region writes)	~1ms (in-memory)
Complex Queries	SQL-like queries (filters, projections)	Limited (key-based lookup only)
Use Case Fit	Real-time cache + long-term audit trail	Purely volatile cache (fast reads)

4. Recommended Hybrid Approach

In BFSI modernization, best practice is often Cosmos DB + Redis together:

• Redis Cache → Ultra-fast session-level caching

  • Example: When investor opens portfolio, prefetch balances into Redis for 5–10 min TTL.

  • Ideal for dashboards, frequent reads during trading peaks.

• Cosmos DB → Real-time portfolio store (semi-persistent)

  • Source for real-time calculations, Change Feed triggers for notifications.

  • Acts as event sourcing store → enables audit trail + recovery.

5. Justification During Interview

If interviewer challenges: “Why not Redis instead of Cosmos DB?”

• Acknowledge Redis’ low-latency advantage for read-heavy scenarios.

• Explain Cosmos DB is chosen because BFSI needs event sourcing + audit trail + flexible queries (cannot lose data if cache evicts).

• Mention hybrid design: Redis for ephemeral session cache, Cosmos for persistent real-time store.

• Highlight compliance: SEBI/RBI mandates auditable storage, which Redis alone can’t meet.

6. When to Prefer Only Redis

• If portfolio calculation is entirely derived from SQL MI and doesn’t need separate persistence.

• If cost sensitivity is extreme and audit is handled at SQL MI layer.

• If global replication isn’t needed (single-region BFSI setup).

Suggested Final Design (Hybrid)

• SQL MI → System of Record (transactions)

• Cosmos DB → Real-time denormalized portfolio view (event-sourced)

• Redis Cache → Session-level ultra-fast access for dashboards