The Honest Delivery Standard

We measure ourselves by
what arrives. Nothing else.

What we insist on — not a slogan, but the floor for every send.

Every send request through our API is logged — every single one. You send N, we submit N to the carrier network; inbound and submission counts reconcile in your dashboard and request logs. We will not shave entrusted volume to cut cost, and we will not falsely report delivered.

Every message gets a carrier-level delivery report (DLR) with status and reason codes. For every message reported as not reaching the recipient, we trace with the telco and document it in reports you can follow — actual delivery, with a trace you can audit. That is the only metric we recognise.

Today's send reconcile
API accepted 1,240
Submitted to network 1,240
DLR delivered 1,198
Not delivered (coded) 42

Full submission: inbound = submitted

Carrier-level DLR on every message

01

Transparent DLR

Every message gets a real Delivery Report — direct from the carrier, with carrier-level error codes. Not "submitted = success".

# Sample DLR webhook payload
{
  "message_id": "msg_01HF8K7Z9TX2",
  "to": "+852•••••567",
  "status": "DELIVERED",
  "carrier": "direct_route",
  "submitted_at": "2026-05-28T08:14:22Z",
  "delivered_at": "2026-05-28T08:14:23Z",
  "latency_ms": 1247,
  "error_code": null
}

Financial-services clients receive a monthly aggregate report — delivery rate, average latency, carrier-level breakdown.

02

Full submission pledge

Every send request your API makes that we accept is submitted to the carrier network — no silent drops, no shaved volume, and no blurring "API accepted" with "entered the network".

Many businesses only discover a gap after switching providers: the dashboard "sent" count doesn't match their own request logs; traffic quietly throttles at peak; month-end invoices show fewer messages with no way to audit line by line. We put this in writing: accepted requests = network submissions — reconcilable live in your dashboard and exportable for internal audit. DLR tells you what the carrier did next; this pledge tells you we didn't eat your traffic before it left our platform.

The gap clients often find

API returns success, but fewer messages hit the carrier queue than your log shows — and you can't reconcile request by request.

Our pledge

1 accepted send request = 1 submission attempt to the network. Failures are reported honestly via DLR — but we don't skip the submission.

03

No grey routes

A grey route is a cheaper third-party hop disguising the sender. Carriers can detect them, delivery silently suffers, and you can't tell from your "submitted" report.

We route SS7-direct to regional telcos worldwide. It costs more per message — and it's why our DLRs say what they say.

What grey routes look like

"Submitted" reported as success. Real delivery 60–75%. No way to audit which messages actually reached.

What direct routes do

Carrier-confirmed delivery report. 95%+ delivery on legitimate traffic. Honest about the rest.

04

Compliance

  • PDPO (Hong Kong): we process personal data only for the purposes you commission, retain only as long as compliance requires, and provide data-access support on request.
  • OFCA SMS Sender Registration Scheme: we register your verified # Sender ID on your behalf, then maintain it.
  • GDPR posture: for clients with EU data subjects, we operate as a data processor under standard contractual clauses.
  • TW PDPA / CN cybersecurity law: handled per region as part of our compliance onboarding for cross-border sends.
  • ISO 27001: certification in progress.
05

Who we say no to

An Acceptable Use Policy is a trust signal, not a legal footnote.

We refuse: phishing, impersonation of banks / government / carriers, unsolicited cold marketing without opt-in, pump-and-dump or unregulated investment promotion, and traffic that uses sender IDs the sender doesn't own.

If a prospect's use case raises a flag, our compliance team reviews before sign-up. That's how we keep deliverability for the rest of our clients high.

Hong Kong · Anti-fraud

The OFCA SMS Sender Registration Scheme, explained

Since 28 December 2023, the Office of the Communications Authority (OFCA) has run a public Sender ID registry that lets recipients verify who actually sent an SMS — the single most effective defence against SMS phishing in Hong Kong. Here is exactly how it works, and what we do about it.

What the # prefix means

A registered sender's messages arrive with a # in front of the Sender ID — e.g. #YourBank. The # is reserved: only senders vetted and entered in OFCA's registry can use it, so a recipient who sees #YourBank knows the message is not an impersonation.

Who has joined

Major telecom operators, the banking industry and government departments registered first; the scheme is now open to all sectors. For regulated Hong Kong securities firms, a registered # Sender ID is fast becoming the baseline customer expectation — not a nice-to-have.

How anyone can verify a sender

The OFCA SMS Sender Registry is public — anyone can search it to confirm a registered sender and its # Sender ID. We hand every client their registry entry so their customers and their compliance team can check it independently.

What we handle for you

We prepare and file your # Sender ID registration with OFCA, advise on a sender name that won't trip carrier blocklists, and maintain the registration so it never lapses. Typical OFCA review takes 2–3 weeks; we manage the back-and-forth.

References: the official OFCA SMS Sender Registration Scheme and the public SMS Sender Registry.

Proof point

100+ Hong Kong securities firms choose us for OTP.

Trading platforms cannot afford a failed login code. The fact that more than a hundred regulated HK firms route their OTP traffic through us is the strongest single proof of the Honest Delivery Standard in practice.

100+
HK securities firms

99.5%+
OTP delivery rate (rolling 30d)

<3s
Median delivery latency

Ready to get started?

Contact us — send soon after a quick account setup. Free trial credit lets you integrate first and confirm the platform fits your use case.