T3TFT - Funds Transfer - R12.01

T24 Funds Transfer
TEMENOS EDUCATION CENTRE

NOTICE
These training materials are the copyrighted work of Temenos Headquarters SA and other companies in the
TEMENOS group of companies (The Copyright Owner). The training materials contain protected logos, graphics and
images. Use of the training materials is restricted solely for use by licensed end users, partners and employees. Any
un-licensed reproduction by any means, redistribution, editing, transformation, publishing, distribution, or public
demonstration of the training materials whether for commercial or personal gain is expressly prohibited by law, and
may result in severe civil and criminal penalties. Violators will be prosecuted to the maximum extent possible. Such
training materials shall not be represented, extracted into or included in part, or in whole, as part of any other training
documentation without the express permission of the Copyright Owner, which must given in writing by an authorised
agent of the Copyright Owner to be valid. Where such permission is given a clear and prominent notice must be
displayed on any and all documentation accrediting the Copyright Owner with having copyright over the materials.
End-user licenses will in no event contain permissions extending the use of these training materials to third parties
for commercial training purposes.
Without limiting the foregoing, copying or reproduction of the training materials in part or in whole to any other sever
or location for further reproduction or redistribution is expressly prohibited, unless such reproduction is expressly
licensed by the Copyright Owner.
Copyright © 2010 Temenos Headquarters SA
Funds Transfer - Objectives
 Overview
 Linkage of Funds Transfer with static tables
 Application specific Parameter tables
 Funds Transfer build sequence
 Product features
 Standing orders
Slide 2
Funds Transfer – Product overview
Customer Account to
Accounts Account transfer
Funds Transfer Drafts,

Internal Bankers cheques
Accounts
International
Limits Profit & Loss
remittances
Items
Delivery
Accounting SWIFT messages Outward FT
Customer Advices Inward FT
Slide 3
FT dependencies
 FT makes use of
 CUSTOMER
 ACCOUNT
 Core dependencies
 Delivery
 Accounting
 Limits
 FT also uses other Static tables
Slide 4
FT dependencies – Product related
 FT application used to transfer money between Customer type of

accounts, internal accounts and PL Categories
 Customer type of accounts use 1000 to 9999 range of Category codes
 Internal accounts use 10000 to 19999 range of Category codes

 Internal accounts needed for handling Cash and Travellers’ cheques
 PL category codes use Category codes above 50000
Slide 5
FT dependencies – Charges and Commissions
In FT, Commission can be

optionally made
applicable only when
FX conversion is involved
(CCY.CONV.DEPENDENT)
Commissions for specific

FT operations can be
collected by linking through
FT.TXN.TYPE.CONDITION
TAX can also be included

with Charges and
Commissions using
TAX.CODE field here
Slide 6
FT dependencies – Charges and Commissions
In FT.CHARGE.TYPE,
either a flat charge structure
Or
Zone based structure
can be set up
and linked to FT through
TAX can be included

through TAX.CODE Field
Slide 7
FT dependencies – settlement related
NOSTRO.ACCOUNT generally defined

Currency and Application wise.
NOSTRO.ACCOUNT For FT, can be defined Transaction type
wise also.
For Inward payments in FT, Nostro account
defaulted in DEBIT.ACCT.NO Field.
For Outward payments in FCY FT, Nostro a/c
defaulted in CREDIT.ACCT.NO Field, if left blank
AGENCY defined Customer wise

AGENCY For Outward payments in LCY FT, if AGENCY
for VOSTRO option
is set up, then Receiving Bank Vostro account
defaulted in CREDIT.ACCT.NO Field
Customer account to be debited for Charges /

CUSTOMER.CHARGE Commission in case of FT. If defined, defaults to
CHARGES. ACCT.NO Field in FT
Slide 8
FT dependencies – Auto-routing agreement
 AGENCY record to set up Standard settlement instructions
 Auto routing instructions can be recorded Currency and Application wise for
any Customer
 Issue of Cover Payment when there is no Nostro / Vostro account

relationship with receiver of payment instructions
Cover via MT 202 message
 Cover message instructions can be set by AUTOROUTE.AGRD Field

Blank – MT 202 message will contain details of both the Sender’s
Correspondent and Receiver’s Correspondent
NO – MT 202 message will contain details of only Sender’s
Correspondent
YES - An agreement exists, and cover payment is suppressed.
Additionally, only the receivers correspondent will be populated
Slide 9
FT dependencies - Currency related
COUNTRY
CURRENCY.PARAM
CURRENCY CURRENCY.MARKET
Buying and Selling exchange rates defaulted based on Currency market chosen.
Buying rate if FCY is Debit currency and Selling rate if it is Credit currency
For a specific type of Funds transfer, if a market is specified in
FT.TXN.TYPE.CONDITION, that will be used to default exchange rates for the deal
Slide 10
FT dependencies – Currency fixing
 In some countries, Exchange rate for major currencies are "fixed" daily
by local Central Bank
 Banks need this rate for applying to transactions
 FIXING.DATE Field in CURRENCY table identifies date on which the

exchange rates were last loaded
 Used only for currencies part of fixing group
 FT checks value of FIXING.DATE Field on the run day

 If fixing rates are not available, transactions needing the fixed rate will
generate an error message, which leads to RATE.FIXING Field with Yes
and No options.
 If Yes is opted, transactions processed using the last available rate
 If No is opted, transaction can be authorised but will be flagged with specific
status of ANORATE
After new fixed rate is available, by running FT.RATE.PROCESS service,
these records will be processed with the new fixed rate and accounting
entries will be passed
Slide 11
FT dependencies – Cut off time
 Possible to define a cut off time in CURRENCY table for automatically

defining value date for Funds transfers
 Rule can be different for different Currencies
 Cut off time entered in CUT.OFF.TIME Field in CURRENCY record
 Depending on transaction entry time, value date defaulted
FT after14.00 hrs can be set to default value date of next day
 For outgoing FT
 Cut off time set for specific Currencies is used with CUT.OFF.RULE Field
definition set in AGENCY record for specific customers
CUT.OFF.RULE set to 0 will move value date by one day
CUT.OFF.RULE set to 1 will move value date by one more day
 These two fields together will calculate DEBIT.VALUE.DATE
 For other situations, FT.TXN.TYPE.CONDITION rules apply
Slide 12
 For outgoing Funds Transfers

 Depending on rules for Debit Currency and Debit Customer, Debit value
date is defaulted
Slide 13
 For incoming Funds Transfers

 Depending on Cut off time rules for Credit Currency and whether Debit and
credit currencies are same, the Credit value date is defaulted
Slide 14
Quiz - 1 – Mark True or False
1) FUNDS.TRANSFER can be used to move funds between Accounts

contracts and Profit and loss items
Ans: False
2) FT.COMMISSION.TYPE is used for collecting commission for FT as
well as other applications
Ans: True
3) Tax on charges and commission collected by defining in
FT.COMMISSION.TYPE
Ans: True
4) It is possible to define one Nostro account for Inward FT and another
Nostro for outward FT
Ans: False
5) NOSTRO.ACCOUNT records are defined for standard settlement
instructions of Customers
Ans: False
Slide 15
Quiz - 1 – Mark True or False
6) Cover Payment is issued when there is no Nostro / Vostro account

Ans: True
7) When Debit currency is Foreign currency in FT transaction, selling rate
is used
Ans: False
8) Up to 99 different markets can be defined in T24 for exchange rate of
Currencies
Ans: True
9) If we want to set a cut off time for automatically defining value date of
FT transactions, it should be set in AGENCY table
Ans: False
10) Cut off time can be set different for different customers by using
AGENCY table
Ans: False
Slide 16
Application specific Parameters
Slide 17
FT - Parameter tables
 Parameter tables for FUNDS.TRANSFER to be set-up during

implementation
 FT.TXN.TYPE.CONDITION
 EB.DUPLICATE.TYPE
 FT.APPL.DEFAULT
 CONDITION.PRIORITY
 FT.GEN.CONDITION
 FT.GROUP.CONDITION
 CORR.BANK.CHARGES
 BENEFICIARY
Slide 18
STO - Parameter tables
 Parameter tables for STANDING.ORDER to be set-up
 STO.TYPE
 STO.BULK.CODE
 ACCOUNT.CLASS
SUSPFTBULK
SUSPFTINWD
Slide 19
 Default conditions for Standard and Custom defined Transaction Types

for FT and STO applications
 Separate record for each transaction type
 Id can be up to 4 characters of which first 2 alpha characters should be one

of the standard transaction type
 There are 13 pre-defined standard transaction types of 2 alpha characters

covering Outgoing payments, Incoming payments, Direct debits and Internal
payments
 User can define any number of further payment types through

FT.TXN.TYPE.CONDITION, they are automatically identified as part of
respective standard type whose Id is used as first 2 characters
Slide 20
 Standard Outgoing payment types

 OC Outward by Cheque in local currency
 OD Outward by Draft (usually foreign currency)
 OT Outward by Telex or SWIFT
Produces pay and cover cables automatically when required
 OB Outward by Bankers Payment (inter bank payment)
Used extensively in UK to perform local currency inter bank payment
 BC Outward by local clearing
 Standard Incoming payment types

 IC General Incoming payment by Cheque or Draft
 IT Inward by Telex or SWIFT
 IB Inward by Banker’s payment
 IM Inward by Mail transfer
 BI Inward by local clearing
Slide 21
 Standard Direct debits

 BD Inward direct debit by Local clearing system
 Standard Internal payment types

 AC Account to account transfer
 DW Direct drawing – Transfer by correspondent banks
 User defined payment types

 ACCL, ACMD, OC10, OT03, IT01
 Using these payment Types, funds can be transferred

 within the branch and between branches
 between banks internationally and via Local Clearing
 by cheques to beneficiaries or for the bank’s own payments to suppliers or
even settle expense claims to employees
Slide 22
 FT.TXN.TYPE.CONDITION is set up for each type of transaction, with

transaction codes, default charges and commissions, defining value
dates and generation of advices
 Transaction codes defined through Fields

 DR.CHEQUE.TXN.CODE for debits through cheques drawn on bank
 TXN.CODE.CR and TXN.CODE.DR for credit and debit entries generated
by Fund Transfers (other than cheques)
 STO.TXN.CODE.CR and STO.TXN.CODE.DR for credit and debit entries
generated by Standing orders
 BULK.TXN.CODE.CR and BULK.TXN.CODE.DR for credit and debit entries
generated in a Bulk Standing order
 DR.CHARGE.TXN.CODE for debiting charges
Slide 23
 Default Charges and commissions

 Pre-defined charges and commissions can be defaulted for this type of
transaction by defining in COMM.TYPES and CHARGE.TYPES multi value
Fields
 It can be multi valued to include other charges and commissions
 Value date restrictions

 FORW.VALUE.MAXIMUM Field to indicate the maximum period of Forward
Value/exposure acceptable for this type of transaction without generating an
override
 Y to indicate run date. N or No when no special maximum needed
+01C to indicate number of calendar days forward
+02W to indicate number of working days forward
+01W+02C to indicate 1 working day plus 2 calendar days forward
 This prevents the operator from inputting a Value date or an Exposure date
which exceeds an acceptable period for this type of transaction
Slide 24
 Value date restrictions

 BACK.VALUE.MAXIMUM Field to indicate the maximum period of Back
Value/exposure acceptable for this type of transaction without generating an
override
Y to indicate run date. N or No when no special maximum needed
-01C to indicate number of calendar days backward
-02W to indicate number of working days backward
-01W-02C to indicate 1 working day plus 2 calendar days backward
 This Prevents the operator from inputting a Value Date or an Exposure Date
which exceeds an acceptable period for this type of transaction
 Date specified in this field should not result in being earlier than the Back
Value Maximum as specified in DATES file and date specified in
FORW.VALUE.MAXIMUM Field, not later than Forward value maximum
specified in DATES file.
Slide 25
 Customer float options for specific types of payments
 Possible to choose Customer float periods, by having different value dates

for debit and credit
 Customer float can be opted on all transactions or rules can be set

separately for transactions involving conversion of one currency into
another and transactions not involving any such conversion
 PAYMENT.TYPE Field can be set as CONV, NOCONV or ALL

CONV for transactions involving conversion of currencies only
NOCONV only for transactions which do not involve any conversion
ALL for all types of transactions
If CONV is chosen, NOCONV rules also to be defined and vice versa
If ALL is chosen, then other rules cannot be defined
Slide 26
FT.TXN.TYPE.CONDITION – Customer float options
 For a chosen Payment type, value date can be defaulted by using

PAYMENT.VALUE Field
 Value Date can be set as either the Processing Date, or a number of

working or calendar days to be added to or subtracted from the Processing
Date
Y or -01C or +03W or +02C+01W or -01C-01W
 Value date for the Customer could be defaulted as a different date by using
CUSTOMER.FLOAT Field, giving a float of funds for the bank
P for processing date or 0 to 9 to indicate the displacement.
If 2 is indicated here, Value date for Customer credit is 2 days after
Debit value date for incoming transfers; value date for Customer debit is 2
days before Credit value date for outgoing transfers
 Different float can also be set when debit and credit accounts belong to the
same Customer using SAME.CUST.FLOAT Field
Slide 27
FT.TXN.TYPE.CONDITION – Delivery related options
 Delivery message options available for Print and Swift medium
 Debit advice generation could be controlled through

DR.ADVICE.REQD.Y.N Field
 If no input is specified in this field, in case of OC, OD, OT, OB, BC
transaction types, a debit advice will be generated by default
 Credit advice generation could be controlled through

CR.ADVICE.REQD.Y.N Field
 If no input is specified in this field, credit advice will not be generated
 To use SWIFT BIC addresses in appropriate bank Fields,

SWIFT.ADDRESS Field must be set as YES
 In FT, ORDERING.BANK, ACCT.WITH.BANK, BEN.BANK,
REC.CORR.BANK, INTERMED.BANK Fields can also be entered as “SW
—”, indicating SWIFT address, instead of Free text or Customer Id
Slide 28
 When user defined Transaction types are used,

