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.

T3TFT – Funds Transfer - R14

2

FUNDS.TRANSFER is one of the account based applications in T24 for 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.

T3TFT – Funds Transfer - R14

3

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.

T3TFT – Funds Transfer - R14

4

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.

T3TFT – Funds Transfer - R14

5

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.

T3TFT – Funds Transfer - R14

6

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

T3TFT – Funds Transfer - R14

6

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.

T3TFT – Funds Transfer - R14

7

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

T3TFT – Funds Transfer - R14

8

defaults into CHARGES.ACCT.NO Field in FT

T3TFT – Funds Transfer - R14

8

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.

T3TFT – Funds Transfer - R14

9

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.

T3TFT – Funds Transfer - R14

10

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.

T3TFT – Funds Transfer - R14

11

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.

T3TFT – Funds Transfer - R14

12

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.

T3TFT – Funds Transfer - R14

13

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.

T3TFT – Funds Transfer - R14

14

T3TFT – Funds Transfer - R14

15

T3TFT – Funds Transfer - R14

16

T3TFT – Funds Transfer - R14

17

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.

T3TFT – Funds Transfer - R14

18

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.

T3TFT – Funds Transfer - R14

19

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.

T3TFT – Funds Transfer - R14

20

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.

T3TFT – Funds Transfer - R14

21

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.

T3TFT – Funds Transfer - R14

22

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.

T3TFT – Funds Transfer - R14

23

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.

T3TFT – Funds Transfer - R14

24

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.

T3TFT – Funds Transfer - R14

25

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.

T3TFT – Funds Transfer - R14

26

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

T3TFT – Funds Transfer - R14

27

will receive the same Value Date.

T3TFT – Funds Transfer - R14

27

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

T3TFT – Funds Transfer - R14

28

and INTERMED.BANK

T3TFT – Funds Transfer - R14

28

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

T3TFT – Funds Transfer - R14

29

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.

T3TFT – Funds Transfer - R14

30

A bank may like to effect transfers between two of its own Nostro accounts or transfer from its Nostro to some other account. Accordingly message generation has to be 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.

T3TFT – Funds Transfer - R14

31

By suitable setup in FT.TXN.TYPE.CONDITION , it is possible to generate different types of swift messages in FUNDS.TRANSFER application. 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. MT200/202 can be used for financial institution transfer by setting 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

T3TFT – Funds Transfer - R14

32

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

T3TFT – Funds Transfer - R14

32

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.

T3TFT – Funds Transfer - R14

33

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.

T3TFT – Funds Transfer - R14

34

By suitable setup in FT.TXN.TYPE.CONDITION , it is possible to generate different types of swift messages in FUNDS.TRANSFER application. 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.

T3TFT – Funds Transfer - R14

35

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. 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

T3TFT – Funds Transfer - R14

36

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.

T3TFT – Funds Transfer - R14

37

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.

T3TFT – Funds Transfer - R14

38

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.

T3TFT – Funds Transfer - R14

39

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.

T3TFT – Funds Transfer - R14

40

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

T3TFT – Funds Transfer - R14

41

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

T3TFT – Funds Transfer - R14

42

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.

T3TFT – Funds Transfer - R14

43

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

T3TFT – Funds Transfer - R14

44

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.

T3TFT – Funds Transfer - R14

45

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.

T3TFT – Funds Transfer - R14

46

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.

T3TFT – Funds Transfer - R14

47

T3TFT – Funds Transfer - R14

48

T3TFT – Funds Transfer - R14

49

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.

T3TFT – Funds Transfer - R14

50

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.

T3TFT – Funds Transfer - R14

51

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.

T3TFT – Funds Transfer - R14

52

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 NoFT.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)

T3TFT – Funds Transfer - R14

53

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.

T3TFT – Funds Transfer - R14

54

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.

T3TFT – Funds Transfer - R14

55

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.

T3TFT – Funds Transfer - R14

56

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

T3TFT – Funds Transfer - R14

57

claim the difference GBP 3.00 from local authorities.

T3TFT – Funds Transfer - R14

57

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.

T3TFT – Funds Transfer - R14

58

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.

T3TFT – Funds Transfer - R14

59

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.

T3TFT – Funds Transfer - R14

60

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.

T3TFT – Funds Transfer - R14

61

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.

