← All posts

Automating SMS and WhatsApp client onboarding under France's 2026 sender-ID rules

  • twilio
  • brevo
  • typescript
  • postgresql
  • ovh
  • cursor
  • sms
  • whatsapp
  • compliance
  • b2b2c

When you receive an SMS (a delivery update, a feedback request, a promotional offer), do you actually know which business sent it? Is it legit, or is it a scam?

In France, until this year, the honest answer was often no: reports of sender-number spoofing to Arcep grew 123% between 2024 and 2025 alone. We recently built a messaging platform that sends transactional messages: appointment reminders, verification codes. But without a verified sender, a legitimate message and a scam look exactly the same to a recipient who has been burned before. The most skeptical recipients don't just ignore it: they warn the business directly, assuming someone is impersonating them, or report the message to the relevant authorities.

That confusion is possible because a single text message hides three separate roles:

  • The platform: the software and the business operating it (Y&M Advisors), sending the texts and WhatsApp messages.
  • The business clients: the companies paying to use it. A chain of hair salons, a network of car dealerships, a group of clinics.
  • The end customers: the people who actually get the texts. The business clients' customers, not the platform's.

That shape, a platform selling to businesses who in turn serve their own consumers, is what's called B2B2C: business-to-business-to-consumer. The platform never talks to the end customer directly, only through the business client sitting in between, and that's exactly why the end customer needs to see the business client's name on the message, not the platform's.

Diagram of three roles: the platform sends the message, the business client pays to send it, the end customer receives it

Three roles: the platform sends, the client pays, their customer receives.

A message has to look like it came from the business client, not from the platform or business running it quietly in the background. This year in France, that stopped being a nice-to-have. It became law. A good one, too: it gives recipients an actual way to tell a real business from a scammer, instead of leaving them to guess every time the phone buzzes. That confidence compounds: a recipient who trusts the last five messages, each from a different verified business, is more likely to open the sixth, click the link, or actually reply, instead of defaulting to suspicion or ignoring it outright.

One shared, anonymous number breaks down fast

The model we started from: one phone number, one account, swap the message text per client. To a recipient who doesn't recognize the sender and has never dealt with them before, it carries the exact same warning signs as a scam:

  • One business client gets flagged as spam, and every other client sharing that number pays for it.
  • Billing, delivery history, and support tickets for unrelated clients pile up in one account.
  • The end customer has no way to know which real business is contacting them.

That last point is exactly what regulators are done tolerating, at least not without the paperwork to prove it: a signed Letter of Authorization (LOA) from the business client.

The same problem, one number quietly serving several businesses, can happen on WhatsApp too: nothing stops a platform from running every client through one WhatsApp Business Account, except then every message carries the platform's own branding, or the business behind it, not the client's. An ISV (Independent Software Vendor, a platform like ours building on top of Meta's and Twilio's infrastructure) avoids that by going through Meta's WhatsApp Tech Provider Program instead of an LOA: it grants permission to send on a business client's own behalf, per business, each with its own verified WhatsApp Business Account (WABA), display name, and logo. WhatsApp has its own onboarding problem, covered later.

WhatsApp message from an unidentified sender with no business name, and the recipient replying STOP

No identifiable sender. The only sane response is STOP.

The fix: each business client gets its own sending identity, its own history and billing (linked to their own sub-account), a phone number when the conversation runs both ways, an Alphanumeric Sender ID when it doesn't.

Diagram showing one platform connecting to three isolated business clients, each with their own sending identity, each reaching their own separate end customers

Each business client gets its own isolated sending identity. Nobody shares a number.

That part is just engineering. French regulation is what forced it to be provable.

What actually changed in France

Two things changed in 2026, and only one of them is a law. They push in the same direction.

The AF2M charter, since 1 March 2026

The Charte Business Messaging 2026 from AF2M governs who can send a business text in France, and under what name. It replaces the 2024 edition and covers Push SMS, conversational SMS (A2P/P2A), and RCS for Business.

Worth being precise about what it is: AF2M is not a regulator. It's an industry body of French operators, aggregators, and service providers, and the charter is co-regulation, not statute. It binds contractually down the delivery chain and is enforced by the operators who terminate the traffic. In practice that distinction buys you nothing: fail the charter and your messages don't land.

Three of its rules decide sender identity:

  • No generic sender names. "INFO", "URGENT," and their variants are out.
  • The sender name must be the advertiser's own trade name, or a brand it owns. No third-party brand, no misleading label, and carriers can demand proof.
  • It applies to traffic terminating on French networks, which pulls in senders based outside France.

Note that the charter's timing rules (marketing sends between 8:00 and 21:30) apply to promotional messages only. The identity rules don't make that distinction: a marketing campaign and an appointment reminder are held to the same standard on who the sender claims to be.

One older requirement is now strictly enforced alongside all this: a French local number needs a compliance dossier before it can send a single message. Business registration (the Kbis), a verified address, a named legal representative. Twilio documents this as a know-your-customer check on the phone number itself, and calls the dossier a Regulatory Bundle. Review normally takes up to three business days.

None of this touches WhatsApp. The charter covers SMS and RCS; WhatsApp sender identity is Meta's own regime, covered below. That's why the two halves of this onboarding never share a step.

On this project, Twilio handled WhatsApp and French number compliance, while Brevo carried day-to-day transactional SMS, at least initially. Registering an Alphanumeric Sender ID for France isn't the obstacle: Brevo requires per-country Sender ID registration too, mandatory for accounts opened after March 2026. The obstacle is Brevo's per-sub-account cost, which runs steep before volume arrives, worth revisiting once client count grows.

