T3TFT - Funds Transfer - R14 PDF

T3TFT – Funds Transfer - R14 1
FUNDS.TRANSFER is one of the account based applications in T24 for

moving funds around the system internally and externally. It could involve
transfer of funds from one account to another account. It could involve transfer
of funds from internal accounts to customer accounts and vice versa. In Funds
Transfer we will be seeing linkages to various static tables like currency,
nostro account and commission on FT. The objective of the course will cover
application specific parameters connected with this application, build
sequence, product features. Standing order is one of the applications
encompassed in FT module. It covers various types of standing orders like
Balance maintenance, Periodic payment Fixed payment etc.

moving funds around the system internally and externally.
Internally, payments can be made to or from a Customer’s account or an
internal account. It could involve transferring money from one customer
account to another customer account. Some of the external types of payment
include Cheques, Mail Payment, Banker’s Draft, Clearing House Payments,
International payments via Correspondents etc.
Instructions can be fed manually or from other electronic communication
systems like Telex or SWIFT. It is linked to all types of outputs whether paper
or wire through the Delivery setup in T24.
The messages can be of two types, Customer advice and SWIFT message. If
there is an interface with SWIFT, then SWIFT message can be generated for
Outward FT. In respect of incoming SWIFT message it can be received and
automated to create FT in INAU status.
The application is designed to handle all types of currencies, local or foreign
and inward or outward payments.
On a real time basis, the application raises accounting entries and updates the
core limit setup whenever an account is debited or credited.
All Contract applications, FOREX, MM, MG, etc also generate movement of
funds, and do not require a Funds Transfer transaction to be done separately.

We need Accounts to handle various customer type transactions say for
movement of funds from debit accounts to credit accounts. We need to have
Customer records before opening Customer type of accounts. Nostro accounts
will be needed to transfer money externally using Agency arrangements.
Delivery in T24 refers to generation of Advices or Messages. Delivery is an
integral part of Core in T24 which is closely linked to transactions input
through FT module. Predefined messages/advices are generated on
authorisation of transaction . The relevant messages are produced as per
mapping and formatting setup such that details from the field input in
transaction are mapped to the pre defined fields and SWIFT tags. They are sent
through appropriate channels, Print, SWIFT or Telex. The channel or mode of
delivery can be configured system-wide for each message type and also setup
at the customer or account level.
On authorisation of FUNDS.TRANSFER, accounting entries are generated.
When an account is debited, system checks for balance in the account. Limit,
if any, sanctioned and attached to the account, is checked for availability of
limit. Override messages are raised for overdraft above the limit availability.
Funds Transfer application makes use of certain Static tables, like
CURRENCY, NOSTRO.ACCOUNT, AGENCY, FT.COMMISSION.TYPE
etc.

FT application is primarily used for transfer of money from one account to
another. It makes use of any of the following types, namely Customer
accounts, internal accounts and Profit and loss categories. Customers have
different types of Accounts such as, Current Accounts, Savings Accounts,
Margin Accounts and so on. We also have internal accounts, which are bank’s
own accounts. Examples are Cash account, Suspense Account, Draft payable
account etc. Profit and Loss items, called Categories in T24, are basically of
two types namely product related income or expense like interest on Loans,
Commission on LC, Charges on Current Account etc. and non product related
like Salaries, Rent, Electricity, etc. All these groups are differentiated by using
suitable range of CATEGORY code.
For example, if there is a transfer of amount from one customer account to
another customer account of the same bank/branch, then the transfer is
between two customer accounts. If a customer requests for a Cashier cheque
or a Demand Draft then a charge is collected for the purpose. Now, it makes
use of three accounts namely a customer account, internal account and Profit
and loss items.
Care should be taken when defining additional sub-classifications of category.
For example, you need not define separate CATEGORY codes for resident and
non-resident customer accounts or for local and foreign currency accounts as
these can be obtained from the definition of Customer or Account used.

FT.COMMISSION.TYPE defines different types of commission used for
various transactions in FUNDS.TRANSFER application. Commission can be
defined as a flat amount or as a percentage, which varies according to the
amount of transaction. Percentages can be defined separately for different
Bands or Levels of transfer amounts. Minimum and maximum commissions
can be specified for each Band or Level together with overall minimum and or
maximum amounts. Commissions can be defined currency wise. Currency
code specified here in association with the percentage or the amount of
commission will always refer to the Currency of the transfer, debit Currency
for the inward payments and credit Currency for all other types of payments.
When transaction currency is not defined here, then default taken from the
local currency or specified default currency condition and calculates
appropriate equivalent amount using the rates held on the CURRENCY file.
CCY.CONV.DEPENDENT Field determines whether Commission Type is to
be applied only when Foreign Exchange conversion is required. By indicating
“YES” value in this field, it indicates that the derived commission amount is
only to be applied when the Debit and Credit Currencies are different. Tax
codes can also be optionally attached. Charges and tax can also be collected in
a FUNDS.TRANSFER application when this is linked through
FT.TXN.TYPE.CONDITION. It is possible to indicate whether the
commission collected is to be amortised over a desired period, or alternately,
commission to be collected in a scheduled future date requires to be accrued.

This feature is used in Accounts and contracts which make use of the particular
commission which has been opted for accrual or amortisation.

FT.CHARGE.TYPE is another Table which can be used when the charge
amount is a FLAT amount, regardless of the monetary value of the transaction,
but they may be varied according to the country and zone of relevant
customer and by currency.
Where necessary, charge can be defined according to the destination Country
Zone, represented by residence of the Credit party. This facility should only be
used in respect of charges for telex, or postage where various charges are
applicable due to the locality. The entire charge can be waived depending on
whether ordering customer is resident or non-resident within certain countries.
Charge applied only when the charged Customer is a resident or non-resident
of specified countries. For example charges can be defined separately for EEC
and NON-EEC resident customers.
Any destination country which has not been specifically defined within this
record will automatically fall within default Zone and its corresponding
Charge.

NOSTRO.ACCOUNT table defines the Nostro Accounts by Currency for
default Nostro in each application. Additionally for FT, different accounts can
be specified, if necessary, for each Transaction type.
AGENCY, file contains settlement details of major customers and all banks.
Details include where possible the Agents correspondent bankers for specific
currencies. This eliminates the need to re-enter the details at transaction level.
For Inward Payments, DEBIT.ACCT.NO Field in FT will contain Our
Correspondent Bank Account detail. System defaults Nostro account in debit
account for Foreign Currency and Vostro Account for Local Currency. For
Outward Payment Orders, this field will usually be our Customer’s account.
For inward transfers, CREDIT.ACCT.NO Field will usually be our Customer’s
account. For foreign Currency outward transfers this field will usually default
to the Nostro account of the credit currency. For local Currency outward
transfers, this will default to the Vostro account of the Receiver bank if defined
in the Agency record.
A CUSTOMER.CHARGE record for each customer will be automatically
created whenever a new CUSTOMER record is authorised.
CHG.COM.ACCOUNT in CUSTOMER.CHARGE defines the account
number to be debited when the customer is required to pay
commission/charges in the Funds Transfer application. When defined here, it

defaults into CHARGES.ACCT.NO Field in FT

AGENCY file contains standard settlement instructions of major customers
and all banks irrespective of whether there is any business connection or not.
Basic details of these banks and major customers must first be defined in the
CUSTOMER. Main objective of this file is to keep a default delivery and
settlement instructions for a customer which otherwise would have to be input
repeatedly on each and every transaction. The details include any arrangement,
account relationship and where ever possible, agents’ correspondent bankers
for specific currencies.
This information is entered centrally to supply automatic routing instructions
for remittances/cover to all banks and customers with whom the Bank has
numerous dealings. At times the receiving bank’s correspondent could be same
as Nostro bank. In such case we can instruct system regarding cover message
by using the field AUTOROUTE.AGRD.
AUTOROUTE.AGRD Field is used where there is an agreement in place with
the correspondent for reimbursement on payments sent to other banks. Three
options are available namely “Blank”, “NO” and “YES”. If input is blank then
cover payment will be sent and swift message will contain values in both the
sender and receiver correspondent. If the input is No, then cover payment will
be sent but SWIFT message will contain value only in sender’s correspondent.
If the input is Yes, then cover payment is suppressed.

COUNTRY table contains static details of each Country like Country Name,
Currency Code, Business centre, Consumer goods index, Central bank etc.
CURRENCY.PARAM table contains common details for each Currency to
ensure that the same numeric code and no of decimals are used on different
currency files in a multi company environment.
CURRENCY file contains the exchange rates for each currency. It is possible
to create different market rates for the same currency and have separate rates
for each market. Buying rate is defaulted for foreign currency debit currency
and selling rate for credit currency,
Up to 99 markets can be indicated in CURRENCY.MARKET table.
Consolidation keys are formed market wise. Markets beyond 9 will be
consolidated with the market type of the first digit – example 10 with 1.
It is possible to indicate the market to apply its rates for any specific type of
funds transfer, by indicating the market in the respective
FT.TXN.TYPE.CONDITION table.

In some countries, exchange rates for major currencies are fixed daily between
banks and local central bank. In CURRENCY application, the FIXING.DATE
Field will therefore identify the date on which exchange rates were last loaded.
For those countries where "Fixing Rates" practice is applicable, the value of
this field will be checked by the FUNDS.TRANSFER application to determine
if the fixing rates have already been input for the run day.
When an exchange rate for a currency is not fixed in the CURRENCY
application, and there is a FT transaction involving that currency, T24 raises a
message “RATE NOT FIXED – USE EXISTING RATE”. This leads to
RATE.FIXING Field in FT. If Yes is opted, then last available exchange rates
will be used. If No is opted, then the transaction has to wait till the exchange
rates for the day is available.
When response is “No” then T24 creates FT with INORATE status, which
could be duly approved. There upon the status changes to ANORATE. When
the rates for the day are loaded, and FT.RATE.PROCESS service is run, all
these transactions are automatically processed with the new exchange rate.
Accounting entries, position and delivery messages are then generated.

Defaulting of value dates in a FT can be generated by the use of field,
CUT.OFF.TIME on the CURRENCY file. Different cut off time can be
specified for each currency.
The default value date for a funds transfer can be calculated by comparing the
transaction entry time with the CUT.OFF.TIME specified for a currency.
Transactions effected after the time specified will have the value date after
current date.
For example, if the time mentioned in CURRENCY is 2 PM, then funds
transfer with transaction entry time after 2 PM will have a value date of next
day.
For outgoing FT, defaulting of value dates in a FT can be generated by the use
of CUT.OFF.TIME Field on the CURRENCY file and CUT.OFF.RULE Field
on the AGENCY file.
CUT.OFF.RULE Field on the AGENCY file can be set to either 0 or 1 , 0
implying the value date as next date and 1 to move the value date by one more
day.
The 2 fields together will calculate the default DEBIT.VALUE.DATE for an
outgoing FT, otherwise the FT.TXN.TYPE.CONDITION record for the
particular transaction type will be used to generate the default date.

For outgoing funds transfer transactions, CUT.OFF.TIME Field in
CURRENCY record is used in conjunction with CUT.OFF.RULE on the
AGENCY table. If these have both been set, DEBIT.VALUE.DATE for
outgoing funds transfer will be defaulted as follows:
If the transaction is entered before the cut off time on the CURRENCY file
(for the debit currency) and CUT.OFF.RULE contains 0, then the debit value
date will be today’s date.
If CUT.OFF.RULE contains 1, then the debit value date will be today’s date +1
working day.
If the transaction is entered after the cut off time on the currency file (for the
debit currency) and CUT.OFF.RULE contains 0, then the debit value date will
be the next working day.
If CUT.OFF.RULE contains 1, then the debit value date will be the next
working day +1 working day.

For incoming funds transfer transactions CUT.OFF.TIME Field of Credit
currency is used in conjunction with debit and credit currencies to determine
default CREDIT. VALUE.DATE.
By using CUT.OFF.TIME the default credit value date on incoming funds
transfer transaction is derived on the following basis -
If debit value date is prior or equal to date of receipt and time of receipt is
prior to or equal to CUT.OFF.TIME , then
If debit currency is equal to credit currency, credit value date will be defaulted
as date of receipt.
If debit currency is not equal to credit currency, credit value date will be
defaulted as date of receipt + 1 working day
If debit value date is prior or equal to date of receipt and time of receipt is later
than CUT.OFF.TIME , then we have
If debit currency is equal to credit currency, credit value date will be defaulted
as date of receipt + 1 working day
If debit currency is not equal to credit currency, debit value date is prior or
equal to date of receipt and the time of receipt is after CUT.OFF.TIME, credit
value date will be defaulted as date of receipt + 2 working days.
In the same case, if debit value date is later than the date of receipt, then credit
value date will be debit value date plus two working days.

These parameter tables are set up during the process of implementation for
funds transfer activity.
FT.TXN.TYPE.CONDITION, table defines the default conditions for each
transaction type, which can be processed by the FUNDS.TRANSFER and
STANDING.ORDER applications.
EB.DUPLICATE.TYPE, table enables the user to check the occurrence of any
FT duplicate contracts.
FT.APPL.DEFAULT, table contains application level default values, which
will be used while processing FUNDS.TRANSFER or STANDING.ORDER
instruction. The user must create one record for each company.
CONDITION.PRIORITY is a table where a user defines the order of priority
to choose criteria for creating groups for differential treatment.
FT.GEN.CONDITION file is dependent on CONDITION.PRIORITY and
defines values from the chosen decision tables which will be required to define
the group and the group name.
FT.GROUP.CONDITION table holds the basis on which charges and
commission are adjusted in FT transactions for different groups of customers.
CORR.BANK.CHARGES defines charges and commission defaulted in FT
during inward and outward processing.

Encompassed within the FT module is a fully operational sub - module for
effecting regular payments. STANDING.ORDER is a file which holds details
of such payments.
A maximum of 9999 standing orders can be defined for one account.
STO.TYPE is the table which defines the types of standing orders that can be
used.
STO.BULK.CODE contains additional details for standing order instructions
which are beneficiary related.
STANDING.ORDER is used for single debit/credit transaction. Multiple
credit/debit to various accounts by debiting/crediting a single account is also
possible in standing order. These type of instructions are input in BULK.STO
and FT.BULK.CREDIT respectively. Its operations are very similar to that of
STANDING.ORDER. Whenever bulk standing orders are executed, the
accounting entries are washed through an internal suspense account as defined
in ACCOUNT.CLASS. For that purpose a record called SUSFTBULK should
be in place and have the relevant accounts opened before using BULK.STO.
Similarly there should be a record called SUSPFTINWD for FT inward
transaction.

FT.TXN.TYPE.CONDITION table defines the default conditions for each
transaction type, which can be processed by the FUNDS.TRANSFER and
STANDING.ORDER applications. These can be summarised as follows
There will be a separate record for each transaction type, like account transfer,
inward payment, outward telex etc. For each transaction type there can be
separate transaction codes for debit and credit and is used for generation of
accounting entries.
It has the default commission or charge types applicable for each transaction
type. These commission types must first have been defined in
FT.COMMISSION.TYPE/FT.CHARGE.TYPE.
The Maximum Forward and Back Value dates applicable for each transaction
type must be specified
The default Value Date conditions may be defined for each transaction type.
Id to be used are of four characters of which first two alpha characters are pre
defined. It is also possible for the user to define any number of payment types
through FT.TXN.TYPE.CONDITION, by extending the Id with final 2
characters.
For example OT03 means outward telex payment with MT 103 message , OT
refers to outward telex payment.

Standard outgoing and incoming payments types which are pre defined in
FT.TXN.TYPE.CONDITION are as under:
OC is for issue of Bankers cheque / Managers cheque in local currency in
favour of beneficiary who does not maintain an account with the bank.
OD is for issue of Bankers draft, usually in foreign currency in favour of
beneficiary who does not maintain an account with the bank.
OT is for money transfer via SWIFT or Telex. Instructions are usually sent to
Bank’s correspondent. Use of this transaction type will automatically produce
both pay and cover cables when required.
OB is for outward bank payments and used in inter bank transactions.
BC is for outward local clearing.
IC is for receipt of a cheque or draft to be credited to a customer’s account
with the bank.
IT is for receipt of SWIFT transfer or telex payment in favour of one of our
customers having account with the bank.
IB is for inward bank payments.
IM is for inward mail transfer.
BI is for inward local clearing.

Standard internal payments includes AC for account to account transfer and
DW for direct drawing for transfer by correspondent banks.
User defined transaction types will comprise of the pre defined first 2
characters appended by user defined alphanumeric namely ACCL or OT03
Here are some examples of the business services that FT is designed to
support.
WITHIN THE BRANCH – Transfer of funds between two accounts within the
same branch.
BETWEEN BRANCHES – Transfer of funds between two accounts within the
same bank, but accounts are held in different branches of the Bank.
BETWEEN BANKS VIA LOCAL CLEARING – Transfer of funds between
accounts in different banks using the local/national clearing system.
CHEQUES TO BANKS OR BENEFICIARIES – Issue of bankers cheques or
drafts by order of the client and sent to the beneficiary or their bank.
INTERNATIONAL PAYMENT VIA CORRESPONDENTS - Transfer of
funds using Telex or SWIFT, in any currency, to any country via the
correspondent network the Bank has established.
BANKS OWN PAYMENTS – To make salary and other payments to its
employees, suppliers, etc.

In FT.TXN.TYPE.CONDITION, for each type of transaction specific codes
should be assigned which will be used for generation of entries in T24.
DR.CHEQUE.TXN.CODE defines the debit transaction code to be assigned
when a cheque is issued by a customer and presented for payment.
Identification of a specific transaction code for this type of transaction will
result in the cheque number input appearing on the statement. To get the
cheque number printed on the statement CHEQUE.IND Field on
TRANSACTION table must be set to YES.
The transaction code for generating credit and debit entries in
FUNDS.TRANSFER application is defined in TXN.CODE.CR and
TXN.CODE.DR respectively.
Like wise the details of the transaction code for generating credit and debit
entries of Standing order is defined in STO.TXN.CODE. CR and
STO.TXN.CODE.DR.
BULK.TXN.CODE.CR and BULK.TXN.CODE.DR indicate the transaction
code for generating credit and debit entries in a bulk standing order.
DR.CHARGE.TXN.CODE defines the transaction code for generating
accounting entries for charges.

COMM.TYPES and CHARGE.TYPES Fields which define the default
Commission or charges applicable to this transaction type. Valid commissions
should have been pre defined in FT.COMMISSION.TYPE and charges should
have been defined in FT.CHARGE.TYPE. The default commission types
specified in this field will be applied automatically in a FT but at the
transaction these can be waived or modified.
FORW.VALUE.MAXIMUM Field allows to specify a maximum period of
forward Value or Exposure Date for this transaction type which could be
either the Processing Date, or a number of working or calendar days to be
added to the Processing Date. Valid values will be Y to indicate that the run
date is maximum and N to indicate no special maximum. Alternatively, +01C
indicates one calendar day forward or +03W would be 3 working days forward
or +01W+02C would be 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. Any Funds
Transfer payment input for this Transaction Type with a Forward Value Date
greater than that specified in this field raises an override which must be
accepted.
Date specified in this field may not be later than the Forward Value Maximum
as specified in the DATES file.

BACK.VALUE.MAXIMUM Field allows to specify a Maximum back Value
or Exposure Date for this Transaction Type being either the Processing Date,
or a number of working or calendar days to be subtracted from the processing
Date. This prevents the operator from inputting a Value Date or an Exposure
Date which is before an acceptable period for this type of transaction. Y to
indicate run date, N or No to indicate no special maximum needed.
Any Funds Transfer payment input for the Transaction Type with a Back Value
date greater than that specified in this field must be overridden.
Example A Default Value Date of -03W would be 3 working days backwards.
or -01W-02C would be 1 working day plus 2 calendar days backwards.
The date specified in this field may not be earlier than the Back Value
Maximum as specified in the DATES file.

