DIGITAL LENDING RFP Solution

🎯 RFP Proposal SOLUTION PRESENTATION – DIGITAL LENDING (WITH COLOR-CODED ARCHITECTURE)

1️⃣ Opening

“Thank you for the opportunity. I’ll walk you through our approach to building a next-generation digital lending platform, leveraging hybrid multi-cloud, AI/ML, and GenAI, while ensuring resilience, compliance, and cost optimization.”

Executive Summary

We propose a next-generation digital lending platform built on:

• Hybrid multi-cloud architecture

  • Primary: Azure (Mumbai)

  • DR / Failover: GCP (Chennai)

• On-prem core banking systems: LOS, LMS, CBS with low-latency adapters

• Real-time fraud detection: ML pipelines with offline & online feature stores, real-time scoring (<100ms)

• GenAI copilots: Underwriter Copilot, Borrower Assistant, Lending Agreement Reviewer, powered by enterprise Knowledge Hub (LLMOps + RAG Layer)

• Regulatory compliance via Fenergo (KYC/CDD/EDD) and NICE Actimize (AML)

✅ Key Business Outcomes

• 40% reduction in underwriting effort

• Real-time fraud detection

• High availability with multi-cloud resilience

• Regulatory compliance & audit readiness

2️⃣ Business Challenges

“We understand the key challenges are:

• Fraud losses

• Regulatory compliance (KYC / AML)

• High availability & DR readiness

• Scaling to 150k concurrent users

• Leveraging AI & GenAI for efficiency”

3️⃣ Core Design Principles

1. Business-first active-active

• Active-active applied to critical lending journey only

• Not every component (avoids over-engineering)

2. Hybrid architecture

• Core banking + compliance → on-prem

• Digital + AI/ML + GenAI → cloud

3. Event-driven architecture

• Loose coupling

• Resilience + replay capability

4. Cost-optimized resilience

• Active-active (critical)

• Active-passive (non-critical + ML DR)

5. Failover = Activation, Not Restart

GCP doesn’t “wait”👉 It takes over instantly

4️⃣ Architecture Walkthrough

Legend:

[🔵] Critical / Active-Active

[🟢] Non-Critical / Active-Passive

[🟡] AI / ML Layer

[🟠] GenAI Layer

[💾] Data Platform

[⚡] Event Layer

[🏢] On-Prem Core & Compliance

[🛡] Security / IAM

┌──────────────────────────────┐

│ CUSTOMER CHANNELS │

│ Web / Mobile / RM Portal │

└─────────────┬────────────────┘

│

┌─────────────▼─────────────┐

│ GLOBAL TRAFFIC LAYER │

│ DNS / Traffic Manager │

└─────────────┬─────────────┘

│

┌───────────────────────────────────┴───────────────────────────────────┐

│ │

┌───────▼─────────┐ ┌───────────▼─────────┐

│ Azure (Mumbai) │ │ GCP (Chennai) │

│ Primary Region │ │ DR / Failover │

├─────────────────┤ ├─────────────────────┤

│ [🔵] Digital Apps│ │ [🔵] Digital Apps │

│ [🔵] APIs + UI │ │ [🟢] Passive Apps │

│ │ │ │

│ [💾] CosmosDB │ │ [💾] DR DB │

│ Lending Timeline│ │ │

│ │ │ │

│ [💾] Azure Data │ │ [💾] GCP Data Lake │

│ Lake │ │ │

│ Raw→Curated→FE │ │ │

│ │ │ │

│ [🟡] Feature │ │ [🟡] Feature Store │

│ Store (Online) │ │ (Replicated) │

│ │ │ │

│ [🟡] Azure ML │ │ [🟡] GKE / Vertex AI│

│ Inference │ │ ML DR Endpoint │

│ │ │ │

│ [🟠] GenAI │ │ [🟠] GenAI DR │

│ Copilots │ │ │

└─────┬───────────┘ └─────────┬───────────┘

│ │