T3TFT – Funds Transfer - R14

62

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.

T3TFT – Funds Transfer - R14

63

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

T3TFT – Funds Transfer - R14

64

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.

T3TFT – Funds Transfer - R14

65

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.

T3TFT – Funds Transfer - R14

66

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.

T3TFT – Funds Transfer - R14

67

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.

T3TFT – Funds Transfer - R14

68

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.

T3TFT – Funds Transfer - R14

69

T3TFT – Funds Transfer - R14

70

T3TFT – Funds Transfer - R14

71

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

T3TFT – Funds Transfer - R14

72

USD 195 as commission for that customer.

T3TFT – Funds Transfer - R14

72

T3TFT – Funds Transfer - R14

73

T3TFT – Funds Transfer - R14

74

T3TFT – Funds Transfer - R14

75

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- instead of the group Id.

T3TFT – Funds Transfer - R14

76

T3TFT – Funds Transfer - R14

77

T3TFT – Funds Transfer - R14

78

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.

T3TFT – Funds Transfer - R14

79

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.

T3TFT – Funds Transfer - R14

80

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.

T3TFT – Funds Transfer - R14

81

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

T3TFT – Funds Transfer - R14

82

T3TFT – Funds Transfer - R14

83

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.

T3TFT – Funds Transfer - R14

84

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.

T3TFT – Funds Transfer - R14

85

T3TFT – Funds Transfer - R14

86

FUNDS.TRANSFER is one of the account based applications in T24 for 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.

T3TFT – Funds Transfer - R14

87

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.

T3TFT – Funds Transfer - R14

88

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.

T3TFT – Funds Transfer - R14

89

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.

T3TFT – Funds Transfer - R14

90

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.

T3TFT – Funds Transfer - R14

91

T3TFT – Funds Transfer - R14

92

T3TFT – Funds Transfer - R14

93

T3TFT – Funds Transfer - R14

94

T3TFT – Funds Transfer - R14

95

T3TFT – Funds Transfer - R14

96

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.

T3TFT – Funds Transfer - R14

97

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.

T3TFT – Funds Transfer - R14

98

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.

T3TFT – Funds Transfer - R14

99

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.

T3TFT – Funds Transfer - R14

100

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.

T3TFT – Funds Transfer - R14

101

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

T3TFT – Funds Transfer - R14

102

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

T3TFT – Funds Transfer - R14

102

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.

T3TFT – Funds Transfer - R14

103

T3TFT – Funds Transfer - R14

104

T3TFT – Funds Transfer - R14

105

T3TFT – Funds Transfer - R14

106

T3TFT – Funds Transfer - R14

107

T3TFT – Funds Transfer - R14

108

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.

T3TFT – Funds Transfer - R14

109

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.

T3TFT – Funds Transfer - R14

110

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.

T3TFT – Funds Transfer - R14

111

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.

T3TFT – Funds Transfer - R14

112

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.

T3TFT – Funds Transfer - R14

113

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.

T3TFT – Funds Transfer - R14

114

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.

T3TFT – Funds Transfer - R14

115

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.

T3TFT – Funds Transfer - R14

116

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 followingIf 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.

T3TFT – Funds Transfer - R14

117

T3TFT – Funds Transfer - R14

117

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.

T3TFT – Funds Transfer - R14

118

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.

T3TFT – Funds Transfer - R14

119

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 .

T3TFT – Funds Transfer - R14

120

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.

T3TFT – Funds Transfer - R14

121

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.

T3TFT – Funds Transfer - R14

122

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.

T3TFT – Funds Transfer - R14

123

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

T3TFT – Funds Transfer - R14

124

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.

T3TFT – Funds Transfer - R14

125

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.

T3TFT – Funds Transfer - R14

126

T3TFT – Funds Transfer - R14

127

T3TFT – Funds Transfer - R14

128

T3TFT – Funds Transfer - R14

129

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.

T3TFT – Funds Transfer - R14

130

T3TFT – Funds Transfer - R14

131

T3TFT – Funds Transfer - R14

132

T3TFT – Funds Transfer - R14

133

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.

T3TFT – Funds Transfer - R14

134

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.

T3TFT – Funds Transfer - R14

135

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.

T3TFT – Funds Transfer - R14

136

T3TFT – Funds Transfer - R14

137