APPLICATION.FORMAT Field can be used to indicate a value of “FT”
or “FT” followed by four numeric characters
 Input in this field can be used to create a record in DE.FORMAT.PRINT (as
the second part of Id)
Each record here defines a format for a printed document
Thus transaction types of OT01 and OTAB can be set to have different
print formats of a single message type, say Customer Payment advice
and this can be different from Transaction type OT
Slide 29
FT.TXN.TYPE.CONDITION - MT 200 and 202
SWIFT Description FT Transaction

Type
MT 200 Financial Institution transfer for own account OT
MT 202 General Financial institution transfer
Instead of
200 Banks
may like to
send 202 for
additional
T24 Bank information
MT 200 MT 202 Additional

details in
MT 202
Payment 53a Sender /
Ordering
institution
58a
Beneficiary
Institution
Our GBP Nostro Our USD Nostro
Account with Account with
Barclays London Bank of NY
Slide 30
 A bank may like to effect transfers between two of its own Nostro
accounts or transfer from its Nostro to some other account. Accordingly
message generation has to be MT 200 (Transfer for own account) or
MT 202 (General transfer)
 Such transfers are handled through OT type of transaction
 Different records with prefix of OT are created to handle different situations
 NOSTRO.XFER.TYPE Field in those records could be optionally set as

200 or 202 or left blank
 Value of 200 (or null) will generate MT200 messages as normal
 202 will enable additional input of Beneficiary and Ordering fields in FT for
transfers between Nostro Accounts
Slide 31
FT. TXN.TYPE.CONDITION - MT 103 and MT 202

Type
MT 103 Single Customer credit Transfer OT
MT 202 General Financial institution transfer OT
T24 Bank
Michael Dell
Debit advice
MT103 MT202
Instruction
Payment
Mr Frank Bishop Frank Bishop’s

Banker Grindlays Bank, London
Slide 32
 In the case of outward transfers (Transaction type of “OT”), normally

Swift message MT 202 is to be sent in case of institutional payments
and MT 103 in case of customer payments
 Accordingly, depending on the owner of the debit account, System will

fill ORDERING.BANK or ORDERING.CUSTOMER Fields in a FT and
send MT 202 or 103
 Even when the client of debit account is not a bank, if MT 202 message
is to be sent indicating an ORDERING.BANK for a transaction type,
then BANK.PAYMENT Field in FT.TXN.TYPE.CONDITION should be
set as “Y”
 ORDERING.BANK and BENEFICIARY.BANK Fields to be filled and
ORDERING.CUSTOMER Field should be left blank in FT transaction
Slide 33
 For outward transfers meant for beneficiaries other than banks, Tag 59
of MT 103 Swift message will contain beneficiary name
 To ensure that these details are mandatorily provided in such cases,
NO.BEN.CUST.Y.N Field could be set as Yes, by which BEN.CUSTOMER
Field in FT will be mandatory
 Where the Bank has to pay funds to a client using only an account
number and not beneficiary name, account number entered in FT is
mapped as Beneficiary name
 To enable this, BEN.ACCOUNT.ONLY Field in FT.TXN.TYPE.CONDITION
of such OT type of funds transfers should be set as “YES”
 No or blank implies that FT requires a beneficiary customer name / text
 Normal practice is to have Name with optional account number
Slide 34
FT. TXN. TYPE. CONDITION - MT 110

Type
MT 110 Advice of Cheque OC, OD
Draft / Banker’s
Cheque
Michael Dell Instruction T24 Bank
Draft / MT 110
Banker’s
Cheque
Draft / Banker’s
Cheque
Our GBP Nostro account

Mr Frank Bishop Payment with Barclays London
Slide 35
FT. TXN. TYPE. CONDITION - MT 400

Type
MT 400 Advice of payment OT
Intimation
Michael Dell Payment

Importer T24 Bank
Forwards the MT 400

Collection bill
Instruction to collect
export bill
Mr Frank Bishop Payment Barclays London

Exporter
Slide 36
 Outward transfers possible to indicate one out of three Swift message

types
 103 to instruct a Funds transfer of Single Customer Credit Transfer
 110 to advice or confirming issuance of a cheque to Drawee bank
 400 to advice payment of a collection or part thereof
 When message type is set as110 or 400 BANK.PAYMENT should not

be set as "Y", substituting MT103 by MT202 does not arise
 If MESSAGE.COND.ID Field is set as 210 for a Funds transfer type

starting with ‘I’ or ‘O’, FT of this type will produce MT210 message
 Helps create separate type of FT for generating MT210 message
(Institutional payment – to notify the receiving bank that receiving bank will
receive funds for sender’s account)
Slide 37
 From inward SWIFT payments MT200 or MT202, depending on the

transaction type, it is possible to send on-forwarding MT205 (further
transmission of a transfer request domestically) or MT202 (movement
of funds between financial institutions) messages automatically
 FWD.IN.TXN Field can be used for indicating one of three options

 “YES” to generate messages, “NO” to block messages
 202 to generate MT202 instead of On-forwarding MT205 message
 If SEND.PAYMENT.Y.N Field is set as Yes, in the case of “OB”

transaction type (Outward by Bankers Payment - inter bank payment),
System will default ‘Yes’ in SEND.PAYMENT Field in Funds Transfer
record.
 This will trigger to send MT210 message, notifying the receiver that it will
receive funds for the sender’s account
Slide 38
 Currency rate related options
 Allowing Two different currencies for debit and credit sides can be
controlled through ALLOW.EXCHANGE Field
If set as 'Y‘ or left blank, different currencies are allowed
If set as ‘N’, debit and credit currencies have to be same currency
 Possible to indicate a pre defined Currency market through

DEFAULT.DEAL.MKT Field, if this transaction type allows different
currencies for debit and credit sides
This rate will be indicated in FT in DEAL.MARKET Field and used for
processing transaction
Slide 39
 Currency rate related options
 A Funds transfer can be input now, but set to be processed on a future

date. Till the processing date, it will be treated as forwards until a batch
program is run to process it
Such a transaction can be input or Authorised as normal and will be
identified with specific Funds Transfer status codes of IFWD or AFWD
 In such cases, it is possible to take exchange rate as at the processing date

rather than the rate of input date / time
 RECALC.FWD.RATE Field is used to control such processing, and is used

to populate value in RECALC.FWD.RATE Field on Funds Transfer record
Where the user has manually entered a rate on the Funds Transfer, rate
input by the user is retained
Slide 40
 Duplicate deal checking
 It is possible to set rules for checking whether a FT transaction is likely to be

a duplicate of another similar transaction by setting rules in
EB.DUPLICATE.TYPE
If debit amount, debit account and debit value dates are same, warns
about possible duplication
 In FT.TXN.TYPE.CONDITION, for a given transaction type, we can stipulate

which records of EB.DUPLICATE.TYPE are to be considered as applicable
for duplicate checking by indicating their record Ids in DUPLICATE.CHECK
multi value Field
Slide 41
 Recording expected receipts
 Banks are often advised of details of incoming funds by other institutions or

clients. Against this information the bank may like to allow overdrafts /
payment.
 The 'expected receipt’ information can be entered manually or automatically

created by incoming SWIFT MT210 which could later be matched with
actual receipt
 If AC.EXPECTED.RECS records of RECEIPT type is desired to be created

automatically, EXPECTED.RECS Field of FT.TXN.TYPE.CONDITION
should be set as ‘Yes’
Applicable only for transaction types beginning with “IT”
Values allowed are blank, No or Yes. Only Yes will activate creation of
records at authorisation for credit accounts set to use
AC.EXPECTED.RECS processing
Slide 42
 History reversal
 FT records are moved to History during Close of business
 To reverse the FT records which are in History, HIS.REVERSAL Field of

respective TXN.TYPE. CONDITION should be set as "YES"
As Funds would have already been transferred, this option to be chosen
only for those types where the Bank will have a control over getting back
the funds, like an internal transfer
When a FT record in History is reversed, it cannot be restored again.
 When HIS.REVERSAL flag is NULL then the FT record cannot be reversed

after moving to History
Slide 43
 Incoming charges
 Bank may receive charges and commission even in the case of incoming
FT from the remitting bank through MT103 (as specified in Tag 71 g)
 During automatic processing, the System needs to account them suitably to

a PL head using suitable transaction codes
 Pre-defined FT.CHARGE.TYPE can be indicated in IN.CHG.CODE Field of

respective incoming payment type
Adequate to define only Category and Transaction codes. Charge
calculations may be left blank
 In case this is not defined, FTs resulting out of MT103 message with tag
71g, will be kept in Hold status with IN.PROCESS.ERR
Slide 44
 Others
 ALLOW.POST.CLOSE Field to be set as “Y” to enable inputting entries in a

previous financial year even after financial closing is over, but within the
post closing period
 Normally debit value should be equal to or prior to credit value date. In case
it has to allow otherwise also, DB.AFTER.CR Field should be set as “YES”
Useful to pass value date corrections
Allowed only for AC type of transactions
 DB.A.CR.MAX.DAYS Field can be used to indicate the maximum number of

Calendar days for such events
The debit value date must not be after the credit value date plus the
number of days defined in this field
Useful to limit any possible mistakes while entering debit value date
Slide 45
EB.DUPLICATE.TYPE
 EB.DUPLICATE.TYPE
 Rules for checking whether a FT transaction is likely to be a duplicate of
another similar transaction
 Id is alpha numeric. Can be designed to reflect nature of rules
 FTREMIT for duplicate checking in FT used for remitting
 Application for which duplicate check is intended should be indicated in

APPLICATION Field
 Field values that are to be compared for determining whether the

transaction is duplicate or not is indicated in multi value Fields
 If DEBIT.AMOUNT and DEBIT.ACCT.NO are indicated, a transaction will be
termed as duplicate, if only its debit account as well as amount are the
same as of another transaction
Slide 46
EB.DUPLICATE.TYPE
 One or more records of EB.DUPLICATE.TYPE can be attached to

required FT.TXN.TYPE.CONDITION records
 When the first FT of the chosen transaction type is input, System

creates a record in EB.DUPLICATE
 Id depends on Fields defined in EB.DUPLICATE.TYPE
 GBP*23701*1100.00 if Currency, Debit account number and amount have
been selected
 When a transaction is input, system checks EB.DUPLICATE for similar Id,
and if present, generates override and when approved, records details of
that transaction also in EB.DUPLICATE
When another transaction matches these definitions, it records details of
that also
 PURGE.DAYS Field of EB.DUPLICATE.TYPE

 Details retained for comparison for the period defined
Slide 47
Workshop - 1
 Create a new Duplicate check condition by using a command line with

the following requirements:
 If TRANSACTION.TYPE, DEBIT.AMOUNT and DEBIT.ACCT.NO are same
in FUNDS.TRANSFER application, then System should warn about
possible duplicate.
 Records to be purged after 2 days
 Commit and authorise the record
 Using the command line

 Attach this record to FT.TXN.TYPE.CONDITION record with Id AC
 Commit and authorise the record
Slide 48
Workshop – 1 Solution
Slide 49
FT.APPL.DEFAULT
 This table is used to set Company level default values to be used when
processing FT or Standing Order instructions
 One record for each Company should be set up
 These defaults are applicable across all Transaction types
 Limit amounts
 AUTO.PROCESS.LIMIT Field to define amount in local currency, below
which incoming transactions received direct from Delivery can be processed
automatically as authorised or unauthorised record, as per set up
If the transaction amount is greater than this Limit amount, FT transaction
will be put in Hold status (IHLD), like any other incomplete message
received from Delivery
For Foreign currency transactions, local currency equivalent of debit side
is used for comparing with this limit amount
Slide 50
FT.APPL.DEFAULT
 Limit amounts
 LESS.CHARGES.LIMIT Field to define the amount, in local currency, below

which instructions for outgoing payments should not be accepted to pay on
a Less Charges basis (where the charges are to be deducted from the
credit)
Used to highlight transfers resulting in charges being greater than, or a
disproportionate amount of, credit entry - like where Charges exceed the
payment amount.
Override produced at transaction level
Slide 51
FT.APPL.DEFAULT
 Charges related
 CLAIM.CHARGES.ACCT Field to define Suspense Account to be debited

when charges are to be claimed from the ordering bank
 When this local currency Internal account is input as the Charge Account
number in a FT transaction, a Claim Charges advice sent to ordering bank
automatically
 Bank may be required to send non-tested message to beneficiary in

addition to sending tested message to Correspondent bank
SECONDARY.TLX.CHG Field can be used to define FT.CHARGE.TYPE
code to be applied for cover and free format telex messages that are not
prime payment cable. It is taken in addition to normal charges entered in FT
Taken when fields FREE.TEXT.MSGTO and MESSAGE are used in FT to
send free text messages
Slide 52
FT.APPL.DEFAULT
 Charges related
 Charges based on Bank’s own clients can be specified in

 Possible to default charges based on the Correspondent, either the

Receiving bank or Credit customer in the case of Outward transfer and
sender in the case of inward messages
Defaulting of charges applicable only for MT103 messages
DEF.CORR.BANK.CHGS Field in FT.APPL.DEFAULT to be set as ‘YES’
CORR.BANK.CHARGES application to be set up for each Correspondent,
and optionally transaction type, to indicate charges and/or commission
details to be defaulted
Slide 53
FT.APPL.DEFAULT
 Currency fixing related
 NO.RATE.DELIVERY Field is used to indicate whether physical delivery for

outgoing payments could take place even before the day’s fixing rates have
been loaded
In some countries, for some currencies, the rates are Fixed by Central
Bank and it may take some time to load the day’s rates
This facility is useful to process Funds Transfer transactions in case the
day’s Fixed rates are not yet loaded
 If “Y” is indicated in this field, delivery message for actual payment will take
place in FT when Commission and charges are either waived or collected
from the debit account
 If “N” is indicated in this field, Payment message will not be delivered till
Fixing rates are loaded in the Currency table
Slide 54
FT.APPL.DEFAULT
 Exchange rate related
 Marketing exchange profit / loss of FT department can be posted as opted