└───────────────────────────┬─────────────────────────────────────────────┘

▼

┌───────────────────────────┐

│ [⚡] EVENT LAYER │

│ Kafka / BDR / Redis │

└───────────┬───────────────┘

│

▼

┌───────────────────────────┐

│ [🏢] ON-PREM CORE │

│ LOS / LMS / CBS │

│ Fenergo / Actimize │

└───────────┬───────────────┘

│

▼

┌───────────────────────────┐

│ [🛡] SECURITY & IAM │

│ Keycloak + Azure AD │

└───────────────────────────┘

“At a high level:

• Customers access via web/mobile → routed through global traffic layer

• Azure (Mumbai) acts as primary region

• GCP (Chennai) acts as DR / failover

Design Choices

• [🔵] Critical services → Active-Active

• [🟢] Non-critical → Active-Passive

• [⚡] Event layer ensures consistency

• [💾] Data platform powers AI/ML

• [🟡] ML handles real-time decisions

• **[🟠] GenAI enhances business efficiency”

5️⃣ Digital Lending Flow

Digital Lending Layer (Azure Primary / GCP DR)

• Customer-facing services: login, consent, KYC, AML checks, income stability, decision engine, agreement, loan-account setup, disbursement

• Critical services active-active: KYC, AML, income verification, decision engine

• Non-critical services active-passive for cost optimization: e.g., document storage, reporting, analytics

Failover:

• Users routed to nearest region; in case of outage, traffic flows to DR region

• Data consistency ensured via Kafka + Postgres BDR + Redis

✅ Design Choice

Area	Decision	Why
Critical services	Active-active	Business continuity
Non-critical services	Active-passive	Cost optimization
User routing	Geo-based	Avoid data conflicts

💡 Key Insight

“Active-active is applied at business capability level, not every service.”

👉 Avoids data conflicts and ensures continuity”

Functional Requirements

Capability	Response
Customer onboarding	Supported
Document upload	Supported
KYC/AML integration	Supported
Loan processing	Supported
Multi-channel access	Supported
Core banking integration	Supported

6️⃣ Data Platform & ML (Highlight Strongly)

“We built a modern data platform:

• Unified data ingestion:

  • Transactions

  • Customer behavior

  • Device / session data

• Data lake + streaming pipelines

• CosmosDB → event timeline

• Azure Data Lake:

  • Raw → Curated → Analytics

  • Feature Engineering

Feature Strategy:

Feature Engineering Pipeline

• Build features like:

  • Transaction velocity

  • Device fingerprint

  • Behavioral patterns

Feature Store Architecture

Offline Feature Store

• Historical data

• Model training

Online Feature Store

• Low-latency feature access

• Used during inference

Feature Materialization

• Sync offline → online store

Real-Time Inference

• Deployed as:

  • REST/gRPC endpoint

• Latency:

  • < 50–100 ms

  
  

GCP DR

• Replicated:

  • Critical datasets

  • Feature store (online)

  • CosmosDB timeline

Event & Data Layer

• Kafka MirrorMaker: cross-region event replication

• Postgres BDR: database replication

• Redis Enterprise: cache replication

Purpose: Ensure HA, DR, and active-active consistency

✅ Design Choice

Area	Decision	Why
Data Lake replication	Selective (not full)	Cost optimization
Feature replication	Real-time (Kafka)	ML consistency
Offline data	Batch replication	Not latency sensitive

🔥 Key Line:

“We replicate features in real-time, not just data — ensuring ML accuracy during failover.”

Multi-Cloud Connectivity

Connection	Primary	DR / Secondary
Cloud → On-prem	Azure ExpressRoute	GCP Cloud Interconnect
Fallback	VPN	VPN

7️⃣ ML Deployment Strategy

“Azure ML is primary for:

• Training

• Model Registry

• Real time Inference

GCP (DR)

• Containerized ML endpoints:

  
  

  • Models are containerized and deployed on GCP (GKE / Vertex AI)

  • Online features are replicated

  • Activated on failover

