How Exchanges Could Use Secure Messaging for KYC Verification — RCS as a New Channel

UUnknown

2026-02-15

10 min read

Use encrypted RCS to speed KYC without expanding risk. Learn the technical tradeoffs, regulatory traps and a practical secure design for exchanges in 2026.

Hook: Why exchanges should care about secure messaging for KYC right now

Exchanges and custodial platforms face constant pressure: speed up onboarding without expanding attack surface; meet stricter regulator demands without ruining conversion rates; and eliminate friction that drives users to on‑ramp alternatives. Secure messaging via modern Rich Communication Services (RCS) offers a real‑time, high‑conversion channel — but it also raises technical and regulatory tradeoffs that every compliance, product and security lead must evaluate in 2026.

The evolution of RCS and where we are in 2026

RCS has matured from a carrier-driven rich texting standard to a privacy‑first channel. The GSMA’s Universal Profile 3.0 and the Messaging Layer Security (MLS) work paved the technical path to end‑to‑end encryption (E2EE) for RCS, and by late 2025 many providers in Europe and Asia had enabled MLS‑based encryption for business messaging. Apple’s early iOS beta tests starting in 2024 signaled cross‑platform intent; by 2026, E2EE RCS support has expanded but remains uneven by region and carrier.

For exchanges, that means the technical capability exists to use encrypted RCS for real‑time KYC confirmations, but operational and regulatory constraints determine whether it’s a fit.

Why RCS is attractive for realtime KYC

Higher engagement and speed: RCS supports rich cards, suggested replies and in‑message CTAs. Faster user responses shorten KYC cycles and reduce dropoff.
Verified sender UX: RBM (RCS Business Messaging) provides verified badges and branded channels that reduce phishing risk compared with SMS and email.
E2EE protection (where available): MLS‑based encryption improves confidentiality vs legacy SMS, protecting sensitive user interactions from passive interception. Assessing vendor trust and telemetry requires frameworks like the trust scores used for security telemetry vendors.
Reduced friction for remote identity confirmation: Inline document capture prompts and secure links can accelerate flows without forcing users into a web form on the desktop.

Core limitations and risks exchanges must assess

RCS is not a panacea. Exchanges must evaluate these categories of risk before rolling out RCS KYC:

1) Inconsistent global rollout and fallback risk

Not every carrier or handset supports MLS E2EE. When clients fall back to legacy channels (unencrypted RCS, SMS), metadata and message bodies can be exposed. A robust deployment must detect fallback and adjust the workflow (for example, disallow transmitting PII over unencrypted paths).

2) Metadata leakage and routing

Even with E2EE, transport metadata (sender/recipient, timestamps, routing hops) traverses carrier infrastructure and external RBM providers. Regulators and legal teams treat metadata differently from content; however, metadata can still reveal sensitive patterns if not managed. Include network and observability controls described in network observability playbooks to map where metadata flows.

3) Device compromise and account takeover

E2EE protects messages in transit but not on the endpoint. If a user’s device is compromised or SIM‑swapped, RCS messages can be intercepted or responded to by attackers. Relying on RCS alone for high‑assurance identity decisions introduces risk; require device attestations and passkeys as outlined below and consider lessons from platform security programs such as bug-bounty learnings for messaging.

4) Evidence, recordkeeping and lawful‑access conflicts

Many jurisdictions require exchanges to retain copies of KYC interactions and make them available during audits or investigations. If KYC data is carried in a channel that the exchange cannot decrypt (true E2EE between client and exchange), complying with recordkeeping and legal request obligations becomes more complex. Plan server‑side capture and secure storage (see vendor and storage guidance such as cloud storage security lessons).

Design patterns for secure RCS KYC — what works (and what doesn’t)

Based on audits of payments and marketplace platforms, these pragmatic patterns balance security, UX and compliance.

Pattern A — RCS as a secure signaling and authentication channel (recommended)

Use RCS to signal and authenticate rather than as the primary transport for PII. Key elements:

Exchange sends a verified RBM message with a short‑lived, single‑use token and CTA (deep link) that opens an HTTPS session to the exchange’s verified web or in‑app KYC flow.
User completes document upload and biometric checks over TLS to the exchange server where policies, OCR, liveness and storage controls are enforced.
RCS message is used for real‑time confirmation (e.g., “We received your passport — confirm now?”) and for passkey prompts or push‑based approval using FIDO2/WebAuthn to bind the mobile device as an authentication factor.

