Integration architecture
OFS vs API vs Batch Interfaces
They all move data in and out of T24. They all have passionate advocates. And they are all wrong for certain use cases. Here is how to choose.
If you have spent any time around a T24 system, you have heard the three integration paradigms mentioned in the same breath — OFS, APIs, and batch interfaces. They all move data in and out of T24. They all have passionate advocates. And they are all wrong for certain use cases.
The problem is that most T24 professionals learn one paradigm and stick with it. The OFS person thinks everything should be an OFS message. The API person thinks REST is the answer to everything. The batch person thinks files are the only reliable way to move data.
The truth is that each paradigm has a sweet spot, and knowing which one to use for which scenario is what separates a T24 integration architect from someone who just knows how to send an OFS message.
OFS: The original real-time interface
OFS — Open Financial Services — is the oldest and most fundamental integration mechanism in T24. The R24 documentation describes it as "the single point of entry to Temenos Transact." Every interaction with Transact takes place through OFS.
What it is: OFS is a text-based protocol that sends structured messages to T24. A typical OFS transaction request looks like this:
FBNK,ACCOUNT.DEBIT.CREDIT/I/PROCESS//DEBIT,ACCOUNTNO:12345,AMOUNT:1000
What it is good for: Real-time transactions, enquiries, routine execution, and SWIFT message processing.
What the R24 docs tell us: OFS supports seven distinct request types — transactions, enquiries, clearing, TEC OFS interface, XML reports, inward SWIFT, and routine requests. It has optional audit trails, API hooks for pre- and post-processing (IN.MSG.RTN, OUT.MSG.RTN,MSG.PRE.RTN, MSG.POST.RTN in theOFS.SOURCE record), full multi-company awareness, and full support for hierarchical data.
The catch: OFS is synchronous. If the downstream system is slow, OFS blocks. If T24 is under load, OFS queues up. And OFS messages are opaque — debugging a failed OFS message requires parsing the response code and knowing what it means.
APIs: The modernisation path
T24's API layer — IRIS, the Interaction Framework, and the REST APIs — is the modern way to integrate. It wraps T24 functionality in standard RESTful endpoints with JSON payloads.
What it is good for: External-facing integrations, low-volume high-value transactions, and modernisation projects.
The catch: APIs add overhead. Every API call goes through authentication, authorisation, request validation, and response formatting. For high-volume scenarios, this overhead adds up. And APIs are not always available for every T24 function.
Batch interfaces: The volume workhorse
Batch interfaces — file-based integration — are the oldest and most reliable way to move large volumes of data in and out of T24. They are also the most underappreciated.
What it is good for: High-volume data loads, regulatory reporting, downstream system feeds, and bulk updates.
The catch: Batch runs on a schedule. If you need real-time data, batch is not the answer. And batch failures are harder to diagnose because the error is in a log file that nobody reads until something breaks.
The decision framework
| Scenario | Best choice | Why |
|---|---|---|
| Customer-facing transaction | OFS or API | Needs to be real-time. OFS for direct T24 control. API for standard REST. |
| High-volume data load (over 10,000 records) | Batch | OFS and API will be too slow. Batch is designed for volume. |
| Regulatory report | Batch | Reports are generated on a schedule and sent as files. |
| Real-time enquiry | OFS or API | OFS for simple enquiries. API for complex ones with structured responses. |
| System-to-system integration | API | Standard protocols, standard auth, standard data formats. |
| Legacy system integration | OFS or Batch | Depends on the legacy system's capabilities. |
| Event-driven integration | API (IRIS) | IRIS publishes events that subscribers consume in real time. |
The R24 perspective
R24 does not change the fundamental paradigms, but it does add some important nuances:
- OFS API hooks are formalised. The
OFS.SOURCErecord in R24 has specific fields for pre- and post-processing routines (IN.DIR.RTN,IN.MSG.RTN,OUT.MSG.RTN,MSG.PRE.RTN,MSG.POST.RTN). These allow you to customise OFS processing without modifying core code. - IRIS event publishing is the new hotness. R24's
Session.publishMessage()API allows you to publish events from within T24 code. This is the foundation for event-driven architecture. - Batch is still king for volume. Despite all the modernisation, batch processing is still the most reliable way to move large volumes of data. R24's Global Processing mode makes batch even more powerful with multi-company, multi-calendar support.
The bottom line
Do not be the person who only knows one integration paradigm. Learn all three. Understand when each one is appropriate. And when someone asks you "should we use OFS or APIs for this integration?" — have a framework for answering, not just an opinion.
The best T24 integration architects are the ones who can look at a requirement and say "this is an OFS use case, this is an API use case, and this is a batch use case" — and then explain why.