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.
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 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.
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 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 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.
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, template governance, consent enforcement and an immutable audit trail across vendors it has no commercial interest in, and exposes all of it through a 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 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
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 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 for banks running more than one licensed entity, and a security posture 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.
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:
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.
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, 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 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.
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). 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:
Reconcile delivered counts against submitted counts, per vendor and per channel, with character-count segmentation and deduplication, so that cost optimisation works on the invoice rather than on the rate card.
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, and the NBFC deployment path 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.