Posted by 
Funds Transfer Application
Cash Pooling
Funds Transfer Application
The Funds Transfer Module is designed to handle all types of Local and Foreign Currency, Inward, Outward and Onward payments.
Also, encompassed within the Funds Transfer Module is a fully operational Standing Order Application. This Application has user friendly maintenance procedures and provides for fixed and preset payments together with Funds Management initiated by balance levels. The User may also use the Standing order mechanism to diarise certain non-payment activity.
Available transactions may be immediately input to the System and validated irrespective of the Value Date. The option exists to provide limited additional information at any time after the initial input, although the transaction may have already been processed. This will facilitate the situation where a ‘Fixing Rate’ must be used in certain Funds Transfer transactions, before the ‘Fixing Rate’ is actually known.
The production of all printed matter in respect of payments, from pre-printed Bankers Payments to advices, is controlled within the GLOBUS Delivery System Module. This System will also cater for all automated communications via Telex, Swift or any other electronic transfer. The only output direct from Funds Transfer is an Activity Journal and an Exception Report.
PRODUCTS PROCESSED BY THE SYSTEM
The main product types handled by this Module can be classified as follows :
1.1 Outward Payments (incorporating Onward payments)
- Account Transfers
- Manager cheque (drawn on ourselves)
- Bank draft
- Bankers Payment
- Electronic Transfers via Telex, Swift
- Local Clearing Payments
- Direct Drawings
Currently, outward payments are only generated for SIC, if required for other systems these must be added as a local enhancement.
1.2 Inward Payments
- Telex, Swift
- Cheques/Drafts
- Bankers Payment
- Mail
- Local Clearing (currently only SIC)
1.3 Batch Payments A future enhancement is planned to enable Customers to send-in magnetic tapes containing numerous payments (e.g. salary payments) for automatic generation of the payments through the Funds Transfer System.
1.4 Standing Orders The Standing Orders Application is an integral part of the Funds Transfer Application and interfaces directly with the Funds Transfer main program for the generation of all derived payments.The types of Standing Order that can be loaded are:
- Fixed Payments, with known amount and frequency
- Preset Payments when amount not known
- Balance Maintenance with automatic transfer of excess funds
- Balance Maintenance with automatic transfer of funds into the account to maintain a minimum balance.
- Diary Instructions - including non-financial information
- Direct Debit Authorities held
FIELD NO 2 = DEBIT.ACCT.NO
For Inward Payment Orders, this account will usually contain Our Correspondent Account detail (Nostro account for Foreign Currency and Vostro Account for Local Currency or internal account). For Outward Payment Orders, this account field will usually contain the Account in our books which is specified by the Customer requesting the payment.
To differentiate between an Account Number and a Category code, the Funds Transfer Application will require the letters PL to be appended to the front of any Category code. Any other input without these letters will be considered to be an Account Number.
For internal transactions (i.e. AC & DW), input in this field is mandatory.
For outward local clearing (BC) transactions, the account must be a local currency account, unless the ALLOW.FCY.DEBIT field on FT.BC.PARAMETER is set to ‘Y’. For local clearing validation rules, see details for the relevant clearing system under the section ‘local clearing rules’.
FIELD NO 7 = DEBIT.VALUE.DATE
For Internal Accounts, the default Debit Value Date is the Processing Date. For other Accounts the rules are as follows:
1. For each Transaction Type, default Value Date Conditions are defined in the Transaction Type Condition table.
The Value Date conditions applicable to the Customer entry (Debit Value Date for outward transfers and the Credit Value Date for the inward transfers) are then defined by specifying a number of days to be added (Inward Payments) or subtracted (Outward Payments) from the bank Value Date.
2. The User can also define different Default Value Date conditions for groups of Customers in the Group Condition table. This table will be referenced by the User, when it is required to apply special conditions to particular groups of Customers (as Banks, Staff, Prime Customers, etc…).
3. Default Value Date conditions can also be defined at the Customer level by means of the Customer Condition table. The User will refer to this table when any particular Customer is to receive special conditions.
4. When the Value Date is not input, the Funds Transfer Application will verify (each time) whether the Customer has special Value Date conditions, or is part of a group of Customers which have been afforded special conditions, and if not, apply the transaction Type default Value Date conditions.
To summarise the priority sequence of conditions:
if not INPUT then CUSTOMER,
if not CUSTOMER then GROUP,
if not GROUP then TXN TYPE.
Note: If there is no record in the Holiday table for the country of the debit currency, the Value Date will be checked against the Local Holiday table record. If the Local Holiday table record is also missing, the transfer will be rejected.
FIELD NO 19 = ORDERING.CUST
Identifies the Customer who is ordering the transaction. This Customer should not be a bank. (If the ordering party is a bank, the Ordering Bank should be used.)
For Outward Payments, input should only occur when the original Customer of the transaction (i.e. the actual Customer ordering the transaction) is not the same as the Customer of the Debit Account Number.
For Inward Payments, this field would be used to enter details (name and address) of the Customer who actually originated the transaction. Any input made in this field will be printed on the credit and debit advices (i.e. By Order Of) and will also be included in the outgoing message (Telex).
This field corresponds to Field 50 in SWIFT messages.
FIELD NO 11 = CREDIT.ACCT.NO
For foreign Currency outward transfers, the Nostro account will be automatically defaulted from the Nostro table if no other input has been entered in this field. For local Currency outward transfers, the Account will default to the Vostro account of the Receiver bank if this has been defined in the Agency record.
FIELD NO 51 = CUSTOMER.SPREAD
The Customer Spread defined in this field will be applied to the Treasury (buy/sell) Rate to generate the final Rate of the transaction, i.e. the exchange rate which is applicable to the Customer. The actual Customer rate will never be input in the Funds Transfer Application because it will always be generated automatically in accordance with the rate values defined in this field and the Treasury rate field.
If no input is made in this field, the Application will default to the spread from the Currency record according to the transaction amount. The User should consider the rules relating to the default values of Spread by the Funds Transfer Application. These rules can be summarised as:
1. The Currency Table allows the User to define different Treasury and Customer exchange Spreads according to the amount of the transaction. The Customer Spreads from this table will be used throughout the Funds Transfer Application when no other special spread conditions have been afforded to the Customer of the transaction.
2. The User can define different spread conditions for groups of Customers by use of the Group Condition table. This table will be enhanced by the User so as to apply special conditions to particular groups of Customers (as Banks, staff, Prime Customers, etc.).
3. Finally, default spread conditions can also be defined at the Customer level by means of an individual customer record on the GROUP.CONDITION table. The User will create entries on this table when a particular Customer receives special conditions.
When the Customer Spread is not input, the Funds Transfer Application will verify if the Customer has special spread conditions, or is part of a group of Customers which have been given special conditions, and if not, the System will apply the standard conditions as defined in the Currency table.
FIELD NO 23 = ACCT.WITH.BANK
Identifies the Bank (other than the Receiver Bank) at which the ultimate beneficiary maintains its Account.
Used when the ordering party requests that the beneficiary be paid at a bank other than the Receiver Bank. The Customer specified, cannot be the same as the Customer of the Credit Account.
The Account With Bank may be a branch of the Receiver Bank, or an entirely separate bank. If the Account with bank is null then it will default per beneficiary autorouting instructions on the agency file.
This field corresponds to Field 57 in SWIFT messages.
For Local clearing validation rules, see the details for the relevant clearing system under the section ‘local clearing rules’.
Example: Mr John Smith requests his bank (British Bank, London) to debit his account for $1,000.00 and transfer the money to American Bank, New York in favour of Mr Peter Brown. The following will be input:
Field Desc. | Field Input.
Ordering Cust. | Mr. John Smith.(automatic default)
Account with Bank. | American Bank. New York.
Beneficiary Customer.| Mr. Peter Brown.
The subsequent Telex Payment Order would be sent direct to our correspondent; British Bank, New York.
FIELD NO 35 = RECEIVER.BANK
Defines the bank to whom the Payment Order is to be sent (OB, OT), or the bank on which the Draft is drawn (OD). The 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.
The 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.
With Cables and Drafts (Transaction Types OD an OT) the input of a Customer Number or Mnemonic will automatically generate the contents of Receiver Correspondent Bank (and optionally, the Intermediary Bank) when the credit currency autorouting instructions have been so defined in the Agency File for the Receiver Bank. If not defined fully within the Agency File, the Receiver Correspondent Bank details will require to be input by the User on each Transaction.
A Cover Cable may be sent to Our Correspondent Bank, in addition to the basic Cable Payment Order, depending on the values of Receiver Bank and Receiver Correspondent Bank (refer to the Receiver Correspondent Bank field for further details).
FIELD NO 36 = REC.CORR.BANK
Identifies the Correspondent Bank for the Receiver Bank (i.e. the bank servicing the Account held by the Receiver Bank in the Currency of the Credit Amount).
The Receiver Correspondent Bank is the location where the funds will be made available for the Receiver.
If this field is not entered it will default automatically from the data stored in the Receiver Bank’s Agency record.
The presence of the Receiver Bank, together with this field, indicates that two cables should be generated:
. Payment Order or Draft Payment to the Receiver Bank
. Cover Cable to Our Correspondent Bank Nostro
This field corresponds to field 54 in SWIFT messages.
Extreme care should be taken when the name and address of the Receiver Correspondent Bank is entered manually, by means of the four available lines, as any direct input will be accepted without further validation.
The Funds Transfer Application will only issue a cover payment for Outward payments:
. by Telex (Transaction Type OT) or . by Draft (Transaction type OD)
As a general rule, within the Funds Transfer Application, 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.
Example:
Let us suppose that British Bank, London send a direct Telex payment order to Belgium Bank in Brussels (with whom they have test arrangements) requesting them to pay Deutsche Marks 1,000,000.00 to one of their Customers.
Because British Bank London does not maintain its Nostro Account in Deutsche Marks with Belgium Bank, Brussels but with German Bank, Frankfurt and Belgium Bank, Brussels does not maintain their Nostro Account in Deutsche Marks 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. Cable to: German Bank, Frankfurt requesting them to pay Deutsche Mark 1,000,000.00 to the other German Bank favour Belgium Bank Brussels with the message ‘In cover of our direct Telex payment order to you.’
A Receiver Correspondent Bank value is always mandatory when the Receiver Bank field is entered (the field may be manually input or defaulted from Agency file). The cost of a Cover Cable, in respect of either a Draft or Telex, may be automatically recovered by use of the Secondary Telex Charge field within the Application Default File.
FIELD NO 46 = COMMISSION.TYPE
The rules relating to the handling of the default Commission Types by the Funds Transfer Application can be summarised as follows:
1. For each Transaction Type, default Commission Type conditions may be defined in the Transaction Type table. The User may define in this table all Commission Types applicable to each Transaction Type.
2. The User can also define different Commission Type conditions for groups of Customers in the Group Condition table. This table will be enhanced by the User when special conditions are to be applied to particular groups of Customers (e.g. Banks, staff, Prime Customers, etc.).
3. Finally, default Commission Type conditions can also be defined at the individual Customer level by means of the Customer Condition table. The User will create entries in this table when a particular Customer is to receive special conditions.
CLEARING PAYMENT: CHAPS £ CHIPS $ SIC DEM
MT 100 Swift message type: customer transfer
NOSTRO.ACCOUNT
The various Nostro Accounts can be recorded for each Application and, if necessary, for each Transaction Type within FUNDS.TRANSFER. Thus FT Inward and Outward Dollars could be defined to use different Nostro Accounts.
Furthermore, within the same Application various Nostros can be defined and the corresponding Application will pick up the appropriate Nostro according to the identifying digit specified at the transaction level. The major use of this specific access method is in FX where various default Nostros may be required per Currency.
AGENCY
The Agency File contains settlement details of major customers and all banks irrespective of whether there is any business connection. Details include any arrangements, Account relationships and, where possible, the 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. This eliminates the need to re-enter the details at transaction level. It thus allows full advantage to be taken of electronic delivery facilities by providing, automatially, the settlement agents for remittances/cover involved in outward payments.
PERIODIC.INTEREST
This table defines, for each currency, interest rates for any time period desired by the user. These periods can be defined either in months, e.g. 1 month, 2 months, 3 months, 6 months etc.. or in days, e.g. 7 days, 15 days, 30 days etc.. For each period defined by the user, both a BID and OFFER rate can be entered.
It will be used by applications such as Foreign Exchange to default interest rate on Forward contracts using the Interest revaluation method or the Loans and Deposits applications to perform automatic Rollover. It decides the rates of placement FD.
CURRENCY
This table contains all details of each individual Currency, for example, Currency Name, Number of Decimal places together with other information such as the Buy and Sell Rates.
Globus caters for both Middle rate and Buy/Sell Rate environments therefore when installing the System the User must specify, in the Company record, which method is to be adopted. Regardless of which rates are entered, however, both Middle and Buy/Sell Rates are used in calculations e.g.
- Middle Rate is used for monitoring of rate variances.
- Buy/Sell Rates are used (in conjunction with spreads) to
calculate Treasury/Customer rates.
Automatically, when the Middle Rate and the Default Spread are entered, the Buy/Sell Rates are calculated and when Buy/Sell Rates are input the Middle Rate and the Default spread will be calculated by the System.
The use of the I.S.O. Currency Codes are recommended as a standard for the ID of this table although an additional numeric code must be defined and may be used as an alternative ID for accessing the Currency details.
Up to 999 additional elements may be defined according to local requirements.
CHEQUES OF COLLECTION
FT.TXN.TYPE.CONDITION
------------------------------------------------------------------------------
This table defines the default conditions for each Transaction Type
which can be processed by the Funds Transfer and Standing Orders
Application. These can be summarised as follows:
. Transaction Codes
The Transaction Codes to be used for the generation of
the entries. Both Debit and Credit Transaction Codes
will be defined for basic entries, standing orders, debit
charges and cheques.
. Commission Types
The default Commission Types applicable for each
Transaction Type. These Commission Types must first
have been defined in the Commission Type table.
. Charge Types
The default Charge Types applicable for each
Transaction type. These Charge Types must have been
previously created in the CHARGE.TYPE table.
. Maximum Forward and Back Value Date
The Maximum Forward and Back Value dates applicable
for each transaction type must be specified and any
excess beyond these value dates will force an override at
the transaction level.
. Default Value Dates for the Accounting Entries
The default Value Date conditions may be held for each
Transaction type. The conditions for both debit and
credit entries are catered for, i.e the User can specify
for each Transaction type, the Value Date conditions
applicable to the bank and to the Customer.
. Production of Advices
For a given transaction type, the production of Debit
and Credit advices by default, can be controlled.
The default conditions defined in this table will only be used by the
Funds Transfer Application, during validation of the transaction, if
specific values have not been manually entered during the transaction
input stage.
Amendments to this table will only take effect after the user has next
signed on to the system.
XXXX (TAKEOVER) FT.TRANSACTION.TYPE.CONDITION S=VOIR
TRANSACTION.TYPE.. OT ------------------------------------------------------------------------------ 1. 1 GB DESCRIPTION. OUTWARD TELEX PAYMENT 1. 2 FR DESCRIPTION. PAIEMENT PAR TELEX 1. 3 DE DESCRIPTION. TELEX- UND SWIFTZAHLUNG 2. 1 GB SHORT.DESCR. TELEX PAYMENT 2. 2 FR SHORT.DESCR. PAIEMENT TELEX 2. 3 DE SHORT.DESCR. TELEX-SWIFT 3 TXN.CODE.CR....... 210 PAIEMENT PAR TELEX 4 TXN.CODE.DR....... 210 PAIEMENT PAR TELEX 5 STO.TXN.CODE.CR... 214 ORDRE PERMANENT 6 STO.TXN.CODE.DR... 214 ORDRE PERMANENT 7 DR.CHARGE.TXN.CODE 230 FRAIS DE SORTIE DE FONDS 8 DR.CHEQUE.TXN.CODE 201 PAIEMENT PAR CHEQUE 10. 1 CHARGE.TYPES... FTSF TRANSFERTS - SORTIE FONDS 10. 2 CHARGE.TYPES... FTSFA TRANSFERTS - SORTIE FONDS - A 10. 3 CHARGE.TYPES... FTSFB TRANSFERTS - SORTIE FONDS - B 10. 4 CHARGE.TYPES... FTSFD TRANSFERTS - SORTIE FONDS - D 11 FORW.VALUE.MAXIMUM Y 12 BACK.VALUE.MAXIMUM Y 13. 1 PAYMENT.TYPE... ALL 14. 1 PAYMENT.VALUE.. +02W 15. 1 CUSTOMER.FLOAT. 2 17 DR.ADVICE.REQD.Y.N Y 18 CR.ADVICE.REQD.Y.N N 19 BULK.TXN.CODE.CR.. 214 ORDRE PERMANENT 20 BULK.TXN.CODE.DR.. 214 ORDRE PERMANENT 28 CURR.NO........... 3
Field 10 contains different types of charges.
FT.CHARGE.TYPE
------------------------------------------------------------------------------ This table defines the conditions relating to various types of standard 'flat' charges used by GLOBUS. Charges in local currency must be entered and foreign currency charges can also be specifically defined if required. The Currency of the Account bearing the Charge determines the Charge Currency applied. Where no charges exist in the Account Currency the default local currency charges will apply and the System will take the currency equivalent using the rates held on the Currency file. In all cases the charge amount will be a 'Flat' Amount, regardless of the monetary value of the Transaction. Where necessary, the Charge can be defined according to the destination Country Zone, defined as the 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 the ordering customer is resident or non-resident within certain countries. In addition CHARGE.TYPES can be linked to allow different charge structures, tax codes etc to be applied depending on the residence of the ordering customer. For example charges can be defined for EEC and NON-EEC resident customers.
FTSF, FTSFA, FTSFB, FTSFD… define for different groups of customers according Local Reference.
XXXX (TAKEOVER) FT.CHARGE.TYPE S=VOIR
CHARGE.TYPE....... FTENC ------------------------------------------------------------------------------ 1. 1 GB DESCRIPTION. TRANSFERTS - ENCAISSEMENT CHEQUES 2. 1 GB SHORT.DESCR. ENC CHQUES 3 CATEGORY.ACCOUNT.. 52400 COM.TPA 4 TXN.CODE.CR....... 232 FRAIS D'ENCAISSEMENT 5 TXN.CODE.DR....... 232 FRAIS D'ENCAISSEMENT 7. 1 CURRENCY....... CHF FRANCS SUISSES 8. 1 FLAT.AMT....... 30.00 14 MTHLY.AMORTISATION NO 33 CURR.NO........... 3
15 Contingent entries for checks FT,ACCA 16 Incoming Cheque – Credit after entry FT,ICA
XXXX (TAKEOVER) COMPTE,BDAS S=VOIR REF 241520963691
FRF CHEQUES/EFFETS A L'ENCAISSEMENT-CLI
***** ENREGISTREMENT COMPTE CLIENT *****
------------------------------------------------------------------------------
1 No Client : 241520 TRADIMEX LIMITED
2 Categorie : 9-600 CHEQUES/EFFETS A L'ENCAISSEMENT-CLI
3 Libelle Compte : TRADIMEX LIMITED CHQ ENC. FRF
5 Nom Court : TRADIMEX LIMITED CHQ ENC. FRF
8 Monnaie : FRF FRANCS FRANCAIS
11 Gestionnaire : 90 PIERRE KRYVIAN
21 Cond. Groupe No: 99 DEFAULT
XXXX (TAKEOVER) COMPTE,BDAS S=VOIR REF 400110913691
FRF CHEQUES/EFFETS EN RECOUVREMENT-BQUE
***** ENREGISTREMENT COMPTE CLIENT *****
------------------------------------------------------------------------------
1 No Client : 400110 CREDIT COMMERCIAL DE FRANCE
6 Mnemonique : FRFCCFCHQ
2 Categorie : 9-100 CHEQUES/EFFETS EN RECOUVREMENT-BQUE
3 Libelle Compte : CREDIT COMMERCIAL DE FRANCE CHQ FRF
5 Nom Court : CREDIT COMMERCIAL DE FRANCE CHQ FRF
8 Monnaie : FRF FRANCS FRANCAIS
11 Gestionnaire : 1 DEFAULT
21 Cond. Groupe No: 99 DEFAULT
1. According to the cheque received, you may input under « FT,ACCA », debit a bank’ account with category of 9100, while credit the customer’s account with category of 9600. No charge. Incoming Cheque Credit after Entry XXXX (TAKEOVER) FUNDS.TRANSFER,ACCA S=VOIR REF FT9724600048
ENCAISSEMENT DE CHEQUE - CAR ECRITURES HORS BILAN
Information Debit —————————————-
2 Compte Debite : 400110913691 CREDIT COMMERCIAL DE FRANCE CHQ FRF 5 Devise Debit : FRF FRANCS FRANCAIS 6 Montant Debite : 2,595,337.04 9 Reference Debit: 241520-2536 ------------------- Information Credit --------------------------------------- 11 Compte Credite : 241520963691 TRADIMEX LIMITED CHQ ENC. FRF 13 Devise Credit : FRF FRANCS FRANCAIS 10 References Cred: 2536-110
2.1 After receiving the confirmation of broker by Swift, you may go on the second step: input under « FT,ICA », debit customer, credit bank. No charge.
XXXX (TAKEOVER) FUNDS.TRANSFER,ACCA S=VOIR REF FT9724600051
ENCAISSEMENT DE CHEQUE - CAR ECRITURES HORS BILAN
Information Debit —————————————-
2 Compte Debite : 241520963691 TRADIMEX LIMITED CHQ ENC. FRF 5 Devise Debit : FRF FRANCS FRANCAIS 6 Montant Debite : 2,595,337.04 ------------------- Information Credit --------------------------------------- 11 Compte Credite : 400110913691 CREDIT COMMERCIAL DE FRANCE CHQ FRF 13 Devise Credit : FRF FRANCS FRANCAIS
2.2 Input the effected transaction: debit bank, credit customer. With charge. Incoming Cheque – Credit after Entry Below the Lines Entries XXXX (TAKEOVER) FUNDS.TRANSFER,ICA S=VOIR REF FT9724600052
ENCAISSEMENT DE CHEQUE CREDIT APRES RENTREE
Information Debit —————————————-
2 Compte Debite : 400110503691 CREDIT COMMERCIAL DE FRANCE FRF 5 Devise Debit : FRF FRANCS FRANCAIS 6 Montant Debite : 2,595,337.04 7 Dte Valeur Deb : 10 SEP 1997 9 Reference Debit: REF SWIFT 68 Montant Debite : FRF 2,595,337.04 ------------------- Information Credit --------------------------------------- 11 Compte Credite : 241520103691 TRADIMEX LIMITED FRF 13 Devise Credit : FRF FRANCS FRANCAIS 15 Date Valeur Crd: 15 SEP 1997 10 References Cred: BLABLA 69 Montant Credite: FRF 2,595,214.22
Frais / Commissions ————————————–
48 Code Frais : CREDIT LESS CHARGES 49. 1 Type Frais : FTENC 50. 1 Mont Frais : FRF 122.82 53 Centre Profit : 241520 TRADIMEX LIMITED
Field 49 determines 50, but can be overrided by manuelly-input amount. Field 69 should be left blank when inputting.
Cash Pooling
The configuration for the “Cash Pooling” requires FT.TXN.TYPE.CONDITION, LOCAL.TABLE, LOCAL.REF.TABLE, ENQUIRY, Routine, PGM.FILE, VERSION. The actual configuration is available on “prod” database.
1. FT.TXN.TYPE.CONDITION:
OTCH OTNO
2. LOCAL.TABLE:
55 : POOLING.NOSTRO was created to specify the default pooling nostro. 56 : DAYS.FWD to specify the date of the transfer 57 : NEW.CR.FWD.BAL 58 : NEW.DR.FWD.BAL 59 : MINIMUM.BAL
3. LOCAL.REF.TABLE:
LOCAL.TABLE 55, 59 was added to ACCOUNT, with position 3, 4 LOCAL.TABLE 56, 57, 58 was added to FUNDS.TRANSFER, with positions 20, 21, 22
4. ENQUIRY:
the enquiry ACCT.FWD.POOL.BEC was created
5. Routine:
Routines V.GET.FWD.BAL1, V.CHECK.CREDIT.CLEARING, V.GET.NEW.BAL, V.GET.NEW.BAL.CRAMT, V.GET.NEW.BAL.DRAMT were written in BP, and compiled
6. PGM.FILE:
The routine V.GET.FWD.BAL1 must be added to PGM.FILE as S type and FT product, the application FUNDS.TRANSFER must be specified in APPL.FOR.SUBR
7. VERSION :
FUNDS.TRANSFER,OTN.OUTBAL1.BEC FUNDS.TRANSFER,OTN.OUTBAL2.BEC FUNDS.TRANSFER,OTN.OUTBAL3.BEC FUNDS.TRANSFER,OTN.OUTBAL4.BEC FUNDS.TRANSFER,OTN.OUTBAL5.BEC
NB:Routine V.CHECK.CREDIT.CLEARING is attached to the versions. It is done to reconstitute an OTCH MT202 based transaction to generate the B11 in case the credit account is the clearing account. For the concept to operate normally, it important to note that every nostro should have a principal pooling account except the principal nostro. These parameters should be defined into the procedure. When the parameters will be set to the new database, it is important to check that the local references have the same position in the application. If these change, it is necessary to modify the routines consequently.