in MKT.EXCH.METHOD Field
If the field is left blank or STANDARD is opted, difference between
CUSTOMER.RATE and TREASURY.RATE, which is the
CUSTOMER.SPREAD is posted as local currency equivalent
System uses the BUY / SELL rate according to nature of transaction and
Treasury spread to arrive at TREASURY.RATE
If MIDDLE is opted, difference between credit and debit amount local
equivalents is posted, where the local equivalents of the two sides are
calculated independently according to respective Currency markets
 Profit / Loss posted to PL Category indicated in ACCOUNT.CLASS with Ids

FTMKTEXCHCR / FTMKTEXCHDR, and in their absence to MKTEXCHCR
/ MKTEXCHDR
Slide 55
FT.APPL.DEFAULT
 Exchange rate related

 If Rate fixing functionality is desired, RATE.FIXING Field should be set as
“YES” . It is defaulted to RATE.FIXING Field in FT but can be changed to
NO there.
If it is set as Null here, RATE.FIXING Field in FT will get a default value
NO and this cannot be changed
 When RATE.FIXING is set as "YES" , for FTs which are in INORATE/
ANORATE status, position entries can be created with One Dealer desk
indicated in DEALER.DESK Field of FT.APPL.DEFAULT instead of using
the FT Dealer desks.
This enables to group positions of FTs pending fixation
Once the rates are available for the day, FT.RATES is run online, old
position entries are reversed and new position entries with current
exchange rate and DEALER.DESK in FT is created
 Rounding rules for conversion is standard by default
Other methods as defined in EB.ROUNDING.RULE can be attached to
the ROUND.TYPE Field
Slide 56
FT.APPL.DEFAULT
 Standing orders related
 Minimum amount of a balance maintenance for processing Standing order

can be stipulated using the associated MIN.STO.CCY and MIN.STO.AMT
multi value Fields. This field defines a Minimum transfer Amount below
which balance maintenance instructions will not be processed
A local currency and amount should be specified before defining a foreign
currency amount
Where the minimum amount is not defined for a Currency, System will
take the equivalent of the local Currency amount.
 If a Standing order is to be executed LESS a tax benefit amount, rules can

be defined using STO.TAX.SEQ.NO and STO.TAX.PERCENT multi value
Fields
Sequence number indicated here can be used in a Standing order
Then, the eventual payment would be Standing order amount less tax
benefit. Beneficiary claims the difference from local authorities
Slide 57
FT.APPL.DEFAULT
 Standing orders related

 STOs can be set for automatic resubmission if pending due to insufficient
funds
 NO.RESUBMSSN.DAYS Field defines the number of days for which they
are to be resubmitted daily during COB
Can be from 1 to 10 days
 RETRY.START.TIME and RETRY.END.TIME Fields can be used to set
time intervals for online automatic resubmission during the following day
 These methods can be combined to create a continuous retry process that
runs on line until funds become available or the limit of 10 days is reached
 After resubmission fails, at the end of this period, System will generate
delivery advice specified in SO.MESSAGE.TYPE Field
Must be a valid delivery message specified in DE.FORMAT.PRINT
 If USE.STO.ACCT.OFF Field is set to ‘Y’. ACCT.OFFICER Field value in
STANDING.ORDER will be automatically defaulted into
PROFIT.CENTRE.DEPT Field of the FUNDS.TRANSFER
Slide 58
FT.APPL.DEFAULT
 Automatic processing of Inward FT
 AWAIT. COVER Field

Bank wants to make payment only after receiving the Cover message
 During Inward processing, if the AWAIT.COVER Field is set to "YES" then

FT will be put on hold.
 Bank can verify whether cover instruction is received and then process
manually
When set as “LIM”, then Correspondent Limit will be checked
When set as NULL, then FT is not put on Hold for this reason
 Above functionality is applicable only for inward swift messages and when
Incoming swift message 103 has Tag 54 (Receiver's Correspondent)
Slide 59
FT.APPL.DEFAULT
 Straight Through Processing (STP) MT 103+
 MT 103+ is a subset of MT 103.
 An outward payment is defined as STP if it is made with MT103+ message

It should contain a correct IBAN (International Bank Account Number) for
the beneficiary customer in Field 59a (Beneficiary Customer)
MT103+ is considered as European whenever the Sender, Receiver and
Field 57A (Account with Institution) if present, have a BIC code of which
the country code falls within the European Validation list of countries
 If Bank details are not made available, it is possible to direct T24 (i) either
to generate MT 103 (instead of MT 103+) after due approval of override (ii)
or generate error message as it is not able to produce MT 103+
Slide 60
FT.APPL.DEFAULT

 If MT.103.CONTROL Field is set as “SYSTEM” to send MT 103+
While inputting FT, if MT103.TYPE Field is set as MT103+, System will
send it if the bank field has either valid BIC code (SW-) for tags or
Customer number with SWIFT address set up for tags 52, 54, 55, 56 &
57. Beneficiary account number is also mandatory.
If these are not present, System will raise an error
If MT.103.TYPE Field is set as MT103EXTEND, and Extend format and
information are provided, Envelope Content details are sent as MT103
with Tag 77T
 Validation flag will be STP for MT 103+ and REMIT for MT103EXTEND
 Field 119 of User Header of message
Slide 61
FT.APPL.DEFAULT
 If MT.103.CONTROL Field to be set as “SYSTEM”

While inputting FT, if MT103.TYPE Field is set as “NULL”, system will
send regular MT 103 instead of MT 103+
 MT.103.CONTROL Field to be set as “NULL”,

While inputting FT, if MT103.TYPE Field is set as MT103+, if the bank
field does not have either valid BIC code (SW-) or Customer number
with SWIFT address set up (for tags 52,54,55,56 & 57), T24 will send
MT103 instead of MT 103+, if override to this effect is duly approved
 These FTs will not be eligible for Straight through processing
Slide 62
FT.APPL.DEFAULT
 General
 When a FT record in History is reversed, reversal will use the Transaction

code indicated in HIS.REV.TXN.CODE Field
If the field is left blank, the original transaction code is used
 When an error is encountered in FT, commission / charge details entered or

defaulted by the system are cleared from the respective fields
While inputting “OT” type of transaction, Beneficiary is mandatory and if
the user has omitted to input beneficiary details, system will prompt an
error and simultaneously clear off the details in Commission / Charge
related fields
 To retain the defaulted or user input values CHG.COM.ON.ERR Field

should be set as "RETAIN”
T24 will not re-calculate the Commission/charges even when there is a
change in Transaction amount or Customer and values retained as it is
Slide 63
Preferential grouping for Commission & Charges
 CONDITION.PRIORITY
 Banks levy commission and charges by applying different set of rules for
select groups
To enable need based grouping for charges and commissions, it is
essential to set the CONDITION.PRIORITY table for FT properly
 Id FUNDS.TRANSFER
Subsequent changes could be made with effect from system date or
future value date for specific company or for entire system
 Any number of fields from CUSTOMER can be chosen to set conditions
 Order of prioritising is set here

Residence first, Sector next, Industry third etc
Slide 64
 FT.GEN.CONDITION
 General conditions of customers could be defined for meaningful
combination of FT charge groups
Group 1 is of US residence, Private Sector, Software industry
Group 2 is of US residence, Private Sector, all other industries
Group 3 is of US residence, all sectors, Software industry
Group 99 is of Any residence, any sector, any industry
 Up to 9999 groups can be formed. Id is Numeric
User definable description for each group
 System always does a best fit for every Customer based on Customer field
selections
 Customer’s actual group is recorded in CUSTOMER.CHARGE for all
applications
It is possible to effect change into any other group at this level
Slide 65
 For the groups defined in FT.GEN.CONDITION, it is possible to indicate

differential treatment with regard to charges and customer spreads of
exchange rates
 Any percentage of FT.CHARGE.TYPE and FT.COMMISSION.TYPE could

be collected for this group (between 0 to 100%)
Either the respective Commission code or “ALL” could be indicated
For specific types of Commission, flat amount in a designated currency
could instead be collected.
Slide 66
 FT.GROUP.CONDITION - other group specific concessions
 Charges and Commission could be shown as separate entries in

statements
CHG.COMM.SEPARATE Field to denote this choice
 RATE.SPREAD Field to denote concessional spread for currency exchange

Where the absolute rate is to be applied, input should be ‘0’
No rate spread
Where entire spread is to be applied, input should be ‘100’
If left blank, standard Customer spread will be assumed (as if 100%)
 PAYMENT.TYPE and CUSTOMER.FLOAT Fields can be used to denote

value date dispensation for transactions that involve (i) Foreign currency
Conversion or (ii) do not involve conversion or (iii) All transactions
Value can be between 0 to 9 calendar days or P for Processing date
ALL and 2 mean Value date for all transactions after 2 days
Slide 67
Workshop – 2
 Use Admin Menu > Payment Administration > Funds Transfer > FT
Gen Condition
 Form a special group – VIP Customer group whose sector is 1001 in
FT.GEN.CONDITION
 Use Admin Menu > Payment Administration > Funds Transfer > FT
Group Condition
 Set rules to collect only 50% of OUTREMITCHG and 75 % for
INREMITCHG for this group
.
Slide 68
Slide 69
 For the groups defined in FT.GEN.CONDITION, it is also possible to

indicate overall minimum/maximum amount with regard to charges and
commission
It could be indicated in COMM.MAXIMUM and COMM.MINIMUM or
CHG.MAXIMUM and CHG.MINIMUM Fields in a designated currency
 This will take precedence over the overall minimum/ maximum amounts
defined in FT.COMMISSION.TYPE or FT.CHARGE.TYPE
 Possible to mention values in COMM.DISCOUN or COMM.PREMIUM or

CHG.PREMIUM or CHG.DISCOUNT apart from mentioning the maximum
and minimum for commission and charges
Commission discount will be deducted from Commission maximum and
Commission premium will be added to commission minimum
Slide 70
Workshop – 3
 Use Admin Menu > Framework Parameter > Interest Taxes &
Charges > Charges > FT Commission Type
 Create a commission type called FT Comm
 Use category code as 52205, transaction code for debit and credit as 451
 Calculation basis as percentage and type as band
 2% Commission up to 20000 and 5 % beyond 20000
 Overall Minimum 100 and Overall Maximum 500
 Commit the record
 Use Command Line
 Create FT Group Condition for your Corporate Customer

 Set rules to collect FT Comm by setting Commission maximum as 250
Commission minimum as 50 and Commission discount as 25
.
Slide 71
Slide 72
Slide 73
 FT.GROUP.CONDITION can be set for a group or for any specific

Customer (Id C-XXXXX)
 When a CUSTOMER record is created,

 System automatically creates a record in CUSTOMER.CHARGE and
indicates, application wise, which group conditions would apply to this
Customer in ACTUAL.GROUP Field
 Possible to change the Group Id here so that the new group rules would be
applicable to this Customer
 When preferential rules are set at Customer level

 Instead of indicating the Group Id, Customer Id is displayed in
ACTUAL.GROUP Field in CUSTOMER.CHARGE
Slide 74
Workshop - 4
 Use Admin Menu > Payment Administration > Funds Transfer >
FT.GROUP.CONDITION
 Set the rules for your individual customer
 Collect only USD 50 for OUTREMITCHG type of Commission
 Through Command line, view how the CUSTOMER.CHARGE reflects

rule that has been set specifically for this Customer
Slide 75
Slide 76
FT Commission & Charges – Based on own Customer
FT.CHARGE.TYPE
FT.COMMISSION.TYPE
CONDITION.PRIORITY
Transaction
types
FT.GEN.CONDITION
Standard
User defined
CUSTOMER.
CHARGE
FT.TXN.TYPE.CONDITION FT.GROUP.
CONDITION
CHARGED.CUSTOMER
CHARGES.ACCT.NO
Fields
FUNDS.TRANSFER
Slide 77
FT Commission & Charges – Based on Correspondent
 Charges can be collected based on Correspondents instead of basing

on our own Customer in case of MT 103 messages
 DEF.CORR.BANK.CHGS Field in FT.APPL.DEFAULT should be set as
YES
 CORR.BANK.CHARGES application to be set for Correspondent Banks

/ Customers on whom collection of charges are based
 Id of CORR.BANK.CHARGES is Customer No
FT.TXN.TYPE.CONDITION record can also be indicated after Customer
No separated by a -
 In case Id is created with Transaction Type, charges are defaulted only
when the same customer No. & transaction type combination is used in FT
 In case Customer No. alone is defined then the same is used as default,
irrespective of transaction type used in FT
Slide 78
 Charges set up in CORR.BANK.CHARGES defaulted as follows:

 For Outward MT103: At the FT level, if all transaction charges are for
ordering customer, T24 defaults charge details along with CHARGE.FOR
as "RECEIVER" and these details are mapped to Tag 71g of Outward
MT103 Message. Amount to be remitted (Tag 32) is arrived by adding the
Credit Amount PLUS Receiver Charges (Tag 71g)
 For Inward MT103: If charge to be taken by Receiver of inward MT103 is
not specified in tag 71G, then Receiver charge details defaulted from
CORR.BANK.CHARGES, as defined for the Sender Customer, irrespective
of details (Ben / Our / SHA) in BEN.OUR.CHARGES
 Charges defined in FT.TXN.TYPE.CONDITION will be defaulted if

CORR.BANK.CHARGES are not present
Slide 79
FT.CHARGE.TYPE
FT.COMMISSION.TYPE
FT.APPL.DEFAULT
Transaction
types
DEF.CORR.BANK.CHGS
Standard Field to be set as YES
User defined
FT.TXN.TYPE.CONDITION CORR.BANK.
CHARGES
FUNDS.TRANSFER
Slide 80
Quiz - 2
1) Can a Bank set up new transaction types and their conditions in

FT.TXN.TYPE.CONDITION?
Ans: Yes by using 4 Characters as Id of which the first 2 Characters are
same as one of the standard transaction type hard coded
2) Which type of FT transaction can be subjected to rules for checking
occurrence of duplicates defined in EB.DUPLICATE.TYPE?
Ans: Any type, by defining suitably in FT.TXN.TYPE.CONDITION
3) In FT.TXN.TYPE.CONDITION, how can we define a default value date
of one working day and 2 calendar days backwards from processing
date?
Ans: -01W-02C to be indicated in PAYMENT.VALUE Field
4) How many days of automatic resubmission is possible for Standing
orders in case of insufficiency of funds?
Ans: Maximum of 10 days
5) How can we set customer specific concessional charges for FT ?
Ans: In FT.GROUP.CONDITION with Id as C-NNNNNN
Slide 81
BENEFICIARY
 When funds transfers have to be made to a particular beneficiary at