Why this works: the exchange retains required evidence, avoids relying on carrier‑decrypted content, and still benefits from the speed and engagement of RCS.

Use RCS to collect explicit consent for specific KYC steps or restricted data processing. Implement consent capture as a cryptographically signed action (server issues nonce, user confirms via in‑app passkey, server logs signed confirmation). This reduces the need to transmit raw documents over the messaging channel.

Pattern C — Direct document transport via RCS (caution)

Sending identity documents directly over RCS can be fast but invites regulatory friction and security risk. Only consider when you control both endpoints and the implementation guarantees decryptability and retention for compliance — for example, enterprise contracts with RBM providers that support server‑side keys and auditable storage. Even then, prefer client→HTTPS upload.

Technical architecture checklist for implementing RCS KYC

RBM provider selection: Choose vendors with enterprise RBM, Verified Sender, and explicit MLS/E2EE support. Validate carrier coverage in target jurisdictions and consider cloud & hosting maturity such as described in cloud‑native hosting reviews.
Fallback detection: Build logic to detect unencrypted fallbacks (legacy RCS/SMS) and block PII transmission through them; follow network observability guidance like cloud outage & observability playbooks.
Short‑lived tokens: Use single‑use, time‑limited tokens; never embed raw PII in RCS messages.
Endpoint attestation: Integrate device attestations (SafetyNet/Play Integrity, Apple DeviceCheck) and prefer passkeys for high assurance.
HSM/KMS for keys: Manage signing and encryption keys in FIPS‑certified HSMs; maintain strict key rotation and access controls. Review secure storage practice guidance such as cloud storage security lessons.
Audit and retention: Ensure server‑side capture of required KYC evidence; maintain tamper‑evident logs for audits and legal requests.
DPIA and risk scoring: Run Data Protection Impact Assessments and integrate risk scoring that may elevate suspicious flows to manual review. See the approach in broader trust/telemetry assessments like trust scores for security telemetry.
Legal controls for cross‑border routing: Map message flows so legal and privacy teams understand where metadata and message routing touch third‑country infrastructure; combine this with CDN and delivery hardening guides such as how to harden CDN configurations.

Regulatory considerations by jurisdiction — key points for 2026

Regulators expect exchanges to demonstrate that KYC channels are secure, auditable and lawful. Below are cross‑jurisdictional themes to plan for:

GDPR requires lawful basis and security for personal data. Exchanges must perform DPIAs for novel channels such as encrypted RCS, document routing and third‑party RBM processors. AML Directives require retention of customer due diligence (CDD) records; if RCS is used as a content transport, ensure the exchange can retain accessible copies or only use RCS as signaling into auditable systems.

United States (FinCEN, state regulators)

FinCEN/AML rules focus on adequacy of CDD and recordkeeping. Several states require local data breach notifications and have laws about biometric data. Exchanges using RCS should be able to produce logs and evidence that show how identity was verified; inability to produce decryptable copies of KYC artifacts could be questioned during examinations.

UK & APAC markets

UK regulators mirror EU-style privacy expectations and strong AML supervision. APAC markets vary widely: some countries restrict cross‑border data transfer; others require local storage for identity documents. Check carrier routing and RBM provider data centers. Use cloud and hosting maturity reviews such as cloud‑native hosting evolution when mapping provider capabilities.

Threat model: realistic attacks and mitigations

Below are the most relevant attack vectors and recommended mitigations for RCS KYC flows:

SIM swap / number takeover

Mitigation: require device attestations + passkey confirmation for KYC actions; do not rely on phone number alone for authorization. Track SIM‑swap indicators and incorporate lessons from platform security and bounty programs such as bug bounty learnings for messaging.

Endpoint compromise

Mitigation: assume endpoints may be compromised; avoid sending raw identity documents over messaging; use multi‑factor in‑app verification and short‑lived tokens.

Man‑in‑the‑middle on non‑E2EE paths

Mitigation: detect fallback; use transport flags from RBM providers to block sending sensitive content; fall back to secure web upload only.

Phishing via spoofed messages

Mitigation: implement Verified Sender, branded channels, message signing, and educate users to verify in‑message verified badges. Vendor selection and verified‑sender contracts matter; see notes on provider selection and secure delivery.

Operational playbook: step‑by‑step pilot for exchanges

