OFS in T24: Message Format, Examples & How It Works

OFS messages look like structured chaos until you understand the pattern. Once you separate the message into operation, options, sign-on context, ID information, and data, an OFS string becomes much easier to read and troubleshoot.

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

Treat examples on this page as synthetic learning material. Exact syntax, option semantics, source/channel behaviour, and security requirements can vary by release, operation, and local configuration.

What OFS actually is

OFS — Open Financial Services — is the message interface used by many external systems and channels to communicate with Temenos Transact. It describes what the request contains and how T24 should interpret it; it is separate from the transport that carries the message.

That distinction matters in production support. MQ, sockets, APIs, gateways, and other middleware can move an OFS message, but a transport failure and an OFS application failure are different problems. First prove whether the request reached the OFS/application processing path, then diagnose the earliest stage that failed.

Think of connectivity as the delivery mechanism and OFS as the message language.

What OFS can do

OFS supports several request families. The exact forms available depend on the environment, but support teams most often need to distinguish transactions from enquiries because their operation and data sections mean different things.

If you are debugging an unfamiliar OFS message, identify the request family first. That prevents the common mistake of treating the fourth comma-delimited section as a universal source or record-ID field.

The message structure

A common OFS request can be read as five comma-delimited sections:

OPERATION, OPTIONS, USER/PASSWORD[/COMPANY], ID INFORMATION, DATA

Operation

For transactions this is commonly the application name, such asSECTOR, FUNDS.TRANSFER, orAA.ARRANGEMENT.ACTIVITY. Enquiries use ENQUIRY.SELECT.

Options

Options can include version, function, and processing behaviour. Do not assume that one example is valid for every request family or release.

VERSION/FUNCTION/PROCESSING_FLAG

OFS.DEMO/I/PROCESS
OFS.DEMO/I/VALIDATE

User / sign-on context

OFS processing is subject to the security context configured for the channel and request. Never use real credentials in examples or external troubleshooting notes.

Source and ID context

OFS.SOURCE is configuration for a source/channel in environments that use it that way; it is not a label that belongs in the fourth section of every OFS string. The fourth section is operation-specific ID information and can be a record key, transaction reference, enquiry context, or blank.

Data

Transaction data commonly uses T24 field and multi-value notation. The exact field set is application/version-specific.

FIELDNAME:MULTIVAL:SUBVAL=VALUE

ORIGINAL.TEXT=SECTOR
APPLICATION:1:=SECTOR
DESCRIPT:1:2=Industrie

Multiple fields are separated by commas. A missing or extra separator can shift the meaning of every section that follows, so structure validation should happen before you diagnose business rules.

A transaction request in full

Here is a synthetic AA arrangement request:

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

Read it left to right:

• AA.ARRANGEMENT.ACTIVITY — operation/application
• OFS/I/PROCESS — options for this synthetic example
• INPUTT/123456 — synthetic sign-on context
• blank ID-information section — intentional for this example only
• the remaining comma-delimited values are the request data

The blank fourth section does not prove that every create operation leaves ID information blank. It demonstrates why the comma position itself matters and why operation-specific syntax must be confirmed locally.

Enquiry requests

Enquiry requests use a different intent from transaction entry. A synthetic pattern can look like this:

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

Here CURRENCY-LIST is enquiry-specific context in the fourth section, illustrating again why that position is not universally a source or transaction record ID. Selection criteria live in the data portion and use enquiry-specific syntax supported by the target enquiry/release.

If an enquiry request fails, separate these questions: did the request parse, did the sign-on context authenticate, does the enquiry exist, can that user access it, and did the selection criteria validate?

VALIDATE mode — useful, but verify the target behaviour

Where the target transaction operation and release support the expected VALIDATE semantics, VALIDATE can be used to run validation/defaulting logic without committing the transaction. That makes it useful for controlled testing before PROCESS.

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

Do not assume that every operation, version, channel, or release returns identical data or executes identical logic in VALIDATE. Confirm the behaviour in an approved non-production path before using it as a production-safety assumption.

OFS.SOURCE — source and channel configuration

Many OFS implementations have source/channel configuration that controls how a connection is identified, logged, or processed. In environments that useOFS.SOURCE, treat it as configuration, not as a universal fourth field inside every OFS message.

When a previously working integration stops, check the source/channel layer only after you know the transport reached the OFS entry point. Useful questions include:

• Is the expected source/channel configuration present and active?
• Does the failing connection resolve to the configuration you think it does?
• Did authentication, company, service, or interface configuration change?
• Is logging sufficient to prove whether the request reached application processing?

Field names and settings vary by release/configuration, so use local documentation and environment evidence rather than copying a setting from another bank or release.

Security — separate authentication from application authorisation

OFS requests execute within a security context. A request can fail before application processing because sign-on/authentication is invalid, or later because the user is not authorised for the requested application/function.

For diagnosis, establish the earliest failing stage. Check whether the identity is valid and active, whether the channel/company context is correct, and whether the user is authorised for the target operation. Do not put production passwords, tokens, account identifiers, or copied sensitive messages into public tools or troubleshooting notes.

Some environments also use application-level controls that restrict OFS access. Those controls are release/configuration-specific; verify them locally instead of relying on a universal field or flag.

What goes wrong and how to diagnose it

The quickest way to diagnose OFS is by failure stage rather than by memorising error strings.

If you need to trace one failing request across TAFJ/JBoss evidence, continue with the failed OFS request tracing guide.

Common OFS terms explained

OFS message / OFS string / OFS format

These phrases usually refer to the same practical object: the structured OFS request string and the rules used to interpret its comma-delimited sections. Use the term that helps the reader, but keep the underlying section semantics precise.

OFS request vs OFS response

The request is what the caller sends. The response is what T24 returns. A timeout does not prove that no processing occurred, so retry decisions must be based on outcome evidence rather than response absence alone.

OFS.SOURCE

This is source/channel configuration in environments that use it that way. It is not a universal label for the fourth comma-delimited section of every message.

Frequently asked questions about OFS in T24

What is OFS in T24?

OFS is the message interface used by many external systems and channels to communicate with Temenos Transact. It defines request/response structure separately from the transport carrying the message.

What is the OFS message structure?

A common request uses OPERATION, OPTIONS, USER/sign-on context, operation-specific ID information, and DATA. The fourth section is not universally a source field.

What is VALIDATE mode in OFS?

Where the target operation/release supports it, VALIDATE can perform validation and defaulting without committing. Confirm behaviour in the target environment.

Further reading and tools

• OFS message quick reference — compact structure, tool-choice, and troubleshooting checklist
• OFS Generator — build synthetic OFS requests
• OFS Message Parser — inspect an existing request
• OFS Error Decoder — classify a short error fragment
• OFS Response Parser — inspect a complete response
• OFS vs API vs Batch Interfaces — compare integration patterns
• MQ Patterns with T24 — OFS over messaging transports