Documente Academic
Documente Profesional
Documente Cultură
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Table of Contents
Introduction.............................................................................................................................................. 4
Application Overview ........................................................................................................................... 4
Client Account .................................................................................................................................. 4
Internal Accounts.............................................................................................................................. 7
Account Number Format .................................................................................................................. 8
Account Input ................................................................................................................................... 9
NOSTRO Accounts ........................................................................................................................ 12
Account balances ........................................................................................................................... 12
Locking of Funds (Blocked or Held Amounts)................................................................................ 33
Change of Main Customer ............................................................................................................. 36
Account Closure ............................................................................................................................. 37
Interest, Premium Interest, Charges And Statement Parameters ................................................. 42
Interest Calculation Overview ........................................................................................................ 44
Interest Capitalisation And Accrual ................................................................................................ 45
Daily Compounding Interest – Accounts ........................................................................................ 46
Compounding Interest in Other Applications ................................................................................. 46
Compounding Interest with non-Daily frequency ........................................................................... 46
Example of Daily Compounding Calculation in Accounts .............................................................. 47
Negative Interest ............................................................................................................................ 49
Bonus Interest ................................................................................................................................ 49
Interest Related Tax And Charges................................................................................................. 50
Account Maintenance Charges ...................................................................................................... 51
Offsetting And Waiving Charges .................................................................................................... 52
Limits .............................................................................................................................................. 52
Account Statements ....................................................................................................................... 52
Account Violations.......................................................................................................................... 53
Account Sweeping.......................................................................................................................... 55
Overview of Input and Processing ..................................................................................................... 59
Multi-Level Cash Pooling................................................................................................................ 59
Example ......................................................................................................................................... 68
Account before first sweep............................................................................................................. 69
Account after COB ......................................................................................................................... 70
Account after new postings ............................................................................................................ 70
Account after next COB.................................................................................................................. 71
Payment Netting............................................................................................................................. 78
Parameter Files .............................................................................................................................. 85
Introduction
Application Overview
The ACCOUNT module (and its Interest and Charges routines) caters for the creation, maintenance
and control of all types of accounts handled by T24. It also provides:
Accounts can be classified as one of two types, client accounts or internal accounts. Client accounts
are those owned by an external customer such as current accounts, savings accounts etc. Internal
accounts are those owned by us such as suspense accounts.
There are no actual general ledger accounts in T24. To allow for accurate and detailed accounting
analysis, profit and loss balances are not held in an account, instead consolidated balances and
movements are kept at the lowest reporting level by use of specific category codes, which are used by
all applications to record profit and loss entries. The usage of these ‘virtual’ general ledger accounts is
explained in the Reporting chapter of the user guide.
Client Account
A client ACCOUNT can be one of many different types, a simple current account, overdraft or savings
accounts and many more. T24’s strength lies in the flexibility within which new account types can be
added to it in order to meet the bank’s ongoing requirements.
T24 is a customer-orientated system. An account is connected to a CUSTOMER record and thus the
owner and address details are not entered on the individual ACCOUNT. This eliminates the need for
extensive maintenance of customer information such as when a customer changes their address.
When T24 is installed, part of the implementation process is to configure the types of accounts the
bank wishes to offer and their characteristics. Typically this would include the debit/credit interest rates,
interest and charges capitalisation frequencies, statement production cycle, other account group
conditions etc. Once these key files are set up the addition of a new client ACCOUNT is very simple.
• Posting Restrictions
• Referral Conditions
• Alternate Account ids
• Mnemonic codes
• Joint account holders
• Liquidation of interest to another account
• Pre-Notification of debit interest due
• Charges capitalised to another account
• Pre-Notification of charges due
• Interest and Charges settled in currencies other than the account currency
• Combining balances across accounts before interest calculations
• System information fields such as balances etc.
In the above example the account 25976 has a field MNEMONIC that contains a value of LDLEUR.
This mnemonic can be entered into any standard T24 ACCOUNT field and is translated automatically
into the correct ACCOUNT number.
A NOSTRO account is a special type of account, identified by the CATEGORY code and the
LIMIT.REF field containing the word “NOSTRO”. As it is a shadow of the VOSTRO account
maintained by the correspondent the client id is informational the real account owner is you. An
example of a NOSTRO account is shown below using the following function:
When setting up a Nostro Account the client of the ACCOUNT should not receive a statement, or
debit/credit advices. These should be re-directed to your reconciliation’s department. Create a print re-
direct address for the correspondent (e.g. US0010001.C-100002.PRINT.2 on DE.ADDRESS) then in
DE.PRODUCT create a record for the Nostro Account (e.g. US0010001.A-26751.ALL.ALL) this will
prevent any advices for this account being sent to your correspondent.
If single limit field in ACCOUNT is set to “Y” then only one account can be attached to a limit record. If
set to “N” then multiple accounts are allowed to utilise a single limit. Single limit Y/N can be defaulted
from ACCT.GROUP.CONDITION using single limit default field. Single limit in account can also be
used independently without setting up ACCT.GROUP.CONDITION.
For information on the Reconciliation module, its capabilities and how it can assist your Reconciliation
Department in their daily workflow please refer to the User Guide chapter for that module.
Internal Accounts
Internal accounts are not related to a CUSTOMER record, and are used for maintenance of cash
accounts, accrued profits, suspense accounts, tax and capital accounts. Since there is no
CUSTOMER record related to internal accounts, details such as account title and short title need to be
specified when the account is created.
The account number of an internal account consists of the currency, category and a subdivision
number.
Client format
The ACCOUNT number on client accounts is a number of up to 16 characters. The format of the
number can be validated if required, for example by the use of check digits or the automatic inclusion
of the CUSTOMER number.
The length and check digit type used for an account is defined in the COMPANY application, in the
fields:
ACCT.CHECKDIG.TYPE
ACC.BKNO.PREFIX
ACCOUNT.MASK
For extended account numbers longer than 16 characters, the input length must be defined in the
EB.OBJECT application, in the field MAX.LENGTH.
ACCT.CHECKDIG.TYPE Please refer to the HELPTEXT on these fields for the settings you require.
Identifies the check digit calculation method for the company being entered.
Note: Once a customer account record has been authorised in this company, this field may no longer
be changed.
Validation Rules
The following values will be accepted: '1', '2', '3', '4', '5', '6', '99', @routine name and 'blank'. Mandatory
input when LOCAL.CURRENCY starts with BE or LU.
Internal Format
The format of an internal account consists of the currency, the category code of the account and a
sequential number. This structure is shown below:
Some fixed internal ACCOUNT records are required by T24 applications and must exist prior to
entering any transactions on these applications. These are listed in the ACCOUNT.CLASS records
and are detailed in the field RECORD.TYPE. It is recommended that the local currency account records
be input manually. T24 is able to open any foreign currency account required automatically, providing
that one exists for the specific account category.
Account Input
Some details such as the account title, customer who owns the account, CATEGORY and
CURRENCY, are input at this time. However, extensive ranges of characteristics are defined on
related parameters tables. This enables an ACCOUNT to be opened with a minimum of details
minimum of details required on input and majority of the processing characteristics defaulted from
group level parameters. Consequently, when these characteristics change, perhaps because of a
change in business policy, the modification need only be applied once to the group level parameter,
which automatically processes all the related ACCOUNT records with the new settings.
The types of characteristics that can be set up on the related parameters include:
The majority of these parameters are linked to the account’s CONDITION.GROUP. The
CONDITION.GROUP defines the way the ACCOUNT is processed. It is set automatically by using
characteristics pre-defined by the user. For example the CONDITION.GROUP for a current account for
corporate clients may be different to that for private clients. This might mean that corporate clients
receive statements daily by default whereas private clients receive them monthly.
Generally these characteristics are defaulted by CONDITION.GROUP but they may be overridden for
particular accounts whenever required. For example, the default statement frequency for private
clients in the above example was monthly, however this could be set to weekly for a particular account.
NOSTRO Accounts
Nostro ACCOUNT records have a key in the same format as a customer ACCOUNT and the account-
servicing bank is treated as a CUSTOMER for most purposes.
Account balances
The following balances are held on the ACCOUNT record in T24.
OPEN.ACTUAL.BAL
This field contains the Actual Non-Cleared Balance or 'Ledger Balance' of the Account as at the start
of the day.
OPEN.CLEARED.BAL
This field contains the Cleared Balance of the Account as at the start of the day. This includes the
value of all entries over the Account except any credit entries or reversed debit entries with Exposure
Dates in the future.
For credit and reversal debit entries with Exposure Dates in the future, this field is updated in the start
of day processing on the appropriate date.
It is possible to split a single entry amount to clear in separate periods. This feature is called exposure
date splitting. For more information on this feature refer to the following sections in the user guide
(Local Clearing, Application Accounting, System Tables and Teller)
ONLINE.ACTUAL.BAL
This field contains the most up to date Actual Balance of the Account. This is the same as the actual
balance at the start of day (OPEN.ACTUAL.BAL) plus the value of all fully Authorised entries since
the start of day.
ONLINE.CLEARED.BAL
This field contains the most up to date Cleared Balance of the Account. This is the same as the
cleared balance at the start of day (OPEN.CLEARED.BAL) plus the value of all fully authorised entries
since the start of day excepting any credits or reversal debit entries with future Exposure Dates.
For credit and reversal debit entries with Exposure Dates in the future, this field is updated at start of
day processing on the appropriate date.
It is possible to split a single entry amount to clear in separate periods. This feature is called exposure
date splitting. For more information on this feature refer to the following sections in the user guide
(Local Clearing, Application Accounting, System Tables and Teller).
WORKING.BALANCE
This field contains the present balance of the Account, which is used for checks done by the LIMITS
system in T24. At the start of day this figure will be the same as the cleared balance figure
(ONLINE.CLEARED.BAL).
For Nostros and Internal Accounts the field is updated by all accounting entries when they have been
fully authorised. For other Customer Accounts it is updated by debit entries when they are Validated
and by credit entries when they have been fully Authorised excepting for any credit or reversal debit
entries with Exposure Dates in the future.
For credit and reversal debit entries with Exposure Dates in the future, this field is updated in start of
day processing on the appropriate date.
It is possible to split a single entry amount to clear in separate periods. This feature is called exposure
date splitting. For more information on this feature refer to the following sections in the user guide
(Local Clearing, Application Accounting, System Tables and Teller).
AVAILABLE.BALANCE
Through the Available Funds functionality, T24 will identify if any movements or transactions will
generate a deficit of cash in a client account or accounts, and will anticipate the impact of a new
transaction on pre-existing client commitments.
DATES
The date updated in the available funds ladder will be selected in the following order of date fields on
the contract resulting in the credit transactions:
1) EXPOSURE.DATE
1) VALUE.DATE
Exposure Date
The exposure date is the date on which a credit entry is included in the cleared balance of an account.
Value Date
The value date is the date from which the entry is included for calculation of interest. Where there is
no exposure date on the transaction the value date is used as the date which the transaction affects
the available funds.
Booking Date
The booking date is the date on which the transaction has been processed.
EXAMPLE:
Any transaction with an exposure date or value date within that period will be included in the available
funds ladder.
As a consequence of this, any forward dated transactions (e.g. Money Market, Loans) with a value
date beyond the window will automatically be included in the available funds ladder.
Backdated transactions
Any transactions with a value date or exposure date less or equal to today’s date will be held under
today’s date available funds ladder.
Example of a backdated transaction and a transaction beyond the window on the following account:
We then enter (and authorise) a back-valued funds transfer, which has the effect of debiting this
account:
The account now shows a debit movement and balance in the available funds fields, with the value
date of today:
MOVEMENTS
Available funds will hold unauthorised and authorised transactions separately, so while
WORKING.BALANCE ignores unauthorised credits and future authorised credits, AVAILABLE.BAL
may contain either unauthorised credits or unauthorised debits or both of them or even neither of them.
All the movements will be held as follows unless a restriction has been set in EB.AF.PARAM at
transaction or application level:
BALANCES
Available Balance
The AVAILABLE.BAL always includes authorised debits and credits. The parameterisation regarding
the update of available balances with unauthorised entries takes place as follows via
AVAILABLE.BAL.UPD:
ACCOUNT.PARAMETER
It is also be possible to set the conditions for all accounts linked to a portfolio at SEC.ACC.MASTER
level, in this case the individual accounts linked to the portfolio will be updated.
Note: If unauthorised debits/credits are excluded from the AVAILABLE.BAL, the movements
will still be updated unless they have been blocked in EB.AF.PARAM.
Credit Checking
A credit check is made whenever a debit transaction is validated or is validated and authorised at the
same time.
An option is available to set credit checking for an account against working balance and cash flows or
available balance via the CREDIT.CHECK field in ACCOUNT.PARAMETER, the options are as
follows:
• ACCOUNT – a flag set here always takes precedence over a flag set elsewhere.
• SEC ACC.MASTER. (If the account is linked to a Portfolio and if ACCOUNT is blank).
• ACCT.GROUP.CONDITION (If ACCOUNT is blank, if account is not linked to a portfolio and
SEC.ACC.MASTER is blank).
• ACCOUNT.PARAMETER (If all of the above applications have not been set).
If set to AVAILABLE then all credit checks will be made against the Available Balances and Cash
flows and Working Balance will be ignored although the Cash flows movements are still populated to
the account.
If an account is linked to a limit then a limit check will take place, otherwise an available balance check
will take place.
If an account is linked to a Shared Balance then a Shared Balance check will take place, otherwise an
available balance check will take place.
NOTE: If an account is a member of a shared balances group then it cannot be linked to a limit.
The AVAILABLE.BAL used for credit checking will be made up of the movements as defined by
AVAILABLE.BAL.UPD.
Override Messages
Parameters
EB.AF.PARAM
This application defines the blocking parameters of unauthorised transactions to the available funds
movements. The blocking may be set at application level or at transaction level within an application.
A blocking at transaction level within an application will take priority over whatever is set for that
application level.
In the function below, blocking parameters have been set for all unauthorised credits and debits within
DC (DATA.CAPTURE).
Figure 11 EB.AF.PARAM showing the available funds parameter set for Data Capture
If an unauthorised transaction is blocked, then neither the movements nor the available balance will be
updated and also no credit check is made for that transaction.
The parameters present in this application are the ones that will be used for blocking unauthorised
transactions for available funds processing. Any change to these parameters must be made through
EB.AF.PARAM.CHANGE.
EB.AF.PARAM.CHANGE
This application allows the input of blocking parameters for available funds processing for an
application.
Fields AVAIL.BAL.NAU.DR and AVAIL.BAL.NAU.CR are used to define the blocking for the
application.
Application
The first two fields define the blocking parameters for the application
• Having the field AVAIL.BAL.NAU.DR set to blank means that all unauthorised debits for DC
should update the available funds movements and the available balances and also credit check
should be made.
• Having the field AVAIL.BAL.NAU.CR set to ‘NO’ means that none of the unauthorised credits
for DC should update either available funds movements or available balances.
Transaction
If a blocking parameter that is different from what has been set for the application needs to apply for a
transaction code, then these parameters need to be set under the transaction code.
In the above example, any DATA.CAPTURE entered which uses transaction code 1 (Miscellaneous
Debits) will be blocked from updating any unauthorised debits.
All other transaction codes used in DATA.CAPTURE will take the blocking parameters set for the
application.
If the field AVAIL.NAU.DR were set to ‘NO’ then no unauthorised Miscellaneous debits in
DATA.CAPTURE would update the available funds movements and the available balances. As a
result, no credit checking would be made for that unauthorised transaction.
Effective Date
The Effective Date field defines the date at which the parameters take effect, by default it will take
today’s unless the date a future date is input.
Once the parameters have been set in EB.AF.PARAM.CHANGE, depending on the effective date,
they will be written to the EB.AF.PARAM during the end of day.
CREDIT.CHECK
This field defines on what balance credit check is to be made, the possible values are:
• WORKING or NULL (blank) - the default indicates that both overdraft and cash flow checks, no
credit check, will be made on Available balances.
• AVAILABLE indicates that only the available funds check is made against the available funds
balance fields. This will take place from the value date of the transaction to the end of the cash
flow window.
AVAILABLE.BAL.UPD
This field defines which unauthorised movements are included in the AVAILABLE.BAL field that will
be used for credit checking:
BOTH indicate that both unauthorised debits and credits are included in the Available
Balance.
NONE indicates that no unauthorised debits or credits are included in the Available Balance.
DEBITS indicate that only unauthorised debits are included in the Available Balance.
CREDITS indicate that only unauthorised credits are included in the Available Balance.
• ACCOUNT
• SEC.ACC.MASTER (If the account is linked to a Portfolio and if ACCOUNT is blank).
• ACCT.GROUP.CONDITION If ACCOUNT is blank, if account is not linked to a portfolio and
SEC.ACC.MASTER is blank).
• ACCOUNT.PARAMETER (If all of the above applications have not been set).
Exceptions
EB.AVAILABLE.FUNDS.WORK
This work file is updated during the start of day processing to store information pertaining to all
accounts with negative available funds balances as of the beginning of the day.
Any required reports will be developed locally using the data in this work file.
This file is keyed on account number and it contains the following information:
• Customer number
• Sector
• Account officer
• Currency of the account
• Portfolio number if applicable
• Last working day
• Previous days open available balance
• Previous days local equivalent of open available balance
• A multi valued set of previous days information related to negative available balances
• Multi valued previous days available date
• Multi valued previous days available negative balance
• Multi valued previous days local equivalent of negative balance
• Current working day
• Current days open available balance
• Current days local equivalent of open available balance
• A multi valued set of current days information related to negative available balances
• Multi valued available date
• Multi valued available negative balance
• Multi valued local equivalent of available negative balance
If there are no negative available balances within the cash flow period for the current day, then the
record is deleted, otherwise amounts for the current working day and the previous working day are
maintained.
The AVF.WORK.UPDATE job within FILE.TIDY.UP batch takes care for the maintenance of the
EB.AVAILABLE.FUNDS.WORK by removing the accounts that no longer have negative available
balances.
This work file gives a list of accounts with an overdrawn available balance or that have exceeded their
limit due to any forward entries that have fit into the Available funds window during the Start of Day.
In order to use the available funds functionality, the available funds ladder must be built for accounts
with existing future transactions, otherwise only new transactions will be reflected in the available
funds.
An option exists in the FILE.TIDY.UP batch, namely REBUILD.AVAIL.FUNDS to rebuild the available
funds ladders for each account.
The job will be run as part of the Start of day process. If the job is to be run the frequency of the job in
the batch needs to be changed.
This process is very time consuming and may impact on the start of day process. Once the start of
day is over, the REBUILD.AVAIL.FUNDS task should be set to ‘A’.
This task may also be run in case of data corruption in available funds.
The first part is to set-up the AC.CP.GROUP.PARAM file with some sort of cash pooling id. The
MAIN.MASTER field must consist of the main account number for the cash-pooling group.
Once the AC.CP.GROUP.PARAM record has been set-up, the next phase would be to set-up the
AC.CASH.POOL record. The id must be the main master account number and all the accounts linked
to the particular group must be set-up under the LINK.ACCT field.
When fields such as BACK.VALUE.ADJ BACK.VALUE.CAP BALANCE.TO.USE & SUB.GROUP are
amended any underlying records relating to that AC.CP.GROUP.PARAM will have the field
LAST.MAINT.DATE on AC.CASH.POOL UPDATED to today’s date. This is because the terms of
the sweep have been altered and back valued adjustments would not follow the same rules as were
previously in place before the changes.
Once the two cash pooling files have been set-up with the group ids, the SB.GROUP.ID field for all
the accounts linked to that particular group will be updated with the cash-pooling id. Please note, if you
are doing an overdraft check on the combined balances of available funds then please make sure that
the CREDIT.CHECK field of the account has been set to AVAILABLE.
When a transaction of some sort is passed through to an account that is linked to a cash pool, the
system will then get all the available balances of all the accounts linked to that same cash pool and
combine them to create an available funds exposure dated ladder. Once the ladder has been created,
the system will locate the date of the transaction on the ladder and then sift through all the combined
balances, displaying the highest overdraft as an override. Below is an example of an overdraft for a
group of combined available fund balances.
10/03/02 5000.00
11/03/02 -1000.00
12/03/02 7000.00 0.00
A Funds Transfer transaction is then passed to ACCOUNT a value dated 07/03/02 for 10,000.00
debits.
Once the transaction is processed the available balances for ACCOUNT A, ACCOUNT B and
ACCOUNT C will be combined to created an available funds date exposure ladder as seen below.
DATE COMBINED
11/03/02 -9000.00
12/03/02 -6000.00
When the date exposure table has been created, the system will then look at all the combined
available balances from the 07/03/02 onwards and find the highest overdraft amount. In this example
the highest overdraft amount is on the 09/03/02, so therefore an overdraft message will be displayed
for the user, showing the date, group id, account number and the amount of –19000.00.
The locked amount was previously input directly to the Account record but now each locked amount is
input as a separate event.
This is achieved through use of the application AC.LOCKED.EVENTS. This application must be
populated with the required details as follows:
ACCOUNT.NUMBER – the Account Number that will have the locked amount.
FROM.DATE – the date the locked amount will commence.
TO.DATE – the final date the locked amount will be held. Funds will be release as from the start of
the following day. If the field is left blank then the locked event will stay forever in the account until the
event is manually reversed.
LOCKED.AMOUNT – the amount of funds to be reserved for the above period.
The ACCOUNT application shows a ladder of locking events applied to that account, and will
automatically include a locked event of zero amounts starting from the date following the last TO.DATE
in any AC.LOCKED.EVENTS record applicable to that account.
Note: Since the TO.DATE field was left blank, then no zero locked amount item is added to the
ladder to show the maturity of the event.
If there is an existing locking event applied to an account, then any new AC.LOCKED.EVENTS record
that covers all or part of the same period will result in the locked amount for the common dates in the
ladder being the sum of the LOCKED.AMOUNT fields for those periods.
Credit Checking
Exact functionality of this feature will depend on whether credit checking is being undertaken based on
the WORKING.BALANCE or the AVAILABLE.BALANCE of the account.
Credit checking against a locked amount is done at the input of a locked event and any transaction
that affects WORKING.BALANCE or AVAILABLE.BALANCE.
Which balance is being checked depends upon the input into field CREDIT.CHECK on ACCOUNT,
ACCT.GEN.CONDITION, SEC.ACC.MASTER or ACCOUNT.PARAMETER.
Working Balance
If this field is set to NULL or WORKING then the system will use the worst-case scenario. The
working balance will be checked against the highest amount in the locking ladder only and an override
generated as applicable.
Available Balance
Single Accounts
If the field is set to AVAILABLE then the system will check all of the available balances within the
available funds ladder against the locked events ladder and override messages generated accordingly.
Group Accounts
If an account forms part of a Cash pool, then an aggregated locked amount ladder is built in and the
group aggregated available balance ladder is checked against the group aggregated locked amount
ladder.
It should be noted that the override ONLY displays that the account will fall below the
LOCKED.AMOUNT and not the actual amount by which the account is short.
Hence the Account record will be updated accordingly and will no longer hold that locked amount.
If a locked amount was set without any start date, the conversion date is used and no maturity is set to
locked event. Thus the locked amount will be held permanently in the account unless the event is
manually deleted or changed.
to any one of the existing JOINT.HOLDER in the ACCOUNT record does not allow modification of
the main customer if there are limits linked to the customer.
Modification of the main customer is validated against the CATEGORY range as defined in
ACCOUNT.PARAMETER application under the record SYSTEM. The following screen shot shows the
example set-up of CATEGORY range in ACCOUNT.PARAMETER.
Figure 22 ACCOUNT.PARAMETER
Modification of the main CUSTOMER.ID for an ACCOUNT record with a single holder is allowed only
for NOSTRO type of accounts, even if the NOSTRO CATEGORY range is specified in the
ACCOUNT.PARAMETER application.
Account Closure
It is possible to close an account both Online and during the Close of Business.
The application ACCOUNT.CLOSURE is used to close accounts wither online or during the close of
business. The account number is used as the record id, and the system will calculate outstanding
interest, premium interest and charges. You may amend the capitalisation date, settlement account
and the posting restriction to be placed on the account record
The example screen below shows the ACCOUNT.CLOSURE record where the account will be closed
during the Close of Business:
Interest and Charges are calculated on the value dated balances and account activity statistics stored
in the ACCT.ACTIVITY file, taking into account all entries over the account up to and including the last
end of day processing.
When an account is flagged for closure, any entries over the account require an override.
During end of day processing the following working day, if the OPEN.ACTUAL.BAL and
OPEN.CLEARED.BAL are both zero, the account is closed.
If it is required to close the account online then the field CLOSE.ONLINE should be set to Y. In
addition to this the user must decide which application will be used to pass the entries, which will settle
the account. FUNDS.TRANSFER, TELLER or ACCOUNT.CLOSURE can be used to pass these
entries. The field CLOSE.MODE will accept FT, TELLER or NULL, if NULL is specified then
ACCOUNT.CLOSURE will be used. Once the ACCOUNT.CLOSURE record is authorised the system
will raise the relevant entries and move the account record to history.
If FUNDS.TRANSFER is used after the ACCOUNT.CLOSURE record is input the system will
automatically raise an FT record and place it on hold, the id of the FT is stored in the field FT.ID.
Once the FT has been authorised, and the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL are both
zero, the ACCOUNT.CLOSURE record should be authorised and the account is closed and moved to
history.
If Teller is specified in the ACCOUNT.CLOSURE record, the system raises a TELLER.DEFAULT
record the ID of record is the ACCOUNT number, this record holds information that will be used in the
TELLER transaction which will pass the entries. The user is required to input a TELLER record, the ID
of the TELLER.DEFAULT record should be populated in the OUR.REFERENCE field of the TELLER,
(once the TELLER.DEFAULT record has been processed it can not be reused), and this will then
populate the transaction with details from the ACCOUNT.CLOSURE. Once the TELLER is authorised
and the OPEN.ACTUAL.BAL and OPEN.CLEARED.BAL are both zero, the ACCOUNT.CLOSURE
record should be authorised, and the account will closed and move to history.
The system will not allow an account to be closed if it meets one of the following criteria
• Part of a SAM
• Direct Debit
• If it is a liquidation account
• Interest compensation account
• Charge account
• All-In-One account
• Part of a sweep account
• Part of a cash pool
• Not in current company
• Part of collateral
• Unauthorised AC.PENDING exists
• Blocked using AC.BLOCK.CLOSURE
• Closure should not be flagged when account is in suspense
A wide range of other parameters are then linked to this processing group defining the processing for
the account such as when interest is to be applied, how often statements are to be produced, how
charges are to be levied on the account etc.
Often these specifications may be overridden for a particular account. For example the
GROUP.DEBIT.INT parameter specifies the debit interest rate to be applied by default to all the
ACCOUNT records in that CONDITION.GROUP. However if the debit rate for a particular account
needs to be different then a record will be entered on the ACCOUNT.DEBIT.INT table.
The structure of table’s controlling interest, charges and statements is shown below.
GROUP.DEBIT.INT
GROUP.CREDIT.INT
ACCOUNT.DEBIT.INT
GROUP.DEBIT.INT , GROUP.CREDIT.INT , ACCOUNT.DEBIT.INT , ACCOUNT.CREDIT.INT
Interest may be calculated on a daily, average, or highest/minimum balance basis using value dated
balances.
The movements/balances on different accounts in the same currency can be combined and interest
calculated on the net result.
Different rates can be specified for different balance levels and may be linked to the same or different
basic rates. The rates may apply to the whole of the balance or to the part between two balance levels.
Using group level conditions, it is possible to use the limits on individual accounts as the first level for
debit interest so that one rate can be charged up to the limit on any account and another rate when
the limit has been exceeded.
For any accounts where interest conditions or rates are changed with effect prior to the last interest
application, the system generates adjustments on request.
Interest may be capitalised daily, every business day, every 1-9 weeks, twice a month (on the 15th and
the last day of the month) or every 1-99 months (using any day of the month). The capitalisation dates
can be specified at group or account level. Cycles may be different for debit and credit interest.
Special interim capitalisation may be requested without affecting the regular cycle.
It is possible to accrue interest normally on a monthly basis and specify certain types of accounts with
daily accrual.
Where:
NR – Nominal Interest Rate, i.e. the rate defined
m – Number of times interest is compounded per year
This is then used to calculate the daily interest amount (DIF):
DIF = (1 + EIR)1/DIY -1
Where:
DIY = Number of days in the year (denominator of the day basis)
The interest amount for a period is then calculated as:
Int = (1 + DIF)D * (P + ITD)
Where:
D – Number of days in the calculation period
P – Principal
ITD – Interest calculated to date since the last application of interest
This formula can also be used for the calculation of daily compounding interest
ACCC.ACCT.CR
Compounding: DAILY
Interest Basis: Actual/360
365
0.05
EIR5.00 = 1 + − 1 = 0.0512675
365
DIF5.00 = (1 + 0.0512675)
1
360 − 1 = 0.000138889
365
0.0525
EIR5.25 = 1 + − 1 = 0.0538986
365
DIF5.25 = (1 + 0.0538986)
1
360 − 1 = 0.000145833
Therefore:
( )
CR.INT . AMT7.1 = (1 + 0.000138889 ) − 1 * (1,000,000) = 416.72
3
Example :
The account in this example has a positive balance throughout the month.
To determine interest accrual for each multi-value set, we apply the formula as follows:
r d
i = (P + I )1 + −P
n
Multi-value set 1:
5
0.05
I = 1,000,0001 + − 1,000,000 = 694.64
360
Multi-value set 2:
20
0.05
I = (1,500,000 + 694.64)1 + − (1,500,000 + 694.64) = 4174.10
360
Multi-value set 3:
6
0.055
I = (2,000,000 + 694.64 + 4,174.10 )1 + − (2,000,000 + 694.64 + 4,174.10) = 1,838.50
360
The results would then be as follows:
Negative Interest
It is possible to set negative interest rates on accounts in credit. To do this, the NEGATIVE.RATES
field on either ACCOUNT.CREDIT.INTEREST or in GROUP.CREDIT.INTEREST must be set to Yes.
If the field is set as either “No” or left unpopulated, then when interest rates fall below 0, zero interest
will be accrued to that account. Negative interest rates may occur either as a result of a negative rate
being directly entered into the CR.INT.RATE field or by a CR.BASIC.RATE being specified, and then a
discount being placed, which is greater than the CR.BASIC.RATE itself.
Bonus Interest
It is possible through fields on the GROUP.CREDIT.INTEREST and ACCOUNT.CREDIT.INTEREST
application to allow for the setting of a minimum value for account balances so that if the balance falls
below this value at any time during the capitalisation period no credit interest will be paid. The fields
CR.ZERO.INT.BAL and CR2.ZERO.INT.BAL in the above applications hold the value which if the
balance falls below, any time during the capitalisation period, then no interest will be paid. The fields
CR.ZERO.INT.OC and CR2.ZERO.INT.OC, in the same applications, allow for the setting whereby
if an account is opened or closed anytime during the capitalisation period then dependant upon the
input into these fields will determine whether or not interest will be paid.
Tax on interest is calculated at application time and is controlled using the TAX application.
Certain additional charges based on the debit interest application may be applied on the same date,
these include:
Account maintenance charges may be levied monthly, quarterly or six monthly, always at the end of
the appropriate month. The same capitalisation cycle is used for all types of account.
Charges are calculated from the second month of opening an account by default. If it is desired to
calculate the charges from the month in which the account was opened instead, a flag viz.
CHARGE.FIRST.MONTH must be set to a value of ‘YES’ on the ACCOUNT.PARAMETER application.
Charges may be combined into one account entry or applied separately. Free, minimum and
maximum amounts can be specified for each charge. Separate charges can be defined for specific
currencies and local currency charges used as the default for all non-specified currencies.
Notional credit interest can be calculated and offset against the charges.
Limits
The LIMIT.REFERENCE field on the ACCOUNT connects the account with the LIMIT system. Limits
are checked at each on-line transaction and at end of day. The value in this field will automatically be
set to NOSTRO for that type of account or a valid LIMIT.REFERENCE relating to a product or global
limit.
For certain types of limit product it is possible to net credit account balances and debit account
balances (the usual practice is to only include debit balances for limit checking). If an account with a
credit balance is to be included in the limit checking, the field ALLOW.NETTING should be set to YES.
Account Statements
Account statements show details of all entries over the ACCOUNT since the last statement. Entries
are listed in transaction date sequence and may show both transaction date and value date.
Statements can be produced every working day, for 1-9 weeks, twice a month (on the 15th and the last
day of the month) or for 1-99 months (using any day of the month as the anniversary or on the month
end date).
Two statement cycles may be specified for each account, e.g. weekly and monthly.
• Separate: Statements for each cycle show details of all entries since the last statement in the same
cycle, regardless of the other cycle.
• Combined: Statements are produced on the dates specified by both cycles, but only contain details of
entries since the last statement from either cycle.
If there have been no entries since the last statement, the statement may be suppressed unless six
months have elapsed.
Special interim statements, showing details of all entries since the last regular cycle 1 statement, may
be produced any day without affecting the regular statement cycles.
When a duplicate / interim statement is produced on request a charge may be applied for the issue of
the statement.
This charge is usually deferred until the next time the statement is printed in accordance with the
statement frequency. The charge may now be made immediately, together with the production of a
debit advice detailing the charge made when the duplicate statement is produced.
The field PRINT.ROUTINE on the PRINT.STATEMENT file can be used to specify the name of an
external routine written by the users that will be called to print the statement. If this field is populated
the program will call this routine and ignore the normal printing process.
Another field CHARGE.ROUTINE on the PRINT.STATEMENT file could used to specify the name of an
external routine written by the users that will be called to apply an immediate charge to the account for
which the statement is being reprinted.
The alternative method of raising the charge accounting entries would be to use the Generic
Accounting Interface.
Figure 32 - PRINT.STATEMENT
Account Violations
The AC.VIOLATION file is used to record and report violations that occur on an account within a
statement period. All transactions eligible (i.e. defined in ACCT.GROUP.CONDITION) are recorded in
this file whether or not the number of transactions equals the threshold concerned. If the number of
eligible transactions equals or exceeds the TXN.THRESHOLD for the ACCT.GROUP.CONDITION, the
AC.VIOLATION record is flagged as being in violation (i.e. VIOLATION.STATUS = Y). This file is
updated daily during the End-of-Day processing but may be also be updated manually if a transaction
needs to be added or a status changed. Transactions are held by STMT.ENTRY id. Records remain
on the AC.VIOLATION file for the length of time defined in the RETENTION.PERIOD field on the
relevant ACCT.GROUP.CONDITION.
Account violations occurring prior to the completion of a statement period will be generated in the End-
Of-Day processing and held on the AC.VIOLATION file with an id composed of the account number
alone.
On completion of the statement period, all entries on the AC.VIOLATION file held with an id of the
account number, will be amalgamated into the violation record for the statement period just passed. i.e.
that held on the AC.VIOLATION file with an id composed of both the account number and the
statement period having just passed.
Account Sweeping
Account Sweeping is a mechanism for creating automatic payments across a number of accounts at
the COB phase based on the balance reaching a predefined ‘Trigger’ amount.
This functionality runs off two main tables, AC.ACCOUNT.LINK that defines which accounts are to be
linked together in a given sweep, and AC.SWEEP.TYPE, which defines the different styles of, sweep
available.
AC.SWEEP.TYPE
Sweep types can be defined with different transaction codes for the sweep or return sweep. There is
also the facility to plug in a routine for calculating the amount to sweep. If this routine were not present
then the processing would move to do a default sweep to the absolute minimum or maximum value as
set on the link record. Lastly for different sweep types you can define the direction of the sweep as
Maintenance, Surplus or Two-way.
This sweep involves sweeping from the ‘from’ account to the ‘to’ account when the to account falls
below its minimum limit.
This sweep involves the sweeping of funds from the to account to the from account when the balance
in the to account goes above the maximum value
This style is simply a Maintenance sweep and a surplus sweep in one link. In this case, the
maintenance sweep always goes first.
In all cases, either the amount of the sweep is defined in the API routine or it is enough to bring the
balance back to the relevant maximum or minimum amount. The ‘from’ account can never be brought
below its minimum amount.
There is also the facility to enable the sweeping mechanism to take into account the limits of the
accounts used when calculating trigger amounts. This would mean an account with a trigger amount
of £200 and a Limit of £100 would trigger when the balance passed £100. This is achieved by setting
the USE.LIMITS field to YES
For return sweeps the funds will always go into the first account in the ACCOUNT.FROM field. However,
by setting the field PRIOROTISE.OD you can specify the sweep to clear any overdrafts amongst the
‘from’ accounts first. This would mean that if there were two from accounts with the first having a
balance of £200 and the second -£50, the sweep would place £50 in the second account and £150 in
the first.
AC.ACCOUNT.LINK
Accounts will be linked through a new table. It will allow multiple to and from accounts to be linked
from across multi company environments. You would assign the SWEEP.TYPE for that link as well.
The last part of the link would be the relevant minimum/maximum amounts for the to account and the
minimum amount of the from account. The Accounts may be of any currency or customer. If an
account has a posting restriction on it then an override will be raised. Similarly you cannot close an
account that has an active AC.ACCOUNT.LINK.
The easiest way to envisage a ‘Group’ or ‘Cash Pool’ is that of a family tree like structure. All accounts
that would qualify for a cash pool will need to have conditions or rules that dictate when and how much
money should be transferred to another account. As mentioned above the purpose of a Cash Pool is
to be able to move funds together at a higher level, the proviso to this would be to ensure that
accounts lower down in the Group tree remain at a certain level and do not fall into overdraft.
There are currently three styles of sweep, (movement). These are maintenance, surplus and two-
way. Maintenance is when an account balance falls below a predetermined level and needs to get
funds from another account to ‘top-up’ the balance. Surplus is when an account has excess funds
(again above a certain predetermined limit) and moves the excess into another account. A two-way is
a combination of the other two; if it is below a limit then get some funds, otherwise put the excess
balance to the another. The surplus will be extended to enable different accounts to be swept into
depending on the balance on the originating account. E.g. If the balance on account A is 900m, move
700m into account B; everything between 700 – 800m goes into account C, and finally any balance
over 800m goes into account D. If account A in the example above is in overdraft then the rule will not
take effect. There is also another new rule, CASHFLOW rule; CASHFLOW, which in essence allows a
two-way rule to have a budget, assigned to it this enabling rule balance monitoring to be used. So an
account can be given an amount of 500m to use and it cannot take more than this figure in sweeps
unless it adds to it.
There is a parameter file, AC.CP.GROUP.PARAM which users will use to enter the parameters that
will control each group that the bank wish to set-up. There is no constraint on the number of pools that
can be in operation, nor is there a restriction on the number of accounts per group. Within the
parameter file the user will enter such information as the default balance to use for the pool, the
highest level account, (the ultimate target for the funds to be swept up into). There must also be
information added as to the type of sequencing to use and whether or not this is a main group or sub-
group – discussed later.
As with the account sweeping functionality there are basic conditions or rules available that will dictate
what an account does with it’s current funds. They are Maintenance, Surplus, Two-way and Cash
flow. Each rule has it’s own objective, the Maintenance rule is used to get funds from another account
if it’s balance should fall below a certain level. The Surplus rule will place funds above a certain
account balance into another account. The Two-way will be a mixture of Surplus and Maintenance; if
the balance falls below a certain level then transfer funds into this account otherwise transfer money
away to another account. The cash flow rule is more complex in that it involves two balances that the
user will initially define , the CASHFLOWDEFINE - the cash flow balance which limits the monetary
amount that can be passed down to account B from account A and the aggregate balance which will
be a running total of monies passed between the two accounts . These two balances accumulated
together set the limit on monies that can be passed down from Account A to Account B at Start of Day;
so once a year, (or whenever you choose) account A states that account B has a cash flow balance of
700million. Throughout the year, with a combination of the other three rules, the aggregate balance
between A an B is 150 million . This 150 million added to the cash flow balance of 700 million
indicates that Account B may receive up to 850 million swept down from Account A. (E.g. there may
have been a large dividend paid into a lower level account which has swept up into this higher level
account). Until the aggregate balance changes the cash flow balance will now be 850million for this
account. It is possible that an account lower down in the pool has had a major mishap and needs to
top-up an overdraft by 200million thus reducing the amount that account B has in it’s aggregate
balance to -50million DR. In such case the balance now available to Account B is 700 million + 50
million DR = 650 million and this will be the maximum amount that can be used until once again it
changes.
Once the parameter file is set the pool is ready to be set. Every account that is to be part of the pool
will need to have information added to the new file AC.CASH.POOL, this is where users will enter
information unique to this account and detail how this account is to interact with the larger pool as a
whole. It will be in the AC.CASH.POOL file that the rule type, (one of Maintenance, Surplus etc) will be
entered. Also entered, also the sequence number of this account within the pool. If a sequence of 34
is entered here then this account would be processed after account 35 and before account 33. It is
possible to change these sequence numbers at any time while an account is still part of a pool by pool.
By entering 72.1 it would inform the system that this account is to be inserted into the tree-like
structure after number 72 and before number 73. So the account with the 72.1 entered in the
sequence field will become number 73 and number 73 will become number 74. This file will also be
used to enter the frequency of each rule entered for an account. This facility gives banks complete
control over their cash pools, how they run, when they run and how much each account will contribute
to the cash pool.
AC.CP.GROUP.PARAM
In order to start to use the Multi-level Cash Pooling functionality the first thing to do is to define a group
on the parameter file that contains basic controlling information. A simple parameter record would look
like this:
From the example it can be seen that a group can be defined as either a main group or a sub group,
the only restriction being that a sub group must be of the same currency as it’s main counterpart. Also,
in the example above, this sub-group is to be used for Cash Pooling only. The field
SHARED.BALANCES indicated indicates whether a group is for Shared Balances or just Cash Pooling.
Using the Cash pool application, surplus funds in the Cash pool account can be moved to a
MONEY.MARKET Contract by specifying the MAIN.MASTER, MAIN.DEPOSIT, OFS.SOURCE and
MM.OFS.VERSION in AC.CP.GROUP.PARAM. Money market Contract related information
INTEREST.KEY or INTEREST.RATE or INTEREST.SPREAD, CATEGORY, and INT.LIQD.ACCT
could be given in AC.CASH.POOL. Using the above information, MONEY.MARKET contracts will be
created during End of day Close of Business processing and will be matured in the immediate
beginning of day and Principal along with the Interest will be credited as per Cash pool set-up.
AC.SWEEP.TYPE
Released into T24 are a couple of basic rules, which are needed as a minimum system requirement,
SURPLUS, MAINTENANCE etc. These can be added to or amended to tailor them for the bank’s
specific needs. They are entered into the file AC.SWEEP.TYPE. We can see below that the
SWEEP.STYLE has been set to surplus, surplus which means that funds will be placed into another
account depending on the conditions entered into the AC.CASH.POOL file. As you can see the
BALANCE.TO.USE field is blank.. In this case the mandatory field in the parameter file will be used.
Figure 40 - AC.SWEEP.TYPE
AC.CASH.POOL
Once the Parameter file has been set up, the group is effectively ‘Live’, so now is time to assign an
account to a group. As you can see below this is a SUPLUS rule to run daily and above 10,000,000.
So this rule states that; every business day (FREQUENCY) take any amount over 10,000,000
(MAXIMUM.AMT) from account 16446 (the record ID) up to an amount of 500,000 and put it into
account 16478 (LINK.ACCT). The field GROUP.ID indicates that this account (16446) is in the Multi-
level Cash Pool Group called “COUNCIL” which is a sub group of the Multi Level Cash Pool Group
called “HOUSING”. The bank may want to use more descriptive names, names this would be totally
controlled by them.
Table 1 - AC.CASH.POOL
Once the cash pool record is authorised then it becomes part of the pyramid sweep and thus is
included in the overnight sweeping processes , the frequency deciding when amounts are swept.
The amount to be swept depends on how the cash pool record is set up. For a surplus sweep the
MAXIMUM.AMT field becomes mandatory. This is the maximum amount that can be held in the
balance specified for the keyed cash pool record. This is what will trigger the sweep. If the balance is
above the maximum amount then the sweep amount can be decided in the following order:
No matter what sweep amount is processed from the above , if it is greater than an amount entered in
the UP.TO.AMOUNT field then only the value in this field will be swept.
We can specify the amount in MIN.TFR.DR and MIN.TRF.CR, to restrict creation of sweeping
entries for a smaller amount.
When RTN.WITH.SW.AMT field is set after attaching a local routine in the field AMT.ROUTINE in
case of AC.CASH.POOL or in the field AMT.SWEEP.ROUTINE in case of AC.SWEEP.TYPE, the
routine will be called after the sweep amount is calculated by the system, before all updates to sweep
history and other files are made.
The third parameter, sweep amount will be used by the called routine for further validation as per
client’s local requirements and will be passed back to the system for raising the sweep transaction.
If both AC.CASH.POOL and AC.SWEEP.TYPE have routines specified, then the routine in
AC.CASH.POOL will take precedence.
INFORMATION SWEEPING
There is an on line application – INFO.SWEEP.CP keyed by cash pool group which will display any
pending cash sweeps for that day and the resulting account balances for a specified group. No
updates are performed by this application. It is purely for informative purposes and can be run many
times a day.
ON-LINE SWEEPING
There is the facility within cash pooling to run a group or sub group on line as many times per day as
required. A group may be defined to run only once or multiple times per day via it’s group parameter
record. The flag INTRA.DAY may be either SINGLE or MULTI. Single meaning a sweep of this group
can only occur once per day, which may be on line or during the overnight batch processing . Multiple
means that a group may be swept many times a day as well as during the overnight batch process. A
record of all accounts swept is held in the AC.ACCOUNT.SWEEP.HIST application.
In the above AC.CP.GROUP.PARAM example the group COUNCIL may be run many times per day.
It is however a sub group , part of the main group HOUSING. The main group may be single or
multiple. If the main group was single and run once , it would still be possible to keep processing
COUNCIL as many times as was required. If however HOUSING was multiple and COUNCIL was
single then no matter how many times HOUSING was processed , the links within COUNCIL would
only have been swept the once.
There is a further option in the cash pool record that allows the user to specify where this pool record
may be processed.. The SCHEDULE field may contain either INTRA, EODCOB or blank. If INTRA then
this pool record may only be included in the sweep via on line processing. If it was due to be
processed today but no online processing was performed, then during the end of day ,Close of
Business the frequency dates would be recycled but no funds would be swept.
If SCHEDULE contains COB then this pool will only be processed during the Close of Business. If left
blank then the pool record may be processed both on line and during the end of day. Close of
Business.
1. The SCHEDULE field on it’s corresponding group parameter record is either blank or EOD’COB.
2. The INTRA.DAY field on the parameter is either MULTI or SINGLE and with no online processing
taken place
SWEEP REVERSALS
The REV.GROUP.CP application allows you to reverse and Close of Business cash pool sweep. Enter
the group name with the ‘V’ function and all accounts swept during the previous Close of Business run
will be reversed. This application does not work with intra day sweeping..
SWEEP RERUNS
Sweep Reruns
The RERUN.CP.SWEEP application allows you to rerun a sweep only after it has been reversed. It
allows the user to enter any back value transactions that may have been omitted from the previous
sweep and these transactions will be included in the new sweep. The sweep can only be rerun once.
Any transactions entered before the rerun with a value date of today will not be included in the sweep
as it is a rerun of the last working day’s sweep only.
SWEEP PRIORITIES
Sweep Priorities
During cash pool processing, either Close of Business or on line all cash pool records with a
frequency date less that or equal to the processing date will be swept.. As there can be many links on
one cash pool record you may get the scenario where two links are to be processed on the same day,
e.g. a link to run daily will eventually coincide with a weekly link.. This obviously would make no sense
and so functionality exists to assign each link a priority to dictate which link is to be processed. A
RULE.PRIORITY field exists on the group parameter record and it’s valid values are ‘FREQUENCY’
and ‘PRIORITY’.
The FREQUENCY option means that during Close of Business when a link date is to be cycled , if a
link already exits with the cycled date then the date will continue to cycle until a unique date is found.
This therefore eliminates the possibility of two links running together.
The PRIORITY option allows the user to assign priorities to each individual link so should it occur that
there are more than one link to process, then the link with the highest priority wins (1 being the
highest). When entering a pool, if its corresponding parameter record is set to use priorities then the
user is forced to prioritise each link in the pool.
SHARED BALANCES
Shared Balances
Shared Balance processing is an extension of Multi-level Cash Pooling where accounts which are
grouped together, as described above, have their combined balances (Balance + overdraft) checked
when a transaction is passed across one of the accounts in the group. If the transaction is larger than
the accounts balance and would normally put the account into overdraft then the usual overdraft
processing that T24 performs will be extended to consider all the other accounts balances in the group.
If an account is to be part of Shared Balance checking then first a parameter record must be set, first
(as described above) with the SHARED.BALANCE field set to YES. Now all accounts entered onto the
AC.CASH.POOL file for this group will be considered for cash pooling. If an account is for shared
balance checking then on the AC.CASH.POOL file it will have the frequency set to daily and the
amount set to 100% of the balance. This is to ensure that during the end-of-day routines all the money
that was checked will be moved as expected.
If an account is for Shared Balances then there can be no other Cash Pooling against it and there can
be no online movement of funds except during the Close of Business. The one proviso to this is that a
sub group could pass funds into a shared balance group which it is not part of.
If the option has been set in the AC.CP.GROUP.PARAM to allow adjustments to sweeps already
performed, then when a back-valued entry is passed across one of the monitored accounts the system
will create an adjustment. The adjustment could be a new sweep, the cancellation of a sweep, or an
adjustment to increase or decrease the amount that swept.
If the result of these adjustments affects another monitored sweep account then that account will also
be checked to see if any adjustments are required.
The adjustments are value-dated meaning that each value date from the back value to the current
date is assessed for any impact on the sweeps performed.
Ideally any back-value should be processed but given the complex and varying scenarios it would be
impractical to expect any system to re-calculate cash pool sweeps for more than a few days, a limit of
31 days has been set. This value van be reduced by setting field BACK.VALUE.CAP on the
AC.CP.GROUP.PARAM record.
Example
In this example we will sweep the funds in Account 40568 to 40576 and keep the balance at zero. The
only time a sweep may not be needed is if the amount to sweep is less than $10.00, as these would
be considered too small to merit the operating costs or any transactional charges the bank may
impose.
Here we can see that the $25,000 has been swept out of the account, note the value date of the
sweep is the same as the credit date.
The entry, which was missed on the 9th Sep 2005, was a debit for $5,000 has now been posted. This
means that the sweep that took place was for too much and needs correcting
To correct the over sweep from the previous day an adjustment sweep has now been posted for
$5,000. The value date is set to the 9th Sep 2005 so from an interest calculation viewpoint the account
has a zero balance, the debit of $5,000 will not cause an overdraft since it is compensated by the
adjustment.
A file CORR.GROUP.CP records details of all back value processing. It is keyed on the account
number to be back back-valued, the value date of the back value transaction and a sequence number.
(it(It is possible that an account may receive more than one back value transaction.) Each record will
hold the details of all accounts re swept as a result of the original accounts new balance.
As many accounts may be affected, the key to CORR.GROUP.CP is help in the account sweep
history record of every account included in the back value process.
A discretionary relationship is where the accounts are managed by the bank and are not subject to
restrictions such as maximum number of debits. This cash pool set-up is similar to the normal cash
pool.
To effect adjustment entries, when there is are back value dated entries in Cash pool accounts, in
AC.CP.GROUP.PARAM, the BALANCE.TO.USE should be VALUE.DATED with BACK.VALUE.ADJ
set as “Yes”. The AC.CASH.POOL can be created like a normal cash pooling record with the ID and
link account along with the sweep condition.
The start date for back value processing is arrived at from the latest among the following:
For example:
• Cash pool record got created on 05th Jun, then the LAST.MAINT.DATE is 05th Jun .
• BACK.VALUE.CAP is mentioned as 10 days in AC.CP.GROUP.PARAM.
• On 8th Jun back value-dated transaction done with value date as 01st Jun.
Then start date for back value adjustment starts from the latest of the above, i.e. 05th Jun and the back
value adjustment entry will be passed from 5th Jun even though the actual back value dated is 01st Jun.
If any change is done to an existing AC.CASH.POOL record, then the LAST.MAINT.DATE will be
updated with current system date and old links details will be ignored for back value date adjustment
processing.
For Account 123456 Cash pool condition record created to sweep any amount above USD10000 with
frequency as Daily. The Cash pool group has the BACKVALU.ADJ Flag is set to YES.
Following are the sweep history details.
Based on the revised account Balance, the following entries will be passed for Account 123456 with
the respective value date.
Non-discretionary type of accounts is where there are local requirements governing how many entries
can be passed each month over the client’s account.
Bank has two type of accounts i.e. DDA &The Bank has two types of accounts, i.e. DDA and MMDA.
The surplus in the DDA account is transferred to MMDA and any short fall in DDA, the DDA balance
will be transferred from MMDA. There is a restriction on debit entries to the MMDA account of say only
5 entries per month and no such restriction on DDA accounts.
For the above requirement, set the MULTI.RULE as “YES” along with the balance to use as
VALUE.DATED and BACK.VALUE.ADJ as “Yes” AC.CP.GROUP.PARAM.
In AC.CASH.POOL, give the DDA account as an ID account and set up the MMDA account as a link
account with the sweep type as Surplus and frequency as “Daily”. Based on the restriction on the
number of entries, set the appropriate frequency. In this case the number of entries are restricted to 5
–5, hence the frequency is given as “WEEKLY”.
“WEEKLY”
Surplus sweep will happen daily and if there is any back value dated entries to the DDA account,
which will result in a Surplus sweep, adjustment entries will be passed along with the normal sweep
amount.
Because of the restriction on debits to MMDA, any shortfall in DDA will be passed as a consolidated
entry by posting the highest shortfall amount with the value date as the first shortfall date for a given
frequency in this case weekly.
When both sweep type frequencies fall on the day, then maintenance will be executed first by posting
the highest short fall amount with value date as the first short fall date- if any exists, or from the last
maintenance frequency run date, followed by the surplus sweep from the date next to the highest
short fall date
After all postings up to yesterday have been included in the work files the balance of our example
DDA looks as follows:
Our work file will have selected the oldest date as July 10th as this is the earliest date where there is a
shortfall. The largest shortfall occurs on July 11th so we need to credit the DDA account with USD
28,000 to leave a balance of USD 5,000.
In order to limit the number of correcting entries to pass, this credit will be posted with a value date of
the earliest shortfall. If we were checking the balances of the account for each date before the daily
sweep job was run this would give a theoretical balance picture as below:
During month end, maintenance sweep will run irrespective of whether maintenance frequency is
there or not
.
Any debit reversal to the surplus amount which is already swept will not be allowed as it will break the
number of debit transactions to MMDA. However the details of the transaction will be written in the
Exception log file with the amount to be reversed along with the AC.CASH.POOL id.
Also gives us the original balance &and original sweep amount and account balance after back value
dated adjustments &adjustments, and revised sweep amounts along with the date and adjustment
amount entry, which is passed.
The field LAST.MAINT.DATE on AC.CASH.POOL controls how far back any adjustments can be
made to. Any entry earlier than that date will be processed as if it equals that date.
This date may be modified if the underlying rules have been modified and the date will be reset to the
date the changes are made.
Payment Netting
Overview
The payment netting facility provides the ability to automatically net payments with a counter party in
the same currency and with the same value date. Netting is permitted only when a
NETTING.AGREEMENT is held with the counter party. The netting agreement has a finite life and
indicates which currencies may be netted with this counter party.
Net payments must be agreed and approved before the payment is generated. This is done using the
NETTING application. T24 will automatically consolidate payments eligible for netting into a ‘netting
group’, which will appear as a single record on the NETTING application. This record may then be
reviewed and confirmed with the counter party. Authorisation of the NETTING record will generate the
single netted payment.
During the review of the NETTING record, individual payments may be rejected for inclusion in this net
payment. Any payments thus rejected will remain in suspense and will automatically be included in the
next netting group created for the same currency, customer and value date. Once a payment has
been selected for netting it can only be made using the NETTING application.
Netting groups may be created during the T24 overnight processing (based upon forward deals) or on-
line (using the CREATE.NETTING application) for spot deals.
The accounting entries for payments that are to be passed across a suspense account, which should
have a zero balance once all net payments have been sent.
Individual payments that are to be net are recorded on the NETTING.ENTRY application. This is a
‘live’ file; i.e. it is not available for input. There is one NETTING.ENTRY record for each contract.
Payments that are netted pass across a suspense account. For example if we are paying US dollars
to a counterparty with a value date of spot, and are expecting one receipt of US dollars funds from the
same counter party with the same value date then if we are not netting payments, T24 will generate
the following entries:
If the payments were netted then T24 would generate the following:
The payment netting facility requires suspense accounts. Setting up these accounts is done in two
stages: an ACCOUNT.CLASS record is created and then a suspense account is opened which will act
as a template for all the suspense accounts.
The ACCOUNT.CLASS record to be established has a key of NETTING. This record is used by T24 to
determine the characteristics of the suspense accounts to be set up to hold the netted payments.
Before setting up the record a new CATEGORY code should be created for netting suspense
accounts. This code will be referenced by the ACCOUNT.CLASS parameter.
Once this is complete the internal netting suspense accounts may be opened using the ACCOUNT
application. The id of these accounts is the same as any other internal account, i.e. the CURRENCY,
CATEGORY, and a four-digit identifier. E.g. USD149550001.
The ACCOUNT.PARAMETER contains a field (NETT.PAYMENTS), which must be set to YES for
payment netting to take place.
All contracts whose payments may be netted contain a field called NETTING.STATUS. This field may
be used at contract input time to stop the payments arising from this contract being netted.
The NETTING.ENTRY application contains details of all entries being netted. Records are created
here upon authorisation of the original contract. When an individual payment has been successfully
included in a net payment then its entry on this file is updated.
The NETTING application is the main control over the net payments process. All individual payments
selected for netting are combined into a single netting record for the counter party, currency, and value
date combination. This record may then be reviewed and amended if necessary. Once the net
payment is correct the netting record is authorised and T24 will create the single net payment or
receipt accounting and delivery messages.
Individual payments may be dropped from a net payment at this point. If dropped they will remain in
suspense until captured in another net payment. Therefore once a payment has been selected for
netting, it can only be paid using the NETTING application. Individual payments may, of course, be
removed from netting by reversing and re-inputting the source contract and ensuring that the
NETTING.STATUS field is set to NO on the re-input.
Parameter Files
Figure 57 - ACCOUNT.PARAMETER
Example. LD-INT, which refers to the interest liquidation account in the LD application, can have a
record in AC.SYS.CODES as follows:
CUSTOMER.SSI is an application which is used to define the Standard settlement instruction (SSI) for
a particular customer which is then used to default settlement account fields such as DRAWDOWN
ACCOUNT, PRINCIPAL LIQUIDATION ACCOUNT & INTEREST LIQUIDATION ACCOUNT,
in applications such as LD, MM, FX, MG, NETTING, BL.BILL, PD.CAPTURE &
PRE.SYNDICATION.FILE. A new field CUSTOMER.SSI has been added in
ACCOUNT.PARAMETER to control the above feature.
If this field is set to “YES” (along with DEFAULT.ORDER field of the required SYS-CODE field as
blank) then during input of contracts for the above applications, the system first checks for a matching
record (combination of CUSTOMER, CURRENCY, SYSCODE or “ALL”) in CUSTOMER.SSI to
default in the relevant settlement Account fields. During capture of a contract the SSIs defined have
the highest priority for defaulting.
In case the Counter party does not have a record for the above combination in CUSTOMER.SSI, then
overrides are generated at the application level and the settlement accounts are defaulted as per
existing functionality of the respective application.
In case the CUSTOMER.SSI field in ACCOUNT.PARAMETER is set as ‘blank’, then the system will
not allow input in CUSTOMER.SSI application and uses the existing functionality of the respective
application for defaulting settlement accounts.
Example: Create the following record in CUSTOMER.SSI application for customer no. 1044 (Michael
Dell):
While inputting a LD contract in USD for the above customer, the settlement accounts get defaulted as
shown below using above set-up:
If a single contract will create both credits and debits to an account, if the net effect of the contract is to
credit the account, it is possible to suppress the override generated for the debit side of the transaction.
For example, if a discounted loan is arranged for a client, whereby the customer has a balance of £10,
receives a credit of $1000 for the loan, but also a debit of $100 for the upfront payment of interest.
The system would usually generate an override specifying that as the customer is being debited $100,
the client is overdrawn by $90. However, it is possible through the fields NET.OD.APPL,
NET.OD.OVERRIDE on ACCOUNT.PARAMETER to net off the differences so as the credit of $1000
exceeds the debit of $100, the override can be suppressed.
The applications for which this functionality is needed is entered into the NET.OD.APPL field and it
can be switched on or off by setting NET.OD.OVERRIDE as ‘YES’ or ‘NO’. Currently this functionality
is allowed only for LD – LOANS.AND.DEPOSITS.
In practise where T24 has replaced an existing system it may be a short-term requirement to allow the
access to client accounts using the old account numbers. In order to allow this, a special parameter
file, ALT.ACCT.PARAMETER needs to be set-up. This tells T24 how the other system account
number structure was defined.
Once this is set up it is possible to enter the old account number on the ACCOUNT record in the field
ALT.ACCT.ID.
An index is kept in ALTERNATE.ACCOUNT, the id is the external system account number and the
single field GLOBUS.ACCT.NUMBER contains the T24 equivalent.
Extending ACCOUNT type fields to enable IBAN and other account numbers
The standard maximum length of ACCOUNT type fields is 16. However, due to requirements to enter
extended account numbers, such as IBAN numbers, it is possible to extend this maximum limit
through the EB.OBJECT application.
On the ACCOUNT record for EB.OBJECT, the maximum length of input to an account type field is
specified. In the above example, it would then be possible to type up to 36 characters into account
type fields.
This file contains various types of restrictions that may be defined, such as ‘Post No Debits’,
‘Whereabouts Unknown’.
The system will automatically close any ACCOUNT that has a posting restriction in the90-99 range of
90-99 as soon as all balances are zero. Posting restrictions in the range 80-89 are used for accounts,
which are pending closure.
Where an ACCOUNT has a value in the field POSTING.RESTRICT and attempts are made to pass
entries to it, an override message will be issued.
REFERAL -– Referral
A referral is only the reporting of the account to the account officer by means of an overnight report. A
posting restriction (a stronger form of referral) should be used if an override message at input is
required.
The REFERAL table contains the pre-defined referral conditions. These are then loaded onto the
ACCOUNT record in the REFERAL.CODE field. Multiple referral codes may be specified on an
account.
This table file has two main types, ACCOUNT and CLASS.
The use of CLASS as the RECORD.TYPE is used to identify a group of ACCOUNT records (e.g. under
a heading like NOSTRO) by matching the account details against those held in the ACCOUNT.CLASS
record.
When the RECORD.TYPE is ACCOUNT then the CATEGORY code must be valid and in the range
10000 to 19999.
When the RECORD.TYPE is CLASS the CATEGORY and SECTOR code fields are treated as multi
value associated fields. Either field may be null, but not both at the same time. Duplications of
CATEGORY and SECTOR code combined are not allowed within one entry on the ACCOUNT.CLASS
table.
The purpose of this table is to define defaults for ACCOUNT statement details when opening new
ACCOUNT records.
This table determines whether the default ACCOUNT.STATEMENT record is set to produce
statements when there has been no movement, descriptive statements, interest and charges
statements and advices and tax advices and the minimum number of months for a statement to be
produced if at all. If no record exists the default will be 'NO' and the minimum frequency will be 6
months.
Figure 81
Figure 82 - AC.STMT.PARAMETER
When a new ACCOUNT is opened, an ACCOUNT.STATEMENT record, specifying the date and
frequency for printing account statements is generated automatically by the system. The default
frequency is determined by the STMT.GEN.CONDITION table.
Figure 84 – STMT.GEN.CONDITION
ACCOUNT.STATEMENT is an application, which allows the printing of account statements for all
Accounts.
The PRINT.STMT field in ACCOUNT.STATEMENT is an optional input, and input can only be made
for Internal Accounts. Input can be Null, Yes or No.
If the field PRINT.STMT is set to Null or Yes, the statement will be printed as normal. If however this
field is set to No, the printing of the account statement is bypassed (i.e. this indicates that the
statement will not be physically printed out but all associated tables will be updated normally, as if the
statement was printed).
SWIFT MT492
The ACCOUNT.STATEMENT application also allows for the production of a SWIFT MT942 messages.
Three fields on the ACCOUNT.STATEMENT record control MT942’s:
Figure 92 SendingMT942
These message types can also be produced on an ad-hoc basis as detailed in the next section.
A customer may authorise another financial institution to receive statements and transaction reports of
his accounts. There is a facility to produce Interim Transaction Reports (SWIFT MT942) on-line on an
ad-hoc basis. Requests are entered through the application DE.MT942.REQUEST where T24 will
produce an Interim Transaction Report on the account specified. Note the 'V' function is required to
invoke the message creation.
Figure 97
The record id for this parameter file is the condition group and the currency of the account(s). Rules on
deposits, withdrawals and premium interest applying to accounts belonging to condition group and
defined for specific currency are entered here.
Further the record id for the parameter file may be suffixed with a date in the YYYYMMDD format. This
date specifies that the record is a change request for the condition group &and currency combination
specified in the first part of the key. The request records are processed in the Close of Business
processing and the new values of the parameters are passed into the active record using the values
from this request record.
It is recommended that the copy function be used to create the request record from the active record
prior to changing any parameters.
Additionally, where the requirement exists to record and report transaction violations on an account or
accounts within a particular group, this may be achieved by defining the threshold permissible before
the violation occurs and the transactions eligible to trigger a violation. The following example
demonstrates how this may be achieved.
In the example above, for ACCOUNT.GROUP 1, the number of transactions, with a transaction code
of 2, 84 or 85, permissible within a statement period, may collectively add up to, but not exceed, 5
transactions. If this threshold (TXN.THRESHOLD) is exceeded, the account is in violation and this will
be recorded on the account violations file (AC.VIOLATION). The above example is set up to record
violations if more than 5 cash withdrawals or more than 3 cheque withdrawals occur within the
statement period defined for the account group into which this account falls.
The RETENTION.PERIOD field defines how long records remain on the AC.VIOLATION file before
being transferred to the history file, AC.VIOLATION.HIST. Additionally, this field also determines when
transactions are deleted from the history file. They will be deleted after twice the period defined. For
example, if '12M' is entered in this field, a violation record will remain on the AC.VIOLATION file for 12
months, it will then be transferred to the AC.VIOLATION.HIST file. The record would then remain on
the AC.VIOLATION.HIST file for a further 24 months before being deleted.
In the example above, for ACCOUNT.GROUP 1, the number of transactions, with a transaction code
of 2, 84 or 85, permissible within a statement period, may collectively add up to, but not exceed, 5
transactions. If this threshold (TXN.THRESHOLD) is exceeded, the account is in violation and this will
be recorded on the account violations file (AC.VIOLATION). The above example is set up to record
violations if more than 5 cash withdrawals or more than 3 cheque withdrawals occur within the
statement period defined for the account group into which this account falls.
The RETENTION.PERIOD field defines how long records remain on the AC.VIOLATION file before
being transferred to the history file, AC.VIOLATION.HIST. Additionally, this field also determines when
transactions are deleted from the history file. They will be deleted after twice the period defined. For
example, if '12M' is entered in this field, a violation record will remain on the AC.VIOLATION file for 12
months, it will then be transferred to the AC.VIOLATION.HIST file. The record would then remain on
the AC.VIOLATION.HIST file for a further 24 months before being deleted.
If a single limit default field in ACCT.GROUP.CONDITION is set to 'Y', then for all new account
opened, under the group single limit field in account is defaulted with 'Y'.
An option of premium interest on accounts has been provided for in T24. The actual parameters used
in the calculation &and processing of premium interest on the accounts is specified on this application.
The premium types defined here are linked to the account via the ACCT.GROUP.CONDITION record.
The INTEREST.BASIS field in this table may not be set to the ‘C2’ interest basis.
An account that capitalises premium interest will create details of the movements that were used in the
calculation process. This file details all such movements with information on the value date, amount,
date from which premium was paid, date to which premium was paid, number of days for which
premium was paid, unrounded premium amount and the rounded premium amount.
Some types of accounts can be set up to have notice withdrawal conditions. In such a situation for a
withdrawal to be effected on the account a notice must have been given that satisfies the notice
conditions set up on the ACCT.GROUP.CONDITION application. These notices are given through
this application.
Default NOSTRO accounts for currency and application are entered in the file NOSTRO.ACCOUNT.
Defaults can be set for each application, even for transaction types within that application. FOREX has
a unique option where the dealer can enter a letter indicating which NOSTRO should be used, these
equate with the input order; so the first FX default would be A, the second B and so on.
The PAYMENT.STOP table allows all payment stop instructions to be recorded. These are input
against the account to which they relate. All stop instructions for one ACCOUNT number is maintained
on the same record. The DATA.CAPTURE, TELLER and FUNDS.TRANSFER applications, then use
this record to validate against when processing a cheque.
Charges and taxes can now be collected for the stop payments recorded. Charges can be a valid
charge or commission code from FT.CHARGE.TYPE or FT.COMMISSION.TYPE and can be
defaulted from the PAYMENT.STOP.TYPE or can be defined by the user for the particular stop
payment. If a tax is associated with these charges then the tax is also booked. When the
WAIVE.CHARGE field is set to ‘NO’ or holds no value then the charges can be defaulted from the
above PAYMENT.STOP.TYPE as given below.
Figure 111
SWIFT MT111
SWIFT message MT111 (Request for Stop Payment of a Cheque) can be produced from the
application EB.MESS.AGE.111.
SWIFT MT112
SWIFT Message MT112 (Status of a request for Stop Payment of a Cheque) is produced from the
PAYMENT.STOP application, via Soft Delivery.
PAYMENT.STOP.TYPE
The PAYMENT.STOP.TYPE table allows the definition of up to 99 reasons for stopping a payment
(e.g. Cheques Lost, Cheques Destroyed etc.).
The table is used by the PAYMENT.STOP application to describe the reason for each stop instruction.
Figure 114
When the payment stop record is authorised the details of the charges and taxes collected are moved
to a live file PAYMENT.STOP.BALANCES whose id is the same as the PAYMENT.STOP file.
Inputting a value of ‘YES’ in the STOP.END.FLAG field can revoke an authorised stop payment.
PAYMENT.STOP.HIST.
CHEQUES. STOPPED
The stopped cheques are written in the format ACCOUNT NO.*CHEQUE NO individually for each
cheque as depicted below.
CHEQUE.NUMBER
ACCOUNT.NO
Earlier, the cheques presented as stopped are written to the PRESENTED.CHQS and STOPPED.CHQS
fields of CHEQUE.REGISTER.
Now with the introduction of concat files like CHEQUES.STOPPED and CHEQUES. PRESENTED –
CHEQUES.PRESENTED, these fields are not updated in the CHEQUE.REGISTER. Only the used
cheques field is updated to arrive at the number of cheques in hand.
CHEQUES.PRESENTED
ACCOUNT.NUMBER CHEQUE.NUMBER
CHEQUE.TYPE
REVOKING PAYMENT.STOP
Earlier to this development –REVOCATION/ WITHDRAWL of payment stop was handled through field
called STOP.END.FLAG and the associated field called APPLY.DATE which is defaulted to the
system date once the STOP.END.FLAG is entered as YES. The withdrawal instructions for a single
cheque when the STOP.PAYMENT instructions contains a RANGE was not possible earlier. Now
with the introduction of 3 new fields the above difficulty is overcome.
Three new fields have been added in the payment stop file are:-file:
(A) MOD.PS.CHQ.NO Cheque number for which payment stop instructions have to be
revoked is input here.
(B) MOD.CHQ.TYPE Indicates the cheque type to which the above cheque
belongs to.
(B) MOD.CHQ.TYPE Indicates the cheque type to which the above cheque belongs.
(C) MOD.PS.DATE The date from which such REVOCATION is applicable.
After the enhancement the newly introduced field MOD.PS.CHQ.NO will have a drill down facility which
lists the cheque numbers that have been stopped for that particular account number (since the
account number is the id in PAYMENT.STOP. FILE]of the PAYMENT.STOP file).
The user will have the option to revoke the stop payment instructions for a particular cheque number
or a range of cheque numbers at his discretion.
After revocation of the stop payment instructions– the data is written to PAYMENT.STOP.HIST as was
the work flow earlier.
NETTING.PARAMETERS
The NETTING.PARAMETERS application controls the payment netting facility. Only one record may
exist (with the id of the system). It specifies the TRANSACTION codes to be used for netting
payments, the number of days prior to the payment value date that netting records should be created,
and the period that history should be kept before netting information is purged from the system.
NETTING.AGREEMENT
NETTING.AGREEMENT
The NETTING.AGREEMENT application contains agreements with counter parties to net payments of
the same currency and value date. One agreement can be made with each counter party
(CUSTOMER) and the agreement may specify that only payments of particular currencies may be
netted and only payments arising from particular T24 applications may be netted.
The agreement lasts for a finite period as specified in the start and end date fields. The agreement
may be input and amended at any time.
Figure 128
NETTING.AGREEMENT
NETTING.ENTRY
The NETTING.ENTRY file contains details of all individual payments that are netted. The id of the
records is the original contract id. The record contains details of each payment arising from the
contract where the payment is being netted.
The NETTING.ENTRY record also holds details of the status of each individual payment. Each
individual payment can have one of two statuses -statuses; ‘waiting to be included in a net payment’
and ‘included in a net payment’. The status is recorded in the field NP.REF. If this field does not
contain a value then the individual payment is waiting to be netted. Once the individual payment has
been included in a net payment then this field will be updated with the reference of the NETTING
record.
CREATE.NETTING
This application is used to create netted payments on-line. Verification of a CREATE.NETTING record
will activate the payment netting process. This will combine all outstanding payments that match the
specified criteria into NETTING records. These can then be reviewed, amended if necessary, and
authorised thus creating the net payments.
Payments can be netted for any combination of counter-party, currency and value date. Thus a record
can net all outstanding payments for a single counter-party, only those for a single currency for that
counter-party etc. The specification of counterparty is mandatory.counter-party is mandatory.
NETTING
The netting application is used to review, and modify if necessary, net payments. T24 creates
NETTING records automatically during the overnight batch run or on-line using CREATE.NETTING.
These records are created with a status of ‘hold’ ready for review and possible input. Once a
NETTING record has been confirmed as being valid (possibly following confirmation with the
counterparty)counter-party), it should be authorised. T24 will then generate the single net payment.
- NETTING
Settlement details, such as bank to bank-to-bank information, may be added to the NETTING record
and will be used on the resultant net payment. Additionally individual payments may be removed from
the netting record if necessary by using the NETTING field. Payments removed from the record will
remain in suspense until another netting record is generated (either in the T24 batch or by the
CREATE.NETTING application).
Internal Files
This is an internal file containing details of account balances and activity, used to calculate interest
and charges. It is also used in the calculation of average balances in the Management Information
module.
Details are held in separate records for each account for each month in which there has been any
activity over the account or in which the value dated balance changes. Full details of all balance
changes are included as well as details of transaction activity by transaction code.
This is an internal file containing details of account balances, activity and availability of funds used in
penalty charge processing. It is also used in the correct implementation of some rules that place
restrictions on the movements on the accounts. These rules are specified on the
ACCT.GROUP.CONDITION application.
Introduction
The Interest and Charges system is part of the essential core of T24 and it is used to define and
calculate the credit and debit interest, and charges on the ACCOUNT records within the database.
Interest and charges are only applicable to customer ACCOUNT records. These are calculated in the
Close of Business processing and applied to the accounts at user-defined intervals.
ACCOUNT records can be defined into logical groups with different debit and credit interest conditions
applied only to those groups. However, it is also possible to define special conditions, which apply only
to an individual account within a group.
Conditions for the calculation and application of interest and charges are specified for groups of
accounts and can be overridden with special conditions for individual accounts.
Account groups are determined automatically on the basis of CUSTOMER and ACCOUNT details.
The criteria used and their order of priority are stored in the user-defined tables,
CONDITION.PRIORITY and ACCT.GEN.CONDITION.
Interest Calculations
Interest may be calculated on a daily, average, or highest/minimum balance basis using value dated
balances.
A further restriction can be imposed on the minimum balance calculation, by calculating the interest on
the minimum balance between two dates (for example – between 10th and the last day of the month,
both days included). These dates can be customised at account or group level, in the applications
ACCOUNT.CREDIT.INT &and GROUP.CREDIT.INT.
For example, assume a credit balance on the 31st of the month of 2,500 and an Account Interest
record, which specifies an applicable rate of 10 per cent to be calculated on a MINIMUM balance. If
the following account balances have been recorded for the account in ACCT.ACTIVITY:
If no dates are specified then on the 31st the account will receive a payment of interest calculated on
100 at 10%. However, if the interest is to be calculated on a minimum balance for a specified period
within the account capitalisation period, i.e. for a starting date of 10th and an end date of 31st, then the
account will receive a payment of interest calculated on 500 at 10%.
Accounts opened or closed after or before the start date of the specified range can be customised not
to accrue any interest for that period. These flags can be customised at account or group level, in the
applications ACCOUNT.CREDIT.INT &and GROUP.CREDIT.INT.
The movements/balances on different accounts in the same currency can be combined and interest
calculated on the net result.
Different rates can be specified for different balance levels and may be linked to the same or different
basic rates. The rates may apply to the whole of the balance or to the part between two balance levels.
Using group level conditions, it is possible to specify limits on individual accounts so that one rate can be
charged up to the limit and another rate when the limit has been exceeded.
Interest can be calculated on a 360/360, 366/360, 366/366, 360/366, 366/365, 366/364 and 360/365 days
basis.
Back valued entries generate automatic adjustments to previously calculated interest. For any accounts
where interest conditions or rates are changed with effect prior to the last interest application, the system
generates adjustments on request.
Interest may be applied daily, every working day, every 1-91-9 weeks, twice a month on the 15th and
the last day or every 1-991-99 months on any day of the month. The application dates can be
specified at group or account level. Cycles may be different for debit and credit interest.
Special interim applications may be requested without affecting the regular cycle.
It is possible to defer debit interest and / or charge application and/or charge applications to an
account in T24 in order to provide the facility of Pre-Notification to the customer. This facility has been
discussed as another heading in this section.
Daily accrual
It is possible to accrue interest normally on a monthly basis and specify certain types of ACCOUNT
with daily accrual. Daily accrual can be set for local currency accounts, foreign currency accounts or
both using the DAILY.ACCR.ALLTYPE field on the ACCOUNT.ACCRUAL record. Alternatively daily
accrual can be set for specific categories or accounts using the DAILY.ACCR.CATG and
DAILY.ACCR.TYPE fields.
It is possible to waive credit interest depending on the number and type of transactions passed over
the account. The feature is controlled with the help of the fields TXN.THRESHOLD, TXN.CODE.GRP
&and WAIVE.CR.INT. This has been illustrated below:
As shown in the above figure all accounts that belong to the group ‘1’ denominated in USD will check
if a transaction code ‘2’ was passed on the account. If this is the case then credit interest on the
account will be waived. (Note only calculations will be performed and stored on the INFO.ACCT.CR
and INFO.ACCT.CR2 files in such a case).
Details on the status related to the above will be stored on the AC.VIOLATION file as illustrated below:
Special Cases
Interest may be paid or received from another ACCOUNT in the same currency.
Credit interest may be calculated for the purpose of offsetting debit interest only and not for application.
In this case debit and credit interest application dates must be the same.
Interest may be suspended for specific accounts, i.e. not posted to profit and loss.
It is possible to calculate interest for information only and not accrue or apply it, e.g. for NOSTRO
ACCOUNT records.
Detailed interest statements may be printed for specified ACCOUNT records whenever interest is
applied.
Certain additional charges based on the debit interest application may be applied on the same date,
these include:
ACCOUNT maintenance charges may be levied monthly, quarterly, six monthly or yearly, always at
the end of the appropriate month. The same application cycle is used for all ACCOUNT records. There
are two main types of charges as follows:
Balance based:
A flat charge can be levied if a certain average or minimum balance is not maintained. A range of
charges for different balances may be specified.
Transaction based:
Charges can be made for the transactions passed over an account. These may be based on the
number or the volume of transactions and may be different for debit and credit or for each transaction
type. Each transaction type may be included or excluded from the calculations. The various types of
transaction charges are as follows:
• Number of credit
• Number of debit
• Turnover credit
• Turnover debit
• Transaction type
Charges may be combined into one account entry or applied separately. Free, minimum and
maximum amounts can be specified for each charge.
Separate charges can be defined for specific currencies and local currency charges used as the
default for all non-specified currencies.
On specified ACCOUNT records, charges may be calculated for information only and then waived.
Charges may also be waived if a certain average or minimum balance is maintained, if the amount of
the charge is below a value worth charging or if the account has been into debit.
It is possible to specify that charges do not apply to foreign currency ACCOUNT records.
Notional credit interest can be calculated and offset against the charges.
The ‘Code of Good Banking Practice’ in the U.K sets out standards of services that customers should
be able to expect from their banks. One element of the code is that the bank should give all private
individual customers 14 days notice before debiting their accounts with interest and/or bank charges
relating to overdrafts.
Debit interest and charges are calculated on the capitalisation date, the positing of the amounts to the
customer account may be deferred for a number of days (e.g. 14 days). In this case the interest and/or
charges are posted to a suspense account on the capitalisation date, then posted to the actual
account (and backed out of suspense) on the deferred date. Where interest and/or charges are
deferred the details of the calculations are held in the application AC.PENDING, which allows
adjustment of the amounts.
The number of days by which debit interest and/or charge related debit amounts scheduled for posting
to accounts are to be deferred is specified in the ACCT.GROUP.CONDITION application. This also
controls the suspense account category and is used for deferring interest/charges.
Subsequent corrections performed on accounts will take place on the next capitalisation date.
The pending debit interest and/or charges will be transferred from the suspense accounts to the actual
accounts after the notice period has been served (i.e. during the Batch run of the deferral date).
The amounts of debit interest, charges and, if applicable, taxes will be stored in a standard T24
application AC.PENDING that will be accessible to all types of reports and enquiries. It will be possible
to make adjustments to, or even waive completely, the debit interest and /or charges pending on the
account. This has been illustrated below:
MTn90 advising a customer of a charge, interest or adjustment, already debited from their
account. No accounting entries are produced from this transaction.
BOOK This raises accounting entries when payment of an unknown charge is received.
CHARGE This
can raise both accounting entries and Swift MTn90/MTn91
CHARGE This can raise both accounting entries and Swift MTn90/MTn91
REQUEST This
raises a MTn91 requesting charges, interest or other expenses from another financial institution, which
were previously unknown to them. No accounting entries are produced from this
transaction.
REQUEST This raises a MTn91 requesting charges, interest or other expenses from another
financial institution, which were previously unknown to them. No accounting entries
are produced from this transaction.
You must always set the STATUS field to PAID if accounting entries are required, as this is the status
that generates the entries.
TAKEN Account entries for the charge have been raised via another application.
When the STATUS is UNPAID, the transaction will stay on the live file indefinitely. All other statuses
will put the transaction to the history file during the Close of Business process.
Example 1:
The following scenario would be one example where a bank would wish to raise a charge, in this case
an MT191 (Charges as a result of a payment order).
William Gates, has received a Customer Transfer from Barclays, London (via BIC BARCGB22), with
instructions to advise the Beneficiary by telephone. Barclays Bank London now requests William
Gates to pay the telephone charges to its account with Barclays Bank, New York.
The user would enter a REQUEST.TYPE of “REQUEST” against the account that William Gates hold
with them in the local currency and for a “1” MESSAGE.SERIES with a CHARGE.DETAIL of “PHON”
and with the BIC code for Barclays Bank New York entered into the ACCOUNT.WITH.BANK field. The
ORDERING.INST would of course be Barclays Bank London.
Example 2:
In the next example William Gates requests Citibank Los Angeles to place a stop on payment on its
cheque number 9100089. Barclays Bank confirms the handling charge (USD 20) associated with this
request via an MT190 to Citibank New York, for which it services a USD account.
Savings Accounts
An ACCOUNT can be classified as a Savings account (see ACCOUNT.CLASS) using the CATEGORY
field. A savings account can be issued a passbook, instead of regular statements and be subject to
additional conditions of withdrawal notices etc. (see ACCT.GROUP.CONDITION).
Parameter Files
The following Parameter files have to be set up before the interest and charges can be activated. In
fact, it will not be possible to open any CUSTOMER ACCOUNT records before the Parameter files
and the debit and credit interest conditions have been set up in the database.
All interest and charges conditions defined are based on an effective date that is part of the key of the
record. Modifications to any existing records will have to be done carefully since the conditions defined
will be applicable from the effective date. Therefore a change in the interest rate will have to be
reflected by opening a new condition record from the date the change is applicable rather than
modifying an existing record.
CONDITION.PRIORITY
This application defines which fields from CUSTOMER and ACCOUNT are to be used for setting
various group conditions. The bank must work out which criteria are required for use particularly for
ACCOUNT conditions. For details, please refer to the User Guide on System Tables.
ACCT.GEN.CONDITION
Every group of ACCOUNT records that the Bank wants to classify is defined in this application. This
classification will be based on the conditions defined in the application CONDITION.PRIORITY.
The purpose of this table is to define the rules for grouping together ACCOUNT records for which the
same interest and charges conditions apply.
Conditions for the calculation and application of interest and charges may then be specified for the
groups and overridden with special conditions for individual ACCOUNT records.
Account groups are determined on the basis of CUSTOMER and ACCOUNT details. The priority data
items from CUSTOMER and ACCOUNT applications are specified in the CONDITION.PRIORITY file
in the record whose ID is ACCOUNT. The priority data items which are used in the
ACCT.GEN.CONDITION records are defaulted from the CONDITION.PRIORITY record with ID
ACCOUNT. For further details regarding XXX.GEN.CONDITION applications, please refer to the User
Guide on System Tables.
Each general condition record specifies the combination of field values defining one account group.
The ID of the general condition record is referred to in other parts of the system as the condition group.
Before any ACCOUNT can be opened, a suitable general condition record must exist in order to
determine the Group to which the ACCOUNT belongs, also a capitalisation frequency record, debit
and credit interest conditions (in the CURRENCY of the account)ACCOUNT) for that group must have
been defined.
Whenever input to an ACCOUNT record occurs, a condition group value is recalculated according to
the details held in this table. Amending an ACCOUNT or CUSTOMER record may result in new
interest conditions being applied and possibly an adjustment to interest previously calculated.
If the details of an account match more than one general condition record, the priority order is used to
determine the group. (The higher priority field with a match wins. Priority 1 is the highest priority.)
An overall default condition (no value specified in any field) must be the first ACCT.GEN.CONDITION
record loaded.
The example below illustrates that the group number 4 (Savings Account (Small Business)) is defined
as any ACCOUNT opened in the system with a category code of 6001 having a customer number
whose sector code is 4200.
ACCOUNT.ACCRUAL
This is a parameter file used to define the interest accrual and posting conditions in the Bank.
Typically data like accrual cycles (Daily, Monthly etc.), foreign or local currency accruals are specified
in this application. The actual interest and charges rates applicable to each ACCOUNT are defined in
other files.
The purpose of this table is to provide the system with information at COMPANY level, about how and
when to process accruals of interest and charges on customer ACCOUNT records. Also, whether
interest capitalisation is inclusive or exclusive of the balance on capitalisation date, the value dates of
interest entries generated and the day on which the entries are booked.
Interest accruals may be processed daily or monthly on any day of the month. Account charges may
only be processed at calendar month end.
It is possible to accrue interest normally on a monthly basis and specify certain types of account with
daily accrual.
Dates for interest capitalisation are specified at group level in the GROUP.CAPITALISATION table
and for a specific ACCOUNT in the ACCT.CAPITALISATION table.
Debit interest conditions can be defined either at group level (i.e. for a group of ACCOUNT types) or at
an account level if the debit interest conditions for the Account are different from those of the group it
belongs to.
GROUP.DEBIT.INT
This file defines the group level debit interest conditions for all the ACCOUNT records in a group. T24
allows definition of two debit interest conditions to be applicable on an
an account.
The file also allows the user to specify the calculation method of debit interest for groups of accounts
and provides the link to the GENERAL.CHARGE table where the charges applicable to the same
group are defined. Interest can be calculated on a Daily, Average, or Highest balance basis using
value-dated balances. Rates can be fixed or linked to basic rates plus or minus a margin. Different
rates can be specified for different balance levels and may be linked to the same or different basic
rates. The rates may apply to the whole of the balance or to the part between two balance levels.
Using group level conditions, it is possible to use the limits on individual ACCOUNT records as the first
level for debit interest so that one rate can be charged up to the limit on any ACCOUNT and another
rate when the limit has been exceeded. (Limits for an individual ACCOUNT are specified in the
ACCOUNT.DEBIT.LIMIT). In this case a maximum of 2 rates may be specified.
For example it is possible to have one debit interest calculated on the daily balance at 10% and
another one on the average balance at 12%.
This can be linked to the TAX table to take a tax on the debit interest. This can be linked to
TAX.TYPE.CONDITION to take a tax on the debit interest. Tax key identifies either a tax record in
TAX or TAX.TYPE.CONDITION record with a "*" symbol prefixed to a valid TAX.TYPE.CONDITION
which specifies the calculation and processing of tax, applicable to debit interest. If a
TAX.TYPE.CONDITION record is given then tax is calculated for the account identified by its group
formed by combinations of Residence, Sector code and Nationality (defined in
TAX.GEN.CONDITION). Input of TAX.TYPE.CONDITION will deduct tax at applicable rate for the
customer. Refer to the User Guide chapter for System Tables for further details.
Figure 166
ACCOUNT.DEBIT.LIMIT
This table allows overdraft limits to be specified for individual ACCOUNT records, which can then be
used as the LIMIT for the first rate of debit interest specified in the appropriate GROUP.DEBIT.INT
condition.
If a GROUP.DEBIT.INT record contains 2 rates, but no DR.LIMIT.AMT for the first rate, the overdraft
LIMIT specified for each ACCOUNT in this table is used as the DR.LIMIT.AMT for the first rate.
In this way it is possible to specify a different DR.LIMIT.AMT for the first rate for each ACCOUNT,
without having to specify separate ACCOUNT.DEBIT.INT condition records.
If there is no LIMIT specified in this table for a particular account, a limit of zero is assumed, and the
2nd rate specified is effective for all balances.
ACCOUNT.DEBIT.INT
ACCOUNT.DEBIT.INT
Any ACCOUNT that has a special set of debit interest conditions different from the group it belongs
to has to be defined in this file. When the interest is processed, T24 will check this file to see if a
particular account has special conditions defined and if not will use the general conditions for the
group the account belongs to.
This can be linked to the TAX table to take a tax on the debit interest. Refer to tax in the chapter on
System Tables for details. This can be linked to TAX.TYPE.CONDITION to take a tax on the debit
interest. Tax key identifies either a tax record in TAX or TAX.TYPE.CONDITION record with a "*"
symbol prefixed to a valid TAX.TYPE.CONDITION which specifies the calculation and processing of
tax, applicable to debit interest. If TAX.TYPE.CONDITION record is given, then tax is calculated for
the account identified by its group formed by combinations of Residence, Sector code and Nationality
(defined in TAX.GEN.CONDITION). Input of TAX.TYPE.CONDITION will deduct tax at the applicable
rate for the customer.
This file is also used to process the charges applicable to the account. Refer to GENERAL.CHARGE
for details.
GENERAL.CHARGE
GENERAL.CHARGE
This application provides the link between all the different charges in T24 to the ACCOUNT conditions
and is used to specify for account groups which charges are to be levied and what balance overrides
are allowed. The GENERAL.CHARGE record applicable to a particular account is specified in the
relevant GROUP.DEBIT.INT or ACCOUNT.DEBIT.INT record.
• Interest related
• Ledger Fee
Interest related charges are processed when the interest is capitalised or accrued. Ledger fee charges
are typically calculated at Monthly, Quarterly, Half-yearly or Yearly frequencies as defined on the
COMPANY record.
If the account has maintained a higher balance than that specified, calculated charges can be waived.
Separate sets of balance level details are specified for interest related charges and for ledger fee
charges.
• DEBIT.INT.ADDON
• GOVERNMENT.MARGIN
• HIGHEST DEBIT
• INTEREST.STATEMENT
Ledger fee charges may be applied Monthly, Quarterly, Half yearly or Yearly as specified in the
COMPANY record, always at the end of a calendar month.
• BALANCE.REQUIREMENT
• NUMBER.OF CREDIT
• NUMBER.OF DEBIT
• TURNOVER.CREDIT
• TURNOVER.DEBIT
• TRANSACTION CODE SPECIFIC
• HIGHEST DEBIT
A waive marker may be set in ACCOUNT records to indicate that charges should be calculated but not
applied.
No Ledger fee charges are calculated on balances and activity in the month in which an account is
opened or closed, (unless the ACCOUNT.CLOSURE date is the last day of the month).
Transaction code specific charges are applied in accordance with the rest of the charges defined on
the GENERAL.CHARGE record but can also be calculated on a daily basis. The details of the charge
scales are defined on the TRANSACTION.CHARGE application.
Similar to the debit interest conditions, credit interest conditions can be defined either at group level or
at an ACCOUNT level.
GROUP.CREDIT.INT
This file defines the group level credit interest conditions for all the ACCOUNT records in a group. T24
allows definition of two credit interest conditions to be applicable on an
an account.
Interest can be calculated on a Daily, Average, or Highest balance basis using value-dated balances.
Rates can be fixed or linked to basic rates plus or minus a margin. Different rates can be specified for
different balance levels and may be linked to the same or different basic rates. The rates may apply to
the whole of the balance or to the part between two balance levels.
Using group level conditions, it is possible to use the limits on individual account records as the first
level for credit interest so that one rate can be charged up to the CR.LIMIT.AMT on any account and
another rate when the CR.LIMIT.AMT has been exceeded. (Limits for an individual account are
specified in the ACCOUNT.CREDIT.LIMIT). In this case a maximum of 2two rates may be specified.
For example it is possible to have one credit interest calculated on the daily balance at 10% and
another one on the average balance at 12%.
This can be linked to the TAX table to take a tax on the credit interest. This can be linked to
TAX.TYPE.CONDITION to take a tax on the credit interest. Tax key identifies either a tax record in
TAX or TAX.TYPE.CONDITION record with a "*" symbol prefixed to a valid TAX.TYPE.CONDITION
which specifies the calculation and processing of tax, applicable to credit interest. If A
TAX.TYPE.CONDITION record is given, then tax is calculated for the account identified by its group
formed by combinations of Residence, Sector code and Nationality (defined in
TAX.GEN.CONDITION). Input of TAX.TYPE.CONDITION will deduct tax at AN applicable rate for the
customer. Refer to the User Guide chapter for System Tables for further details.
.
ACCOUNT.CREDIT.INT
ACCOUNT.CREDIT.INT
Any ACCOUNT that has a special set of credit interest conditions different from the group it belongs to
have to be defined in this file. When the interest is processed, T24 will check this file to see if a
particular account has special conditions defined and if not, will use the general conditions for the
group the account belongs to.
This can be linked to the TAX table or to TAX.TYPE.CONDITION to take a tax on the credit interest.
Tax key identifies either a tax record in TAX or TAX.TYPE.CONDITION record with a "*" symbol
prefixed to a valid TAX.TYPE.CONDITION.
.
CHARGES
Charges
There are two types of charges that are allowed within T24. They are Interest Related Charges and
Ledger Fee charges.
Interest Related Charges include Debit Interest Add-on, Government Margin, Highest Debit Charge
and Interest Statement Charge. Debit Interest Add-on, Government Margin and Highest Debit are
charged when debit one interest is applied. Either Debit Interest Add-on or Highest Debit may be
charged but not both. Interest Statement Charge is levied each time debit interest is applied.
Ledger Fee Charges may be applied monthly, quarterly, half yearly or yearly as specified in the
Company record, always at the end of a calendar month.
The charges can be based on Highest Debit, Balance Requirement, Number of Credits, Number of
Debits, Turnover of Credits, Turnover of Debits and non-immediate transaction charges depending on
the Transaction Codes. Either the number of credits and debits or the turnover figures can be charged,
but not both. It is possible to combine all these charges into one charge. A notional amount of credit
interest may be calculated and deducted from the charge amount.
A special type of ledger fee charge called transaction code based charge may be defined to be
applicable to a specific general charge or to all general charges. These charges are applied in
accordance with the other ledger fee charges but additionally can be calculated on a daily basis.
A waive marker may be set in Account records to indicate that charges should be calculated but not
applied.
No Ledger Fee Charges are calculated on balances and activity in the month in which an Account is
opened or closed, (unless the Account Closure date is the last day of the month).
DEBIT.INT.ADDON
The purpose of this table is to specify a supplementary flat percentage charge, which is to be applied
to the overdraft (debit 1)one) interest amount calculated by the system on capitalisation date. No
DEBIT.INT.ADDON is possible for debit 2two interest.
DEBIT.INT.ADDON represents the same type of charge as 'Highest Debit' and for this reason they
cannot both be specified for application to any one particular Account.
Free, minimum and maximum amounts of charge can be specified by currency and default values can
be input for currencies not specified.
HIGHEST.DEBIT
This table allows the specification of a percentage charge, based upon the highest debit balance
recorded on an ACCOUNT during the application period for debit interest (debit 1)one) or during the
application of the ledger fee charges.
Separate charges can be defined for specific currencies, including local currency. A default charge, in
local currency equivalent, can be defined to cover all accounts in currencies not specifically mentioned.
The highest debit charge can be treated as a ledger charge taken on the charge frequency defined in
the Company application. In making a calculation for the charge a provision is made to allow the
charge to be calculated for an entire charge period or monthly within the charge period.
The field called HIGHEST.DEBIT.CH on the GENERAL.CHARGE application allows for the
specification of a highest debit record id. Any charge id linked to this field will be calculated and posted
according to the rules programmed for the charges.
Fields on the STMT.ACCT.CH, ACCR.ACCT.CH and INFO.ACCT.CH records all the information
related to this new charge.
GOVERNMENT.MARGIN
GOVERNMENT.MARGIN
The same percentage charge is applicable for all currencies. However, it is possible to specify
minimum and maximum amounts for specific currencies as well as local currency equivalent amounts,
which apply to all other currencies.
If there are no overdraft balances during the debit interest capitalisation period, no Government
Margin charge is made.
INTEREST.STATEMENT
INTEREST.STATEMENT
The purpose of this table is to specify a flat fee, which is levied at the time of capitalisation of debit
interest. Specific charges can be entered by currency. For all currencies not specifically mentioned, a
default charge can be entered in local currency equivalent.
All ledger fee charges are applied on the same day, monthly, quarterly six, monthly or yearly, at the
end of the appropriate month, as specified in the COMPANY record. In each case, the details
applicable are those ruling on the date of the charge's application.
BALANCE.REQUIREMENT
BALANCE.REQUIREMENT
The purpose of this table is to define a fixed ACCOUNT charge to be applied if a specified balance is
not maintained.
The required balance may be defined as the minimum or average balance over a given period.
The charge is applied monthly, quarterly, six monthly or yearly as specified in the COMPANY record.
The GENERAL.CHARGE record specifies whether the calculation is in one step, covering the
balances over the whole period, or in monthly steps, applying the appropriate charge for each month
during which the required balance is not maintained.
NUMBER.OF.CREDIT
This table allows a fixed charge to be specified for each chargeable credit entry, which passes over an
ACCOUNT during the capitalisation period. Alternatively, the TURNOVER.CREDIT table may be used
to specify a charge expressed as a percentage of the total value of the entries. Only one of these two
types of charges can be specified for each account.
Entries are chargeable only if the record on the TRANSACTION table corresponding to the transaction
code in the entry contains 'Y' in the TURNOVER.CHARGE field.
If the associated GENERAL.CHARGE record indicates that charges for debit and credit entries should
be combined, the total number of chargeable entries is calculated and then the details from the
NUMBER.OF.CREDIT tables are used.
The amount per entry, and free, minimum and maximum amounts may be defined for specific
currencies. Default amounts in local currency equivalent may also be defined and are used for
accounts in currencies for which no amounts are specified.
NUMBER.OF.DEBIT
NUMBER.OF.DEBIT
This table allows a fixed charge to be specified for each chargeable debit entry, which passes over an
ACCOUNT during the capitalisation period. Alternatively, the TURNOVER.DEBIT table may be used
to specify a charge expressed as a percentage of the total value of the entries. Only one of these two
types of charges can be specified for each account.
The details of this table are exactly the same as the NUMBER.OF.CREDIT table. If the associated
GENERAL.CHARGE record indicates that charges for debit and credit entries should be combined,
the total number of chargeable entries is calculated and then the details from the
NUMBER.OF.CREDIT table are used.
TURNOVER.CREDIT
This table is used to specify a percentage charge on the total value of chargeable credit entries, which
pass over an ACCOUNT during the capitalisation period. Alternatively, the NUMBER.OF.CREDIT
table may be used to specify a fixed charge per entry. Only one of these two types of charges can be
specified for each account.
Entries are chargeable only if the record on the TRANSACTION table corresponding to the transaction
code in the entry contains 'Y' in the TURNOVER.CHARGE field.
If the associated GENERAL.CHARGE record indicates that charges for debit and credit entries should
be combined, the total value of chargeable entries is calculated and then the details from the
TURNOVER.CREDIT table are used.
Free, minimum and maximum amounts may be defined for specific currencies. Default amounts in
local currency equivalent may also be defined and are used for accounts in currencies for which no
amounts are specified.
TURNOVER.DEBIT
This table is used to specify a percentage charge on the total value of chargeable debit entries, which
pass over an ACCOUNT during the capitalisation period. Alternatively, the NUMBER.OF.DEBIT table
may be used to specify a fixed charge per entry. Only one of these two types of charges can be
specified for each ACCOUNT.
The details of this table are exactly the same as the TURNOVER.CREDIT table. If the associated
GENERAL.CHARGE record indicates that charges for debit and credit entries should be combined,
the total value of chargeable entries is calculated and then the details from the TURNOVER.CREDIT
table are used.
TRANSACTION.CHARGE
This table allows a charge, determined by the TRANSACTION code, to be specified for each entry
that passes over an ACCOUNT during the capitalisation period. These charges may be specified to
be calculated on a daily basis.
The TRANSACTION table specifies which TRANSACTION.CHARGE (if any) is applicable to each
different TRANSACTION code.
The charge amount can be expressed either on a unit basis, which represents the cost per entry, or as
a percentage of the total value of the entries.
If transaction charge needs a complex set up then a valid FT.COMMISSION.TYPE record can be
used to form the basis of THE calculation. A valid FT.COMMISSION.TYPE record is to be given in
field commission key. Category, debit-credit transaction code and tax key is taken from the
TRANSACTION.CHARGE record for processing.
The amount per entry, free amount, minimum amount and maximum amount may be defined for
specific currencies. Default amounts, in local currency equivalent, are used for accounts in currencies
for which no amounts are specified.
There could be a requirement to set specific charges for the creation of statements, based upon the
channel (print, swift, etc.) by which the statement is transmitted and the number of statements that
have been created for the account during the defined billing period.
The above has been enabled through the Generic Charges to allow definition of generic charges by
Customer, as well as by account. Generic charges process would select accounts by customer as well
as group and subsequently apply the defined charge.
IC.CHARGE
Application IC.CHARGE allows input of a CUSTOMER number as a key, using the prefix ‘C-‘ to
indicate customer, to apply the generic charge to all accounts belonging to the customer.
Generic charge processing selects accounts for an IC.CHARGE key with ‘A-ACCOUNT.NO’, if does
not exist looks for a key ‘C-CUSTOMER.NO’, if does not exist looks for a key ‘G-GROUP.ID-
CURRENCY’ and if does not exist looks for a key ‘G-GROUP.NO’, and if none of the above exists no
charge is calculated for the account.
Figure 200 IC.CHARGE shown for an account for the above customer with key ‘A-
ACCOUNT.NO’
ACCT.INTERIM.CHG
Application ACCT.INTERIM.CHG accepts a valid CUSTOMER from the Customer table into the field
CUSTOMER.NO. The ACCOUNT.NO and CUSTOMER.NO fields are mutually exclusive and only one
can be entered. If a CUSTOMER.NO has been entered it would read all the accounts from the concat
file CUSTOMER.ACCOUNT, and default the accounts and the relative charges are multi-valued in the
related fields ACCOUNT.NO, IC.CHARGE.CODE and CHG.PRODUCTS as defined in IC.CHARGE and
clear the CUSTOMER.NO field of any values.
The below screen shots of CUSTOMER.ACCOUNT and ACCT.INTERIM.CHG showing the record
with CUSTOMER.NO field input and the record after the CUSTOMER.NO field value has been accepted
for the customer as defined in the above IC.CHARGE screen shot with key as ‘C-50037’ and key ‘A-
20435’
Figure 201 CUSTOMER.ACCOUNT showing the accounts for the customer defined in
the above IC.CHARGE
Figure 202 ACCT.INTERIM.CHG showing the CUSTOMER.NO field input and not yet
accepted
Figure 203 ACCT.INTERIM.CHG showing the accounts defaulted with the charge
products for the above Customer entered in the CUSTOMER.NO field
The above screen shots show that for customer-50037 interim charges would be computed for
account-20435 based on record A-20435 and for account-20443 based on record C-50037 as defined
in application IC.CHARGE.
GENERIC CHARGES
Generic Charges
Overview
The Generic Charges functionality has been developed to enable local charge requirements, which
are not catered for with the above functionality, to be developed locally and incorporated into the T24
charging suite. It also enables locally developed charges to use a different capitalisation frequency
(as opposed to current functionality where capitalisation frequency is set for all charges on the
COMPANY application). Taxes can be applied on these charges.
As with current charging functionality, charges created through generic charge functionality can be set
at a group and currency level, or at an account level. There is also the functionality whereby charges
are applied at a group level – regardless of the accounts created.
Generic charges are not accrued, only capitalised. Capitalisation frequency for each charge can be set
to monthly, quarterly, half yearly or yearly. Interim capitalisation can also be specified for these
charges.
Set-up of IC.CHARGE.PRODUCT
FT.COMMISSION.TYPE
FT.COMMISION.TYPE
Charge Routine
IC.CHARGE.PRODUCT
Local Tables
The FT.COMMISSION.TYPE table holds the basic details for the IC.CHARGE. It specifies the P&L
category into which the charges will be paid, the transaction codes which should be used for the
debiting and crediting through the charge, and the routine from which the charge amount is calculated.
As the charge routine is responsible for generating the actual charge amount, fields that would usually
be mandatory such as CALCULATION.BASIS, CURRENCY and CALC.TYPE no longer become
necessary.
IC.CHARGE.PRODUCT
So in the above example, the IC.CHARGE.PRODUCT record defines the charge product,
ACCT.KEEP.FEE. The FT.COMMISSION.TYPE key, NUMBEROFTXNS is linked to the charge
product. The field BASE.AMT.RTN accepts a routine, that calculates and returns the base amount
(principal) on which charge is calculated. The base amount routine can be developed locally suiting
the client’s requirements.
Set-up of IC.CHARGE
Set-up of IC.CHARGE
The IC.CHARGE table links an account or a customer or a group of accounts with the
IC.CHARGE.PRODUCT records. The charge calculation step period, capitalisation frequency and
effective charge date (the date from which the charge is effective) is specified here. As a result, each
charge product can have its own capitalisation frequency, calculation step period and effective charge
date
The above IC.CHARGE record is set for an account, so that one charge is calculated monthly and
applied annually, while another is calculated and applied every 6 months.
The CHRG.EFF.DATE specifies the date from which the charge is effective. The charge effective date
is defaulted to today. Charges can be waived by specifying value ‘YES’ in the field WAIVE.CHARGE.
Charges can be set for a group of accounts or for a group of accounts with particular currency. For
example, an IC.CHARGE record with an id G-1 would be applied to all accounts within condition group
1. An IC.CHARGE record with an id of G-1-USD would be applied for all accounts within group 1one,
which have a currency of USD. G-1-USD would take precedence over G-1. As detailed above,
individual accounts may be specified where the id is ‘A-<ACCOUNT.NUMBER>, also customer can be
specified where the id is C-<CUSTOMER.NUMBER>. Settings here would take precedence over both
group level settings and group and currency level settings. This is more clearly detailed below :
The above IC.CHARGE is defined for an account group 1.one. All the accounts falling into this group,
will have this charging structure
Figure 213 Linking account groups for a specific currency to generic charges
The above IC.CHARGE record is set for an account group1group one and currency USD. This means
that for all the accounts falling into this group with currency USD will have this charging structure. The
two different charge products are attached with different capitalisation frequency (monthly and
quarterly).
ACCT.INTERIM.CHG
Generic charges are usually capitalised at month ends or quarter ends or half yearly or yearly. If
certain charge products that are set on an account needs to be capitalised on a specific date, which is
not the regular capitalisation date, interim capitalisation can be done for that date.
Application ACCT.INTERIM.CHG accepts a valid CUSTOMER from the Customer table into the field
CUSTOMER.NO. The ACCOUNT.NO and CUSTOMER.NO fields are mutually exclusive and only one
can be entered. If a CUSTOMER.NO has been entered it would read all the accounts from the concat
file CUSTOMER.ACCOUNT, and default the accounts and the relative charges are multi-valued in the
related fields ACCOUNT.NO, IC.CHARGE.CODE and CHG.PRODUCTS as defined in IC.CHARGE and
clear the CUSTOMER.NO field of any values.
The below screen shots of CUSTOMER.ACCOUNT and ACCT.INTERIM.CHG showing the record
with CUSTOMER.NO field input and the record after the CUSTOMER.NO field value has been accepted
for the customer as defined in IC.CHARGE screen shot with key as ‘C-50037’ and key ‘A-20435’
Figure 215 CUSTOMER.ACCOUNT showing the accounts for the customer defined in the above
IC.CHARGE
Figure 216 ACCT.INTERIM.CHG showing the CUSTOMER.NO field input and not yet accepted
Figure 217 ACCT.INTERIM.CHG showing the accounts defaulted with the charge products for the above
Customer entered in the CUSTOMER.NO field
The above screen shots show that for customer-50037 interim charges would be computed for
account-20435 based on record A-20435 and for account-20443 based on record C-50037 as defined
in application IC.CHARGE.
Application ACCT.INTERIM.CHG accepts a valid CUSTOMER from the Customer table into the field
CUSTOMER.NO. The ACCOUNT.NO and CUSTOMER.NO fields are mutually exclusive and only one
can be entered. If a CUSTOMER.NO has been entered it would read all the accounts from the concat
file CUSTOMER.ACCOUNT, and default the accounts and the relative charges are multi-valued in the
related fields ACCOUNT.NO, IC.CHARGE.CODE and CHG.PRODUCTS as defined in IC.CHARGE and
clear the CUSTOMER.NO field of any values.
The below screen shots of CUSTOMER.ACCOUNT and ACCT.INTERIM.CHG showing the record
with CUSTOMER.NO field input and the record after the CUSTOMER.NO field value has been accepted
for the customer as defined in IC.CHARGE screen shot with key as ‘C-50037’ and key ‘A-20435’.
Figure 218 CUSTOMER.ACCOUNT showing the accounts for the customer defined in
the above IC.CHARGE
Figure 220 ACCT.INTERIM.CHG showing the CUSTOMER.NO field input and not yet accepted
Figure 222 ACCT.INTERIM.CHG showing the accounts defaulted with the charge
products for the above Customer entered in the CUSTOMER.NO field
The above screen shots show that for customer-50037 interim charges would be computed for
account-20435 based on record A-20435 and for account-20443 based on record C-50037 as defined
in application IC.CHARGE.
Interest is calculated on value-dated balances. All entries over an ACCOUNT are considered to have
a value date, which is the date on which the entry affects the (value-dated) balance for interest
purposes.
If no value date is entered in a transaction, it may be added automatically by the system, depending
on rules specified in the TRANSACTION code table, or rules specified in the application, which
generated the transaction (e.g. MONEY.MARKET).
If no value date has been entered or generated in an entry, a default of the booking date is assumed,
i.e. the entry is considered to affect the balance for interest purposes on the same day as it is
processed.
There is functionality within T24 to apply charges to a customer, depending upon the unutilized/utilised
amount of a LIMIT. When set up, T24 will record the utilized amount, and calculate the unutilised
amount, and record it in contingent account(s), from which interest and charges can be calculated
and applied to the customer account, using standard T24 functionality. As the utilised amount of the
limit varies, so the amounts in the contingent accounts vary and so the interest and charges can be
calculated.
ACCOUNT.PARAMETER
The ACCOUNT.PARAMETER file contains the top-level settings for contingent accounts. It is here
that it is specified which CATEGORY codes can be used for contingent accounts, and also which
TRANSACTION codes should be used for the debiting and crediting of the contingent account.
ACCOUNT.CLASS
Two separate ACCOUNT.CLASS IDs, namely OFFLIMIT and UTILLIMIT are created. They have to
be opened in the ACCOUNT.CLASS application, with appropriate CATEGORY codes, as mentioned
in the ACCOUNT.PARAMETER table. Internal Accounts are to be opened in the categories
mentioned, to post the contra entries.
Contingent accounts, as they have different reporting and accounting consequences than non-
contingent (typical) accounts, have to be set up to have their own groups. As a result, specific
ACCT.GEN.CONDITION, GROUP.CREDIT.INT, GROUP.DEBIT.INT and GROUP.CAPITALISATION
records must be set up to cater for the contingent accounts. These can be set up in the same way as
contingent account groups are set up.
When creating contingent ACCOUNT records, it is necessary to indicate to which accounts the
interest and charges generated from the contingent account are applied. These are specified in the
INTEREST.LIQU.ACCT and CHARGE.ACCOUNT fields of the ACCOUNT application. These fields
are mandatory where the CONTINGENT.INT field has been populated. The CONTINGENT.INT field
will be populated by default from the ACCT.GROUP.CONDITION setting (see above). . There are
four different settings at present; “B” (to indicate on-balance sheet interest), “O” (to indicate off-
balance sheet interest), “C” (to indicate contingent interest off-balance sheet) and “I” (to indicate the
contingent account is internal.
LIMIT.PARAMETER
LIMIT
The contingent account to which the unutilized/utilised amount of a limit is to be swept is specified in
the LIMIT application, in the UNUTIL.ACCT/UTIL.ACCT fields. It is from here that the current
unutilized/utilised amounts are taken. There is also the option here of overriding the
LIMIT.PARAMETER application on the setting of whether credits to the contingent account should
occur when the unutilised amount is reduced.
Once set up, the contingent accounts are updated during the end of day. It is also possible to update
the accounts through DATA.CAPTURE and FUNDS.TRANSFER . It is only possible to make a
FUNDS.TRANSFER when both accounts are typical accounts or when both accounts are contingent.
Likewise DATE.CAPTURE the entire batch must be of the same type.
Interest Accruals
These files contain details of the calculation of the credit interest that has been accrued on an
ACCOUNT but has not yet been posted to the account.
The files ACCR.ACCT.CR and ACCR.ACCT.CR2 are similar in layout and denote the CR or the CR2
interest respectively.
These files contain details of the calculation of the debit interest that has been accrued on an
ACCOUNT but has not yet been posted to the account.
The files ACCR.ACCT.DR and ACCR.ACCT.DR2 are similar in layout and denote the DR or the DR2
interest respectively.
ACCR.ACCT.CH
This file contains details of the calculation of the charges that have been accrued on an ACCOUNT
but have not yet been posted.
Interest Capitalisation
GROUP.CAPITALISATION
The purpose of this table is to specify the next date and subsequent frequency of application of debit
and credit interest, for a group of Accounts.
Interest may be applied on any day of the month. Cycles may be different for debit and credit interest,
(e.g. debit interest may be charged monthly and credit interest paid quarterly) unless credit interest is
only to be calculated as an offset to debit interest.
The date of debit interest application is also used as the date of application of interest related charges.
(These are DEBIT.INT ADDON,DEBIT.INT.ADDON, GOVERNMENT.MARGIN, HIGHEST.DEBIT and
INTEREST.STATEMENT).
If the 'Last Day Inclusive' field in the ACCOUNT.ACCRUAL file contains 'Y', interest is calculated on
balances with value up to and including the capitalisation date. The value date of the interest entry
booked is the day after the capitalisation date. If 'Last Day Inclusive' contains 'NO' only balances up to
and including the previous working day are included. The value date of the interest entry booked is the
day after the last balance included.
Interest entries are booked to the ACCOUNT on the day they are calculated, or on the next working
day, depending on the application posting day specified in the ACCOUNT.ACCRUAL record.
If the capitalisation date falls on a non-working day, the application is processed on the previous
working day, unless a month end accrual day falls before the capitalisation date, in which case the
application is processed on the next working day. In either case, the calculation is up to the
capitalisation date and the entries generated have the same value date as they would have had if they
had been processed on that date.
ACCT.CAPITALISATION
ACCT.CAPITALISATION
This table allows interest capitalisation dates to be specified for individual accounts, overriding the
dates specified for the associated group in the GROUP.CAPITALISATION table.
The details included in this table are exactly the same as the GROUP.CAPITALISATION table.
The input into INT.POST.PERIOD on ACCT.GROUP.CONDITION allows the user to define the value
date of interest capitalisation. The actual posting date, which should not be confused with the value
date, of the capitalised interest, is governed by the input in the four frequency fields on
GROUP.CAPITALISATION. The LAST.DAY.INCLUSVIE setting on ACCOUNT.ACCRUAL will
determine whether the interest calculations are inclusive or exclusive of the capitalisation date. If, for
example, Q (Quarterly) is input in INT.POST.PERIOD and LAST.DAY.INCLUSVIE is set to Y (Yes)
then interest will be posted to the account with a value date of the first working day of the next quarter.
If LAST.DAY.INCLUSVIE is set to N (No), and the INT.POST.PERIOD remains the same, then the
value date of the posting will be the last working date of the current quarter period. It should be noted
that once a customer account has been opened in the company the LAST.DAY.INCLUSVIE field
setting cannot be changed.
Last day inclusive Interest post period Calculation Period end Value date of interest
setting date posting
N M 30th July 31st July
ACCT.INTERIM.CAP
Used to request interim interest applications on particular ACCOUNT records, without affecting the
normal application cycles. The interim applications requested will be processed during the Close of
Business run on the day specified.
ACCT.SUSP.SETTLE
ACCT.SUSP.SETTLE
Used to request settlement of interest and charges, which have been suspended and not booked to
Profit and Loss. The Close of Business program EOD.ACCT.SUSP removes the requested amounts
from the SUSPENSE.AMOUNT fields in the ACCOUNT record and generates the appropriate entries for
Profit and Loss.
TABLE.CAPITALIS.CORR
Used to request recalculation and correction of previously applied interest. (The system automatically
recalculates and corrects interest when entries with value dates prior to the last interest application are
processed, but does not automatically recognise back-valued changes to interest rates or conditions.)
The requested recalculations are processed during the Close of Business run on the day specified.
This functionality can now be used to generate STMT.ACCT.XX and CORR.ACCT.XX records for
back-valued changes to the balance of an account for both zero interest and interest generating
accounts.
A STMT.ACCT.XX will be produced showing the recalculated balances and interest if applicable.
Whereas the CORR.ACCT.XX will show the original balances and calculations i.e. before the back
valued correction was made.
ENQUIRIES
Enquiries
These applications may be used to request on-line calculations of credit interest for CR and CR2. The
results are for information only and no entries are generated.
The file layouts for the two files are similar and INFO.ACCT.CR calculates the CR Interest and the
INFO.ACCT.CR2 calculates the CR2 Interest.
These applications may be used to request on-line calculations of debit interest for DR and DR2. The
results are for information only and no entries are generated.
The file layouts for the two files are similar and INFO.ACCT.DR calculates the DR Interest and the
INFO.ACCT.DR2 calculates the DR2 Interest.
INFO.ACCT.CH
This application may be used to request on-line calculations of charges. The results are for information
only and no entries are generated.
INFO.ACCT.PREMIUM
This application may be used to view on-line calculations of premium interests. The calculations are
initiated from an enquiry called ‘INFO.ACCT.PREMIUM’. The results are for information only and no
entries are generated.
ACC.CURRENT.INT
This enquiry may be used to view on-line for an Account any Interest rate changes for a given period.
This enquiry is used to view the generic charges for an account or a range of accounts till a given date.
The above screenshot shows online calculation of generic charges for account number 17205. It
shows the calculated date till when the charges were calculated, the charge amount, tax amount and
the charge product set and the narrative.
ADVICES
Print advices to notify Interest Rate Changes on accounts can be generated in T24 during overnight
run. Development of the new functionality is based on Multi threading and this approach should have
the field JOB.NAME for the record ACCT.RATE.CHANGE in PGM.FILE set to
@BATCH.JOB.CONTROL. A batch record called RATE.CHANGE.ADVICE runs between specified
dates in on an ad-hoc basis. Advices for accounts that are subject to interest rate change since last
advice date are produced. The program ACCT.RATE.CHANGE last run date and the next run date in
the batch record are considered and gathered. When it is run for the first time since the batch last run
date has been left blank, the last date advice produced viz.is produced. The advice produced for rate
changes up to that date has been hard coded to be the entry in the field BACK.VALUE.MAXIMUM in
DATES.
To generate the advices, in addition to the above, further relevant parameterisation needs to be in
place in the applications given below
EB.ACTIVITY
EB.ADVICES
DE.MAPPING
DE.PRODUCT
DE.FORMAT PRINT
For further details please refer to the DELIVERY section in the User Guides.
FILES USED
Files Used
ACCT.ACTIVITY
ACCT.ACTIVITY contains details of ACCOUNT balances and activity used to calculate IC charges.
Details are held in separate records for each account for each month in which there has been any
activity over the account or in which the value dated balance changes.
The details held in this file for the calculation of interest include value-dated balances and total debit
and credit turnover for each value date.
The details held for the calculation of charges include the total number of entries with each different
TRANSACTION code processed during the month, and the total value of the entries with each
TRANSACTION code. These details are held in the record for the month in which the entries are
processed, regardless of the value dates of the entries.
The value-dated balances are also used for the calculation of BALANCE.REQUIREMENT charges
and for determining whether a high enough balance has been maintained for waiving charges and for
calculating credit interest to offset charges.
This file is updated during the Close of Business process EOD.ACCT.ACTIVITY with the details of
every entry which has been generated during the day and also during the Close of Business
capitalisation processes, EOD.CAPITALIS.CORR and (unless next day posting is specified in the
ACCOUNT.ACCRUAL table) EOD.CAPITALISATION.
A new ACCOUNT activity record is generated every time an entry is encountered with a value date or
booking date in a month in which the account has not previously had any entries.
If an entry has a Value date in a different month from the booking date, at least 2 account activity
records are updated, one containing the value dated balances for interest purposes, the other
containing the numbers and amounts of transactions for charge purposes.
If an entry has a value date earlier than entries that have previously been processed for the same
account, all subsequent value dated balances are updated. This may involve updating several account
activity records.
These files contain details of the calculation of the credit interest that has been booked to the client
ACCOUNT.
The files STMT.ACCT.CR and STMT.ACCT.CR2 are similar in layout and denote the CR or the CR2
interest respectively.
These files contain details of the calculation of the debit interest that has been booked to the client
ACCOUNT.
The files STMT.ACCT.DR and STMT.ACCT.DR2 are similar in layout and denote the DR or the DR2
interest respectively.
STMT.ACCT.CH
STMT.ACCT.CH
This file contains details of the calculation of the charges that has been booked to the client
ACCOUNT.
These files contain details of the previous calculation of credit interest, which have been capitalised
and recalculated and corrected. The new details are held on the STMT.ACCT.CR and
STMT.ACCT.CR2 files.
The files CORR.ACCT.CR and CORR.ACCT.CR2 are similar in layout and denote the CR or the CR2
interest respectively.
These files contain details of the previous calculation of debit interest, which have been capitalised
and recalculated and corrected. The new details are held on the STMT.ACCT.DR and
STMT.ACCT.DR2 files.
The files CORR.ACCT.DR and CORR.ACCT.DR2 are similar in layout and denote the DR or the DR2
interest respectively.
ACCR.ACCT.TRAN.CH
ACCR.ACCT.TRAN.CH
This file contains the details of the currently accrued transaction code based charges if these were
defined to be calculated on a daily basis on the TRANSACTION.CHARGE application. Details of
calculated charge amounts are used from this file at the time of capitalising charges, when also these
details are transferred to the STMT.ACCT.TRAN.CH file.
STMT.ACCT.TRAN.CH
This file contains the details of the previously applied transaction code based charges. A new record is
stored into this file for every capitalisation date for an account.
This file contains the details of generic charges that have been capitalised to the customer account.
The id of the file is ACCOUNT. NUMBER, CHARGE.PRODUCT.CAPITALISED number charge,
product capitalised date. This file shows full details about the charges and taxes capitalised.
The above diagram shows the STMT.GEN.CHG record for an account 17205. The charge product that
has been capitalised is ACCT.KEEP.FEE on 15/01/2001. The charge and tax information like the
charge amount, IC.CHARGE set for the account, the tax amount, charge and tax category, the
FT.COMMISSION.TYPE (charge code) id attached to the charge product, debit and credit transaction
codes for charge and tax, etc are shown in this record.
END OF DAY
Close of Business
The following programs run the BATCH and their general functions are described below:
INT.POST.NEXT
If interest entries have been generated for posting the next day, these must be processed before any
other ACCOUNT module Close of Business programs.
This Batch job posts interest entries generated during the previous Close of Business run if NEXT is
specified in the application posting day field in the ACCOUNT.ACCRUAL record.
The interest and charges module includes the following programs which must be run during
end-of-day Close of Business processing, after processing any interest entries generated the previous
day and after the Close of Business processes which generates accounting entries for the various
other transaction processing modules. The programs must be run in this order.
EOD.ACCT.SUSP
Settles 'suspended' interest and charges as requested via the table ACCT.SUSP.SETTLE, by
removing the requested amounts from the suspense amounts in the ACCOUNT record and generating
the appropriate entries for Profit and Loss.
EOD.ACCT.ACTIVITY
Updates opening balances in account records and the value dated balances and activity details in the
ACCT.ACTIVITY file used to calculate interest and charges.
It also updates files used by other Close of Business procedures in the ACCOUNT module in printing
account statements and in determining accounts to be included in the overdraft and referral reports
and accounts with back-valued entries, which may require corrections of interest previously, applied
and accounts which may be closed.
EOD.UPDATE.ACCT.ACT
Adds booking date information to the ACCT.ACTIVITY file for any entry made during the day for which
the value date did not equal the booking date.
EOD.CAPITALIS.CORR
Recalculates interest previously applied and generates correcting entries. It automatically processes
any accounts, that have had entries with value dates prior to the last application date, and also
processes any accounts selected via TABLE.CAPITALIS.CORR.
EOD.CAPITALISATION
Calculates and applies interest and charges on regular capitalisation dates (specified in the GROUP
or ACCT CAPITALISATION tables), on any interim application dates selected via
ACCT.INTERIM.CAP and for ACCOUNT records flagged for closure.
DAILY.CHARGES.EOD
Calculates on a daily basis, the charges that have accrued on accounts that have been linked to
transaction code based daily charges.
EOD.REBUILD.ACCT.GRP.COND
Some of the parameters in the ACCT.GROUP.CONDITION file cannot be changed on-line. This is
because a change made to them necessitates rebuilding the ACCT.AVAILABILITY file. Therefore any
changes to be made to these parameters are created into a request record, which carry over the new
values to the active records. This program is responsible for these functions.
EOD.REBUILD.ACCT.AVAIL
The ACCT.AVAILABILITY file is crucial to the correct validations on account transactions. If any of the
parameters governing these validations change, the ACCT.AVAILABILITY file becomes out of sync
and needs to be rebuilt for all of the accounts affected. This program handles the rebuild of the
ACCT.AVAILABILITY file.
EOD.ACCRUAL
Processes accrual of interest and charges on customer accounts, generating entries for profit and loss.
The days on which interest and charges are accrued are specified in the ACCOUNT.ACCRUAL table.
Interest may be accrued daily or monthly (on any day of the month). Charges may be accrued monthly,
at calendar month end, or only booked to profit and loss when they are applied.
DELIVERY
Delivery
The delivery system is used to produce interest statements and interest and charges advices.
Formats, addresses and numbers of copies required are specified within the delivery system. Interest
and charges advice’s may be printed or sent via SWIFT.
The interest and charges module passes the required information to the Delivery system, which
transforms it into the appropriate messages.
The interest statement has a delivery code of 1950 and interest and charges advice’s have the
Delivery code of 1990.
Introduction
T24 provides functionality for banks that have requirements to manage the issuing and registration of
cheques and bank drafts issued to their clients.
Banks can record requests for chequebooks ordered by customers and when these cheques are
received from the vendors, issue them to the appropriate customer.
When a chequebook is issued to the client, the range of the cheque numbers will be recorded into a
cheque register. Furthermore, when cheques are stopped or returned, this can also be recorded in
the cheque register. When cheques are presented, this is stored in a CHEQUES.PRESENTED file.
There is also the functionality to charge the client for the issuing of cheque books, for charges to be
applied on the usage of cheques by the customers, and also a periodic charge for possession of a
cheque book.
Furthermore, the CHEQUES.PRESENTED file is also consulted to confirm that the cheque has not
already been presented elsewhere.
When a cheque does not conform to the above rules, an override is requested. If the override is
accepted the cheque may still be used.
On completion of the above transaction the cheque register and CHEQUES.PRESENTED file is
updated with the last status on the cheque.
Banks can issue cheques and drafts drawn on them. Details for these are stored in a similar manner
to customer cheques. Further details regarding the following could be obtained from the system if
required.
Setting up ACCOUNT.PARAMETER
The first step towards issuing cheques on accounts is to set up a CHEQUE.TYPE record. This record
will allow you to specify certain default parameters associated with a class of cheques. An example
has been illustrated as under:
The user can set up the charging rules in the CHEQUE.CHARGE application to levy charges on
cheques issued, cheques used, and also a periodic charge for having the cheque facility, as illustrated
under:
In order to invoke the processing that will validate cheques issued to a client account, a
TRANSACTION record will need to be linked to the CHEQUE.TYPE created in step 4.3.1.4. The
transaction code used in the accounting entry raised for the cheque transaction must be linked into a
CHEQUE.TYPE record for the system to perform the extra validation associated with cheque issue
and management. An example of this has been illustrated as under:
Cheques are issued to clients through the CHEQUE.ISSUE application. This has been illustrated as
under:
In the example above the client account 20648 has been issued 100 cheques of cheque type ‘CURR’
on the 6th February 2001. The customer has also been charged $20.00 on the 9th February 2001 for
the issuing of cheques. The cheque numbers will start from 101000 and go up to 101099.
As seen in the figure above account number 20648 now has cheque 101000-101099 issued to it.
The CHEQUE.ISSUE application will now have additional fields to track the status of chequebook and
handle charges other than cheque-leaf related charges. Attempt has also been made to link this
application to soft delivery by triggering delivery messages on cheque status change. A new table
called CHEQUE.STATUS has been added to store various cheque statuses. The CHEQUE.CHARGE
application has been enhanced to take-in FT.CHARGE.TYPE and FT.COMMISSION.TYPE and this
has been linked to CHEQUE.ISSUE application.
The history of charges debited under various stages and the history of date of statuses will be stored
in CHEQUE.CHARGE.BAL for reference by the Bank.
A way of distinguishing the cheque issued to the customer for the first time from the issues of
subsequent times, for the purpose of defining a different approval mechanism by the Bank.
During EOD,COB, the accounts that have reached the minimum holding level of cheques will be
identified and new cheque issue records will be automatically created with status as defined by user.
Banks can follow this record, for automatic delivery of chequebooks to customers as a re-order
process
Bank drafts and cheques issued by the bank may be registered using the same procedure as that
detailed above, with the difference of using a Nostro account instead of a client account. Thus a new
cheque type for bank drafts would need to be set up (with "Nostro accounts" as the category field),
and a TRANSACTION record to be used when issuing drafts. The TRANSACTION record would have
to have ‘CREDIT’ flagged in the DEBIT/CREDIT indicator (as opposed to debit for client cheques).
No CHEQUE.CHARGE record would be required.
It should be noted that at present it is not possible to run a TELLER or FUNDS.TRANSFER deal
where both sides of the transaction refer to TRANSACTION records where the CHEQUE.IND field is
set to YES. In other words, it is not possible for a client to buy a registered bank draft, using their own
registered cheques.
It is now possible to pass a TELLER transaction that debits the account number on which the cheques
were issued. The system will respond with overrides when cheques that have already been presented
or stopped are presented on a transaction.
The following screen shot depicts how the system responds when attempting to present a cheque
already presented earlier to the system.
This is because in the CHEQUES.PRESENTED file there is already a record of this cheque having
been used. If we say Yes to the override, the CHEQUES.PRESENTED file gets updated, and the
REPRESENTED.COUNT field is updated. :
Stopped Cheques
In order to stop cheques the user will need to enter a PAYMENT.STOP record for the account number
on which the cheque has been issued (see section 0). This is done as shown under: The
PAYMENT.STOP record must be authorised before the stop comes into effect.
Now when an attempt is made to use a stopped cheque on a transaction the system responds with an
override message that has been illustrated in the figure below:
If the answer to this override were ‘Y’ then the TELLER record would record this message into its
OVERRIDE fields as shown under:
Returned Cheques
The system handles the collection of deposited cheques; this is in addition to the normal method of
clearing cheques. The cheque clearing system takes cheques entered through TELLER,
FUNDS.TRANSFER or DATA.CAPTURE and creates a Cheque Collection Record for each cheque.
The cheque collection record can be processed individually or through CHEQUE.BATCH, that groups
batches of cheques together for processing. The processing caters for cheques deposited into the T24
bank that clear in a certain or uncertain number of days. For example foreign cheques may take an
uncertain number of days to clear, with this functionality T24 can deal with this. While the cheques are
waiting to be collected the funds are posted to a Suspense account. Upon the successful collection,
the funds are then credited to the customer. If the cheque is returned then funds in suspense to are
returned to a suspense account.
Set-up
The cheque collection functionality is triggered by TRANSACTION codes. New transaction codes are
created to indicate whether processing is required or not. After the new transaction codes have been
created they are input onto the Account parameter record. For every transaction created through
Funds Transfer, Data Capture or Teller, the system checks the account parameter record for the
transaction code. If the transaction code is not found on the account parameter record, the Cheque
Collection processing is by-passed.
Transaction codes
New transaction codes must be created as a means of identifying the transaction to be processed
through the cheque collection processing.
There are two methods of deciding which suspense account the funds go to for clearing and returns,
the suspense category is either defined on the Bank Sort Code record or on the Account Parameter
record with the transaction code. The transaction code decides where the funds should be posted,
there are a minimum of three transaction codes required on the Account Parameter record. A
transaction code must be created for the Collection of Cheques, the Clearing of Cheques and the
Return of Cheques. Multiple transaction codes can be set for each of the mentioned cheque actions.
The account parameter Account Parameter accepts multiple transaction codes as a unique
transaction code could be created for Funds Transfer, Data Capture and Teller.
For example a cheque is deposited using a TRANSACTION code that is on the Account Parameter
record, the transaction is then posted to the collection suspense account (as defined by the collection
category code on the ACCOUNT.PARAMETER record) and a Cheque collection record is created.
Figure 281
Figure 282
The above example transaction codes will be used though the remainder of this manual. The
transaction codes are entered onto the ACCOUNT.PARAMETER record and also used by the Teller
Transaction codes.
Category Code
New CATEGORY codes will need to be created to enable the set up of the new suspense accounts.
These category codes specify which suspense account the funds should be held in. The category
codes can be defined on the ACCOUNT.PARAMETER record and/or the Bank sort code record, the
differences will be explained later on. There must be at least one category code for each transaction
code. The category codes must be between the range of 10000 and 19999, thus defining them as
internal accounts.
Suspense Accounts
Internal suspense accounts need to be created for each CATEGORY code. These internal suspense
accounts are updated when the corresponding transaction codes are used in a transaction. As there
are three main category types required so too is there a need to create a minimum of three internal
Suspense accounts.
As the cheque progresses through the deposited Cheque Collection system, the funds move with it
through the internal suspense accounts until the cheque is cleared. If the cheque is returned then the
returned suspense account will contain the value of the returned cheque.
Account Parameter
The ACCOUNT.PARAMETER record determines whether or not the deposited cheque collection
functionality should be invoked. If the ACCOUNT.PARAMETER record has the CHQ.DEP.TXN,
DEF.COLL.SUSP, CHQ.COLL.TXN, CHQ.RTN.TXN and the DEF.RTN.SUSP fields entered then the
deposited cheque collection functionality is invoked.
The system decides what processing to invoke by locating the transaction code in the transaction
code fields (CHQ.DEP.TXN, CHQ.COLL.TXN and CHQ.RTN.TXN) on the ACCOUNT.PARAMETER
record.
If the TRANSACTION code is found the system then assigns a CATEGORY code to the transaction.
The category code can come from two places; the BC.SORT.CODE record for the bank sort code
used in the transaction or from the ACCOUNT.PARAMETER record (transaction codes can have
associated category codes).
Bank sort code records can be created with CATEGORY codes. The category codes are only used for
suspense deposited cheque collection transactions if the ACCOUNT.PARAMETER record is set. If the
ACCOUNT.PARAMETER record has been set, and a bank sort code is used by the transaction, the
system will firstly check the sort code record for a category code to suspend the funds. If there is no
CATEGORY code it will use the CATEGORY code from the ACCOUNT.PARAMETER record.
Having the CATEGORY codes on the BC.SORT.CODE records allows the funds to be posted to
individual suspense accounts for each bank.
The FT.BC.PARAMETER and the FT.LOCAL.CLEARING files go hand in hand. If you need to create
or modify the FT.BC.PARAMETER record then the FT.LOCAL.CLEARING record should also be
checked and/or updated. For further information on the FT.BC.PARAMETER file and the
FT.LOCAL.CLEARING file see the Funds Transfer and/or Local Clearing User Guides.
Cheque Collection
The cheque collection records are created through Funds Transfer, Data Capture and Teller. The
normal processing for these applications occur, however if the transaction code is found on the
account parameter record the system will also create a cheque collection record. In Teller the
TELLER.TRANSACTION code record contains the TRANSACTION code used in the contract, and in
FUNDS.TRANSFER the FT.TXN.TYPE.CONDITION code record contains the transaction code used
in the contract.
In the above example the FT.TXN.TYPE.CONDITION record IC has a TRANSACTION code of 221
(Incoming Cheque Payment), therefore a cheque collection record has been created. For every Funds
Transfer, Data Capture and Teller transaction created the system searches through the list of
TRANSACTION codes on the ACCOUNT.PARAMETER trying to locate the TRANSACTION code of
the deal. The field on the ACCOUNT.PARAMETER where the TRANSACTION code is found
determines what processing is required for Cheque collection.
Normal account processing takes place on the transaction. In the example below you will see that the
USD Nostro account has been debited $543.00, while the internal suspense account has been
credited with the $543.00,$543.00; the customer account has not been credited. The internal
suspense account has been derived from the BC.SORT.CODE record 100000301123 which has a
Collection suspense CATEGORY of 14820.10400.
On the credit STMT.ENTRY record the CHQ.COLL.ID field indicates the Cheque Collection id -
Customer Account number.
The record is now available for processing through Cheque Collection. The Cheque collection record
shows the cheques status. Cheque Collection records are created with a status of Deposited, this
indicates a cheque has been entered into T24 and is waiting to be processed. Cheques can be
processed individually in Cheque collection or in batches through the Cheque Batch application (see
Cheque Batch section).
A Cheque can be Clearing, Cleared or Returned. The cheque collection CHQ.STATUS field indicates
what status the cheque is at. Cheques are usually sent for Clearing, and can come back either
returned or cleared. The Cheque collection record then has the CHQ.STATUS field changed to the
appropriate status.
The cheque collection record is processed through changing the CHQ.STATUS to the required status.
The status will be changed to clearing,, which means the cheque has been sent to the appropriate
bank for action. The reply from the bank will determine which status is to be entered next, if the
cheque is cleared the cheque collection record CHQ.STATUS field is changed to cleared.
The cheque collection record with a CHQ.STATUS of cleared will create the following accounting
entries. The accounting entries will credit the customer account and debit the internal suspense
account completing the transaction. Note that no accounting entries are generated when the cheque
status changes from deposited to clearing.
Below, are all the entries which are raised by a cleared cheque with charges when processed through
the Cheque Collection application.
There are five entries raised by the clearing of a CHEQUE.COLLECTION record, the crediting of the
customer and the debiting of the suspense account are standard. There is one entry for charges and
the other two entries come from a linked FT.CHARGE.CODE.
Cheques can be bounced/returned by the other bank and this results in the funds being transferred
from the internal cheque collection suspense account to the returned cheque collection suspense
account. The returned suspense account can be derived from the either the BC.SORT.CODE file or
the ACCOUNT.PARAMETER file.
Along with the normal accounting entries for the Funds Transfer there is the debiting of the cheque
collection suspense account and the crediting of the returned cheque collection suspense account.
Cheque Batch
CHEQUE.BATCH is the application that provides a method of clearing multiple deposited cheques.
Cheques can be of varying currencies and denominations with the validation ensuring the entered
total of each currency matches the calculated total for the batch. The cheques are then returned by
the external banks and are either cleared or returned. The entire batch can be updated, or individual
items can be updated.
CHEQUE.COLLECTION records can only be added to the CHEQUE.BATCH record if they have a
status of Deposited, which will be changed to Clearing, as they are entered into the CHEQUE.BATCH
record.
The five items from the enquiry that are highlighted are dragged to the CHQ.COLL.ID field, which
expands. The cheque batch record will look as below:
The CHEQUE.BATCH application will update the status of all the Cheque collection records on the
batch automatically. The record will stay with a status of clearing until a cheque or all the cheques
have been either cleared or returned.
If a CHEQUE.COLLECTION record is part of a CHEQUE.BATCH the status of the record can only be
updated through the CHEQUE.BATCH application. In CHEQUE.BATCH it is possible to update the
status of individual CHEQUE.COLLECTION records or to update the whole batch by changing the
OVERALL.STATUS field to the desired status. Changing the overall status field will update every
CHEQUE.COLLECTION record that currently has a status of clearing with the status entered in the
OVERALL.STATUS field.
In the below example the cheque for USD 2000.00 is returned, the individual status of the
CHEQUE.COLLECTION record has been updated leaving the status of all other
CHEQUE.COLLECTION records unchanged. The returned cheque funds will be posted to the return
Cheque Suspense account.
If the remaining cheques come back cleared then the OVERALL.STATUS can be updated to cleared,
this will populate all remaining status fields that have a status of clearing to Cleared.
All CHEQUE.COLLECTION records on this CHEQUE.BATCH record that have a status of clearing
have been set to cleared. Below is the CHEQUE.COLLECTION record that has been returned noting
that this record has not been updated since the status had been set to returned.
Figure 326
CHEQUES RE-BATCH
An application called CHEQUE.CHANGE has been introduced for the purpose of selecting cheque
collection records or cheque batches and group them for further processing.
If CHEQUE.BATCH is selected as APP.ID and no further selections are made, all the open cheque
batches will be grouped together. This will be useful at a Service Branch of the bank to combine the
batches received from various branches and present them to Clearing House. The regrouped new
batch ID will be displayed as a no input field in BATCH.ID.
Grouping of Cheque Batches can be done using the fields, SELECTION.FIELD, OPERAND and DATA
DATA. On Verify mode, the process like re-batch will be done.
CHEQUE COLLECTION ACCOUNTING
A new table called STOCK.PARAMETER is created with a field named DEF.COLL.SUSP. If the
credit side transaction code of the TELLER.TRANSACTION relating to Clearing is defined in this table
and the DEF.COLL.SUSP field is left blank, then the credit of Cheque Collection record will go directly
to the customer account. Otherwise it will follow the usual path defined in ACCOUNT.PARAMETER.
The same code will not be permitted both in STOCK.PARAMETER and ACCOUNT.PARAMETER.
Cheque Collection records are created by the system for the full amount, without deducting charges. A
field named DEFER.CHARGE is introduced in TELLER.TRANSACTION, if the credit side transaction
code matches the transaction code defined in ACCOUNT.PARAMETER or STOCK.PARAMETER
under CHQ.DEP.TXN. If YES is defined under DEFER.CHARGE, then the charges defined at
TELLER level will be carried over to Cheque Collection record and will be processed at the time of
regularising the credit as CLEARED or RETURNED. Otherwise the charges will be collected at the
Teller entry level itself.
Introduction
Interest and charges for accounts are accrued either on a DAILY or MONTHLY basis, the default
frequency being monthly. The frequency is normally defined in the ACCOUNT.ACCRUAL application.
Daily accruals may be requested for all accounts, all foreign or all local, or by product category.
When a daily (or other period) accrual is required for the accounts, however the accrual entries do not
need to be raised for each individual account, the level of currency, department and product category
or group should be sufficient. Accrual entries should be raised as a single P&L (CATEG.ENTRY) and
special (RE.CONSOL.SPEC.ENTRY) for each grouping.
When an account is capitalised, or a detailed accrual is required, the system will ensure that the group
accrual figure for as given account is reversed to avoid reporting the same figure twice.
This bulk accrual facility is created to allow these daily (or other) periodic accruals and postings to be
performed at a high level. Where bulk accrual takes place the accrual calculation is simplified and is
simply on a daily accrual figure. The daily accrual figure can be revised when an individual account
moves.
This identifies which product categories are to be accrued, the frequency of the accrual and
recalculation of daily accrual figures.
The Close of Business programs will compare any duplicate / overlapping settings made in this
parameter file and the ACCOUNT.ACCRUAL file and will give precedence to the group accrual
functionality.
A rebuild of the group accrual files is necessary when a GROUP.ACCRUAL.PARAM record is input
and whenever the parameter settings for group accruals have been changed.
The Group Accrual files can be rebuilt on-line or as part of the batch processing.
The application REBUILD.GROUP.ACCRUAL is used to drive the rebuilding of Group Accrual. The
figure below shows the accrual of all current accounts.
Each account subject to group accrual will store a daily average accrual figure for each type of interest
and/or charge defined. This figure will be re-calculated either when an account moves or when a
scheduled recalculation is run. The figure is calculated by projecting the interest forwards to the next
capitalisation date (based on the current account balances). The projected interest / charge amount is
then divided by the period of the calculation to give an average daily amount. The daily amount will be
stored in the application GROUP.ACCRUAL.DETAIL (See figures screenshot below); amounts will be
held by P&L category.
TSA.SERVICE
The TSA.SERVICE record BNK/GROUP.ACCRUAL.ONLINE can be activated to run on line, and will
run indefinitely until stopped by the user.
The function of this agent is to reduce Close of Business overhead processing time for any intra day
updates to the group accrual records.
The associated GROUP.ACCRUAL.DETAIL records pertaining to this account will be rebuilt online.
Introduction
Accounts can be linked into a hierarchical structure of individual groups. Each group consists of a
main account to which other (sub accounts) can be linked. A main account in one group can be a sub
account in another higher-level group. At any one time an account can therefore be a member of a
maximum of two ICA groups.
There is no limit imposed on the number of sub accounts in an individual group and no limit imposed
on the number of levels of groups in a hierarchy.
Accounts within a group and therefore within the same hierarchy must be of the same currency or of
the same fixed currency group, e.g. members of the Euro group.
Hierarchies are constructed for the purpose of distributing the difference between interest earned by
the group as a whole, based on the interest conditions pertaining to the main account of the group,
and the total of the interest earned by the individual group members (including the main account).
Interest distributions are split into the four interest types available in T24, i.e. DR, DR2, CR and CR2.
NB. Tax and charges are not applicable to ICA hierarchy interest calculation and postings; their
purpose is for the distribution of interest only.
NB. ICA group interest is not accrued it is calculated and posted at the time the main account in a
group is capitalised.
The difference between interest earned by the group as a whole and the total of the interest earned by
the group members can be distributed to the sub accounts of the group using two different methods: -
Ratio: where a straight percentage of the group interest is allocated to a sub account.
! Group Difference * Ratio / 100
! Interest: where the proportion of interest earned by the sub account indicates the proportion
of group difference allocated to the sub account.
! Group Difference * (Interest earned by sub account / Interest earned by all accounts).
In both cases the remainder of any unallocated interest is allocated to the main account.
Using the Ratio method the default scenario will be to allocate zero ICA interest to the sub accounts
and therefore all interest goes to the main account.
If when a main account is capitalised a sub account has subsequently been closed, then any ICA
interest due to the sub account will be allocated to the main account. If the main account has been
closed then the interest due to the main account will be allocated to a suspense account.
NB. Account Class records must be created for ICA interest, they should have the following keys: -
If desired the category codes can be set to be the same values as for normal interest i.e.
The account class records SUSPCREDIT and SUSPDEBIT.
The following example describes a simple ICA hierarchy of one top-level group with two sub groups.
The example shows a small ICA hierarchy made up of three actual groups, ICA1 the top-level group
and ICA2 and ICA3 two sub level groups linked to the top-level group.
Each group has three accounts, one main account and two sub accounts.
Two of the accounts AC2 and AC3 are both main accounts of their respective groups and sub
accounts of the top-level group. The top account is AC1.
• Group interest is calculated using the group balance and the interest rate applicable to the main
account.
• Group difference is calculated as group interest - normal interest.
N.B. the formula used to calculate interest in this example is simplified to be a straight percentage of
the balance.
Interest distribution is shown using the ratio method, with values shown on the sub dist% field.
• Normal Interest.
• Sub account level group distribution interest.
• Main account level group distribution interest.
N.B. Group Interest will be calculated at the capitalisation dates, it will not be accrued during the
capitalisation period.
Generally the capitalisation dates of sub accounts should coincide with those of the main account. If
capitalisation is monthly then the day of the month should be the same for main and sub account. The
capitalisation frequency of the sub account must not be less than that of the main account, e.g. a sub
account can capitalise monthly and a main account quarterly not vice versa. An override will be
generated if this is not the case.
N.B For the Interest compensation to work properly, interest capitalisation frequency
should not be less than monthly.
Special ACCT.ACTIVITY records are created to store ICA information related to account balances, for
each group and for situations where an account or group of accounts were only partial members of an
ICA group.
In the same manner special STMT.ACCT.XX and CORR.ACCT.XX records will be created to store the
interest calculation results for ICA groups, where XX indicates DR, DR2, CR and CR2.
Correction processing takes place in the same manner and at the same time as standard T24 interest
correction processing.
The actual interest postings of ICA interest will be stored on the standard T24 STMT.ACCT.XX
records.
ICA.HIERARCHY.PARAMETER
This record must be set up first, before any input can be made to build a hierarchy.
It contains category and transaction codes for all the possible types of ICA interest postings.
If on first input the record is committed it will default the existing hard coded category and transaction
codes used to post interest in T24.
A second input can be made to modify the relevant codes, which can be used to identify ICA postings.
For example it may be decided to keep the existing category codes but to use different transaction
codes for ICA interest.
ICA.HIERARCHY
Before an ICA hierarchy can be set up, a record to describe the hierarchy and to define the main
account of the top-level group of the hierarchy must be defined.
A hierarchy should be set up in a logical manner starting from the top account and progressing down
through the hierarchy level by level.
The top account in the hierarchy is defined by linking it to itself, indicated by the field
ICA.MAIN.ACCOUNT.
The field ICA.MAIN.ACCT.IND is set to YES indicating that this account is the main account of an
ICA group.
ICA.DISTRIB.TYPE indicates that the distribution method for which this group is the main account is
to be the RATIO method.
ICA.POST.INTEREST is applicable to all ICA accounts and indicates the type of interest posting
applicable to all interest types for ICA accounts. There are three types of interest posting: -
• OFF – No interest is calculated and interest statement files are not updated so no interest
is posted.
NB. The OFF option should not be selected for a main account as this has the effect of turning off ICA
interest postings for the whole group.
ICA.MAIN.RATIO indicates the total percentage of ICA interest, which has been allocated to sub
accounts for which this account is the main account when the ratio method interest distribution has
been defined.
In this example the account has been linked to a higher level account but has itself been defined as a
main account, i.e. ICA.MAIN.ACCT.IND = YES.
The fields ICA.MAIN.ACCT and ICA.MAIN.ACCT.DATE indicate that the historical links for this
account.
This example shows a sub account, which does not have any other accounts linked to it, i.e.
MAIN.ACCT.IND is null. If it is required to link sub accounts to this account then the
MAIN.ACCT.IND field should be set to YES before linking other accounts to it.
NB. In this example it can be seen that this account was linked to the main account 18961 from the
first of1st May, removed on the fifth of may5th May and then re linked on the 7thof August.
Interest is taken into account for ICA purposes only for the periods that an account was a member of
an ICA group.
In this example it has been decided to change the link for the above account from 18953 to 18961,
and for the link to be effective from the first of January.
If this account were itself a main account then changing the link would effectively change the links of
all accounts linked to this account.
Links cannot be back-valued past the last capitalisation date of the account.
ICA.GROUP.DETAIL
Each ICA group will have an associated ICA.GROUP.DETAIL record, which contains all pertinent data
for the group, and is updated automatically. The key to each record is the main account number of the
group.
It contains historical data related to the level that the group resided in the hierarchy, and to the
membership periods of sub accounts.
It is important to know the hierarchy level of a group, in particular the maximum number of levels that a
group has been from the top of a hierarchy. When account balances are combined for ICA groups into
special ACCT.ACTIVITY records those groups at the bottom of the hierarchy must be processed first;
this is because higher-level groups require the combined balances of lower level groups in order to
calculate interest. This information is stored in the MAX.PROC.LEVEL field.
Details of the group interest calculations relating to the latest ICA capitalisation are also stored here.
An application ICA.GROUP.HISTORY contains data relating to past interest capitalisation. The key is
appended with the capitalisation date.
ICA.GROUP.DISTRIBUTION
This file is updated whenever an ICA main account is capitalised, and is used to drive the ICA interest
capitalisation processing: -
• MAX.PROC.LEVEL indicates the process level of the group, those furthest from the top of a
hierarchy are processed first.
• INTEREST.CALC indicates which types of interest were capitalised characters 2 to 4 represent
CR, CR2, DR and DR2 accordingly.
• START.DATE.XX indicates the beginning of the respective interest calculation period.
• END.DATE is the capitalisation date.
• MAIN.ACCTY.KEY stores the ACCT.ACTIVITY keys used to store ICA group balances.
• PARTIAL.ACCOUNT stores details of all sub accounts which were not members for the full
capitalisation period.
• PART.ACCTYS stores the ACCT.ACTIVITY keys relating to the balances for the partial
membership period.
Only the relevant data for ICA interest calculations is stored i.e. the day number of the month and the
balance on that date. This example shows the combined balances for the top-level group.
STMT.ACCT.CR record
STMT.ACCT.CR Record
Details of ICA interest postings are stored in the standard T24 STMT.ACCT.XX record. This example
shows the CR type interest posting for account the main account of an ICA group. If this account were
also a sub account of a higher-level group the details of any interest due, as a sub account of the
higher-level group would also be shown.
When a Bank has all the customer information in place they will need to set-up a new TAX.TYPE,
APPL.GEN.CONDITION, TAX, TAX.GEN.CONDITION and a TAX.TYPE.CONDITION for the
customers that they wish to be considered for GWHT processing. This will basically be a German
resident as defined on the CUSTOMER file. The specific TAX.TYPE called GWHT will indicate that a
customer will be liable for German Tax. The following screen shots and descriptions will show
examples of how to set-up the processing tables: -.
TAX.TYPE: -
This application allows definition of the types of TAX, which may be calculated within T24. Conditions
for applying this tax for a given set of customer conditions maybe defined in the next set of
applications: TAX.TYPE.CONDITION and TAX.GEN.CONDITION.
APPL.GEN.CONDITION: -
Figure 363
APPL.GEN.CONDITION:-
This application can be used to allocate the group you have defined for GWHT. The above description
shows that for Money Markets Conditions, any deal entered under CONTRACT.GRP MMCAT which is
equal to category 21012 (MM Deposits.) is liable for GWHT if that CONTRACT.GRP is set up in
TAX.TYPE.CONDITION,TAX.TYPE.CONDITION. This will be shown in further diagrams. The
DECISION fields can be multi-valued to add in new conditions for that category, e.g. for GWHT
deposits placed at 1.00 % or less are not liable for GWHT, as shown in the shot below: -screenshot
below:
TAX
The set up of the TAX for GWHT is similar to the existing functionality but 3 new fields have been
entered:-
1. LINK.TAX. This new field will contain a link to another existing tax record on this file and will form
the basis of the ‘TAX-ON-TAX’ processing. The entry here must be a valid Tax record and if that
has a link tax already in place this must be checked for duplication.
1. LINK.TAX. This new field will contain a link to another existing tax record on this file and will
form the basis of the ‘TAX-ON-TAX’ processing. The entry here must be a valid Tax record and
if that has a link tax already in place this must be checked for duplication.
TAX.BASE this
2. new field will contain either Tax or Event. If tax is chosen this shows that the above id is to be
calculated as a tax on tax. If Event is chosen it will indicate that the above tax is linked to an event.
2. TAX.BASE. This new field will contain either Tax or Event. If tax is chosen this shows that the
above id is to be calculated as a tax on tax. If Event is chosen it will indicate that the above tax
is linked to an event.
3. UPDATE.POOL.SEQ. This new field has been introduced for the updating of the customer’s record
via a Kest type pool. (Pool.1) Any entries passed over Pool.1 are Kest liable so therefore will
update the CUST.TAX.ALLOWANCE accordingly. If left blank then no Pools will be updated.
3. UPDATE.POOL.SEQ. This new field has been introduced for the updating of the customer’s
record via a Kest type pool. (Pool.1) Any entries passed over Pool.1 are Kest liable so therefore
will update the CUST.TAX.ALLOWANCE accordingly. If left blank then no Pools will be
updated.
Shown below is the TAX file for ZEST with the link shown to SOLI.
The screen shot below will show the ‘LINK’ that the ZEST tax has with the SOLI. As you can see from
field LINK.TAX above, it is linked to another TAX record.
LINK.TAX with another TAX present will use the ‘TAX-ON-TAX’ scenario.
Figure 369
Figure 370
Each Tax has a different CATEGORY for processing. This allowance allows for the different amounts
of tax to be processed on an individual basis, per percentage of Tax. The Dr and Cr codes can remain
the same for bulk processing.
TAX.GEN.CONDITION:-
The set-up for TAX.GEN.CONDITION will determine who you want the process GWHT to affect. The
set up must contain the TAX.TYPE you set up originally and can be split to show the
Residency/Sector and Nationality of GWHT recipients.
The set-up here will also show those customers who are liable for GWHT but are also exempt to a
certain percentage of the Tax, e.g. Non-profit making organisations. These are also added here but
can have Exemption Certificates against them. This will be explained further on.
Below is the set-up for Customers that are liable for GWHT via standard T24 processing in
TAX.GEN.CONDITION:-TAX.GEN.CONDITION.
The next shot shows that any customers in 1000 or 1600 sector that are also resident in Germany and
have German Nationality are liable for GWHT. This can be changed if customers are not residents of
Germany and therefore not liable for GWHT.
EXEMPTION
Exemption
The next shot shows the Customer exemption. This applies to Non-profit making Organisations, e.g.
Churches, Sports Funds who can claim Part/Full exemption from GWHT. These are named ‘NV’
certificates and carry a wide range of percentage reductions.
The EXEMPTION shown here will bear a 50 % reduction on Zest processing if added to a
CUST.TAX.ALLOWANCE at input Stage.
TAX.TYPE.CONDITION
The TAX.TYPE.CONDTION table will govern which contract groups will incur GWHT.
Included with the TAX.TYPE.CONDITION is the tax liable for those chosen. As per the set up in
APPL.GEN.CONDITION, the contract groups set in here along with the Tax set up will form the main
GHWT functionality.
CUST.TAX.ALLOWANCE
The set-up of CUST.TAX.ALLOWANCE is based on all the above functionalities that have been set up
previous to this. It is individually based but there is an option to Merge/De-Merge customers based on
circumstances such as Marriage, Divorce, and Death.
This allows individual customers to increase their single allowance to a joint allowance. They can also
spread their allowance amongst different institutions depending on their account structure. But, as any
taxation, it is centrally reported, so therefore it is up to the individual/s to maintain their correct Tax
returns or be liable for penalties.
The set-up involves the T24 CUSTOMER number plus the current tax year (Which(which is added
automatically at process). For allowance purposes, the Customer has to request what amount he/she
wishes to use within the institution. Additionally, there is an ALLOWANCE.MOVEMENT amount which
lets the customer Increase/Decrease their current ALLOWANCE if need be by the process of a + or – in
front of the amount. This is governed by the MAX.ALLOWANCE amount,, which cannot be broken at
any time.
CUST.TAX.ENTITY
The CUST.TAX.ENTITY application allows the institution to Merge/De-merge customers to give them
1one single allowance for a joint couple (MERGE Process). This process happens (MERGE) if
customers are joined in Marriage.
It is up to the individual customers to tell the institution what allowance they wish to set (as per the
single CUST.TAX.ALLOWANCE) for the joint application. The rules of MAX.ALLOWANCE and
ALLOWANCE.MOVEMENT still apply for a joint application.
If one member of the party is does not hold an account with the institution, an account has to be set-
up to complete the merge. This process can only work for individual customers and not for any other
companies.
Once customers are merged you can amend their CUST.TAX.ALLOWANCE to a new amount if they
wish to Increase/Decrease their Allowance, however this cannot break their original MAX.ALLOWANCE.
The opposite of this is the De-Merge process. This happens if the Customers divorce or in the
circumstance of death. Again, it is up to the Individual/s to advise their Bank regarding this.
Once the De-merge process is complete you will need to set up a new CUST.TAX.ALLOWANCE for
the new customers again only if they wish to change their allowances.
On the next page you can see the Merge/De-merge process in the way of screen shoots, including the
CUST.TAX .ENTITY shots, including the CUST.TAX.ENTITY showing this.
The first two screen shots show individual customers with ‘SINGLE’ allowances before the ‘MERGE’
process.
Figure 170
The next will show the process of Merge and De-merge via CUST.TAX.ENTITY. Once set up
CUST.TAX.ENTITY will still keep a record of the ‘Individual’ allowances, but that is for the ‘De-merge’
option.
As stated, in the case of divorce or death the process of ‘De-merge’ will take place. This reverts the
customers back to their single status and a new allowance (if necessary) must be input. Depending on
the split of allowance, it must be checked against any outstanding and settled trades that have and will
pass through their accounts. This is done at customer level and they must advise their institution what
balance they have left (per customer) after they have decided on what allowance they have left.
ACCOUNTING SET-UP
Accounting Set-up
For T24 to post deducted tax amounts to CUST.TAX.ALLOWANCE the accounting side must be set
up correctly. For LC, MM and Interest and Charges the Transaction Codes are hard coded and
therefore must by defined for the individual deal type, otherwise T24 will calculate GHWT but not post
it to the Customer GWHT framework.
The accounting set up involves the input of a new field in the TRANSACTION application. The
UPDATE.INTEREST.POOLS field, when set to ‘YES’ will (as it states) update the Interest Pools of
POOL.1 (individual customer taxation) and pass accounting entries to show this. If left blank normal
accounting is still performed (Default is ‘NO’).
As stated before, the Transaction Codes for T24 Accounting are hard coded per module so for each
type the UPDATE.INTEREST.POOLS must be set to ‘YES’.
The hard coded Transaction codes are found in the SYSTEM.RECORD application of T24 and hold all
the Transactions codes for the different Modules.
Depending on what LD and MM deals you are setting up in your APPL.GEN.CONDITION you will
have to amend the TRANSACTION codes accordingly.
INCOME.TAX.CALC
This new field has been added to the MM and LD portion of GWHT and enables a customer to
indicate how the interest tax is to be calculated for the deposit.
1. FULL or NULL
The full interest will be calculated and deducted from the interest, i.e. no tax allowance nor exemption
will be taken into account.
2. REDUCED
The interest will be offset by any tax allowance or exemption. If the resultant is greater than 0 then it
will be used as the base to calculate the interest tax, which will then be deducted from the interest.
Otherwise, there will be no interest tax. The tax allowance of the customer will be REDUCED in both
cases.
3. ZERO
VALIDATION RULES
. NULL
. FULL
. REDUCED
. ZERO
DEFAULT IS ‘NULL’
Tax can be calculated JOINT.HOLDER wise on ACCOUNT interest by adding a sample routine
TAX.LOCAL.RTN in field no.34 CALC.ROUTINE in application TAX.
When tax joint holder wise is to be computed, a valid TAX.TYPE.CONDITION record has to be
specified in ACCOUNT.CREDIT.INTEREST / ACCOUNT.DEBIT.INTEREST /
GROUP.DEBIT.INTEREST / GROUP.CREDIT.INTEREST in the field TAX.KEY as shown in the
below screen shot.
As shown in the above screen shot, the field TAX.KEY has to be input with the tax type and not the
tax key for computing tax joint holder wise for an account.
From the tax type specified for the account, for the tax key applicable for the main customer based on
the tax type specified in CUSTOMER.CHARGE table, the local routine must be input in application
TAX in the field CALC.ROUTINE.
When a customer record is created based on the RESIDENCE, NATIONALITY, SECTOR, etc
TAX.GEN.CONDITION is validated for the tax conditions applicable for the customer and the same is
updated in table CUSTOMER.CHARGE. When the tax type is specified on the account interest, it
checks for a valid TAX.TYPE and a TAX.ACT.GROUP in CUSTOMER.CHARGE and applies the
TAX rate for the group in field CUST.TAX.GRP of TAX.TYPE.CONDITION for each joint holder.
TAX.LOCAL.RTN
The routine is to be input for the Tax key applicable to the main customer in the account. Tax for the
account will be computed JOINT.HOLDER wise and the total of the individual TAX will be computed.
Credit Interest or Debit Interest on the ACCOUNT, is divided equally based on the number of holders
and then Tax is calculated.
For example, if there is a main CUSTOMER.ID and a JOINT.HOLDER in an ACCOUNT with TAX
rates as 10% for the main CUSTOMER.ID and 20% for the JOINT.HOLDER based on their status,
and if the interest earned is 100USD, the interest amount will be equally divided as 50USD to each
JOINT.HOLDER and the tax computed would be 5USD for main CUSTOMER.ID and 10USD for the
JOINT.HOLDER, so the total tax for the ACCOUNT would be 15USD.
The individual tax amounts JOINT.HOLDER wise can be viewed through INT.MOVEMENT and
through the table TAX.CAP.LOCAL.INFO. To enable update of INT.MOVEMENT the field
INT.MVMT.UPDATE must be set to “Y” flag in application ACCOUNT.PARAMETER and also a valid
Interest and Charge application ID must be specified in field SYSTEM.ID in application
INT.MOVEMENT.PARAM.
Field SYSTEM.ID in application INT.MOVEMENT.PARAM has to be set to the Interest and Charges
application ID as shown in the above screen shot.
TAX.CAP.LOCAL.INFO displays the tax amount for the joint account customer wise as shown in the
screen shot above.
INT.MOVEMENT as displayed in the above screen shot will show the tax amount for the joint account
customer wise along with other details like total interest amount.
SUB-ACCOUNT PROCESSING
The ACCOUNT application allows the entries for an account to be distributed automatically across
sub-accounts. The system will automatically allocate an entry to a linked sub-account within the
accounting sub-system processing. This will ensure that locking contention is minimised.
Sub-accounts linked to the main account are held in the cross-reference table AC.SUB.ACCOUNT.
Whenever a transaction(both real and forward accounting transaction) hits a high volume account, the
system will allocate the sub-account from the AC.SUB.ACCOUNT table on a random basis using the
maximum number of sub-accounts as the maximum value.
The STMT.ENTRY record will be used to store the original account number under the field
MASTER.ACCOUNT.
Numbering sub-accounts
When using Sub accounts with internal accounts and internal Inter-company accounting the Sub
accounts can be set up to increment using either the CATEGORY or SUFFIX part of the account
number.
USD-11500-0001-0033
If the field INT.ACC.TYPE in AC.AUTO.ACCOUNT is set to CATEG then when sub accounts are
automatically opened by the system, it is the CATEGORY section of the account number that will be
incremented, up to the MAX.SUB.ACCOUNT (defined in the master account). For example the above
account number will become:
USD-11501-0001-0033
AC.AUTO.ACCOUNT
Figure 402 SETTING UP RULES FOR SUB-ACCOUNT CREATION FOR A/C CATEGORY
Fixed value
Some fields may hold a fixed value for sub accounts under a specific category, irrespective of the
value held in the Master account.
The associated fields FIELD.NAME and FIELD.VALUE allow the definition of the fixed value that
some fields will hold.
Any field defined with a fixed value will have priority over the inherited field, hence the field in the sub
account will hold the value defined in the FIELD.VALUE field.
Although the account is defined as a high volume account, some transactions may be excluded from
being distributed to sub accounts. This may be at application level or at transaction level.
This may be defined under the fields EXCLUDE.SYS.ID and EXCLUDE.TXN
A routine may be called to perform any other operation associated with the creation of the sub account.
This must be defined under the field CREATION.RTN
The entry has been distributed to a sub account which has been created automatically:
Figure 406 STMT.ENTRY distributed to sub account and MASTER.ACCOUNT hold value of original
account
Statement Printing
The account statements are generated by Sub Account, that is for each sub account there will be a
separate statement.
Nostro Reconciliation
Consult the Nostro Reconciliation User Guide for details of how sub-accounts will be handled
The NO.ENTRIES.START in the ‘DEFAULT’ record is set to 400, which means that consolidation of
statement entries will start once 400 entries have been raised for the day to both Internal and Nostro
accounts.
The detailed statement entries generated by the three FT entries have been consolidated based on
the consolidation criteria defined above.
The AMOUNT.LCY and AMOUNT.FCY from the detailed entries are added to the value in the
consolidated entry. A new EXCHANGE.RATE is calculated based on the value of the local and foreign
amounts.
The TRANS.REFERENCE and OUR REFERENCE in the consolidated entry contain the value NET-
consolidated id.
The original SYSTEM.ID is suffixed with the value NET – this will allow existing enquiries to drilldown
to the consolidated entry rather than the originating application since the contract reference will not be
present. The STMT.NO field will indicate the number of statement entries that have been consolidated.
STMT.ENTRY.DETAIL.XREF
STMT.ENTRY.DETAIL
The STMT.ENTRY.DETAIL application is a replicate of the STMT.ENTRY but which holds only the
detailed statement entries that have been consolidated. The Detail Id is the key to
STMT.ENTRY.DETAIL and it will hold the details of the statement entry.
The following shows the details of the two entries that have been consolidated:
Statement Printing
Although the statement entry is consolidated, the statement contains the contents of detailed entries.
Nostro Reconciliation
The NR.STATEMENTS will also include the details as per THE STMT.ENTRY.DETAIL.
The following shows the NR.STATEMENT record generated for the account.
The system will then raise consolidated category entries for those categories specified, the detail of
the underlying entries will be maintained in a new file, CATEG.ENTRY.DETAIL. Details will be linked
to the consolidated entry by a cross-reference file CATEG.ENTRY.DETAIL.XREF.
The consolidated entries will be written to the CATEG.ENTRY file and will be the entries presented in
standard account statements and enquiries.
ARCHIVING
The detailed entries that have been consolidated will be archived every six months. The detailed
entries are extracted from the consolidated statement entry id in the ACCT.STMT.PRINT. The
STMT.ENTRY.DETAIL record in ARCHIVE defines the archiving details for the detailed statement
entries.
Introduction
It is possible to mask accounting entries, where entries have either been posted incorrectly and had to
be reversed out, or other financial postings that customers do not want on their statements.
Masking is also necessary because some customers reconcile directly against the statements they
receive from the banks and unexpected entries can cause confusion to their reconciliation’s. This is
especially true when the statement is delivered electronically and the customer uses it to reconcile
internally within their computer systems.
Masking will only apply to statements only. The entry will not be removed from the account and the
transaction will not be deleted it, it just will not show on the statement.
A field called MASK.PRINT exists in STMT.ENTRY to indicate whether certain statement entries
should be masked from printing, or not. To update the MASK.PRINT field AC.PRINT.MASK allows
users to flag statement entries manually that customers do not want to see on their statements. The
selection of entries to be masked for a particular account will be assisted by the provision of
STMT.ENTRY enquiries.
Once the statement entries have been captured into AC.PRINT.MASK application, the system will
then perform routine validations on the selected entries, firstly to ensure the integrity of the selected
items and to also make sure that the net movement of the selected entries is zero.
Once all the routine validations have taken place, the statement print programs or formatting enquires
must now check the MASK.PRINT field on the STMT.ENTRY record, if the value of the field is true
then the entry should not be displayed.
AC.PRINT.MASK
As mentioned before, the AC.PRINT.MASK application has been produced to allow users to go in and
manually flag certain statement entries that have to be omitted from customers’ statements. This
section will show you how to set up an AC.PRINT.MASK record and explain the rules and validations
of the application.
First of all run the application AC.PRINT.MASK and capture and id which can be automatically
generated by setting up an AUTO.ID.START record for AC.PRINT.MASK and by also making sure
that the application exists in the COMPANY record under the PG.AUTOM.ID. Once you have
captured the id you will be required to capture the account number of the customer and the current
date in MASK.DATE. Enter dates in ENQ.START.DATE and ENQ.END.DATE. These dates are
captured to ensure that statement entries that are to be masked fall within the start dates and end
dates. If you do not enter any dates into these fields a default date of today will be captured in those
fields. The MASK field will indicate whether the statement entries should be masked and unmasked.
You can capture either “YES” or “NO” and which is mandatory. The MATCHED.TO field is used to
capture all the statement entries you wish to mask or unmask, however they must all be debit entries
or all credit entries. You cannot mix debit and credit entries in the same field. The same applies to the
MATCHED.FROM field. You can use STMT.ENTRY enquiries to pick the entries you wish to select to
update the relevant fields in STMT.ENTRY. There is an example below that explains how to run the
enquiries and to select, copy and paste the relevant entries into the MATCHED.TO and
MATCHED.FROM fields.
This is an example of all the statement entries that are associated with account number 0000001775.
To bring up this list you have to run an enquiry on the STMT.ENTRY application of all statements that
belong to the particular account that you want to mask.
Once you have found the statement entry that you wish to mask or unmask for printing on the enquiry
list, you then double click on the statement entry and the full record for the statement entry will then be
displayed as shown in Figure 0-3. You then highlight the statement entry id at the top of the record
and right click on the mouse and copy the id.
Once you have copied the statement entry id, you then go back to the running AC.PRINT.MASK
application, move your mouse to either the MATCHED.TO or MATCHED.FROM field, right click on them
and then paste the id into the field and hit enter. Once you hit enter, the fields TO.TOTAL and
FROM.TOTAL as well as the NET.TOTAL field will be updated with totals in the statement entry
record. Once again, make sure that your MATCHED.TO and MATCHED.FROM fields consist of either
all debit or all credit entries.
When all the entries have been captured you can then commit and authorise the record, but the
system will make sure that the net movement between the statement entries captured is zero.
Once the authorisation takes place the relevant STMT.ENTRY records will be either masked or
unmasked for printing at a later stage.
AC.PRINT.MASK
Key Description
ACCOUNT.NO Account number of the statement entries you
want to flag.
MASK.DATE Current date of the system.
ENQ.START.DATE The start date for the selection of entries by
booking date.
ENQ.END.DATE The end date for the selection of entries by
booking date.
MASK Indicates whether the statement entries captured
should be masked (YES) or unmasked (NO).
MASK.NARRATIVE Descriptive field used to update the entry.
MATCHED.TO This is where the statement entry id from
STMT.ENTRY file is captured to be matched. If
there is more than one then they must be all
debits or all credits entries.
TO.TOTAL This will be updated by the system. This is the
total sum of all the MATCHED.TO entries.
MATCHED.FROM This is where the statement entry id’s from the
STMT.ENTRY file are captured. If there is more
than one they must be all debits or all credits.
MATCHED.FROM This is where the statement entry ids from the
STMT.ENTRY file are captured. If there is more
than one they must be all debits or all credits.
FROM.TOTAL This will be updated by the system. This is the
total sum of all the MATCHED.FROM entries.
US REGULATION D COMPLIANCE
US Regulation D Compliance
In order to allow the record of any Regulation D violation on-line, the Core Accounting module has
been modified to facilitate this regional development, by allowing a locally developed accounting sub
routine to be defined.
This routine will accept accounting entries, and optionally return a list of override messages at the
input stage, i.e. for unauthorised entries.
The rule to generate the overrides is defined in the local subroutine, an example program namely
AC.TEST.NAU is provided.
Although other user processing may also take place, care must be taken to ensure system
performance is not affected.
The core system will then process these overrides, including the possibility of logging them with the
DISPO module.
Account.Parameter
ACCOUNT.PARAMETER
The Core Accounting routine will fetch the local routine if it is defined in ACCOUNT.PARAMETER
under ACCT.NAU.SUBRTN.
Override Messages
When a transaction is being processed the Core Accounting routine will process all the system
overrides then will call the local routine and generate the local overrides.
As from the example program, an override message ‘HAVE A NICE DAY’ is generated at the
transaction input stage.
The example below shows a Funds Transfer input and the flow of the override message. Once the
system overrides have been raised then the local ones will be raised.
Figure 446 - First system override showing same debit and credit account