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.
The On-Premises API is gone. Meta’s final client version expired on 23 October 2025, and every brokerage that reaches clients through the WhatsApp Business Platform now runs on Cloud API — infrastructure Meta hosts, not infrastructure you rack. That change moved a question out of the IT column and into the compliance column: where do the messages sit, for how long, and what do you write in your record of processing when the DPO asks?
The usual answer is « the cloud », which satisfies nobody. Meta actually documents the answer, and there is one setting involved that cannot be changed after the fact without deregistering your number. That alone makes it worth twenty minutes before you connect a line, rather than twenty minutes during an audit.
By default, Cloud API stores your message data on Meta infrastructure without any commitment to a particular country. Meta offers an opt-in feature, local storage, that pins message data at rest to a designated region. It is switched on with a single parameter, data_localization_region, supplied when the business phone number is registered against your WhatsApp Business Account.
The supported regions are a short list of two-letter country codes. In Europe there are three: EU (Germany) as DE, Switzerland as CH, and the United Kingdom as GB. Elsewhere Meta lists Australia, Indonesia, India, Japan, Singapore and South Korea in APAC; Brazil; Bahrain, South Africa and the United Arab Emirates; and Canada. For a brokerage in Dublin, Amsterdam, Stockholm or Madrid, the only in-EU option is the German region — there is no per-member-state choice, and asking for one will not produce it.
Two details matter more than the list. First, message content is not pinned during processing: Meta states that data in use may sit on its data centres internationally for up to sixty minutes for Cloud API before it lands in your designated region. Local storage is a rule about data at rest, not a promise that nothing ever leaves the region. Second, once enabled, local storage cannot be disabled or switched to another region directly. Changing your mind means deregistering the number and registering it again — with everything that implies for a line your clients already message.
| Item | Covered by local storage? | Broker consequence |
|---|---|---|
| Text messages, template messages | Yes, at rest in the chosen region | The renewal chase and the client’s reply are in scope |
| Media payloads (images, documents, audio, video) | Yes | Claim photos and signed proposal PDFs are in scope |
| Data while being processed | No — up to 60 minutes, internationally | Your transfer analysis still has work to do |
| Contact book data from shared-contact requests | No — held on Meta data centres regardless | Do not use share-contact flows to move client data around |
| Numbers already registered without the parameter | No, and not retroactively | Deregister and re-register, or accept the default |
| Your own conversation archive | Not Meta’s job at all | See the next section — this is the one that gets you |
Local storage is a useful control, not a compliance conclusion. Three things still need writing down.
Your record of processing should name the platform, the region you chose, and the fact that processing may occur outside it. Vague entries such as « messaging provider » are what turn a routine supervisory question into a long thread. If you use a business solution provider or a platform on top of Cloud API, that party is in the chain too and belongs in the record.
Your transfer position needs a mechanism, because a region for data at rest does not by itself remove an international transfer. Read the business terms you accepted, note which version you relied on and when, and keep a copy — terms are updated and « we accepted whatever was on the site in 2024 » is not a document. Where the assessment is genuinely uncertain, say so internally and escalate rather than writing a confident sentence you cannot support.
Your risk assessment should be proportionate to what you actually do on the channel. A shared line used for renewal reminders is not the same as a line where advisers discuss health disclosures or where an assistant drafts replies automatically; we set out when that tips into a formal assessment in our note on when an AI-assisted broker inbox needs a DPIA.
This is where brokers get caught. Meta operates Cloud API to deliver messages, not to be your archive; message data is retained for as long as the service needs it and no longer. Your regulatory record-keeping obligations are entirely separate and run for years, not days. If a complaint reaches the Financial Ombudsman Service in 2029 and your evidence of what was said in 2026 was « in WhatsApp », you do not have evidence. Pulling the conversation into a system you control, with timestamps and an audit trail, is the actual requirement — the detail is in our guide to archiving WhatsApp under SYSC 9 and ICOBS.
The same logic answers the question brokers ask next: whether the WhatsApp Business app is enough. It is not, for this purpose — a phone backup is not a record, and the choice between the two is set out in our comparison of the WhatsApp Business app and the API.
In ORIS the number is connected through Meta’s Embedded Signup and registered against your WhatsApp Business Account with a six-digit PIN, so the residency question is settled at that moment or not at all — raise it before the connection wizard, not after. What ORIS holds afterwards is the working copy: conversations in a shared inbox, consent and opt-out records, audit logs, and a CSV export when someone needs the file out of the system. That is the copy your compliance officer will actually read.
No, and claiming so in a privacy notice would be a mistake. Meta is explicit that data in use may be processed on its infrastructure internationally for up to sixty minutes before being stored in your designated region. Local storage governs data at rest. Treat it as a meaningful control that reduces exposure, not as a substitute for a transfer mechanism.
Not directly. Meta requires you to deregister the phone number and register it again with the region parameter set. That is an operational event on a live client channel, so plan it: tell the team, pick a quiet window, and expect a short period where the line is not usable. Whether it is worth it depends on how sensitive your traffic is.
No. They answer different questions. Encryption concerns messages in transit between devices and the platform; local storage concerns which country’s data centres hold the message once processing is done. A firm can have one without the other, and a compliance file should address both separately.
It is a marketing sentence, not a record. What you need is the specific chain: who is the controller, who processes on your behalf, which region is set for data at rest, which transfer mechanism applies, and what the retention rule is. Ask for those five answers in writing. A provider that cannot supply them has told you something useful.
The local storage feature belongs to the Cloud API, so no. If your advisers are still using the app on handsets, your data residency question is really a device question — who holds the phone, what is backed up where, and what happens when that person leaves. That is a harder problem, not an easier one.
Shared WhatsApp inbox, client records, follow-ups and opportunities for the whole brokerage. 15-minute demo.
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.
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.
