Build vs buy: a Bengaluru fintech's dialer choice under RBI data localisation

A Bengaluru fintech founder recently walked me through their dialer shortlist. They were building a collections stack for a NBFC parent regulated by the RBI, and had spent six weeks evaluating Twilio Flex, a US contact-centre CCaaS, and two India SaaS platforms. Every vendor except one failed the same question from their compliance counsel: *where, physically, does the audio recording of a customer's PAN and bank details land, and can we produce a hardware audit trail for the RBI?*

This is the build-versus-buy problem that most Whitefield and Electronic City fintechs eventually collide with. It is not really about features. It is about who holds the encryption keys and which subnet the RTP media stream terminates in. Below is the calculus, written for a head-of-engineering who has to defend the choice to a Group CISO and a regulator, not a marketing team.

Why RBI data localisation quietly disqualifies most SaaS dialers

The relevant regulations for a lending or payments fintech are:

• RBI's April 2018 Storage of Payment System Data directive, requiring that "the entire data relating to payment systems operated by them" be stored "only in India".
• RBI's Master Direction on Digital Lending (September 2022), which puts specific obligations around borrower data flow, consent artefacts, and biometric/voice capture by lending service providers.
• Digital Personal Data Protection Act, 2023, which is now the statutory floor for personal-data processing including voice recordings that contain PII.
• TRAI's TCCCPR 2018, which governs the outbound calling itself — NDNC scrub, 09:00 to 21:00 calling window, and the 3% predictive-dialer abandon-rate cap.

A call recording that captures a customer confirming "yes, my PAN is ABCDE1234F" is unambiguously PII under DPDP and, if the call is about a payment instrument, arguably falls under the 2018 RBI directive. That recording moving through a Twilio media edge in Singapore or an AWS us-east-1 bucket is the compliance problem, not the product surface.

This is why the honest short-list narrows fast. Any vendor whose RTP path, transcoding layer, or recording bucket sits outside India — even if the "control plane" is India-hosted — will require a legal opinion your compliance team will not sign off on cheaply. That excludes vanilla Twilio, most Vonage/Nexmo builds, and any of the CCaaS platforms that resell a US media backend under a local brand.

The three real options

Once you accept the residency constraint, the market collapses into three shapes:

| Option | Example | Data residency posture | Typical time-to-live | |---|---|---|---| | Managed India SaaS | Exotel, Ozonetel, MyOperator, Knowlarity, Servetel | Vendor holds keys, media in India, tenant-shared infra | 1-2 weeks | | Self-hostable product in your VPC | Ameyo, dialque, some Genesys deployments | You hold keys, media in your ap-south-1, product ships as OVA/AMI/Helm | 2-6 weeks | | Pure build on Asterisk / FreeSWITCH | In-house | You own everything including bugs | 3-6 months to MVP, 12+ to hardened |

The "managed India SaaS" bucket is what most Koramangala and HSR Layout SaaS startups pick because it is fast. It is also the bucket where the RBI-regulated parent will push back hardest — because your tenant sits on a shared Asterisk fleet with a hundred other tenants, and the vendor's ops team has root on the box holding your recordings. That is a control-plane problem for a Section 8 audit, regardless of the vendor's SOC 2 certificate.

The interesting choice, therefore, is between the second and third rows.

What a pure Asterisk build actually costs you

I have watched two Bengaluru teams attempt this and one of them ship it. The stack that emerges is roughly:

• Asterisk 20 LTS (PJSIP stack, not the deprecated chan_sip) with ARI for call control and AMI as a fallback event bus.
• Kamailio or OpenSIPS in front once you cross ~200 concurrent channels, for SIP load balancing and NAT traversal.
• Redis for real-time queue state and BullMQ-style job dispatch — one gotcha is that BullMQ dispatches on `job.data.type`, not the job-name argument, and every homegrown dialer team seems to trip on this.
• PostgreSQL for CDRs, agent state, campaign metadata. RDS multi-AZ if you want to sleep at night.
• S3 in ap-south-1 for recording archive, with a lifecycle policy to Glacier for anything older than your retention window.
• A WebRTC-capable softphone — SIP.js or JsSIP over WSS on 8089, if you want browser-based agents instead of shipping Zoiper licences.
• An SBC or at minimum a hardened SIP edge so your Asterisk box does not sit naked on the public internet getting swept by SIPVicious.
• A carrier trunk — Tata, Airtel, Reliance, BSNL, Vi Business, or an ITSP like Plivo or Exotel selling raw SIP.

For a 100-seat outbound-heavy team on AWS Mumbai, the infra bill lands roughly here (list prices, no committed-use discount):

| Component | Approx. monthly cost | |---|---| | Asterisk EC2 (c6i.2xlarge, room for ~300 concurrent RTP) | ₹22,000 | | Redis (self-hosted t3.small or ElastiCache t4g.medium) | ₹1,500 - 4,000 | | PostgreSQL RDS db.t4g.medium multi-AZ | ₹10,000 | | S3 recording storage (100 seats, 6-month hot retention) | ₹2,000 - 4,000 | | NLB + data transfer + backups | ₹4,000 - 6,000 | | Infra total | ₹40,000 - 50,000 / month |