Rules can be set for application of value date conditions for a customer.
Defaulting conditions can be applied for all transactions or set separately for
transactions involving conversion of one currency to another and another for
no conversion.
PAYMENT.TYPE Field which provides facility to define whether or not
conversion is involved in the transaction in order to determine if different
Value Date conditions exist. This field defines the type of Payment for which
the Value Date conditions defined in the next three fields are applicable.
If PAYMENT.TYPE of CONV is chosen, conditions specified in the next
three fields are only applicable to transactions involving conversion of
Currencies. In the same way, if NOCONV is chosen, conditions specified in
the next three fields are only applicable to transactions not involving
conversion of currencies.
For PAYMENT.TYPE of ALL, the conditions specified in the next three fields
are applicable to all transactions irrespective of whether the transactions
involve conversion of Currencies or not.
If ALL is specified, no other Payment Types may be input. If either CONV or
NOCONV is input, both must be specified, separately as one is not valid
without the other.

PAYMENT.VALUE Field specifies the default payment or transfer Value date
applicable to the Payment Type for this type of transaction. It specifies the
number of calendar or working days to be added to or subtracted from the
Processing Date in order to obtain the default Value Date.
Example: A Default Value Date of +03W would be 3 working days forward. or
+01W+02C would be 1 working day plus 2 calendar days forward.
CUSTOMER.FLOAT Field defines the default number of days to be applied
for any customer value date applicable to the payment type for this type of
transaction. This field allows the User to define special Customer Value Date
conditions at the transaction level. If zero '0' is input, the Customer will
receive funds on the same day value. If 1 is input the customer will receive the
funds on the next working day. For example in the case of incoming transfer
when the debit value date in nostro account is 15th Jan and if the customer float
is set as 3 then the customer will receive the credit with value date 18th Jan. In
the case of outgoing funds transfer if the credit to nostro account is value 15th
Jan and if the customer float is 2 then the debit to customer account will be on
13th Jan.
SAME.CUST.FLOAT Field specifies the default Customer Value Date
condition applicable to the Payment Type for the Account Transfer Transaction
Type when the credit and debit parties are the same customer. Valid number of
days can be specified. If the zero ('0') is input, both the debit and credit entries

will receive the same Value Date.

In FT.TXN.TYPE.CONDITION, delivery options can be set or controlled for
each type of funds transfer transaction .
For example: If an account to account transfer is effected, then the rules for
generation of debit advice and credit advice has to be set up in a field called
DR. ADVICE.REQD or CR. ADVICE.REQD.
If no input is specified in DR.ADVICE.REQD then in outgoing fund transfer
like outward clearing, outward draft and outward telex debit advice will be
automatically generated by default.
Similarly in CR.ADVICE.REQD also it has to be mentioned whether credit
advice is to be generated for a specific transaction. If no input is specified then
credit advice will not be generated.
In the case of SWIFT messages, there is a facility to enter the SWIFT Id (BIC
code) instead of entering the customer number and hence reducing the
overhead of looking up the customer number when only the SWIFT Id is
known.
If the SWIFT.ADDRESS Field in the FT.TXN.TYPE.CONDITION is set to Y
then the user can instead of giving Customer Id or free text, input the Swift
Address prefixed by SW- in the following bank fields in FUNDS.TRANSFER
like
ORDERING.BANK, ACCT.WITH.BANK, BEN.BANK, REC.CORR.BANK

and INTERMED.BANK

To support different types of print format advices in respect of same
transaction type, APPLICATION.FORMAT Field can be used to specify an
application format which will be used instead of default values for transaction
type specified in the key of the record.
User defined transaction types namely OT01 or OTAB can be defined to have
different format of print advices for customer payment advice as compared to
standard transaction type of OT.
When input is valid in this field, appropriate records should be created on the
DE.FORMAT.PRINT file, which carries format of the printed message used by
delivery module. Input in this field will form the second part of the
DE.FORMAT.PRINT key

