24Last printed 3/26/2009 7:41:00 PM

TEMENOS T24
Funds Transfer

User Guide

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Funds Transfer

Table of Contents
Overview.................................................................................................................................................. 4
Customer Payments ............................................................................................................................ 5
Currency Conversion ........................................................................................................................... 5
Rounding .............................................................................................................................................. 6
Architecture/Design ................................................................................................................................. 7
Application Default Table ..................................................................................................................... 7
FT.TXN.TYPE.CONDITION ............................................................................................................... 10
Deal/Transaction Processing ................................................................................................................ 17
Payment Types .................................................................................................................................. 17
Outward Payment Instructions ....................................................................................................... 17
Inward Payment Instructions .......................................................................................................... 21
Internal Payment Instructions ......................................................................................................... 23
Set up .................................................................................................................................................... 26
Duplicate Contract Checking ............................................................................................................. 26
Swift ID for Bank Fields...................................................................................................................... 29
Sender to Receiver Information Tag 72 ............................................................................................. 30
Rate Fixing ......................................................................................................................................... 30
RATE.FIXING in Browser ............................................................................................................... 32
MT103TYPE ...................................................................................................................................... 36
Cover Methods................................................................................................................................... 37
Recording card details ....................................................................................................................... 38
Agency ............................................................................................................................................... 38
Beneficiary details .............................................................................................................................. 39
AUTO.ID.START................................................................................................................................ 42
AC.EXPECTED.RECS....................................................................................................................... 43
FT.BULK.CREDIT .............................................................................................................................. 43
Charges and Commissions ................................................................................................................... 46
Receiver correspondent bank charges (MT103) - OUTWARD ......................................................... 46
Example for defaulting Receiver Charges for Outward Transaction (MT103): - ............................ 47
Example for defaulting of Sender Charges for Outward Transaction (“OTXX”): - ......................... 50
Receiver correspondent bank charges (MT103) – INWARD............................................................. 52
CUSTOMER.CHARGE ...................................................................................................................... 56
FT.GEN.CONDITION ..................................................................................................................... 56
FT.GROUP.CONDITION................................................................................................................ 57
Inward Delivery ...................................................................................................................................... 58
Incoming Messages ........................................................................................................................... 58

TEMENOS T24 User Guide Page 2 of 117

Funds Transfer

FT.OFS.INWARD.MAPPING ......................................................................................................... 58
Inward SWIFT Funds Transfer Messages using OFS.GLOBUS.MANAGER ................................ 66
Multiple Messages.......................................................................................................................... 70
Awaiting Cover Payment ................................................................................................................ 71
Inward Processing of MT102 ......................................................................................................... 74
Bypass the processing of inward messages...................................................................................... 80
Outward Delivery ................................................................................................................................... 85
Assigning SWIFT Message Types to FT Transactions ..................................................................... 85
MT103 Single Customer Credit Transfer ....................................................................................... 86
Generation of MT102 - Multiple Customer Credit Transfer ............................................................ 86
Automatic MT110 Advice of Cheque(s) ......................................................................................... 96
Automatic MT400 Advice of Payment ............................................................................................ 96
Generation of MT203 -Multiple general Financial Institution Transfer ........................................... 96
Interfaces ............................................................................................................................................. 104
Delivery ............................................................................................................................................ 104
Accounting ....................................................................................................................................... 105
Local Clearing .................................................................................................................................. 105
BULK CREDIT / DEBIT.................................................................................................................... 106

TEMENOS T24 User Guide Page 3 of 117

Funds Transfer

Overview
FUNDS.TRANSFER (FT) is the part of T24 used to effect payments, either internally from one
ACCOUNT to another, or externally to another bank. The STANDING.ORDER application also
belongs to the FT module, and their operations are explained here.

FT handles internal and external funds movements:

• Customer payments
• Banks own payments
• Incoming
• Outgoing
• Internal

It is integrated with:

• Accounting
• Central liability
• Delivery (Outgoing)
• Delivery (Incoming)
• Position management

Real time updates are applied to:

• Balances
• Positions
• Cash flows
• Limits

Charges and commissions can be taken based on a variety of conditions or input directly.

Standing payments are effected during overnight processing

Screen VERSION records are often used to make this general application specific to particular
business requirements.

TEMENOS T24 User Guide Page 4 of 117

Funds Transfer

Customer Payments
Payments may be made to or from a client account or an internal account. Funds may be transferred
to beneficiaries at other banks via agents or correspondents.

Types of payment:

• Mail payment
• Cheques
• Bankers draft
• Clearing house payment
• Telex
• Local clearing
• Standing orders
• Bulk
• Regular dates
• Sweep account balances
• Between branches (with inter-company transfer)
• Within a branch
• Between banks via local clearing
• Cheques to be sent to beneficiary or their bank
• International payments via correspondents
• Local currency
• Foreign currency
• Foreign currency with conversion

Currency Conversion
Transfers may include conversion of currency between the debit and credit accounts. Large amounts
are usually dealt with as FOREX deals. FT is more likely to be used for banking services and trade
settlement rather than FX trading. Nevertheless, accounting and position management are updated in
the same way by these applications.

Rates for conversion are obtained from the CURRENCY table, which by default allows for a buy/sell
spread. The spread may vary according to the amount of the transfer and by any splitting of the
spread between the treasury and the service departments.

The exchange rates for foreign currencies can be input either in the TRESURY.RATE field, which will
add/deduct the customer spread and default the final rate in CUSTOMER.RATE or final rate, can be
specified directly in CUSTOMER.RATE.

TEMENOS T24 User Guide Page 5 of 117

Funds Transfer

The user should consider the rules relating to the default values of spread by looking at the FT
Application. The rules of default spread are summarised as:

• The CURRENCY table allows the user to define different treasury and customer exchange
spreads according to the amount of the transaction. The customer spreads from this table will be
used throughout the FT application when no other special spread conditions have been afforded
to the customer of the transaction.
• The user can define different spread conditions for groups of customers by use of the
GROUP.CONDITION table. The user can enhance this table so that special conditions for
particular groups of customers can be recorded (as Banks, Staff, Prime Customers, etc.).
• Default spread conditions can also be defined at the customer level by means of an individual
customer record on the GROUP.CONDITION table. The user will create entries on this table
when a particular customer receives special conditions.
• The default spread as calculated above is recalculated with the difference between treasury rate
and Customer Rate, when CUSTOMER.RATE is entered directly. In such cases, customer spread
can be positive or negative based on the difference between customer rate and treasury rate.

When spread is negative then market exchange profit will show a negative amount implying the loss.

Any input by the user will supersede the applicable default conditions. Any direct input will be
subjected to certain range checks.

Where the processing date of the transfer is in the future, the rates for conversion may be input by the
user, defaulted at input time or defaulted at processing time i.e. at the value date of the transfer.

Limits may be set on the CURRENCY record so that the Services Department has to refer to the
Treasury Department for a currency rate on large amounts.

Rounding

In the Funds Transfer application, when a debit or credit currency is a foreign currency and treasury
rate or default buy/sell rate is used to convert it into local currency a rounding rule can be applied, the
default in T24 is natural.

However, the field ROUND.TYPE in FT.APPL.DEFAULT and in the record can be used to setup
new rounding rules. The rounding rule will first need to be set up in the application EB.ROUNDING
and is then input into ROUND.TYPE.

NB: A rounding rule entered into a funds transfer contract will override the FT.APPL.DEFAULT

TEMENOS T24 User Guide Page 6 of 117

Funds Transfer

Architecture/Design
Application Default Table
The FT.APPL.DEFAULT table contains application level default values, which will be used when
processing FUNDS.TRANSFER or STANDING.ORDER instructions. These defaults will be
applicable irrespective of the transaction type, and the user must create one record for each
COMPANY on the system. The default values defined in this table can be summarised as follows:
• Limit Amounts
The field AUTO.PROCESS.LIMIT defines the amount, in local currency below which incoming
transactions, received direct from Delivery can be processed automatically
The field LESS.CHARGES.LIMIT Defines the amount, in local currency, below which instructions
for outgoing payments should not be accepted to pay on a Less Charges basis, e.g. where
Charges would exceed the amount of the payment.

Example FT.APPL.DEFAULT

The field MIN.STO.AMT defines a Minimum transfer Amount below which balance maintenance
instructions will not be processed.

MIN.STO.AMT field FT.APPL.DEFAULT

TEMENOS T24 User Guide Page 7 of 117

Funds Transfer

• Suspense Accounts
CLAIM.CHARGES.ACCT field is the ACCOUNT to be debited when charges are to be claimed
from the ordering bank.

SECONDARY.TLX.CHG field FT.APPL.DEFAULT

• General Information
The field SECONDARY.TLX.CHG telex charge to be applied for cover and free format telex
messages. The field CENTRALISED.FT defines whether or not the Funds Transfer function in
the bank is centralised in one department.

• Commission/Charge on Error
When FT’s are input with commission/charge related fields and any error encountered while
committing, all the commission/charges related fields are nullified and once again need to be input
or defaulted from FTTC.
For example;
An OT TXN.TYPE is input with commission and charges but without mandatory beneficiary details.
Because of this system clears the commission/charge field details after raising error “Input
Missing” and defaults again from the FTTC. To retain the commission/charges input even after
encountering an error, the CHG.COM.ON.ERR field can be specified as “RETAIN” in
FT.APPL.DEFAULT or Null to clear the fields (existing functionality).

TEMENOS T24 User Guide Page 8 of 117

Funds Transfer

Field CHG.COMM.ON.ERR FT.APPL.DEFAULT

• Currency Fixing Rates

For currencies where the exchange rate is fixed daily and the exchange rate needs to be taken
based on the fixing date, then RATE.FIXING needs to be mentioned as “YES” and the same will
be defaulted in FT. The defaulted value can be modified in FT during input. The DEALER.DESK
field in FT.APPL.DEFAULT is mandatory if the RATE.FIXING flag is “YES”. This functionality
is explained in the rate fixing section.

RATE.FIXING field set to Yes

• MT103 CONTROL
SWIFT message MT103+ which is straight through processed can be generated through FT by
giving MT103.TYPE as MT103+ and all bank related fields ACCT.WITH.BANK, RECEIVER.BANK,
REC.CORR.BANK, INTERMED.BANK (Tag 52,54,55,56 & 57) with either customer number who
has a valid record in DE.ADDRESS for carrier as “SWIFT” or a valid BIC code prefixed with “SW-
“along with the BEN.ACCT.NO. When the above case is not satisfied, the system raises an error if
the MT103.CONTROL is specified as “SYSTEM”. When MT103.CONTROL is NULL it generates an
MT103 instead of an MT103+ with an override.

TEMENOS T24 User Guide Page 9 of 117

Funds Transfer

FT.APPL.DEFAULE MT103

• Default of Receiver Bank Charges

To default receiver charges for outgoing / incoming MT103 messages based on the
CORR.BANK.CHARGES application in FT, field DEF.CORR.BANK.CHGS can be set to “YES”.

FT.TXN.TYPE.CONDITION
This table defines the default conditions for each transaction type, which can be processed by the
FUNDS.TRANSFER and STANDING.ORDER applications. These can be summarised as follows:
• The TRANSACTION codes to be used, for the generation of the entries. Both Debit and
Credit transaction codes will be defined for basic entries, standing orders, debit charges and
cheques.
• The default commission types applicable for each transaction type. These commission types
must first have been defined in FT.COMMISSION.TYPE.
• The default charge types applicable for each transaction type. These charge types must have
been previously created in the FT.CHARGE.TYPE.
• The maximum forward and back value dates applicable for each transaction type must be
specified and any excess beyond these value dates will force an override at the transaction
level.
• The default value date conditions may be held for each transaction type. The condition for
both debit and credit entries are catered for, i.e. the user can specify for each transaction type,
the value date conditions applicable to the bank and to the customer.