✅ Design Choice

Area	Decision	Why
ML deployment	Active-passive	Avoid complexity
Model replication	Container-based	Cloud portability
Feature sync	Streaming	Real-time accuracy

💡 Key Insight

“We avoided full active-active ML to reduce complexity while ensuring DR readiness.”

👉 Ensures:

• Cost optimization

• DR readiness”

🔥 Strong Line:

“So during failover, GCP has both:

• Model

• Features

Which ensures real-time decisioning continues without disruption.”

8️⃣ GenAI / Enterprise Knowledge Hub

• LLMOps Pipeline: Model orchestration, versioning, prompt management

• RAG Layer: Fetch regulatory rules, loan policies, past knowledge

• Copilots:

  • Underwriter: highlights high-risk cases, recommends action→ reduces effort by 40%

  • Borrower Assistant: guides loan applicants→ improves customer experience

  • Lending Agreement Reviewer: summarizes payment terms, EMI, affordability→ summarizes contracts

Deployment: Hybrid (Azure cloud for LLM inference, on-prem for sensitive knowledge

We introduce GenAI through an enterprise knowledge hub:

Architecture

• LLMOps pipeline

• RAG layer

• Hybrid deployment:

  • Cloud → inference

  • On-prem → sensitive knowledge

✅ Design Choice

Area	Decision	Why
GenAI deployment	Hybrid	Data security
Knowledge base	On-prem	Regulatory compliance

👉 Ensures compliance + scalability”

9️⃣ Core Banking & Compliance (On-Prem)

• Core Systems: LOS, LMS, CBS

• Adapters: LOS Adapter, LMS Adapter, CBS Adapter for low latency

• Compliance:

  • Fenergo: KYC/CDD/EDD

  • NICE Actimize: AML & Fraud

Integration: Event-driven → digital layer sends transactions → core & compliance

Benefit: Regulatory workflow, reporting, audit-ready

✅ Design Choice

Keep core & compliance on-prem for regulatory control and stability

9️⃣ Resilience & DR

“Resilience is multi-layered:

• Active-active → critical services

• Active-passive → ML + non-critical

• Kafka + BDR → data sync

Failover:

“If Azure fails:

• Traffic → GCP

• GCP uses:

  • Replicated features

  • ML models

👉 Lending continues seamlessly”

🔟 Security & Regulatory Compliance

“We use:

• IAM: Keycloak integrated with Azure AD

• Protocols: OIDC / OAuth2 / SAML for browser-based apps

• JWT Tokens: Used for service-to-service and user authentication

• Zero-trust

• Encryption:

  • TLS / AES-256

Compliance:

• Data residency

• Auditability

• Compliance workflows via:

  • Fenergo

  • NICE Actimize

Data Consistency Strategy

• PostgreSQL BDR → transactional replication

• Kafka MirrorMaker → event replication

• Redis → cache sync

👉 Supported by:

• Idempotency

• Versioning

• Controlled writes

RFP WAR ROOM & HYPERSCALER PARTNERSHIP

War Room Setup

• Solutioning, Finance, Delivery, Leadership

• Hyperscaler SMEs (Azure + GCP)

Hyperscaler Contributions

Area	Contribution
Azure	ML, CosmosDB, Data Lake
GCP	DR, ML inference, interconnect
Both	Reference architectures, security, CI/CD

💡 Key Insight

“Hyperscalers reduced solution risk and accelerated design by ~20%.

Delivery Plan & Model

Phase	Duration
Foundation + Data Platform	4 months
Core + Integration	6 months
AI/Fraud Implementation	6 months
UAT & Compliance	3 months

👉 Total: 15–18 months

“5 squads, 7-8 members each

Timeline: 18–22 months

POD Team: Digital, AI/ML, GenAI, Integration, DevSecOps”

• MLOps: Azure ML for training & deployment

• LLMOps: Hybrid (Azure + on-prem sensitive data)

• Program governance: Agile, sprint-based delivery with KPIs

Governance

• Hybrid Governance

• Program Governance Weekly program reviews

• Architecture review board (EARB/ARB)

• Risk tracking & escalation

Commercials

Component	Cost ($M)
Implementation	40–50
Cloud (Azure + GCP)	12–15
AI/ML	15–20
GenAI	15–20
COTS(Fenergo + Actimize )	25–30
Support	20–25

👉 Total: $110–150M

Assumptions & Dependencies

• Core APIs exposed via adapters

• Network stability

• Regulatory approvals

Risks & Mitigation

Risk	Mitigation
ML model drift	Continuous monitoring & retraining
Fraud latency	Online feature store & low-latency inference
Compliance delays	Async event-driven workflow
Data conflicts	Controlled writes + idempotency
Cloud outage	Multi-cloud failover
Feature inconsistency	Real-time sync

“What differentiates our solution:

1. Business-driven active-active (not over-engineered)

2. Realistic ML DR strategy

3. Feature-level consistency for AI accuracy

4. Hybrid compliance-ready architecture

5. Strong hyperscaler-backed design

“This architecture balances:

• Resilience (multi-cloud DR)

• Cost (selective active-active)

• Intelligence (AI/ML + GenAI)

While ensuring a future-ready, compliant digital lending platform.

“This solution integrates cloud-native digital lending with on-prem core banking and compliance platforms, while also introducing real-time fraud detection using advanced AI/ML capabilities. Customer onboarding is handled in the cloud, while compliance workflows such as KYC and AML are executed on-prem via event-driven integration with platforms like Fenergo and NICE Actimize through low-latency adapters.. The fraud detection layer uses a feature store architecture with real-time inference to detect risk within milliseconds.GenAI-powered copilots for underwriting, borrower assistance, and agreement analysis, built on an enterprise knowledge hub using LLMOps and RAG. The platform is deployed across Azure and GCP with resilient connectivity to on-prem systems, ensuring high availability and regulatory compliance. This design enables a scalable, intelligent, secure digital lending ecosystem, compliance, and a superior customer and operation experience.”

Panel may ask few questions please be ready with your answer

❓ 1. If both regions are active, why do you still need DR?

“Active-active ensures availability, but DR is still required for catastrophic failure scenarios.”

Explain clearly:

1. Active-active = both regions serve traffic

2. But:

   • Cloud-wide outage

   • Data corruption

   • Cyber attack

3. DR ensures:

   • Clean recovery point

   • Isolation from failure

👉 Punchline:

“Active-active is for availability; DR is for survivability and recovery.”

❓ 2. If ML is not active-active, is this a true active-active system?

“Yes, because active-active is applied at the business capability level, not every component.”

Break it down:

1. Critical user journey (loan processing) → active-active

2. ML inference → active-passive (but fast failover)

3. Trade-off:

   • Avoid complexity

   • Optimize cost

👉 Punchline:

“We prioritize active-active for business continuity, not for every technical component.”

❓ 3. How do you avoid data conflicts in active-active?

“We prevent conflicts by design, not by resolution.”

Steps:

1. Geo-routing → user sticks to one region

2. Session affinity / token routing

3. Idempotent APIs

4. Event ordering (Kafka partitioning)

👉 Punchline:

“Instead of resolving conflicts later, we design the system to avoid them upfront.”

❓ 4. What if CosmosDB and Postgres become inconsistent?

“We treat them as different sources of truth.”

Explain:

1. Postgres → transactional truth

2. CosmosDB → event timeline / projection

3. Sync via events (event sourcing pattern)

👉 If mismatch:

• Rebuild CosmosDB from event logs

👉 Punchline:

“CosmosDB is eventually consistent and rebuildable; Postgres is the source of truth.”

❓ 5. Why not keep everything on one cloud?

“We chose multi-cloud for risk diversification and regulatory alignment, not trend.”

Explain:

1. Avoid vendor lock-in

2. Regulatory requirements (data locality / resilience)

3. DR isolation (true independence)

👉 Punchline:

“Multi-cloud is a strategic risk decision, not just a technology choice.”

❓ 6. How do you test DR?

“We follow structured DR testing.”

Steps:

1. Planned failover drills

2. Partial failure testing (ML / DB / API)

3. Data validation post failover

4. RTO / RPO measurement

👉 Punchline:

“DR is validated continuously, not assumed.”

❓ 7. What is your RTO and RPO?

“Defined based on business criticality.”

Example:

• Critical services:

  • RTO: few minutes

  • RPO: near-zero

• Non-critical:

  • RTO: hours

  • RPO: acceptable lag

👉 Punchline:

“RTO/RPO are business-driven, not technology-driven.”

❓ 8. How do you control cloud cost in this architecture?

“Cost optimization is built into architecture.”

Steps:

1. Active-active only for critical services

2. Active-passive for non-critical

3. ML not active-active

4. Storage tiering (hot / cold data)

5. Reserved instances / committed usage

👉 Punchline:

“We balance resilience and cost through selective activation.”

❓ 9. What if Kafka replication fails?

“We design for failure.”

Steps:

1. Retry + backpressure

2. Dead Letter Queue (DLQ)

3. Replay from offset

4. Monitoring & alerts

👉 Punchline:

“Event-driven systems are resilient because they support replay and recovery.”

❓ 10. How do you ensure security across multi-cloud?

“We enforce centralized identity with federated control.”

Steps:

1. Keycloak + Azure AD federation

2. OIDC / SAML for authentication

3. JWT tokens for services

4. Zero-trust principles

5. Encryption in transit & at rest

👉 Punchline:

“Identity is centralized, enforcement is distributed.”

❓Why didn’t you make ML fully active-active across Azure and GCP?

“Full active-active ML across clouds adds significant complexity — especially around model consistency, feature synchronization, and latency. Instead, we designed active-active at the application layer and active-passive for ML inference, where: Azure ML handles primary inference GCP hosts containerized DR endpoints This ensures resilience without unnecessary cost and operational overhead, while still meeting real-time fraud detection SLAs.”

❓ How do you ensure feature consistency between Azure and GCP?

“We separate offline and online feature flows: Offline features (training) are replicated in batch. Online features are synchronized using Kafka-based streaming Feature materialization ensures the same feature definitions are used across regions. This guarantees that ML predictions remain consistent during failover.”

❓What happens if feature replication lags? Won’t ML predictions be wrong?

“Good point — we handle this with: SLA-based lag monitoring for feature pipelines Graceful degradation (fallback rules or last known features) Critical features prioritized for real-time sync So even in lag scenarios, we ensure controlled and explainable decisions, which is important for banking.”

❓ How do you deploy ML models from Azure to GCP?

“Models trained in Azure ML are: Serialized (e.g., ONNX / pickle / containerized format) Packaged into Docker containers Deployed on GKE or Vertex AI endpoints in GCP CI/CD pipelines ensure that every model version in Azure is replicated to GCP, maintaining DR readiness.”

❓ How fast is your failover for ML inference?

“Failover is near real-time: Traffic rerouted via DNS / API gateway GCP already has: Latest model container Synced online features So inference resumes almost immediately, with minimal latency impact.”

❓ Why use CosmosDB for lending timeline? Why not Postgres?

“CosmosDB is ideal because: It handles high-volume, event-based, semi-structured data Provides low-latency reads/writes globally Supports flexible schema for evolving lending events Postgres is used for transactional consistency, while CosmosDB is optimized for event timeline and journey tracking.”

❓How do you ensure data consistency in active-active setup?

“We use a combination of: Kafka (event streaming) for eventual consistency Postgres BDR for database replication Idempotent APIs to prevent duplicate processing Also, user operations are typically region-local, which reduces conflict scenarios.”

❓What if both regions process the same user request?

“We avoid that using: Geo-routing (user sticks to one region) Session affinity / token-based routing Idempotency keys for APIs So duplicate processing is prevented at design level.”

❓ How did hyperscaler partnership really help here?

“Hyperscaler collaboration was key: Azure team helped with ML architecture, feature store, and CosmosDB patterns GCP team validated DR strategy, containerized ML inference, and interconnect setup We leveraged reference architectures and accelerators, reducing solutioning time by ~20% This ensured the design was validated, scalable, and production-ready.”

❓ What is your biggest risk in this architecture?

“The biggest risk is feature inconsistency across regions impacting ML decisions. We mitigate this via: Real-time feature sync for critical features Monitoring & alerting Fallback strategies This ensures decision reliability even during DR scenarios.”

🌐 Multi-Cloud Data & ML Replication Strategy

1️⃣ Azure Data Lake → GCP Data Lake Replication

• Purpose: DR / failover of raw, curated, and analytics data for digital lending pipeline

• Approach:

Step	Description
1. Raw Data Ingestion	All lending events, transactions, and KYC/AML logs are ingested into Azure Data Lake (raw layer).
2. Curated / Analytics Layer	Transform raw data into curated + aggregated datasets for ML feature engineering.
3. Feature Engineering	Offline features generated here → materialized for online feature store.
4. Cloud-to-Cloud Replication	Use cross-cloud replication pipelines:  - Option 1: Scheduled / streaming data export from Azure Blob Storage → GCP Cloud Storage / Data Lake.  - Option 2: Use Apache Spark / Dataflow pipelines with connectors for Azure → GCP.  - Option 3: Hybrid Kafka topics that stream transformed features → GCP feature store in near real-time.
5. Online Feature Store in GCP	Updated features consumed by containerized ML inference endpoints on GCP during DR.

Key Principle: Only critical datasets & features are replicated to DR (cost optimization). Non-critical analytics can be rebuilt in DR on-demand.

2️⃣ ML Model & Inference Replication

• Primary Region (Azure ML)

  • Training, online inference (<100ms latency), feature access from Azure feature store

  • Generates ML models, serialized artifacts, and endpoint containers

• DR Region (GCP / GKE)

  • Containerized ML inference deployed to GKE for DR failover

  • Feature replication: Online features synced from Azure → GCP using streaming / event-driven pipelines (Kafka MirrorMaker or Dataflow)

  • Offline features / model artifacts replicated using cloud storage sync (Blob → GCS)

  • DR endpoint becomes active only if Azure ML goes down

Notes:

• Azure ML itself doesn’t run natively on GCP; we export models as containerized endpoints and deploy on GKE

• Features must be kept in sync to ensure inference correctness. This is done via streaming replication or event-driven pipelines.

• Non-critical model artifacts (training datasets, offline analytics) can be stored in GCP cold storage; real-time inference uses synced online features + model container.

3️⃣ Data Consistency & DR

• Event Layer (Kafka / Postgres BDR / Redis) replicates transactional & real-time events across regions

• Single Writer Principle:

  • Active-active for critical services ensures both regions can serve traffic

  • Features / ML pipelines are reconciled continuously to handle eventual consistency

• Failover Scenario:

  • Azure primary goes down → users routed to GCP

  • Containerized ML endpoints in GCP + replicated online features serve real-time inference

  • Core digital lending workflow continues uninterrupted

“For multi-cloud DR, Azure Data Lake feeds our ML feature pipeline — offline features are materialized, online features are synced via streaming pipelines to GCP. ML models trained on Azure ML are exported as containerized endpoints and deployed to GKE in GCP. In DR, the online feature store + model container serve inference for sub-ms latency, ensuring critical lending workflows continue even if Azure region is down. Event-driven replication (Kafka / Postgres BDR / Redis) ensures data consistency, and we replicate only critical datasets to optimize cost. Non-critical analytics can be rebuilt in DR on-demand.”