By suitable setup in FT.TXN.TYPE.CONDITION , it is possible to generate
different types of swift messages in FUNDS.TRANSFER application.
MT200/202 can be used for financial institution transfer by setting
NOSTRO.XFER Field in FT.TXN.TYPE.CONDITION accordingly. Transfer
between Nostro accounts are handled as Financial institution transfer between
own accounts. SWIFT message that is generated on account of transfer
between own accounts can be MT 200. If one of the Nostro is having a surplus
funds it can be transferred to another Nostro account, where there is a shortfall.
For example Citi Bank New York is maintaining GBP account with
American Express Bank London and also with Allied Irish Bank London. If
there is a shortfall of funds in American Express Bank London, then Citi Bank
New York can effect a funds transfer from Allied Irish Bank to American
Express bank London. Such type of transfer of funds from one Nostro account
to another Nostro account are handled in Funds transfer under MT 200. It is
also possible to transfer funds from Nostro account in one currency to another
Nostro account in different currency. For example, transfer of funds from GBP
Nostro account with Barclays Bank to USD Nostro account with Bank of New
York.

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 MT200 (Transfer for own account) or MT202 (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.
The Value of 200 (or null) will generate MT200 messages as normal
functionality.
202 will require additional input of Beneficiary and Ordering related fields in
FUNDS.TRANSFER application for transfers between Nostro Accounts.

MT103 is message for Single Customer Credit Transfer.
For this to happen, the OT record on application FT.TXN.TYPE.CONDITION
must have the MESSAGE.TYPE Field set to 103.
NOSTRO.XFER Field in FT.TXN.TYPE.CONDITION accordingly.
Transferring money can be done electronically and advised to various parties
through Swift messages using the cover method of payment.
Dell can request T24 Bank to transfer GBP10,000 electronically to Bishop.
Let us take the GBP nostro account of Dell’s banker (T24) as Barclay’s bank,
London. Bishop, the beneficiary may not maintain his account with Barclay’s
Bank, London. In such a situation, if Bishop’s banker namely Citibank has an
account with Barclay’s bank, London, then payment moves from Dell to
Bishop passing through Barclay’s Bank and Citibank. T24 will handle different
combination of swift messages for such a situation, namely MT103 to Citibank
and cover message MT202COV to Barclay’s bank.
Thus we have a client bank which is sending an outward remittances will send
a MT 103 message to the beneficiary bank, giving the full details of the
payment message, by indicating the ordering customer name, beneficiary’s

account number, bank name, payment details etc. Simultaneously it will send a
MT202COV to its nostro bank as a cover payment message.

In the case of outward transfers, normally SWIFT message MT202 will be sent
for institutional payments and MT103 will be sent for customer payments.
Depending on the owner of the debit account, system will update the ordering
bank or ordering customer and send MT202 or MT103.
If MT 202 is to be sent in the case of debit account not being a bank, then
BANK.PAYMENT Field has to be defined as Y. This ensures that an MT202
payment message is created instead of the usual MT 103 when the client of the
debit account is not bank. For such cases, the following rules must be followed
in the FT transaction.
Rule 1: Both ORDERING.BANK and BENEFICIARY.BANK Fields must be
present in the transaction.
Rule 2 : ORDERING.CUSTOMER must not be completed.
This option will only be allowed for transaction types OT and when
MESSAGE.TYPE is blank or MESSAGE.TYPE is 103.
The Delivery Process in Funds Transfer will be amended to produce an MT202
instead of MT 103 if this option is selected.

For outward transfers meant for beneficiaries other than banks, Tag 59 of Swift
message will contain beneficiary name. To ensure that these details are
mandatorily provided in such cases, NO.BEN.CUST.Y.N Field in
FT.TXN.TYPE.CONDITION of the concerned transaction type could be set as
Yes, by which BEN.CUSTOMER Field in the FT will be Mandatory.
Where the bank has a need to pay funds to a client using only an account
number, to maintain client confidentiality or other such reasons, option of YES
in BEN.ACCOUNT.ONLY Field will allow input of just the beneficiary
account number.
Where the field is set to 'Yes' then if the transaction has only the beneficiary
account number entered (in the BEN.ACCT.NO Field on the
FUNDS.TRANSFER application) then no validation error will occur. The
delivery message will be modified so that the beneficiary account number is
mapped to the beneficiary name in order that message is acceptable to SWIFT
Since this is not a standard banking practice, the default will be to require the
beneficiary name with an optional account number.

Automatic MT110 Advice of Cheque: T24 is able to produce an MT110 from
the FUNDS.TRANSFER application when OC or OD transactions are input.
In order for this to happen, the OC or OD records on application
FT.TXN.TYPE.CONDITION must have the MESSAGE.TYPE Field set to
110. When a foreign currency demand draft is issued, Banks usually send out a
confirmation to its Nostro Bank by means of Swift message MT110. MT 110
contains details of the Transaction reference number, Date of Issue of draft,
Amount of draft, Draft number, Beneficiary name along with instructions, if
any, for payment of the draft when presented to the Nostro Bank.
Nostro Bank will act on this MT 110 message once the draft is presented for
payment.
For example: Michael Dell has an account with T24 Bank and wants to send
an amount to Frank Bishop, who is not an account holder in T24 Bank. In this
instance, T24 Bank will issue a draft in favour of Frank Bishop by debiting the
account of Michael Dell. Simultaneously, T24 Bank will advise its Nostro
Bank namely, Barclays Bank, London with a MT110 message. The draft is
sent by Michael Dell to Frank Bishop, who presents the draft to Barclays Bank
for payment. Based on the instructions received by Barclays Bank, the draft
will be honoured and payment made to the beneficiary.

NOSTRO.XFER Field in FT.TXN.TYPE.CONDITION accordingly.
Automatic MT400 Advice of Payment: T24 is able to produce an MT400 from
the FUNDS.TRANSFER application when OT transactions are input. In order
for this to happen, the OT records on application FT.TXN.TYPE.CONDITION
must have the MESSAGE.TYPE Field set to 400

MESSAGE.TYPE Field indicates what sort of message will be produced from
each FT transaction type. When this field is left blank the message sent will be
either MT103 for payment message types, or for cheques issued, advice type
40 (print only) will be defaulted.
Valid message types are :
MT103 is used for single customer funds transfer.
MT110 is used for confirming issuance of a cheque to Drawee bank
MT400 is used to advice payment of a collection or part thereof.
MESSAGE.COND.ID Field is used to control production of MT210 message
for institutional payments to notify the receiver that it will receive funds for
sender’s account. Field when set as 210 in respect of specific funds transfer
type starting with I for inward swift or telex payment and O for outward swift
or telex payment, system will produce MT210.

FT can process incoming (inward) messages to produce FT transactions, some
of which may in turn produce onward (outward) messages. This is done by
using either FT.IN.PROCESSING, or by utilising OFS. They can both take an
inward SWIFT message generated via the relevant SWIFT carrier and use it to
produce a FUNDS.TRANSFER.
From inward swift payments MT200 or MT202, depending on the transaction
type, it is possible to send MT205, further transmission request domestically or
send MT202 messages automatically.
For generating on-forwarding messages the field FWD.IN.TXN Field has to
be filled up. This field has three option namely YES to generate message
MT205, NO to block message and 202 to generate MT202.
SEND.PAYMENT.Y.N Field is used to control the generation of Payment
Message during a FT transaction. In case of transaction type other than
AC/DW, this field can be set as Yes and hence the system will default “Yes” in
SEND.PAYMENT.Y.N Field in FUNDS.TRANSFER record. This will trigger
MT 210 message , notifying the receiver that it will receive funds for the
sender’s account.
For transaction types AC/DW it will always default to Null as no payment
message can be generated for these types.

ALLOW.EXCHANGE Field defines whether the input of two different
currencies requiring an exchange rate will be allowed in a funds transfer
transaction.
If there is no input or input equals 'Y', different currencies will be allowed for
a funds transfer of this transaction type.
Input of 'N‘ restricts any funds transfer input to the same debit and credit
currency for the transaction type.
It is possible to indicate a pre defined currency market through a field called
DEFAULT.DEAL.MKT, provided the transaction type allows different
currencies for debit and credit sides.
Rates for markets defined in the above field in FT.TXN.TYPE.CONDITION
are defaulted into DEAL.MARKET of a funds transfer transaction.

A funds transfer can be input and set to be processed on a future date. Such
type of transaction can be input or authorised as normal and will be identified
with specific funds transfer status codes of IFWD and AFWD. In such cases
the exchange rate will be on the date of processing rather than the rate of input.
In funds transfers where the processing date is set for a future date, it is
possible to default the treasury rate as at the PROCESSING.DATE instead of
rate as on deal input date. The same is controlled by defining Yes in a field
called RECALC.FWD.RATE. In a funds transfer of such transaction is input
without user furnishing rate then treasury rate of processing date is used in the
transaction.

There are possibilities of duplicate funds transfer transaction being input into
the system.
For example, if debit account, amount and value dates are all same for two
FTs, then there is a possibility of duplication and hence the System warns user
whenever this happens.
For that purpose it is possible to set rules for checking whether a FT
transaction is likely to be a duplicate of another similar transaction.
EB.DUPLICATE.TYPE file allows definition of criteria to check the
occurrence of any duplicate contracts.
Several records can be created in EB.DUPLICATE.TYPE file.
For a particular transaction type, like OT03, we can specify the records for
which check has to be made by using the multi value field of
DUPLICATE.CHECK Field in FT.TXN.TYPE.CONDITION

Banks are often advised of details of incoming funds by other institutions or
clients. This information can help the bank to allow a client an intra day
overdraft, since the funds advised could be guaranteed, or the bank may take a
business risk and allow the payment.
In order to do this the expected receipt information needs to be recorded in
T24 and used to provide balance projection information for ad-hoc Enquiries
or reports.
AC.EXPECTED.RECS application allows the user to enter the expected
receipts manually or to have them created by incoming SWIFT MT210s and to
match them with actual receipts, either automatically or manually.
Funds Transfers can be set to create an automatic 'receipt' record in
AC.EXPECTED.RECS being the opposite to the 'expected' record. Where the
receipt is the one 'expected' and providing the details are all correct or within
defined tolerances then an auto match is made when the FT for receipt is
authorised. Others need to be matched manually. Updates of expected receipts
are also stored in the ACCOUNT file and users can have enquiries for details.
EXPECTED.RECS Field of FT.TXN.TYPE.CONDITION set as Yes indicates
that this type of FT will be used to generate AC.EXPECTED.RECS records as
RECEIPT types for possible automatic or manual matching with EXPECTED
records.
Input is allowed for inward types beginning with IT

Generally at the close of Business, FT records are moved to history.
To reverse FT records which are in the history, HIS.REVERSAL Field of
FT.TXN.TYPE.CONDITION should have been set as YES. This field controls
the reversal of FUNDS. TRANSFER contracts which are moved to History
after close of business.
As Funds would have already been transferred, this option is 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 back again.
When HIS.REVERSAL flag is NULL then the FUNDS.TRANSFER cannot be
reversed after moving to History.

Generally Banks receive charges and commission for the incoming Funds
Transfer from the remitting bank. Any charges which are received through FT
Inward processing need to be automatically accounted into suitable PL head of
accounts by the system.
For this purpose, a suitable record from FT.CHARGE.TYPE need to be
specified in IN.CHG.CODE. Field
When an Incoming MT103 is processed and charges are specified in Tag 71G ,
this will be credited using the charge code details from FT.CHARGE.TYPE
like TRANSACTION. CODE, PL-CATEGORY etc.
Incase this field is not defined for the transaction type used during Inward
Processing of MT103 message with SWIFT tag 71g, then system moves the
resultant FUNDS.TRANSFER contract to Hold status with error information
in IN.PROCESS.ERR. Field

ALLOW.POST.CLOSE Field when set to Yes specifies whether this
FT.TXN.TYPE.CONDITION can be used to input entries pertaining to
previous year even after financial closing is over , but within the post closing
period .
Generally the debit value should be equal to or prior to credit value date.
However, where FT is to be used to pass value date corrections this restriction
needs to be relaxed. In order to allow debit value dates after the credit value
date, the DB.AFTER.CR Field should be set as Yes. To limit any possible
mistakes the number of days that the dates can differ should be entered into the
DB.A.CR.MAX.DAYS Field.

EB.DUPLICATE.TYPE is an application where it is possible to set rules for
checking the occurrence of duplicate contracts. Though Id is alphanumeric, it
can be designed to reflect nature of rules. For example FTREMIT could be
used for duplicate checking of FT used for remitting purpose.
The application for which duplicate check is intended should be indicated in
APPLICATION Field.
The rules or criteria for comparison should be defined in the multi value fields
with the name FIELDS. This may also be user-defined field or a user-defined
calculated value field type "I” on STANDARD.SELECTION.
Field values that are to be compared for determining whether the transaction
whether it is duplicate or not has to be mentioned in DEBIT.AMOUNT, and
DEBIT.ACCT.NO. 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.

One or more records of EB.DUPLICATE.TYPE can be attached to required
FT.TXN.TYPE.CONDITION records. Assume 2 duplicate types have been set
up (1) Credit account number and amount and (2) Debit amount. For AC type
condition, duplicate check could be done based on either the first type or
second or both.
When a FT of the chosen transaction type is input, System creates a record in
EB.DUPLICATE, if not already present, and checks this with subsequent
transactions for possible duplicates.
Id of EB.DUPLICATE depends on FIELDS defined in
EB.DUPLICATE.TYPE file.
If only one FIELD is defined on the EB.DUPLICATE.TYPE file, then the key
will be composed of that one FIELD. If more than one FIELD are defined,
then the key will be composed of the number of fields defined joined together
with asterisks.
Credit Account number and amount in the first case and debit amount in the
second case defined above.
Any contract that matches this key while it is held on file will cause a
“possible duplicate” override, and will be added to the TRANS.REF Field.
The record will be deleted from the EB.DUPLICATE file in accordance with
the number of days defined in the PURGE.DAYS Field on the
EB.DUPLICATE.TYPE file.

The FT.APPL.DEFAULT table contains application level default values, which
will be used when processing FUNDS.TRANSFER or STANDING.ORDER
instructions. These defaults will be applicable irrespective of the transaction
type, and the user must create one record for each COMPANY on the system.
Limit Amounts in local currency can be specified in AUTO.PROCESS.LIMIT
Field such that incoming transactions are automatically processed into
authorised or unauthorised status depending on the transaction amount.
For incoming transactions received direct from delivery, transaction amount is
compared with the amount set here and processed as under.
If transaction amount is less than limit amount, then it will be processed but if
it is greater than limit amount, the transaction will be placed on hold. For
foreign currency transactions, the local currency equivalent is compared with
the limit amount and processed accordingly.

Certain outgoing payments can be made by deducting charges from the
payment or credit amount of transaction. This could result in charges
exceeding the credit entry or a disproportionate amount of credit entry. For
highlighting such transactions, it is possible to set an amount in
FT.APPL.DEFAULT using LESS.CHARGES.LIMIT Field for raising
override message at the transaction. Amount should be specified in local
currency.
This is not applicable for inward transactions.

CLAIM.CHARGES.ACCT is the account to be debited when charges are to be
claimed from the ordering bank. Only internal accounts category is allowed. In
FT, the local currency account of this category needs to be specified. System
disallows customer/foreign currency accounts for this purpose. When this
account is mentioned in FT for charge account number, then a claim charges
advice is automatically sent to ordering bank.
A Bank may be required to send a direct telex advice to the Beneficiary when
one of the Customers requests the Bank to make an Outward Payment under
direct telex advice to the Beneficiary. When the receiver of the message is not
existing in the CUSTOMER file, the User may directly input the Name and
Address details of the intended receiver of the message in
FREE.TEXT.MSGTO Field and input the non tested message in MESSAGE
Field in FT. To collect charges in such cases SECONDARY.TLX.CHG Field
is to be defined with a valid code pre defined in FT.CHARGE.TYPE
For any free format telex, the FUNDS.TRANSFER Application will
automatically apply the default Secondary Telex Charge Code, from the
SECONDARY.TLX.CHG Field defined in FT.APPL.DEFAULT. This charge
is taken in addition to those specifically entered, or defaulted, within Funds
Transfer main processing.

In case of outward transfer default charges for Correspondent, either
Receiving Bank or Credit Customer, can be setup in
CORR.BANK.CHARGES application whose Id is Customer No-
FT.TXN.TYPE.CONDITION or Customer No. To enable this defaulting
applicable for MT103 messages in FT, DEF.CORR.BANK.CHGS Field in
FT.APPL.DEFAULT application should be set as YES.
Based on the setup, Correspondent Charges are defaulted as follows
At the FT level, if BEN.OUR.CHARGES Field is set as "OUR" meaning all
transaction charges are for ordering customer, then based on the charges
defined in CORR.BANK.CHARGES application, system defaults charge
details along with CHARGE.FOR as "RECEIVER" and these details are
mapped to Tag 71g of Outward MT103 Message. The amount to be remitted
(tag 32) is arrived by adding the Credit Amount plus Receiver Charges.
While processing Inward MT103 message, if charge to be taken by the
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 of Charges (Ben/Our/Sha)

In some countries, certain currencies require exchange rates to be fixed by
Central bank and it may take some time to load the day’s rates.
This could mean when the transaction is entered into the System, relevant
exchange rate may not yet be available. Value defined in
NO.RATE.DELIVERY Field in FT.APPL.DEFAULT application will indicate
the Delivery of the actual Payment message, resulting from these transactions,
can take place before the final exchange rate is known.
If ‘Y’ is indicated in this field, delivery of actual payment message will take
place even before the fixed rates are actually loaded in the CURRENCY table.
This will be applicable only when in FUNDS.TRANSFER,
COMMISSION.CODE / CHARGE.CODE Fields are indicated as “Debit Plus”
or “Waive”, by which the Credit amount is not going to be affected by Charges
and Commission, which could change due to a different exchange rate.
If N, then payment advice will not be delivered till rates are fixed and loaded
into CURRENCY table.

FT makes use of a Treasury Rate each time a transaction involves a
conversion of currencies. The Final exchange rate quoted to Customers
(CUSTOMER.RATE) will be determined by the addition or subtraction of the
appropriate Customer Spread to/from the Treasury Buy/Sell Rate.
When ever a conversion take place an element of exchange profit or loss can
arise on account of such conversion. Defining a method for local equivalent
calculation and deriving marketing exchange profit is done in
MKT.EXCH.METHOD Field.
The option of STANDARD, the default method, will cause marketing
exchange profit to be calculated as the difference in local equivalent due to the
difference between the CUSTOMER.RATE and the TREASURY.RATE.
The option of MIDDLE causes marketing exchange profit (or loss) to be
booked as the difference between credit and debit amount local equivalents,
where the local equivalent of the debit and credit side is calculated
independently according to the CURRENCY.MKT.CR or
CURRENCY.MKT.DR. The amount for transfer is calculated at the entered
rate, which can be defaulted according to the DEAL.MARKET.
The marketing exchange profit or loss is booked to a P&L category defined in
the ACCOUNT.CLASS record FTMKTEXCHCR, FTMKTEXCHDR.

RATE.FIXING is for the purpose of fixing rates functionality. Defaults the
functionality in FT where YES can be changed to No but not vice versa.
When RATE.FIXING is set as "YES" in FT.APPL.DEFAULT, then for FT's
which are in INORATE/ANORATE status, position entries are created with the
DEALER.DESK as given in FT.APPL.DEFAULT, instead of DEALER.DESK
given in FT application. This enables to group positions of FT's for which the
Exchange rate not fixed on a single DEALER.DESK. Once the rates are
available for the day, FT.RATES is run online, and the old position entries are
reversed and new position entries with current exchange rate and
DEALER.DESK as given in FT gets created. If RATE.FIXING is given as
Null then it will be always using the FT's Dealer Desk for position entries.
In the Fund Transfer , when debit and credit currency are different, treasury
rate or default buy/sell rate is used for conversion of amounts for which a
rounding rule can be applied, the default in T24 is natural. However, the field
ROUND.TYPE in FT.APPL.DEFAULT can be used to setup new rounding
rules. The rounding rule will first need to be set up in the application
EB.ROUNDING.RULE and is then input into ROUND.TYPE.

MIN.STO.CCY and MIN.STO.AMT Fields which define the Minimum
Amount for a Currency required for processing a balance maintenance
Standing Order. If balance amount falls below the amount specified here, then
balance maintenance instructions will not be processed.
Example: A Customer requests the balance of his Current Account to be
maintained at GBP 100.00 to the DR/CR of his Savings Account. Where the
MIN.STO.AMT equals GBP 5.00, No balance maintenance transfer will take
place when the balance is between GBP 95.01 and GBP 104.99.
Local currency MIN.STO.AMT should be set before creating details for any
foreign currency. Where the Minimum Standing Order Amount does not exist
in the Currency of the Account where the Standing Order applies, the System
will take the equivalent of the local Currency amount.
If the standing order is to be executed after deduction of tax, then the same
has to be mentioned in a field called STO.TAX.SEQ.NO and
STO.TAX.PERCENT where the former defines the Tax Sequence Number
applicable to Standing Orders and latter Tax Percentage, This will be used
where some Standing Orders receive a beneficial tax treatment.
For example : Standing Order Amount equal to GBP 10.00 is defined and the
tax benefit indicated using these two fields is equal to 30%, the amount of
GBP 7.00 will be transferred to the charity organisation which in turn can

claim the difference GBP 3.00 from local authorities.

If a Standing Order fails due to insufficient funds, the associated
FUNDS.TRANSFER record generated is placed on hold status pending
manual intervention. Standing Orders can be set for automatic resubmission.
Two methods exist to retry either for specified days up to maximum of 10 days
within the Close of Business batch processing or online at set time intervals
during the day. These methods can be combined to create a continuous retry
process that runs all day every day until funds become available or until the
specified number of days is reached.
Daily resubmission is enabled in FT.APPL.DEFAULT, entering a value for the
number of days in NO.RESUBMSSN.DAYS. User can also specify
RETRY.START.TIME and RETRY.END.TIME in a 24-hour clock notation,
within the FT.APPL.DEFAULT record, for enabling online resubmission.
When the retry limit is reached without sufficient funds, the funds transfer
record is created in hold as before, and T24 can generate a delivery advice
message to this effect. The message to be used is specified in
FT.APPL.DEFAULT field SO.MESSAGE.TYPE and suitably defined in
DE.FORMAT.PRINT.
When USE.STO.ACCT.OFF Field is specified as Y, then the ACCT.OFFICER
used in the STANDING ORDER record should be defaulted into the
PROFIT.CENTRE.DEPT Field of FUNDS.TRANSFER when processing
standing orders.

When the Bank wants to make payment only after receiving the Cover
message, AWAIT.COVER Field can be set.
When a Swift Payment message is received during inward processing, if the
AWAIT. COVER is set to "YES" then FUNDS. TRANSFER contract will be
put on hold. Bank can verify whether cover instruction is received then process
the contract manually.
When the AWAIT.COVER Field is set as “LIM”, Correspondent limit
checking is done.
When AWAIT. COVER is set as NULL, then FUNDS. TRANSFER contract
will not put the record on Hold because of above reason.
Above functionality is applicable only for inward swift messages which are
processed through OFS.GLOBUS.MANAGER when Incoming swift message
type MT103 has Tag 54.

The EC Regulation on cross-border payments imposes on banks the
elimination of the price difference between the cross-border and domestic
transactions. Therefore, the European banking community has agreed on the
conditions to consider a payment as Straight Through Process able (STP).
In practical terms, the account number line of Field 59a (Beneficiary
Customer) of any European MT 103+ or MT 102+ must contain an IBAN. An
MT103+/MT102+ is considered as European whenever the Sender, the
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. Countries concerned are Andorra, Austria, Belgium, Bouvet Island,
Switzerland, Germany, Denmark, Spain, Finland, France, United Kingdom,
French Guiana, Gibraltar, Guadeloupe, Greece, Ireland, Iceland, Italy,
Liechtenstein, Luxembourg, Monaco, Martinique, The Netherlands, Norway,
Saint Pierre and Miquelon, Portugal, Reunion, Sweden, Svalbard, Jan Mayen
Islands, San Marino, French Southern Territories and Vatican City State.

MT103+ can be generated to make it straight through processable with bank
field tags as "xxA". MT103+ - with Bank field tags (52,54,55,56,57) as “xxA”
along with BEN.ACCT.NO for straight through processing.
MT103 EXTEND- with Tag 77T Envelope contents.
In case MT103.TYPE is MT103Extend then EXTEND.INFO in FT is
mandatory and details entered in EXTEND.INFO along with the
EXTEND.FORMAT is mapped to tag 77T of MT103. In MT103 outgoing
SWIFT message user header block 3 for field 119 validation flag will be
having “REMIT”.
In case MT103+ is given then ACCT.WITH.BANK, RECEIVER.BANK,
REC.CORR.BANK, INTERMED.BANK Fields should have either a
customer who has a record in DE.ADDRESS for carrier as “SWIFT.1” or a
valid BIC code prefixed with “SW-“ along with BEN.ACCT.NO.
In FT.APPL.DEFAULT Field MT103.CONTROL, is set to SYSTEM, then
system raises an ERROR message if above condition is not met. If the above
condition is met, then an override is raised and MT103 is generated instead of
MT103+.
The generated MT103+ will be populated with “STP” in user header block 3
for field 119 validation flag.
In other cases a plain MT103 is generated.

Incase MT103.CONTROL is null then system raises an override and generates
MT103 instead of MT103+ , in the absence of essential details. This will not
go through Straight through processing.
From R14,
In MT103+ whenever the Sender & Receiver Bank and (or) Account with
Bank country code is either ‘IL’ or belongs to the European union list of
Countries (maintained in a separate table) IBAN validations are made
mandatory. This is achieved through field 59A Beneficiary Customer, Subfield
Account in MT103+ namely, MT103.CONTROL
Decides if system raises an error or an override while checking if the

IBAN.BEN field is mandatory.
•If set to 'SYSTEM' an error is displayed.
•If set to 'NULL' an override advising MT103 is displayed.
Or it will amend the message type to MT103, and produce an override.

From R14, Whenever the Country code of the Sender and Receiver BIC
belong either to the EU list of Countries Or is ‘IL’
Or if optionally the Account with Institution is defined and if it belongs to EU
list of Countries Or is ‘IL’
Then the Beneficiary Account number (Tag 59A) should be a valid IBAN
henceforth and system will validate this in order to produce a valid MT103+
message with code STP in the user header of the message.
In other cases the presence of IBAN in Tag 59A is optional.

Based on MT103 control field setup as system or null we get error or override
as seen above.

For reversal of history records separate transaction codes can be used if
HIS.REV.TXN.CODE Field is set with a value, else original transaction code
continues to be used.
When an error is encountered in funds transfer transaction, the charges and
commission details entered or defaulted by the system are cleared from the
respective fields. To retain those charges or commission it has to be defined in
CHG.COM.ON.ERR Field as retain.
For example, in an "OT03“ transaction type of input in FT, where Beneficiary
is mandatory and user has omitted to input the beneficiary details, then system
will prompt an error and clear off the details which is already there in
Commission/Charge related fields.
In order to retain details of charges and commissions, CHG.COM.ON.ERR
Field needs to set as "RETAIN“. System will not recalculate the commission
or charges even when there is a change in the transaction amount or customer
and the values will be retained .
If set as Null then defaulted charges/commission will be cleared when an error
is encountered in a FT.

We have seen so far that, via FT.TXN.TYPE.CONDITION, T24 can default
charges directly on to a Funds Transfer transaction. Defaulted charge is not,
however, based upon the Customer but on the transaction type. This structure
is ideal for the use of standard tariffs, but in a bank many customers are given
benefit with preferential form of tariff.
T24 allows us to create groups of customers for whom we can consider
defaulting non-standard tariffs.
CONDITION.PRIORITY file is set during implementation and determines
what T24 will look at to assign a customer to a particular condition group. The
determinants are chosen based on FT business needs of the bank.
For this purpose, the Id will be FUNDS.TRANSFER and choice of criteria or
conditions is any field in the CUSTOMER application. The order of priority of
the criteria needs to be specified and will decide the grouping of a Customer
into a group of best fit, when more than one condition are satisfied.
For example, residence could be first priority, sector next and then industry. If
a customer satisfies a group condition for residence and also another group
condition for sector, then the best fit group will be based on residence as it is
of higher priority.

FT.GEN.CONDITION assigns a condition group code and attributes based on
the selection criteria laid down in CONDITION.PRIORITY.
The Id of the general condition records will be numeric from 1 to 9999 and
meaningful descriptions will be specified for each condition.
To create a Group Condition, user must identify the Group by means of the
General Condition number defined in this table. Customers will then be
assigned to an group by means of the details held within this table.
System identifies the best fit based on the field selections and the priority of
fields defined.
When a Customer is authorised, customer’s group is recorded in
CUSTOMER.CHARGE file. However, it is possible to change the default
grouping of the customer in this file.
Amending a Customer record may therefore result in reclassification of the
Customer into another Group or even restore to the 'normal conditions'.
Amendments to this tables takes effect only after COB is run.

FT. GROUP. CONDITION defines special conditions applicable to specific
Groups of Customers or individual customer.
FT.GROUP.CONDITION is used to define the preferential tariffs for that
group of customers. Id is the same as Id of the FT.GEN.CONDITION group.
When the number is entered, T24 will pick up the name of the group from
general condition file.
It is possible to lay down conditions for a particular customer. In such case, the
ID of the customer must be preceded by 'C-' (e.g. C-100010). This will
automatically get defaulted to CUSTOMER.CHARGE
The various options which can be used in COMM.TYPE Field for defining the
rates are either the respective Charge or Commission could be indicated by
their Ids in FT.COMMISSION.TYPE in the associated multi value fields or
transaction types from FT.TXN.TYPE.CONDITION or if the concession is
applicable for all Charges and Commissions, “ALL” could be indicated . Any
percentage mentioned in COMM.PERCENT could be collected for each
group. Alternatively, specific types of Commission / Charges could have a flat
amount in a designated currency as in COMM.CCY and COMM.F.AMT.

In some banks there is a tendency to show charges and commission separately
in statement entries. To show those charges as separate in
FT.GROUP.CONDITION there is a CHG.COMM.SEPARATE. Field. If this is
set to Yes then charges and commission will be shown separately from transfer
amount in the Account statement to the Customer.
RATE.SPREAD Where a customer or group of customers are given
preferential exchange rates this field is used to define what percentage of the
standard Customer Spread (as defined in the Currency table) should be
applied. If left blank the Rate Spread will be the same as for a standard
customer (as if 100% was entered).
PAYMENT.TYPE Used with the field Customer float, to give different Value
Date conditions . ALL means that the condition specified in Customer Float is
applicable to all transactions irrespective of the fact that these transactions
involve conversion of Currencies. CONV for transactions involving
conversion of Currencies. NOCONV means for transactions not involving
conversion of Currencies.
CUSTOMER.FLOAT Indicates the number of days after which the value date
will be given. If '0' is input, the Group of Customers will receive SAME day
value as the bank itself.

It is possible to mention overall maximum/overall minimum commission or
charges to be charged for specific customer or for a group of customers. To
achieve this functionality, the following fields should have values,
COMM.TYPE should indicate a record Id from FT.COMMISSION.TYPE or
FT. CHARGE.TYPE. Apart from that the user should also input values in
COMM.MAXIMUM, COMM.MINIMUM or CHG.MAXIMUM and
CHG.MINIMUM. This will have a precedence over the overall
minimum/maximum amounts defined in FT. COMMISSION.TYPE or
FT.CHARGE.TYPE. User can also specify a discount amount or a premium
amount entered in the field COMM.PREMIUM or COMM.DISCOUN. It is
possible to enter any one of them and not both. If it is a discount then the
discount amount will be deducted from the commission maximum and will be
applied. Like wise if it is a premium then the premium amount will be added
to the commission minimum and applied . When this field like
COMM.PREMIUM or COMM.DISCOUN is entered then the existing fields
COMM.PERCENT & COMM.F.AMT should be a no input field. For example
In FT.COMMISSION.TYPE for a particular commission if you have indicated
a banded type of calculation as 2% up to 20000 and 5% beyond 20000. In FT.
GROUP.CONDITION for a particular customer it has been mentioned Comm
max as 250 Comm min as 50 Comm discount as 25 and if an FT for USD
11000 is put through for that customer, system will calculate 2% of 11000
which works out to 220 and deduct the comm discount of USD 25 and apply

USD 195 as commission for that customer.

FT.GROUP.CONDITION table defines special conditions applicable to
specific groups of customers or individual customers. Any customer will be
classified into one of groups defined or could have a specific condition as an
individual.
As and when a customer record is created, system automatically creates a
record in CUSTOMER.CHARGE with the same Id as the customer record.
Application wise group conditions applicable to the customer are updated in
the field ACTUAL.GROUP. It is possible to change Group Id so that new
group rules are applicable to the Customer. Changes in the values of the
Customer record could affect the grouping condition such that the customer
now gets classified into a different group. This will be updated by System
automatically during COB to change the group of a customer.
When customer specific grouping record is defined in
FT.GROUP.CONDITION using Customer Id prefixed with C-, then
ACTUAL.GROUP in CUSTOMER.CHARGE of the customer will hold the
value as C-<Customer.Id> instead of the group Id.

This slide shows the links between the various files making up the Condition
Group structure for FT charges and commissions.
The concessional charges and commissions go with CHARGED.CUSTOMER
Field. For the Customer Id appearing in these fields, if any concessional rates
have been stipulated in FT.GROUP.CONDITION, then that is applied to the
respective FT.

To default charges applicable for the Receiver (Outward) and Sender (Inward)
in the case of MT103 message, charge details can be specified at
CORR.BANK.CHARGES. To enable collection of charges based on the
Correspondent involved ie Customer No of Credit Customer if Receiver Bank
not specified, or Receiver Bank if it exists for Outward, or Sender for Inward
messages, FT.APPL.DEFAULT should be defined with
DEF.CORR.BANK.CHGS as YES. Then in application
CORR.BANK.CHARGES should be defined for the Correspondent Bank or
Customer.
ID is Customer No-FT.TXN.TYPE.CONDITION OR Customer No.
In case ID is created as Customer No-FT.TXN.TYPE.CONDITION then
charges defined here 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 and irrespective of transaction type
used in FT.
In this application, Charges can be defined for the Correspondent Customer for
each Currency. At least one Commission or Charges details for a currency
should be specified.

Based on the above setup, Correspondent Charges are defaulted in FT as
follows
Outward MT103
At the FUNDS.TRANSFER Application level, if BEN.OUR.CHARGES is
given as "OUR" then system will 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)
Inward MT103
If the 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 or Our or Sha in
BEN.OUR.CHARGES .
If charges are not setup for Correspondent bank, then default conditions of
FT.TXN.TYPE.CONDITION will apply.

This slide shows the links between the various files making up the Charge
structure for Correspondent based charges and commissions.To default
Correspondent Bank charges in FUNDS.TRANSFER application while
processing Outward / Inward MT103 message, DEF.CORR.BANK.CHGS
Field has to be set as "YES" and charges has to be specified in
CORR.BANK.CHARGES application, which can be attached to FT. Where
ever the CORR.BANK.CHARGEs is not defined , system will refer to the
default charges set up in FT.TXN.TYPE.CONDITION

Presently, when funds transfers have to be made to a particular beneficiary at
regular intervals, all the details of the beneficiary have to be given by the user
every time a transfer is made. In order to overcome this and store details of
frequently used beneficiaries, BENEFICIARY table can be use. This allows to
input all the required details of the beneficiary. This can then be linked to AC
and OT types of Funds Transfer and Standing order applications which would
enable all the details input in this table to be suitably defaulted. Furthermore,
the user need not remember the details of frequently used beneficiaries like the
beneficiary’s account number, beneficiary’s bank, BIC, etc. while transferring
funds. Example of this scenario are where a client pays his telephone bills
frequently to the same beneficiary or payment of electricity charges etc.
For AC types of funds transfers, Account number, Reference, if any and
Narratives will be defaulted.
For OT types of funds transfers, Account number, Customer number, Bank sort
code and Account with bank details will be defaulted.

The order in which Primary build files should be created is stored within the
automated tool for IM. For easy reference, the order sequence in ascending
build reference order is given in the left.
The mandatory fields are shown with a RED STAR mark and optional fields
are shown with out a red star.
Wherever there are dependencies for filling up values in the tables in build
sequence, the dependencies are shown on the right.

