What financial institutions send
| Message | Trigger | Integration |
|---|---|---|
| One-time passwords for login, transfers and payout changes | User action, real time | API or SMPP from the core banking or app backend |
| Deposit, withdrawal and transfer confirmations | Transaction posts | API or SMPP |
| Balance alerts and mini-statements | Threshold or request | API; keyword request over two-way SMS |
| Loan approval, disbursement and instalment reminders | Loan lifecycle, scheduled | API from the loan management system, or scheduled spreadsheet upload |
| Arrears and collections messages | Overdue instalments | Personalised upload per collections run |
| Fraud and security notices | New device, password change | API |
| Product campaigns to opted-in customers | Marketing calendar | Console campaign with A/B testing |
OTP and transaction authentication
The OTP is the message a bank cannot afford to lose. It has to leave the moment the customer asks for it, arrive from a sender the customer recognises, and be traceable afterwards. Your system generates the code and submits it through the send API or an SMPP bind; the response carries a message ID, and the delivery report for that ID is the evidence that the code reached the handset. The OTP SMS guide covers the flow and the design choices — validity, attempts, resend — in detail.
Repayment reminders and collections for MFIs
Microfinance institutions run on repayment discipline, and a reminder three days before an instalment costs a fraction of a field visit after it is missed. Two ways to run it:
- From the loan system, automatically. A nightly job selects instalments due in three days and calls the API once per borrower with name, amount and date.
- From a spreadsheet, per run. Export the due list, upload it with a template, schedule for 08:00. The upload is validated and each borrower receives their own figures.
Blacklisted numbers (customers who have asked not to be contacted by SMS) are suppressed on every send automatically, so a collections upload cannot accidentally message them.
SMPP for continuous, high-volume traffic
A bank's alert stream is constant. Rather than one HTTP request per message, connect the core system to the Ontech BulkSMS SMPP 3.4 server with a persistent transceiver bind: submits go out as PDUs, delivery receipts and any inbound messages come back on the same session. Each credential has a throughput limit and is gated by your IP whitelist. For lighter integrations — a loan app sending a few thousand messages a day — the HTTP/JSON API is simpler and equally tracked.
Audit and reconciliation
- Every message sent is logged with its recipient, sender ID, timestamp, credit cost and message ID.
- Every delivery report is stored against the message and shown in the dashboard; reports can be exported to CSV or Excel.
- Every API request is recorded, and API keys are restricted to whitelisted IP addresses.
- Organisations let several staff logins draw from one shared credit balance while recording which member performed each action.
Sender identity and trust
Fraudulent "your account is blocked" texts are common, so the institution's sender ID is part of its security posture. A branded sender ID (up to 11 characters) is approved on a signed authorization letter and is then the only name that appears on your messages; consider separate sender IDs for security messages and for marketing so customers learn what to expect from each.
Consent and data protection
Transactional messages — OTPs, confirmations, reminders — are expected by the customer as part of the banking relationship. Marketing messages need a recorded opt-in and an opt-out path. Phone numbers and message content are personal data under Zambia's Data Protection Act 2021; the platform's Privacy notice describes how they are processed and Ontech Solutions is registered with the Data Protection Commission (DP000394). Keep message content to what the customer needs and avoid full account numbers in the text.