regular intervals, details of the beneficiary to be given by the user every
time
 BENEFICIARY table allows user to input all the required details of the
beneficiary
 It can be linked to Funds Transfer and Standing order applications

using AC and OT type of transactions
 User need not remember the details of frequently used beneficiaries

like the beneficiary’s account number, beneficiary’s bank, BIC, etc.
while transferring funds
Slide 82
FT (other than STO) - Build sequence
* Mandatory
Optional
1. EB.DUPLICATE.TYPE
EB.DUPLICATE.TYPE
2. FT.TXN.TYPE.CONDITION * FT.CHARGE.TYPE
FT.COMMISSION.TYPE
3. FT.APPL.DEFAULT *
4. CONDITION.PRIORITY *
5. FT.GEN.CONDITION *
FT.CHARGE.TYPE
6. FT.GROUP.CONDITION FT.COMMISSION.TYPE
FT.CHARGE.TYPE
7. CORR.BANK.CHARGES
FT.COMMISSION.TYPE
8. BENEFICIARY
Slide 83
Funds Transfer – Product features
Slide 84
Product features
 FT handles internal and external funds movements

 Customer payments, Banks own payments
 Incoming, Outgoing and Internal
 It is integrated with Accounting, Central liability, and Outgoing as well

as Incoming delivery
 Real time updates are applied to Balances, Positions, Cash flows and
Limits
 Charges and commissions defaulted or input directly

 Concessions on charges for groups or individuals
 Standing order payments effected as part of batch process
Slide 85
Basic elements – Id
 ID format is FTYYDDDNNNNN where YY stands for last two digits of

year and DDD for Julian day of processing and NNNNN for sequence
number. Ranges of sequence number assigned
 00001 to 09999 for online processing, 20000 to 29999 for Bulk order
payments, 40000 to 49999 for Standing orders, 50000 to 59999 for
Incoming via Delivery, 60000 to 79999 for Clearing Transaction Incoming,
80000 to 89999 for Account closure settlements. Others are reserved
 Where volume of transactions are high, Id can be set in AUTO.ID.START
application to include Alpha characters at the end
 If the Funds Transfer operation is not centralised, and more

transactions are envisaged, the sequence number can be set to be
preceded by the Department code from User Profile
 UNIQUE.NO Field in AUTO.ID.START to be set as YES
 Id format will now be FTYYDDDPPPNNNNNN where PPP is Processing
Department of Inputter set in PROCESS.DEPT Field in USER Application
Slide 86
Basic elements – Mandatory fields
 TRANSACTION.TYPE to have a valid record pre-defined in

 For AC and related transaction types

 Debit Account, Credit Account, Debit amount and Currency or Credit
amount and Currency are mandatory
 Using this transaction type, transfer could be effected between two
Customer Accounts or two internal accounts or between a Customer
Account and an Internal Account or between a Customer / Internal Account
and a PL Category
 If Internal account or PL Category is debited, ORDERING.CUST or

ORDERING.BANK Field is mandatory
Slide 87
Funds Transfer between accounts
 If Debit and Credit Currencies are different for a transaction, Buying

and selling exchange rates used
 Rates set in CURRENCY table for different markets
 Treasury and Customer spread additionally applied
Concessions on Customer spread possible
 Customer rate obtained by adding Customer Spread to the treasury

rate to generate a final rate for the transaction
Slide 88
Outward delivery process – Soft delivery
 Once input is complete for outward remittance in FT, preview of

related messages for that activity can be launched
 Preview button enabled to preview the delivery message
 Date to be input in MSG.DATE Field while previewing the message
 Message date if left blank, will default the processing date
 If a forward date is input in MSG.DATE Field, delivery message will not

be generated on authorising the record
 Information will be updated in the message date
 During COB of the scheduled date, delivery message will be generated
Slide 89
Workshop - 5
 Use User Menu > Retail Operations > Lcy Draft Issue/Acct trfr >
Transfer between Accounts
 Effect a funds transfer for USD 1,000 by debit to a customer’s USD account
 Credit your customer’s account in USD
 Accept overrides and commit the record
 Use User Menu > Retail operations > Lcy Draft Issue/Acct trfr >
Transfer between Accounts
 Effect another funds transfer for USD 1,000
 Debit the same USD account as above
 Credit your customer USD account
 Observe whether the System warns you of possible duplicate
 Get the records authorised
Slide 90
Slide 91
Slide 92
Workshop - 6
 Input a Funds Transfer through Command Line

 Select the transaction type as AC
 Effect a funds transfer for USD 11,000 by debiting your corporate
customer’s USD account to whom overall maximum commission has been
set in your earlier workshop
 Credit your customer’s account in GBP
 Select the Commission type as FT Comm
 Look at the commission calculation
 Get the records authorised
Slide 93
Slide 94
Basic elements for OT transactions – Mandatory fields
 For OT and related transaction types, it is mandatory to provide names

and details of Beneficiary Customer or Beneficiary Bank, the ultimate
receiver of funds
 BEN.CUSTOMER corresponds to Tag 59 in SWIFT message
 BEN.BANK corresponds to Tag 58 and is used in MT 202 message
Input should conform to ACCOUNT.CLASS for BANK
 Value in these two fields could be Customer Id / Mnemonic or Free text
 It is possible to opt to provide Beneficiary’s account number instead of

name or other details to maintain client confidentiality etc.
 BEN.ACCT.ONLY Field in FT.TXN.TYPE.CONDITION should be set as Yes
 If Credit Account is not input, Nostro account for Foreign currency and
Vostro account for local currency defaulted
 NOSTRO.ACCOUNT and AGENCY tables used
Slide 95
Basic elements for OT transactions – Mandatory fields
 When transfer is between two own Nostro accounts of the bank,

NOSTRO.XFER.TYPE Field in FT.TXN.TYPE.CONDITION should be
set as 200 or NULL for generating MT 200
 MT200 is sent for Financial institution transfer for own account
 When the debit and credit accounts are our Nostro, as we are the
beneficiaries, Beneficiary Bank or Beneficiary Customer information cannot
be further provided
 Instead of MT 200, possible to generate MT 202 type of payment

messages for transfers between Nostro Accounts
 MT202 is sent for General Financial institution transfer
 NOSTRO.XFER.TYPE Field in FT.TXN.TYPE.CONDITION to be set as
202
 Though we are ordering as well as beneficiary customers, both details have
to be entered as this is treated like a general transfer
Slide 96
Product features – Messages related
 BK.TO.BK.INFO Field corresponds to Tag 72 in SWIFT
 Provide instructions or additional information for receiver, intermediary

account with institution, or beneficiary institution
Should not be used for information for which another field is intended
 Message to start with standard code word defined in

SWIFT.CODE.WORDS file, and enclosed between slashes ‘/’. Information
can also be entered by multi valuing this field, but every line information
must start with ‘//’
/REC/PLEASE REMIT FUNDS AS INSTRUCTED
//TO CITIBANK, NEWYORK
 For Inward payments which are processed directly from Delivery,

transactions with this information will be placed in hold status (IHLD) to
force the user to review instructions of sending bank
Slide 97
 When FT is authorised, based on FT.TXN.TYPE.CONDITION and

details given in the FT, appropriate SWIFT messages will be sent to
Credit Customer, Debit Customer, Collection Remitting Bank and
Receiver Bank
 It is possible to send different information to different Banks by using

multi value field SEND.TO.PARTY Field and providing corresponding
information
 SEND.TO.PARTY Field can be multi valued and input as CRCUST,
DRCUST, COLL.REM.BK or RCVBK to indicate to whom the corresponding
BK.TO.BK.OUT message is meant
 Bank to Bank information can be specified either here or in

BK.TO.BK.INFO Field, but not in both
Slide 98
Transfer between Nostro accounts - MT 200
Financial institution transfer between own accounts
T24 Bank
MT 200
Payment
Our GBP Nostro

Account with Our USD Nostro
Barclays London Account with
Bank of NY
Slide 99
Transfer between Nostro Accounts with MT200
 Mandatory Fields required for Nostro transfer
 Nostro account to which funds are transferred would be debited

Nostro account maintained at our end is a mirror of our actual Nostro
account at the other end. Hence, this account, which is receiving funds, is
debited
 Nostro account from which funds are transferred is credited
 Credit currency, amount and value date details are also mandatory
Slide 100
Role Based Home Page on Remittances
 Remittances home page has custom set of menus / enquiries

 Front-end solution for users to process Remittance transactions
 Once a home page for remittance is invoked multiple screens are displayed
 Enables a User / Payment Supervisor to carry out his day to day work
related to Remittances
 Composite screen for Remittances is divided into several sections

 Processing of issue of draft, outward remittances, inward remittances,
account transfers, standing orders etc.
 Menus available for Funds Transfer, Standing Orders, Direct Debits and
bulk Standing Orders
 Components of Remittances Home Page in the form of tabs, for easy
navigation
Slide 101
Workshop – 7
 Use Role Based Home Pages > Payment Services > Home Page –
Payments > Funds Transfer >Account Transfer > Choose Transaction
>Transfer between Nostro Accounts (MT200)
 Effect a funds transfer of Euro 100,000
 Funds to go from one Euro Nostro account to another Euro Nostro
Account
 Bank to Bank information - /REC/PLEASE REMIT FUNDS
 Get the record authorised
 Select Delivery Preview button > View FT Messages
 View the Swift Message MT 200
 View the accounting entries through Context sensitive enquiry,
 Use Role Based Home pages > Payment Services > Home Page –
Payments > Funds Transfers > Remittances Enquiry > Nostro Transfer
Today
 View the Nostro transfers
Slide 102
Slide 103
Slide 104
Slide 105
Slide 106
Product features – Charges related options
 BEN.OUR.CHARGES Field corresponds to Tag 71A in MT103

 SHA - Transaction charges on Sender's side to be borne by ordering
customer, and Receiver's side charges by beneficiary
If FT.TXN.TYPE.CONDITION is set to produce MT103, SHA defaulted
 OUR - All charges to be borne by ordering customer
Recipient bank will send Claim charge advice to Sending bank
 BEN - All charges to be borne by beneficiary
If MT103 is sent, charges based on Correspondent not Valid
 COMMISSION.FOR and CHARGES.FOR Fields

 Indicate whether the commission and charges are for Sender or Receiver,
as per value in BEN.OUR.CHARGES Field
 Sender– SWIFT message shows that they are for Sending Bank
 Receiver – SWIFT message shows that they are for Receiving Bank
Slide 107
 COMMISSION.CODE Field
 Identifies which party to pay
 Options are DEBIT PLUS CHARGES, CREDIT LESS CHARGES, WAIVE
 DEBIT PLUS CHARGES

 For outgoing transfers full transfer amount will be sent to receiving bank and
Charges will be debited to our Customer
 For incoming payments
Full transfer amount will be credited to our beneficiary Customer and
commission amount will be debited to the account defaulted or specified
Debit account defaulted as charges account except when it is a Nostro
If it is Nostro, Claim Charge Account as defined in the
FT.APPL.DEFAULT will be used and a claim sent to Ordering Bank
Slide 108
 CREDIT LESS CHARGES option in COMMISSION.CODE Field
 For outgoing transfers commission amount will be deducted from the

Transfer amount remitted to receiver bank
 For Incoming payments, commission amount will be deducted from the

received amount and credited to a Profit and Loss Category code
 If the Customer has requested the bank to apply all commissions and
charges to a separate account, the complete transfer amount will be
credited to one account and the corresponding commissions and charges
debited to the specific charge/ commission account of the Customer
Debit account for charges for a Customer can be indicated in
CUSTOMER.CHARGE table
Slide 109
 WAIVE option of COMMISSION.CODE Field

 Commission will not be applied. If a Commission type is indicated, it will not
be accepted
 For Standing Order transfers and any transfers with Nostro for both Debit
and Credit Accounts, Waive Commission will be the default value
 If MT 103 is set to be produced

 COMMISSION.CODE Field gets value of Credit less charges, Debit plus
charges or Waive as per BEN.OUR.CHARGES Field
BEN – All charges are for Beneficiary. Will default credit less charges
OUR – All charges are for Ordering Customer. Will default debit plus
Charges
WAIVE – All charges waived. Will default Waive
Slide 110
 Commission / Charge type to be collected is defaulted from the settings

in the underlying FT.TXN.TYPE.CONDITION or
CORR.BANK.CHARGES table as the case may be
 System calculated amounts displayed. Alternately, user can indicate these
 Collected from Charges account displayed
 Generally commission / charges booked along with transfer amount unless
opted otherwise in FT.GROUP.CONDITION
 CHARGE.COM.DISPLAY Field helps to choose whether the

commissions and charges calculated are to be displayed before or after
transaction validation
 If ‘Y’ is entered, results displayed prior to accepting the transaction
 Values have to be removed before the transaction is accepted
Slide 111
Outward remittances - MT 103
Debit advice
MT103
Single customer credit transfer
Payment
Our GBP Nostro
Mr Frank Bishop account with Barclays
London
Slide 112
Outward remittances - MT 103 and MT 202COV
Debit advice
Instruction T24 Bank

Michael Dell
Single customer credit transfer

General Financial institution transfer MT103 MT202COV
Payment Payment
910 / 950
Confirmation of
Our GBP Nostro
Frank Bishop’s
Mr Frank Bishop Credit / Detailed account with Barclays
Banker Statement of A/c London
Slide 113
Product features – Cover method
 Cover method
 Cover Payment is issued when there is no Nostro / Vostro account
 FT issues MT 202COV only for OT transaction types

MESSAGE.TYPE Field in FT.TXN.TYPE.CONDITION should have been
set as 103, as cover is meant only for 103 messages
 COVER.METHOD Field has 4 options to choose from