The law, since 11 August 2026

Separately, article 13 of Loi n° 2025-594 du 30 juin 2025 flipped telephone prospecting from opt-out to strict opt-in, and décret n° 2026-662 du 23 juillet 2026 set out how consent must be collected, stored, and withdrawn. Both took effect on 11 August 2026. Bloctel wasn't superseded, it was abolished: the decree repealed the articles that organized the opposition list outright. A business now has to obtain consent, keep it, and be able to prove it.

That law governs voice calls, not SMS, so it doesn't directly bind the messages this platform sends. It matters as direction of travel: silence used to mean permission, now it means refusal. Anonymous commercial contact is on its way out.

None of this is unreasonable on its own. Apply it to a platform onboarding new business clients every week, and "give them a phone number" turns into a compliance file that can come back rejected.

The manual process: fine once, a mess at scale

Onboarding a business client, by hand, looked like this:

  1. Create a sub-account in the messaging provider's console.
  2. Upload a scan of the business registration document.
  3. Type in the postal address and the legal representative's name.
  4. Wait for a review that comes back approved, rejected, or needing a fix.
  5. Once approved, buy a number and copy identifiers between screens to attach the sender name. (For SMS this step drops entirely for a notification-only sender, which needs its Alphanumeric Sender ID approved and never needs a number.)

Every one of those five steps can cost you an afternoon: a typo, an address format the reviewer rejects, a forgotten field. Every rejection sends you back to step 4.

Tolerable for your first client. Not tolerable once new clients arrive weekly instead of yearly.

WhatsApp makes it worse, not better

Each business client gets exactly one number, so every onboarding creates that client's first and only WhatsApp Business Account. Under the Tech Provider rules above, the client has to complete Embedded Signup themselves, because they have to own the account. A single Twilio account can't hold more than one WABA either, which is another reason the per-client sub-account split isn't a matter of taste.

Meta then verifies that the client owns the number, by SMS or by voice OTP. Which one you get depends on the number's capabilities, and neither branch is clean:

  1. SMS capability: Meta texts the verification code to the number directly.
  2. Voice-only capability: Meta places a call to a number the client has no handset for, because we hold it.

On the voice branch, something has to answer that call, so it routes to Twilio's voicemail Twimlet, which records it, transcribes it, and emails the transcription over. From there the code still has to reach the client fast enough for them to type it into their own Embedded Signup screen before it expires. The signup flow itself discards all progress after 60 minutes of inactivity.

The fix, in five steps

The fix wasn't clever engineering. It was making the legal requirement automatic, instead of a manual step someone has to remember every time.

Five-step vertical diagram: isolate the business client, assemble the compliance dossier from existing data, poll for approval instead of blocking, provision the number and identity together, and handle opt-outs centrally

Five steps, running automatically for every new business client.

  1. Isolate the client immediately. A sub-account exists before any number or message does.
  2. Assemble the dossier with zero data retention. Registration document, address, and legal representative are pulled live from the business's own record and forwarded straight to the compliance provider. The messaging layer never stores a copy, only the resulting approval reference. Twilio's v2 Regulatory Compliance API exists for exactly this, so a platform can run the submission itself instead of sending clients into a console.
  3. Poll for the decision, don't block on it. Review runs to three business days on a good week. Rejections surface the exact reason, so they get fixed and resubmitted without starting over.
  4. For SMS, provision the identity, and a number only when the conversation needs one. A one-way notification doesn't need a phone number, only an approved Alphanumeric Sender ID: up to 11 characters, verified and approved in place of a number. That isn't a workaround, it's the design: an alphanumeric sender can't receive replies at all. A real number only enters the picture once a client needs two-way conversation.
  5. Handle opt-outs centrally, once, instead of rebuilding consent logic for every client.

Zero data retention was a deliberate constraint, not an accident: the messaging layer is a pass-through for compliance data, never a second home for it. Fewer places holding a Kbis document means fewer places that document can leak from.

Where WhatsApp diverges

On WhatsApp, step 4 works differently, for the Meta reasons covered above: every WhatsApp Business Account needs a real number regardless of direction, one-way notification or not.

On both channels, the endpoint is the same: the approved identity is added as a sender on a Messaging Service scoped to that client's sub-account, and every send goes out through that Messaging Service SID with the sender set as the from, so nothing goes live without a verified, approved identity attached to it.

The paperwork that survives

The dossier isn't the only paperwork this replaced, and one piece of it can't be automated away. The sender name still needs that signed LOA, on the client's own letterhead. The pipeline pre-fills that PDF from the same client data already collected for the dossier. The business prints it on letterhead, the authorized representative signs it by hand, and it comes back scanned to Twilio, or to us, when we're the ISV of record.

Get this right, and a customer sees a safe SMS and a clear WhatsApp message like this: a real business name, a verified link, one tap.

WhatsApp message from a verified business sender with its logo, a clear call-to-action button, and the recipient tapping it

Identified sender, verified link, one tap. This is the target state.

The lesson

None of this needed exotic engineering. It needed noticing early that this kind of compliance cost scales with the number of business clients rather than staying fixed, then building onboarding so that compliance is a pipeline instead of a checklist.

Next time a French carrier tightens the rules again, and they will, the fix is one change in one place, not a scramble across every client's paperwork.

Stack notes: Twilio and Brevo for messaging, a TypeScript and PostgreSQL backend, OVH for object storage, built in Cursor.

Further reading and sources