WHAT IT IS
SMSGateway is a middleware layer that centralises SMS sending and receiving for all of a bank's internal and partner applications through a single integration point, instead of each system connecting directly to the mobile operator. Each application is registered as its own entity, with a monthly quota, priority permissions and specific security rules. Sending can happen in real time via API (SOAP or REST) or in batch via file upload. What sits above and below it barely matters. Every application integrates the same way, whichever core it happens to run on, and the mobile operator is reached through a provider that can be swapped out.
WHY IT MATTERS
On the bank's side, there's a single SMS integration point - not a dozen direct, ad-hoc connections to the mobile operator, each built its own way by a different system. Every integrating application gets its own quota, priority and authorised IP list, the cost of each message is calculated down to the segment to match the operator's invoice, and each message's delivery status is tracked in detail - without forcing rework on anyone already integrated whenever the platform evolves.
FEATURES
Governance per application: every integrated system is registered as its own application, with a monthly SMS quota and high-priority sending permission set individually.
SOAP and REST APIs: real-time sending, individual or bulk, through a legacy SOAP API kept stable or a modern REST API documented with Swagger/OpenAPI.
Batch sending with prior validation: file upload with one SMS per line, a validate-only (dry-run) mode ahead of the actual send, and a per-line result after processing.
Self-service backoffice: a dedicated web interface, with session login and LDAP or internal authentication, letting a bank employee send batch SMS campaigns without requesting development work.
Exact accounting for billing: precise calculation of the number of segments per message, based on the character set used, with daily, monthly and yearly counters per application.
Granular delivery reports: detailed per-message states - delivered to handset, delivery failed, delivery pending, delivered to operator, not delivered to operator.
Certificate- and IP-based security: mandatory HTTPS/TLS communication with client certificates (mTLS) issued per application and an allow-list of source IPs per environment.
Scheduled automatic reports: scheduled jobs periodically email usage reports to each integrated application.
Pluggable provider architecture: actual SMS delivery runs through a replaceable internal interface, with a "dummy" provider available for test environments.
New messaging channels (WhatsApp, RCS): architecture designed to support additional messaging channels beyond SMS in the future.
ADVANTAGES
Mobile app, internet banking, virtual branch, agent banking, credit systems and CRM no longer negotiate with the mobile operator on their own - they all go through the same integration point, with central governance over who sends what.
The self-service backoffice lets a business user upload a campaign file, validate it before any real sending, and launch the campaign on their own - without requesting development work for every campaign.
The number of segments per SMS is calculated precisely - accounting for the character set, not a simplistic division - with daily, monthly and yearly counters per application, so the operator's invoice can be checked without disputes.
The platform was modernised internally - new stack, new REST API documented with Swagger - without forcing anyone already on the legacy SOAP API into any rework.
Architecture designed to be the bank's single SMS integration point - not one more system to reconcile.
BUILT FOR
Mobile app, internet banking, virtual branch, agent banking and credit systems each integrating with the operator their own way - with no central visibility over quotas, priority or cost.
A marketing or CRM team that needs to launch a batch SMS campaign without opening a development request every time.
Without an exact per-application segment count, reconciling the operator's invoice becomes a guessing game.
Need to evolve the platform without breaking whoever is already integrated through the existing SOAP API.
HOW IT WORKS
A short onboarding form is filled in - system, expected monthly volume, need for high priority, source IPs, SMS receiving, delivery reports - then configured and approved before go-live.
Connection via SOAP or REST API, or by uploading a batch file, validated beforehand in validate-only mode.
SMS are sent through the configured provider and delivery status is returned via DLR reports.
Segments and volumes are counted per application and reported periodically by email through scheduled jobs.
It's a middleware layer that centralises SMS sending and receiving for all of a bank's internal and partner applications through a single point, instead of each system connecting directly to the mobile operator. It supports sending via API (SOAP or REST) and via batch file, with exact segment accounting for billing.
Yes. The core connection is adapter-based - Banka, Finastra Essence, an in-house legacy system, whatever is already there - over API/ISO, with no change to the central system. The domestic side works the same way: each market's clearing house, EMIS in Angola included, plugs in through an adapter.
Both. Banks in markets with data-residency requirements usually choose on-premise; SaaS where regulation allows it.
It supports both. Each integrated application can be granted permission to send high-priority messages (such as OTPs), and separately, the self-service backoffice allows batch campaigns to be sent via file upload, with the format validated before the actual send.
INM's own teams - we don't subcontract implementation. The same team runs, evolves and supports the product 24/7 after go-live.
Talk to our team to see how this product fits your ecosystem.