COVER-DIRECT, COVER-NEAR, SERIAL and THIRD-INST
 According to the choice

Payment instruction of MT103 are sent to different intermediary Banks
and Payment cover of MT 202COV sent to Correspondent Bank
Slide 114
Product features – Cover options
 Cover method
 COVER-DIRECT
Detailed payment instruction is sent directly to another institution via
MT103 and brief instructions sent to our correspondent via MT202COV
for covering Payment Message
 COVER-NEAR
Payment message (MT103) sent through several reimbursement
institutions and brief instructions to our Correspondent via MT202COV.
 SERIAL
Payment message (MT103) is sent to the next party in the transaction
 THIRD-INST
Payment Message MT103 sent to party closest to beneficiary, using a
third reimbursement institution. MT202COV instructions to
Correspondent
Slide 115
Product features – Cover message time
 Cover Payment
 When MT103, its Cover MT202COV and MT205 (Further domestic

transmission) are issued, it is possible to indicate Time in Tag 13c of the
messages
 If RELATED.MSG Field is set as COVER, then TIME.IND Field indicates

time to appear in MT103, and if RELATED.MSG Field is set as PAYMENT,
TIME.IND Field indicates time in MT202COV
 Time indication in Tag 13C can have 3 components – SWIFT code, Time
and Time offset with Central European Time
 SWIFT code and Time are indicated here

SWIFT codes of SNDTIME, CLSTIME, RNSTIME can be used
Input to be like /SNDTIME/1220, /CLSTIME/1820
Slide 116
Product features – Cover message time
 Cover Payment
 SWIFT allows certain message types to have reference to time based on

Central European Time (CET). Time offset gets defaulted from
CET.TIME.DIFF Field in DE.PARM
This field identifies the local time difference from the CET. It will indicate
this in those SWIFT messages, where conversion TIME.CET is specified
for time Field in the DE.FORMAT.SWIFT
 If /SNDTIME/1220 is indicated in TIME.IND Field in FT, and if offset time is

set as +1000, then Tag 13C will show /SNDTIME/1220+1000
 Though RELATED.MSG Field can be multi valued to have COVER as well

as PAYMENT, to generate simple MT103 or MT202 or MT205 with tag 13C,
it should be set as either of them
If Time is not to be indicated, this should be left blank
Slide 117
Product features – Correspondent Banks
 Correspondent banks
 INTERMED.BANK Field defines Intermediary Bank through which funds

must pass through prior to Beneficiary / Account with Banks.
 Corresponds to Tag 56 in SWIFT when the Cover Method is Direct or Near

and to Tag 54 in MT 103 (Receiver correspondent) and Tag 56 in MT
202COV (Intermediary) when Cover Method is Third institution
 COLL.REM.BK Field defines Bank to which an MT400 Advice of Payment

regarding Collection is to be sent
Can only be entered when FT.TXN.TYPE.CONDITION has been set up to
process SWIFT message type MT400
Slide 118
Product features – Correspondent Banks defaulting
 Based on the cover method and Customer indicated as Beneficiary

Customer or Bank, T24 uses AGENCY record set for Customer to
default values
 For COVER-DIRECT method

 MT 103 is sent directly to another institution and MT 202COV is sent to our
correspondent, Receiver Bank, its correspondent bank and intermediary
banks, if any, defaulted, if defined in AGENCY
 AGENCY records should have been set up for Receiver bank and its
Correspondent bank also
 For COVER-NEAR method

 MT103 is sent through several reimbursement institutions using an ‘Account
with institution’ and MT 202COV is sent to our Correspondent.
 Account with Bank, Receiver Bank and its correspondent bank are
defaulted, if defined in AGENCY
Slide 119
Product features – Correspondent Banks defaulting
 For SERIAL method, Account with Bank and Intermediary Bank details
are defaulted, if defined in AGENCY table
 For THIRD-INST method, Receiver Bank, its correspondent bank and

intermediary bank fields are defaulted, if defined in AGENCY table
 Error raised in case any one of the above Bank fields is NULL
 Details given in REC.CORR.BANK Field will be mapped to tag 55 (Third
Reimbursement Institution) and INTERMED.BANK Field to Tag 54
(Receiver Correspondent Bank) in SWIFT MT103 message
 If ACCT.WITH.BANK details are also given, override generated
Slide 120
 Debit and Credit advices can be controlled at Transaction level by using

DR.ADVICE.REQD.YN and CR.ADVICE.REQD.YN Fields
 PAYMENT.DETAILS Field corresponds to Tag 70

 Details of transfer for inclusion on Payments and Advices
 Contains reference information for Beneficiary as supplied by the Ordering
Customer and NOT payment instructions
Examples are Reference and invoice numbers
 PAY.METHOD Field corresponds to Tag 72. Contains additional Bank

to Bank instructions like further method of payment
 Drop down provides standard SWIFT codes like TA - Telex advice, PB -
Pay beneficiary only, CH - Pay by cheque etc
Slide 121
 INSTRCTN.CODE Field can be used to input Free format text
 Corresponds to Tag 23E INSTRUCTION.TYPE in MT103

 Input allowed if corresponding FT.TXN.TYPE.CONDITION is set to produce
SWIFT message MT103
Contact Beneficiary by Phone
 Not to be used for STP processing
Slide 122
 Free text messages
 Possible to send free text messages like sending a direct telex advice
to Beneficiary in addition to sending the standard message to Bank, at
our Customer’s request
 FREE.TEXT.MSG Field
 Can have a CUSTOMER Id or Mnemonic or alternately free text of Name
and address above 10 characters
 Input allowed only if charges to be taken for additional messages are pre
defined in FT.APPL.DEFAULT
 This charge is taken in addition to those specifically entered, or defaulted,
within Funds Transfer main processing
 Non-tested message to be sent is input in MESSAGE Field
Slide 123
Outward remittances with MT103
 Basic details
 Debit account, credit account, currency and amount of transfer
 Charges defaulted as to be shared – SHA

 Charges at our end collected from remitter and your end may be collected
from beneficiary
 Other options are BEN and OUR
 Method of collection defaulted as DEBIT PLUS CHARGES

 Other options are WAIVE or CREDIT LESS CHARGES
Slide 124
Workshop - 8
 Use Role Based Home Pages > Payment Services > Home Page -
Payments > Funds Transfers > Outward Remittances > Choose
Outward Remittance > (With MT103)
 Effect Outward remittance of GBP 25,000 using
Debit account as Current account of your customer
Credit Nostro account of GBP
 Indicate
Beneficiary as “TEMENOS”
Bank to bank information as /REC/PLEASE CREDIT AMOUNT VALUE
TODAY
 Accept overrides if any and get the record authorised
 Select Delivery preview Button > View FT Messages

 View MT 103 message
Slide 125
Slide 126
Slide 127
Outward remittances with MT103 / 202COV
 Outward remittances through MT103 which necessitate cover payment
message of MT202 COV are handled using a different transaction type
 Input is similar to Outward Remittances (MT103), but MT202COV

message will contain all the tags of MT202 and some additional tags
detailing the contents of MT103 like Ordering Customer, Beneficiary,
etc.
 All fields in this section, except BEN.BANK (Beneficiary institution in

Model Bank) get default values from MT103 section
 BEN.BANK Field identifies the Bank which is the ultimate receiver of the
funds transferred by the sending bank and corresponds to Tag 58 in MT202
 As BEN.CUSTOMER (Beneficiary Customer) Field is made as mandatory in
the Version, the field needs to be filled up
 In the header field Tag 119 it is indicated as COV
Slide 128
Workshop - 9
 Use User Menu > Payment Services > Funds transfer > Outward
Remittances >Outward Remittance (MT103+MT202)
 Effect Outward remittance of GBP 25,000
 Choose your customer’s USD Current account as debit account
 Select a GBP NOSTRO.ACCOUNT as credit account
 Indicate
Beneficiary as TEMENOS UNITED KINGDOM
MT 103 Receiving bank as 100436 (American Express bank Singapore)
Message to Receiving bank - /REC/PLEASE INFORM BENEFICIARY
 Accept overrides if any and get the record authorised
 Select Delivery Preview button > View FT Messages

 View messages of MT103 and MT 202COV
Slide 129
Slide 130
Slide 131
Product features – Netting of Messages
 MT102 (Multiple Customer credit transfer) and MT203 (Multiple General

Financial institution transfer) generation
 By using NETTING.STATUS Field MT103 / MT202 messages to be

generated can be grouped together and sent as MT102 / MT203 messages
 When set to "N", MT202 or MT103 is generated from FT directly
 When this field is Null and DE.PARM and DE.MESSAGE applications for
records 103 and 202 have NETTING.ALLOWED Field set as "Yes”, then a
Value of 102 or 203 or 102*203 is defaulted here
If 102 is defaulted, then MT103 is suppressed
If 203 is defaulted MT202, is suppressed
If 102*203 is defaulted, MT103 and 202 are suppressed
Slide 132
Product features – Netting of Messages
 When MT103 / 202 are suppressed, details passed on to

NETTING.ENTRY application to generate MT102 / MT203
 To generate a MT102 / 203 Swift Messages, a record in

NETTING.AGREEMENT has to be created for the receiver of the
message and required contracts can be selected through
CREATE.NETTING application for the following criteria
 Customer/ Currency/ Value Date/ System Id / Receiver Correspondent/
Sender Correspondent/ Bank operation Code (Mandatory for MT103 and
can have values of CREDIT or CHQB to indicate method of payment)
 NETTING application is used by FT only for grouping and generating

messages and NOT for netting accounting entries
Slide 133
Outward remittances with MT400 / 202
 MT 400 sent by Collecting Bank to the Bank which has sent

instruments for collection
 MT 202 is sent as cover to the bank with which the Collecting Bank is
having Nostro account
 MESSAGE.TYPE Field of FT.TXN.TYPE.CONDITION to be set as 400 for
this
 Receiving bank would be the bank which has sent collection

instruments
 Different Sender to Receiver information can be input for MT 400 and MT
202
 Message in MT400 could be addressed to COLL.REM.BK and message in
MT202 could be addressed to CRCUST
Slide 134
Workshop - 10
 Use User Menu > Payment Services > Fund transfers > Outward
Remittances > Outward Remittance (MT400+MT202)
 Effect Outward remittance of GBP 50,000 being proceeds of Collection
instrument CH12345.
 Choose your Corporate Customer’s USD Current account as Debit account
 Select credit account from the drop down box
 Indicate
Beneficiary as BARCLAYS BANK, LONDON
Receiver Bank and MT 400 to be sent to SW-BARCGB22
Message to Collection Remitting bank - /REC/REMITTED PROCEEDS
THROUGH HSBC and message to Credit Customer - /REC/COVER FOR
OUR COLLECTION PAYMENT
 Select Delivery Preview Button > View FT Messages

 View MT400 and MT202 messages
Slide 135
Slide 136
Slide 137
Draft Issue in Local currency
 OC (Outward Cheques) and related transaction types can be used to

issue Local currency Drafts / Bankers cheques
 Input details for issue of a draft in local currency

 Credit account would be the Internal Account used for Managers cheques /
Drafts
 Draft Amount, Draft currency unit, being the decimal unit and Draft Number
to be indicated
Slide 138
Basic elements – Draft issue with MT 110
 OD (Outward Drafts) and related transaction types can be used to issue

Drafts / cheques drawn on another bank
 MT110 messages can be generated by setting MESSAGE.TYPE Field as

110 in FT.TXN.TYPE.CONDITION
 Credit account would be Nostro / Vostro account of the bank on whom the
draft is drawn on
 Signature arrangements must have been defined for the Receiver Bank’s
AGENCY record as S or B
TEST.SIGNATURE Field in AGENCY defines if testing arrangements
exist with the Agent and whether they hold our authorised signatures
T = Telegraphic Testing arrangements exist
S = Signature arrangements exist
B = Both conditions exist
Blank = No control documents
Slide 139
Issuing Drafts - MT 110 Advice of cheque
Draft / Banker’s
Cheque
Draft /
Banker’s MT110
Cheque
Draft / Banker’s
Cheque
Payment Our GBP Nostro

Mr Frank Bishop account with Barclays
London
Slide 140
 For OC and OD types of transactions, MAILING Field could be set as

BEN or CUST in FT to indicate to whom the Cheque and advice is to be
sent
 BEN - Cheque or Draft to be sent to Beneficiary
 CUST - Cheque or Draft to be sent to Ordering Customer. Cheque and

Debit advice prepared. Covering advice for beneficiary is not generated
Slide 141
Workshop – 11
 Use User Menu > Payment Services > Funds Transfer > Issue of
Foreign Currency Draft > Choose Transaction Foreign Currency Draft
with MT 110
 Issue Draft for GBP 5,000 by debiting your customer’s USD account
 Indicate Beneficiary’s name as Frank Bishop
 Draft Number as C123456
 Bank to Bank Information - /REC/Please pay the draft as instructed, if
otherwise in order
 Select Delivery Preview Button > View FT Messages
 View MT110 message
 Use User Menu > Payment Services > Funds Transfer > Remittances
Enquiry > Foreign Currency Drafts Issued
 Look at foreign currency drafts issued today
 Using context sensitive enquiries, look at the accounting entries
Slide 142
Slide 143
Slide 144
Slide 145
Slide 146
Inward remittances
202
Inward
FT
routing
Delivery
SWIFT
202
Credit A/C 202Cov
Position Limit
balance or 205
205Cov
Slide 147
Inward remittances
 FT can be used for effecting Inward remittances in favour of our

Customers
 Can be executed / paid / credited to the beneficiary’s account manually
 Through suitable interface, incoming SWIFT message can be received and
automated to create FT in INAU status
 Today’s value dated instructions can be executed online and future value
dated instructions executed during COB
 From inward MT200 / 202 COV, it is possible to automatically send on-

forwarding MT205COV (further transmission of a transfer request
domestically) or MT202 COV
 FWD.IN.TXN Field in FT.TXN.TYPE.CONDITION to be set up accordingly
“YES” to generate MT205COV. “NO” to block messages
202 to generate MT202 instead of On-forwarding MT205COV message
Slide 148
Inward remittances – with manual intervention
Warning Override Message