moving funds internally and externally.
Internally, payments can be made to or from a Customer’s account or an
internal account. It could involve transferring money from one customer
account to another customer account.
Some of the external types of payment include Cheques, Mail Payment,
Banker’s Draft, Clearing House Payments, international payments via
Correspondents etc.
Transfer instructions can be entered manually or fed from other electronic
communications systems like Telex or Swift. It is linked to all types of outputs
whether paper or wire through the Delivery setup in T24.
The application is designed to handle all types of currencies, local or foreign
and inward or outward payments.
On a real time basis, the application updates the core limit setup , Positions
and balances whenever an account is debited or credited.
Commissions can be made to default for a variety of Funds transfer
transaction based on conditions pre defined or input manually.
Standing order payments can be setup and effected as batch process during
COB.

ID format will be FTYYDDDNNNNN where NNNNN is the sequence number
assigned for various types of Funds transfer. Different ranges of the sequence
number can be assigned to different types of processing.
To avoid the necessity to input the complete Reference Number, User has the
facility to input only the sequence number of the transaction to access any
transaction which has been input that day. Application will automatically
generate the seven first digits and append them to the front of the sequence
number in order to retrieve the requested transaction.
Access to any Funds Transfer transaction from a previous day requires the
input of the day number and sequence number, the system will automatically
generate the first 4 characters, assuming that the current year is applicable.
ID will be shown on all output generated from the transaction.
The Reference Number will be generated automatically when specified as such
in the COMPANY table for the FUNDS.TRANSFER Application.
If the Funds Transfer operation requires more transactions , the sequence
number can be set to be have alphanumeric characters when UNIQUE.NO
Field in AUTO.ID.START to be set as YES. In this case Id format will now be
FTYYDDDAAAAA where AAAAA represents alphanumeric characters. To
handle large volumes of FT, it is possible to include Alpha characters at the
end of this number by suitably opting in AUTO.ID.START application.

For each type of transaction, there must be a valid record available in
FT.TXN.TYPE.CONDITION, which defines the default conditions for each
transaction type that can be processed by the FUNDS.TRANSFER and
STANDING.ORDER applications.
For Account to account transfer the mandatory fields required to input a
transaction are DEBIT.ACCOUNT, CREDIT.ACCOUNT, DEBIT. AMOUNT
and DEBIT.CURRENCY or CREDIT.AMOUNT and CREDIT.CURRENCY.
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 or Internal Account and a PL
Category.
For example : Transfer of funds between 2 customer accounts.
Outward cheque payment by debit to Customer and credit to Internal account.
Payment transferred out by means of banker’s cheque involves internal
account.
Salary credited to staff account will involve customer account and PL account
on other side.
When internal or PL account is debited, ORDERING.CUST or
ORDERING.BANK Fields is mandatory.

When transfer between accounts are input through a funds transfer, there could
be instances when credit and debit currencies are different. In such cases,
system uses exchange rate of buy or sell for appropriate currency market
defined in CURRENCY table. This is defaulted into the TREASURY.RATE
based on the amount of transaction. To this rate the Customer spread is added.
CUSTOMER.SPREAD defines the customer specific exchange spread
applicable for such transactions . When preferential conditions are setup in the
parameter file, namely FT.GROUP.CONDITION for the specific Customer or
for the group to which the customer belongs ( debit account customer) then
system will apply such conditions and default the rate. If an additional spread
is applicable for a customer specific to this transaction then user can input the
same.
CUSTOMER.RATE identifies the final rate for the transaction. Generally it is
obtained by adding customer spread to the treasury rate.
In case Treasury Rate and Customer spread is null, then user can input
exchange rate in Customer Rate.
In such cases, the Customer spread will be calculated and defaulted with the
difference between Treasury rate and Customer Rate.

In Funds Transfer application , it is possible to preview the delivery message
of outward remittance like MT 103, MT 200,MT 202, 210 etc. This preview of
delivery message is not available for Standing order, FT.BULK.CREDIT. Once
the transaction is validated by the user, and by clicking on the camera near
more action button, user can have a look of preview of delivery message.
When a message is previewed, the MSG.DATE Field will become inputtable
field, so that the user can give their message send date. The message date
cannot be less than today or not greater than maximum of credit, debit or
processing date. If the message date is blank, then it will be defaulted to
processing date.
When the message date is forward, the delivery message will not be generated
on authorizing the record. The information will be updated in the message
date. During COB of the scheduled date, it will generate the delivery message.

For all types of outward remittances like OT or OT03, beneficiary customer
name or beneficiary bank name is mandatory. Purpose of this field is to
indicate ultimate receiver of funds. When the bank has to pay funds to a client
using only an account number, then BEN.ACCT.ONLY Field in
FT.TXN.TYPE.CONDITION should be set to Yes. Now the transaction will
allow the input of just the beneficiary account number in BEN.ACCT.NO
Field of the transaction. As this is not standard banking practice the default
will be the beneficiary name with an optional account number.
The value in BEN.CUSTOMER is mapped to Tag 59 in Swift message, while
BEN.BANK is mapped to Tag 58 in Swift message MT202. Input into this
field should conform to the setup in ACCOUNT.CLASS for the record Bank.
The Beneficiary customer can be input using valid Customer Id/Mnemonic or
Free text. When free text is used, T24 searches for an existing Customer record
using the text as Mnemonic. If such Mnemonic is not found, it retains the free
text. If such Mnemonic is there, it changes the value to Customer Id.
If credit account is not input, then system will use defaulting rules such that for
a FCY, it uses the NOSTRO.ACCOUNT for the corresponding currency and
Vostro account for the AGENCY in respect of local currency.

For transfer between Nostro accounts through a funds transfer it is possible to
generate either MT200 or MT202 depending on the setup in
FT.TXN.TYPE.CONDITION.
When the transfer is between own accounts of the bank using two Nostro
accounts, then MT 200 can be sent by setting NOSTRO.XFER.TYPE Field in
FT. TXN.TYPE.CONDITION with “200” or “null”. Since both debit and
credit accounts are Nostro, BEN.CUSTOMER and BEN.BANK cannot be
input in the transaction.
For some OT type transactions it is possible to generate MT 202 payment
messages for transfers between Nostro Accounts by entering the value of 202
in NOSTRO.XFER.TYPE Field in FT.TXN.TYPE.CONDITION. In this case
it will be necessary to input Beneficiary and Ordering particulars for the
transaction in Funds Transfer.

BK.TO.BK.INFO Field corresponds to Tag 72 to provide instructions or
additional information for receiver, intermediary account with institution, or
beneficiary institution. Information already input in another field need not be
given again.
Information should be input beginning with an appropriate codes available in
SWIFT.CODE.WORDS. These should be enclosed between slashes. When
details overflow to multiple lines, then BK.TO.BK.INFO Field in the
transaction should be expanded and every additional line should be prefixed
with “//”.
For Outward Payments, these details will be relayed to the Receiver Bank.
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.

When FT is authorised, based on FT.TXN.TYPE.CONDITION and details are
given in the FT, appropriate Swift messages or advices will be sent to Credit
Customer, Debit Customer, Collection Remitting Bank and Receiver Bank.
Bank to bank information which is mapped to Tag 72, could have different
details depending on the party to whom it is sent. Hence, associated pair of
fields namely SEND.TO.PARTY and BK.TO.BK.OUT can be used to indicate
different parties and their related message details. SEND.TO.PARTY can be
defined with the values namely CRCUST,DRCUST,COLL.REM.BK or
RCVBK to indicate whether the party is credit customer, debit customer,
collection remitting Bank or Receiver Bank. Mention the appropriate Bank to
Bank Information for the concerned party in the field BK.TO.BK.OUT and
same will be used in all swift messages in Tag 72 which are sent to that Party.
When details are specified here, then it cannot be mentioned in
BK.TO.BK.INFO. Information for Tag 72 can be specified in either
BK.TO.BK.INFO or in associated multi value fields BK.TO.BK.OUT.

Transfer between Nostro accounts are handled as Financial institution transfer
between own accounts. SWIFT message that is generated on account of
transfer between own accounts can be MT 200. If one of the Nostro is having a
surplus funds it can be transferred to another Nostro account, where there is a
shortfall.
For example Citi Bank New York is maintaining GBP account with
American Express Bank London and also with Allied Irish Bank London. If
there is a shortfall of funds in American Express Bank London, then Citi Bank
New York can effect a funds transfer from Allied Irish Bank to American
Express bank London. Such type of transfer of funds from one Nostro account
to another Nostro account are handled in Funds transfer under MT 200. It is
also possible to transfer funds from Nostro account in one currency to another
Nostro account in different currency. For example, transfer of funds from GBP
Nostro account with Barclays Bank to USD Nostro account with Bank of New
York.

For transferring funds between two Nostro accounts, MT200 type of message
are used. Some of the mandatory fields are
DEBIT. ACCOUNT, which indicates the Nostro account to be debited or the
account to which funds are transferred, CREDIT.ACCOUNT refers to the
Nostro account to be credited or the account from where funds are transferred.
Debit Nostro will be the account which will receive funds from the credit
Nostro account. This is because entries in Nostro accounts maintained at
Bank’s end are mirror of the actual entries at the other end.
For Outward Payment Orders, CREDIT.CURRENCY will usually represent
the Currency of the Nostro account to be credited. For Inward Payment Orders,
this field will usually represent the Currency of the Customer account to be
credited.
For Outward Payments, CREDIT.AMOUNT will represent the natural transfer
amount while for Inward Payments it is DEBIT.AMOUNT which will
represent the natural transfer amount. This field could, however, be used for
inward transfers when our correspondent requests us to pay a specific
Currency and Amount to one of our Customers and to debit another account
for the equivalent of the charges. CREDIT.VALUE.DATE Identifies the date
when the Credit entry is to be given value for interest purposes.
When the Value Date is not input, it will be defaulted from Customer specific

Value Date conditions or group specific conditions, and if not, it will apply the
Transaction Type default Value Date conditions.

Retail home page has custom set of menus/enquiries required by a Retail user
to carry on the day to day operations. Home Page will help the User to process
Remittance transaction , view the customer details, input transactions and
view/create opportunities for the customer. The Home Page is designed to
assist the Payment Supervisor in authorising transactions, to view enquiries
and delivery messages.
Menus available for Funds Transfer, Standing Orders, Direct Debits and bulk
Standing Orders.
Components of Remittances Home Page is available in the form of tabs, for
easy navigation.
Functionality is provided with essential CRM features for the front end.

When ever a funds transfer is effected, Charges could be effected from
different accounts namely, on ordering customer or on beneficiary or shared
mutually by the beneficiary and ordering customer. This has to be defined in
BEN.OUR.CHARGES Field which corresponds to SWIFT Tag no 71A in
Message type 103.
SHA means Transaction charges on Sender's side to be borne by ordering
customer, and Receiver's side charges by beneficiary.
OUR means all charges to be borne by ordering customer.
BEN means all charges to be borne by the beneficiary.
COMMISSION.FOR and CHARGES.FOR Fields used to specify whether the
corresponding commission amount entered is due to the sending bank or the
receiving bank. If the transaction type is OT and the system has been set to
produce SWIFT message MT103 Single Customer Credit Transfer and if the
field is set as Sender then the corresponding charge amount entered is due to
the sending bank. If mentioned as Receiver the corresponding charge amount
entered is due to the receiving bank. For transaction type OT with a message
type of MT103 the default is Sender.

COMMISSION.CODE identifies how Commission is to be applied. Valid
options are DEBIT PLUS CHARGES, CREDIT LESS CHARGES and
WAIVE.
Debit plus Charges value indicates that, for outgoing payments, the complete
transfer amount will be remitted to the receiving bank and Ordering
customer’s account will be debited with the charges amount.
For incoming payments, the complete transfer amount will be credited to our
beneficiary Customer and the commission amount will be debited to the
Account defaulted or as specified in Charges Account Number. The charges
account number will be the debit account if the same is not a Nostro. In the
case of debit account being a Nostro, then the default of the charge will be to
CLAIM.CHARGES.ACCT as defined in FT.APPL.DEFAULT and a claim is
also sent to the Ordering Bank.

