RCS is turning the humble text message into a verified, app-like channel — and banks are being pushed back into an inbox they thought they had left behind. The verified-sender pitch is real, but for regulated institutions the encryption story is more complicated than the marketing slide suggests.
For a decade, retail banking strategy pointed in one direction: get the customer into the app. The app was the moat, the data, the cross-sell surface and the brand. Everything else — SMS, email, the call centre — was legacy plumbing kept alive out of obligation.
Then the plumbing got an upgrade. RCS, the messaging standard that replaces plain SMS, has quietly turned the default text inbox on billions of phones into something that looks a lot like an app: branded, interactive, verified. And that changes the question every bank's customer team is now asking. If the text inbox can carry a logo, a verified badge, buttons and rich cards, do you still need to fight to keep customers inside your own app for every interaction?
What RCS actually is
RCS — Rich Communication Services — is a GSMA standard, delivered through the carrier messaging system and shipped to Android through Google's Jibe platform, which handles a large part of carrier traffic. It is the successor to SMS: no download, no separate account, it lives in the same inbox where texts already arrive.
The upgrade over SMS is not cosmetic. RCS supports branded sender profiles, images and carousels, suggested-reply buttons, read receipts and typing indicators. For a business, it turns a 160-character grey bubble into something closer to a mini web page inside the conversation.
The moment that mattered for reach: Apple added RCS support in iOS 18, released on 16 September 2024. Until then RCS was effectively an Android story. With Apple on board, the standard finally spans both ecosystems — which is exactly why banks are looking at it now rather than two years ago.
Why banks care: the verified-sender problem
The single most valuable thing RCS offers a bank has nothing to do with carousels. It is identity.
Plain SMS is trivially spoofable. Anyone can send a message that appears to come from "YourBank," and smishing — SMS phishing — has become one of the most effective attack vectors against retail customers precisely because the channel carries no proof of who is really sending. Every bank in Europe has spent years telling customers not to trust links in texts, which is an awkward position when the bank itself relies on texts.
RCS Business Messaging answers this with verified sender profiles. A verified business gets a registered brand name, logo and a verification badge, with the brand vetted by Google and participating mobile operators. To the customer, the difference between a real message and a scam becomes visible in the inbox rather than something they have to reason about. For fraud-prevention teams, that is the headline.
The catch nobody puts on the slide
The verified-sender story is real. The encryption story is more nuanced than it looks. The GSMA added MLS-based end-to-end encryption to the RCS Universal Profile in 2025, and since May 2026 personal chats between iPhone and Android have begun to be encrypted end to end — still in beta on iOS and dependent on carrier support. But that rollout covers person-to-person chats. Business messages sent via RCS Business Messaging are encrypted in transit only, not end to end, and pass through Google's and aggregators' infrastructure. For a bank, that is the whole risk assessment.
This is the distinction that gets lost in vendor decks. Verified identity and end-to-end encryption are two different guarantees. RCS Business Messaging gives banks the first one strongly and the second one not at all. That is fine for a delivery notification or a fraud alert that says "call us" — and not fine for anything that would expose account detail or serve as a channel of record.
From standard to shipped product
The gap between "RCS supports this" and "our bank sends this safely to millions of customers" is engineering, not standards. A message has to be provisioned through an aggregator, the sender profile has to be verified, the content has to be templated and localised, delivery and fallback to SMS has to be handled when RCS is not available, and the whole flow has to be wired into core systems and consent records without turning into another siloed channel.
That integration work is where the channel lives or dies, and it looks a lot like the plumbing European banks already maintain elsewhere — think EBICS connections and the messy reality of getting regulated financial data to move reliably between systems. Specialist product teams have started to treat RCS as exactly that kind of integration problem; the Cologne-based studio Railslove, for instance, has put both RCS development and EBICS implementation on its roster, which is a fair signal of where the two worlds are converging. The point is less about any single vendor than about the category: RCS is becoming an integration discipline, not a marketing toggle.
The bigger board: who owns the conversation
Step back and RCS is one move in a larger contest over the messaging layer. The Digital Markets Act already obliges Meta to open WhatsApp and Messenger to interoperability requests — RCS itself is not covered, but the pressure toward less fragmented messaging could still help banks that want one channel instead of five.
And RCS does not arrive on an empty field. WhatsApp Business already has deep penetration across much of Europe and uses the Signal protocol — though with Meta's Cloud API, encryption ends at Meta's hosted endpoint rather than at the bank, so neither channel gives the bank true end-to-end control. The strategic read is the same either way: the messaging inbox, not the banking app, may be where the next round of customer contact is won or lost.
What to actually do with it
The honest recommendation is narrow and useful. Use RCS where its strength — verified identity — matches the job: fraud alerts, delivery and appointment confirmations, one-time notifications, and driving customers toward the app for anything sensitive. Do not use it as a substitute for the app's secure channel, and do not let a vendor imply that "encrypted" and "verified" are the same promise.
The deeper lesson is the one banks keep relearning. High-assurance interactions — the ones that need genuine end-to-end control — still belong in infrastructure the bank actually controls, while business messages remain outside end-to-end encryption. The text inbox is back in play as the place to be seen and trusted at first contact. It is not the place to move the crown jewels.
Transparency note: Railslove, mentioned above as an example, is led by a member of the FinTech Weekly team.