Where your clients’ WhatsApp messages are actually stored, and what to tell your DPO
Cloud API stores message data where you tell it to, but only if you set the region before registering the number. What EU and UK brokers should check.
Two grey ticks are not proof of receipt. What sent, delivered, read and failed mean on the WhatsApp Business Platform, and what a broker should file instead.
The complaint lands eleven months after the event and says one thing: I never received the renewal notice, and I found out I was uninsured when I tried to claim. The account handler opens the thread, sees two grey ticks against the message, screenshots it, and considers the matter closed. It is not. A screenshot of two ticks answers a question nobody asked, and the questions an adjudicator does ask — what exactly was sent, to which number, when, and on what medium — are usually the ones the brokerage cannot answer from a phone.
Delivery statuses are useful. They are also routinely over-read. Here is what each one means on the WhatsApp Business Platform, what it cannot tell you, and what belongs in the file instead.
The first thing to unlearn is the API response. Meta's send-messages documentation is explicit that a successful response "only indicates that the API successfully accepted your request — it does not indicate successful delivery of your message". Delivery is reported afterwards, by webhook, as a sequence of status updates. Their definitions in Meta's status webhook reference are narrower than the words suggest:
| Status | Meta's definition | What it does not tell you |
|---|---|---|
| sent | The message was successfully sent from Meta's servers | Nothing about the client's phone. A message can sit at "sent" for days. |
| delivered | The message was successfully delivered to the user's device | Who holds the device, whether the number still belongs to your client, whether anyone opened it. |
| read | The message was displayed in an open chat thread on the user's device | Whether a human read it, understood it, or was even the policyholder. |
| failed | Failure to send or deliver the message to the user's device | Why, unless you keep the error code that came with it. |
Two mechanics matter for the timeline you will one day have to explain. Undelivered messages are retried for a time-to-live period — 30 days for everything except authentication templates — so a "delivered" webhook can arrive long after the send, which is no use at all if the deadline was the renewal date. And a status is only considered read once it has been delivered, so where a client is already sitting in the chat when the message lands, you may see the read status without a separate delivered event. Statuses can also arrive out of the order you expect; what a broker should record is each transition with its own timestamp, not a single current state.
WhatsApp users can switch read receipts off in their privacy settings, in which case no read receipt is generated for one-to-one chats — including chats with a business. The setting has known exceptions: read receipts are always sent in group chats, and turning them off does not stop play receipts for voice messages. A brokerage that treats "no blue ticks" as evidence the client ignored the message is reading a privacy preference as behaviour.
The reverse inference is just as weak. A read status means the message was displayed in an open thread on a device — a screen unlocking in a pocket, a spouse checking the phone, a WhatsApp Web session left open on a shared laptop. For a firm that has to think about the Consumer Duty's consumer understanding outcome, "displayed" is a long way from "understood". The only reliable signal of engagement is a reply that answers the question you asked, which is why renewal messages that end in a question or a quick-reply button generate better evidence than the ones that end in a full stop.
None of this is what the Handbook is measuring. ICOBS 4.1A requires information to be communicated in a clear and accurate manner and provided on paper, on another durable medium, or via a website, with a paper copy available on request and free of charge; the choice of a non-paper medium has to be an active and informed one, and firms are told not to treat a pre-ticked box as consent. The durable medium test is about storage and unchanged reproduction — which a message a sender can delete for everyone does not obviously satisfy, but an attached PDF that the client can save does. The nuances are set out in our definition of durable medium.
The practical consequence for renewals is a two-part pattern. Send the regulated document — the renewal notice with the disclosures required by ICOBS 6.5, the statement of demands and needs, the policy summary — as a file on a medium the client can keep, and use the chat as the nudge that gets it read. Structuring that message is the subject of our renewal notice template. What you must never do is rely on chat alone for something the rules require in a durable medium, then argue about ticks.
An adjudicator or a compliance reviewer is looking for a reconstruction, not a screenshot. Keep, per message:
Retention is a separate question from capture, and the periods, personal-device problem and export format are covered in our guide to archiving WhatsApp under ICOBS and SYSC.
This is the unglamorous half of what a platform such as ORIS does. Each outbound message is queued with proof of send stored before it is confirmed, statuses are recorded as they arrive and only ever move forward — Meta does not guarantee the order of its notifications, so a late "sent" webhook must never overwrite a "delivered" already on file — and every message sits against the customer record in a shared inbox that a CSV export can hand to a compliance reviewer. Consent is rechecked at the moment of sending, not only when the audience was built, and opt-outs stop messages already in the queue. If you want to see what that record looks like when a complaint arrives, take the walkthrough.
A message stuck at "sent" is a signal with a short shelf life. The usual causes are mundane: the number is no longer on WhatsApp, the client changed handset, the phone has been off, or the number was mistyped at onboarding. The workable rule is a deadline of your own, not Meta's — if a renewal message has no delivered status a set number of days before cover expires, it stops being a messaging problem and becomes a contact problem, resolved by phone, email or post, and recorded as such. Firms that write that threshold into their renewal timetable stop discovering silent failures at the point of claim.
It proves the message reached a device registered to that number at that time. It does not prove the person who holds the device is your client, that the file attached opened, or that anyone read it. It is good evidence of dispatch and weak evidence of receipt, which is why it belongs alongside a durable-medium copy rather than instead of one.
Because they have turned read receipts off in WhatsApp's privacy settings, which suppresses them in one-to-one chats. It is a user preference, applied to everyone they message, and it says nothing about your firm or your message. Group chats are the exception — read receipts are always sent there.
Messages other than authentication templates have a 30-day time to live, so delivery can be attempted long after you sent it. For anything with a deadline that is far too long to be useful: treat a message with no delivery status within your own service window as undelivered and switch channel.
Rarely. A screenshot shows a rendering at one moment on one device, without message identifiers, template versions or status timestamps, and it can be produced from a phone that has since left the business. An export from the system of record, tied to the customer file, answers questions a screenshot cannot.
Yes, and it is the strongest evidence available to you. A message ending in a question or a quick-reply button produces an inbound message from the client, stored against their record, which shows engagement rather than delivery. It also has the side effect of opening a conversation window, which makes the follow-up cheaper and more human than another template.
Shared WhatsApp inbox, client records, follow-ups and opportunities for the whole brokerage. 15-minute demo.
Cloud API stores message data where you tell it to, but only if you set the region before registering the number. What EU and UK brokers should check.
Why clients see a number instead of your firm, how Meta reviews display names, and which of your legal, trading or network names belongs at the top of the thread.
Migrate the number clients already message, or run it alongside the app. What each route costs you in chat history, and the checklist to do it in one evening.