MQ Patterns with Temenos T24

Here is a scenario that plays out in every T24 bank at least once a quarter:

The payment system sends a message to T24. T24 processes it. But the response never comes back. Was the payment posted? Was it rejected? Nobody knows. The operations team spends three hours tracing through logs. The payment is eventually found — it was posted, but the response was lost in a network blip.

This is the problem that MQ solves.

Message queue technology — specifically IBM MQ (formerly WebSphere MQ, formerly MQ Series) — is the backbone of reliable messaging in most T24 banks. It is not glamorous. It does not make the front page of architecture diagrams. But it is the thing that ensures payments are not lost, responses are not dropped, and operations teams can sleep at night.

Why MQ matters for T24

T24 was built in an era when direct database access was the norm and network reliability was optimistic. As banks grew and added more systems, the need for reliable, asynchronous communication became critical.

MQ provides three things that T24 integrations desperately need:

1. Guaranteed delivery. Once a message is on the queue, it stays there until it is consumed. Server crash? Network outage? Application restart? The message survives.
2. Asynchronous processing. The sender does not wait for the receiver. It puts the message on the queue and moves on. This decouples systems and improves resilience.
3. Load leveling. If T24 is under heavy load, messages queue up and are processed when capacity is available. No messages are lost.

Pattern 1: OFS over MQ

This is the most common pattern. An external system sends OFS messages to an MQ queue. A T24 listener — typically the OFS.REQUEST.MGR or a custom MQ listener — picks up the message, processes it through OFS, and puts the response on a reply queue.

External System → MQ Request Queue → T24 OFS Listener → T24 → MQ Reply Queue → External System

When to use it: When you need reliable delivery for OFS messages. If the OFS message is a payment instruction, you do not want it lost in a network failure.

The gotcha: The OFS listener needs to handle the correlation between request and response. MQ correlation IDs are the standard approach.

Pattern 2: MQ as a batch trigger

In this pattern, an MQ message triggers a batch process in T24. The message contains parameters for the batch job — which company, which process, which date.

Scheduler → MQ Trigger Queue → T24 Batch Manager → Batch Job Execution → MQ Status Queue → Scheduler

When to use it: When you need to trigger batch jobs from an external scheduler or when batch jobs need to be chained together.

The gotcha: The batch job needs to report its status back to the MQ queue. If the batch job fails, the MQ message should trigger an alert or a retry.

Pattern 3: Event publishing via MQ

In this pattern, T24 publishes events to an MQ topic. Multiple subscribers can consume the same event. This is the foundation of event-driven architecture in T24.

T24 → MQ Topic → Subscriber 1 (Data Warehouse)
             → Subscriber 2 (Reconciliation System)
             → Subscriber 3 (Alerting System)

When to use it: When multiple downstream systems need to react to the same T24 event — a payment posted, a customer created, an account opened.

The gotcha: Topic-based publishing requires careful design of the event schema. If you change the event format, all subscribers need to be updated. Versioning is essential.

Pattern 4: Dead letter queue and retry handling

This is not a glamorous pattern, but it is the most important one. When a message cannot be processed — because T24 is down, because the data is invalid, because of a transient error — it goes to a dead letter queue (DLQ).

MQ Queue → Processing Failure → Retry Queue (3 attempts) → Dead Letter Queue → Manual Intervention

When to use it: Always. Every MQ integration with T24 should have a DLQ strategy. Messages that cannot be processed should not be silently dropped.

The gotcha: The DLQ needs monitoring. A DLQ with 10,000 messages that nobody looks at is not a DLQ — it is a time bomb.

MQ vs IRIS: The R24 perspective

R24 introduces IRIS (Interaction Framework) as the modern event-publishing mechanism. IRIS uses Session.publishMessage() to publish events that subscribers can consume via REST webhooks or Kafka topics.

So where does MQ fit in the R24 world?

• MQ is still the right choice for OFS message delivery. IRIS does not replace MQ for reliable OFS message transport. If you need guaranteed delivery of OFS messages, MQ is still the answer.
• IRIS replaces MQ for event publishing. If you are publishing events for downstream consumption, IRIS is the modern approach. It uses standard protocols (REST, Kafka) and does not require MQ infrastructure.
• MQ is still the right choice for legacy system integration. If you are integrating with a legacy system that only speaks MQ, you are not going to replace it with IRIS.

The bottom line

MQ is not dead. It is not going away. And it is not replaced by REST APIs or event-driven architecture.

MQ is the reliable backbone that keeps T24 integrations running when networks fail, servers crash, and applications restart. It is the thing that ensures payments are not lost and responses are not dropped.

If you are building a T24 integration and you are not thinking about MQ, you are probably building something that will fail in production. And the operations team will not thank you for it.