Credit less Charges value will indicate that, for outgoing payments, the amount
of commission will be deducted from the Transfer Amount which is remitted
to the receiver bank.
For Incoming payments, the amount of commission will be deducted from the
received amount (Transfer 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 or commission account of the Customer.

Waive option refers to waive Commission and no commission is to be applied
on this transaction. Any input in Commission Type and Commission Amount
will consequently be refused.
For Standing Order transfers and any transfers with Nostro for both Debit and
Credit Accounts, the default value generated is W (Waive Commission)
When MT103 is set to be produced, then COMMISSION.CODE gets value
based on the input in BEN.OUR.CHARGES. If BEN.OUR.CHARGES is
Ben, then all charges are for the beneficiary and hence COMMISSION.CODE
will be Credit less charges. If value is OUR, then all charges are for the
ordering customer and hence commission will be debit plus charges and if
shared, then commission will be debit plus charges pertaining to the ordering
customer only.

COMMISSION.TYPE or CHARGE.TYPE are Fields which get default values
from FT.TXN.TYPE.CONDITION or CORR.BANK.CHARGES depending
on the pre defined setup available in FT.GROUP.CONDITION for specific
customer or for the group to which the customer belongs , if any. Based on
this, system calculates the amount based on conditions defined therein or
alternatively user can indicate amount specific for the transaction.
Charges are collected from the defaulted account number in
CHARGES.ACCT.NO Field which will be defaulted from
CUSTOMER.CHARGE, Credit or Debit account or internal account specified
in FT.APPL.DEFAULT for incoming transfer.
Instead of raising a net transfer entry, if a separate entry for the
commission/charges is required then it is defined in the relevant Group
Condition. In such case, separate entries will be generated for this transaction
in the Debit Account Number for outgoing payments and in the Credit Account
Number for incoming payments.
If charges and commissions are to be displayed after validation,
CHARGE.COM.DISPLAY Field needs to be set as Y. Default value is N, when
it is not displayed after validation.

Transferring money can be done electronically. Transferring money from one
country to another country can also be done through Swift messages.
For example, Dell can approach his Banker, namely T24 Bank with an
instruction to transfer money electronically to Bishop, through Bank’s Nostro
account.
In this case, T24 Bank will send a message to Nostro Bank, advising them to
credit the Beneficiary. Such transfers involving single customer credit can be
done through MT103, sent to the Nostro bank.
Note that in this case no drafts or cheques are to be issued by T24 Bank, nor
should Bishop call on the bank for his account credit.

Transferring money can be done electronically and advised to various parties
through Swift messages using the cover method of payment.
Dell can request T24 Bank to transfer GBP10,000 electronically to Bishop.
Let us take the GBP nostro account of Dell’s banker (T24) as Barclay’s bank,
London. Bishop, the beneficiary may not maintain his account with Barclay’s
Bank, London. In such a situation, if Bishop’s banker namely Citibank has an
account with Barclay’s bank, London, then payment moves from Dell to
Bishop passing through Barclay’s Bank and Citibank. T24 will handle different
combination of swift messages for such a situation, namely MT103 to Citibank
and cover message MT202COV to Barclay’s bank.
Thus we have a client bank which is sending an outward remittances will send
a MT 103 message to the beneficiary bank, giving the full details of the
payment message, by indicating the ordering customer name, beneficiary’s
account number, bank name, payment details etc. Simultaneously it will send
a MT 202COV to its nostro bank as a cover payment message.

Cover Payment is issued when there is no Nostro / Vostro account relationship
with receiver of payment instructions.
In FUNDS.TRANSFER application, cover message can be issued only for
OT transaction types which have been defined to send message type of MT
103. There are four options to choose field COVER.METHOD to decide to
whom the payment instructions are sent. They are COVER- DIRECT where in
detailed payment instruction is sent directly to another Institution via an
MT103 and brief instructions are sent to our correspondent via an MT202 for
covering payment message, COVER-NEAR where payment message (MT103)
sent through several reimbursement institutions, using an account with
institution and brief instructions to our correspondent via an MT202, SERIAL
where payment message (MT103) is sent to the next party in the transaction
and THIRD-INST where payment message (MT103) sent to party closest to
the beneficiary, using a third reimbursement institution and instructions to our
Correspondent via MT202.

Based on the cover method and Customer Number given in Ben.Customer or
Ben.Bank, system will access AGENCY for customer and using the setup for
the Currency, values will be defaulted in bank fields as per following-
If COVER.METHOD is COVER-DIRECT then fields that will be defaulted
are RECEIVER.BANK, REC.CORR.BANK, INTERMED.BANK. Here a
Detailed payment instruction is sent directly to another institution via MT103
and brief instructions sent to our correspondent via MT202COV for covering
Payment Message.
When COVER.METHOD is COVER-NEAR, then fields that will be defaulted
in ACCT.WITH.BANK, RECEIVER.BANK, REC.CORR.BANK. Payment
message (MT103) sent through several reimbursement institutions and brief
instructions to our Correspondent via MT202COV.
For COVER.METHOD as SERIAL, then ACCT.WITH.BANK &
INTERMED.BANK will be defaulted. Payment message (MT103) is sent to
the next party in the transaction.
For COVER.METHOD as THIRD-INST Fields that will be defaulted are
RECEIVER.BANK, REC.CORR.BANK, INTERMED.BANK. Payment
Message (MT103) sent to party closest to the beneficiary, using a third
reimbursement institution and instructions to our Correspondent via
MT202COV.

Whenever a MT103 along with MT202/MT205 cover payment is sent, a bank
can specify the time detail in a field called TIME.IND which will be mapped
to tag 13C of MT103 ,202, 205 Swift messages. Depending on the value in
RELATED.MSG Field, value in TIME.IND will appear in MT103/MT202.
When the field is mentioned as COVER, then time appears in MT103, while
mention of PAYMENT will ensure that time appears in MT202.
Time indication in Tag 13C has 3 components ie. Swift code, time indication
and time offset with Central European Time .
Swift Code and time indication has to be specified here in the transaction.
Swift code is validated with SWIFT.CODE.WORDS and is given between two
“/” and Time indication given should be a valid HHMM format and HH should
be between 00 to 23 and MM should be between 00 to 59.
Time offset will get defaulted from CET.TIME.DIFF Field in DE.PARM. If
no value is given in DE.PARM, then defaulted to +0000
For example : In DE.PARM application, if CET.TIME.DIFF Field is set as
+1000 and in FT, for TIME.IND Field value is given as /CLSTIME/1220,
then 13C tag of swift message will be /CLSTIME/1220+1000
Duplicate SWIFT.CODE.WORDS not allowed for a same RELATED.MSG.

In respect of all cover payment SWIFT allows certain message types to have
reference to times based on Central European Time (CET), this field identifies
the local time difference from the CET. It will be used in adding the CET time
offset, after the time in the SWIFT message. This will be possible if the
delivery format table of appropriate swift message in DE.FORMAT.SWIFT
has the time field defined with the conversion option TIME.CET .
The format for input is either HHMM or -HHMM. as a time offset, where HH
is the hours component in the range of 00 to 23 and MM is the minutes
component in the range of 00 to 59.
Input is made either as a positive or without sign value, for example, 1230
meaning 12 1/2 hours after CET. Or as a negative signed value, for example, -
1230 meaning 12 1/2 hours before CET.
If /SNDTIME/1220 is indicated in TIME.IND Field of FT, and if offset time is
set as +1230, then Tag 13C will show /SNDTIME/1220+1230 and if offset is
-1230, then tag 13C has /SNDTIME/1220-1230.
RELATED.MSG is a multi value field and can have both values namely
COVER and PAYMENT defined though generally a single value of either of
the values is used. If left blank, then no time is available in either of swift
messages.

As a general rule, in FT, a Cover Payment will be issued when no account
relationship (e.g. Nostro account, Vostro account) exists between the Sender
and the Receiver of the payment instructions. When INTERMED.BANK is
defined for payment through which funds pass through prior to the
Beneficiary, then this gets mapped to Tag 56 when cover is DIRECT and to
Tag 54 in MT103 when cover is THIRD-INST , while getting mapped to Tag
56 in MT202COV message.
Example:
Let us suppose that British Bank, London sends a direct Telex payment order
to Belgium Bank in Brussels (with whom they have test arrangements)
requesting them to pay Euro 1,000,000.00 to one of their Customers.
Because British Bank London does not maintain its Nostro Account in Euro
with Belgium Bank, Brussels but with German Bank, Frankfurt and Belgium
Bank, Brussels does not maintain their Nostro Account in Euro with British
Bank, London but with another German Bank in Frankfurt, the Funds Transfer
Application will automatically create a Cover payment which will be sent to
British Bank's correspondent in Germany.
When MT400 message is to be sent for payment advice regarding collection,
then FT.TXN.TYPE.CONDITION is to be defined accordingly and
COLL.REM.BANK needs to be specified in the transaction .

Based on the cover method and customer given in BEN.CUSTOMER or
BEN.BANK, it is possible to get the bank values defaulted in related fields
using AGENCY record for the customer.
For COVER-DIRECT method, where MT 103 is sent directly to another
Institution and MT 202COV is sent to our correspondent,
RECEIVER.BANK, REC.CORR.BANK and INTERMED.BANK Fields are
defaulted, provided AGENCY has been suitably defined and setup for
Receiver Bank and its correspondent Bank.
For COVER-NEAR method, where MT103 is sent through several
reimbursement institutions using an ‘Account with institution’ and MT
202COV is sent to our Correspondent, ACCT.WITH.BANK,
RECEIVER.BANK, and REC.CORR.BANK Fields are defaulted, if defined
in AGENCY.

ACCT.WITH.BANK identifies the Bank other than the receiver Bank where
the ultimate beneficiary maintains its Account. It is used when the ordering
party requests that the beneficiary be paid at a bank other than the receiver
Bank. Customer specified, cannot be the same as the Customer of the Credit
Account. RECEIVER.BANK is defined as bank to whom the Payment Order
is to be sent like OB, ( outward banks payment) OT, ( outward Telex
payment) or the bank on which the Draft is drawn like OD type of transaction
as defined in FT.TXN.TYPE.CONDITION. Field will only be used to identify
the recipient of a Bankers Payment, the recipient of a Cable Payment Order or
the Bank where a Draft Payment is payable.
Receiver Bank may only be entered, in respect of Bankers Payment, Cables
and Drafts. When the field is left blank, the Application will use the Customer
of the Credit Account as the recipient of the Payment Order. Details given in
REC.CORR.BANK will be mapped to tag 55 (Third Reimbursement
Institution) and INTERMED.BANK to Tag 54 (Receiver Correspondent Bank)
in Swift MT103 message.

Generation of Debit and Credit advices can be controlled at transaction level
by using DR.ADVICE.REQD.YN and CR.ADVICE.REQD.YN Fields which
set as “Y” to generate suitable advice.
PAYMENT.DETAILS Field in FUNDS.TRANSFER corresponds to Tag 70 in
SWIFT. It allows details of the transfer to be input for inclusion on the
Payments and Advices. Payment Details should not contain payment
instructions, but reference information for beneficiary as supplied by the
ordering customer. Typical examples are Reference and invoice numbers.
PAY.METHOD Field contains additional instructions for the bank to whom the
Payment Cable is sent. It defines further method of payment to be used by the
receiver. This data forms part of the Bank-to-Bank information defined for
SWIFT field 72.
Some of the standard swift codes are TA Telex advice, PT Pay by telex, PA
Phone advice, PP Pay by phone, AT Application / Identification by telex AI
Application / Identification , PB Pay beneficiary only and CH Pay by cheque.

Free format text to appear on the SWIFT message 23E INSTRUCTION.TYPE
on message MT103 Single Customer Credit Transfer
Validation of these code words take place in SWIFT, therefore it is important
they are used in their correct format.
Only allowed when the Funds Transfer transaction has been set to produce
SWIFT message MT103 via FT.TXN.TYPE.CONDITION

It is possible to send free text messages other than standard – like sending a
direct telex advice to Beneficiary in addition to sending the standard message
to Bank, at our Customer’s request.
When data is present in FREE.TXT.MSGTO Field, a further telex will be sent
in addition to the messages normally produced when the transaction is being
processed by the Delivery Application.
When the receiver of the message does not exist on the Customer file, the User
may directly input the Name and Address details of the intended receiver of
the message. In this case the User should also supply the telex number (where
available) to enable the delivery system to send message.
If input in this field is less than 11 characters, the system will interpret the
input as a Customer Mnemonic and try to find a Customer accordingly. For
this reason, any free text used to input manually the name and address of the
receiver of the free message must exceed 10 characters.
Charges can be taken for the additional message and is indicated
FT.APPL.DEFAULT. This will be in addition to normal charges applicable for
the transaction.

When ever a outward remittance transaction with generation of MT103 is done
in T24, the version can be split up into two section. The first section has details
of Charges on outward remittance which could be collected from Beneficiary
or our Customer or shared amongst the Banks .Each Bank would take its
charges from its Customer. BEN.OUR.CHARGES is used to signify who will
be responsible for charges. This field corresponds to field 71A in SWIFT
messages.
These options are called BEN, OUR and SHA . If OUR is mentioned, charges
of both the banks are on the Ordering Customer. If Charges are defined as
BEN, all charges are for the account of Beneficiary. This includes charges of
remitting Bank. In this case, the remitting Bank would send proceeds less its
charges.
SHA means all transaction charges on the Sender's side are to be borne by the
ordering customer and transaction charges on the Receiver's side are to be
borne by the beneficiary customer.
As charges are shared generally, value SHA is set to be defaulted. However,
depending on the instructions, this could be changed by inputter.

Outward remittances through MT 103 with a MT 202COV can be handled
through a different Funds transfer Menu. Input details are similar to the earlier
option with additional details for MT 202COV message.
Detailed payment instruction are sent to a bank in MT 103 while the cover
message is sent to the bank’s correspondent bank in MT 202COV. In this
section, information from earlier sections get defaulted with the addition of the
beneficiary institution. BEN.BANK Field identifies the Bank which is the
ultimate receiver of the funds transferred by the sending Bank. This
information is mapped to Tag 58 in SWIFT message MT202COV. MT
202COV message will contain all the tags of MT202 and additional tags from
MT103 like ordering customer, beneficiary customer details etc.

MT 102 refers to multiple Customer credit transfer and MT 203 refers to
multiple general financial institution transfer generation.
MT103 / MT202 messages that are to be generated from
FUNDS.TRANSFER, can be grouped together and sent as MT102 / MT 203
by defining NETTING.STATUS Field as “null”. If this flag is set to "NO",
then MT202 or MT103 is generated from FUNDS.TRANSFER without
applying netting process.
For netting purpose DE.PARM is to be setup with NETTING.PAYMENT Field
as Y. This enables netting of delivery message. Further, DE.MESSAGE
records with ID 103 and/or 202 is to be defined with NETTING.ALLOWED
Field as Y. If one of the message is set to Y, then suppression of that message
alone takes place in FT. Based on these setup, actual transaction in FT decides
the generation of message.
Now in FT, if NETTING.STATUS Field is “null”, then default into the field
will be 102 , 203 or 102*203. When DE.MESSAGE record for 103 alone is
allowed for netting, then field in FT defaults as 102 and MT103 will be
suppressed. Likewise, if netting is defined for 203 ,then it is defaulted to 203
and MT202 will be suppressed and when both MT103 and MT202 are netted,
then both are suppressed and field defaults as 102*203.

Further after generation of MT202 and MT103 from FT are suppressed, details
are passed on to NETTING.ENTRY application . Additional setup needs to be
done for processing of the delivery message for all FTs grouped.
To generate a MT102 and MT203 Swift Messages, suitable records in
NETTING.AGREEMENT have to be created for the receiver of the message
with Id as <customer Id>.<message Id>.
The required contracts can be selected for purpose of netting through
CREATE.NETTING application for the following criteria namely Customer /
Currency/Value Date/System Id /Receiver Correspondent/ Sender
Correspondent/Bank operation Code. In the case of MT103 netting, it is
mandatory to give the operation code namely CREDIT or CHQB to indicate
the method of payment. When this record is verified, then based on the
selection criteria, all FTs are grouped into an application NETTING. When
this record is authorised, then respective messages namely MT102 and MT
203 are generated for the group of FTs.
NETTING application is used by FT only to generate MT102 / MT203 by
grouping MT103 / MT202 details respectively and not for netting of
accounting entries. Respective FTs raise accounting entries independently on
authorising those transactions.

When instrument are sent for collection , the collecting bank is required to
send out a payment message to the bank which has sent instrument for
collection. T24 is able to produce an MT 400 from the funds transfer
application for certain OT transactions that are input. For this purpose, there
must be a record in FT.TXN.TYPE.CONDITION with a record ID as
OTXX(namely OT40) where the MESSAGE.TYPE Field should be indicated
as 400. For such transactions MT400 will be sent to the bank indicated in
COLL.REM.BK. Field, Customer to whom an MT400 Advice of Payment will
be sent must be a bank.
If the bank which has received the instrument for collection has no
Nostro/Vostro relationship with them , then an MT 202 is required to be sent as
cover message to the bank with which the collecting bank is having a Nostro
account.
RECEIVER.BANK is mandatory when credit account belongs to a Nostro
account and should be same as the collecting bank. Sender to Receiver
information can be defined differently for each message of MT 202 and
MT400 by specifying SEND.TO.PARTY as CRCUST or COLL.REM.BK.

OC is transaction type used for issue of a local currency draft/ Bankers
cheques/Cashier check. In case of Banker’s cheque, the account on which draft
is drawn will be CREDIT.ACCT.NO and a pre defined internal account can be
setup. For local Currency outward transfers, the Account will default to Vostro
account of the Receiver bank if this has been defined in the Agency record.
CREDIT.AMOUNT defines transfer amount or draft amount.
DFT.CCY.UNIT defines decimal unit in respect of each currency. For example
in GBP currency, the DFT.CCY.UNIT is pence. Like wise in USD it is called
as Cents.

When a bank issues a foreign currency demand draft, MT110 can also be
generated. To generate the MT110 message, it has to be set up in
FT.TXN.TYPE.CONDITION, with a suitable transaction code such as OT10.
For generating MT110, transaction type record in
FT.TXN.TYPE.CONDITION is to be set as 110 in MESSAGE.TYPE Field.
While issuing draft, credit account is either a vostro account or a nostro
account of the bank on whom the draft is drawn on.
Agency record of the Receiving bank can be defined if testing arrangements
exist or whether they hold any authorised signatures and specified in field
TEST.SIGNATURE.
Where a nostro type of relationship is maintained with this Agent, input must
be T or B, For a Vostro relationship input must be T, S or B and for all other
agents input is optional. T stand for Telegraphic testing arrangements exist. S
stands for signature arrangements exist. B stands for both conditions T & S
exist. Null refers to no control documents.

When a foreign currency demand draft is issued, Banks usually send out a
confirmation to its Nostro Bank by means of Swift message MT110. MT 110
contains details of the Transaction reference number, Date of Issue of draft,
Amount of draft, Draft number, Beneficiary name along with instructions, if
any, for payment of the draft when presented to the Nostro Bank .
Nostro Bank will act on this MT 110 message once the draft is presented for
payment.
For example : Michael Dell has an account with T24 Bank and wants to send
an amount to Frank Bishop, who is not an account holder in T24 Bank. In this
instance, T24 Bank will issue a draft in favour of Frank Bishop by debiting the
account of Michael Dell. Simultaneously, T24 Bank will advise its Nostro
Bank namely, Barclays Bank, London with a MT110 message. The draft is
sent by Michael Dell to Frank Bishop, who presents the draft to Barclays Bank
for payment. Based on the instructions received by Barclays Bank, the draft
will be honoured and payment made to the beneficiary.

MAILING identifies instructions relating to the delivery of a Cheque or a
Draft Payment which is issued as a result of the Transaction Types OC or OD.
When specified as BEN, it implies that the cheque or draft issued must be sent
directly to the beneficiary and CUST implies that the cheque or draft is to be
sent to the ordering Customer rather than the beneficiary. In this instance the
cheque or draft will be printed with the debit advice and the covering advice
(for the beneficiary) will not be produced.
If the Debit Account Number is a Profit and Loss Category Code or an Internal
Account, the Customer will be identified by the content of the Ordering
Customer field.

FT can be used by Banks for Inward Remittances in favour of its Customers .
This can be done manually or automated by suitable interfaces.
When processed using OFS , incoming SWIFT message can be received and
automated to create FT in INAU status/ authorised, by using different versions.
The transaction will in turn perform normal processing of updating limit,
position and account balances.
Today’s value dated instructions can be executed online and future value dated
instructions executed during COB
If there are any errors, then those FT records are put on hold.
From inward Swift payments (MT 200 or MT 202), depending on the
transaction type, it is possible to send on-forwarding MT 205 (further
transmission of a transfer request domestically) or MT 202 (movement of
funds between financial institutions) messages automatically. FWD.IN.TXN
Field in FT.TXN.TYPE.CONDITION can be used for indicating one of three
options:
“YES” to generate messages in the form of MT205COV
“NO” to block messages
202 to generate MT202COV instead of On-forwarding MT205COV message

Handling inward remittance is very similar to that of outward remittance.
It can be handled through FUNDS.TRANSFER application manually or
automatically if there is a suitable interface with SWIFT. Once it is interfaced
with SWIFT then T24 can create a record in FUNDS.TRANSFER in
unauthorised status.
For handling inward remittance, MT200 or MT202 it is possible to
automatically send On-forwarding MT 205. For this FWD.IN.TXN Field in
FT.TXN.TYPE.CONDITION to be set up accordingly. If it set as Yes then
MT205 will be generated, No refers to blocking of messages and 202 then it
will generate MT202 instead of MT205.

FT application can process incoming ( inward ) messages to produce
electronic messages, which can be mapped to produce FUNDS.TRANSFER
transactions. These transactions may be generated in unauthorised status for
further input and authorisation, or may not require authorisation and be
completely automatic. Such incoming transactions may even generate
outgoing messages as well, especially if you are operating as a correspondent
bank.
When override message is encountered, then FT will be on hold and user has
to accept the override manually to complete the transaction.

It is possible to manually input details of inward remittance using suitable
menus and transaction types . It can be designed to accept four mandatory
fields, namely Debit account, currency, amount and Credit account. The debit
account has a drop down list of Nostro/Vostro accounts.
Another information, when the debit account is a Nostro, it will be person who
has ordered this remittance which is input in ORDERING.CUST or
ORDERING BANK depending on the information in Tag 50 and Tag 52
respectively in swift message. It is a multi value field, where either the
existing customer Id or Mnemonic or the name and address of the ordering
Customer is entered. These help Banks to print suitable advices.
If Debit account is not input, FCY nostro account from NOSTRO.ACCOUNT
application and LCY Vostro account from AGENCY application will get
defaulted, depending on the debit currency.

AC.EXPECTED.RECS records the expected funds or payments in T24 and
allows the banks to determine the projected balances, assisting them to
perform their business more efficiently. When the funds are received or
payments made these are recorded and also matched with the expected funds
or payments. The notifications to receive the funds can be by means of
incoming SWIFT MT210, TELEX or PHONE etc which are captured into
AC.EXPECTED.RECS by suitable definition in the inward delivery setup.
For actual receipt, when a FT of transaction type with ITXX is authorised, for
which the EXPECTED.RECS in FT.TXN.TYPE.CONDITION is set to YES,
the system automatically creates an AC.EXPECTED.RECS record and match
with expected receipts based on criteria in ER.PARAMETER and finally
displays in the information box .
ER.PARAMETER defines the account/s or type of account ( category) for
which expected payments and receipts are to be monitored. It holds the rules
for matching criteria like type of expected fund type and payment type namely
ER(expected receipt) and RECEIPT , credit/debit type, updation to account
balance, matching fields and tolerance, if any allowed. VALUE.DATE,
CCY.AMOUNT and ACCOUNT.ID are fields which have to be defined to
check for matching.
There are only two possible records in this file SYSTEM and COVER.
SYSTEM is for standard receipts/payments processing and COVER is used to

link FT to set limits on the processing of cover payment message.

Fields which are to be filled up in AC.EXPECTED.RECS are account ID,
Value date, Currency and amount expected. Here the account ID will normally
be the account of a Vostro or a client account. These input can be manual or
automatic from incoming MT210
FUNDS.TYPE can be defined to identify whether record is an expected
amount or a received/payment amount. Defaults to Receipt when created by an
incoming FT transaction else, it will be expected receipt (ER). For a manual
creation input is mandatory in the field.
Status of the record goes through various stages namely Waiting, Matched,
Deleted, etc..
When two records are matched their STATUS is changed to MATCHED, and
the MATCHED.WITH Field will have the corresponding matching records ID.
When manually input, it will be initially Waiting. To do a manual matching
select the record to be matched (current STATUS should be WAITING, or
PARTIAL MATCHED), change the STATUS to F (FORCE MANUAL
MATCH) and insert or select the ID of the record to be matched with in
MATCH.WITH Field. If the records are compatible then these will be
matched. The record with a lower amount will have STATUS MATCHED i.e.
fully matched and the record with the higher amount will have STATUS
PARTIAL MATCHED. The PARTIAL MATCHED record can be manually

matched again with another receipt.

In FT.TXN.TYPE.CONDITION transaction types whose id is ITXX ,
EXPECTED.RECS Field has to be set as yes for automatic creation of receipt
records in AC.EXPECTED.RECS . Then when an incoming receipt is updated
in FT transaction, System will automatically create a record in
AC.EXPECTED.RECS with FUNDS.TYPE Field as RECEIPT. Based on
criteria set in ER.PARAMETER, System does an automatic match with
records in Waiting/Partial matched and when completely matched changes the
status to Matched. Cross reference of transactions matched are updated in
AC.EXPECTED.RECS and FT is updated with reference of
AC.EXPECTED.RECS. In case of manual matching, details of records which
have to be used for matching has to be input by User.
Automatic matching can be setup with a tolerance in ER.PARAMETER.
After completion of matching, status in AC.EXPECTED.RECS gets changed
suitably to Matched and historical movement is also maintained in it.
In the ACCOUNT record, date wise balance of expected receipts are updated.
Fields used for the purpose is ER.VALUE.DATE and ER.BALANCE. When a
receipt is matched then the ER.BALANCE gets reduced by the receipt amount.
Similar features can be defined for expected payments also.

MT103 messages requesting payments to be made by the receiver bank may
be received from banks which do not hold accounts in the currency of the
transaction with the receiver bank. The receiver bank will expect a cover
payment to be made by the sender via one of its correspondents, who will
notify the receiver of the cover payment in some way. The payment instruction
will be held until the receiver is satisfied that the cover payment has been
made.
T24 can allow payments requests to be automatically authorised, without the
receipt of cover payment confirmation, where a sending bank does not hold a
Vostro account with the receiver bank but it does have a preset allowance or
limit. MT195s will be produced to query an unauthorised payment and finally
cancel it (when it has been authorised within an unused limit) if a cover is not
received within specified escalating periods.
During MT103 inward processing, in AC.EXPECTED.RECS application a
record is created with FUNDS.TYPE as “EC-Expected Cover” and checks on
the limit availability. A record is created in ER.COVER.LIMIT with the
Sender’s BIC code and limit affected to the extent of incoming transaction
Amount. FUNDS.TRANSFER contract is created in Hold or Live based on the
available limit with the incoming MT103 details.

During MT103 inward processing, a record is created in
AC.EXPECTED.RECS application with FUNDS.TYPE as “EC-Expected
Cover” with appropriate Status based on the limit availability.
In AC.EXPECTED.RECS, cover details received for the MT103 payment can
be input manually with funds type “RC-Received Cover”. When MT103 is
received for payment, the system checks for matching cover details before
processing and when matching cover is available the system matches both
“RC” and “EC” record. Otherwise available limit, as defined in
ER.COVER.LIMIT for the sender of MT103 is reduced, to the extent of
transaction amount. To match “EC” with “RC” record, matching criteria in like
Account id, Currency, Amount, Value date, Reference etc can be specified in
ER.PARAMETER.
In AC.EXPECTED.RECS application, “EC” records can be created only
through inward message processing. “RC” records can be created through
manual input or through an interface using the statement entry details or cover
payment details. The related AC.EXPECTED.RECS id is available in FT and
id of ER.COVER.LIMIT in AC.EXPECTED.RECS for cross-reference.
Using EB.FREE.MESSAGE application, MT195 (Queries) is raised for the
unmatched AC.EXPECTED.RECS during COB batch process for follow-up.

In FT.APPL.DEFAULT setup of AWAIT.COVER is required Set to “LIM” to
use Limit correspondent checking functionality when inward MT103 is
received.
When set to “YES”, then FT’s created through inward processing are always
put into HOLD and the User has to manually check the cover details.
If AWAIT.COVER is left blank then the hold or approve Cover Limit
processing is not activated.
In ER.PARAMETER, add a record with ID as “COVER” and give the
matching criteria for payment request to cover limits and retention days for
moving the matched records to history.
In ER.COVER.LIMIT, specify the limit allotted to correspondent Bank who
does not hold a Vostro account. The id for this application accepts 8 or11
characters-and should be a valid BIC code. When a record for the sender of
MT103 is not available in this application, then system automatically creates a
record with available Limit as “0”. To set-up a Limit for a Bank that can be
used by all its branches, id has to be created with 8 characters (i.e. without
branch code or “XXX”).

When an Inward MT103 message is received from a Non-Vostro Customer.
Case 1: Customer for whom the limit is not defined in ER.COVER.LIMIT: It
will create a FT on hold and “EC” record in AC.EXPECTED.RECS
application with STATUS as “UA-Unauthorised“. Also record is created in
ER.COVER.LIMIT with available limit as “0”.
Case 2: Customer for whom the limit is defined and available :FT record is
created and authorised and an “EC” record is created in
AC.EXPECTED.RECS with status as “AU-Authorised”. Limit amount is
reduced from ER.COVER.LIMIT for the Customer to the extent of payment
amount.
If the incoming message amount is in excess of any limit amount available
then the FT is created on Hold and AC.EXPECTED.RECS is created with
STATUS as “UAL-Unavailable Limit”.
Case 3: Cover details available for a Payment : FT record is authorised and an
“EC” record is created and matched with the respective “RC” record with
status as “M-Matched”. However, the limit will not be affected as cover for the
payment is received.
During the processing of an Inward MT103 message, an “EC” record is
created with incoming details and the system matches the “EC” record with
“RC” details (as per the matching criteria) and both records are set to “M-

Matched” status.

In AC.EXPECTED.RECS, details which need to be input are Account number,
Value date, Currency and expected amount.
Normally the Account will be a Vostro or a Client account. Account number is
entered by user or can be populated via an incoming SWIFT message
(MT210). 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)
Only accounts defined in the ER.PARAMETER either individually or by
CATEGORY can be entered.
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)