The default value date conditions could also be held on the BC.SORT.CODE file. This condition will
default the value date on the credit side if the sort code field has been specified. The value date
default from here will override the one from the TRANSACTION record.

TEMENOS T24 User Guide Page 10 of 117

Funds Transfer

Default value dates can also be generated by use of CUT.OFF.TIME on the CURRENCY file and
CUT.OFF.RULE on the AGENCY file. The default debit value date, for outgoing funds transfers, and
the default credit value date for incoming funds transfers can be calculated by comparing the
transaction entry time with the cut off time specified for the currency (debit currency for outgoing,
credit currency for incoming). In the case of an outgoing funds transfer, for this method to be applied,
the CUT.OFF.RULE field on the AGENCY file must be set to either 0 or 1. For an incoming funds
transfer the debit value date, date of receipt of the transaction and the debit and credit currencies will
be taken into account when deriving the default credit value date.

Using CUT.OFF.TIME and CUT.OFF.RULE the default debit value date on outgoing FT transactions
is derived as follows:
• If the transaction is entered before the time specified in CUT.OFF.TIME (for the debit
currency) and CUT.OFF.RULE is set to 0, then the debit value date will be that working day, if
CUT.OFF.RULE is set to1, then the debit value date will be next working day.
• If the transaction is entered after the time specified in CUT.OFF.TIME (for the debit currency)
and CUT.OFF.RULE is set to 0, then the debit value date will be the next working day. If
CUT.OFF.RULE is set to 1, then the debit value date will be the next working day +1 working
day.
• If neither the debit or credit value date have been entered on an outgoing funds transfer and
the default debit value date is after the default credit value date then the credit value date will
be set to the default debit value date.

Using CUT.OFF.TIME the default credit value date on incoming funds transfer transactions is derived
as shown in the following table:

Debit Value Date Cut off time Debit/credit currency Credit value date default

Debit value date prior or Time of receipt prior or Debit currency equal Credit value date equal date
equal to date of receipt equal to cut off time credit currency of receipt

As above As above Debit currency not Credit value date equal date
equal to credit currency of receipt +1 working day

As above Time of receipt after cut Debit currency equal Credit value date equal date
off time credit currency of receipt +1 working day

As above As above Debit currency not Credit value date equal date
equal credit currency of receipt +2 working days

Debit value date after day Time of receipt prior or Debit currency equal Credit value date equal debit
of receipt equal to cut off time credit currency value date

As above As above Debit currency not Credit value date equal debit
equal to credit currency value date +1 working day

As above Time of receipt after cut Debit currency equal Credit value date equal debit
off time credit currency value date +1 working day

As above As above Debit currency not Credit value date equal debit
equal credit currency value date +2 working days

TEMENOS T24 User Guide Page 11 of 117

Funds Transfer

For forward transfers, whether the transfer will have the currency rate defaulted at input time or at
processing time.

T24 will automatically produce a variety of outgoing SWIFT messages via the DELIVERY Module
and FT. For OT transactions it is possible to produce either an MT103 or MT400. For OC and OD
transactions it is now possible to produce an MT110 advice. To allow one of these message types to
be used an alternative, the field MESSAGE.TYPE in the relevant FT.TXN.TYPE.CONDITION record
should be input.

For OT transactions it is possible to produce either an MT103 or MT400

SWIFT ID (BIC code) prefixed by "SW-" can be entered for the Bank fields for FT and Standing Orders.
To allow BIC codes to be used, the relevant FT.TXN.TYPE.CONDITION record must have the
SWIFT.ADDRESS field set to ‘YES’. In the screenshot below, a BIC code is being used in field
ACCT.WITH.BANK.

TEMENOS T24 User Guide Page 12 of 117

Funds Transfer

Swift. Address set to ‘Yes’ to accept “SW-“ in Bank fields

TEMENOS T24 User Guide Page 13 of 117

Funds Transfer

Account With Bank entered in FT with “SW”

TEMENOS T24 User Guide Page 14 of 117

Funds Transfer

Funds transfer with the debit after the credit value dates for transaction type “AC” can be entered. The
fields DB.AFTER.CR and DB.A.CR.MAX.DAYS on the FT.TXN.TYPE.CONDITION are available to
control this. The DB.AFTER.CR can be set to “YES” for transaction type “AC” (and those with the first
2 characters as AC) and DB.A.CR.MAX.DAYS defines the maximum number of days the debit value
date may be after the credit value date.

DB.AFTER.CR set to ‘YES’ & DB.A.CR.MAX.DAYS

TEMENOS T24 User Guide Page 15 of 117

Funds Transfer

From IT type of funds transfer, it is possible to generate the receipt of funds record in the
AC.EXPECTED.RECS. This is controlled using the field EXPECTED.RECS on the
FT.TXN.TYPE.CONDITION. This field should be set to ‘YES’ for selecting and creating the
AC.EXPECTED.RECS for the qualifying accounts (Applicable only for “ER”/”EP” funds type).

Setting for Expected Receipts

FT contracts, which are in live, can be reversed online using reversal function. Live FT contracts are
moved into history after running the Close of Business. To control the reversal of FT contracts, which
are in history, the field HIS.REVERSAL in FT.TXN.TYPE.CONDITION should be set to “YES”.

To process the receiver charges in the incoming MT103, new field IN.CHG.CODE can be defined
here with an FT.CHARGE.CODE record.

TEMENOS T24 User Guide Page 16 of 117

Funds Transfer

History reversal flag and Incoming Charge code for MT103

A transaction type from FT.TXN.TYPE.CONDITION identifies the type applicable to the transaction
being processed. There are two basic types, outward and inward (outward includes onwards). The
FUNDS.TRANSFER module processes the following transaction types:

Deal/Transaction Processing
Payment Types
Outward Payment Instructions
These are transactions where the beneficiary of the payment does not maintain an appropriate
account relationship and where usually the Bank will credit a Nostro account (foreign currency
payment) or a clearing/nostro account (local currency payment) to execute the payment.

Within T24 Outward Payment, orders are classified as follows:

TEMENOS T24 User Guide Page 17 of 117

Funds Transfer

Type Usage Details

OC Outward by Refers to the issuance by the bank of a Manager cheque
Cheque or a Bank cheque in local currency in favour of the
beneficiary who does not maintain an account with the
bank
OD Outward by Draft Refers to the issuance by the bank of a Bank Draft (usually
in foreign currency) in favour of the beneficiary who does
not maintain an account with the bank
OT Outward by Refers to the issuance by the bank of a payment via Swift
Telex or Telex. The instructions are usually sent to the Banks
correspondent. Use of this transaction type will produce
both pay and cover cables automatically where required.
OB Outward by Refers to the issuance by the bank of a bankers payment
bankers payment in local currency. This method of payment is used
extensively in the UK to perform local currency payments

BC Outward by Bacs This transaction type is only applicable for Sterling and
within the UK and refers to outward transfers by BACS
(bankers automatic Clearing System). Currently no BACS
payments are generated by the system. If this is required,
it must be added as a local enhancement. Other host
countries may have similar systems to which this may be
adapted.
OT03 SWIFT MT103
payment
OT40 SWIFT MT400
payment

T24 Outward Payment Orders

In the screenshot below we have a draft being issued to the ‘Inland Revenue’ in USD with the cost
including charges being made to the client. The VERSION record shown is tailored just for the issue
of drafts. The charges applied to the transaction are input using the ‘charges’ tab on the VERSION,
as shown in the second screenshot.

TEMENOS T24 User Guide Page 18 of 117

Funds Transfer

Issue draft or cheque screen and Issue Transfer of Charges Screen

TEMENOS T24 User Guide Page 19 of 117

Funds Transfer

Outward Swift/Telex Screen using version FUNDS.TRANSFER,OTC

A further example of an outward payment is the funding between two Nostros, a very simple
VERSION for a dealer to action quickly and efficiently.

TEMENOS T24 User Guide Page 20 of 117

Funds Transfer

Outward Payment – Nostro Transfer Screen

Alternative messages for OT transactions

For OT transactions it is possible to send an MT202 instead of the normal MT103 when the debit
account belongs to a client rather than a bank, and both ORDERING.BANK and BENEFICIARY.BANK
are present in the transaction. Setting the BANK.PAYMENT field on the OT record on the
FT.TXN.TYPE.CONDITION file to Y can enable this option.

Inward Payment Instructions

These are transactions where the beneficiary of the payment is one of our customers who require the
funds to be credited to an account in our books. The inward payments are classified as follows:

Type Usage Details

IC Inward payment Refers to the receipt by the bank of a cheque or a draft
by cheque or to be credited to a customer account in our books
draft
IT Inward by Telex Refers to the receipt by the bank of a Swift or Telex
payment in favour of one of our customers and where
the proceeds have to be credited to an account in our
books.

TEMENOS T24 User Guide Page 21 of 117

Funds Transfer

IM Inward by mail Refers to the receipt by the bank of a mail transfer

transfer payment in favour of one of our customers and where
the proceeds have to be credited to an account in our
books.
IB Inward by Refers to the receipt by the bank of a Bankers payment
bankers in favour of an account in our books (UK only)
payment
BI Inward by local
clearing
BD Inward direct
debit by local

Inward Payment Instructions

FT can be used to process an incoming cheque, though for larger volumes either DATA.CAPTURE
or the local clearing can be used.

Incoming Cheque Collection Screen

Incoming payments by Telex or SWIFT are processed in FT quite easily.

TEMENOS T24 User Guide Page 22 of 117

Funds Transfer

Incoming SWIFT/Telex Payment Screen

Internal Payment Instructions

Two additional transaction types are covered within the FUNDS.TRANSFER Module:

Type Usage Details

AC Account transfer Refers to an in house transfer of funds, i.e. a transfer of
funds between two customer accounts or two internal
accounts in our books.
DW Direct drawing This transaction type is similar to account transfers,
however it usually refers to transfers from one account
to another by correspondent banks who maintain
accounts within our books.

Internal Payment Instructions

Shown in the screenshot below is a simple ACCOUNT transfer.

TEMENOS T24 User Guide Page 23 of 117

Funds Transfer

Account Transfer Screen

The following table provides a high level indication of the various account type combinations, which
are permitted within a FUNDS.TRANSFER per transaction type.

Outward/Onward Products AC DW OB OC OD OT BC
NOSTRO CREDIT
DEBIT
BOTH

VOSTRO CREDIT X
DEBIT
BOTH X

PROFIT CREDIT X X X X X X
& DEBIT X
LOSS BOTH X

INTERNAL CREDIT X X

TEMENOS T24 User Guide Page 24 of 117

Funds Transfer

DEBIT
BOTH

CUSTOMER CREDIT X X X X X
DEBIT
BOTH

PROV CREDIT X X X X
RATE DEBIT X X X X X X
BOTH

Within T24 inward payment, orders are classified as follows:

Inward Products IB IC IM IT
NOSTRO CREDIT
DEBIT
BOTH

VOSTRO CREDIT
DEBIT
BOTH

PROFIT CREDIT
& DEBIT X X X X
LOSS BOTH