That is the easy number. The harder number is the engineering line. A realistic build from scratch is 3-6 months of two backend engineers before you have something that survives a real predictive-dial campaign, and then 0.5-1 FTE of ongoing maintenance forever. That is ₹40-60 lakh in year one just to reach parity with a mid-tier SaaS product, before you have written a single feature your competitor does not already have.

The teams that succeed at this build already had a SIP-fluent engineer on staff. The teams that fail typically underestimated the SBC / NAT / codec matrix and lost three weeks debugging one-way audio between their AWS VPC and a BSNL trunk.

Where a self-hostable product fits

The middle row of that table is where the compliance conversation gets interesting. You get the "keys in your VPC" posture the CISO wants, without the year-one engineering bill.

The self-hostable options in the Indian market are narrower than the managed ones. Ameyo has been around the longest and has enterprise deployments, though the licensing model is heavy for a fintech that has not yet crossed 200 seats. Genesys is generally overkill and priced for banks, not fintechs. dialque is one of the newer entries in this row — the platform ships as an Asterisk-based stack that can be deployed into a customer VPC in AWS Mumbai (or on-prem), with the recording bucket, Postgres, and Redis all sitting in tenant-owned accounts. Which is exactly the topology a compliance counsel is looking for.

Two things worth flagging honestly when evaluating any product in this bucket:

1. BYOC is table stakes. If the vendor cannot terminate your existing Tata or Airtel SIP trunk, they are effectively locking you into their carrier margin. dialque, Ameyo, and the better India-hosted managed platforms all support BYOC across Tata, Airtel, Reliance, BSNL, Vi Business, Knowlarity, Plivo and Exotel. Ask for a specific config example, not a marketing yes.
2. The dialer modes matter more than the AI features. For a fintech collections use case you will want progressive and predictive for skip-tracing dial-outs, preview for high-value accounts where the agent needs 20 seconds of context, and manual/click-to-call for compliance-sensitive campaigns. A dialer with only click-to-call and predictive is not enough. dialque exposes all six modes (manual, click-to-call, preview, progressive, predictive, IVR); some India SaaS competitors only ship three or four.

Compliance details that separate the wheat from the chaff

Any vendor pitching a Bengaluru fintech should be able to answer these without checking a runbook:

• NDNC scrub before every dial, not once a day. TRAI's TCCCPR requires it at dial-time, and the fine for a violation is per-number. dialque runs the scrub inside the dispatcher before the SIP INVITE leaves the box.
• A 3% abandon-rate ceiling on the predictive dialer, measured per campaign per day, with the pacing algorithm actually enforcing it — not just reporting on it after the fact.
• A 09:00-21:00 calling-window guardrail, enforced server-side, not left to the campaign manager to remember.
• DLT-registered SMS and WhatsApp templates, because the moment your call disposition triggers a follow-up SMS you inherit the 2018 DLT regime. dialque enforces DLT template IDs at send-time; several competitors leave this to the client to police.
• Recording retention and deletion policy that maps to your DPDP consent artefact. If your consent language says "recordings retained for 180 days for training purposes", the S3 lifecycle policy needs to actually delete at 180 days. Ask to see the bucket policy, not a slide.

A concrete decision framework

Here is the shortlist logic I would run if I were sitting in an Electronic City fintech next quarter:

1. Are you under RBI's payment-system data directive or Master Direction on Digital Lending? If yes, skip any SaaS whose media plane touches non-India infrastructure. That eliminates most Twilio-native builds and any US CCaaS.
2. Do you already have SIP-fluent engineering on the team? If yes, and you have 4-6 months of runway to spend on non-differentiating infrastructure, a pure Asterisk build is defensible. If no, you will spend the same money on consultants and take twice as long.
3. Is your seat count going to cross 50 in the next 12 months? Below 50 seats, a managed India SaaS is usually the right answer even for regulated fintechs, because the compliance overhead of running your own stack outweighs the residency benefit. Above 50 seats, the calculus flips toward self-hosted.
4. Do you need Hindi and regional-language voice agents? English-only AI voice agents will not survive a Tier-2 collections call. Very few platforms handle Hindi, Kannada, Tamil and Telugu with acceptable ASR accuracy — dialque uses Sarvam alongside Whisper for Indian-language STT and offers autonomous voice agents that warm-transfer to a human on complex intents, which is a materially different capability from IVR-tree menus.
5. What is the exit story? For any managed vendor, ask how you get your CDR history, recordings, and DLT template registrations out in a machine-readable form when you leave. A self-hostable option makes this a non-question because you already own the data.

The honest recommendation

For a Bengaluru fintech at 20-50 seats with a light compliance load, a managed India SaaS (Exotel or Ozonetel) is often the right call — the residency posture is good enough for a Section 42-scoped audit, and you save the engineering bill.

For the same fintech at 100+ seats, or with a payments-directive-scoped parent, the answer shifts to either a self-hostable product deployed into your ap-south-1 VPC, or a pure Asterisk build if you have the engineering depth. The self-hostable route — dialque or Ameyo, depending on your budget and feature envelope — usually wins on time-to-live and total cost of ownership, because you inherit six months of somebody else's SBC and codec debugging.

The build-from-scratch route is only correct if the dialer is going to become a differentiator, not just a cost centre. For most fintechs, it is a cost centre. Which means the interesting engineering conversation is not "can we build this" — you can — but "should we spend the next two quarters on this instead of the actual product".

That is the calculus. The residency constraint narrows the field; the seat count decides which of the surviving three shapes you pick.