Funds transfer module can be linked with FOREX application when exchange
rates for a transaction is to be obtained from a dealer. CURRENCY table
defines the negotiable amount above which the exchange rate to be used must
be obtained from the dealer. For amounts within this value exchange rate from
CURRENCY can be used without reference to the dealers.
Internal deals are created within FX to allow dealers an option of immediate
updates of the Currency positions, without dependence on other departments.
Transactions which exceed the amount specified in the negotiable amount
should be booked with the dealers, who in turn will input a Forex transaction
and mention the deal as internal in the field called DEAL.SUB.TYPE in
FOREX application.
In FUNDS.TRANSFER contract input of rate should be done manually and
linked to the above FOREX transaction by giving the reference into
NEG.DEALER.REFNO Field of FT. User should input only the sequence
number of the FX transaction to relate to a deal which has been input. When
the FT record is authorised, System will therefore cancel the Forex deal to
avoid duplication of foreign currency positions. Internal deals which are yet to
be matched by a corresponding FT can be viewed as Exception in Forex
application.
Note : It must be remembered that when the transaction amount is greater than
the negotiable amount, only the customer spread (as defined on the

CURRENCY table) will be added to the Treasury rate.

The accounting entries are raised on authorisation of Funds transfer and are of
two types namely STMT.ENTRY and CATEG.ENTRY. Entries affecting
Account balances are stored in STMT.ENTRY file by the system, be it
Customer account or Internal account. Entries affecting P & L heads are stored
in CATEG.ENTRY file.
The charges/commissions and taxes thereon collected from Customer account
can be shown separately or customer account credited/debited with net amount
of transaction. If Charges and commissions are to be reflected separately in
the account statement of the customer, then it can be specified in
FT.GROUP.CONDITION for appropriate group of customer or specific
customer using CHG.COMM.SEPARATE. Field. When it is set as Yes, then
entries are split for charges from debit/credit transaction amount of the
customer.
The system uses the transaction code as defined in the
FT.TXN.TYPE.CONDITION and from FT.COMMISSION.TYPE for the
commission.

MT103 is message for Single Customer Credit Transfer and MT102 is used
for multiple customer credit transfer. Variations used for the purpose of
Straight through processing will be MT103+ and MT103REMIT.
For this to happen, the OT record on application FT.TXN.TYPE.CONDITION
must have the MESSAGE.TYPE Field set to 103.
Automatic MT110 Advice of Cheque: T24 is able to produce an MT110 from
the FUNDS.TRANSFER application when OC or OD transactions are input.
In order for this to happen, the OC or OD records on application
FT.TXN.TYPE.CONDITION must have the MESSAGE.TYPE Field set to
110
NOSTRO.XFER Field in FT.TXN.TYPE.CONDITION accordingly. MT203 is
used for multiple transfer in respect of financial institution transfer.
T24 also supports MT 202COV/MT205COV
MT205 can be generated for forward transmission using FWD.IN.TXN Field
in FT.TXN.TYPE.CONDITION.
Automatic MT400 Advice of Payment: T24 is able to produce an MT400 from

the FUNDS.TRANSFER application when OT transactions are input. In order for this
to happen, the OT records on application FT.TXN.TYPE.CONDITION must have the
MESSAGE.TYPE Field set to 400

This table defines the contents of each basic Message Type. It lists the fields,
describes them as single or multi value, and states whether each field is mandatory or
optional. It also determines whether a test key is required for each message type.
The ID chosen for each Message Type should, where possible, conform to a SWIFT
message type, defined in the SWIFT manual, even when there is no intention of
sending a message by SWIFT. This avoids confusion when an incoming SWIFT
message is received. On the Delivery Message Table a message may be defined with
many more fields than the corresponding SWIFT message because additional
information may be required for printed versions.
For example if a MT 103 message for single customer credit transfer has to be sent
then in DE. MESSAGE all the tags like sender’s reference, Payment details, etc. that
appear in SWIFT message MT 103 has to be defined.
As and when a transaction is authorised all the details of the transaction are written in
DE.O.HANDOFF.
DE.MAPPING is a table which defines where data for outward messages (and
message headers) is located within the raw message data passed to DE.O.HANDOFF
by the banking applications. The banking applications do not format and send
messages themselves. They send details to the Delivery System which then uses the
Mapping Table to locate value for each field (tag) in DE.MESSAGE from within that
raw data. Id is of the form Message type, Application and sub classification. For

example : 103.FT.1

DE.FORMAT.SWIFT defines how the data content of a message is to be converted for
SWIFT. The header and trailer required by SWIFT are standard and generated
automatically. They are not specified in this table. This table is also used to convert
incoming SWIFT messages for processing by various banking applications. For
example: It holds that Tag 20 field is linked to the field sender reference in
DE.MESSAGE.
For the purpose of delivery message, DE.PRODUCT holds information like Status
(Normal, Hold or Delete), Priority (Normal, Priority or Urgent), carrier to be used, and
the version of the address that a message must be set to. It also specifies for each
Carrier/Delivery Address, which version of the format should be used, and how many
copies should be made. Product records may be specified for: a particular company, a
customer, an account, application or combination of these.
DE.ADDRESS file contains the names and address of a bank's customers and also of
each company within the banking organisation. Postal address of each Customer is
automatically updated when the address is changed through Customer Maintenance.
Swift address and additional postal address has to be manually given.
DE.O.HEADER tells about the disposition of the message. A message will be placed
in the Repair Queue with disposition set to 'Repair‘ when system encounters a
discrepancy in mapping or formatting. A description of the error will be defined in
ERROR.CODE. When the problem of a formatting error has been resolved the
MSG.DISPOSITION can be changed from 'Repair' to 'Resubmit‘ and authorised to get

the message.

The International Bank Account Number (IBAN) is an international standard
for identifying bank accounts across national borders with a minimal risk of
propagating transcription errors. It was originally adopted by the European
Committee for Banking Standards (ECBS), and later adopted as an
international standard under ISO 13616:1997 based on SWIFT.
Standard domestic account numbering systems exist in most countries. The
IBAN is not a single account number structure to replace these. Instead, it is a
way of representing existing account numbers in a standard recognisable
format, which can be verified using mathematically calculated check digits. To
make a cross border European payment, customers will need to quote an
IBAN and its associated Bank Identification Code (BIC) in the same way they
currently quote an account number and a BIC.
The IBAN structure is defined in ISO 13616-1. Subject to a maximum of 34
characters, the IBAN consists of a two-letter ISO 3166-1 country code,
followed by two check digits and up to thirty alphanumeric characters for a
BBAN (Basic Bank Account Number) which has a fixed length per country and,
included within it, a bank identifier with a fixed position and a fixed length per
country. The Country code enables recognition of the Country in which the
IBAN was issued. It also indicates the national account structure to be used
when deciphering the domestic account number contained within the IBAN.
IBAN length can vary between countries as standard account number length
varies between countries. But structure of IBAN will be the same. When
stored electronically, IBAN cannot contain spaces. However when printed,
IBAN is expressed in four-character groups.
For example, the IBAN GB19LOYD30961700709943 will be represented in
print as: GB19 LOYD 3096 1700 7099 43

During Account generation, the IBAN will be formed in such a way that the
components for the Bank & Branch will be taken from the COMPANY file by referring
to the IBAN.BANK.ID & IBAN.BR.ID fields.
IBAN Generation
IBAN will be generated for a T24 account while opening the account if IBAN is
installed. System checks the Company table to retrieve the COUNTRY.CODE-
COMPANY.CODE to get the required data.
Based on the mapping defined for the bank code, branch code and account number
in the structure file, BBAN (Basic Bank Account Number) will be generated for the
account. Using IBAN generation algorithm, determine the Check digit of IBAN and
prefix BBAN with the Country code and Check digit to form complete IBAN
Once IBAN is created for the account, IBAN will be stored in ALT.ACCT.ID field
associated with ALT.ACCT.TYPE having T24.IBAN of Account record
The generated IBAN can be amended if required. In case of manual input, system can
validate the IBAN using check digit.
The IBAN related fields are available in the Funds.Transfer application. IBAN related
fields are also included in the Agency and Beneficiary application to ensure that the
IBAN of Agency records and also in Beneficary are also validated

The IBAN related fields are included in the Funds Transfer module. Upon inclusion of
the above fields in the respective versions, the IBAN is validated when input in those
fields with respect to its structure by referring to the IBAN structure of the country to
which it belongs.
The IBAN.BEN field contains the IBAN of the beneficiary account number.

The IBAN that has been populated in the fields of the respective versions are mapped
to the corresponding Swift messages

Funds Transfer, Standing Order and Beneficiary application derives the BIC code, Institution
Name & Country Name of the Beneficiary automatically from the IBAN that has been entered in
the IBAN.BEN field.
BIC.IBAN.BEN.NAME and BIC.IBAN.BEN.CITY can be manually input if there is no value in
the BIC.IBAN.BEN. These fields are to be mapped in tag 57D.
When there is a BIC in BIC.IBAN.BEN, but it is not valid, then all three fields should be
mapped to 57D. In this case the BIC code should not be prefixed by “SW-“.
BIC.IBAN.BEN - Is defaulted with the BIC code that is derived from the IBAN of the
Beneficiary blank for manual Input in case the BIC information is unable to be derived from the
IBAN of the Beneficiary. The BIC code of the valid IBAN of the Beneficiary is checked with the
BIC of the RECEIVER.BANK and in the absence of the same will be checked with the BIC of
the Credit Nostro Customer and if found to be different will be automatically defaulted by
appending ‘SW-‘ in the ACCT.WITH.BANK field.
BIC.IBAN.BEN.NAME - is defaulted with the Institution Name relevant to the BIC code. Blank
for manual Input in case the BIC information is unable to be derived from the IBAN of the
Beneficiary
BIC.IBAN.BEN.CTRY - is defaulted with the Country of the Bank relevant to the BIC code.
Blank for manual Input in case the BIC information is unable to be derived from the IBAN of the
Beneficiary
IBAN.BEN field contains IBAN number, the above three fields are optional. Even if one of the
above field is left blank – override message is displayed
BIC.IBAN.BEN.CITY - field BIC.IBAN.BEN.CTRY is renamed to BIC.IBAN.BEN.CITY of
the BIC.IBAN.BEN. The information will be mapped from the CITY field of the DE.BIC table
when defaulted.
BIC.IBAN.BEN.NAME - Can be manually input when no value in the field BIC.IBAN.BEN
BIC.IBAN.BEN.CITY - It is required that the values of these two fields be mapped in tag 57D.

FT1308505GTBSHN8

T24 Customer
Temenos University - June 2012

Bank Directory Plus - Financial institutions and corporates use this file to look up basic data
about financial institutions, and to validate and cross-reference BICs, CHIPS codes and national
bank codes.
T24 is enhanced to support the new Bank Directory Plus. There are new fields in Bank Directory
Plus which are not present in the BICPlusIBAN directory. These new fields are added to DE.BIC
table.
IBANPlus – This data is used by financial institutions and corporates to validate IBANs, derive
the BIC from an IBAN, look up the country specific IBAN structure, determine whether the
usage of IBANs in a country is optional or mandatory(available in the future).
T24 supports SWIFT IBANPLUS Directory and EXCLUSIONLIST file.
IBAN is validated by extracting bank code and validating it against new exclusion list data. BIC
is derived from IBAN.PLUS file
In addition to existing IN.IBAN.STRUCTURE verification, from IBAN Structure record get the
BANK IDENTIFIER POSITION and the IBAN NATIONAL ID LENGTH based on country
code and extract the bank code from the IBAN. Verify this bank code in EXCLUSIONLIST and
if present then the IBAN is invalid.
In the IBAN Plus File based on IBAN.ISO.COUNTRY.CODE and IBAN.NATIONAL.ID,
retrieve the associated BIC from the IBAN.BIC. This is the BIC to be used with the IBAN.
IN.IBAN.PLUS - Maps the information from the downloaded IBANPlus file
IN.IBAN.STRUCTURE - Three new fields added to store IBAN information
IN.EXCLUSIONLIST - contain the records uploaded from SWIFT EXCLUSIONLIST file.
IN.EXCLUSION.LIST.LOAD - to map the information from the downloaded SWIFT
EXCLUSIONLIST file into a new table EXCLUSIONLIST.

Standard enquiries available in Funds transfer are as under:
Foreign currency Draft issued. It is a report consisting of FCY draft issued on
a day, detailing the FT reference number, transaction type such as OT, or OT03
or OT10, Debit account, Debit customer, Draft number, Beneficiary name,
Currency of the draft, Draft amount , Drawn on which Nostro account and
details of charges collected.
Outward remittances enquiry displays a report consisting of all outward
remittance with a transaction type code as OT or OT03 and OT40 . It is a
report detailing the FT reference number, Transaction type, Debit account no,
Debit customer, Beneficiary name, Currency, remittance amount, drawn on
account ( indicating which Nostro account) drawn on, amount debited
together with details of charges.
Transfer between Nostros displays the list of Funds transfer transaction
between two Nostro accounts.
Inward remittances received on a day report shows the list of inward funds
transfer received through Vostro and Nostro account are displayed.
Enquiries for FT reversed report shows the list of FT transactions reversed for
the day. It could be any type of FT transaction like, Account to account transfer
or Inward remittances etc.

Encompassed within the FUNDS.TRANSFER module is a fully operational
sub-module for effecting payments using Standing orders (STO).
Single transfers involve a single debit and credit. An account can have
multiple standing orders for which different types . It includes maintenance of
balance, minimum or maximum such that transfers occur into or out of account
when it falls below or goes above the amounts specified.
Standing orders could be defined with fixed or periodic payments which can
be effected from accounts. For example monthly payment of fixed amount of
rent or telephone bills with variable amounts. The module can be used to pay
interest capitalised on an account to another – internal / external.
Certain types of standing order called Diary could be instructions recorded for
reminder. Caters for Operating Lease contracts and accrual of Standing Order
amount.
Bulk transfers involving single credit and multiple debits or single debit with
multiple credits can also be handled in standing orders. In addition to
STANDING.ORDER, which is used for single standing orders, there are other
applications, BULK.STO and FT.BULK.CREDIT, which are used to pay many
amounts with one compensating entry.
For example : John’s account will be debited each month with USD 10,000.00
of which USD 2,500.00 will be paid to a Mr John Fowler and balance USD

7,500.00 via an account transfer to Mr David Dell.

During implementation parameter tables are to be set up for
STANDING.ORDER processing. It is in STO.TYPE table that various types of
standing order instructions can be set up.
Standing orders can be executed using multiple credits or debits, Debit to one
account and credit to multiple accounts or credit to one account and debit to
multiple accounts. In both cases, accounting is washed through an internal
suspense account as defined on ACCOUNT.CLASS. The record
SUSPFTBULK must be in place and have the relevant accounts opened before
using BULK.STO, which handles debit to one account and credit to multiple
accounts.
In addition to the BULK.STO there is another application where the id is the
credit account and multiple debit accounts and amounts are allowed. This
application is FT.BULK.CREDIT, is a single credit and multiple debit
solution.
In ACCOUNT.CLASS, the record SUSPFTINWD must be in place and have
the relevant accounts opened before using FT.BULK.CREDIT.
STO.BULK.CODE will enable the User to load, in a central place, specific
details on the most frequently used Standing Orders. These details concern the
Beneficiary, Beneficiary account number, Account with banks and Bank sort
code

The different types of standing orders handled are done by means of 10 hard
coded STO.TYPE.
Funds Management based on balance levels include BI, BO and BP types.
Automatic transfer of funds to maintain a minimum balance in accounts is
handled by BI which refers to Balance Maintenance In. Defined for an
ACCOUNT which is to be maintained at a minimum balance. When balance
goes below the amount specified, then transfers from another internal account
will be executed to restore the balance to the required level. Id for the
transaction will be account number followed by sequential number which will
be between 900 to 999 and it must be assigned by the user at input.
Automatic transfer of excess funds uses BO which is for Balance Maintenance
Out . Balance in ACCOUNT is to be maintained at a maximum balance. The
system will draw down the excess amount and effect a payment as specified in
the instruction. ID for the transaction will be account number followed by the
sequential number which will be between 900 to 999 and must be assigned by
the user at input.

Funds Management based on balance levels:
BP, the abbreviation BP stands for Balance Payment . This STO is similar to
BO type, but gets executed during the Start of day process. Hence the balance
used for the transfer will be that day’s opening balance. Any Interest/Charges,
which are 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 in the instruction. ID for the transaction will be account number
followed by the sequential number which will be between 900 to 999 and must
be assigned by the user at input.
Regular payment types:
Fixed (FI) payments is used for standing orders which are effected for a fixed
amount on regular basis. Can be set for debiting or crediting an account.
FI for “Credit” type STO refers to a type of Standing order where the
customer’s accounts would be periodically credited with a fixed amount,
normally claiming the amount from external systems. Account specified in the
Record ID is treated as the Credit Account and the account specified in
CPTY.ACCT.NO Field is treated as the Debit Account.

Preset Payments when the amount and date are not known. PP refers to
periodic payments where a Customer has authorized the bank to pay bills
from third parties upon presentation of these bills. The amount will vary and
there is no definite frequency. Therefore, whenever an amount is input, then
during COB, start of day process, the payment will be made and the payments
program will delete the amount from the STANDING.ORDER record.
PPI refers to Periodic payment Interest. This standing order is used when
customer has requested the bank to pay out any interest capitalised in the
account to another account, which may be internal or external to T24. The
value dates will be based on the definition in FT.TXN.TYPE.CONDITION for
the respective transaction types.
RC or Revolving Credit standing order is 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.

