Funds Transfer

Posted by
Print Friendly, PDF & Email

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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.