Databricks — events & appearances

Databricks sits inside a category the telecommunications industry calls A2P — application-to-person — messaging. Every text an airline sends when a boarding gate changes, every login code from a bank, every "your package is out for delivery" note from a logistics carrier, every one-time discount from a retailer — they all travel over the same rails: short, ordered, store-and-forward packets that the world's mobile networks have been carrying for more than thirty years.

What has changed is the plumbing behind those texts. In the consumer era, SMS was person-to-person over a single carrier. In the enterprise era, a message originates in a database, a queue or a workflow engine — is handed to a platform like SveaSMS via a REST API — and lands on a device in Osaka, Oslo or Ouagadougou seconds later, having crossed multiple operators, regulators and billing systems along the way. That path is the product.

An SMS is not a stream. It is a 140-octet payload defined in 3GPP TS 23.040, carried by the Short Message Service Centre (SMSC) of a mobile network and delivered as a control-plane signal to the recipient handset. The 160-character limit that users remember comes from the GSM 7-bit alphabet — Unicode messages fall to 70 characters per segment, and long messages are concatenated with a User Data Header that the handset re-assembles. This matters commercially: a "message" a customer writes may cost one, two or three billable segments depending on characters, emoji and line breaks.

Because SMS is signalling — not data — it works when 4G doesn't, when Wi-Fi is off and when the recipient has never installed an app. That resilience is why banks, governments and airlines have never migrated away from it, even as chat apps proliferated.

Routing is the difference between a message that arrives in two seconds with the correct sender ID and one that is silently filtered, throttled or grey-routed. A tier-1 route is a contracted, disclosed interconnect with the destination operator — the operator knows the traffic, prices it, and guarantees the sender ID it delivers. A grey route is arbitrage: a message enters the destination network dressed as person-to-person traffic to avoid termination fees, and the operator's anti-fraud systems increasingly detect and drop it.

We operate on disclosed, direct-carrier routes because that is the only substrate on which OTPs, boarding passes and medical reminders can be trusted. When a low-cost aggregator quotes a rate that seems too good, the delta is almost always paid for by the recipient's failed login.

An API — application programming interface — is the contract between the code that decides "send this message" and the infrastructure that performs it. Ours is a small, well-typed HTTPS surface: one endpoint to send a single message, one to send in bulk with per-recipient personalisation, one to receive delivery-report webhooks, one to receive inbound replies, plus authentication, rate-limit signalling and a status endpoint that reports carrier-level acknowledgement.

Well-designed messaging APIs abstract away the parts customers should never see — segment counting, encoding negotiation, carrier lookup, sender-ID registration, retry with exponential backoff — and expose the parts they must control: destination, sender, content, delivery window, priority, callback URL and idempotency key. Everything else is our problem, not yours.

Marketing pages love the word "throughput". Operations teams care about a different number: the percentage of accepted messages that reach the handset within the intended window. High throughput on a bad route means we sent very quickly to nowhere. Deliverability, measured against carrier delivery receipts (DLRs) rather than platform-level acceptance, is audited weekly per corridor and shared with any customer who asks. When a corridor drifts, we reroute — we do not adjust the dashboard.

Every destination has its own rulebook. The United States enforces 10DLC registration for local long-code sending, and carriers actively filter unregistered traffic. India requires DLT template and header registration through TRAI. The United Kingdom, Germany, France and the Nordics enforce GDPR consent provenance. Saudi Arabia and the UAE require registered sender IDs with government approval. Brazil applies Anatel rules. China requires an ICP-registered sender and content review.

We handle registration, template approval and consent-record audits per market so that customers ship in one interface and stay legal in twenty. Getting this wrong is not a deliverability issue — it is a fine, a blocked sender ID and, increasingly, a criminal referral.

A well-routed A2P message clears in one to three seconds end-to-end: platform acceptance, carrier ingress, MAP signalling to the visited MSC, handset delivery, DLR return. The variance comes almost entirely from the destination carrier's own congestion and from whether the route is direct. Cost is driven by termination fees the destination operator charges; they range from fractions of a cent (dense European corridors) to double-digit cents (some African and Middle Eastern markets). We publish these as flat, per-corridor rates rather than blended averages — a blended rate hides which markets subsidise which.

Two-factor authentication and one-time passwords are the largest single volume driver — every login flow at every bank in the world eventually generates a text. Transactional notifications (order shipped, appointment tomorrow, invoice due) are second. Marketing broadcasts — opted-in, timed to open rate rather than send rate — are third. Emergency and public-safety alerts, class registration reminders, delivery driver ETAs, fraud alerts, VIP campaigns, political get-out-the-vote, election-day poll notifications, ticket resale confirmations — each is a variation on the same underlying primitive: a short, ordered, guaranteed message to a phone that is always with its owner.

We are the operational brand of Global Trade Rhino LLC's messaging division. The company runs direct interconnects across 200+ destinations, a single global API, and a billing and compliance stack that unifies all of that into one account. Customers do not stitch three regional aggregators together — we already did that, and we monitor it. The Nordic identity is historical: our flagship market and where onboarding, pricing and support are anchored.

• A2P — application-to-person messaging.
• P2P — person-to-person messaging.
• SMSC — Short Message Service Centre; the operator node that stores and forwards SMS.
• SMPP — Short Message Peer-to-Peer; the binary protocol most operators expose to us.
• MCC/MNC — mobile country and network codes; how a route is targeted.
• DLR — Delivery Receipt; the acknowledgement that a message reached the handset.
• Sender ID — the alphanumeric or numeric string the recipient sees as the "from".
• 10DLC — the U.S. carrier programme for registered local long-code A2P traffic.
• DLT — Distributed Ledger Technology; the Indian regulator's template-registration platform.
• Grey route — an undisclosed, arbitrage route that operators actively block.

Do you own the routes? We contract directly with terminating operators wherever the regulator allows a direct interconnect, and we hold tier-1 aggregation relationships where we do not. Both categories are disclosed to the customer.

What about RCS, WhatsApp, iMessage? They are excellent channels for two of the seven parties in a typical customer base. SMS is the only channel that reaches all seven, on any device, with no install, in every country. We use it as the foundation and layer richer channels on top when the recipient supports them.

Can we start small? Yes. There is no minimum monthly commitment. Pricing is per-message and per-corridor, published in advance.