Standing Order Type DD means Direct Debit . Bank has received a direct debit
mandate from the Customer which authorises the bank to accept direct debits
received on the Account, like payment of insurance. This type of Standing
Order will be completely passive in the sense that its sole purpose is to provide
the User with an on-line retrieval facility of Direct Debit mandates held by the
bank. When direct debits are received by the bank, the User can then verify
on-line if proper authority has been received from the Customer.
Diary Standing Order Type refers to DIARY for ad hoc requests against an
account. For example: Ring customer for new disposal instructions. It can be
created for any type of instructions to be recorded. Online reminder by way of
enquiry possible from Contents of STO.DIARY.
Only for DIARY type, it is possible to input USER.ROUTINE and
DAYS.DELIVERY Field. The permitted values for USER.ROUTINE are YES,
NO and NULL, while for DAYS.DELIVERY they are 1,2 or 3.
Each time the User creates a DIARY Standing Order item, the System will
automatically update an internal file STO.DIARY which will allow Users to
review the instructions.
Other types include OL or operating lease which caters for Operating Lease
contracts and accrual of Standing Order amount.

The account classification will uniquely identify each ACCOUNT.CLASS
entry. Specific records on the ACCOUNT.CLASS table are used by the other
applications when either an account number is to be constructed or an account
is to be checked for a particular group.
ACCOUNT.CLASS records are used for handling bulk standing order
operations. Accounting entries are washed through an internal suspense
account as defined in ACCOUNT.CLASS with a record ID as SUSPFTBULK
must be in place and have the relevant account opened before using
BULK.STO. This application handles multiple credits to a single debit. The
actual accounting is affected by the FT records created on-line or at COB. The
account used as part of the ID of this application becomes the debit account
on the resultant FT records and can be an internal/client account or Profit and
loss category. While handling single credit and multiple debit solution there
must be a record in ACCOUNT.CLASS called SUSPFTINWD. In this instance
application used will be FT.BULK.CREDIT.
In both instances, internal accounts in local currency must be setup for the
categories defined in these records.

STO.BULK.CODE is a table which will enable the User to load, in a central
place, specific details on the most frequently used Standing Orders. . When
many customers give Standing order instruction in favour of particular
beneficiary, bank could define these common beneficiaries to avoid repetitive
input and the risk of error in specifying the content of four fields namely
Beneficiary, Beneficiary’s Bank, Account number and Bank sort code ( BACS
payments ) in each Standing Order record.
For example, if many customers have given the bank Standing Order
instructions in favour of the same beneficiary,(example the annual subscription
to the AA or RAC), the User will wish to define in this table these common
beneficiaries to avoid the repetitive input and the risk of error in specifying the
content of four fields in each Standing Order record. Id of this record is
alphanumeric and must be given in the Standing Order record which will then
be sufficient to automatically generate the 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.

The order in which these files should be created is stored within the automated
tool for TAABS. For easy reference, the order sequence in ascending build
reference order is given in the left.
The mandatory files are shown with a red star mark.
Wherever there are dependencies for filling up values in the tables in build
sequence, the dependencies are shown on the right.

Standing orders can be recorded for a variety of uses. Various types of standing
order can be recorded in STO.TYPE.
Funds Management type of standing orders is used to specify balance levels in
an account which can operate in two ways. It is an indicator identifying a
balance level starting from which funds must be transferred either into, or out
of, the Account.
Fixed and Preset Payments types is used to load fixed payments with known
amount and frequency (monthly payment of rent) or as preset payments where
the amount is unknown (payment of gas bill).
Diary Instructions on any account can be defined with their related frequency.
An on-line retrieval facility (STO.DIARY) will allow User to check at any
time the outstanding Diary instructions.
Direct Debits is applicable when User can load mandates which the bank has
received from Customer to accept Direct Debits received on the Account.
When the Direct Debits are actually received by the bank, the User will then
access this file to check if the appropriate mandate has been received from the
Customer.
Periodic Payment of Interest facility will allow the user to pay away any
interest capitalised on an account periodically to the beneficiary.

During COB, the Batch jobs will access all Standing Orders due since the last
run date and up to and including that date. STO.BALANCES is run at end of
day to process Balance Maintenance Standing Orders, while STO.PAYMENTS
is run at start of day to process others.
FT transactions are generated automatically in authorised status if no errors or
overrides are encountered, else the FT transaction is created in IHLD.
For example: When the application is processing BI Balance
Maintenance Standing Orders and funds are not available to pay into the
Account, a Funds Transfer transaction will be generated with a status of
IHLD. The override field will specify the amount Required, the amount
available and, if applicable, the minimum balance to be kept in the
account from which the funds have to be taken. With the help of this
information, the user can access the FTs and then continue with normal
processing manually.

While creating a new Standing Order, System generates the next sequence
number automatically on giving the account number. However, for Balance
Maintenance Standing Order types, the sequence number must always be have
a number of 900 to 999 and for this reason, must be specifically input by the
User.
When the User wants to change an existing Standing Order, it will be
necessary to enter the complete Standing Order reference number which
includes the Account Number and the sequential Standing Order number
separated by a dot.
Generally, the account number used in the Id is the account which is debited.
However, when REV.DR.CR.ACCT Field in the Standing Order is set to 'Y'
(for Standing Orders with FI Type and PAY.METHOD is set as AC), the
Account number specified in the ID will be taken as the Credit Account.
Examples of Standing Order references are:
111112.1 The first Standing Order existing on the Account 111112.
222224.7 The seventh Standing Order existing on the Account 222224.
For an account only one balance maintenance standing order type can be
defined. If we have the balance maintenance standing order for Account
444448 defined as 444448-900 & 444448-901, then 444448.900 will be such
that a minimum balance has been defined below which funds will be
transferred to the Account and 444448.901 will have a maximum balance
defined above which funds will be transferred out of the Account.

Various types of STANDING.ORDER can be indicated in the STO.TYPE.
Some of the standing order types are as under:
BI refers to the account which is to be maintained at a minimum balance.
Transfer from another account will be executed to restore the balance at the
required level. The sequential number will be between 900 to 999 and must be
assigned by the user at input. For Example Customer requests to cover
automatically any overdraft in his current account by debiting his savings
account. In this case, standing order will be defined for the currenct account
and the specified balance will be 0. When the balance goes below 0 an
automatic transfer will then be generated from the savings account to feed the
current account.
BO refers to the account to be maintained at maximum balance. The system
will draw down the excess amount and effect a payment as specified in the
instruction. The abbreviation BO stands for Balance Maintenance out and the
sequential number will be between 900 to 999 and must be assigned by the
user at input. For example 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, say GBP 1,500 an automatic
transfer will be generated for the excess amount of GBP 500 which will be
transferred out of the current account to savings account

Some more type of standing order are :
FI it means that the customer has given instruction to the bank to pay on a
regular basis a fixed amount and debit his account. The amount will be
specified by the customer and in that sense the amount of the standing order is
fixed.
Generally, the account number used in the Id is the account which is debited. It
is 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. For this purpose, REV.DR.CR.ACCT Field in the
Standing Order is set to 'Y' (for Standing Orders with FI Type and
PAY.METHOD is set as AC). Now, the Account number specified in the ID
will be taken as the Credit Account and the account specified in
CPTY.ACCT.NO Field is treated as Debit account.
PP refers to periodic payments where Customer has authorised the bank to pay
bills from the third parties upon presentation of the bills. Amount will vary and
there is no definite frequency. In this case, amount will not be specified but
will hold the beneficiary whose bills are to be paid. Whenever the amount is
input then during the COB process, payment will be made and amount will be
deleted from the STANDING.ORDER record.

Some more types of Standing order are:
OL refers to Operating lease which handles accrual and repayment of lease
rentals in case of lease transaction between customer and Bank. It handles two
type of situations where a bank is lessor and the other situation where a bank is
a lessee.
In the first instance, 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.
In the second instance 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.
ASSET.REGISTER contains the information needed by T24, to be able to link
the assets to a STANDING.ORDER.

Some more types of Standing order are:
RC refers to revolving credit- 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.

DD refers to Direct Debit. The bank can define a direct debit mandate from
the Customer which authorises the bank to accept direct debits received on the
Account. For example 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. Amount is not always
specified for Direct Debits standing order. This type of standing order will be
completely passive in the sense that its sole purpose is to provide the user with
an online retrieval facility of direct debit mandates held by the bank.

Standing orders get executed through FUNDS.TRANSFER application.
Standing orders create a funds transfer record for effecting the transaction.
Hence a transaction type record from FT.TXN.TYPE.CONDITION needs to
be specified in PAY.METHOD in STANDING.ORDER application.
Generally, AC type of transaction is used for Fixed or Periodic type of standing
order.
In the case of Periodic Payment of interest OT type of transaction may be used
for an external transfer.
A Diary type of standing order does not create any transaction in
FUNDS.TRANSFER and hence no input is made into this field.

Currency code for the standing order is given in CURRENCY Field. Input is
not allowed for the Standing Order type DIARY and optional for the Standing
Order type DD and mandatory for the other Standing Order types BI, BO, FI,
PP, BP and PPI. The Currency for Balance maintenance types must be the
same as the Currency of the Standing Order account.
For transaction type AC, the Currency code must be the same as the Currency
of the Account defined in the Beneficiary Account Number field or the
currency of the account of the standing order. In all the circumstances where
the Currency of the Standing Order may differ from the Currency of the
Standing Order account, an override will be required. For the transaction type
OB and OC, the Currency must be equal to the Local Currency while for OT
and OD, if the Currency Code specified is equal to the local currency code, the
Funds Transfer record generated will be placed on hold because these payment
types require a Credit Account number as mandatory.
CURRENT.AMOUNT.BAL specifies the amount of the Standing Order. For
Balance Maintenance Standing Order types, it will define the Balance to be
maintained in the Account and can even be zero.
For the DD Standing Order type, this field is only for information purposes.
For the PP Standing Order type, whenever an amount is input, the payment
will be made on specified day and then delete the amount from the Standing

Order record.

The Standing Order can be executed with a frequency specified in
CURRENT.FREQUENCY up to and including the current end date specified
in the CURRENT.END.DATE. Standard frequency type comprising of date
of first execution and frequency thereafter. This field is mandatory input for
the Standing Order types BI, BO, FI, OL, BP,PP, PPI and DIARY. Optional for
type DD. Not allowed for type PP. Any input made for the Standing Order type
DD will only be for information purposes. 'DAILY' frequency is not allowed
for Standing Order types B1, BO and BP, but BSNSS is allowed to maintain
balance every working day. An override will be required if the date input is a
non-working day and the frequency is 'BSNSS'.
Frequency can also be set up to be processed on the same date as the
repayment frequency in AA. For example if a date of 24Sep2008 is selected as
next date and the frequency is Weekly and on Wednesday of the week, then the
frequency is set as a recurrence pattern.A CURRENT.END.DATE is required
when the bank has received from the Customer instructions which stipulate
that the Standing Order must be executed during a determined period of time.
It is also used when the Customer has requested the bank to pay a certain
amount during a determined period of time and then another amount starting
from that date. In this case, the User will enter in this field the end date of the
first Standing Order amount. After that date the second amount will then be
executed as included in FUT.AMOUNT.BAL, FUT.FREQUENCY and

FUT.END.DATE Fields can be used. These fields can be used to include any number
of instructions provided they are loaded in a chronological order and at any time
without waiting for the expiry of the existing instructions.

Commission details specified in a standing order is collected during Funds
transfer creation. It can be a onetime collection with a date or a frequency as
defined in COMM.FREQUENCY Field of STANDING.ORDER. Frequency
can be specified as date (for one time execution) or date with valid frequency.
If Commission frequency is specified, then it should be same as standing
orders' CURRENT.FREQUENCY. However, the start date of commission can
be different.
For example: If STO’s CURRENT.FREQUENCY is given as
20080101M0101 & COMM.FREQUENCY can be given as 20080401M0101
to indicate charges to be collected from monthly from April, while standing
orders are executed monthly from January.
Commission will be valid till the end date if any specified in the
COMM.END.DATE Field.
Either a commission type from FT.COMMISSION.TYPE can be specified in
COMMISSION.TYPE Field for defaulting values or amount defined with
currency in COMMISSION.AMT as USD 50.00 or GBP 25.50.
CHARGES.ACCT.NO in STANDING.ORDER application can be specified
with the Account Number where the commissions and charges are to be
debited, when Commission and charges are to be collected from a separate
account instead of Debit Account. Account entered here mapped to

CHARGES.ACCT.NO Field in FUNDS.TRANSFER Application

Processing date rules can be set in FT.APPL.DEFAULT by using
STO.PROCESS.GAP Field.
For example : +01W-01C means Last day before next working day
These rules are NOT applicable for balance maintenance types and for those
STOs for whom rules are set using DATE.ADJUSTMENT Field at STO
level.
A local clearing Holiday table may be considered for processing of STOs by

using the Bus Day Defn field. This field has been introduced in R13 at the
Standing Order Level such that each STO refers to this field to decide which
Holiday setup it should consider for processing. Whenever a value which is a
valid Region or Holiday record is defined in the Bus Day Defn field, System
will process the STO according to the holiday setup defined for that region. If
the BUS.DAY.DEFN field is null, then the processing will happen as per the
Official Holiday setup

DATE.ADJUSTMENT Field on a STANDING.ORDER helps define when a standing order is
to be processed, if scheduled date falls on a non-working day.
“Null” is used for standard processing. Processed on the execution date (as set in the
CURRENT.FREQUENCY field) unless that is a non-working day, in which case it is
processed on the next working day. Subject to amendment, if STO.PROCESS.GAP Field in
FT.APPL.DEFAULT is set
If the DATE.ADJUSTMENT Field is selected as FOLLOWING it is processed on the next
working day.
The value PRECEDING means it is processed on the previous working day.
MODIFIED means STO is processed on the following working day unless the next working
day falls in the next month, in which case it is processed on the previous working day.
E.g. If date falls on a Saturday, which is a holiday, it will be processed on Monday,(next
working day) unless Monday is in a different month to Saturday, in which case it will be
processed on working day preceding Saturday.)
From R13, we have an option Mbackward in the Date Adjustment field, allowing STO to
process on the previous working day within the same month. In case if the previous day falls
on the previous month then the STO will be processed during the next working day of the
same month.
For example, The business day definition for the defined region has 05 Jan 2011 as holiday.
Date Adj as Mbackward with processing date on 5th Jan will be processed on 4th Jan as the
STO will take the previous working day for processing.
Likewise, The business day definition for the region has 01 Jan 2011 as holiday. If the
Processing date for the STO will not process the same on the previous day which is 31st Dec
as it results in a cross month scenario but will process on 4th Jan which is the next working

day within the same month.

EXECUTION.STAGE field in STANDING.ORDER application defines the COB stage at which the
STANDING.ORDER will get picked up for processing. This field accepts values SOD, EOD or
None.' None' option would use the default processing time pre-defined for each of the type
of STANDING.ORDER. For FI/BP type of STANDING.ORDER's which are usually processed
during START.OF.DAY (SOD) it is now possible to set the EXECUTION.STAGE to EOD. Similarly
for BO/BI type of STANDING.ORDER's that are usually processed during END.OF.DAY (EOD), it
is now possible to set the EXECUTION.STAGE to SOD. The STANDING.ORDER's will now get
picked up for processing based on the date and then by the EXECUTION.STAGE as defined in
the STANDING.ORDER.
The EXECUTION.STAGE can be changed at any point of time during the lifetime of the
STANDING.ORDER. System ensures the changes to frequency date are made from the next
frequency date.
While changing the EXECUTION.STAGE from blank to ‘SOD’ or ‘SOD’ to blank for BO/BI type
STO’s and the CURRENT. FREQUENCY falls on the same day, system throws validation error to
change the frequency. While changing the EXECUTION.STAGE from blank to ‘EOD’ or ‘EOD’ to
blank for remaining type STO’s and the CURRENT.FREQUENCY falls on the same day, system
throws a validation error to change the frequency.
For a STANDING.ORDER which will get processed by default during SOD, it is not possible to
set the same as the EXECUTION.STAGE and vice versa for a STANDING.ORDER that will get
processed during EOD.
The record id in concat file STO.FREQ.DATE is updated in the format
FREQUENCY.DATE*STO.ID*EXECUTION.STAGE
Remember : The child STANDING.ORDER's created for resubmission purposes will follow the
EXECUTION.STAGE set at the parent STANDING.ORDER.

From R14,
A Percentage value for Balance Out type STOs to arrive at the transfer amount,
meaning the percentage of excess amount that needs to be transferred during
the execution of the Standing Order to the Counter-party Account. As a result,
during execution of BO STO, this percentage is applied on the excess amount
that needs to be transferred.
PER.OVER.CAB - Percentage value to arrive at the Transfer amount :- Is
Non Mandatory - Applicable only for BO type STOs - Accepts 3 digit non-
negative numeric value between 1 and 100.
For instance, PER.OVER.CAB is set at 25%, 75% is retained in the account
and 25% is transferred in a BO STO.
Priority Number in Standing Order is useful to define the order of execution

of the FI type STOs held by a Customer Account, which has the same
execution date. During Batch process, the STOs for the particular Account are
processed by the order of the Priority Number defined in the STO
For FI type STOs, System raises ‘F’ entries to block funds for the next
frequency of the STO. In case an account has more than one FI type STO for a
frequency each STO will raise ‘F’ entry to block funds. While processing the
STOs as per the given priority order even if the Working Balance of the
account is sufficient to accommodate the current STO, due to lack of Available

Balance, override will get generated as a result of which the FT will be put on Hold.
In the same manner all the STOs to be processed will get the ‘Available Balance
overdraft’ override because of the other STOs and all FTs generated will be put on
HOLD.
As the above process contradicts the set up of Priority for an FI type STO a set up in
the EB.AF.PARAM.CHANGE needs to be done to disable the generation of Override
which puts the FT on hold in case of lack of Available Balance in the Account. This
set up would facilitate the STOs to be processed as per the Priority set in the Account
even in case of partial Available Balance.
PRIORITY.NUMBER - Is Non Mandatory, Applicable only for FI type STOs, Accepts

numeric value between 1 and 100, Can be removed during the Life of the STO, Not
applicable for Retry STOs.

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 should
be noted that before setting the system to use value dated accounting, care
should be taken to ensure that there are no forward entries in the system. Once
value dated accounting is switched on, it cannot be reversed.
DAYS.DELIVERY includes the number of working days to be added onto the
current processing date of STO to arrive at the value date for the Funds
Transfer record that will be created by it. This value date is defaulted by
System into the field FT.DEBIT.VAL.DATE in STO and is then used to match
against value dated balances on the account record in order to use the
appropriate balance for standing order calculations. If left blank then the
FT.DEBIT.VAL.DATE is also left blank and the ONLINE.CLEARED.BAL
will be used.
When ACCOUNT.PARAMETER is set to value dated accounting, then
VALUE.DATED.BAL in STO can be set as Yes to enable this functionality.
If set to yes then the system will try to match the FT DEBIT VALUE DATE on
the standing order with a value date on the account record. Where possible the
corresponding value dated balance is used if there is no match then the last
value dated balance will be used. If none are present, then the
ONLINE.CLEARED.BAL on the account record is used.

When ever two different currencies are involved, in a STO, the exchange rate
can be indicated in STANDING.ORDER application by defining
CUSTOMER.RATE or TREASURY.RATE and CUSTOMER.SPREAD. Then
these rates will get defaulted in the FT application.
SETTLEMENT.MARKET and CONVERSION.TYPE can also be defined in a
STO to apply the appropriate exchange rate for the currency market.
On authorising a STO defined with currency market and conversion type, a
new record is created by System in SETTLEMENT.RATES with Standing
Order Id.
If PROTECTION.CLAUSE Field is flagged to YES in
SETTLEMENT.RATES, the system derived exchange rate for the event date
for a particular currency would be compared with historic exchange rates
applied for the currency and the best exchange rate (either current day's rate or
one of the historic rates, whichever is more beneficial to the Bank) would be
considered for liquidation.
If the field is flagged to NO, then either the user input exchange rate in
EV.APPL.RATE or the system derived rate (for no input by user) would be
used for liquidation.

