Everything worth knowing, nothing that isn't.
How attackers spoof
Three patterns. They submit through a weakly-governed aggregator that doesn't enforce sender-ID whitelisting against registered owners (this should never happen, but happens). They route through a foreign SS7 path that bypasses local sender-ID checks (mostly closed by FS.07-aligned firewalls). They abuse SIM-box infrastructure to send from a real MSISDN that they then alphanumeric-overlay with a fake brand string (some aggregator stacks allow this).
How operators defend
Sender-ID registration (the foundational defence). Outbound sender-ID enforcement at the aggregator: BroadNet's submission gateway rejects any submit_sm whose alphanumeric sender field is not in the customer's approved sender-ID whitelist for the destination country. Inbound sender-ID validation at the operator firewall: cross-check incoming A2P traffic's claimed sender against the registered owner per country.
What buyers should expect from their aggregator
Strict whitelisting. If your aggregator lets you set the sender ID to any arbitrary string at API-call time without prior approval, that aggregator is a smishing risk to the rest of the ecosystem. Reputable aggregators require sender-ID pre-registration. Period.
Regulatory state
MENA regulators (TDRA, CST, NTRA, TRC) have been increasingly aggressive on sender-ID spoofing. Operators in EU markets are deploying SMS-Sender-ID validation under EU NIS2 frameworks. RCS Business Messaging is gradually replacing trust-critical SMS exactly because the sender is cryptographically verified.