INTERNAL CREDIT
DEBIT
BOTH

CUSTOMER CREDIT
DEBIT X X X X
BOTH

TEMENOS T24 User Guide Page 25 of 117

Funds Transfer

Set up
Duplicate Contract Checking
There is a facility that enables the user to check for the occurrence of any FT duplicate contract types.

The type of duplicate contract to check for has to be defined on the EB.DUPLICATE.TYPE file. This
file acts as a parameter file, to allow for the definition of selected fields to check against within a given
application, for the occurrence of any duplicate contracts.

The FT application should first be defined on the APPLICATION field of the EB.DUPLICATE.TYPE
file. A specific field or fields from the FT STANDARD.SELECTION record can then be input to fields.
T24 will then check for the occurrence of any duplicate contracts against the fields defined.

It is up to the user to decide upon the level of duplicate checking that they wish to perform. For
example, the user may wish to check for the occurrence of any duplicate contracts, using just one field
from the FT application.

Duplicate Contract Checking

It is recommended that several fields from FT be specified, in combination since having insufficient
search criteria could result in similar contracts being listed as duplicates. See the screenshot below.

TEMENOS T24 User Guide Page 26 of 117

Funds Transfer

Set Credit/Debit fields as search criteria

Once a record is created, the EB.DUPLICATE.TYPE record id should be added to the

DUPLICATE.CHECK field on the FT.TXN.TYPE.CONDITION file. An example of this is shown in
the screenshot below.

TEMENOS T24 User Guide Page 27 of 117

Funds Transfer

Add the EB.DUPLICATE.TYPE record id to the DUPLICATE.CHECK field

For each funds transfer record, a record will be written to EB.DUPLICATE for each
DUPLICATE.CHECK defined on the EB.DUPLICATE.TYPE record. If the key of the record already
exists on EB.DUPLICATE then an override message indicating a possible duplicate will be
displayed.

If a possible duplicate is committed, then its key is added to the EB.DUPLICATE record concerned.

The purge date is calculated as the current date plus the number of PURGE.DAYS.

TEMENOS T24 User Guide Page 28 of 117

Funds Transfer

Duplicate contracts are held on the EB.DUPLICATE file

The key fields may set up as calculated results by using setting field USR.TYPE “I” via
STANDARD.SELECTION.

Swift ID for Bank Fields

There is the option of entering the SWIFT Id (BIC code) instead of entering the customer number,
reducing the overhead of looking up the customer number when only the SWIFT Id is known.

If the SWIFT.ADDRESS field in the FT.TXN.TYPE.CONDITION is set to Y then the user can input
the SWIFT Address prefixed by SW- in the following bank fields in an FT transaction:

• ORDERING.BANK
• ACCT.WITH.BANK
• BEN.BANK
• REC.CORR.BANK
• INTERMED.BANK

In the FT application the facility is there to enter the Account Number of the above bank fields, which
will get prefixed with the concerned bank fields and generate the appropriate tags in SWIFT message.

Acct Numbers in Bank field can be given

TEMENOS T24 User Guide Page 29 of 117

Funds Transfer

Sender to Receiver Information Tag 72

In SWIFT messages, additional information (Tag 72) can be given to the receiver or any party. In FT,
additional information for Tag 72 can be given in BK.TO.BK.OUT along with SEND.TO.PARTY.
Therefore bank-to-bank information can be sent to a different send to party. For example,
SEND.TO.PARTY is specified as CRCUST and DRCUST along with different BK-TO-BK information,
(i.e. One for debit customer and other for credit customer). Then the SWIFT messages-MT900 for
debit customer and MT910 for credit customer will get generated with additional information (Tag 72)
as specified for the respective send to party. The same facility is available in STANDING.ORDER.

Input of Additional Information (Tag 72) and Time Indication (Tag 13C) in FT

The time indication (Tag 13C) for SWIFT message supported in FT can be specified as per the above
screenshot in TIME.IND for a PAYMENT or COVER message in RELATED.MSG, and the same will
be used while generating the appropriate message.

Rate Fixing
When an exchange rate for a currency is not fixed in the CURRENCY application (FIXING.DATE is
less than FT’s PROCESSING.DATE) and the FT contract is processed requiring that currency as debit
account currency or credit account currency and the other side (Dr/Cr) account currency is local
currency then system raises override “RATE NOT FIXED – USE EXISTING RATES”. The response to
this override can be as “YES” to use the available exchange rates or “NO” to wait till the exchange
rates for the day is available.

When response to the override is “No” then system creates FT with ANORATE status and waits for
the exchange rate to be fixed for the day or when response is “YES” using existing rates creates
accounting, position and delivery messages. In case fixing is already done (FIXING.DATE is equal to
FT PROCESSING.DATE) FT will be created using the available rates since rates are available
(Existing functionality).

To process FT’s based on fixing date; RATE.FIXING flag in FT.APPL.DEFAULT can be set to
“YES”.

TEMENOS T24 User Guide Page 30 of 117

Funds Transfer

RATE.FIXING flag defaulted from FT.APPL.DEFAULT to FUNDS.TRANSFER and can be

changed from “YES” to “No” but not vice versa.

Based on RATE.FIXING flag, FT is processed as per following:

Case 1:

Rates for the day are not available (FIXING.DATE in Currency application is less than processing
date) and FT can be processed only after getting that day rates.

If the RATE.FIXING flag is s “YES” in FUNDS.TRANSFER application then FT will be created with
status as ANORATE/INORATE (based on FT Record status). However customer account balance is
checked and position entries updated with Dealer Desk as given in FT.APPL.DEFAULT.

Once the rate is fixed for the day and by running FT.RATES online, accounting entries, position and
delivery messages are generated using current exchange rate and dealer desk as given in FT.
POSITION entry created with FT.APPL.DEFAULT dealer desk gets reversed.

Case 2:

When exchange rates already fixed for the day (FIXING.DATE in CURRENCY application is equal to
FT processing date) and subsequent FT needs to be processed based on next working day rates.

If the RATE.FIXING flag is “YES” in FUNDS.TRANSFER; an FT will be created with processing date
as next working date and with status as AFWD/IFWD (Based on FT Record status). No live
accounting entries, position and delivery messages are generated.

Next day once the rate fixed for the day by running FT.RATES online-accounting entries, position and
delivery messages are generated using latest exchange rate. (Like Case 1)

In all other cases FT will be created as per existing functionality.

FT records created through OFS will be using existing exchange rates even when the rate is not fixed
for the day.

To create FT’s with ANORATE Status when the rates not fixed for the day, incoming OFS message
needs to be supplied with RATE.FIXING as “YES” and AUTO.EXCH.RATE.IN as “AWAIT”.

TEMENOS T24 User Guide Page 31 of 117

Funds Transfer

FT with RATE.FIXING as “YES” & STATUS as ANORATE

RATE.FIXING in Browser

The T24 Browser allows online processing for rate fixing. During input, if the field RATE.FIXING is
set to ‘NO’ an override “RATE NOT FIXED, USE EXISTING RATE” will be raised to confirm whether
existing rates can be used or should the user wait for new rates, with the option “Y/N”. At committal
the User is prompted via an override message to complete the field RATE.FIXING.IND with ‘Y’ to
accept the current rates, and ‘N’ to wait the rate fixing.

TEMENOS T24 User Guide Page 32 of 117

Funds Transfer

FT with RATE.FIXING set to ‘No’

Example FT with override

TEMENOS T24 User Guide Page 33 of 117

Funds Transfer

During online input, if the field RATE.FIXING is set to NO, an override ‘RATE NOT FIXED, USE
EXISTING RATE’ will be raised to confirm whether existing rates can be used or should the user wait
for new rates, with the option Y/N.

If ‘Y’ is chosen the existing rates are used.

If ‘N’ is chosen, the override is therefore not accepted the field STATUS in the contract is set to
‘INORATE’.

Example contract with STATUS set to INORATE

Once the contract is authorised the STATUS field is updated to ‘ANORATE’.

TEMENOS T24 User Guide Page 34 of 117

Funds Transfer

Example contract with STATUS set to ANORATE

The record ID will be written into the file FT.NORATE and at this stage no entries will be passed.

Once the rate has been agreed, start the TSA.SERVICE FT.RATES.FIXING.PROCESS, the rates will
be populated in the FT transaction and the system will remove ANORATE from the STATUS field in
the contract and the entries will now be generated.

TSA.SERVICE BNK/FT.RATES.FIXING.PROCESS

TEMENOS T24 User Guide Page 35 of 117

Funds Transfer

STATUS ANORATE has been removed from contract

MT103TYPE

From the FT application in addition to the MT103, the following 103 sub-types can be created using
MT103.TYPE in FT.

MT103+ - with Bank field tags (52, 54, 55, 56, 57) as “xxA” along with BEN.ACCT.NO for straight
through processing.

MT103 EXTEND- with Tag 77T (Envelope contents).

In case MT103.TYPE is MT103Extend then EXTEND.INFO in FT is mandatory and details entered in

EXTEND.INFO along with the EXTEND.FORMAT is mapped to tag 77T of MT103. In MT103 outgoing
SWIFT message user header block 3 for field 119 validation flag will be having “REMIT”.

In case MT103+ is given then all bank fields ACCT.WITH.BANK, RECEIVER.BANK,

REC.CORR.BANK, INTERMED.BANK should have either a customer who has a record in
DE.ADDRESS for carrier as “SWIFT.1” or a valid BIC code prefixed with “SW-“ along with
BEN.ACCT.NO.

In FT.APPL.DEFAULT field MT103.CONTROL, is set to SYSTEM, then system raises an ERROR

message if above condition is not met. If the above condition is met, then an override is raised and
MT103 is generated instead of MT103+.

The generated MT103+ will be populated with “STP” in user header block 3 for field 119 validation flag.

In other cases a plain MT103 is generated.

TEMENOS T24 User Guide Page 36 of 117

Funds Transfer

Cover Methods
The following Cover Methods are supported from FT:

COVER-DIRECT- Detailed payment instruction is sent directly to another Institution via an

MT103 and brief instructions are sent to our correspondent via an MT202 for
covering payment message.
COVER-NEAR- Payment message (MT103) sent through several reimbursement institutions,
using an account with institution and brief instructions to our correspondent
via an MT202.
SERIAL- Payment message (MT103) is sent to the next party in the transaction.
THIRD-INST- Payment message (MT103) sent to party closest to the beneficiary, using a
third reimbursement institution and instructions to our Correspondent via
MT202.

Based on the cover method and customer number given in BEN.CUSTOMER or BEN.BANK, from
AGENCY for the currency and application, values will be defaulted in bank fields and BEN.ACCT.NO
as per following:

• If COVER.METHOD is ‘SERIAL’, then ACCT.WITH.BANK and INTERMED.BANK will be defaulted.

• If COVER.METHOD is ‘COVER-DIRECT’, fields will be defaulted in RECEIVER.BANK,
REC.CORR.BANK, and INTERMED.BANK.
• If COVER.METHOD is ‘COVER-NEAR’, fields will be defaulted in ACCT.WITH.BANK,
RECEIVER.BANK, and REC.CORR.BANK.
• If COVER.METHOD is ‘THIRD-INST’, fields will be defaulted in RECEIVER.BANK,
REC.CORR.BANK, INTERMED.BANK and an error will be raised in case any one of the above
Bank fields are NULL. Details given in REC.CORR.BANK will be mapped to Tag 55 (Third
Reimbursement Institution) and INTERMED.BANK to Tag 54 (Receiver Correspondent Bank) in
SWIFT MT103 message.