T3TFT – Funds Transfer - R14

138

T3TFT – Funds Transfer - R14

139

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.

T3TFT – Funds Transfer - R14

140

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.

T3TFT – Funds Transfer - R14

141

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.

T3TFT – Funds Transfer - R14

142

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.

T3TFT – Funds Transfer - R14

143

T3TFT – Funds Transfer - R14

144

T3TFT – Funds Transfer - R14

145

T3TFT – Funds Transfer - R14

146

T3TFT – Funds Transfer - R14

147

T3TFT – Funds Transfer - R14

148

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

T3TFT – Funds Transfer - R14

149

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.

T3TFT – Funds Transfer - R14

150

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.

T3TFT – Funds Transfer - R14

151

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.

T3TFT – Funds Transfer - R14

152

T3TFT – Funds Transfer - R14

153

T3TFT – Funds Transfer - R14

154

T3TFT – Funds Transfer - R14

155

T3TFT – Funds Transfer - R14

156

T3TFT – Funds Transfer - R14

157

T3TFT – Funds Transfer - R14

158

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

T3TFT – Funds Transfer - R14

159

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

T3TFT – Funds Transfer - R14

159

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

T3TFT – Funds Transfer - R14

160

matched again with another receipt.

T3TFT – Funds Transfer - R14

160

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.

T3TFT – Funds Transfer - R14

161

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.

T3TFT – Funds Transfer - R14

162

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.

T3TFT – Funds Transfer - R14

163

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”).

T3TFT – Funds Transfer - R14

164

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-

T3TFT – Funds Transfer - R14

165

Matched” status.

T3TFT – Funds Transfer - R14

165

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)

T3TFT – Funds Transfer - R14

166

T3TFT – Funds Transfer - R14

167

T3TFT – Funds Transfer - R14

168

T3TFT – Funds Transfer - R14

169

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

T3TFT – Funds Transfer - R14

170

CURRENCY table) will be added to the Treasury rate.

T3TFT – Funds Transfer - R14

170

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.

T3TFT – Funds Transfer - R14

171

By suitable setup in FT.TXN.TYPE.CONDITION , it is possible to generate different types of swift messages in FUNDS.TRANSFER application. 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 MT200/202 can be used for financial institution transfer by setting 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

T3TFT – Funds Transfer - R14

172

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

T3TFT – Funds Transfer - R14

172

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

T3TFT – Funds Transfer - R14

173

example : 103.FT.1

T3TFT – Funds Transfer - R14

173

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

T3TFT – Funds Transfer - R14

174

the message.

T3TFT – Funds Transfer - R14

174

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

T3TFT – Funds Transfer - R14

175

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.CODECOMPANY.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

T3TFT – Funds Transfer - R14

176

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.

T3TFT – Funds Transfer - R14

177

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

T3TFT – Funds Transfer - R14

178

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.

T3TFT – Funds Transfer - R14

179

FT1308505GTBSHN8

T3TFT – Funds Transfer - R14

180

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.

T3TFT – Funds Transfer - R14

182

T3TFT – Funds Transfer - R14

183

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.

T3TFT – Funds Transfer - R14

184

T3TFT – Funds Transfer - R14

185

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

T3TFT – Funds Transfer - R14

186

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

T3TFT – Funds Transfer - R14

186

T3TFT – Funds Transfer - R14

187

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

T3TFT – Funds Transfer - R14

188

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.

T3TFT – Funds Transfer - R14

189

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.

T3TFT – Funds Transfer - R14

190

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.

T3TFT – Funds Transfer - R14

191

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.

T3TFT – Funds Transfer - R14

192

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.

T3TFT – Funds Transfer - R14

193

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.

T3TFT – Funds Transfer - R14

194

T3TFT – Funds Transfer - R14

195

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.

T3TFT – Funds Transfer - R14

196

T3TFT – Funds Transfer - R14

197

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.

T3TFT – Funds Transfer - R14

198

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.

T3TFT – Funds Transfer - R14

199

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.

T3TFT – Funds Transfer - R14

200

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

T3TFT – Funds Transfer - R14

201

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.

T3TFT – Funds Transfer - R14

202

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.

T3TFT – Funds Transfer - R14

203

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.

T3TFT – Funds Transfer - R14

204

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.

T3TFT – Funds Transfer - R14

205

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.

