What Is OFS in T24?

At some point you will be handed a log file containing something like this:

HELPTEXT.MENU,OFS.DEMO/I/PROCESS,TEST.USER/654321,OFS.TEST,APPLICATION:1:=SECTOR,DESCRIPT:1:=Sector

If your first thought is that someone sat on a keyboard, you are in good company. OFS messages look like structured chaos until you understand the pattern. Once you do, they are actually quite readable — and every integration problem that comes through an OFS channel becomes diagnosable in under a minute.

This article explains the pattern.

What OFS actually is

OFS — Open Financial Services — is the single point of entry interface to Temenos Transact. Every interaction with T24 from an external system goes through OFS. Mobile banking, third-party integrations, internal batch processes talking to T24, channel systems — all of them communicate via OFS messages.

OFS is not the connectivity layer. It does not define how a message gets from A to B — that is handled separately by MQ, API Gateway, or whatever transport mechanism the bank has configured. OFS defines the structure of the message itself: what it contains, what it means, and what T24 will do with it.

Think of it as the language T24 speaks. Connectivity is the postal system. OFS is the letter format.

What OFS can do

OFS handles several distinct types of request:

• Transactions — create, modify, delete, or validate records in any T24 application
• Enquiries — query T24 data using the standard enquiry framework
• Routine requests — call T24 BASIC routines directly
• XML report requests — trigger report generation
• Clearing — submit clearing messages
• SWIFT inward delivery — pass inbound SWIFT messages into T24

The two you will encounter most often in day-to-day support are transactions and enquiries. The rest are specialist and context-dependent.

The message structure

Every OFS message follows the same basic structure, comma-delimited:

OPERATION, OPTIONS, USER/PASSWORD, SOURCE, DATA

Five components, separated by commas. Let's go through each one.

Operation

The T24 application or action to run. For transactions this is the application name — SECTOR, FOREX, FUNDS.TRANSFER,AA.ARRANGEMENT.ACTIVITY and so on. For enquiries it is always ENQUIRY.SELECT.

Options

Specifies version, function, and processing flag, separated by /:

VERSION/FUNCTION/PROCESSING_FLAG

OFS.DEMO/I/PROCESS    → version OFS.DEMO, Input, Process (commit)
OFS.DEMO/I/VALIDATE   → version OFS.DEMO, Input, Validate only (no commit)
/R                    → no version, Read/display
/D                    → no version, Delete

The function defaults to I (Input) if not specified. The processing flag defaults to PROCESS. VALIDATE is a particularly useful flag — more on that below.

User/Password

A valid T24 sign-on in the format USERNAME/PASSWORD. OFS will not process anything without valid credentials. The user's T24 security profile applies — so if the user cannot access the application through the Browser, they cannot access it through OFS either.

For multi-company environments, the company code is appended: TEST.USER/654321/DE0010001

Source

The name of the OFS.SOURCE record that defines the connection parameters for this integration. This is how T24 knows what logging to apply, what syntax type to expect, and what special handling to use for this channel.

Data

The field data for the request, using T24's multi-value notation:

FIELDNAME:MULTIVAL:SUBVAL=VALUE

ORIGINAL.TEXT=SECTOR              → field with simple value
APPLICATION:1:=SECTOR             → multi-value 1 of APPLICATION
DESCRIPT:1:2=Industrie            → sub-value 2 of multi-value 1 of DESCRIPT

Multiple fields are separated by commas. This is the part that looks intimidating at first, but the logic maps directly to how T24 stores multi-value fields — once you know that, it reads cleanly.

A transaction request in full

Here is an example that creates a new AA arrangement:

AA.ARRANGEMENT.ACTIVITY,OFS/I/PROCESS,INPUTT/123456,,
ARRANGEMENT=NEW,
ACTIVITY:1:1=LENDING-NEW-ARRANGEMENT,
EFFECTIVE.DATE:1:1=20130718,
CUSTOMER:1:1=100100,
PRODUCT:1:1=PERSONAL.LOAN,
CURRENCY:1:1=USD,
PROPERTY:1:1=COMMITMENT,
FIELD.NAME:1:1=AMOUNT:1:1,
FIELD.VALUE:1:1=1000

Reading left to right:

• AA.ARRANGEMENT.ACTIVITY — the T24 application
• OFS/I/PROCESS — version OFS, Input function, commit to database
• INPUTT/123456 — the T24 user and password
• Source is blank (uses default)
• Data: creates a new lending arrangement with the specified fields