An override is required when ACCT.WITH.BANK details given along with COVER.METHOD as

‘THRID.INST’.

Example for defaulting of bank fields based on BEN.CUSTOMER & COVER.METHOD

Our bank is Temenos Bank PLC.

We use Chase NYK as our USD correspondent.
Client is DBL Limited and they have a US account with BNP Grenoble A/C no 123456.
BNP Grenoble needs to have US covered via BNP Paris.
BNP Paris takes cover at Bank of New York, NY.

TEMENOS T24 User Guide Page 37 of 117

Funds Transfer

For the above customers, appropriate set up has been done through Auto routing details of AGENCY
for currency “USD” and application “FT”.

Now defaulting of FT bank fields from AGENCY based on BEN.CUSTOMER as per following:

$ Customer No 100345 will be appearing in Tag 55 of MT103 & tag 57 of MT202

# Customer No 100654 will be appearing in Tag 54 of MT103 & tag 56 of MT202

Recording card details

Card number and details relating to the card transaction can be recorded in the fields CARD.NUMBER
and CARD.TXN.DETAIL in STMT.ENTRY through FUNDS.TRANSFER, so that they can be used
in statement production. The same feature is available through AC.ENTRY.PARAM as this
information can be received from the switchware that is processing the transactions.

Agency
The main objective of the AGENCY file is to keep the default delivery instructions for a customer or
for a BIC address and the details of operation of the NOSTRO.ACCOUNT. It provides settlement
information, which would otherwise have to be input repeatedly on each transaction.

The key to the AGENCY file is the customer number or the BIC address prefixed by ‘SW‘. The
customer number should be a valid T24 customer number and should exist on the CUSTOMER file.

The SWIFT address is prefixed by ‘SW-‘ and must contain 11 characters for a valid SWIFT Id (without
prefix) and must be present on the DE.BIC file. The DE.BIC file is loaded from the information
supplied by SWIFT on CD-ROM containing current BIC codes, addresses and other details.

TEMENOS T24 User Guide Page 38 of 117

Funds Transfer

Further details on the usage of the AGENCY table are provided in the System Tables User Guide.

There is a field on the AGENCY record called AUTOROUTE.AGRD, which is used where there is an
agreement in place with the correspondent in regard to reimbursement on payments sent to other
banks. This can be used to suppress cover payment messages where they are not required.

Beneficiary details
The BENEFICIARY table is used to maintain beneficiary information which can be defaulted into
either the FUNDS.TRANSFER or STO.PAYMENT. Beneficiary data can include routing
information e.g. BIC code, sort code or account number etc

There are two types of beneficiary which can be defined;

• Bank defined
• Customer defined

The following fields may only be used in a customer defined BENEFICIARY record

• OWNING.CUSTOMER – Valid customer id of the customer who creates the

beneficiary
• LINK.TO.BENEFICIARY – Contains the @id of a bank defined beneficiary record
• CUSTOMER.REFERENCE – Swift format field.
• DEFAULT.NARRATIVE – Swift format field

The following fields may only be used in bank defined records

• CATEGORY - Descriptive text field ‘Utilities’, ‘Credit Card Company’ etc

• HINT.TEXT - Text field, which could enable banks to inform a user where to find
specific information, for example customer reference number on a
bill.

The Customer or Bank can define any number of beneficiaries. A customer can create his own
beneficiaries or can use the bank defined beneficiaries as a link and create a beneficiary table.

The ID of the beneficiary table is a unique system generated ID

The following fields will be used to map information from BENEFICIARY to either FT or STO.

TEMENOS T24 User Guide Page 39 of 117

Funds Transfer

• ACCOUNT.WITH.BANK - Maps to the field ACCOUNT.WITH.BANK in both FT and STO.

• BANK.SORT.CODE - Maps to BANK.SORT.CODE in both FT and STO
• BEN.ACCT.NO - Mandatory field for AC and BC type transaction. Maps to
BEN.ACCT.NO in FT, and CPTY.ACCT.NO field in STO for AC
transactions. It is an optional field for OT and OD transaction types
which maps to the field BEN.ACCT.NO for both FT and STO.
• BEN.CUSTOMER - Mandatory field for OT, BC and OD transaction types and maps to
field BEN.CUSTOMER in FT and STO
• BIC - Allowed for only OT transaction types and maps to
RECIEVER.BANK in FT. Must be a valid id on DE.BIC table
• CUSTOMER.REF - Mapped to the CREDIT.THEIR.REF in FT and BEN.REFERENCE
in STO.
• DEFAULT.NARRATIVE - Mapped to DEBIT.THEIR.REF in FT and STO. Also mapped to
CREDIT.THEIR.REF when CUSTOMER.REF is NULL

Example BENEFICIARY record for a customer OT03 txn

TEMENOS T24 User Guide Page 40 of 117

Funds Transfer

Example BENEFICIARY for customer AC

Example Bank defined BENEFICIARY

TEMENOS T24 User Guide Page 41 of 117

Funds Transfer

Field BENEFICIARY.ID in FT

Field BENEFICIARY.ID in STO

AUTO.ID.START
This application initiates automatic key numbering. The FT application has two types of automatically
generated key formats available:

1. The Standard – FT0700112345 where 07001 is today’s Julian date and 12345 is a transaction
count thus allowing up to 99,999 FT transactions in one day.
2. The Unique key – such as FT07001123456789 where the sequence is generated according to
conditions in the AUTO.ID.START fields.

In order to use the longer key format then ‘YES’ must be entered in field UNIQUE.NO and depending
on whether alpha characters are allowed the BASE.TABLE field as well. The id.length field
should then be set to 16.

TEMENOS T24 User Guide Page 42 of 117

Funds Transfer

See the User Guide for System Tables for full details of AUTO.ID.START usage.

AC.EXPECTED.RECS
When an FT of TYPE IT is authorised for which the EXPECTED.RECS is set to YES, the system will
interface to AC.EXPECTED.RECS. If the funds are to be credited to the qualifying account then an
AC.EXPECTED.RECS record is created for the receipt funds. This information is displayed in the
information box and if there was an expected record to which this receipt is matched with then the
message to this effect is displayed. For more details of the AC.EXPECTED.RECS functionality
please see the AC.EXPECTED.RECS user guide.

FT.BULK.CREDIT
In addition to the BULK.STO there is another application where the id is the credit account and
multiple debit accounts and amounts are allowed. This application is FT.BULK.CREDIT, is a single
credit and multiple debit solution.

Usage of this application is dependent on the business requirements; it allows

FT.TXN.TPE.CONDITION records based on the ACXX or IMXX types (that means the first two
characters must be either AC or IM). Accounting is washed through an internal suspense account as
defined on ACCOUNT.CLASS, the record SUSPFTINWD must be in place and have the relevant
accounts opened before using FT.BULK.CREDIT. The actual accounting is affected by the FT
records created on-line or at COB.

The screenshot below caters for both credit and debit commissions and charges using the standard
FT.CHARGE.TYPE and FT.COMMISSION.TYPE records. Amounts and accounts are entered
where required for the many debit items and the total is used to credit the id account.

TEMENOS T24 User Guide Page 43 of 117

Funds Transfer

FT.BULK.CREDIT screen

Records created for this application are usually processed during the end-of-day processing, although
they can be run on-line using SINGLE.INWARD.BULK. This allows the user to select the required
records and create the associated Funds Transfer deals on-line.

TEMENOS T24 User Guide Page 44 of 117

Funds Transfer

SINGLE.INWARD.BULK Screen

Looking at a practical example - we have received our statement from one of our correspondents and
are now ready to debit them to the clients whose activities incurred the charges. We wish to credit the
Nostro account to keep our reconciliation correct, and post debits to the customers we are to charge.

Example of an FT Bulk Credit Transaction

TEMENOS T24 User Guide Page 45 of 117

Funds Transfer

When authorised we can process the record on-line or leave it for the COB processing. Whichever is
used will create several Funds Transfer records. For the screenshot above there will be three FT’s
raised. One will credit the total amount to the credit account with an offset to the suspense account.
The other two will be debits to the specified debit accounts with the offset credited to suspense. This is
to cater for exception conditions such as overrides, which can occur when creating the FT contracts. It
is therefore incumbent on the bank to check the unauthorised deals and to monitor the suspense
account balances.

More than one FT.BULK.CREDIT can be entered using the date and a sequence No as ID, along
with the account number for a date. To retain an FT.BULK.CREDIT record in a live file after it
moves to “MAT”, we can specify MOVE.TO.HISTORY as “NO” in the FT.BULK.CREDIT record.

Charges and Commissions

Chargesand commissions are defined in the tables FT.CHARGE.TYPE and
FT.COMMISSION.TYPE. Further details on the usage of these tables are provided in the System
Tables chapter of the User Guide.

Charges and commissions entered in COMMISSION.AMT and CHARGE.AMT can be input separately
for the sending bank and the receiving bank by using COMMISSION.FOR and CHARGE.FOR, with
values of SENDER OR RECEIVER; SENDER being the default. Receiver commission/ charges can
be specified manually during FUNDS.TRANSFER contract input or charges can be defaulted using
CORR.BANK.CHARGES application, which is explained below.

Receiver correspondent bank charges (MT103) - OUTWARD

In MT103 (single customer credit transfer) message, charges for the receiver of MT103 message can
be specified and remitted to them along with transfer amount for outward transaction.

CORR.BANK.CHARGES is used to define charges and commission based on customer and these
charges are defaulted in FT during inward and outward processing when that customer is used as per
the below defaulting mechanism.
The Correspondent bank charges for a currency can be set up in CORR.BANK.CHARGES for a
customer with ID as “CUSTOMER” with optional FT.TXN.TYPE to default charges as applicable for
the customer or with ID as “DEFAULT” with optional TXN.TYPE to default charges in case there is no
definition at customer level.

Order of defaulting commission / charges from CORR.BANK.CHARGES:

When the charge/commission is defined in CORR.BANK.CHARGES for the contract currency-the

order of defaulting of correspondent charges is as follows

TEMENOS T24 User Guide Page 46 of 117

Funds Transfer

1. CUSTOMER - TXN.TYPE
2. CUSTOMER
3. DEFAULT-TXN.TYPE
4. DEFAULT

In case a record exists with above order but the charge/commission is not defined for the contract
currency-then no charges is defaulted. I.e. In CBC record is available for customer 100170 with
currency USD & DEFAULT record with USD & JPY-then when an incoming message (MT103) is
processed with currency JPY for customer 100170-then no charge is defaulted since for the customer
100170 charge is not defined for currency “JPY” even though the “DEFAULT” is available.

To default charges based on CORR.BANK.CHARGES Application in FT, field

DEF.CORR.BANK.CHGS in FT.APPL.DEFAULT should be set to “YES”. In FT, receiver of
MT103 message can be;

• CREDIT.CUSTOMER (When receiver bank not specified or receiver bank not a valid T24
customer)
• RECEIVER.BANK when it is a valid customer - (In this case cover payment is sent to
CREDIT.CUSTOMER.)

Commission/charge code given in CORR.BANK.CHARGES has precedence for defaulting in FT

over FT.TXN.TYPE.CONDITION charge type. Hence for TXN.TYPE where the correspondent
charges to be defaulted, in FT.TXN.TYPE.CONDITION commission/ charge code should be null.

Example for defaulting Receiver Charges for Outward Transaction (MT103): -

