SMS vendor due diligence for Hong Kong banks and brokerages — non-forwardable routes, # Sender ID, DLR audit trail, data residency

Key takeaways

• Financial institutions evaluate SMS vendors on five kinds of question — route, identity, evidence, data, operations — and price comes after all five.
• Verification codes must travel on a non-forwardable route with direct connections to the local carriers; through a grey route or an overseas aggregator, neither non-forwardable nor the # Sender ID takes effect.
• Delivery receipts (DLR) must be the carrier’s own and exportable per message, or you cannot prove “delivered to the registered handset” to an auditor.
• Encryption, retention period and storage location of message content must map to the Personal Data (Privacy) Ordinance and the HKMA’s outsourcing expectations.
• The vendor must explain its OTP-flooding controls and incident notification, because both turn directly into your cost or your complaints.

A financial audit needs evidence, not promises. We connect directly to the carriers, DLRs are the carrier’s own, every message has a full audit trail, and financial clients can request monthly reports. See business SMS or contact us for our completed copy of the questionnaire.

The operations team at a brokerage picks an SMS vendor, agrees the price and connects the API — and compliance sends the purchase request back. Not because it is “too expensive”, but because of questions nobody can answer: can the verification code be forwarded? When something goes wrong, can we produce per-message delivery records? Where is message content stored, and for how long?

This article sorts those questions into five groups. Each group explains the risk first, then lists the specific things to ask. A copy-ready questionnaire is at the end. If you are comparing API vendors specifically, see also How Hong Kong fintechs and brokerages choose an SMS API.

Group one: route — how does the text reach the customer’s phone?

The risk: many vendors quote cheaply because the message passes through several overseas aggregators before it enters Hong Kong — the so-called grey route. The problem is not only delivery rate. For a financial institution it is worse: the non-forwardable arrangement between local carriers and the # Sender ID both apply only to direct routes. You think you bought non-forwardable; the code is actually travelling as an ordinary international text.

Questions to ask:

1. Do you connect directly to each Hong Kong mobile carrier? List them.
2. Can verification traffic be placed on a non-forwardable route? Is the sender a carrier pre-assigned long number, or does it need a separate application?
3. Can verification and promotional traffic be routed separately, with separate Sender IDs?
4. How are customers notified of route changes, such as carrier maintenance?

How non-forwardable works and where it stops is in What is non-forwardable SMS; why grey routes end up costing more is in Grey routes vs direct carrier connections.

Group two: identity — who does the customer see as the sender?

The risk: since the banking industry joined the SMS Sender Registration Scheme in 2024, customers have been taught that “only # is genuine”. A financial institution’s notifications and promotions still going out from a plain number or an unregistered alphanumeric name are not just less recognisable; customers report them as phishing.

Questions to ask:

5. Can you help apply for a # Sender ID under the OFCA scheme? What is the process and lead time?
6. If we want our own # Sender ID on the non-forwardable route, what are each carrier’s setup fee and lead time?
7. How does an unregistered Sender ID display on local networks?

The application process is in The full # Sender ID application process in Hong Kong.

Group three: evidence — what can you produce when something goes wrong?

The risk: when a customer complains “I never got the code” or “I received a strange text”, the institution has to explain to the customer, to compliance, and possibly to the regulator. A success from the API only means the vendor accepted the request, not that the carrier delivered to a handset.

Questions to ask:

8. Is the delivery receipt (DLR) the carrier’s own, or the vendor’s estimate?
9. Can delivery records be exported per message (time, status code, sender number, route)? For how long are they retained?
10. Are DLR webhooks signed against forgery?
11. Can you provide periodic delivery reports for internal audit?

What each status code means is in SMS DLR status codes explained.

Group four: data — where is message content stored, and for how long?

The risk: message content often contains a customer’s name, a partial account number or a transaction amount — personal data under the Personal Data (Privacy) Ordinance. The HKMA’s outsourcing expectations for regulated institutions also require assessing a service provider’s data protection and access controls.

Questions to ask:

12. Is message content encrypted at rest? Retained for how long? Purged automatically on expiry?
13. In which region is data stored? Can the retention period be shortened on request?
14. Who inside the vendor can read message content? Is there an access log?
15. Does the API accept HTTPS only? Does it support source-IP allowlisting?
16. Do you hold, or are you in the process of obtaining, an information security certification such as ISO 27001?

A vendor that cannot answer retention and access control usually has not thought about it.

Group five: operations — what goes wrong day to day?

The risk: the two most common operational incidents both turn straight into your cost or your complaints. One is OTP flooding (SMS pumping), where bots trigger verification codes in bulk and run up the bill. The other is a carrier or vendor outage that locks your customers out while you do not know why.

Questions to ask:

17. Are there rate limits and anomaly alerts per number and per source IP?
18. What is the incident notification channel and response time? Is there a status page?
19. How are we notified when credits run low? Can automatic reminders be set?
20. Is promotional traffic screened automatically against the Do-Not-Call registers?

OTP flooding controls are in OTP flooding and SMS pumping protection; the compliance requirements for promotional SMS are in the Hong Kong marketing message compliance checklist.

The one-page vendor questionnaire

The twenty questions above in a form you can send as-is:

Group	Questions
Route	Which local carriers are directly connected? Can verification codes use a non-forwardable route? Can verification and promotions be routed separately? How are route changes notified?
Identity	Can you help obtain a # Sender ID? Fee and lead time for our own # Sender ID on the non-forwardable route? How does an unregistered Sender ID display?
Evidence	Are DLRs the carrier’s own? Exportable per message, retained how long? Are webhooks signed? Periodic reports?
Data	Content encrypted, retained how long, stored where? Who can read it, is there an access log? HTTPS only, IP allowlist? Security certification?
Operations	Rate limits and alerts? Incident notification time? Credit reminders? Automatic DNC screening?

A practical approach: send the questionnaire to two or three vendors, require written answers, and attach the replies to the purchase request. Compliance wants answers it can file, not a salesperson’s verbal assurance.

FAQ

Is this list only for banks?
No. Brokerages, insurers, stored-value facilities and money lenders — anyone using SMS for identity verification or transaction confirmation — face the same five groups.

Does price not matter at all?
It matters, after the five groups. A cheap quote on a grey route voids both non-forwardable and the # Sender ID, which makes it the most expensive option.

The vendor says “we can do that” but will not put it in writing.
Require written answers to the questionnaire. Anything they cannot or will not write down, treat as absent.

For our completed copy of the questionnaire, or a check of your existing routes, contact us.