Project Flux
A high-velocity financial switchboard built for managing the friction between high-speed consumer retail and legacy banking.
Project Flux: A High-Velocity Financial Switchboard
Built for managing the friction between high-speed consumer retail and the slow, heavy machinery of legacy banking.
The Problem: The Point-of-Sale Bottleneck
Imagine a customer at a store like Croma or Reliance Digital. They've picked out the latest iPhone to buy and want to pay by EMI. They don't have a credit card, and the existing in-store EMI process by Bajaj Finance is full of manual paperwork, slow, and cumbersome. At that moment, the merchant wants a sale, and the customer wants instant gratification - but both are being threatened by the clumsy process.
Our client, a rising star in the Fintech space, sat right in the middle. Their thesis was: what if the cumbersome in-store EMI process could be transformed into just a few taps in an app? So they thought of a waterfall lending approach: a loan application process completely online that tried multiple lenders one after another, until one of them accepted and disbursed the loan. The 30-minute offline process could happen online in less than two minutes.
That's when they hired us to build it for them.
Our client already had a few things set up before they engaged us: contracts with leading NBFCs in India (think ABFL, Piramal Capital, Hero Fincorp, and Tata Capital) to begin lending, agreements with major retail chains (Croma, Reliance, Sangeetha Mobiles, DMart, Aditya Birla Fashion, Vijay Sales, Zudio, among others) for letting customers buy products on EMIs, and a mobile app that customers could download and use at those retail stores. What's missing was: a loan management system, and API integrations between the NBFCs and their internal LMS.
All this with a big catch. Every lender had different rules, different APIs, and different "appetites" for risk. If the first lender said no, the system had to pivot to the second, then the third—all while the customer was standing at the checkout counter. They needed a production-grade engine that could handle the chaos of real-time credit decisions. They wanted to have a system that could find a lender and disburse the loan at the speed of a typical credit card transaction.
The Core Architecture
We built a fully decoupled micro‑services ecosystem on Amazon EKS that delivers a fault‑tolerant, real‑time loan‑checkout experience for a multi‑NBFC consumer‑lending product. The design follows the principles of bounded context, autonomous deployment, and graceful degradation, so that a single NBFC's API outage can never cascade into a full‑checkout failure.
Service Map – Detailed Component Architecture
Below is a deeper dive into each bounded context, the technologies that power it, and the business value each delivers.
1. Lender Selector – High‑Speed Business Rules Engine
| Feature | Implementation Details |
|---|---|
| Rule authoring | A React‑based UI backed by a GraphQL gateway that writes rule definitions to Amazon DynamoDB (fast, schemaless storage). |
| Rules execution | A Drools‑derived rule‑engine container (Java 17) that evaluates ~10,000 + “risk dials” per second, leveraging caching via Amazon ElastiCache (Redis) for static lookup tables (CIBIL score bands, age brackets, geographic risk weights). |
| Live‑tuning | UI exposes feature‑flags (via LaunchDarkly) so credit‑team analysts can adjust thresholds (e.g., “CIBIL ≥ 750”) in real time without a code deployment. Changes propagate instantly through an AWS SNS that the engine subscribes to. |
| Performance | Sub‑10 ms latency per request under a 5,000 RPS load (synthetic load‑tests). |
| Business impact | Empowers the client’s risk‑team to iterate on underwriting policies daily, cutting time‑to‑market for new credit products from weeks to hours. |
2. Lender Orchestrator – The “Traffic Controller”
| Feature | Implementation Details |
|---|---|
| State management | AWS Step Functions (Express workflow) orchestrates the end‑to‑end loan‑application saga, persisting state in Amazon Aurora MySQL with event‑sourcing for full auditability. |
| Compensation actions | If a downstream bank rejects the request, compensating transactions (e.g., rollback of provisional hold, notification to user) are automatically triggered via the saga. |
| Idempotency | All service calls are wrapped with idempotency tokens stored in Aurora, guaranteeing exactly‑once semantics even when retries occur. |
| Resilience | Circuit‑breaker policies (via Resilience4J) and adaptive retry back‑off are configured per‑bank endpoint, preventing a misbehaving API from exhausting thread pools. |
| Scalability | Stateless orchestrator pods horizontally scale behind an ALB; Step Functions can handle millions of concurrent executions, ensuring the platform can support “Black Friday” traffic spikes. |
| Business impact | Guarantees a graceful degradation path: if Bank A is down, the orchestrator instantly reroutes the applicant to the next eligible lender, preserving the checkout flow and protecting revenue. |
3. Lender Adapter – Low‑Code Integration Harness
| Feature | Implementation Details |
|---|---|
| Integration model | AWS API Gateway + Spring Boot Microservice expose a Unified Lending API (REST/JSON) internal to the platform. The microservice layer leverages Apache Quartz Jobs to perform workflow orchestration and offload short term memory to a Redis cluster. |
| Plug‑and‑play onboarding | A JSON-driven connector descriptor defines endpoint URLs, auth scheme (OAuth 2.0, mutual TLS, or API‑key), request/response mapping, and validation rules. The descriptor is version‑controlled in the client’s Git repo. |
| Business impact | Reduces integration lead‑time from months to days, enabling the client to capture market share quickly as new partner banks become available. |
4. Loan Management System (LMS) – The Immutable “Source of Truth”
| Feature | Implementation Details |
|---|---|
| Data model | Event‑sourced ledger stored in Amazon Aurora MySQL with a write‑ahead log (WAL) to ensure no transaction gets lost. |
| Versioned snapshots | Periodic snapshots are materialised in Amazon S3 (Parquet) for cost‑effective long‑term retention (24 months) and BI querying via Amazon Athena. |
| ACID guarantees | Transactions are wrapped in two‑phase commit across Aurora and DynamoDB (for quick‑lookup caches) to guarantee consistency of loan status, payment schedule, and “No‑Dues” certification. |
| APIs | gRPC services expose loan‑state CRUD operations; the API surface is documented with OpenAPI 3.1 for external consumption (e.g., the client’s mobile app). |
| Business impact | Serves as the single source of truth for all downstream systems (collections, reporting, compliance), eliminating data silos and reducing reconciliation effort by > 90 %. |
5. Agreement & Notification Services
| Feature | Implementation Details |
|---|---|
| Message bus | Amazon SQS FIFO queues trigger AWS Lambda functions (Python 3.11) that process agreement generation and notification dispatch in parallel, guaranteeing order and exactly‑once processing. |
| PDF generation | A headless Chromium + Puppeteer container renders HTML templates (Handlebars) into high‑fidelity PDFs (digital signatures applied via DocuSign SDK). PDFs are stored in S3 (SSE‑KMS) and a pre‑signed URL is sent to the user. |
| Multi‑channel delivery | Integration with Amazon SNS for SMS (via Twilio), Email (Amazon SES), and in‑app push (Firebase Cloud Messaging). Each channel is abstracted behind a Strategy pattern to allow easy addition of new mediums. |
| Retry & back‑off | Workers implement exponential back‑off and dead‑letter queues; failed notifications are automatically escalated to the ops dashboard (Grafana alert). |
| Compliance | All outbound messages contain mandatory disclosures (RBI, GDPR) injected at runtime via the templating engine. |
| Business impact | Guarantees that borrowers receive legally binding agreements within seconds of approval, and that follow‑up communications (EMI reminders, payment confirmations) are delivered reliably, improving on‑time repayment rates by ~ 12 %. |
The Technical Hurdles, and how we overcome them
In FinTech, the "happy path" is easy. We earned our keep by solving the "nightmare paths."
1. The "Ghost Loan" Sync (Data Consistency)
The Challenge: Sometimes, a bank would approve a loan, but their API would timeout before telling us. We’d move to the next lender, potentially creating two loans for one customer.
The Solution: We implemented a "Double-Check" pattern in the Lender Orchestrator. Before the orchestrator moved to "Lender B," it would fire a background "Status Inquire" to "Lender A" to confirm the failure. We used Redis-based distributed locking to ensure no two processes could ever act on the same loan simultaneously.
2. The Legacy API Issues
The Challenge: One major lending partner required a 4-step authentication handshake that expired every 15 minutes. Hard-coding this logic for every bank was a maintenance trap.
The Solution: This is why we built the Lender Adapter as a low-code harness. We created a "Workflow Runner" based on Apache Quartz. We could define a bank's unique handshake as a series of "Steps" in a JSON config. If a bank changed their auth logic, we just updated a config file—no code deploy required.
3. The 4:00 PM Notification Spike
The Challenge: Most EMI repayments happen around the same time. Sending 50,000 SMS and App notifications simultaneously would lag the database and slow down the "Selector" for new customers.
The Solution: We completely decoupled the Notification Service using AWS SQS. The LMS would just "fire and forget" a message into the queue. The Notification Service would then consume those messages at a controlled rate, ensuring the core loan engine stayed snappy even during peak repayment hours.
4. PDF Generation at Scale
The Challenge: Generating a 10-page, legally binding loan agreement with watermarks and digital signatures is CPU-intensive. Doing this in the middle of a checkout flow was killing performance.
The Solution: We moved PDF generation out of the "critical path." The customer gets an "Instant Approval" screen, while a Lambda-based Agreement Service generates the PDF in the background and stores it in AWS S3. The customer receives the document via a signed link two minutes later, keeping the store checkout time under 60 seconds.
Why It Worked
We didn't just give them a "Loan App." We gave them a scalable engineering practice.
- Fixed Cost, Zero Surprises: We planned the microservice boundaries so clearly during discovery that the budget never shifted, even as we added complex bank integrations.
- Total Visibility: With New Relic instrumented into every microservice, the client could see exactly which bank was responding slowly, allowing them to have data-driven conversations with their partners.
- Ownership: We handed over a clean, Dockerized codebase. On launch day, their internal team was already trained on how to use the low-code harness to add their next partner.