In our example when a MT103 is sent to CEDEL (customer No-100170), the correspondent charges
that is to be given to CEDEL is USD30 for processing USD payments and EUR10 for EUR payments.
It has been defined in CORR.BANK.CHARGES application with ID as CUSTOMER-TXN.TYPE.

TEMENOS T24 User Guide Page 47 of 117

Funds Transfer

CORR.BANK.CHARGES – Set up for Customer – TXN.TYPE combination

Now based above set-up, when CEDEL customer id is given as CREDIT.CUSTOMER or in

RECEIVER.BANK and BEN.OUR.CHARGES is given as “OUR” in FUNDS.TRANSFER, system
defaults the charge code and charge amount as applicable for the CREDIT.CURRENCY and
CHARGE.FOR as” Receiver”. I.e. USD30 is collected and remitted to CEDEL along with the transfer
amount.

TEMENOS T24 User Guide Page 48 of 117

Funds Transfer

FT - Example for Defaulting of Receiver Charges for CEDEL

Accounting entries for amount to be received by receiver of MT103 is arrived by adding charges due
to the receiver plus transfer amount.

Accounting Entries with Receiver Charges

TEMENOS T24 User Guide Page 49 of 117

Funds Transfer

Outward MT103 message the receiver charges (71g) is populated along with the instructed (33b) and
remitted amount (32A). Remitted amount is arrived by adding charges with the transfer amount.

MT103 message output with Receiver Charges.

Defaulting of charge code in FT is applicable only for outward transfer transaction (OTXX) for which
MESSAGE.TYPE is given as 103 in FT.TXN.TYPE.CONDITION and BEN.OUR.CHARGES is given
as “OUR” in FT. Since receiver charges (Tag 71g) is applicable for message type 103 and for details
of charges (Tag 71A) is “Our”. For message types other than 103, BEN.OUR.CHARGES or “OUR”
CHARGE.FOR cannot be given as “Receiver” in FT and an error message is raised.

Example for defaulting of Sender Charges for Outward Transaction (“OTXX”): -

Irrespective of value in BEN.OUR.CHARGES field in FT, when an Outward TXN.TYPE is used

(“Otxx”) then Commission / charge amount is populated based on DEBIT.CUSTOMER when a set-up

TEMENOS T24 User Guide Page 50 of 117

Funds Transfer

is available for that customer, TXN.TYPE and currency combination in the CORR.BANK.CHARGES.
Otherwise charge is defaulted based on “DEFAULT”, TXN.TYPE and currency combination.

For customer – GATES (1040) commission of 1% to be collected whenever an outward transfer

(“OTXX”) is executed. For this commission code “OUTSWIFT” which has a set-up of collection
commission of 1% for USD is linked in CORR.BANK.CHARGES with ID as CUSTOMER.

Commission defined for Customer 1040 in CORR.BANK.CHARGES application

Using the above set-up when the debit account of customer GATES is used for “OTXX” type of
transaction, system calculated USD100.00 as commission and CHARGE.FOR field is populated as
“SENDER”.

Commission collected as per CBC in FT.

TEMENOS T24 User Guide Page 51 of 117

Funds Transfer

When the customer level definition is not available, the system will be calculating the
commission/charges if CORR.BANK.CHARGES application has a “DEFAULT- WITH OPTIONAL
TXN.TYPE” set-up.

In FT if BEN.OUR.CHARGES is given as “OUR” then system calculates the receiver charges based on
the credit customer or receiver bank (when a valid customer) as well as sender charges based on
debit customer based on the above defaulting mechanism.

Receiver correspondent bank charges (MT103) – INWARD

The receiver of the MT103 message can claim/collect charges for processing an inward MT103 in the
following ways: -

1. When sender (MT103) remits the receiver charge along with the transfer amount, the user can
debit the sender and collect the charges.
2. When the sender advises the receiver to claim charges from the sender-receiver of MT103 they
can send a request with charge details for reimbursement.

In case-2 where the sender maintains a Vostro account with the receiver bank, then charges can be
debited directly and debit advice can be sent, otherwise request for reimbursement of charges has to
be sent.

Case 1
When an inward MT103 message is received and charge amount due to the receiver is sent along
with transfer amount through tag 71G (Receiver charges), then during FT inward processing, charge
amount is debited with the charge code as defined in the IN.CHG.CODE field in
FT.TXN.TYPE.CONDITION. In case IN.CHG.CODE is not defined for the TXN.TYPE then during
inward processing, FT is put on Hold with PROCESS.ERROR indicating “Missing IN.CHG.CODE”.

Case 2
To default the correspondent bank charges based on the CORR.BANK.CHARGES application
during inward MT103 processing in case the charges not specified in tag 71g of MT103 message,
FT.APPL.DEFAULT, field DEF.CORR.BANK.CHGS should be set to “YES”.

Based on details of charges (Tag 71A) available in the Inward MT103 message, COMMISSION.CODE
/ CHARGE.CODE in FUNDS.TRANSFER are defaulted as follows:

Default of Comm/Chg Code in FT

TEMENOS T24 User Guide Page 52 of 117

Funds Transfer

In the respective FT.TXN.TYPE.CONDITION, the CHARGE.TYPE has to be Null since the charge
code defined in the CORR.BANK.CHARGES is given precedence for defaulting in FT.

Add a record in CORR.BANK.CHARGES application for the CUSTOMER or CUSTOMER-

TXN.TYPE condition as explained above to default charges during Inward MT103 processing*.

* (Please refer to MT103 inward message processing using OFS.GLOBUS.MANAGER section in

this user guide)

In our example set-up is done to take USD120 for USD & GBP5.91 for GBP currency payments from
CEDEL (Nostro Account Holder) for processing a MT103 inward Message.

CORR.BANK.CHARGES –Set-up for Defaulting of Correspondent charges

Add a record in AUTO.ID.START for AC.CHARGE.REQUEST to generate ids automatically.

Based on the above set-up, during MT103 inward processing if the receiver charges are not specified
in Tag 71G, and detail of charges (Tag 71A) is “OUR”, the system defaults the charge code and
charge amount based on DEBIT.CURRENCY.

FT-Inward charges defaulted during inward processing.

TEMENOS T24 User Guide Page 53 of 117

Funds Transfer

For the defaulted charges, the system creates a record in AC.CHARGE.REQUEST to keep track of
the charge details and the related record AC.CHARGE.REQUEST that is available in FT for
reference along with the CHG.ADVICE.MSG (190/191). Transaction entries related to charges are
handled in FUNDS.TRANSFER itself and only for the messages is AC.CHARGE.REQUEST
application used.

Inward MT103 message & AC.CHARGE.REQUEST ID & Msg type in FT

The charge advice (either 190 / 191) to be generated is based on the ACCOUNT.CLASS of the debit
account – either Vostro or Nostro.

When a Nostro account is used as debit account, then charges debited to charge claim account as
given in FT.APPL.DEFAULT and MT191 (request for payment of charges) is raised through
AC.CHARGE.REQUEST application with incoming FT details.

TEMENOS T24 User Guide Page 54 of 117

Funds Transfer

When a Vostro account is debited for the charges then MT190 (advice of charges) is raised through
AC.CHARGE.REQUEST application with incoming FT details.

AC.CHARGE.REQUEST Record for 190 message – Debit to Vostro A/c

In case MT103 payment is received through an institution other than the sender institution, an
MT190/191 charge advice is sent to sender of MT103 with receiver correspondent details in account
with bank (tag 57).

In case the inward MT103 has details of charges (tag 71a) as:

• “BEN” (All transaction charges are to be borne by the beneficiary customer).

or
• “SHA” (Transaction charges on the sender side are to be borne by the ordering customer,
transaction charges on the receiver side are to be borne by the beneficiary customer).

TEMENOS T24 User Guide Page 55 of 117

Funds Transfer

Then based on CORR.BANK.CHARGES set-up for the sender of MT103, as explained above
charge amount is defaulted but the amount is credited to the beneficiary after taking the charge
amount. In this case no record is created in AC.CHARGE.REQUEST.

When an inward MT103 generates outgoing MT103 message (TXN.TYPE = OTXX), the incoming
charge details (i.e. currency and amount of the transaction charges deducted the sender and by
previous banks in the transaction chain) are mapped to FT in-fields and it is used while generating
outward MT103 Message.

CUSTOMER.CHARGE
A standard feature of T24 is to target the charges made to a client according to the grouping of the
client.

A file called CUSTOMER.CHARGE achieves this. This is created whenever a new CUSTOMER
record is opened. The controlling tables that decide which group the client should default to for
FUNDS.TRANSFER (there are similar tables for LC, SC and FD) are:

• FT.GEN.CONDITION
• FT.GROUP.CONDITION

Effectively this operates on the basis of defining groups, one group would be a default where the full
charge is taken, and other groups would be used to reduce a particular charge for that group.

FT.GEN.CONDITION
This file is for the base level decisions. Here you specify what record values from the chosen decision
tables are required to define the group and the group name.

Note that this file is dependent on the CONDITION.PRIORITY table where you define which tables
are to be used for the decisions in FT.GEN.CONDITION. For example you may decide that
CATEGORY and SECTOR are the obvious choice tables, these would be entered into
CONDITION.PRIORITY for the FT record. Then you could create a group where the CATEGORY
code had to be 1000 and the SECTOR code 2000.

The ID length for both FT.GEN.CONDITION and FT.GROUP.CONDITION may be up to 4

characters long.

A typical default group would have no conditions.

TEMENOS T24 User Guide Page 56 of 117

Funds Transfer

Example - FT.GEN.CONDITION

FT.GROUP.CONDITION

Once the default at the minimum has been set in FT.GEN.CONDITION, you can specify the basis
on which charges and commissions are adjusted. For example a group may be created to reduce all
TX charges to 50% for special clients, whilst another sets clients to be charged 75% of TX charges.
TX could be the record id of either FT.CHARGE.TYPE or FT.COMMISSION.TYPE.

Example - FT.GROUP.CONDITION

TEMENOS T24 User Guide Page 57 of 117

Funds Transfer

Inward Delivery

Incoming Messages
FT can process incoming (inward) messages to produce FT transactions, some of which may in turn
produce onward (outward) messages. This is done by using either FT.IN.PROCESSING, or by
utilising OFS. They can both take an inward SWIFT message generated via the relevant SWIFT
carrier and use it to produce a FUNDS.TRANSFER.

While FT.IN.PROCESSING has to be run manually on a periodic basis, OFS can be used to map
inward SWIFT messages continuously via a phantom process. For information how to set up an
OFS.SOURCE record and an EB.PHANTOM, please see the OFS user guide. At present through
FT.IN.PROCESSING and FT.OFS.INWARD.MAPPING, the SWIFT messages that can be
processed are MT202, MT200, and MT100*, along with the relevant MT205 being produced from an
inward MT200 or MT202. Through OFS.GLOBUS.MANAGER SWIFT messages MT100*, MT103,
MT200, MT202, MT205, MT210 are supported. Moreover the incoming message need not be
processed it can be redirected to EB.FREE.MESSAGE for viewing. The set-up related to above
OFS.GLOBUS.MANAGER is given at the end.

• Where an MT100 has been requested in a legacy application base MT103 is produced instead.

FT.OFS.INWARD.MAPPING

