Real-time SMS banking on a live transaction switch

The problem

A major bank needed real-time balance, withdrawal, transfer and alert notifications driven directly off core banking activity. The hard constraints: notifications had to be near-instant, the core banking system could not be slowed down, and a customer must never receive a wrong balance. A late SMS is annoying; a wrong one destroys trust.

Options considered

Polling the core database. Simple to build, but it puts constant read load on the core, adds latency (you're only as fast as your poll interval), and race conditions between the poll and in-flight transactions make wrong balances likely.

Event-driven off the transaction switch. The IRIS switch already receives transaction events. Hooking notification triggers to those events avoids the continuous database load and interval-based delay introduced by polling.

The decision

Event-driven, off the switch. I mapped switch events to notification triggers and kept three concerns strictly separate: message formatting, delivery, and account routing. That separation kept delivery failures away from formatting logic and made new notification types additive.

The hard part: partial and duplicate transactions

Transaction switches emit messy reality — reversals, timeouts, duplicate events. The defensive rules:

• Every event carried an idempotency key; duplicates were dropped at the boundary.
• Balance-bearing messages were only composed from settled state, never from the event payload alone.
• Ambiguous events (partial/reversed) suppressed the balance line rather than risk sending a wrong number.

The final rule favored omitting uncertain balance data over sending a potentially incorrect value.

Outcome

The integration produced real-time notifications from transaction events without a continuous polling workload on the core database. Idempotency and settled-state checks made duplicate and ambiguous events explicit parts of the design.

What I'd do differently today

I'd put a message broker between the switch adapter and the notification engine from day one. We effectively rebuilt half of one with retry tables; RabbitMQ would have given us established dead-lettering and replay mechanisms.