T3TFT – Funds Transfer - R14

206

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

T3TFT – Funds Transfer - R14

207

Order record.

T3TFT – Funds Transfer - R14

207

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

T3TFT – Funds Transfer - R14

208

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.

T3TFT – Funds Transfer - R14

208

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

T3TFT – Funds Transfer - R14

209

CHARGES.ACCT.NO Field in FUNDS.TRANSFER Application

T3TFT – Funds Transfer - R14

209

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

T3TFT – Funds Transfer - R14

210

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

T3TFT – Funds Transfer - R14

211

day within the same month.

T3TFT – Funds Transfer - R14

211

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.

T3TFT – Funds Transfer - R14

212

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 nonnegative 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

T3TFT – Funds Transfer - R14

213

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.

T3TFT – Funds Transfer - R14

213

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.

T3TFT – Funds Transfer - R14

214

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.

T3TFT – Funds Transfer - R14

215

T3TFT – Funds Transfer - R14

216

T3TFT – Funds Transfer - R14

217

T3TFT – Funds Transfer - R14

218

T3TFT – Funds Transfer - R14

219

T3TFT – Funds Transfer - R14

220

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.

T3TFT – Funds Transfer - R14

221

T3TFT – Funds Transfer - R14

222

T3TFT – Funds Transfer - R14

223

T3TFT – Funds Transfer - R14

224

T3TFT – Funds Transfer - R14

225

T3TFT – Funds Transfer - R14

226

T3TFT – Funds Transfer - R14

227

T3TFT – Funds Transfer - R14

228

T3TFT – Funds Transfer - R14

229

T3TFT – Funds Transfer - R14

230

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.

T3TFT – Funds Transfer - R14

231

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

T3TFT – Funds Transfer - R14

232

FT.APPL.DFAULT is generated

T3TFT – Funds Transfer - R14

232

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.

T3TFT – Funds Transfer - R14

233

T3TFT – Funds Transfer - R14

234

T3TFT – Funds Transfer - R14

235

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.

T3TFT – Funds Transfer - R14

236

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.

T3TFT – Funds Transfer - R14

237

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 on- line 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.

T3TFT – Funds Transfer - R14

238

T3TFT – Funds Transfer - R14

239

T3TFT – Funds Transfer - R14

240

T3TFT – Funds Transfer - R14

241

T3TFT – Funds Transfer - R14

242

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

T3TFT – Funds Transfer - R14

243

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

T3TFT – Funds Transfer - R14

244

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.

T3TFT – Funds Transfer - R14

244

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.

T3TFT – Funds Transfer - R14

245

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.

T3TFT – Funds Transfer - R14

246

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

T3TFT – Funds Transfer - R14

247

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

Transaction type given here will be overridden when FT.BLK.IT.TRANSACTION.TYPE is provided at FT.BULK.ITEM level

T3TFT – Funds Transfer - R14

248

Mandatory for MULTI Should be a Valid record in FT.TXN.TYPE.CONDITION 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

T3TFT – Funds Transfer - R14

248

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 Should be a Valid record in FT.TXN.TYPE.CONDITION 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 Used only for CREDIT processing

Transaction type given here will be overridden when FT.BLK.IT.TRANSACTION.TYPE is provided at FT.BULK.ITEM level

T3TFT – Funds Transfer - R14

248

Mandatory for SINGLE Should be a Valid record in FT.TXN.TYPE.CONDITION 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 Used only for CREDIT processing Transaction type given here will be overridden when FT.BLK.IT.TRANSACTION.TYPE is provided at FT.BULK.ITEM level Mandatory for SINGLE type Should be a Valid record in FT.TXN.TYPE.CONDITION

T3TFT – Funds Transfer - R14

248

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

T3TFT – Funds Transfer - R14

249

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.

T3TFT – Funds Transfer - R14

249

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.

T3TFT – Funds Transfer - R14

250

T3TFT – Funds Transfer - R14

251

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

T3TFT – Funds Transfer - R14

252

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”

T3TFT – Funds Transfer - R14

253

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’.

T3TFT – Funds Transfer - R14

254

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

T3TFT – Funds Transfer - R14

255

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.

T3TFT – Funds Transfer - R14

256

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

257

T3TFT – Funds Transfer - R14

258

T3TFT – Funds Transfer - R14

259