In the case of fixed STO.TYPE, the customer’s account will be periodically
credited with a fixed amount. The account specified in the record ID is treated
as the debit or credit account. To project the cash flows for the
internal/customer accounts in STANDING.ORDER, forward entries are raised
from standing order for the next execution date. On input of a new standing
order with STO.TYPE as FI, forward entries are raised for the
customers/internal account involved in the STO, with value date as next
execution date mentioned in first component of CURRENT.FREQUENCY
and the amount given in CURRENT.AMOUNT.BAL. When STO is cycled to
the next frequency date, forward entries are raised with the value date as next
frequency date. The value date and the amount given in the STO are updated
in available date and Dr/Cr movement related fields in accounts, so as to track
the cash flows. The balances are updated for the period setup in
CASH.FLOW.DAYS in ACCOUNT.PARAMETER.

STO.BULK.CODE is the table which holds specific details on the most
frequently used Standing Orders.
If, for example, many customers have given the bank Standing Order
instructions in favour of the same beneficiary, for example the annual
subscription to the AA (Automobile association) or RAC(Royal automobile
Club) , then these common beneficiaries and details are set in
STO.BULK.CODE to avoid the repetitive input and the risk of error in
specifying the content of four fields in each Standing Order record. Id of this
record input in BULK.CODE.NO field of the STANDING.ORDER record
will then be sufficient to automatically generate the value of these four data
elements BENEFICIARY, BEN.ACCT.NO, ACCT.WITH.BANK and
BANK.SORT.CODE Fields.
In STO.BULK.CODE, BENEFICIARY and BENEFICIARY.ACCT.NO holds
the beneficiary name and address with the account number. Further,
ACCT.WITH.BANK identifies the Bank where the Beneficiary maintains his
Account. For BACS payments, this field will define the bank to whom
payment is to be made and is only used for Standing Order statement purposes
to print the name of the bank and branch to whom payment is to be made.
BANK.SORT.CODE, defines the Bank Sorting Code of the bank and branch to
whom the payment is to be sent. It is only applicable to the BACS payments.
This table is not mandatory to run the Standing Order Application.

If a Standing Order fails due to insufficient funds, the associated funds transfer
record generated is placed on hold status pending manual intervention.
Standing Orders can be set for automatic resubmission. Two methods exist to
retry up to maximum of 10 days either during the Close of Business batch
processing or online at set time intervals during the day as a phantom process.
These methods can be combined to create a continuous retry process that runs
all day every day until funds become available or until the limit of 10 days is
reached.
Daily resubmission is enabled in FT.APPL.DEFAULT, entering a value for the
number of days in NO.RESUBMSSN.DAYS, by specifying
RETRY.START.TIME and RETRY.END.TIME in a 24-hour clock notation, in
FT.APPL.DEFAULT, for enabling online resubmission.
To start the online process the EB.SO.RETRY.CHECK record in
EB.PHANTOM needs to be verified. This record contains the field parameter
SLEEP.SECS to allow the user to indicate a time interval in seconds between
retry attempts. For example, to retry failed Standing Orders every hour enter
an interval of 3600 seconds.
When the retry limit has reached the stipulated no of resubmission days and
failed in auto-resubmission then the FT record is put on hold, a delivery
advice message as defined in SO.MESSAGE.TYPE Field in

FT.APPL.DFAULT is generated

In addition to STANDING.ORDER, which is used for single standing orders,
there is another application called BULK.STO which is used when an account
is debited with a single payment and the credit is given to multiple accounts.
The Id can be Account No followed by automatically generated sequence or
Account no with date separated by "-" and an automatically generated
sequence. If the Id is given with a date then it will consider as a single
payment type of Bulk STO and the date from Id will be defaulted to single
payment date. Date component in Id has to be greater than the input date . For
a frequency based Bulk Standing order, the Id has to be created with account
no followed by automatically generated sequence number.
Hence for a same account using the sequence no, more than one Bulk Standing
Orders can be created.
When the User wants to change an existing Bulk Standing Order, it will be
necessary to enter the complete reference number i.e. the Account Number and
the sequential Bulk Standing Order number separated by a . (dot) or Account
number with date separated by "-" and "." sequential no.
Only Fixed Payment type of Standing orders with known amount can be input.
Using SINGLE.PAYMENT Field one off payment can be input or a frequency
furnished in CURRENT.FREQUENCY. This feature can be used for monthly
payment of salary to staff.

Usually BULK.STO records are processed during COB processing but if
required they can be effected on-line using the SINGLE.BULK.STO
application.
SINGLE.BULK.STO is the application which allows more than one
BULK.STOs to be executed online. After giving an alphanumeric Id, details of
BULK.STO records need to be specified in BULK.ORDER.IDS Field. Only
such Bulk order Ids can be specified which have their SINGLE.PAYMENT
Field set as YES and date in SINGLE.PYMNT.DATE is less than or equal to
date of execution. When the record in SINGLE.BULK.STO is verified,
suitable FTs are created for effecting the standing orders.

FT.BULK.CREDIT is used for handling single credit with multiple debit
situations. This application is very similar to that of BULK.STO, which
enables the user to handle single debit with multiple credits. The Id for the
FT.BULK.CREDIT is the credit account. The debit currencies should also be
in the same currency as that of the credit currency. It is possible either to
execute as one-off payment or with an associated frequency by using
SINGLE.PAYMENT and CURRENT.FREQUENCY Fields.
If SINGLE.PAYMENT is set as NO , then a frequency has to be defined in
CURRENT.FREQUENCY field. This field identifies the current frequency of
the Bulk Standing Order for the total amount specified in
TOTAL.CREDIT.AMOUNT. The Bulk Standing Order application will
execute the standing order instruction according to the frequency specified in
CURRENT.FREQUENCY Field up to and including the
CURRENT.END.DATE Field.
In SINGLE.PAYMENT if it set as YES, then it will be treated as one off
transaction, in which case the date has to be specified in the field called
SINGLE.PYMNT.DATE Field.
This is applicable only for AC & IT types of transaction.
Generally application is updated during COB but online process can be
initiated using SINGLE.INWARD.BULK.

When Diary type of Standing order is created, STO.PAYMENTS program will
automatically update an internal file called STO.DIARY, which can be
reviewed periodically. Any Diary item will remain in the list until a positive
action has been taken by the user. Whenever the frequency date of the Diary
standing order has been reached, System keeps track of Diary text, Ordering
Customer and Department identification The Diary type of Standing order can
be reviewed using an online enquiry or attaching the enquiry in the Close of
Business process, which will give a list of diary items, where the action is to
be taken.
It is also possible that the user can request an on-line print or displays on this
STO.DIARY file. To do this online print, the user has to select the verify
button in the screen on any of the Diary instruction, where a user is expected
to take some action. Functions that will be provided to the users are list and
see function. Once the frequency date has reached the user will be able to list
all the Diary instruction.

Once sufficient approval is given, all payments within a file are automatically
processed.

Upload of files
Create a mechanism through which a file can be transferred, through HTTPS,
onto the T24 server Should be generic enough to allow all types of files – not
just data files (e.g csv) but any file – including a jpg or .doc. This will enable a
corporate user, through their internet portal, to upload a file of payments to the
bank for processing
Processing of files
Create a mechanism whereby uploaded files can be processed, to create T24
entries. While sufficient for the requirements of Bulk Payments, the processing
mechanism should be sufficiently generic to allow the creation of any records
within T24 This mechanism will create a header record, and multiple item
records. It has a flexible structure, using Version, to provide mapping and
defaulting.
Payment of Multiple Credits
Allow corporate customers to use the Generic processing functionality above
to upload a single data record, which may contain multiple payments, to
recipients within and outside T24 bank. Upon Mandate approval, payments are
automatically processed on behalf of the corporate user. Forward processing
dates may be specified.
Override/Limit checking applied to sum amount of payments – where

insufficient funds available, warning overrides generated. During payments,
insufficient funds may result in payments being blocked, in accordance with standard
security settings. Funds transfers generated to handle payments – and charges – in
accordance with specified FT.TXN.TYPE.CONDITIONs
Either single or multiple payments posted to the corporate account, with appropriate
value & exposure dates (use of a wash account when only single debit required).
Claim of Multiple Debits
Allow corporate customers to upload a file of direct debit claims, to debtors within
and outside T24 Only approved customers may claim direct debits
Single or multiple credits may be specified on the corporate account.
Mandate approval required before any claims may be sent out.
Funds Transfers generated to handle receipts
System can generate charges for both payer and recipient, in accordance with
FT.TXN.TYPE.CONDITIONs defined for that set of transactions
Internet Banking Payments
Allow retail internet banking customers to create a ‘shopping trolley’ of
payments.Running balance maintained, indicating customer’s available funds when
payment is instructed. Single click then processes multiple payments
A front end user can refer to ARC IB module on Bulk Processing for further details.

Bulk debits (e.g claiming of direct debits) – the system will convert
BULK.ITEM records into DD.ITEM records. An enhancement will be done to
DD.ITEM functionality, so that it does not require a DD.DDI record in order to
be created.
Upon creation of the DD.ITEM record, processing will continue in line with
existing Direct Debit functionality, to either debit the T24 account (if present)
or to raise a clearing entry, to be handled through the clearing entry file.
Credit will be posted to the corporate account. When returns occur from
clearing, the Corporate account will be debited to reflect this, with a value date
equal to the processing date.
As there is a degree of trust required from the bank, to ensure that bogus debits
are not claimed & funds then removed, an attribute will be added to the
customer’s record, to indicate that they are authorised to process Direct Debit
claims.

Bulk Credits (e.g processing of payroll) – the system converts BULK.ITEM
records into individual FUNDS.TRANSFER records, either debiting the
corporate account (where the customer has indicated they wish for multiple
debits to the corporate account) or a wash account, which will in turn debit the
corporate account, when the customer has specified that they only wish for a
single debit to their account.
The credit side of the FUNDS.TRANSFER involves the crediting of the payee.
This is likely to be an account outside of T24 – in which case, the
corresponding bank will be specified with appropriate instructions in the
BEN.ACCT.NO field. Funds transfer will then handle the required
functionality for generating clearing/swift entries.
Returns will re-credit the Corporate Account, with a value date equal to the
processing date.
When FTs are generated as a result of bulk credits being issued, they will
inherit the signatories from the bulk master record. As a result, it is important
to ensure there is no minimum amount that these signatories can approve –
otherwise they may be able to approve the batch, but individual items may
then be rejected for being too low.

Here, we are considering a bulk credit processing situation where the bulk
items contain beneficiaries information. So the parameter setup contains
beneficiary upload details.

Important fields in FT.BULK.UPDATE.TYPE
ACTIVE.PASSIVE.EXT
Transaction type used to handle transfer funds from ACTIVE account given in
FT.BULK.MASTER to NON T24’s PASSIVE account given in
FT.BULK.ITEM
Transaction type given here will be overridden when
FT.BLK.IT.TRANSACTION.TYPE is provided at FT.BULK.ITEM level
Mandatory for MULTI
Should be a Valid record in FT.TXN.TYPE.CONDITION
ACTIVE.PASSIVE.INT
This field holds the Transaction type used to handle transfer of funds from
ACTIVE account given in FT.BULK.MASTER to T24’s PASSIVE account
given in FT.BULK.ITEM
Used only for CREDIT processing

Mandatory for MULTI
BULK.TYPE.ID
Name of Bulk Update type.
Alphanumeric characters are allowed. Id should be meaningful, so that it reflects the
mode of bulk process (SINGLE or MULTI)
DD.PARAM.ID
A valid DD.PARAMETER id is given for DIRECT.DEBIT processing.
Not mandatory.
DESCRIPTION Free text field, which hold the information about bulk update type
Mandatory field
Text upto 35 characters of type A can be given
MODE.OF.TRANSFER
Holds the mode of transfer to be used in the payment process
Reserved for Future Use
PROCESSING.DAYS
Number of Working or Calendar days to be added with Today is given here. This will
be defaulted in FT.BULK.MASTER’s PROCESSING.DATE field.
This value can be overridden at Bulk Master Level
Values like 1C, 2W, etc are allowed
Mandatory Input
SINGLE.MULTI
Mode of Bulk update type is given.
SINGLE :
CREDIT - Initially funds are transferred from Active account to Wash account. And
then each Passive account given in FT.BULK.ITEM is credited from the Wash
account

DEBIT – Initially funds are transferred from each Passive account given in
FT.BULK.ITEM to Wash account. And then Active account in FT.BULK.MASTER is
credited from Wash account
MULTI :
CREDIT - Every time Passive account given in FT.BULK.ITEM is credited from the
Active account
DEBIT - Every time Active account is credited from the Passive account given in
FT.BULK.ITEM
The value given in this field can be overridden at Bulk Master Level
Mandatory Input
Only SINGLE or MULTI is allowed
VERSION
A version of Application, which will be used to do payment through OFS in Payment
process
Currently restricted to use FT version for Credit upload processing.
Mandatory Input
Valid record in VERSION
WASH.ACTIVE Holds Transaction type used to handle transfer funds between
ACTIVE and WASH account
Used for both DEBIT and CREDIT processing
Mandatory for SINGLE type
WASH.PASSIVE.EXT
Transaction type used to handle transfer funds from WASH account given in
FT.BULK.MASTER to NON T24’s PASSIVE account given in FT.BULK.ITEM

Mandatory for SINGLE
WASH.PASSIVE.INT
Transaction type used to handle transfer funds from WASH account given in
FT.BULK.MASTER to T24’s PASSIVE account given in FT.BULK.ITEM
Mandatory for SINGLE type

FT.BULK.MASTER holds all the header information of a Bulk upload. The
Bulk Master file controls the authorisation of all the items. The Bulk Master
file controls the authorisation of all the items. It maintains a running total of all
the items involved in the batch.
The FT.BULK.MASTER application processes bulk upload of credit and debit

payments. This can either be uploaded thru generic upload interface thru ARC
or can be uploaded manually.
This application holds all the header information of a Bulk upload.
FT.BULK.MASTER record contains fields to hold TOTAL.AMOUNT,

VALUE.ITEMS.ERR, VALUE.VALID.ITEMS and TOT.EXTERN.ITEM
values all depending on the FT.BULK.ITEM records attached with that bulk
master record.
According to the STATUS and REQUEST.TYPE of the FT.BULK.ITEM

record, the corresponding AMOUNT field value will represent any of the
above mentioned amount fields of FT.BULK.MASTER.
After creation of Master as unauthorized, the relevant individual payments can

be created or uploaded thru FT.BULK.ITEM application.
When the FT.BULK.MASTER is SINGLE, the AMOUNT in each processed

FT.BULK.ITEM record will get credited to the WASH.ACCOUNT from where the
final amount will be swept into ACTIVE.ACCOUNT using FT transaction.
Payment process is triggered on the PROCESSING.DATE of the FT.BULK.MASTER

either manually through running a service or as a COB job.

Each item must reference a bulk master. When each item is entered, or
amended, this updates the running totals which are stored on the Bulk master.
Items will include information such as the destination account, and amount.
Items may also indicate the payment type to be used (eg BACS or CHAPS),
which will be translated to different FT.TXN.TYPE.CONDITION records on
the ultimately generated FT.
Running totals include total valid amount, and total amount including invalid
items, are stored and updated on the bulk header. The users will be able to
amend any items, including invalid items, before the bulk is authorised –
which updates the bulk header totals accordingly.
Therefore, the Bulk Master will contain a total for the amount that a corporate
customer will be debited/credited, upon approval. It is possible to approve a
batch without all items being in a valid status – in this case, the invalid items
will not be processed.

The clerk uploads the file.
Run service – T24.UPLOAD.PROCESS
The data in the file will be used to create records in T24. The file contains data
in a format that has to match with the fields values in the application in which
you need to create records.
The clerk/ admin validates the master record; A warning message is generated
if there are insufficient funds, but it will not stop the process
The master moves to INAU
The authorized signatory logs in
Authorizes the master record
Run service – FT.BULK.PAYMENT
Individual FT records are created
FTs are created once the processing date is reached. There is an option to
authorize the payment as well
For more information: refer to ARC IB – Bulk Processing

We are now going to see the creation of bulk master.
User Menu -> Payments Services ->Bulk Payments -> FT Bulk Master
Creation -> Input Bulk Master Details
Now select “New Task”

Here, we consider the situation of Bulk credit processing.
Suppose the corporate customer wishes make payment for monthly expenses,
it will generate multiple credits. The customer is particular about having only a
single debit against the accounts for the bulk credit payments. Hence, the
Single Multi flag is set to ‘Single’
As the corporate customer requires a single payment to the ‘active’ account, a
‘wash account’ is required, to net all the payments and pass a single payment
to the ‘active’ account.
Once the Bulk Items are created, the user should also update the status as
‘Ready’.

Once the master is in place, the individual items within the master can be
entered. We use menu option.
Goto: User Menu -> Payment Services -> Bulk Payments -> FT Bulk Items ->
Input FT Bulk Item
To enter a bulk item, the user must enter the Bulk Master Id

T24 automatically launches a unique ID linked to the Bulk Master in which
relevant details for the payee can be entered.
Data such as Value Date, status are defaulted when the item is validated.
Once the first item is committed, the user can continue to add additional items
using the same BULK.MASTER @ID.
There is no limit to the number of items that can be added.

Once the Bulk Master and the Bulk Items have been created. A different user
can authorise the bulk master. This will create a single debit to the customer
and multiple FTs (DD items are created in case of bulk debit processing) are
created for making the credit transfers.


T3TFT - Funds Transfer - R14 PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

T3TFT - Funds Transfer - R14 PDF

Caricato da

Copyright:

Formati disponibili

T3TFT – Funds Transfer - R14 1

FUNDS.TRANSFER is one of the account based applications in T24 for

T3TFT – Funds Transfer - R14 2

T3TFT – Funds Transfer - R14 3

T3TFT – Funds Transfer - R14 4

T3TFT – Funds Transfer - R14 5

T3TFT – Funds Transfer - R14 6

T3TFT – Funds Transfer - R14 6

T3TFT – Funds Transfer - R14 7

T3TFT – Funds Transfer - R14 8

T3TFT – Funds Transfer - R14 8

T3TFT – Funds Transfer - R14 9

T3TFT – Funds Transfer - R14 10

T3TFT – Funds Transfer - R14 11

T3TFT – Funds Transfer - R14 12

T3TFT – Funds Transfer - R14 13

T3TFT – Funds Transfer - R14 14

T3TFT – Funds Transfer - R14 18

T3TFT – Funds Transfer - R14 19

T3TFT – Funds Transfer - R14 20

T3TFT – Funds Transfer - R14 21

T3TFT – Funds Transfer - R14 22

T3TFT – Funds Transfer - R14 23

T3TFT – Funds Transfer - R14 24

T3TFT – Funds Transfer - R14 25

T3TFT – Funds Transfer - R14 26

T3TFT – Funds Transfer - R14 27

T3TFT – Funds Transfer - R14 27

T3TFT – Funds Transfer - R14 28

T3TFT – Funds Transfer - R14 28

T3TFT – Funds Transfer - R14 29

T3TFT – Funds Transfer - R14 30

T3TFT – Funds Transfer - R14 31

T3TFT – Funds Transfer - R14 32

T3TFT – Funds Transfer - R14 32

T3TFT – Funds Transfer - R14 33

T3TFT – Funds Transfer - R14 34

T3TFT – Funds Transfer - R14 35

T3TFT – Funds Transfer - R14 36

T3TFT – Funds Transfer - R14 37

T3TFT – Funds Transfer - R14 38

T3TFT – Funds Transfer - R14 39

T3TFT – Funds Transfer - R14 40

T3TFT – Funds Transfer - R14 41

T3TFT – Funds Transfer - R14 42

T3TFT – Funds Transfer - R14 43

T3TFT – Funds Transfer - R14 44

T3TFT – Funds Transfer - R14 45

T3TFT – Funds Transfer - R14 46

T3TFT – Funds Transfer - R14 47

T3TFT – Funds Transfer - R14 50

T3TFT – Funds Transfer - R14 51

T3TFT – Funds Transfer - R14 52

T3TFT – Funds Transfer - R14 53

T3TFT – Funds Transfer - R14 54

T3TFT – Funds Transfer - R14 55

T3TFT – Funds Transfer - R14 56

T3TFT – Funds Transfer - R14 57

T3TFT – Funds Transfer - R14 57

T3TFT – Funds Transfer - R14 58

T3TFT – Funds Transfer - R14 59

T3TFT – Funds Transfer - R14 60