The blank source field is worth noting — it is not an error, it means the default OFS source is used. Missing commas, however, are always an error. The comma count is how T24 knows which component is which.

Enquiry requests

Enquiry requests follow a slightly different pattern. The operation is always ENQUIRY.SELECT, and the data section contains selection criteria rather than field values:

ENQUIRY.SELECT,,TEST.USER/654321,CURRENCY-LIST,@ID:LK=C...

The data section uses SELECTION.FIELD:OPERAND=CRITERIA format. Supported operands:

• EQ — equals
• NE — not equals
• GT / GE / LT / LE — greater/less than
• LK — like (pattern match)
• NR — not like

The enquiry must exist and be valid in T24. If the enquiry does not exist or the user cannot access it, OFS returns an error rather than results.

VALIDATE mode — the most useful thing nobody tells you

Every OFS transaction can be run in VALIDATE mode instead of PROCESS mode. VALIDATE performs all normal T24 processing — validations, defaults, calculations — without committing anything to the database.

This is useful in two situations most people do not think of immediately:

Testing a message before sending it for real. Run it in VALIDATE first. T24 tells you exactly what would happen — what values would default, what errors would fire, what the resulting record would look like — without touching live data.

Fetching defaults from a product or application. Send a VALIDATE request with minimal data and T24 returns the full record with all default values populated. This is how channel systems pre-populate forms for users before a transaction is actually submitted.

ABBREVIATION,//VALIDATE,TEST.USER/654321,SEC,ORIGINAL.TEXT=SECTOR

The double slash before VALIDATE means no version specified and no function (defaults to Input), with VALIDATE as the flag. The record is not written.

OFS.SOURCE — the configuration layer

Before any OFS request can be processed, the OFS.SOURCE record for that connection must exist and be configured. This is where the behaviour of the integration is defined at a channel level.

Key fields in OFS.SOURCE:

• Source Type — the type of communication being used (Telnet, and others depending on the connectivity layer in use)
• Max Connections — maximum concurrent OFS connections for this source. Should be at least 5 less than the total user limit in SPF
• Log Detail Level — NONE, EXCEPT (errors only), or FULL (all messages). Full logging is useful during testing; leave it on EXCEPT or NONE in production unless you are actively debugging
• Maint Msg Dets — if set to Y, T24 writes each OFS request and response to OFS.REQUEST.DETAIL. Useful for audit and debugging. Has a performance cost at volume.

If an OFS message arrives referencing a source that does not exist or is not configured correctly, T24 rejects it before any application processing happens. This is one of the first things to check when an integration suddenly stops working.

Security — what actually controls access

OFS does not have its own security model. It uses T24's standard SMS (Security Management System) definitions. The user in the OFS message must have valid T24 credentials, and everything that user can and cannot do in the Browser, they can and cannot do through OFS.

This has a practical implication: if an integration starts failing with authentication or authorisation errors, the first check is not the OFS configuration — it is the T24 user profile. Expired passwords, locked users, changed security profiles, and SMS definition changes all affect OFS connections without touching OFS itself.

You can also lock a specific T24 application out of OFS entirely by adding NOFS to the ADDITIONAL.INFO field in the application's PGM.FILE record. This is a system-level control used sparingly, but worth knowing exists when debugging unexpected rejections.

What goes wrong and how to diagnose it

OFS failures fall into a small number of categories. Identifying which one you are dealing with is faster than reading every error message in full.

Authentication failure

The user/password component is wrong, the user is locked, or the password has expired. Check the T24 user record before touching anything in OFS.

Source not found or misconfigured

The OFS.SOURCE name in the message does not match any configured record, or the record exists but is missing required fields. The message is rejected before T24 even looks at the data section.

Application-level error

The OFS message reached T24, the user authenticated, and the application processed the request — but it returned an error. This shows up in the response. Read the error code and the error text. This is the same error you would see if you entered the same data manually in Browser.

Malformed message

Wrong number of commas, wrong field notation, wrong syntax. T24 cannot parse the message and rejects it. Compare the failing message against a known working example field by field.

Duplicate message

If a message ID is used and T24 has already processed a message with that ID, it is rejected as a duplicate. This protects against double-processing but can confuse retry logic in external systems that do not rotate message IDs correctly.

For detailed logging, enable FULL logging on the relevant OFS.SOURCE temporarily and check OFS.REQUEST.DETAIL. Every message in and out will be recorded there. Turn it off again afterwards.