Unicom Americas Mobile Business
English
Customer Portal Portal Request a quote
Unicom Americas Mobile Business
Request a quote Customer Portal

Fintech & banking: A2P SMS and mobile data

One-time codes on registered senders, sized for the peak.

Unicom Americas – Mobile Business team

Request a quote

In figures

  • An OTP is judged by arrival time and by the audit trail behind it: message ID, sender, timestamp and delivery receipt kept together per transaction.
  • SMS one-time codes inherit the weaknesses of the number: a SIM swap moves the code to an attacker, so risk controls belong in the application, not only in the message.
  • An alphanumeric sender ID is one-way in most networks; two-way verification, STOP replies and inbound support need a long or short number.
  • Regulators generally treat transaction messages differently from marketing: opt-in, opt-out and time-of-day rules attach to marketing, while service messages rest on the existing customer relationship.
  • Banks and acquirers clear OTP peaks through registered sender IDs rather than shared routes, and reserve throughput before the peak rather than during it.

This page is not legal advice.

Scenarios

Sign-up and login verification

A login code has a short life and a narrow job: prove the person holds the number now. Set a validity window, cap resends, rate-limit by number and device, and decide what happens on the third failure before launch. Message text should not include a balance, a full card number or a link to a login page, because codes get forwarded and screenshotted. Where the risk model requires it, pair the code with device binding, and offer an alternative channel when the message does not arrive. The OTP delivery and fraud explainer walks through the failure modes.

Transaction alerts

A purchase alert has to arrive close to the event and match the transaction the customer sees in the app. Send the merchant, the amount and the last four digits, not the full card number, and suppress duplicates when an authorization is reversed and re-presented. Batch non-urgent summaries overnight where the regulator allows it, and keep urgent fraud alerts on the immediate path. Reconcile what the bank recorded against what the network reported, because a receipt marked delivered is still only the network's observation.

Collections and servicing

Service reminders and consented outreach only; collection-related shutoffs stay outside the traffic policy. The practical constraints are timing, frequency and evidence: quiet hours, a cap on messages per customer per month, and a record of the consent that justified each campaign. Templates should name the sender and the purpose in the first line, so the recipient knows why the message arrived. Marketing content never rides the OTP route, even when the same team owns both, because mixing them confuses filters, consent records and the customer.

Onboarding and identity checks

Account opening often needs the customer to follow a link, upload a document or complete a liveness check. Those links are secrets with a lifetime: single use, bound to the application, and expiring faster than a marketing link ever would. A long URL is also a deliverability problem, because some filters treat unfamiliar domains and public shorteners as suspect. Use a domain you have registered with the aggregator, keep the message under one segment where possible, and never put identity documents in the message itself, only the instruction to open the app.

Branch and agent networks

Branches, agencies and ATMs in places without dependable fixed lines need a backup path that comes up without a technician. A data profile in the terminal or the branch router carries authorization and monitoring traffic while the primary circuit recovers, and the failover rule decides whether a transaction waits or reroutes. Keep the backup link out of the general office network, so a branch outage does not become a security event. Terminal estates and their certification sit on the payments page; this page covers the messaging and the branch data path around them.

Product bundle

FAQ

Do you support OTP peaks at launch?
Yes. Tell us the peak and the destinations, and the binds are sized before traffic starts, with a retry budget for the first minutes of a launch.

Can marketing run on the same senders?
Only consented marketing the recipient agreed to receive, on senders kept separate from OTP where the destination requires it. Mixing the two routes is the fastest way to get a transactional sender filtered.

What about POS traffic?
Terminal connectivity belongs on the payments page, which covers authorization traffic on private APNs. This page covers OTP, alerts and the branch data path behind the counter.

What happens when a code does not arrive?
Retry once, then offer an alternative: voice call, push approval or a fallback destination the customer already verified. Infinite resends raise cost, annoy the customer and look like the traffic pattern fraud systems flag.

How long should we keep message records?
Your regulator and your own retention policy decide, not the messaging route. Keep the message ID, template, sender, timestamp and receipt together so an audit can reconstruct what was sent to whom, and delete the content when the policy says so.

Sources

  1. 3GPP TS 23.040: SMS technical realization
  2. GSMA: mobile fraud types

Request a quote

Tell us whether you send as a platform or as the enterprise itself; we assess the fittest access.

Request a quote Enterprise