Table of Contents
In 2025, MAS issued 47 regulatory circulars. HKMA updated its AI risk management guidance three times. Compliance teams across BFSI — banking, financial services, and insurance — were expected to absorb, cross-reference, and act on all of it, without proportional increases in headcount. The result is predictable: stretched compliance officers, delayed reviews, and audit-readiness gaps that cost institutions millions in remediation and fines.
Retrieval-Augmented Generation (RAG) is the technology changing this equation. Banks and insurers in Singapore and Hong Kong are deploying RAG systems that compress four-hour regulatory gap analysis sessions into four-minute operations, produce cited answers that survive regulatory examination, and update instantly when new circulars are issued — without any model retraining. This article explains exactly how they are doing it, what architecture powers these systems, and how to implement one in your institution.
Why Compliance Costs Are Straining BFSI Teams in Singapore and Hong Kong
Compliance in banking and financial services has always been demanding. But the last three years have pushed the function to a breaking point across Singapore and Hong Kong. MAS has accelerated its regulatory output — covering technology risk, AI governance, ESG disclosures, AML/CFT enhancements, and consumer protection — while HKMA has simultaneously updated its supervisory frameworks for AI, operational resilience, and digital assets.
The result is a compound problem. Compliance teams must absorb a 30–40% increase in regulatory documentation without proportional headcount growth. A senior compliance officer at a mid-size bank in Singapore may be personally responsible for tracking dozens of active regulatory obligations — each with its own interpretation, implementation deadline, and audit evidence requirement. The cognitive load is unsustainable, and manual approaches inevitably create gaps.
The traditional responses — hiring more compliance staff, engaging external legal counsel for gap analysis, or relying on expensive regulatory intelligence subscriptions — address symptoms rather than the root cause. The root cause is that compliance knowledge work is fundamentally a document retrieval and synthesis problem. And in 2026, that is exactly the class of problem that AI handles best.
Key compliance pain points driving RAG adoption in BFSI:
- Volume overload: 47 MAS circulars in 2025 alone, plus HKMA updates, FATF guidance, and internal policy changes — far exceeding what manual tracking can reliably cover
- Cross-referencing burden: Gap analysis requires matching new regulatory requirements against multiple internal policies simultaneously — a multi-document retrieval task
- Audit response pressure: Regulatory examinations require assembling evidence packages under tight deadlines, where a single missed document can trigger follow-up scrutiny
- Regulatory change velocity: When MAS or HKMA issues new guidance, impact assessments that previously took 3–5 days must now be completed within 24–48 hours
What RAG Actually Is, Explained for Compliance Leaders
Retrieval-Augmented Generation (RAG) is an AI architecture that solves one of the most critical limitations of standard large language models: they do not know your organisation’s specific data. A standalone GPT-4 or Claude model has never read your internal compliance policies, your institution’s specific interpretations of MAS circulars, or the audit evidence you filed last quarter. It generates plausible-sounding text based on public training data — which is dangerous in a compliance context.
RAG changes this by inserting a retrieval step before generation. When a compliance officer asks “What does MAS Notice 637 require regarding internal audit of credit risk models?”, the system does not rely on the model’s training data. Instead, it searches your compliance knowledge base in real time, retrieves the most relevant sections of Notice 637 alongside your internal policy documents and any relevant gap analysis reports, then uses the language model to synthesise a precise, cited answer from those retrieved documents.
The architecture has three core components:
- Knowledge Base: Your compliance documents — MAS circulars, HKMA SPM sections, internal policies, product approval documents, audit reports — ingested, chunked, and indexed in a vector database.
- Retrieval Layer: When a query is submitted, this layer searches for the most semantically relevant document chunks using a combination of dense vector search and keyword matching.
- Generation Layer: A large language model synthesises the retrieved chunks into a coherent, cited, auditable answer — constrained to only use the retrieved content, dramatically reducing hallucination risk.
The most important distinction for compliance contexts: the LLM is never the source of truth. It is the reasoning engine. The source of truth is your compliance knowledge base. Every answer cites the specific document and section that informed it, creating an auditable trail that regulators can examine.
RAG vs. Fine-Tuning: Which One Compliance Teams Actually Need
Enterprise leaders sometimes conflate RAG with fine-tuning. They serve different purposes, and for compliance use cases, the distinction matters enormously.
| Dimension | RAG | Fine-Tuning |
|---|---|---|
| Knowledge source | Your documents, retrieved at query time | Baked into model weights at training time |
| Data freshness | Real-time — add a new circular, it's instantly searchable | Static — requires expensive retraining to update |
| Auditability | High — every answer cites its source documents | Low — model reasoning is opaque |
| Hallucination risk | Low — constrained to retrieved context | Moderate — model can generate beyond training data |
| Regulatory compliance | Directly satisfies MAS/HKMA explainability requirements | Difficult to demonstrate model decision traceability |
| Setup time | Weeks | Months |
| Cost | Moderate setup, low ongoing | High GPU cost, periodic retraining expenses |
For BFSI compliance — where regulations change constantly, auditability is mandatory, and hallucinated regulatory guidance could trigger supervisory action — RAG is the only viable approach. Fine-tuning is appropriate for adjusting model behaviour (tone, output format, task execution), not for injecting up-to-date regulatory knowledge.
MAS and HKMA Rules Every AI Compliance Leader Must Know
One of the most common questions from compliance and technology leaders in Singapore and Hong Kong: does deploying AI for compliance create new regulatory obligations? The answer is yes — but RAG’s architecture is specifically well-suited to meeting them.
1. MAS TRM 2021 and the Case for Model Explainability
The Monetary Authority of Singapore’s Technology Risk Management (TRM) Guidelines 2021 require financial institutions to implement robust model risk management frameworks for AI and algorithmic systems used in material processes. Key requirements directly relevant to RAG deployments include:
- Model governance and validation: AI systems must have documented development, testing, and approval processes. Your RAG pipeline requires a model risk governance framework covering the embedding model, the LLM, and the retrieval logic. Regulators will ask for this during Technology Risk examinations.
- Explainability: MAS TRM explicitly requires that institutions be able to explain AI model outputs to management and regulators. RAG’s citation mechanism directly satisfies this — every answer includes the specific document and section that informed the response, creating an auditable explanation chain.
- Data quality and lineage: The guidelines require tracking of data sources, quality assurance steps, and version control. RAG systems that log which documents were retrieved for each query, when those documents were last updated, and who approved them provide exactly this lineage.
- Operational resilience: AI systems supporting critical compliance processes must have fallback mechanisms. Document fallback procedures in your business continuity plan.
- Third-party risk management: If you use cloud-hosted vector stores or external embedding model APIs, MAS TRM requires third-party due diligence documentation. Verify SOC 2 Type II certifications and ensure contracts include appropriate data processing and audit clauses.
2. HKMA Supervisory Policy Manual on AI Governance
The Hong Kong Monetary Authority’s Supervisory Policy Manual (SPM) addresses AI governance across multiple modules. HKMA-regulated institutions deploying RAG for compliance purposes need to demonstrate:
- Board and senior management oversight: AI governance must be embedded in institutional governance structures. Compliance RAG systems should be reviewed and approved by your Chief Compliance Officer and, for material systems, reported to the Risk Committee.
- Model risk management: Similar to MAS TRM, HKMA requires documented model validation, performance monitoring, and periodic review. Establish a model risk rating for your RAG system based on materiality and implement review cadences accordingly.
- Data governance: HKMA expects institutions to maintain complete records of data used by AI systems. For RAG, this means documenting every document in your knowledge base, tracking versions, and maintaining records of when regulatory content was added, updated, or deprecated.
- Audit trail: Every query, every retrieval, and every generated answer must be logged with timestamp, user identity, and source documents. These logs are your primary evidence during HKMA examinations.
- Human oversight: For high-stakes decisions — product approvals, audit responses, regulatory submissions — HKMA expects human review of AI-generated outputs. Design your RAG system as decision-support, not a replacement for human judgment.
Key Insight: RAG does not create regulatory problems — it solves them. The architecture’s inherent citation and logging capabilities directly address the explainability, auditability, and traceability requirements that MAS TRM 2021 and HKMA SPM demand of AI systems in compliance contexts.
High-Value RAG Use Cases Transforming BFSI Compliance
Not all compliance workflows are equally amenable to RAG automation. The highest-value use cases share a common characteristic: they involve retrieving and synthesising information from multiple documents to answer a specific regulatory or policy question. Here are the four use cases delivering the most measurable impact in Singapore and Hong Kong BFSI deployments.
1. Regulatory Q&A and Gap Analysis
This is the entry point for most compliance RAG implementations. A compliance officer needs to answer questions like: “What does MAS Notice 637 require regarding stress testing of credit portfolios?”, “How does our internal capital policy compare to the HKMA’s ILAAP requirements?”, or “Are there any gaps between our AML procedures and the latest FATF recommendations?”
Without RAG, answering any of these questions requires manually searching through regulatory documents, cross-referencing internal policies, and synthesising a comparison — a process that typically takes 2–4 hours per question. With RAG, the system retrieves the relevant sections from MAS notices, HKMA circulars, internal policy documents, and gap analysis templates simultaneously, then synthesises a cited answer in under 60 seconds.
In production deployments at Singapore banks, this use case alone has reduced regulatory lookup and gap analysis time by 65–70%, freeing compliance officers to focus on interpretation and remediation rather than document search. The cited output is also audit-ready: the specific regulatory sections and internal policy paragraphs that informed the answer are logged and can be produced in a regulatory examination.
2. New Product Compliance Review
Every new product, service, or significant feature change in a bank must pass a compliance review — verifying that the product design, marketing materials, and operational procedures are consistent with applicable regulations. These reviews involve checking dozens of regulatory requirements across multiple frameworks: MAS consumer protection guidelines, PDPA requirements, AML/CFT obligations, and applicable HKMA notices for cross-border products.
A RAG system equipped with the institution’s complete regulatory knowledge base can accelerate this process dramatically. A compliance analyst submits the product concept document, and the system retrieves all applicable regulatory requirements, flags potential gaps between the product design and regulatory expectations, and generates a structured compliance checklist with source citations. Human reviewers then focus on assessing the gaps rather than discovering them.
One Hong Kong wealth management firm implementing this workflow reduced average new product compliance review time from 15 business days to 5 business days — a 67% improvement — while simultaneously improving the thoroughness of reviews by ensuring no applicable regulatory framework was overlooked.
3. Regulatory Change Impact Assessment
When MAS or HKMA issues new guidance, compliance teams must assess its impact across the institution: which products, processes, and policies are affected, what changes are required, and by when. A RAG system automates the first pass of this analysis. The new circular is ingested into the knowledge base immediately upon publication. Compliance staff then query the system for key changes, affected internal policies, and impacted processes — getting a structured impact summary in hours rather than days.
This transforms what was previously a 3–5 day manual impact assessment exercise into a 2–3 hour process where the AI generates the initial mapping and humans validate and prioritise remediation. For an institution managing simultaneous implementation of five to ten regulatory changes — a common situation in the current environment — this efficiency gain is transformational.
4. Audit Response and Evidence Assembly
External audits and regulatory examinations require banks to assemble evidence packages — demonstrating that specific regulatory requirements were met, with supporting documentation. Under time pressure, compliance teams must locate relevant policies, procedural evidence, testing records, and approval trails. A RAG system over your compliance document repository dramatically accelerates this assembly.
Beyond speed, this use case reduces the risk of incomplete evidence packages — a significant concern, since incomplete responses to regulatory inquiries can result in follow-up examinations and, in serious cases, formal supervisory actions.
Technical Architecture of a Production-Grade BFSI RAG Stack
Understanding the architecture of a production BFSI RAG system helps compliance and technology leaders make informed decisions about vendor selection, implementation approach, and data governance. The following five-layer architecture represents the pattern used in production compliance RAG deployments in Singapore and Hong Kong.
Layer 1: Document Ingestion and Preprocessing
The quality of a RAG system is overwhelmingly determined by the quality of its data pipeline. For BFSI compliance, this layer must handle a heterogeneous document landscape: MAS circulars in PDF format, HKMA SPM modules, internal policy documents in Word and PDF, procedural guides, audit evidence in Excel, and regulatory correspondence.
Key design decisions at this layer:
- Chunking strategy: Regulatory documents have hierarchical structures — sections, subsections, clauses. Semantic chunking that preserves these boundaries outperforms simple fixed-size splitting. Hierarchical chunking — maintaining parent section context with each child chunk — is particularly valuable for regulatory documents where sub-clauses only make sense in their section context.
- Metadata enrichment: Every chunk should carry structured metadata: source document name, document type, publication date, effective date, expiry date, access classification, and responsible business unit. This metadata powers filtered retrieval and access control.
- Multilingual handling: Both Singapore and Hong Kong compliance contexts increasingly require processing documents in English and Chinese. Embedding models must support cross-lingual retrieval.
- Version control: When MAS issues an updated circular that supersedes a prior one, the old version must be flagged as deprecated — not deleted. Historical queries need to retrieve the version that was in force at a specific time.
Layer 2: Embedding and Vector Storage
Embedding models convert text chunks into high-dimensional vectors that encode semantic meaning, enabling similarity search. For BFSI compliance:
- Model selection: OpenAI text-embedding-3-large (3072 dimensions) and Cohere embed-v3-multilingual are the most commonly used in Singapore/HK deployments. For institutions requiring on-premises deployment due to data residency constraints, BGE-M3 (open source, multilingual, self-hostable) is the standard alternative.
- Vector database: Enterprise-grade options include Qdrant (preferred for on-premises/self-hosted deployments where data residency is critical), Azure AI Search (for institutions already on Microsoft stack with Azure Singapore/HK availability zones), and pgvector for institutions preferring PostgreSQL-native solutions.
- Index design: Separate vector namespaces or collections for different document classification levels enable retrieval-time access control — sensitive documents are never even retrieved for users without appropriate clearance.
Layer 3: Hybrid Retrieval and Reranking
Naive semantic search alone misses critical compliance content. Compliance queries often contain exact terminology — specific notice numbers, clause references, defined terms — where keyword matching outperforms pure semantic similarity. Production BFSI RAG uses hybrid retrieval combining dense vector search (semantic meaning) and BM25 keyword search (exact matches), fused via Reciprocal Rank Fusion (RRF). A second-pass cross-encoder reranking model then re-scores the top-k candidates for precision, adding 200–400ms latency but meaningfully improving answer quality for complex regulatory queries.
Layer 4: Generation and Compliance Guardrails
The generation layer transforms retrieved chunks into structured, cited compliance answers. GPT-4o via Azure OpenAI in Singapore/HK regions and Claude 3.5 Sonnet are the dominant choices for BFSI deployments. The system prompt must explicitly instruct the model to: (a) only answer based on retrieved context, (b) cite specific source documents and sections, (c) express explicit uncertainty when retrieved context is insufficient, and (d) refuse to speculate beyond the provided regulatory documentation.
Layer 5: Audit Logging and Access Control
This layer is non-negotiable for BFSI compliance. Every query, every retrieved document chunk, and every generated answer must be logged with user identity, timestamp, retrieved document names and versions, generated answer text, retrieval confidence scores, and any access control filters applied. These logs serve as your primary evidence for MAS/HKMA examinations, your audit trail for PDPA compliance, and your source material for continuous improvement of the retrieval system.
Access control must be enforced at retrieval time — not at the application layer. Metadata filters on the vector store ensure that a user querying the system can only retrieve documents they are authorised to access. Never rely on prompt-level instructions to enforce access control in a compliance RAG system.
Data Residency and Security for Singapore and Hong Kong Deployments
Data residency is a critical architecture constraint for BFSI institutions in Singapore and Hong Kong. Both MAS-regulated entities (under MAS Outsourcing Guidelines) and HKMA-regulated entities have obligations around where customer data and sensitive institutional data is processed and stored.
Every layer of the RAG stack must be evaluated for data residency compliance:
- Document ingestion: Cloud options include AWS Singapore (ap-southeast-1), AWS Hong Kong (ap-east-1), Azure Southeast Asia (Singapore), Azure East Asia (Hong Kong), GCP Singapore, and GCP Hong Kong.
- Embedding models: Enterprise API agreements for OpenAI and Cohere typically offer data residency commitments. For maximum control, self-hosted embedding models (BGE-M3, E5-large) eliminate this concern entirely.
- Vector database: Self-hosted Qdrant or pgvector on institution-managed infrastructure provides the strongest data residency guarantee. Managed services in approved SG/HK regions are acceptable with appropriate contractual commitments.
- LLM inference: Azure OpenAI in Singapore/HK regions, AWS Bedrock with Claude in ap-southeast-1, or fully on-premises deployment via Ollama/vLLM are the compliant pathways.
Key Insight: Data residency is an architecture decision, not a post-deployment remediation. Design your cloud region configuration before you write a single line of code. Retrofitting data residency controls into a live system is expensive and disruptive.
Implementation Roadmap: From Pilot to Production
Based on delivery experience with BFSI compliance RAG implementations in Singapore and Hong Kong, the following three-phase roadmap is the standard path from concept to controlled production deployment.
Phase 1: Scoping and Data Audit (Weeks 1–3)
- Identify 2–3 compliance use cases with highest business impact and clearest data availability (regulatory Q&A and gap analysis are typically the best starting points)
- Audit source documents: inventory, formats, volumes, update frequency, access classification
- Define success metrics: specific answer quality benchmarks, latency targets, compliance officer satisfaction criteria
- Select deployment environment: cloud region (SG/HK), on-premises, or hybrid
- Complete technology risk assessment and obtain preliminary sign-off from model risk and IT security
- Define data governance framework: document taxonomy, access classification, version control process, retention policy
Phase 2: Pilot Build and Testing (Weeks 4–10)
- Implement document ingestion pipeline for priority data sources
- Design and validate chunking strategy against representative compliance documents
- Deploy vector database in approved environment and index initial document set
- Implement hybrid retrieval (dense + sparse) with initial reranking
- Configure LLM with compliance-specific system prompt and output format
- Implement audit logging and basic access control
- Build golden evaluation dataset: 50–100 representative compliance queries with expert-validated answers
- Evaluate retrieval precision and answer quality; iterate on chunking, retrieval parameters, and prompt engineering
Phase 3: Controlled Rollout (Weeks 11–16)
- Deploy to pilot user group: 10–20 compliance officers with structured feedback process
- Complete formal model risk validation documentation
- Security review and penetration testing of API endpoints
- PDPA/data privacy impact assessment
- Compliance sign-off from Chief Compliance Officer
- Broader rollout with ongoing monitoring, evaluation, and improvement cadence
What Does Compliance RAG Really Return? The Business Case
Quantifying the ROI of compliance RAG is more straightforward than most AI investment cases, because the efficiency gains are direct and measurable.
| Value Driver | Typical Impact | Measurement Method |
|---|---|---|
| Regulatory lookup time | 60–70% time savings per query | Time-tracking: before/after workflow comparison |
| New product compliance review | 50–67% cycle time reduction | Average review days: before/after deployment |
| Audit response preparation | 40–60% reduction in evidence assembly time | Examiner response preparation hours |
| Regulatory change impact assessment | 3–5 day process → half-day process | Days from circular publication to completion |
| Compliance officer capacity | 20–30% increase in capacity for higher-value work | Time allocation analysis |
For a compliance team of 15 officers at a mid-size bank in Singapore, where each officer spends an average of 8 hours per week on document retrieval and gap analysis tasks (a conservative estimate), a 65% reduction in that time frees approximately 78 officer-hours per week. At Singapore compliance officer total compensation rates, that represents significant cost savings — while simultaneously improving compliance quality and audit-readiness.
The secondary value driver — risk reduction — is harder to quantify but potentially larger. A single MAS or HKMA supervisory finding stemming from an oversight that a RAG system would have caught can cost far more than the entire RAG implementation.
Common Pitfalls in BFSI RAG and How to Avoid Them
Based on production deployments across BFSI institutions in Singapore and Hong Kong, these failure modes emerge most frequently during the first 90 days of compliance RAG deployment:
- Poor document hygiene in the knowledge base: RAG amplifies both the quality and the defects of your underlying documents. If your internal compliance policies contain outdated references, contradictions, or missing sections, the RAG system will surface these issues. Conduct a document quality review as part of your scoping phase — before building anything.
- Neglecting the audit log layer: Many first implementations focus entirely on retrieval and generation quality, treating logging as an afterthought. In a compliance context, this is backwards. Design your audit logging infrastructure first. You will need it for model risk validation, for regulatory examinations, and for PDPA compliance.
- Over-reliance on AI-generated answers without human review: Compliance RAG systems are decision-support tools, not decision-making systems. Establish clear governance around which output types require human review before action — particularly for audit responses, regulatory submissions, and product approval decisions.
- Underestimating chunking strategy complexity: Generic text splitting performs poorly on regulatory documents with complex hierarchical structures, numbered clauses, cross-references, and tables. Allocate significant time to chunking strategy design and evaluation before indexing your full document set.
- Skipping the golden evaluation dataset: Without a curated set of representative queries with expert-validated answers, you have no systematic way to measure retrieval quality or detect regression as the system evolves.
- Ignoring the regulatory change management process for the AI system itself: As MAS and HKMA update their guidelines, your RAG system’s knowledge base must be updated. Establish a formal process for monitoring regulatory publications, ingesting new guidance promptly, and deprecating superseded documents.
How Sthambh Helps BFSI Teams Deploy Compliance RAG
If you are evaluating RAG for compliance automation or scoping a pilot, the highest-leverage starting points are:
- Audit your current document landscape: Inventory your compliance document sources, assess quality and accessibility, and identify the 2–3 use cases with the clearest retrieval requirements and highest compliance officer time cost
- Define your data residency constraints upfront: Resolve your deployment environment (cloud region, on-premises, hybrid) before any architecture decisions are made
- Build your golden evaluation dataset early: 50 representative compliance queries with expert-validated answers will guide every architecture and configuration decision you make
- Engage your model risk and compliance governance teams from Day 1: The fastest path to production is one where MAS TRM and HKMA SPM governance requirements are designed in, not retrofitted
Sthambh specialises in production RAG and GenAI implementation for banks and financial institutions across Singapore, Hong Kong, and Europe — with specific experience navigating MAS TRM, HKMA SPM, and data residency requirements from architecture design through regulatory sign-off. Contact us to discuss your compliance RAG requirements.
FAQs
Q. What is RAG and how does it help with BFSI compliance?
A. RAG (Retrieval-Augmented Generation) is an AI architecture that retrieves relevant document chunks from your compliance knowledge base before generating answers, rather than relying on the model’s general training data. For BFSI, this means compliance teams get cited, auditable answers grounded in your actual regulatory documents — reducing manual search time by 60–70% while satisfying MAS and HKMA explainability requirements.
Q. Does deploying RAG for compliance require MAS or HKMA notification?
A. For most compliance knowledge management and research use cases, RAG deployment falls within the institution’s existing AI governance framework and does not require separate regulatory notification. However, if the system is used to support material risk decisions, customer-facing applications, or processes subject to model risk management oversight under MAS TRM or HKMA SPM, it should be included in your model inventory with appropriate governance documentation. We recommend engaging your Chief Compliance Officer and Model Risk team during scoping to determine the appropriate governance treatment.
Q. How long does it take to implement RAG for compliance in a bank?
A. A focused compliance RAG pilot typically takes 8–12 weeks: 1–3 weeks for scoping and data audit, 4–10 weeks for pilot build and testing, and 11–16 weeks for controlled rollout with formal model risk validation. The timeline depends heavily on the state and accessibility of source documents, IT security approval processes, and data residency requirements. Data preparation and access provisioning are almost always the longest lead-time items.
Q. What compliance documents can RAG process?
A. A production BFSI compliance RAG system can ingest and retrieve from MAS circulars and notices, HKMA Supervisory Policy Manuals, internal compliance policies, AML/CFT procedures, product approval documents, audit reports, regulatory correspondence, board and committee minutes, and more — in PDF, Word, and structured formats. Multilingual support covers both English and Chinese documents.
Q. Is data residency an issue for banks using RAG in Singapore and Hong Kong?
A. Yes, and it must be addressed at the architecture level. Both MAS-regulated and HKMA-regulated entities have data residency obligations for sensitive institutional and customer data. Production BFSI RAG deployments typically use Singapore (AWS ap-southeast-1, Azure Southeast Asia) or Hong Kong (AWS ap-east-1, Azure East Asia) cloud regions for all processing layers. Institutions with the strictest requirements deploy fully on-premises using self-hosted embedding models and locally-run LLMs.
Q. Can RAG handle Traditional Chinese regulatory documents?
A. Yes. Multilingual embedding models — particularly Cohere Embed v3 Multilingual and BGE-M3 — support strong cross-lingual retrieval for both English and Traditional Chinese. This is particularly important for Hong Kong deployments where HKMA documents, SFC circulars, and many internal policy documents exist in Traditional Chinese. Cross-lingual retrieval allows an English query to retrieve relevant Traditional Chinese source documents and vice versa.
Nikhil Khandelwal
Co-founder & CTO, Sthambh