OFS will call the routine FT.OFS.INWARD.MAPPING when its input message directory is clear.
The routine FT.OFS.INWARD.MAPPING is used to translate all unprocessed inward SWIFT
messages into OFS syntax, and write them into the OFS input directory. The actual detailed mapping
is performed by a message specific routine defined in INWARD.OFS.RTN on the relevant
DE.MAPPING record. A default routine FT.OFS.DEFAULT.MAPPING (for which the source
code is provided) is supplied to process 100, 200, 202 and 205 messages. A detailed description of
the FT.OFS.DEFAULT.MAPPING mapping logic is supplied in the API Developers Guide. OFS will
then process these messages and produce FT’s. When all messages have been processed the cycle
begins again. The details of the records needed are shown by the screenshot examples below:

TEMENOS T24 User Guide Page 58 of 117

Funds Transfer

OFS Source See Screen

As can be seen from the OFS.SOURCE record above, the field IN.DIR.RTN can be used to specify
a user defined routine. When this is used in conjunction with the field below called VERSION, this can
create OFS.MESSAGES. The OFS.SOURCE record is referred to in the EB.PHANTOM record and
this is then started by using the VERIFY function. The inward formatting phantom can to be switched
on via DE.MENU.

DE.MESSAGE Input Screen

The version used by OFS will be that defined in IN.OFS.VERSION on the DE.MESSAGE record.

TEMENOS T24 User Guide Page 59 of 117

Funds Transfer

OFS Record is referred to in the Phantom Control Record

The delivery module will process incoming SWIFT messages and translate them via DE.MAPPING
parameters into the DE.I.MSG.FT file, used to produce FT’s. The DELIVERY user guide gives
details of setting up the inward SWIFT and telex carriers.

Example of MT202 with Intermediary

There follows examples of SWIFT message, with the resultant outward Funds Transfers produced by
using OFS and EB.PHANTOM.

{1:F01TEMEUS33XXXX.SN...ISN.}{2:I202MLNYUS33XXXXN}{3:{108:xxxxx}}{4:
:20:FT0031100012
:21:MT202INTER1
:32A:001106USD3020,00
:52A:BOTKJPJT
:56A:CITIUS33
:57A:BBMBUS33
:58A:BBMBGB2L
-}

MT202 with intermediary

TEMENOS T24 User Guide Page 60 of 117

Funds Transfer

Example of MT202 with Intermediary

Example of MT202 following onto an MT205

9 lines long.
#001: {1:F01MGTNUSXXXXXXN.SN...ISN.}{2:I202STDPLATXXXXX}{3:{108:xxxxx}}{4:
0002: :20:MT202INTER10
0003: :21: RELATED REF
0004: :32A:950914USD2000
0005: :53B:/11398
0006: :56A:EUROBEBR
0007: :57A:100013
0008: :58A:100010
0009: -}#
Bottom at line 9.

mt202

TEMENOS T24 User Guide Page 61 of 117

Funds Transfer

Example of MT202 following onto an MT205

TEMENOS T24 User Guide Page 62 of 117

Funds Transfer

Example of MT202 following onto an MT205

TEMENOS T24 User Guide Page 63 of 117

Funds Transfer

Example of MT200 Account with Institution

The credit account number is determined by extracting the customer number from the
DE.SWIFT.ADDRESS file for EUROBEBR. Then by extracting THEIR.ACCOUNT.NO from the
AGENCY record for that customer. DE.SWIFT.ADDRESS is an internal file derived from
DE.ADDRESS

TEMENOS T24 User Guide Page 64 of 117

Funds Transfer

Example of MT200 Account with Institution

Example of MT200 producing an On-forwarding MT205

>ED SWIFT.IN MT200INTER1

7 lines long.
#001: {1:F01MGTNUSXXXXXXN.SN...ISN.}{2:I200STDPLATXXXXX}{3:{108:xxxxx}}{4:
0002: :20:MT200INTER1
0003: :32A:950914USD3050
0004: :53B:/11398
0005: :56A:EUROBEBR
0006: :57A:100013
0007: -}#
Bottom at line 7.

Example mt200

TEMENOS T24 User Guide Page 65 of 117

Funds Transfer

Example of MT200 producing an on forwarding MT205

Inward SWIFT Funds Transfer Messages using OFS.GLOBUS.MANAGER

Certain SWIFT payment messages may be processed using the Inward Delivery OFS Globus
Manager method (see the Delivery section of this Manual for a detailed description of this method).
This generic method relies on OFS Globus Manager and on message specific subroutines to improve
functionality and maintainability and to allow the flexibility of locally developed message subroutines.
It has been developed largely in response to increased STP requirements, so that, where required,
outbound transfer requests will be automatically sent on receipt of certain inbound requests.

The supported messages for the FT application are; inbound MT101, MT103, MT200 and MT205
(more will be converted to this method in the future).

TEMENOS T24 User Guide Page 66 of 117

Funds Transfer

General Set up requirement for Processing Inward Messages

An OFS.SOURCE record is created to define an OFS interface.

OFS.SOURCE Record for Inward Delivery

A FUNDS.TRANSFER zero authoriser version record is created.

Funds Transfer Version

TEMENOS T24 User Guide Page 67 of 117

Funds Transfer

The inward OFS subroutine, OFS source and the FUNDS.TRANSFER version are indicated in the
DE.MESSAGE record for the message. Note: the example in Fig. 70 shows the T24 supplied routine
DE.I.MT103, but a local routine may be indicated here instead.

DE.MESSAGE for MT103 Indicating OFS.GLOBUS.MANAGER Processing

Delivery will route the message via GLOBUS OFS Manager when the DE.MESSAGE record is set up
in this way (reverting to standard processing if these fields are left blank).

Funds Transfer Specific Set Up

TRANSACTION.TYPE
A single message type may be required to generate different FUNDS.TRANSFER transaction types,
e.g. an MT103 may result in an Inward Telex (FT.TXN.TYPE IT) requesting a payment to an internal
customer, or may generate an Outward Telex (FT.TXN.TYPE OT03) producing an onward MT103 for
payment to a customer at a correspondent bank.

The relevant subroutine (like DE.I.MT103) will allocate the type No depending on the contents of
the message Tags and the FT.TXN.TYPE to be used for the Type No can be set as a multi-value
field in DE.I.FT.TXN.TYPES in field FT.TXN.TYPE for each message type. At least one
FT.TXN.TYPE must be present for each message type.

For example DE.I.MT103 subroutine supports eight combinations of type and for each type, an
FT.TXN.TYPE can be set as and FT created with FT.TXN.TYPE applicable for that Type No.

TEMENOS T24 User Guide Page 68 of 117

Funds Transfer

DE.I.FT.TXN.TYPES for message MT103

The rules are applied to each message to decide the transaction type are summarised below:
Condition FT Transaction Type
MT101*
Acct with Bank Cr Acct/Dr Acct is Transaction Type Example
present Vostro or Nostro No from FT Txn Type Code
(Tag 57) Subroutine From DE.I.FT.TXN.TYPES
DE.I.MT101
NO YES 1 IT
YES 2 OT
NO NO 3 AC

MT103
Acct with Bank Receiver Receiver Charges Transaction Type Example
present Correspondent present No from FT Txn Type Code
(Tag 57) (Third party) Bank (Tag 71G) Subroutine From DE.I.FT.TXN.TYPES
present DE.I.MT103

YES NO NO 1 OT03
YES NO YES 2 OT03
YES YES NO 3 OT03
YES YES YES 4 OT03
NO NO NO 5 IT
NO NO YES 6 IT
NO YES NO 7 IT
NO YES YES 8 IT

TEMENOS T24 User Guide Page 69 of 117

Funds Transfer

MT102
Acct with Bank Receiver Charges Bank Transaction Type Example
present present Operation No from FT Txn Type Code
(Tag 57) (Tag 71G) Code Subroutine From DE.I.FT.TXN.TYPES
(Tag 23 ) DE.I.MT102

NO NO --- 1 IT

YES YES ---- 2 OT03

YES NO ---- 3 OT03

YES YES CHQB 4 OC

YES NO CHQB 5 OC

NO YES CHQB 6 OC

NO NO CHQB 7 OC

MT200
1 OT
MT202/ MT203 (Multiple Sequence Message)
Acct with Bank Transaction Type Example
present No from FT Txn Type Code
(Tag 57) Subroutine From DE.I.FT.TXN.TYPES
DE.I.MT202 /203
NO 1 IT
YES 2 OT

MT205
Acct with Bank Transaction Type Example
present No from
Subroutine FT Txn Type Code
(Tag 57) DE.I.MT205 From DE.I.FT.TXN.TYPES
NO 1 IT
YES 2 OT

FT.TXN.TYPE Rules

* Refer to the Application Delivery user guide in API Developers Guide section for knowing about
MT101 Inward/Outward Message processing.

Multiple Messages
An MT101 (Multiple) Request for Transfer may contain multiple transfer instructions resulting in
several FUNDS.TRANSFERS of AC, IT and/or OT types, depending on the rules set out as above.

TEMENOS T24 User Guide Page 70 of 117

Funds Transfer

Awaiting Cover Payment

A SWIFT payment request (MT103) may be from a non-correspondent bank but contain an indication
of a cover payment via a correspondent bank. The receiver may wish to suppress STP and withhold
payment until confirmation of the cover payment is received from its correspondent.

Field ‘AWAIT.COVER’ in FT.APPL.DEFAULT can be set to “YES” to hold all such Funds Transfer
payments until cover is received. The FT will be put on Hold with the IN.PROCESS.ERR description
‘Awaiting Cover Payment’ until it is manually released. If field ‘AWAIT.COVER’ in
FT.APPL.DEFAULT is set to “LIM”, then using correspondent bank limit functionality inward MT103
message is processed which is explained in above (AC.EXPECTED.RECS section)

FT.APPL.DEFAULT with AWAIT.COVER = 'YES'

TEMENOS T24 User Guide Page 71 of 117

Funds Transfer

Examples of MT103 inward processing through OFS.GLOBUS.MANAGER

Inward MT103 Message

TEMENOS T24 User Guide Page 72 of 117

Funds Transfer

FT created after processing the above MT103 SWIFT message

TEMENOS T24 User Guide Page 73 of 117

Funds Transfer

(cont) FT created after processing the above MT103 SWIFT message

Inward Processing of MT102

An incoming MT102 message may be required to generate different FUNDS.TRANSFER transaction

types, e.g. an MT102 may result in an Inward Telex (FT.TXN.TYPE IT) requesting a payment to an
internal customer, or may generate an Outward Telex (FT.TXN.TYPE OT03) producing an onward
MT103 / MT102 for payment to a customer/s at a correspondent bank, or an OC type of transaction
whereby, cheques are issued by the bank to clients who do not have an account with them.

The relevant subroutine (DE.I.MT102) will allocate the TXN.TYPE depending on the contents of
Tags in the message received. These conditions are specified in DE.I.FT.TXN.TYPES for 102 in the
field FT.TXN.TYPE for each message type. At least one FT.TXN.TYPE must be present for each
message type.

For example DE.I.MT102 subroutine supports seven combinations of type and for each type,
conditions have been specified.

TEMENOS T24 User Guide Page 74 of 117

Funds Transfer

DE.I.FT.TXN.TYPES for message MT102

STEP 1: Create an OFS.SOURCE for example OFS.TEST. Please refer the User Guide on OFS for
further details.

OFS.SOURCE Record - OFSTEST

STEP 2: Create a VERSION e.g. FUNDS.TRANSFER,TEST

TEMENOS T24 User Guide Page 75 of 117

Funds Transfer

VERSION - FUNDS.TRANSFER,TEST

