Real-time SMS banking connected to a transaction switch

The problem

A major bank wanted to send SMS alerts for balance, withdrawals, transfers and other account activity as soon as they happened. The requirements: alerts had to be almost instant, the core banking system could not be slowed down, and a customer must never get a wrong balance. A late SMS is annoying. A wrong one makes customers stop trusting the bank.

Options

Polling the core database. Easy to build, but it adds constant read load on the core system. It is also slow (only as fast as the poll interval), and timing issues between the poll and running transactions can easily lead to wrong balances.

Listening to events from the transaction switch. The IRIS switch already receives every transaction event. Triggering notifications from these events avoids the database load and the delay that polling adds.

The decision

Use events from the switch. I mapped each switch event to a notification trigger, and kept three parts clearly separate: message formatting, delivery, and account routing. Because of this, delivery errors did not affect formatting, and adding a new notification type did not require changing existing code.

The hard part: partial and duplicate transactions

Transaction switches send messy data: reversals, timeouts and duplicate events. The rules I used:

• Every event had an idempotency key, and duplicates were dropped as soon as they arrived.
• Messages with a balance were built only from the settled balance, never from the event data alone.
• For unclear events (partial or reversed), the balance line was left out instead of risking a wrong number.

In short: it is better to leave out a balance than to send one that might be wrong.

Outcome

The system sent real-time notifications based on transaction events, without constant polling of the core database. Idempotency and settled-balance checks made sure duplicate and unclear events were handled on purpose, not by accident.

What I'd do differently today

I would add a message broker between the switch adapter and the notification system from the start. We ended up building half of one ourselves with retry tables. RabbitMQ would have given us dead-letter queues and message replay out of the box.