Limit excess for example
Authoriser
202
Inward
FT
routing
Delivery
SWIFT
202
or
Credit A/C
Position Limit 205
balance
Slide 149
Basic elements – Mandatory fields
 For Inward remittance and related transaction types, Debit account,

currency, amount and Credit account are mandatory
 Ordering customer or Ordering bank is also mandatory if the Debit

account is a Nostro account
 Ordering customer corresponds to Tag 50 in SWIFT message
 Ordering bank corresponds to Tag 52 in SWIFT message
 If Debit account is not input, FCY Nostro account from

NOSTRO.ACCOUNT application and LCY Vostro account from
AGENCY application defaulted, depending on the Debit currency
Slide 150
Workshop – 12
 Use User Menu > Payment Services > Funds Transfer > Inward
Remittances > Choose Transaction Inward Remittances thru’ Vostro
Accounts
 Credit USD 20,000 to your Customer’s Current Account
 Debit USD VOSTRO account
 Note the defaulting of charges for the transaction
 Commit the transaction after accepting overrides
Enquiry > Inward Remittances today
 Look into the Inward Remittances executed today
Slide 151
Slide 152
Slide 153
Workshop – 13
 Use User Menu > Payment Services > Funds Transfer > Inward
Remittances > Choose Transaction Inward Remittances thru’ Nostro
Accounts
 Credit CHF 10,000 to your Customer’s Account
 Choose a CHF Nostro Account
 Indicate ordered by customer as Nat west Bank London
 Commit and get the record authorised
Enquiry > Inward Remittances today
 Look into Inward Remittances executed today for CHF currency
Slide 154
Slide 155
Slide 156
Product features – Expected receipts
 For IT type of transactions it is possible to create records of expected

receipts which can be entered manually or automatically created by
incoming Notice to receive MT210 message in AC.EXPECTED.RECS
application
 If automatic creation of RECEIPT type of records is desired,
EXPECTED.RECS Field of respective FT.TXN.TYPE.CONDITION should
be set as Yes
 Only individual accounts / categories defined in ER.PARAMETER can

be covered under AC.EXPECTED.RECS
 Rules for matching criteria like Expected funds type, Payment funds type,
Matching fields and tolerance allowed, if any can be opted here
Slide 157
Expected receipts - AC.EXPECTED.RECS
 ACCOUNT.ID, VALUE.DATE, CURRENCY and AMOUNT expected

are required to be filled
 Normally the Account will be a Vostro or a Client account
 Account number is entered by user or can be populated through an
incoming MT210
 FUNDS.TYPE Field defines whether the record is an Expected amount

or a Received amount. This is mandatory for manual input and can be
defaulted by incoming SWIFT or by inward FT transactions
 For manual input, it should be set as ER – Expected receipt
 Default of Receipt is used for FT inward transaction
 System maintains STATUS Field throughout the life

 Waiting, Matched, Deleted, Partial matched etc
Slide 158
Expected receipts - Matching
 FT creates an automatic 'receipt' record in AC.EXPECTED.RECS, if

FT.TXN.TYPE.CONDITION is suitably set
 Where receipt is the one 'expected' and providing details are all correct
then an auto-match is made when the FT is authorised
 Auto-match can also be done if within defined tolerances
 If matched, it inputs Id of AC.EXPECTED.RECS record in

EXPECTED.RECS.ID Field in FT record for cross reference
 STATUS Field in AC.EXPECTED.RECS is suitably changed to

“Matched”
 Expected Receipts value date and balance, Expected Payments

balance are stored in the respective ACCOUNT file
Slide 159
Product features - Correspondent Limit
 MT103 messages may be received from banks which do not hold

accounts with the receiver bank. Receiver bank will expect a cover
payment to be made by the sender through its correspondent. Payment
instructions are not generally acted upon till cover payment is made
 Some banks may like to sanction a preset allowance, or limit for

correspondents, and effect payments when within this limit
 Limit for correspondent bank can be indicated in ER.COVER.LIMIT.

Record Id is BIC code of correspondent
 During MT103 processing, System checks for limit availability. If no

record is available, it creates a record in ER.COVER.LIMIT
 Depending on limit availability, FT record is Live or kept on Hold
Slide 160
AC.EXPECTED.RECS – Correspondent Limit
 When cover details are received, details input manually or through

interface in AC.EXPECTED.RECS with funds type “RC-Received
Cover”
 During MT103 inward processing,

 T24 creates a record in AC.EXPECTED.RECS with FUNDS.TYPE as “EC-
Expected Cover”
 It checks for matching cover details and matches RC and EC records.
Matching criteria like Account id, Currency, Amount, Value date, Reference
etc can be specified in ER.PARAMETER
 Limit available for correspondent reduced to the extent of transaction
amount when matching cover is not available
 After specified period in ER.PARAMETER, MT195 (Queries) is raised

for EC items (Expecting cover) during COB for follow-up
Slide 161
Correspondent Limit - steps
 In FT.APPL.DEFAULT, AWAIT.COVER Field to be set as “LIM” to

check for correspondent bank limits
 If set as “YES”, FTs created through inward processing is always put on
HOLD and User has to manually check cover details
 In ER.PARAMETER, a record with ID as “COVER” to be created and

matching criteria and retention days for moving matched records to
history to be defined
 In ER.COVER.LIMIT, limit allotted to Correspondent Bank to be set

 Id could be Valid BIC code of 8 or 11 characters - without or with branch
code. Accordingly considered as Limit for all braches or for a particular
branch of a bank
 When a record for sender of MT103 is not available, system automatically
creates a record with available Limit as “0”
Slide 162
Correspondent Limit - Recap
 When inward MT103 is received from Non Vostro Customer

 If Limit has not been set, FT is put on hold
“EC” record in AC.EXPECTED.RECS application with status as “UA -
Unauthorised” created
Record created in ER.COVER.LIMIT with Available limit as “0”
 If Limit is defined and available, FT created and authorised

“EC” record is created with status as “AU-Authorised”.
Limit suitably reduced
 If Limit is defined but not adequate, FT is put on Hold

“EC” record with status as “UAL - Unavailable Limit” created
 If COVER details are available for payment, FT record is authorised

“EC” record created and matched with respective “RC” record with status
as “M-Matched”. Limit not affected as cover already received
Slide 163
AC.EXPECTED.RECS – Correspondent limit - recap
 ACCOUNT.ID, VALUE.DATE, CURRENCY and AMOUNT expected

are required to be filled
 Normally the Account will be a Vostro or a Client account
 Account number entered by user or populated via an incoming MT210
 Accounts defined in the ER.PARAMETER either individually or by

CATEGORY can be entered
 Incase the AC.EXPECTED.RECS is created for Correspondent Limit

Processing (i.e. with FUNDS.TYPE "EC" or "RC") then Id should be a valid
BIC code (8-11 Characters)
 FUNDS.TYPE Field: Record created by Correspondent limit processing will

be using "EC" (Expected Cover) and Cover message received for this can
be inputted manually with "RC" (Received Cover)
Slide 164
Quiz - 3
1) When is the ordering customer a mandatory input in account to account

transfer?
Ans: When an Internal account or a PL Head is debited
2) How is T24 designed to prevent a situation of Debit and credit amounts
not matching in a FT transaction?
Ans: It allows user input of either Debit amount or Credit Amount and not
both
3) When debit and credit currencies are different, how is the final
exchange rate worked out for a Customer in FT transaction?
Ans: Customer spread ( after working out concession set in
FT.GROUP.CONDITION) added to exchange rate in CURRENCY for
the specified market
4) How is Bank to Bank information indicated in Swift messages Tag 72?
Ans: Message to start with Standard code word present in
SWIFT.CODE.WORDS file and enclosed between ‘/’
Slide 165
Quiz - 3
5) What is the debit account when the resultant message is MT200

Ans: Nostro account to which funds are transfered
6) Where is Swift address of Customers stored in T24?

Ans: DE.ADDRESS
7) What type of netting is possible in FT?

Ans: Netting of delivery message and not accounting
8) If commission code is set as DEBIT PLUS CHARGES, when will full transfer
amount be given to Beneficiary – in Incoming payments or outgoing
transfers?
Ans: In both the cases
9) From incoming MT200 / 202 messages, which messages can be sent from
our end ?
Ans: On-forwarding MT 205message or MT202
Slide 166
FT – Other features
Slide 167
Linkage with FOREX
 CURRENCY table defines the Negotiable amount, up to which

exchange rates are valid. When a FT transaction amount exceeds this,
rate should be obtained from Dealer, who in turn can input a FX
transaction with DEAL.SUB.TYPE as Internal
 In FT, rate obtained should be manually input and the associated

internal deal to be indicated in NEG.DEALER.REFNO Field
 5 Numeric characters, being the daily FX transaction sequence
 Entry of this reference will cause the FX deal to be identified, matched,

and cancelled automatically when the Funds Transfer transaction is
authorised, thus avoiding a double update of foreign Currency position
 Internal deals yet to be matched by a corresponding FT, can be viewed

in the Exception display of FOREX Application
Slide 168
Product features - Accounting
 Accounting entries generated through FT
 STMT.ENTRY for Debit / Credit to Non contingent balances in Accounts

Accounts include Customer type and Internal accounts
 CATEG.ENTRY for PL heads like interest and commission

Possible to split entries for Commission and Tax thereon from Debit /
Credit transaction amount by suitable choice indicated in
FT.GROUP.CONDITION.
System will then pass one accounting entry for all the commissions / tax,
so that in Customer statements, this could be shown separately from
Debit / Credit amount
 Transaction codes specified through FT.TXN.TYPE.CONDITION

Also uses transaction codes defined for FT.COMMISSION.TYPE
Slide 169
Important SWIFT messages supported

Type
MT 102 Multiple Customer credit Transfer OT
MT 102+
MT 103 Single Customer credit Transfer
MT 103+
MT 103 REMIT
MT 110 Advice of Cheque OC, OD
MT 199 Free format message OT
MT 200 Financial Institution transfer for own OT

account
MT 202 General Financial institution transfer OT
MT 202COV Cover payment for individual transfer
MT 203
MT 205 Financial institution transfer execution OT
MT 205COV Institutional payment to notify the receiver OT
MT 210
MT 400 Advice of payment OT
Slide 170
Outward Delivery process
 DE.MESSAGE contains contents of basic message types

 Id 103 meant for Customer Credit Transfer and defines all Tags by Name
like SENDER REF, PAYMENT DETAILS etc
 When a transaction is authorised, all transaction details are written to

DE.O.HANDOFF
 These can be viewed through Enquiry DE.HANDOFF.DETS
 DE.MAPPING defines where data is located and helps mapping

 Id 103.FT.1 (Message type, Application and sub classification)
 Maps through Input Position (information from DE.O.HANDOFF or
Application) and field Name (Tag names pre defined in DE.MESSAGE)
Slide 171
Outward Delivery process
 DE.FORMAT.SWIFT formats the message

 Id 103.1.1 formats as field Tag, Field Name
 Tag 20 Field SENDER REF, Tag 13C Field TIME IND
 DE.PRODUCT sets rule Company wise, Customer / Account wise,

Message type wise
 Number of copies, Carrier to be used etc
 DE.ADDRESS helps store Company wise, Customer wise, Carrier wise

addresses. Can be used to hold mail
 DE.O.HEADER lets us know the message disposition

 Used to track the message. Contains information about the processing and
status of the message. Can also be used to re submit a message
Slide 172
Standard enquiries for Funds transfer
 Standard enquiries available for Funds Transfers for the day are:
 Foreign currency drafts issued
 Outward remittances
 Transfer between Nostros
 Inward remittances
 Enquiry for FT Reversed
Slide 173
Standing Orders
Slide 174
Standing orders – Overview
Balance Balance Inward

management Balance outward
Balance payment
Single
transfer
Regular
payment Fixed payment
Periodic payment
Standing Periodic payment
Orders Direct Debit interest
Revolving credit
Diary
Operating
Lease
Bulk
FUNDS transfers
TRANSFER Fixed payment
Slide 175
Standing Orders related Parameter
Slide 176
FT Accounts - Parameter tables
 Additional Parameter tables for STANDING.ORDER to be set-up
 STO.TYPE
 STO.BULK.CODE
 ACCOUNT.CLASS
SUSPFTBULK
SUSPFTINWD
Slide 177
STO.TYPE
 Ten different types of Standing orders are defined here

 Id is the hard coded STO type
 Multilingual description possible
 Balance Management Standing Order Types

 BI – Balance inward
For maintaining an account at a minimum balance level by effecting
inward payments when the balance goes below the specified amount
 BO – Balance outward
For maintaining an account at a maximum balance level by effecting
outward payments when the balance goes above the specified amount
Slide 178
STO.TYPE
 Balance Management Standing Order Types

 BP – Balance payment
Balance on a fixed length savings account can be paid away on maturity
date by using this type
Similar to BO, but gets executed during Start of day process. Hence
balance used for transfer will be that day’s opening balance
Interest/Charges, credited or debited in the previous day COB activity are
also taken into account. System will draw down the excess amount and
effect a payment as specified
 Regular Payments Standing Order Types

 FI – Fixed
To pay a Fixed amount on a regular basis by debiting an account
Can also be set for crediting an account with fixed amount regularly
Slide 179
STO.TYPE
 Regular Payments Standing Order Types

 PP - Periodic payment
When a customer instructs the bank to pay bills as and when presented
by third parties. Amount may vary
 PPI – Periodic payment Interest
To pay interest capitalised on an account to another – within the bank /
external account
 RC - Revolving credit
Set up to indicate a payment due on a revolving credit account
Payments are made on a regular basis and the amount due can be
determined using a locally developed routine
The purpose of the RC standing order is to record the amount due
using the Past Due module (PD)
No actual accounting entries will be produced by RC type standing
orders
Slide 180
STO.TYPE
 Direct Debit Standing Order Type

 DD - A direct debit mandate authorising the bank to accept direct debits, like
insurance payments, received on an Account
Passive type. Displays list of direct debit mandates for further action
 Diary Standing Order Types
 DIARY - To define any type of Diary instructions on a specific account