STEP 3: In DE.MESSAGE message ID 102, the following values are to be input:

Routine name that is DE.I.MT102 is to be input in field no 17.
The version name is to be input in Field no 18.1.
The OFS.SOURCE.RECORD ID that is OFSTEST is to be input in field 21.

TEMENOS T24 User Guide Page 76 of 117

Funds Transfer

INWARD MT 102 PROCESSING

Incoming MT102

Screen shots of the FUNDS.TRANSFER record generated from this incoming MT102

TEMENOS T24 User Guide Page 77 of 117

Funds Transfer

FT03077001000001

TEMENOS T24 User Guide Page 78 of 117

Funds Transfer

FT03077001000001

TEMENOS T24 User Guide Page 79 of 117

Funds Transfer

FT03077001000001

OT IT type of FTS will be generated automatically if the relevant details are available in the incoming
MT102.

However, the OC type of FT will always be generated in Hold status since details of the cheque no are
to be input. The cheque number can be input and the record committed.

Bypass the processing of inward messages

Bypass the processing of messages ‘XXX’ means that the inward messages of type ‘XXx’ will not be
processed. Instead a new record in EB.FREE.MESSAGE will be created storing the inward delivery
reference id.

The set up required is as follows:

Create EB.ACTIVITY.

TEMENOS T24 User Guide Page 80 of 117

Funds Transfer

If we want to bypass processing 103 messages, then create EB.ACTIVITY with id being EB-0103 (id
should start with EB-0 followed by the message type).

EB.ACTIVITY created to bypass 103 messages

Create EB.ADVICES with the above EB.ACTIVITY id with the message type, message class,
mapping key.

EB.ADVICES record created for the above EB. ACTIVITY id

Create OFS.SOURCE with value GLOBUS in the SOURCE.TYPE field.

TEMENOS T24 User Guide Page 81 of 117

Funds Transfer

OFS.SOURCE with SOURCE.TYPE ‘GLOBUS’

Create a Version for EB.FREE.MESSAGE with required GTS.CONTROL.

VERSION record for EB.FREE.MESSAGE

TEMENOS T24 User Guide Page 82 of 117

Funds Transfer

In DE.MESSAGE for the MESSAGE.TYPE, attach the routine DE.I.MTBYPASS that has ‘S’ type entry in
PGM.FILE in the field INWARD.OFS.RTN.

PGM.FILE for routine DE.I.MTBYPASS

Attach the version created for EB.FREE.MESSAGE in the field IN.OFS.VERSION.

Attach the OFS.SOURCE id as created above in the field OFS.SOURCE.

DE.MESSAGE 103 record with Inward routine details

TEMENOS T24 User Guide Page 83 of 117

Funds Transfer

Create AUTO.ID.START for EB.FREE.MESSAGE so that Ids can be generated automatically. In the
COMPANY application, add EB.FREE.MESSAGE code in PGM.AUTOM.ID to generate the ID
automatically during inward processing.

AUTO.ID.START created for EB.FREE.MESSAGE

The Inward Delivery Reference Id is updated in the field IN.DEL.REF of EB.FREE.MESSAGE.

With all the above set up, the incoming messages will not be processed. The FUNDS.TRANSFER
contract creates a record instead in EB.FREE.MESSAGE with the delivery ID.

The DE.I.MTBYPASS routine attached in DE.MESSAGE will identify the SENDING.CUSTOMER

and will update the same in the CUSTOMER field of EB.FREE.MESSAGE.

Incoming MT103 Inward message

TEMENOS T24 User Guide Page 84 of 117

Funds Transfer

EB.FREE.MESSAGE record for the MT103

Message viewed from the context level enquiry

Outward Delivery

Assigning SWIFT Message Types to FT Transactions

Various SWIFT messages are automatically generated from outgoing FT transaction types. The OT
transaction can generate an MT202/MT103. The MT103 is the advice cable, when either the ordering

TEMENOS T24 User Guide Page 85 of 117

Funds Transfer

or receiver customer is not a banking institution. FT.TXN.TYPE.CONDITION field MESSAGE.TYPE

now allows the user to specify other such messages to be generated with specific transaction types.
When entered these will override the MT103 SWIFT message

Transaction OT can produce either a MT103 – Single Customer Credit Transfer or

MT400 – Advice of Payment

Where MESSAGE.TYPE is left blank, then a SWIFT message MT103 is presumed.

Transaction OD and OC now also have the option to issue a SWIFT advice.

MT103 Single Customer Credit Transfer

T24 is able to produce an MT103 from the FUNDS.TRANSFER application when OT transactions
are input. In order for this to happen, the OT record on application FT.TXN.TYPE.CONDITION
must have the MESSAGE.TYPE field set to 103.

Generation of MT102 - Multiple Customer Credit Transfer

This message is sent by or on behalf of the financial institution of the ordering customer(s) to a
financial institution in the country of the beneficiary customer(s).

It requests the Receiver to credit the beneficiary customer(s) directly or through a domestic clearing
mechanism via another financial institution in the receiving country, or to issue a cheque to the
beneficiary.

This message is used to convey multiple payment instructions between financial institutions for clean
payments. Its use is subject to bilateral/multilateral agreements between sender and receiver. The
message contains several transactions. This helps to group all the outward MT103 messages and to
send as a single MT102.

The MT102 consists of three sequences:

• Sequence A - General Information is a single occurrence sequence and contains information

which applies to all individual transactions described in sequence B.
• Sequence B - Transaction details is a repetitive sequence. Each occurrence is used to
provide details of one individual transaction.
• Sequence C - Settlement details is a single occurrence sequence and contains information
about the settlement.

TEMENOS T24 User Guide Page 86 of 117

Funds Transfer

From the FUNDS.TRANSFER application, individual MT103 messages can be suppressed and a
single MT102 can be sent using the NETTING application. Details for first sequence is supplied from
the NETTING application and details for repetitive second sequence is supplied from
FUNDS.TRANSFER.

Following are the set up and workflow related to grouping of MT103 messages and sending a single
MT102 (multiple customer credit transfer) from the FUNDS.TRANSFER.

Step 1: To group MT103 messages generated from FT application, the NETTING.PAYMENT field in
DE.PARM and DE.MESSAGE (for RECORD ID 103) has to be set to “Y”.

DE.PARM SYSTEM.STATUS– with NETTING.PAYMENT as “Y”

TEMENOS T24 User Guide Page 87 of 117

Funds Transfer

DE.MESSAGE with NETTING.ALLOWED as “Y”

Step 2: Add a record in NETTING.AGREEMENT for the Receiver of MT103. The ID of the Record
in NETTING.AGREEMENT should be the ‘CUSTOMER ID.102’. Criteria like settlement currency
and settlement amount may be specified in this record. In the field OPERATION.CODE, the user may
input the value CREDIT or CHQB so be defaulted into the MT102 generated. The default value is
CREDIT.

NETTING.AGREEMENT

TEMENOS T24 User Guide Page 88 of 117

Funds Transfer

Step 3: Input a few FT’s with NETTING.STATUS field as Null.

Standard FT processing occurs. When an FT is input with CREDIT.ACCOUNT as a Nostro account

and RECEIVER.BANK as Null, then an MT103 would be generated for the Nostro correspondent.
When an FT is input with CREDIT.ACCOUNT as a Nostro Account and with a value in the
RECEIVER.BANK, then an MT103 would be generated for the RECEIVER.BANK. In both cases, the
MESSAGE.TYPE in FT.TXN.TYPE.CONDITION should have been set to “103”. The system will
check FT transaction input on the criteria such as currency, credit account, value date, operation code,
etc against the details specified in the NETTING.AGREEMENT. If there is a match then the MT103
will be suppressed and the NETTING.STATUS field in the FT application is defaulted with ‘102’.

If the sender of the message would like cheques to be issued, in relation to messages included in an
MT102, to the Beneficiary instead of crediting an account, then field BK.OPERATION.CODE in the
FUNDS.TRANSFER application should be input with the value ‘CHQB’. Tag 23 of the MT102 would
then hold this value, but all sequences in that message must be for issuing cheques to the
Beneficiaries. If not the value input in this field in the FUNDS.TRANSFER application would default
‘CREDIT’ and Tag 23 in the MT102 would hold the value ‘CREDIT’.

Given below is one of the FT’s for which an MT102 is generated instead of an MT103.

TEMENOS T24 User Guide Page 89 of 117

Funds Transfer

FUNDS.TRANSFER with NETTING STATUS “102”

TEMENOS T24 User Guide Page 90 of 117

Funds Transfer

FUNDS.TRANSFER With NETTING STATUS “102”

A NETTING.ENTRY record is created when there is a NETTING.AGREEMENT between the

sender and receiver the message.

Each Funds transfer record for which an MT102 is to be generated; related detail from FT is stored in
NETTING.ENTRY. These details will be used by the CREATE.NETTING application. However,
the accounting entries will not be netted and will be generated when the FT is authorised.

TEMENOS T24 User Guide Page 91 of 117

Funds Transfer

NETTING.ENTRY DETAILS captured from FT

Step 4: To create the MT102, a record in the NETTING application must be created. This can be
done by, verifying a record in the application CREATE.NETTING; the ID of this record can be 1-10
alphanumeric characters. When inputting the selection criteria in CREATE.NETTING, it
crosschecks the records in NETTING.ENTRY and NETTING.AGREEMENT for details like
currency, settlement amount, value date, counter party, etc. For MT102, FUNDS.TRANSFER details
are grouped based on first sequence fields in MT102 - i.e. counter party (Receiver of MT103),
currency, value date, etc. The CREATE.NETTING record should then be verified.

TEMENOS T24 User Guide Page 92 of 117

Funds Transfer

CREATE.NETTING-with selection criteria

After verification, the system creates a NETTING record in HOLD status. In case there is only one FT
record, then an MT103 is generated from the NETTING application.

Step 5: Authorise the NETTING record for creation of an MT102 Message. Details that are defaulted
in a NETTING record from a FUNDS.TRANSFER cannot be amended or changed.

TEMENOS T24 User Guide Page 93 of 117

Funds Transfer

NETTING application details after authorization

On generating the MT102, delivery reference and date of creation is updated in NETTING for
reference. For more details about NETTING, please refer to the PAYMENT.NETTING chapter in
Accounts Interest & Charges User Guide.

TEMENOS T24 User Guide Page 94 of 117

Funds Transfer

Outward MT102 with A B and C Sequences

TEMENOS T24 User Guide Page 95 of 117

Funds Transfer

In case CREATE.NETTING is not verified during the day, then the COB process creates a record in
the NETTING application in HOLD status based on the records available in NETTING.ENTRY.
The NETTING records thus created have to be further processed by the User for generation of
MT102s.

Automatic MT110 Advice of Cheque(s)

T24 is able to produce an MT110 from the FUNDS.TRANSFER application when OC or OD

transactions are input. In order for this to happen, the OC or OD records on application
FT.TXN.TYPE.CONDITION must have the MESSAGE.TYPE field set to 110.

Automatic MT400 Advice of Payment

T24 is able to produce an MT400 from the FUNDS.TRANSFER application when OT transactions
are input. In order for this to happen, the OT records on application FT.TXN.TYPE.CONDITION
must have the MESSAGE.TYPE field set to 400.

Generation of MT203 -Multiple general Financial Institution Transfer

MT203 is a multiple message sent by or on behalf of the ordering institution directly, or through
correspondent(s), to the financial institution(s) of several beneficiary institution(s). The message
contains several transactions. This helps to group all the outward MT202 messages and to send as a
single MT203.