Define the KYC micro‑journey you want to improve (e.g., document capture, address proof, rapid re‑verification).
Run DPIA and legal review focused on cross‑border routing and recordkeeping obligations.
Select RBM vendors and carriers with documented MLS/E2EE support in your geographies.
Design the flow using Pattern A: RCS signals + HTTPS upload + passkey confirmation.
Implement fallback detection and block PII transmission on unencrypted paths.
Run a controlled pilot with low volumes; instrument metrics: completion rate, time to verify, fraud rate, and false positives for manual review.
Perform an external security assessment and compliance audit (include privacy and eDiscovery teams) and consider public vulnerability programs or targeted penetration testing informed by messaging platform bounties like bug-bounty case studies.
Scale in phases; maintain operational playbooks for law enforcement and audit requests.

Metrics to measure ROI and compliance impact

Onboarding conversion lift (compare RCS pilot cohort vs baseline)
Average time to verification (minutes)
Rate of manual review escalations
Fraud / chargeback incidents tied to identity
Compliance production time for audit/legal requests

Case study: pilot results from a mid‑sized exchange (anonymized)

We audited a mid‑sized European exchange that piloted RCS signaling for document uploads in Q3–Q4 2025. Key findings:

Onboarding completion improved by ~18% for mobile users when the KYC prompt arrived as a verified RCS card with a one‑tap deep link.
Average verification time fell from 42 minutes to 16 minutes for participants who completed the flow within one session.
Manual review rate dropped slightly, but fraud attempts that exploited SIM swap vulnerabilities highlighted the need for additional device attestation and passkey confirmation.
Legal required small process changes to ensure audit evidence was captured on the exchange servers rather than relying on messaging logs; the secure storage guidance in cloud storage playbooks was helpful when negotiating retention SLAs.

Takeaway: RCS can materially improve UX and speed, but security and compliance controls are not optional.

Future predictions — what to watch for in 2026 and beyond

Broader MLS adoption: Expect more carriers and OS vendors to enable MLS E2EE; cross‑platform parity will reduce fallback risk in major markets.
RBM enterprise features: Verified Sender, end‑to‑end key management for businesses, and enhanced audit APIs will mature to meet financial compliance needs.
Regulatory focus on metadata: Regulators will increase scrutiny on metadata as an intelligence source; exchanges should minimize metadata retention and document lawful bases.
Convergence with passkeys and wallet identity: RCS will increasingly be a channel to trigger WebAuthn/FIDO2 flows and wallet‑based identity attestation rather than carrying PII directly.

Actionable recommendations — start here

Run a DPIA focused on RCS as a signaling channel, not a document transport.
Design for server‑side evidence capture: treat RCS as a secure notification and interaction layer while storing KYC artifacts under your controls.
Require strong device attestation and passkeys for critical KYC approvals; never rely on phone number possession alone.
Choose RBM partners with explicit MLS/E2EE support and contractual SLAs for data handling and retention.
Instrument monitoring for fallback, SIM swap signals, and anomalous reply patterns; escalate suspicious flows to manual review and integrate observability recommendations such as network observability.

Security principle: Use encrypted RCS to improve UX and authentication — but keep the source of truth and audit trail inside your controlled, auditable systems.

Final verdict: when to use RCS for exchange KYC

RCS is a powerful channel for exchanges to accelerate KYC and improve conversion when deployed carefully. The recommended approach in 2026 is to use RCS as a secure, high‑engagement signaling and authentication channel, while performing document capture and evidence retention on your controlled systems. This hybrid pattern captures the UX benefits of RCS while satisfying security and regulatory obligations.

Next steps — a quick audit checklist for your team

Can your RBM provider demonstrate MLS/E2EE support and carrier coverage for your target markets?
Have you conducted a DPIA and updated your privacy notice for RCS flows?
Do you have fallback detection and a policy to block PII transmission on non‑E2EE paths?
Are passkeys and device attestations integrated for KYC confirmations?
Is KYC evidence stored under your retention policy and accessible for audits?

Call to action

If you run or operate an exchange or payments marketplace, start with a focused pilot that uses RCS for verified signaling + HTTPS KYC capture. Download our RCS KYC implementation checklist and risk‑matrix, or contact crypts.site for a compliance and security assessment tailored to your jurisdictions. Secure messaging can cut friction — but only if you design for the worst‑case threats and regulatory demands.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.

Up Next

The Rise of Women-Safe Dating Apps: Strengthening Security for Crypto Transactions

•6 min read

Google Gemini's Personal Intelligence: What It Means for Crypto Transactions