Can be created for any type of instructions to be recorded
Online reminder by way of enquiry possible from contents of STO.DIARY
Specific instructions received in advance are another example of details
which could be loaded as a Diary Standing Order type
 Other types
 OL – Operating lease
Caters for Operating Lease contracts and accrual of Standing Order
amount
Slide 181
ACCOUNT.CLASS
 ACCOUNT.CLASS records are used for some handling bulk Standing

order operations
 In BULK.STO application which is a single debit and multiple credit

solution, Accounting is washed through an internal suspense account
as defined in ACCOUNT.CLASS with record Id SUSPFTBULK
 In FT.BULK.CREDIT application which is a single credit and multiple

debit solution, Accounting is washed through an internal suspense
account as defined in ACCOUNT.CLASS with record Id SUSPFTINWD
 Internal accounts in local currency must be set up for the Category

codes defined in these records
Slide 182
STO.BULK.CODE
 This table will help the User to load, in a central place, specific details
on the most frequently used Standing Orders
 Beneficiary, Beneficiary’s Bank and Account number, Bank sort code (used
in United Kingdom for the BACS payments)
 Useful if many customers give Standing Order instructions in favour of

the same beneficiary
 Annual subscription to the AA or RAC
 Id is 2 to 10 Alpha numeric characters. Input of this Id in the Standing

Order record will be sufficient to automatically generate value of these
four data elements
 This table is not mandatory to run the Standing Order Application but is
provided as an additional facility to the User
Slide 183
Quiz - 4
1) Name the balance management types of Standing orders

Ans: Balance Inward ( BI) Balance outward ( BO)
Balance payment (BP)
2) Is it possible to set a FI (Fixed) type of Standing order to credit an account
regularly with a fixed amount?
Ans: Yes
3) Why are we required to set up records in ACCOUNT.CLASS for handling
bulk Standing orders?
Ans: To indicate internal suspense account so that multiple debits/credits
could be washed through to a single account
4) Several customers of our Bank give instructions to send monthly
subscriptions to Motor Quest magazine. In which table can we store Bank
details of Motor Quest?
Ans: STO. BULK.CODE
5) What is the main difference between BO and BP types ?
Ans: BO executed during COB and BP at Start of business
Slide 184
STO Build sequence
Mandatory*
1. ACCOUNT.CLASS * Optional
(Records SUSPFTBULK,
SUSPFTINWD)
2. STO.TYPE *
3. STO.BULK.CODE
Slide 185
Standing Orders – Product features
Slide 186
Product features
 STANDING.ORDER application is part of FUNDS.TRANSFER module

and uses FT for executing the standing orders set here
 Standing orders can be recorded for a variety of uses. System enables

these actions when the suitable hard coded STO.TYPE is used
 Funds Management initiated by balance levels - BI, BO, BP
 Fixed and preset payments - FI, PP
 Diary instructions - DIARY
 Direct debits - DD
 Periodic payment of interest - PPI
Slide 187
Product features
 During COB, the Application will access all standing orders due since
the last run date and up to and including that date
 STO.BALANCES process is run at end of day to process Balance
Maintenance Standing Orders
 STO.PAYMENTS process is run at start of day to process others
 FT transaction will be generated and automatically authorised if there

are no overrides / error conditions
 Otherwise, FT is put on Hold
In BI type, overrides display full details of the Amount required, available
and minimum balance required in Transferor Account
 Next day, User can access these FTs and decide on further action. They
follow the normal validation and authorisation process of FT
Slide 188
Basic elements - Id
 Id
 The first part is the Account number for which the User wants to define
Standing order instructions. Second part is a 4 digit sequence number and
separated from the Account Number by a '.'
 When creating a new standing order, if the Account number is input, System
will always generate the next sequential Standing Order number between
001 to 899 and after that, 1000 to 9999.
 For balance maintenance and revolving credit standing order types (BI, BO,
BP and RC), sequence number should be between 900 and 999 and must
be manually entered by User
The same balance maintenance standing order type can be used only
once per account
Slide 189
Basic elements – Type
 Type of Standing order to be indicated in TYPE Field. With this, the

STO inherits the properties of the hard coded STO.TYPE
 Some examples for usage of Standing order Type:

 BI - Customer requests to cover automatically any overdraft in his current
account by debiting his savings account. In this case, the specified balance
will be 0 and when the balance will be below 0 an automatic transfer will
then be generated from the savings account to feed the current account
 BO - Customer requests to transfer automatically from his current account

any amount in excess of GBP 1,000 to his savings account. When the
balance is in excess of this amount, an automatic transfer will be generated
by the Application by which the excess of GBP 1,000 will be transferred out
of the current account to savings account
Slide 190
Basic elements - Type
 Some examples for usage of Standing order Type (continued)
 FI - Customer requests to pay rent for his house every month. The amount
will be specified by the Customer and in that sense the amount of the
Standing Order is Fixed
Also possible to define “Credit” type Standing Orders for which
customers accounts are periodically credited with a fixed amount,
normally claiming the amount from outside. In this case, Account
number specified in the Record ID would become the Credit Account.
REV.DR.CR.ACCT Field should be set as 'Y‘ for Credit type STOs
 PP - Customer requests the bank to pay bills received from Electricity board
and Telephone company whenever received. In this case, the amount will
not be specified by the Customer but only the name of the beneficiary
whose bills are to be paid automatically
Slide 191
 OL – Handles accrual and repayment of lease rentals, in case of lease

transaction between customer and the bank
When customer takes on lease an asset from the bank, Standing Order id
is a valid customer account and accrual entries are a debit to the
suspense account and a credit to PL category. On repayment date,
customer account is debited and the suspense account is credited with
the Standing Order amount
When the bank takes on lease from a customer, Standing Order Id must
be a valid suspense account. Accrual entries are a debit to the PL
category and a credit to the suspense account. On repayment date,
suspense account is debited and Customer account credited with the
Standing Order amount
 STO can cater to Operating lease by using ASSET.REGISTER
Slide 192
 RC - A customer has a revolving credit account with payments due on a

monthly basis. The amount due can vary depending on the balance of the
RC account. When a RC standing order is set up on a monthly frequency
making use of a locally developed routine to calculate the amount due, a
PD.PAYMENT.DUE record will be created on the due date with a contingent
balance to indicate the amount due
 When a credit entry is posted to the revolving credit account, the PD record
will be credited with the amount on the entry, before the amount is credited
to the RC account. When the PD is cleared, it will be written to history
Slide 193
 DD - Customer authorises the Bank to honour direct debit instructions of a

Building Company to pay his monthly installments of a Mortgage loan
contracted with the Building company
 The amount is not always specified for Direct Debits Standing Order and, if
entered, will only be considered as an information field
Slide 194
Basic elements – Payment method
 Standing orders get executed through FUNDS.TRANSFER application
 Hence, in PAY.METHOD Field, we have to indicate the underlying

FT.TXN.TYPE.CONDITION record that is to be used to execute this
STO
 A Periodic Payment STO may be set to generate AC type of Funds Transfer
 A Periodic Payment of Interest STO may be set to generate OT type of
Funds Transfer, if the transfer is external
 A Diary type of STO does not need any Funds transfer and hence this field
should be left blank
Slide 195
Basic elements
 Currency of a Standing order is indicated in CURRENCY Field

 Diary type, no input and for Direct debit, it is optional
 Balance maintenance types, should be the same as that of Standing order
account
 PAY.METHOD is set as AC, then the currency should be that of either the
Debit or the Credit account
 PAY.METHOD is OB or OC, Currency can only be local currency
 CURRENT.AMOUNT.BAL Field used to indicate Standing order

amount
 Balance Maintenance types, Balance to be maintained is indicated here and
can even be “0”
 Direct Debit type, this is only for information purpose
 Periodic payments, this amount is deleted after payment execution
Slide 196
Product features – Frequency setting
 Frequency and end date for frequency can be indicated through

CURRENT.FREQUENCY and CURRENT.END.DATE Fields
 'DAILY' frequency is not allowed for Balance maintenance type of Standing
Order
 ‘BSNSS’ is allowed to facilitate maintaining balance every working day
 Weekly and monthly frequencies possible
 Frequency can also be set up to be processed on the same date as
repayment frequency in AA
Example : weekly once on Wednesday.
 It is possible to load in advance any number of future changes to

instructions by using the multi value set of FUT.AMOUNT.BAL,
FUT.FREQUENCY and FUT.END.DATE Fields
 Should be loaded in chronological date order
 Input allowed only if the Current end date is entered
 Facility not meant for PP and DD Standing Order types
Slide 197
Product features - Commission
 Commission / Charges related options
 Could be collected once by giving a date
 Could be collected at frequency matching STO frequency

Start date could however be different
Standing order commencing from 1st October on monthly basis and
monthly commission could be set to commence from 1 st December
 Amount could be allowed to be defaulted or indicated with Currency

involved
USD 50.00; GBP 25.50
 Can be collected from Debit account or any other account defined in

CHARGES.ACCT.NO Field
Slide 198
Product features – Processing date
 In FT.APPL.DEFAULT by using STO.PROCESS.GAP Field

 Processing date rules can be set
 +01W-01C means Last day before next working day
 Rules are NOT applicable for balance maintenance types
 STOs for whom rules are set using DATE.ADJUSTMENT Field at STO level
 When processing date falls on a holiday

 DATE.ADJUSTMENT Field in STO specifies how the processing date
should be adjusted
 PRECEDING and FOLLOWING to indicate prior and following working days
respectively
 MODIFIED to indicate next working day if within the same month and
previous working day otherwise
 NULL – According to rules set in FT.APPL.DEFAULT. Otherwise, next
working day
Slide 199
Product features – Value Dated balances
 When value dated accounting has been set through

ACCOUNT.PARAMETER, balance maintenance type standing orders
have the facility to specify which account balance to check when
transferring funds between accounts
 It is possible to check either the cleared balance, or a forward un-cleared
balance, by entering the number of forward working days from today’s date
in DAYS.DELIVERY Field
 This date is then checked against the value dated balances on the account
record
 If there is no direct match, the system will choose the nearest earlier date
 If no dates exist, then the system will default back to the cleared balance
 VALUE.DATED.BAL Field to be set as YES
Slide 200
Product features – Exchange rate
 When debit and credit account currencies are different, we can indicate
exchange rate in STO as a CUSTOMER.RATE or TREASURY.RATE
and CUSTOMER.SPREAD, which get defaulted in appropriate fields in
the FT application
 SETTLEMENT.MARKET and CONVERSION.TYPE (BUY, MID or

SELL) can also be defined in STO to enable the System to use the
appropriate exchange rate during FT processing
 On authorising a STO with these options, a new record is created in
SETTLEMENT.RATES with Standing order Id
 This has facility to opt for PROTECTION.CLAUSE by which either the
historic rate or System derived rate, which ever is beneficial to Bank can be
applied
 User can also manually input EV.APPL.RATE to override System derived
rate
Slide 201
Workshop - 14
 Use User Menu > Payment Services > Standing order > Balance
Maintenance STO > Choose Transaction Maintain Minimum Balance
 Set up the following standing order to maintain a minimum balance of USD
1,000 in your customer’s savings account
 Debit Customer’s CHF account, if needed, every Business day
 Use User Menu > Payment Services > Standing order > Balance
Maintenance STO > Choose Transaction Maintain Maximum Balance
 Set up the following standing order to maintain a maximum balance of USD
100,000 in your customer’s current account.
 Surplus, if any, to be transferred to Customer’s savings account, every
month on the last day
 Instructions valid for one year from the date of first transfer
 Credit less commission of ‘OUTREMITCHG’
Slide 202
Slide 203
Slide 204
Workshop - 15
 Use User Menu > Payment Services > Standing Order > Balance
Maintenance STO > Choose Transaction Max Bal Standing Order with
MT103-202
 Set up the following standing order to maintain a maximum balance of USD

50,000 in your customer’s Savings account.
 Surplus, if any, to be transferred to TEMENOS GENEVA (who have A/c

TEM 123456 with CITIBANK Geneva) through CHF Nostro Account
 Amount to be transferred on a monthly basis
 Debit plus commission of ‘OUTREMITCHG’ of USD 50
Slide 205
Slide 206
Product features – Forward entries
 To project the cash flows for the Internal/Customer Accounts involved

in STANDING.ORDER, forward entries are raised from standing order
for the next execution date
 Applicable only for “FI” STO.TYPE
 On input, forward entries are raised for the Customer/Internal Accounts

involved in the STO, with value date as next execution date (date
component as given in CURRENT.FREQUENCY) and with the amount
as given in CURRENT.AMOUNT.BAL
 Similarly when a STO is cycled to the next frequency, forward entries

are raised with the value date as Next frequency date
 To track cash flows, the value date and the amount given in STO are
updated in Available date & Dr/Cr movement related fields in Accounts
(subject to the CASH.FLOW.DAYS given in ACCOUNT.PARAMETER)
Slide 207
Workshop - 16
 Use User Menu > Payment Services > Standing order > Fixed
Transfers STO > Choose Transaction Fixed Amount Transfer
 Set the following Standing orders for your Customer’s GBP account,
 Use Fixed amount transfer, transfer GBP 2,000 once every two weeks to
Customer’s GBP account with you. Authorise the record
 Use Context sensitive enquiries and view the Forward movements of debit
account
 Use User Menu > Payment Services > Standing order > Periodic
Payments STO > Choose Transaction Periodic Payments
 Use Periodic payment ,register mandate to transfer GBP amounts to the
Account 13196 of American Electric Power. Authorise the record. Then
make a payment of GBP 2,124.58, being payment of Electric bill 321789
 Use User Menu > Payment Services > Standing order > Periodic
Payment s STO > Choose Transaction Periodic Payment of Interest
 Transfer the interest of your account to GBP Nostro account monthly on the
last day
Slide 208
Slide 209
Slide 210
Slide 211
Workshop - 17
 Use User Menu > Payment Services > Standing Order > Diary Action
 Input the following Standing orders for your Customer’s GBP account,
 Use Standing order - Diary Action , set a reminder to ‘Discuss investment
