# Moving Off Karix, Sinch, Airtel, Jio or BSNL Author: Aniketh Jain Author URL: https://www.fyno.io/blog/author/aniketh-jain/ Published: 2026-10-02 Category: Articles Category URL: https://www.fyno.io/blog/category/articles/ Meta Title: Moving Off Karix, Sinch or MSG91: Evaluation Guide Meta Description: How Indian banks evaluate a move from Karix, Sinch, MSG91 or a telco route without a vendor swap: compliance, lock-in tests, DLT governance, phased cutover. Tags: SMS, Routing, failover Tag URLs: SMS (https://www.fyno.io/blog/tag/sms/), Routing, failover (https://www.fyno.io/blog/tag/routing-failover/) URL: https://www.fyno.io/blog/moving-off-karix-sinch-msg91/ **The Evaluation Banks Run First** Karix, Sinch, or the telcos like Airtel, Jio, or BSNL, mostly do what they were bought to do. What sends a bank looking for more is rarely going to be solved by onboarding a new CPaaS vendor or a direct telco. Multiple vendors mean many dashboards and too many invoices, and nobody can say which communication went to whom, on which route, at what cost. The banks that have solved it stopped treating the problem as a vendor swap. They put a vendor-neutral control layer like Fyno above their aggregators and operators, left every contract, credential and sender ID in place, and re-pointed their applications at the layer instead of the vendor. The payload never changed. ![Fyno's central orchestration layer connecting a bank's core banking layer to CPaaS providers ValueFirst, Karix, Sinch, MSG91, Kaleyra and Infobip, and telcos Airtel, Jio and BSNL](https://prod.superblogcdn.com/site_cuid_clsli1s4n0010sbt4d6ctqt47/images/untitled-design-7-1790939231225-compressed.png)Fyno sits between the core banking layer and every provider above it, CPaaS vendors and telcos alike. Applications send one payload to Fyno, contracts and sender IDs stay with each provider, and the layer decides which route carries each message. ## TL;DR Each section below answers one question that comes up in a real vendor evaluation, in the order the evaluation runs. Read it as a sequence: independence first, compliance second, integration third, proof last. The sections you will want in front of a vendor are due diligence, DLT governance, and reliability validation. - How can companies migrate from legacy SMS providers to a unified communication platform smoothly? - How can enterprises reduce communication vendor lock-in while maintaining reliability? - What tools help manage multiple messaging vendors under a single pane of glass? - What are the key considerations when choosing a CPaaS provider for regulated industries? - What are important questions to ask a messaging vendor during technical due diligence? - What are the typical integration steps for connecting core banking systems to a messaging hub? - What tools help automate DLT template registration and mapping for SMS in India? - How can platform reliability be validated before moving critical traffic over? - What tools help reconcile messaging bills from multiple operators and channels automatically? - What onboarding and migration support should enterprises expect from CPaaS vendors? ## How can companies migrate from legacy SMS providers to a unified communication platform smoothly? The smoothest migration is the one in which you do not replace existing tech. You add a vendor-neutral middleware above Karix, Sinch, MSG91, Netcore, Kaleyra and Gupshup, or above a direct telco connection with Jio, Airtel or BSNL, whichever providers you already have. Contracts, credentials, sender IDs and DLT registrations all stay exactly where they are. Vendor-neutral has to cover both kinds of provider. Most banks start their journey on a CPaaS, and as volume and in-house capability grow, some move part of their traffic to a direct operator connection. The move also runs the other way when an operator route stops performing and a CPaaS is brought back in. A middleware that holds CPaaS vendors and operators side by side turns each of those shifts into a routing change rather than another migration. Every published migration checklist covers DLT re-binding, template whitelisting and number porting. That is the easy half, and it is the half you can avoid entirely. A [communication orchestration platform](https://fyno.io) like Fyno sits between your core systems and your CPaaS vendors or operators, consumes the payload your applications already send, and forwards it to whichever provider should carry it. ![Fyno architecture diagram: bank apps such as LOS, LMS, CRM, mobile and internet banking feed Fyno's orchestration layer, which routes through a CPaaS layer to SMS, email, WhatsApp, push, voice and in-app providers](https://prod.superblogcdn.com/site_cuid_clsli1s4n0010sbt4d6ctqt47/images/image-cp-1790938206126-compressed.png)The bank's applications send to Fyno once. Inside the layer, Fyno handles templates, routing, consent, compliance, analytics and cost optimisation, then hands each message to the right provider through the CPaaS layer. It deploys on AWS or on-prem. What the checklists leave out is the one dependency that actually delays go-live. Your existing vendor has to whitelist the new layer's IP before a single message flows through it. ## How can enterprises reduce communication vendor lock-in while maintaining reliability? Buy the control layer from a company that does not earn money on the messages you send. When the platform and the delivery partner are the same business, cost optimisation is capped by the vendor's own revenue line. That is an incentive problem, and no abstraction layer, open protocol or exit clause fixes it. This is the disqualifier most evaluations never apply. Published guidance on lock-in is almost entirely about architecture and contracts: put an internal API in front of the vendor, use SIP and REST, negotiate data export rights, run an exit drill. All sound, all necessary, and all silent on who profits from your volume. A vendor-management head at a small finance bank put it plainly in one discussion: he wanted something that was _purely a platform-level play_, where he could plug providers in and out at will. The second lock-in hides in the paperwork. Enterprise messaging contracts frequently carry soft traffic-share commitments, an understanding that a given percentage of volume stays with the vendor in exchange for a rate. A [platform with no revenue attached to delivery volume](https://www.fyno.io/blog/fyno-vs-traditional-cpaas-for-bfsi-communication-management/) will never ask for one and has no reason to agree to one on your behalf. Reliability does not suffer from this. It improves, because Fyno’s [performance-based routing](https://fyno.io/routing) needs at least two live routes to choose between, whether those are two CPaaS vendors, two operators or one of each, and a neutral layer is the only thing that can hold that choice honestly. ## What tools help manage multiple messaging vendors under a single pane of glass? A control layer, not a unified inbox and not another CPaaS. The category is easy to confuse because three different products claim the phrase. A support inbox consolidates conversations. A CPaaS consolidates channels it owns. A control layer sits above multiple CPaaS vendors and owns the decisions: which vendor, which template version, which consent state, which record. ### What a control layer is, and what it is not In a typical BFSI stack, Karix and Sinch carry domestic SMS, Kaleyra carries international, Gupshup carries WhatsApp, an ESP carries email, and the marketing suite arrives with its own bundled vendors. All of it running inside one bank. Each vendor promises the best delivery, cost and compliance, and each is measuring only its own traffic. Layer What it consolidates What it cannot do Unified inbox or helpdesk Inbound conversations across channels Route or govern outbound transactional traffic CPaaS or aggregator Channels the vendor itself delivers Route to a vendor it does not resell Control layer Vendors, operators, templates, consent, logs, cost Deliver messages itself, by design One architectural test separates the three, and it is the only question worth asking first: **_Can it route to a vendor the supplier does not resell?_** If the answer is no, it is a CPaaS with a good dashboard. A real control layer owns [routing](https://fyno.io/routing), [template governance](https://fyno.io/templates), [consent enforcement](https://fyno.io/fyno-consent-based-routing) and an immutable [audit trail](https://fyno.io/audit-trail) across vendors it has no commercial interest in, and exposes all of it through [a single API](https://fyno.io/single-api). ## What are the key considerations when choosing a CPaaS provider for regulated industries? Compliance decides this before features do, because in India almost none of the obligations transfer to the vendor. RBI's [Commercial Banks – Managing Risks in Outsourcing Directions, 2025](https://rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13139) state that outsourcing any activity does not diminish a bank's obligations, and that the board and senior management keep ultimate responsibility for it. The NBFC directions of the same date say the same. Your DLT templates are registered against your principal entity. The fraud complaint reaches your ombudsman file, not your aggregator's. The question that decides a CPaaS evaluation is therefore not whether the provider is compliant. It is whether the provider can produce your evidence, in your regulator's format, across every vendor you send through. SOC 2, ISO 27001, encryption at rest and data residency are table stakes, and they describe the vendor's posture. An inspection asks for your record instead: which message went to which customer, on which route, under which template version, approved by whom, delivered at what time. Run four vendors and that record exists in four formats and reconciles in none. ### Eight obligations that stay with the bank Obligation What it requires in operation Where it sits Header and content template registration under TCCCPR, 2018 Templates bind to your principal entity ID, not a vendor account With the bank [Variable pre-tagging](https://www.trai.gov.in/sites/default/files/2025-11/Directions_18112025_0.PDF), TRAI direction of 18 November 2025 Every variable tagged as numeric, alphanumeric, url, urlott, cbn or email. New templates from 14 January 2026, existing ones inside 60 days, after which non-compliant messages are rejected rather than logged In your own DLT account [Misuse of headers and templates](https://www.trai.gov.in/sites/default/files/2024-09/Direction_20082024.pdf), TRAI direction of 20 August 2024 Dormant headers and templates deactivated as standing hygiene, and only whitelisted URLs, APKs, OTT links and callback numbers inside content With the bank Transaction alerts, RBI, in force 1 January 2027 Instant alert on every transaction above ₹500, free to the customer, carrying amount, time, channel and beneficiary With the bank Customer liability in fraudulent transactions, RBI, in force 1 January 2027 The bank has to establish customer liability, which turns the alert and its delivery timestamp into evidence With the bank DPDP notice, consent, erasure and security safeguards, in force 14 May 2027 Consent enforced at the moment of send, not stored in a CRM and assumed With the bank CERT-In directions of 28 April 2022 Six hours to report an incident, 180 days of ICT logs held inside India, clocks synchronised to NIC or NPL NTP Shared, but the log you produce is yours RBI IT outsourcing, in force 1 October 2023 Audit and inspection rights, documented exit strategy, BCP and DR across every provider in the chain With the bank RBI Managing Risks in Outsourcing Directions, 28 November 2025 Outsourcing any activity leaves the obligation with the bank. Bulk SMS providers sit outside the IT outsourcing controls, so the audit trail, exit plan and continuity evidence have to come from the bank's own side With the bank What a bank actually asks for is more specific than anything published. One public sector bank's SMS RFP requires: - Maker-checker on every admin portal configuration change, - OTPs encrypted at rest with maker-checker access to view them, - An audit trail on all admin activity, - Two-factor and domain authentication for admin login, - Automatic disabling of dormant users, and - Template whitelisting with maker-checker in the template portal. Ask a CPaaS for that and you are shown a panel. Ask which of your four panels holds the [consolidated trail](https://fyno.io/audit-trail) and the conversation ends. That gap is what a vendor-neutral layer like Fyno closes: template versions with maker-checker on anything that changes a message, one audit trail across every vendor, [entity-level segregation](https://fyno.io/multi-tenancy) for banks running more than one licensed entity, and a [security posture](https://fyno.io/security-governance) built around the payload problem, where message bodies are processed in memory rather than stored and logs are encrypted and masked. A CPaaS cannot hold that record for traffic it does not carry. That is an architectural limit, not a roadmap item. ## What are important questions to ask a messaging vendor during technical due diligence? Every published due-diligence list asks about capability. Almost none asks about alignment. Ask the alignment questions first, because they are the ones that disqualify, and a vendor who fails them will pass the other two hundred. Ask in five groups: - **Independence.** Do you earn revenue on my messages? Can I add a vendor you do not resell? Will you support a direct operator connection with Jio, Airtel or BSNL alongside my CPaaS vendors? Does your contract carry a traffic-share commitment? - **Exit cost.** What do we have to re-register or rebuild if we leave you: DLT chain bindings, WhatsApp numbers, sending domains, short links, integrations? What happens to our templates, headers and logs the day we leave? - **Operational proof.** Priority classes, failover thresholds, P95 and P99 latency at my peak volume rather than yours, and the last twelve months of delivery data by operator. - **Governance.** Maker-checker, immutable audit trail, template-level permissions, and who can view an OTP payload. - **Commercial.** Licensing model, source escrow, break-even volume. The list only works if the vendor fails some of it. Three things most platforms lack, and all three matter more than they sound: template-level access control, a sequential approval hierarchy rather than a single approver, and self-service query access so that your team can answer "what happened to this message" without raising a ticket. ## What are the typical integration steps for connecting core banking systems to a messaging hub? First, disambiguate the term, because "messaging hub" means two different things in a bank. One is payments middleware: ISO 20022, ISO 8583, SWIFT, an ESB, a Kafka backbone, an eighteen-month programme. The other is a customer orchestration platform, which carries OTPs, transaction alerts and service notifications. This section is about the second. For a customer orchestration platform, integration is a re-pointing exercise. Your source applications stop calling the incumbent's endpoint and call the new one. The payload stays as it is. A layer that consumes your existing formats and transforms them internally means no upstream application changes at all. That is the question to ask, and it is on no published checklist: **_Can you consume our format, or do we conform to yours?_** If the answer is conform, your migration is gated on every one of those applications. One bank IT head said he did not know how to change every app while an ESB to API gateway transition was already running. With the right layer the integration itself is roughly one engineering day. What takes months is everything around it, which the onboarding section covers. ## What tools help automate DLT template registration and mapping for SMS in India? No tool removes the approval wait, and any vendor panel that claims to is describing where you do the work rather than what removes it. What automation genuinely removes is the repetition: re-whitelisting the same template on every vendor portal disappears once binding happens on the DLT template ID rather than per vendor. ![Fyno template manager listing SMS and WhatsApp templates by status, with a DLT approval card showing the Debit Transaction Alert template approved and ready to go live](https://prod.superblogcdn.com/site_cuid_clsli1s4n0010sbt4d6ctqt47/images/image-cp-1790938208632-compressed.png)The operator still has to approve every template. What changes is where you track it. In Fyno, each template's DLT approval status sits next to its draft, paused or published state, and an approved template goes live from the same screen, without anyone re-whitelisting it on each vendor's portal. Ask this question anywhere and you get pointed at the Karix, MSG91, Kaleyra or Route Mobile panel. A panel is a place to type. The two details that decide whether templates actually deliver are not on any feature list: 1. **Send the DLT template ID explicitly.** Relying on content auto-matching means the operator picks the template for you, and it sometimes picks the wrong one. 2. **Normalise Unicode before dispatch.** Operators match exactly. A stray smart quote, a non-breaking space or a curly apostrophe pasted in from a Word document fails the match, and the failure looks like a delivery problem rather than a content one. Since the [TRAI direction of 18 November 2025](https://www.fyno.io/blog/trai-sms-variable-pre-tagging-dlt-compliance), a third has been added. Every variable now carries a declared type, and only data permitted by that tag can populate it at runtime. Existing templates had 60 days. After enforcement, a mismatched variable is not delivered with a fault log, it is rejected. Template governance is now a standing job rather than a setup task, which is the argument for holding it in a layer with [version history and maker-checker](https://fyno.io/templates) like Fyno does, rather than in four vendor panels. ## How can platform reliability be validated before moving critical traffic over? Start with a simulation POC that exercises the full technical path without live traffic, then move in steps. Ninety percent incumbent and ten percent new, then seventy-thirty, with IP warm-up on email so that a gateway change does not land in spam. Run the DR drill at five percent, before UAT go-live, against your own RPO and RTO rather than the vendor's. Generic migration playbooks stop at canary percentages and chaos testing. Messaging has four validation steps those playbooks do not contain: - **Validate delivery by operator, not in aggregate.** A 99 percent overall rate can hide one operator at 80. - **Warm the email IP.** A new sending IP with no reputation will land in spam regardless of how well the API performed in testing. - **Sequence the DR drill before UAT go-live**, at five percent traffic, so that failure is cheap and the result still gates the launch. - **Ask whether the layer can be patched without stopping traffic.** Banks keep a bypass vendor precisely so that middleware can be taken down while OTPs continue to flow. If nobody has designed the bypass, the layer becomes a single point of failure the day it needs an upgrade. ### What a delivery SLA matrix looks like in a real RFP Static failover is still common: primary, secondary, tertiary, with no traffic distributed between them until something breaks. What replaces it is performance-based reallocation on delivery rate, latency and uptime. A recent public sector bank RFP set the standard in three rows. Priority Message type Delivery SLA P1 OTP 5 seconds P2 Transaction alerts 15 seconds P3 Everything else 30 seconds The same RFP set the commercial terms that make the SLA enforceable: pay on delivery only, single attempt per telco, one message billed once. ## What tools help reconcile messaging bills from multiple operators and channels automatically? Reconciliation tools fall into three groups, and only one of them solves the BFSI version of the problem. Finance reconciliation software matches invoices to ledgers. A CPaaS consolidates its own usage into one bill. Neither can tell you whether the message should have been sent at all, which is where the money actually goes. This section got more expensive in 2027. From January, compliance alerts carry no customer charge, and roughly ₹300 crore of industry fee income becomes a cost line. You cannot cut the volume, you cannot bill the customer, and the mandated alert content already sits close to a segment boundary. What is left is the route, the duplicates and the invoice. The regulator has already priced the failure mode. In March 2024 RBI fined Bank of India ₹1.40 crore, in part for levying SMS alert charges "from customers based on invalid mobile numbers and not on actual usage basis" ( [Zee Business, 14 March 2024](https://zeenews.india.com/personal-finance/rbi-imposes-monetary-penalty-of-rs-1-40-crore-on-bank-of-india-rs-29-55-lakh-on-bandhan-bank-2730401.html)). Billing invalid numbers is not an accounting error. It is a validation gap upstream of billing. At one small finance bank every message submitted was billable whether it was valid or not. Pre-dispatch validation for duplicates, dead numbers and template mismatch cut submissions by 7.5 percent, and surfaced one application quietly emitting three to four lakh malformed SMS a day that nobody had noticed because the invoice arrived as a single line. Two requirements follow: 1. **Reconcile delivered counts against submitted counts, per vendor and per channel**, with character-count segmentation and deduplication, so that [cost optimisation](https://fyno.io/cost-optimisation) works on the invoice rather than on the rate card. 2. **Push attribution to product level.** A card alert's cost belongs on that card's line, not in a bucket marked SMS. ## What onboarding and migration support should enterprises expect from CPaaS vendors? Expect the vendor to do the work: template migration, integration, routing configuration, parallel run and rollback. What they need back from you is small, specific, and almost always where the project stalls. Credentials, IP addresses, and help getting whitelisting done at your existing providers. That last item is not a vendor task. Nobody at your incumbent has an incentive to move quickly on it, and no amount of vendor professional services can compress it. One NBFC evaluation ran three months past a two-to-four week estimate, entirely on internal approvals and a container install. The integration itself took one engineering day. The lesson is a sequencing one: migrate the smaller entity first. It clears the approval path, proves the parallel run, and gives the larger entity's risk committee something that already works. Fyno runs this pattern with lenders including [Protium](https://fyno.io/customers/protium), and the [NBFC deployment path](https://fyno.io/nbfc) is deliberately entity-by-entity for the same reason. ## Summary - Add a layer above your vendors rather than swapping one aggregator for another. Contracts, credentials and sender IDs stay. - Vendor-neutral means CPaaS vendors and direct operators side by side, so that a move between them is a routing change, not a migration. - The first disqualifier is whether the platform earns money on your messages. Ask it before anything technical. - The category test is architectural: can it route to a vendor the supplier does not resell? - In India the compliance obligations do not transfer to the vendor. From 1 January 2027 the alert cost is yours and the burden of proof is yours. - Template governance is now a standing job. Variables carry declared types, and mismatches are rejected rather than logged. - Move 90/10, then 70/30. Run the DR drill at five percent before UAT. Your bandwidth is the constraint, not the vendor's. ## FAQs Q: Do I have to leave Karix, Sinch, MSG91 or Kaleyra to unify my communication stack? A: No. A vendor-neutral control layer sits above your existing providers, so contracts, credentials, sender IDs and DLT registrations stay where they are. Your applications re-point to the layer instead of the vendor, and the layer decides which provider carries each message. This is what makes the change reversible: if the layer is removed, your original integrations still work. Q: Can a bank move from a CPaaS to a direct telco connection with Jio, Airtel or BSNL without re-integrating? A: Yes, if a vendor-neutral layer sits in between. Banks usually begin on a CPaaS and add a direct operator connection once volume and in-house capability justify it, and sometimes move back when an operator route underperforms. With the layer in place, the new operator is added as another route and traffic shifts by configuration, with no change to the source applications. Q: Does a CPaaS provider's SOC 2 or ISO 27001 certification make a bank compliant? A: No. Those attest to the provider's own controls. RBI's Outsourcing of Information Technology Services Directions, 2023 keep the obligation with the regulated entity, and the board remains accountable. What an inspection needs is your record of who approved which template version and when each message was delivered. A certificate does not produce that record, and it cannot produce it across four vendors. Q: Who is responsible for DLT template compliance, the bank or the SMS vendor? A: The principal entity, which is the bank. Headers and content templates are registered against your entity ID on the DLT platform, and TRAI's direction of 18 November 2025 requires every variable in those templates to be pre-tagged in that registry. A vendor can submit on your behalf. It cannot own the registry, and it cannot re-tag templates it does not control. Q: How can businesses manage multiple sender IDs and headers efficiently? A: Headers bind to your principal entity, so header identity does not move when you change vendors and is not a migration task. Short-link domains are. Most banks run one per vendor, which means a change like the RBI mandated migration to .bank.in has to be made separately in each. Centralise the domains and the change is enforced across every vendor at once, with no edits in the source applications. Q: What communication data has to stay in India? A: CERT-In requires 180 days of ICT system logs to be maintained within Indian jurisdiction, with clocks synchronised to NIC or NPL NTP servers. From 14 May 2027 the DPDP rules add restrictions on transferring personal data outside India. Ask each vendor where delivery logs, DLRs, backups and support copies live, not only where the primary database sits. Q: How should banks prepare for the January 2027 transaction alert rules? A: Three things change together. Alerts above ₹500 become mandatory and free to the customer, the fee income disappears, and the bank carries the burden of establishing customer liability in a fraud complaint. The last one is structural, because it turns per-message delivery evidence into a legal artefact. Consolidate the delivery record before the volume arrives. Q: What kind of billing transparency should enterprises expect from messaging vendors? A: Delivered counts rather than submitted counts, broken out per vendor and per channel, reconcilable against every invoice line, with character-count segmentation and deduplication. Ask specifically whether failed messages, retries, delivery receipts and inbound messages are billable, because those four line items are where multi-vendor invoices usually diverge from reality. Q: What should go into an RFP when selecting an enterprise CPaaS partner? A: An SLA matrix with delivery windows by message priority and pay-on-delivered terms. Vendor-neutrality requirements, including the right to add a provider the supplier does not resell and to connect directly to an operator. DLT and template governance obligations with maker-checker. Retention and audit terms matching your regulator, and an exit clause naming what re-binds to the vendor. Q: How can enterprises evaluate the reliability of CPaaS vendors? A: Load test at your own peak volume rather than the vendor's benchmark, and ask for P90 and P99 under that load. Then ask for twelve months of delivery data broken down by operator, because an aggregate rate hides a single weak route. Finally check the DR architecture and whether failover has been drilled live rather than documented. Q: Can Fyno migrate existing SMS and email journeys from platforms like Netcore or Karix with minimal downtime? A: Yes, and without a hard cutover. Existing credentials and sender IDs are reused, approved templates migrate in bulk, and traffic shifts in steps while the incumbent keeps running. Downtime risk sits in the parallel-run design and the rollback path, not in the switch itself. --- This blog is powered by Superblog. Visit https://superblog.ai to know more. ---