The MT203 consists of two types of sequences:

• The first sequence provides details of the transaction between the sender and receiver, i.e. the
value date and total amount to be transferred, as well as any other information about this
transaction, as necessary.
• The second sequence must appear at least twice and, in order to accelerate processing, not more
than ten times. It provides details of each transaction between the receiver and a financial
institution to which the funds will be transferred. Each sequence includes a TRN, the reference of
the related transaction, the amount and currency code to be transferred, the identification of the
beneficiary institution and any other institution(s) through which the funds will pass and any other
information about the transaction, as necessary.

From the FUNDS.TRANSFER application, individual MT202 messages can be suppressed and a
single MT203 can be sent using the NETTING application. Details for the first sequence are supplied
from the NETTING application and details for a repetitive second sequence are supplied from FT.

TEMENOS T24 User Guide Page 96 of 117

Funds Transfer

Following is the set-up and workflow related to grouping of MT202 messages and sending as a single
MT203 (Multiple General Financial Institution Transfer message) from the FUNDS.TRANSFER
application.
Step 1: To group MT202 messages generated from the FT application, the NETTING.ALLOWED field
in DE.PARM and DE.MESSAGE (for record id 202) has to be set to “Y”.

DE.PARM – with NETTING.PAYMENT as “Y”

DE.MESSAGE with NETTING.ALLOWED as “Y”

Step 2: Input few FT’s with the NETTING.STATUS field as Null.

To generate an MT202 from the funds transfer application, input FT’s with receiver bank or with
TXN.TYPE for which NOSTRO.XFER.TYPE in FT.TXN.TYPE.CONDITION is set to “202”.

In the above case, when a message 202 is to be generated from FUNDS.TRANSFER, the
NETTING.STATUS defaults to “203” and suppresses the MT202 message generation from the FT
application. However the accounting entries related to 202, are handled in FUNDS.TRANSFER
application itself.

TEMENOS T24 User Guide Page 97 of 117

Funds Transfer

Given below is one of the FT’s for which an MT203 is to be generated instead of an MT202. Input a
few more contracts to group MT202 to generate an MT203 for the credit customer, currency, value
date sender and receiver correspondent combination.

FUNDS.TRANSFER Contract with NETTING.STATUS as “203”

TEMENOS T24 User Guide Page 98 of 117

Funds Transfer

FUNDS.TRANSFER Contract with NETTING.STATUS as “203”

In this case an MT103 is sent to a customer specified in receiver bank and MT202 to be sent to credit
customer is suppressed and the NETTING.STATUS is updated with 203 indicating that it is selected
for 203.

TEMENOS T24 User Guide Page 99 of 117

Funds Transfer

Step 3: Add a record in NETTING.AGREEMENT for the receiver of MT203’s customer number with
SYSTEM.ID as “FT”.

For each funds transfer record for which a 203 is to be generated, a 202 related detail from an FT is
stored in NETTING.ENTRY, which will be used in the next step.

NETTING.ENTRY details captured from FT

Step 4: Verify the CREATE.NETTING application with the selection criteria. For an MT203, funds
transfer details are grouped based on first sequence fields in MT203, i.e. counter party (receiver of
MT202); currency; value date; sender correspondent and receiver correspondent combination.

CREATE.NETTING-with selection criteria

TEMENOS T24 User Guide Page 100 of 117

Funds Transfer

After verification, the system creates a NETTING record in Hold status. For the above selection
criteria, from NETTING.ENTRY, for more than one record and up to 10 FT records, a single MT203
is created. In case a single FT record is selected, then an MT202 is generated from the NETTING
application.
Step 5: Authorise the NETTING record for creation of an MT203 Message. Details, that are
defaulted in NETTING from FUNDS.TRANSFER cannot be amended or changed.

On generating the MT203/202, delivery reference and date of creation is updated in NETTING for
reference. For more details about Netting, please refer to the PAYMENT.NETTING chapter in the
Accounts User guide.

TEMENOS T24 User Guide Page 101 of 117

Funds Transfer

NETTING application details after authorization

TEMENOS T24 User Guide Page 102 of 117

Funds Transfer

Outward MT203 message with sequence A & B

TEMENOS T24 User Guide Page 103 of 117

Funds Transfer

Outward MT203 message with sequence A & B

To populate sender to receiver information (tag 72) for first sequence, details can be given in the
NETTING application and BK.TO.BK information given in the respective FT’s is used for a second
sequence. The sum of amounts for tag 19 is calculated by adding all the FT credit amounts.

In case CREATE.NETTING is not initiated during the day, then the Close of Business batch process
creates a record in the NETTING application in Hold status based on the records available in
NETTING.ENTRY.

To generate an MT202 from the FUNDS.TRANSFER application, when the NETTING.ALLOWED flag
is set in DE.PARM and DE.MESSAGE, the NETTING.STATUS in FT should be changed to “NO”
during input stage.

To suppress 203 from the STANDING.ORDER field NETTING.STATUS can be set to “NO” and it is
mapped to the NETTING.STATUS field in FT.

Interfaces
Delivery
The interface to the delivery application allows various kinds of payment documents to be produced -
cheques, drafts, telexes, SWIFT messages and local electronic clearing. The data made available to
delivery is defined in DE.MAPPING. Where required, the system can produce ‘cover’ telexes or
SWIFT messages in addition to payment messages. Advice documents such as cover advices for
cheques can similarly be produced via the delivery application.

Incoming electronic messages can be mapped to produce FT transactions. These transactions may
be generated unauthorised for further input and authorisation, or may not require authorisation and be
completely automatic. Such incoming transactions may even generate outgoing messages as well,

TEMENOS T24 User Guide Page 104 of 117

Funds Transfer

especially if you are operating as a correspondent bank. The application to process these is
FT.IN.PROCESSING.

The outgoing delivery messages can be previewed and printed even before the FUNDS.TRANSFER
record is authorised. The user may click the Delivery Preview button after entering the transaction
details which would validate the input and display DE.PREVIEW with the list of delivery messages
that would get generated for the transaction. Clicking again on the message type, the user can
preview the delivery message and can even print the message, if necessary.

DE.PREVIEW showing delivery messages for the FUNDS.TRANSFER transaction

Scheduling the delivery messages for a future date can be done using the field MSG.DATE in
FUNDS.TRANSFER application for each of the message type. When the messages are scheduled
for a future date, delivery reference will get updated in the field DELIVERY.OUTREF in FT, upon
actual generation of the message on reaching that date.

Accounting
Accounting is carried out on-line. ACCOUNT balances and LIMIT records are checked on input and
override messages are produced as and when necessary.

Local Clearing
There are interfaces to local clearing for both outgoing and incoming transactions. There are final links
to the external interface, which are specific to the country in question, but some aspects are
independent of the country. Details of how funds transfer links to the local clearing application are
contained on FT.BC.PARAMETER and FT.LOCAL.CLEARING.

TEMENOS T24 User Guide Page 105 of 117

Funds Transfer

Default amount limits, charges, tax and bulk transaction types are defined on FT.APPL.DEFAULT.
Further definitions of transaction codes, commission, charge codes and date limits are defined on
FT.BC.TXN.CODE. Sort codes are held on BC.SORT.CODE.

BULK CREDIT / DEBIT

The FT bulk debit and credit was written using EB.TABLE.DEFINITION
(EB.TABLE.DEFINITION is a utility for clients to build and support their own applications) and is
provided in the user guide as a template only to show what functionality is available using this tool.

It is now possible to achieve the following functionalities for the generation of FUNDS.TRANSFER
records:
• 1 Credit against Multiple Debits or Multiple Credits against 1 Debit.
• Outward payments, internal transfers and cheque payments.
• Validate Credit and Debit totals.
• Calculate single side amount if left blank.
• Calculate currency amount where the credit currency and debit currency differ.

This is achieved by using the following applications. Please take note that the accounting entries,
position updates, profit / loss entries, delivery etc will be handled only from the FUNDS.TRANSFER
application side.

1. FT.BULK.CREDIT.AC - This application is used to transfer funds between accounts maintained

at the same Company. This application allows multiple credits of a common currency against one
debit of either the same currency as the credit currency or any other currency. When such
transfers involve two different currencies, the exchange rate if not input, would default from the
currency table. The debit amount will be calculated by the system if left blank. On authorisation of
this record, individual FTS of AC Transaction type are created.

TEMENOS T24 User Guide Page 106 of 117

Funds Transfer

FT.BULK.CREDIT.AC

FUNDS.TRANSFER – FT04026001000003

TEMENOS T24 User Guide Page 107 of 117

Funds Transfer

2. FT.BULK.DEBIT.AC - This application is used to transfer funds between accounts in the same
company. It allows multiple debits of a common currency and a single credit either of the same
currency or any other currency. When such transfers involve two different currencies, the
exchange rate, if not input, would default from the currency table. The credit amount will be
calculated by the system if left blank. On the authorisation of this record, individual FTS of AC
Transaction type are created.

FT.BULK.DEBIT.AC

TEMENOS T24 User Guide Page 108 of 117

Funds Transfer

FUNDS.TRANSFER - FT03111001000007

TEMENOS T24 User Guide Page 109 of 117

Funds Transfer

FUNDS.TRANSFER - FT03111001000007

3. FT.BULKCR.OT - This application is used to make bulk payments, that is one debit against
several credits of a common currency to a beneficiary/beneficiaries who does not maintain an
appropriate account relationship and where, usually, the Bank will credit its nostro account(s)
(foreign currency payment) or clearing/nostro account(s) (local currency payment) to execute
payment(s). This application when authorised, will create an FTS with OT transaction type, from
which pay or cover cables can be generated automatically. Netting of these messages is possible.
Please refer to the details given above for netting of MT103 and MT202 Messages.

TEMENOS T24 User Guide Page 110 of 117

Funds Transfer

FT.BULKCR.OT

TEMENOS T24 User Guide Page 111 of 117

Funds Transfer

FUNDS.TRANSFER – FT04027001000003

4. FT.BULKDR.OT - This application is used to make bulk payments, that is multiple debits of the
same currency against one credit either in the same currency or in a different currency, to a
Beneficiary who does not maintain an appropriate account relationship and where usually the
Bank will credit its Nostro account (foreign currency payment) or Clearing/Nostro account (local
currency payment) to execute payment. This application, when authorised, will create FTS with OT
transaction type from which pay or cover cables can be generated automatically.

TEMENOS T24 User Guide Page 112 of 117

Funds Transfer

Netting of these messages is possible. Please refer to the details given above for netting of
MT103 and MT202 messages.

FT.BULKDR.OT RECORD - BKOT0307600008

TEMENOS T24 User Guide Page 113 of 117

Funds Transfer

FUNDS.TRANSFER - FT03111001000010

TEMENOS T24 User Guide Page 114 of 117

Funds Transfer

FUNDS.TRANSFER - FT03111001000010

5. FT.BULK.CREDIT.OC - In this application, one debit supports several credits for the issuance
of cheques drawn on the Nostro correspondent(s). It allows the input of credits to different
correspondents having the same currency.

TEMENOS T24 User Guide Page 115 of 117

Funds Transfer

FT.BULK.CREDIT.OC - BKOC0307600007

TEMENOS T24 User Guide Page 116 of 117

Funds Transfer

FUNDS.TRANSFER – FT04027001000005

TEMENOS T24 User Guide Page 117 of 117