avenues with Customer’ once in a month
 Use User Menu > Payment Services > Standing Order > STO
Enquiries > Diary Actions
 View STO Enquiries – List of Diary actions, view all the diary actions
 Use User Menu > Payment Services > Standing order > Direct Debit
 Record Customers mandate to pay any Euro amount any time demanded
by ABC mortgage company
 Use User Menu > Payment Services > Standing order > STO
Enquiries > Direct Debit
 View List of all Direct debit mandates
Slide 212
Slide 213
Slide 214
Slide 215
Slide 216
Product features – Bulk code
 BULK.CODE.NO Field can be used to indicate a code that has already

been created on the STO.BULK.CODE table to enable the most
frequently used Standing Orders to be loaded in a table and avoids
repetitive input of four fields in the Standing Order instructions
 Beneficiary, Beneficiary’s Bank and Account number, Bank sort code (used
in United Kingdom for the BACS payments)
 Four fields updated automatically in STO

 Beneficiary, Beneficiary account number, Account with Bank and Bank sort
code
Slide 217
Product features – Resubmission of STO
 If a Standing order fails due to insufficient funds, associated FT is

placed on hold status pending manual intervention
 Standing orders can be set for automatic resubmission up to 10 days

 During COB or online using a phantom process at set time intervals by
setting up FT.APPL.DEFAULT through NO.RESUBMSSN.DAYS,
RETRY.START.TIME and RETRY.END.TIME Fields
 These methods can be combined to create a continuous retry process

that runs all day every day until funds become available or until the
resubmission day limit is reached
 When the retry limit is reached, FT record is put on hold as before, and
a delivery advice message as specified in SO.MESSAGE.TYPE Field in
FT.APPL.DEFAULT is generated
Slide 218
BULK.STO
 BULK.STO application is part of FUNDS.TRANSFER module

 Fully operational Bulk Standing Orders application
 Several outgoing standing order payments from a single account could

be bundled together and input as a single Bulk Standing order instead
of several Standing orders
 In many respects it is similar to the STANDING.ORDER application, except
that it allows credit to many accounts by debiting one account
 Standing orders are to be recorded as Fixed Payments with a known

amount
 It is possible either to execute as one-off payment or with an associated

frequency by using SINGLE.PAYMENT and CURRENT.FREQUENCY
Fields
 Monthly payment of staff salaries can be set with this facility
Slide 219
Workshop - 18
 Use User Menu > Payment Services > Bulk Standing Orders > Input
Bulk STOs
 Input Bulk Standing order for your Customer’s EUR account
 EUR 10,000 to be transferred to Customer’s GBP account
 EUR 5,000 to be transferred to Customer’s another CHF account with you
 Transfers to be scheduled on every business day from system date
Slide 220
Slide 221
SINGLE.BULK.STO
 BULK.STO processed during COB, but if required single payment bulk

STOs can be processed on-line
 SINGLE.BULK.STO application is used for this purpose

 Allows one or more Bulk Standing Orders to be executed
 Id can be 1 – 12 alpha numeric
 The User has to enter the ID of the Bulk Standing Order/s which are to
be processed
 Bulk Standing Orders which have SINGLE.PAYMENT Field set to 'YES',
and the date in SINGLE.PYMNT.DATE Field less than or equal to the date
of execution can be chosen
 Using Verify function, record is to be verified for on-line processing and

raising suitable FTs
Slide 222
FT.BULK.CREDIT
 FT.BULK.CREDIT application
 Used for handling single credit and multiple debit situations
 Similar to BULK.STO, which enables single debit and multiple credits
 Allows FT.TXN.TPE.CONDITION records based on AC or IT types

(Account to account or Inward by mail transfers)
 Possible either to execute as one-off payment or with an associated

frequency
 Using SINGLE.PAYMENT and CURRENT.FREQUENCY Fields
 Application may be run on-line or as COB process

 To run it on-line, SINGLE.INWARD.BULK application should be used
Slide 223
System maintained Tables
 STO.DIARY
 When Diary type of Standing order is created, STO.PAYMENTS program

will automatically update this internal file whenever the frequency date of
the Diary standing order has been reached. Here, System keeps track of
Diary text, Ordering Customer and Department identification
 As and when required, the User can request an on-line Print or display on
this file to verify any Diary instructions where it is expected that some action
should be taken
 Function LIST will provide Users with all the Diary instructions where the
frequency date has been reached
Slide 224
Quiz - 5
1) How many Balance maintenance standing orders can be set for an

Account?
Ans: 100 with Sequence numbers of 900 to 999
2) Which frequency is not allowed for Balance maintenance standing
orders?
Ans: Daily
3) Can we collect commission for handling Standing orders, and if yes, at
what frequency?
Ans: Yes at the same frequency set for Standing order. Starting date
can be later
4) When are bulk standing orders processed?
Ans: During COB. But single payment orders can be processed online
5) What types of Funds Transfer are used to execute DIARY type of
Standing order ?
Ans: None
Slide 225
FUNDS.TRANSFER - Dependency diagram
FT.COMMISSION.TYPE
CUSTOMER FT.CHARGE.TYPE
ACCOUNT CONDITION.PRIORITY
CATEGORY
FT.GEN.CONDITION
CURRENCY
FT.GROUP.CONDITION
LIMIT
COLLATERAL
STO
STO.TYPE FT
FT.APPL.DEFAULT
STO.BULK.CODE
ACCOUNT.CLASS
STO.DIARY
Slide 226
Bulk Payments
Slide 227
Bulk Payments – An Overview
 Corporates require payments to be executed as single transactions or

multiple transactions in one click. Examples of multiple transactions
include Payroll processing, direct debit claims, etc
 To facilitate these requirements, banks come up with solutions like

multiple credit and multiple debit facilities. They are termed as bulk
payments.
 Bulk payments could be of the following types:
 Multiple debit and single credit
 Multiple credit and single debit
 Temenos provides such payment facilities under the category of bulk

payments.
Slide 228
T24 Bulk Payments - Processing
 T24 provides the bulk payments functionality

complemented by the following attributes:
 The facility to upload entries from a preformatted

record through secured internet banking channel.
 The ability to specify single or multiple postings to

the customer’s account(s).
 The use of Mandate processing to ensure

authorised signatories approve the transaction.
Slide 229
Features of T24 Bulk Payments
Slide 230
Bulk Debit Processing
 Assume the situation of a Corporate

customer who wants to claim payment
amount from its clients. This is an instance
of multiple debits and single credit situation.
 System converts BULK.ITEM records into

DD.ITEM records and processing continues
in line with Direct Debit functionality
 Possible either to execute as one-off

payment or with an associated frequency
 Credit is posted to the corporate account.
Slide 231
Bulk Credit Processing
 While considering the example of payroll

processing, there is a single debit to the
corporate customer’s account and multiple
credits to the employees account.
 System converts BULK.ITEM records into
individual FUNDS.TRANSFER records,
 FT.BULK.MASTER value can be single or multi

 SINGLE - WASH.ACCOUNT is debited from
where the final amount will be swept into
ACTIVE.ACCOUNT.
 The credit side of the FUNDS.TRANSFER

involves the crediting of the payee.
 Funds transfer will then handle the required

functionality for generating clearing/swift entries.
Slide 232
Bulk Payments – Parameter tables
 Parameter tables for Bulk Payments

are to be set-up in:
 EB.FILE.UPLOAD.PARAM - Allows
system wide parameters to be
specified for file uploads to T24
 EB.FILE.UPLOAD.TYPE - Allows
parameters for a type of upload to be
defined. These include the upload
directory, optional maximum file size
limit, and optional extension.
Slide 233
FT.BULK.UPDATE.TYPE
 This application contains parameter

information for Bulk types represented in
FT.TXN.TYPE.CONDITION that should be
used
 It also captures the type of transaction -

SINLGE or MULTI type.
 It is then attached to FT.BULK.MASTER
Slide 234
FT.BULK.MASTER
 FT.BULK.MASTER application processes bulk

upload of credit and debit payments
 Upload can be done:

 Through Interface
 Manually
 It holds all the header information of a Bulk

upload.
 After creation of Master as unauthorized, the

relevant individual payments can be created or
uploaded through FT.BULK.ITEM application
 FT.BULK.MASTER can be SINGLE or MULTI
Slide 235
FT.BULK.ITEM
 This application hold individual payment

details of the Bulk upload.
 It can be created when the corresponding

FT.BULK.MASTER exists.
 Items will include information such as

 Destination account
 Amount.
 Payment type to be used (eg: BACS or

CHAPS)
 These values get populated in the

generated FT records based on
FT.TXN.TYPE.CONDITION.
Slide 236
Bulk Payments – Flow of Actions
Create parameter tables

EB.FILE.UPLOAD.PARAM
EB.FILE.UPLOAD.PARAM EB.FILE.UPLOAD.TYPE
EB.FILE.UPLOAD.TYPE
at setup level
Create the parameter

information for each type FT.BULK.UPDATE.TYPE
FT.BULK.UPDATE.TYPE
of bulk
Create the header to hold

FT.BULK.MASTER
FT.BULK.MASTER
information of a Bulk
upload
Update individual
payment details of the FT.BULK.ITEM
FT.BULK.ITEM
bulk upload
Slide 237
Processing the Bulk Items
Upload File
Creates Master and Items

Stage 1
The clerk/admin validates the

Master
Authorised
signatory (mostly
managers)
Login as the authorized
Stage 2 Authorize the Master
T24 creates individual FT records
Slide 238
Example – Step 1. Creation of FT.BULK.MASTER
Slide 239
Example – Step 1. Creation of FT.BULK.MASTER
Slide 240
Example – Step 2. Creation of FT.BULK.ITEMS
Slide 241
Example – Step 2. Creation of FT.BULK.ITEMS
Slide 242
Example – Step 3. Authorisation of Bulk Master
Slide 243
Summary
 We have so far seen
 The dependencies and linkages between Funds Transfer module and T24
Core and other applications
 Main business features of FT, STO, BULK.STO and Bulk Payments

Applications
Slide 244
Thank You
TEMENOS EDUCATION CENTRE

NOTICE
These training materials are the copyrighted work of Temenos Headquarters SA and other companies in the
TEMENOS group of companies (The Copyright Owner). The training materials contain protected logos, graphics and
images. Use of the training materials is restricted solely for use by licensed end users, partners and employees. Any
un-licensed reproduction by any means, redistribution, editing, transformation, publishing, distribution, or public
demonstration of the training materials whether for commercial or personal gain is expressly prohibited by law, and
may result in severe civil and criminal penalties. Violators will be prosecuted to the maximum extent possible. Such
training materials shall not be represented, extracted into or included in part, or in whole, as part of any other training
documentation without the express permission of the Copyright Owner, which must given in writing by an authorised
agent of the Copyright Owner to be valid. Where such permission is given a clear and prominent notice must be
displayed on any and all documentation accrediting the Copyright Owner with having copyright over the materials.
End-user licenses will in no event contain permissions extending the use of these training materials to third parties
for commercial training purposes.
Without limiting the foregoing, copying or reproduction of the training materials in part or in whole to any other sever
or location for further reproduction or redistribution is expressly prohibited, unless such reproduction is expressly
licensed by the Copyright Owner.
Copyright © 2010 Temenos Headquarters SA

T3TFT - Funds Transfer - R12.01

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T3TFT - Funds Transfer - R12.01

Uploaded by

Copyright:

Available Formats

T24 Funds Transfer

TEMENOS EDUCATION CENTRE

 Linkage of Funds Transfer with static tables

 Application specific Parameter tables

 Funds Transfer build sequence

Funds Transfer Drafts,

Accounting SWIFT messages Outward FT

Customer Advices Inward FT

 FT also uses other Static tables

 FT application used to transfer money between Customer type of

 Customer type of accounts use 1000 to 9999 range of Category codes

 Internal accounts use 10000 to 19999 range of Category codes

 PL category codes use Category codes above 50000

In FT, Commission can be

Commissions for specific

TAX can also be included

TAX can be included

NOSTRO.ACCOUNT generally defined

AGENCY defined Customer wise

Customer account to be debited for Charges /

 AGENCY record to set up Standard settlement instructions

 Issue of Cover Payment when there is no Nostro / Vostro account

 Cover message instructions can be set by AUTOROUTE.AGRD Field

 FIXING.DATE Field in CURRENCY table identifies date on which the

 FT checks value of FIXING.DATE Field on the run day

 Possible to define a cut off time in CURRENCY table for automatically

 For outgoing Funds Transfers

 For incoming Funds Transfers

1) FUNDS.TRANSFER can be used to move funds between Accounts

6) Cover Payment is issued when there is no Nostro / Vostro account

 Parameter tables for FUNDS.TRANSFER to be set-up during

 Parameter tables for STANDING.ORDER to be set-up

 Default conditions for Standard and Custom defined Transaction Types

 Separate record for each transaction type

 Id can be up to 4 characters of which first 2 alpha characters should be one

 There are 13 pre-defined standard transaction types of 2 alpha characters

 User can define any number of further payment types through

 Standard Outgoing payment types

 Standard Incoming payment types

 Standard Direct debits

 Standard Internal payment types

 User defined payment types

 Using these payment Types, funds can be transferred

 FT.TXN.TYPE.CONDITION is set up for each type of transaction, with

 Transaction codes defined through Fields

 Default Charges and commissions

 Value date restrictions

 Value date restrictions

 Customer float options for specific types of payments

 Possible to choose Customer float periods, by having different value dates

 Customer float can be opted on all transactions or rules can be set

 PAYMENT.TYPE Field can be set as CONV, NOCONV or ALL

 For a chosen Payment type, value date can be defaulted by using

 Value Date can be set as either the Processing Date, or a number of

 Delivery message options available for Print and Swift medium

 Debit advice generation could be controlled through

 Credit advice generation could be controlled through

 To use SWIFT BIC addresses in appropriate bank Fields,

 When user defined Transaction types are used,

SWIFT Description FT Transaction

MT 200 MT 202 Additional

 NOSTRO.XFER.TYPE Field in those records could be optionally set as

SWIFT Description FT Transaction