4 Core PDF

T3IMBR - Core - R9.
01
T3IMBR - Core - R9.01
Modification of CUSTOMER records or insertion/modification of

TAX.GEN.CONDITION records will be updated in the default customer tax groups
in CUSTOMER.CHARGE only during COB.
For each TAX.TYPE .
Whenever a CUSTOMER is input, a record is created by T24 in
CUSTOMER.CHARGE where default customer tax groups are updated using
TAX.GEN.CONDITION parameters
Actual customer tax groups in CUSTOMER.CHARGE could be modified by user.
If no group could be identified for a Customer for a Tax Type, the groups for the Tax
Type will not be updated by T24 in CUSTOMER.CHARGE
Modification of tax record values will not modify the tax already calculated.
Input a tax record with an effective date, if the rates change
The Tax account number format is: CCY-5 digit Category Code-4 digit suffix. If
UNIQUE.SUFFIX is not set to Y, all the transactions involving Tax will be posted to
the same internal account (suffix 0001), as a result, there could be delay in case of
large volume transactions to be simultaneously posted. When the UNIQUE.SUFFIX
field is set to Y, then the tax transactions will be posted to different internal accounts
with different suffixes, generated as a random number, thus avoiding locking
situation. The random number is by default between 1 and 20, but can be increased
by setting the field MAX.TAX.SUFFIX in ACCOUNT.PARAMETER.
Field TAX.ROUNDING is not currently used
TAX.OPERANDR value Plus - Base amount: 100 and Tax:15

Payment to Customer:
Dr: P&L: 115 and Cr: Customer:100, Cr: Tax:15
Receipts from Customer
Dr: Customer: 115 and Cr: P&L:100, Cr: Tax:15
TAX.OPERANDR value Minus - Base amount: 100 and Tax:15
Payment to Customer:
Dr: P&L: 100 and Cr: Customer:85, Cr: Tax:15
Receipts from Customer
Dr: Customer: 100 and Cr: P&L:85, Cr: Tax:15
The customer grouping for Tax is updated by T24 in CUSTOMER.CHARGE. For a

joint account, Tax by default will be calculated as per the Tax group of the primary
customer. When the core routine TAX.LOCAL.ROUTINE is attached to the field
CALC.ROUTINE in the TAX record (related to the TAX.TYPE which is specified
in ACI, GCI, ADI or GDI), then the Tax base amount will be equally divided based
on number of joint account holders, and the tax will be calculated on each amount,
as per the rates defined in TAX.TYPE.CONDITION for each joint account holders
tax group.
Core routine TAX.LOCAL.RTN available to calculate tax based on the joint
account holders tax groups
10
Example: Transaction amount: 5000 TAX ID attached 1.

In TAX record 1.20060101, Field RATE:30, LINK.TAX:2.20060101 and
TAX.BASE:EVENT
In TAX record 2.20060101, Field RATE:10 and TAX.BASE: EVENT
Tax calculated for Tax 1: 5000*30%=1500 and for Linked Tax 2: 5000*10%=500,
since the Link tax is on event
In the above case, if in TAX record 2.20060101, TAX.BASE is defined as TAX,
then
Tax calculated for Tax 1: 5000*30%=1500 and for Linked Tax 2: 1500*10%=150,
since the Link tax is on tax already calculated
11
In field TAX.CODE, ID of a TAX record without the date part will be specified.
T24 will use the parameters in the latest dated record.
12
For Accounts, either a TAX.TYPE ID (such as WHT Withholding Tax) or a TAX

ID (which specified a percentage) could be defined in ACI, ADI, GCI, GDI.
Similarly, for charges and commission, a TAX.TYPE ID or a TAX ID could be
attached to FT.CHARGE.TYPE and FT.COMMISSION.TYPE
Similarly at contract level either a TAX.TYPE ID or a TAX ID could be attached to
calculate tax on Principal or Interest or on both, which are application dependent.
13
14
15
16
17
Some of the fields of FT.COMMISSION.TYPE are application specific such as for

FT and LC
Fiduciaries use the commission parameters specified in FD.COMMISSION.TYPE
In cases where the transaction is principal debit amount plus charges or charges are
consolidated before posting, then the application will assign its own transaction
code to the debit entry
18
When charges for the currency of the contract or the currency of the charge bearing
account in case of FT is not defined, the contract amount or the transfer amount in
case of FT is converted into the local currency (if charges are defined for local
currency) or into the default currency (if charges are not defined for local currency
but only defined for default currency). Then the charges are calculated as per the
parameters for calculation, and finally the amount is converted into the currency of
the account bearing the charges
19
If CALC.TYPE Field is set as LEVEL, the parameters which correspond to the

transaction amount applied to entire amount
If it is set as BAND, parameters for each range of transaction amount separately
applied and totaled
20
MINIMUM.AMT of each range should be greater than or equal to the

MINIMUM.AMT of previous range
21
OVERALL.MIN.AMT must be less than or equal to the first minimum amount

specified within a range for the currency
22
23
If CHARGE.PERIOD in FT.COMMISSION.TYPE is 3, and LC duration is 12

months, then in LC the field CHARGE.PERIOD will be defaulted as 4, and the
commission will be recovered for 4 periods (4 times the normal commission)
If CHARGE.PERIOD is 3, and MINIMUM.PERIOD is also 3 and a LC is of
duration 3 months, then the charge will be recovered 3 times, instead of 1 time
24
25
26
27
Different interest day basis for calculation of interest is possible depending on

methods followed for calculating number of days in an interest period and days in a
year. Input in this field determines the components for the interest calculation.
The following values have been defined as Numerator and Denominator for each
type.
Type A is where each month is considered to have 30 days for the numerator and
the denominator will also be 360. Sub Divisions of A are A1 and A2. A1 360/360.
For A1, additional interest for February is calculated on the last day of February,
under A2, it is calculated on the penultimate day of February. Under Type B exact
number of days will be considered in respect of the numerator while the
denominator will be 360. C is where the exact number of days will be considered in
respect of the numerator while the denominator will be 365 in a non-leap year and
366 in a leap year. Method D is that each month is considered to have 30 days for
the numerator while the denominator will be 365 in a non-leap year and 366 in a
leap year. E method is where the exact number of days will be considered in respect
of the numerator while the denominator will be 365. F is the method where each
month is considered to have 30 days for the numerator while the denominator will
be on a 365 basis. Subdivided into methods F1 and F2. F1 and F2 are similar to A1
and A2 for calculation of interest for additional days in February. Method H is
where month is considered to have 30 days for the numerator while the denominator
will be 356. S is for Special interest basis.
28
29
30
Floating interest rates are defined in BASIC.RATE.TEXT and actual rates

applicable are updated in BASIC.INTEREST. In BASIC.INTEREST table, rate
change is indicated with the effective date for such a change, the underlying
Accounts derive the new rate from this table.
It is possible to set negative rate of interest in BASIC.INTEREST. It is used only in
MM, SW and DX applications.
Though negative spread can be specified over basic interest rate for all types of
accounts, it is possible to set negative interest rates only for accounts in credit
balance. To do this, the NEGATIVE.RATE Field on GROUP.CREDIT.INT or
ACCOUNT.CREDIT.INT must be set to Yes or BLOCK.MARGIN.
If set to YES, this would enable collecting interest from accounts with credit
balances. Negative interest in an account could result due to a negative spread being
higher than the underlying floating rate. For example, a negative spread of 2%
(Minus 2%) on LIBOR which is 1.5%. In this case as the interest being capitalised
is negative, it will be debited from the customer account instead of making the
interest as zero. If set to no, then the rate would be considered as Zero. If set to
BLOCK.MARGIN, negative effect will not be allowed because of margin. Negative
margin can not make the rate more negative or a positive rate to negative. For
Example, If base rate is -7, ( Minus 7%) margin is -2 ( Minus 2%) then net effect
will be -7 ( Minus 7%).If margin is +2 ( Plus 2) then the effective rate become -5 (
Minus 5).If base rate is +5 ( plus 5%) and margin is -7 ( Minus 7%) then effective
rate will be zero not negative.
31
32
This table is used for LIBOR type rates of this nature . Rates vary depending on
the length of time and for Bid and Offer purposes.
For contracts that are set to rollover automatically, this table can be linked for rate
reviews. At the scheduled dates the system will refer to this table and automatically
pick up the relevant rate and apply that to the contract until the next review date.
This table maybe automatically updated/interfaced daily with an external feed such
Reuters, or maintained manually by the user.
PERIODIC.INTEREST keys are generated daily by the System. It is possible to
effect changes in rates of dates prior to system date.
As a result, all MM contracts which had accessed the (changed) key at an earlier
date, will recalculate interest based on the changed interest rates.
It is possible to stipulate the extent of interest tolerance to be allowed for MM
contracts in the field Int Tolerance. A tolerance entered here will be used to check if
an over-ride is required for any interest rate difference found on any money market
contracts entered.
33
34
Field: DEFAULT.MIS.TABLE is not used by MI module. MIS rates can be given

either as a rate or as a floating rate key in the contract or it can be given as a pooled
rate in MI.PARAMETER
35
LOCAL.ROUTINE : By using local routines in this field, regional developers can

add their own tables to T24 and return spreads and/or interest rates based upon
decisions in their own routines. As an example, Money Market Auto Rollovers can
use a routine to determine new rates and/or spreads based on locally developed
spread tables related to department and customer groups.
36
37
COUNTRY: Contains static details of each Country, for example, Country Name, Currency Code
etc. Dummy Country codes may be used for entities that do not have an official Country code but
have a Currency Code, for example, the European Currency Unit.
HOLIDAY: This table is used to indicate the public holidays for each Country, or Region within a
Country, for the calendar year over which the bank's current business is spread. User must indicate,
for each Country or Region, the public holidays and which days of the week make up the weekend.
All T24 Application will refer to this table during input validation to check that if any dates entered
by the User are holidays and/or to raise an override to accept any contract event that fall on a
Holiday. It is also used to determine the delivery date, by taking non-working days into
consideration.
38
39
40
41
GEOGRAPHIC.BLOCK: allows user to define countries within a particular

geographical block. Countries that are not allocated to any geographical block
remain in a geographical block called OTHER until allocated.
Country: This table contains the static details of each individual Country, for
example, Country Name, Currency Code(s) etc. The use of the I.S.O Country codes
are recommended as a standard for the key of this table.
REGION : The purpose of this table is to segregate a Region within a Country
where the public holidays differ from other parts of the Country. This enables a
separate HOLIDAY table to be defined for the Region, to allow delivery to be
controlled correctly within the T24 system. Up to 99 regions may be specified for
each Country.
HOLIDAY: For each Country or Region, the public holidays and which day(s) of
the week make up the weekend are specified here. The non-working weekend days
are then generated automatically for the year and for this reason they do not have to
be specified individually as public holidays.
All T24 Applications refer to this table during input validation to verify that any
dates entered by the User are working days or to force an override to accept nonworking days. It is also used to determine the delivery date, by taking non-working
days into consideration.
42
CURRENCY.PARAM: Contains common details for each Currency to ensure that

the same numeric code and no of decimals are used on different currency files in a
multi company environment. Currency name and Interest basis maybe changed at
individual Currency file level. Numeric currency code, an alternate to Currency
code, can only be changed on this file. Once a record has been authorised, number
of decimal places cannot be changed. In the field EQUIVALENT.CCYS
relationship must be established to enable currencies to be used as interest or charge
currencies on any accounts set-up for the main currency. If two currencies are
involved in a conversion, then the currency with the lowest rank will take
preference as base currency
CURRENCY.MARKET: Possible to create different market rates for the same
currency - Separate rates for Notes / Travellers Cheques etc. Consolidation keys are
formed market wise. Markets beyond 9 will be consolidated with the market type of
the first digit example 10 with 1.
FORWARD.RATES: The Rest periods can be defined either in months, e.g. 1
month, or in days, e.g. 7 days, 15 days etc. To calculate the date of the rest period,
the system will add to the SPOT date the value defined in the field REST.PERIOD.
If the Rest period is defined in months and the calculated date falls on a non
working day, the date is moved forward to the next working day. If, however, this
next working day falls in the next month, the system will instead move
BACKWARD to the previous working day in the same month.
43
44
It is possible to specify different exchange rates for different markets using the multi
value fields.
The rates mentioned here are the market rates for the currency. A negotiable
amount upto which the departments can use the above rates is also mentioned for
each market. If the transaction value exceeds this, then rates are to be obtained
from Treasury department.
Over and above the market rates, Treasury department margin and marketing
department margins can also be added and this could be different for small value
transactions and medium value transactions.
Trsy.small.sprd : Defines the spread Treasury require from small value transactions.
This default Treasury spread will be used by the System to calculate the Treasury
Buy/Sell rate in any transaction where the amount is less than the Upto Small
Amount.
Cust.small.sprd : Defines the default spread marketing areas require from small
value transactions. This spread will be recognised as the default exchange profit of
the transaction attributable to the Marketing area. When the user does not want to
apply this default spread on any particular transaction, he will always have the
possibility to input the spread at the transaction level. The spread will be used by
the System to calculate the Customer Buy/Sell rates by modifying the Treasury
Buy/Sell rates. Quotation or use of a rate, other than the Customer Buy/Sell rate,
will only affect the profit margin of the marketing area.
45
46
The category table is one of the most important table for the accountants. In T24
You will not be able to create an account without having a category linked to, or you
will not be able to input a contract based transaction without link to a category
which indicates which product or sub-product the transaction belongs to.
47
The use of these codes, together with selection criteria defined in the
CONSOLIDATE.COND table, e.g. Residence, Status, Industry and Sector codes
etc., enable the Bank to produce balance sheets and returns reflecting a coordinated
and structured view of its operations, by directing business transactions to their
appropriate place on the report.
(1) Loans by Industry (Criteria - Industry) segment
(2) Geographical distribution (Criteria - Residence) of Loans & Deposits
(3) Sectoral (Criteria - Sector) distribution of Loans & Deposits
48
A Category table is delivered with every T24 implementation to save time creating
thousands of records from scratch. Client can decide to use the delivered
categories, add new ones within specific ranges, modify those that need changes and
mark as `Reserved for future use those categories that they do not need for the
present.
There is in-built validation to prevent non PL codes being assigned as PL.
49
Accounts use 1000 to 199999 range. Accounts are classified into 2 broad ranges as
Customer Accounts and Internal Accounts. Customer Accounts are allocated the
range of 1000 to 9999, whereas Internal Accounts are allocated the range of 10000
to 19999. It is possible to accrue Interest for Customer Accounts, whereas it is not
possible to accrue interest for internal accounts. Within Customer Accounts,
product wise ranges are also suggested by Temenos.
50
Contracts use 20000 to 49999 range. Under this broad range, each application has
its own allocated range.
FOREX application can use only 20000 to 20999 range while
MM.MONEY.MARKET and LD.LOANS.AND.DEPOSITS applications share the
same range of 21000 to 21999, as their business is similar.
However, as these handle deposits as well as loans, and as accounting is automatic,
there are sub ranges for deposits and loans. If a loan business product is made to use
the range meant for a deposit product, accounting entries will be passed as though it
were a deposit. Hence, we should be careful in using the correct range for the
correct business product.
While Securities have a range of 22000 to 22999, they use only one single defaulted
category code of 22999.
Similarly for every other Contracts application, there is a particular range to be
used, all of them falling within 20000 to 49999 range.
These ranges and sub-ranges within facilitate automatic accounting.
51
The Profit and Loss items are broadly classified as Product related items and Non
product related items or overheads.
Accordingly, 50000 to 59999 is used for product related Profit and Loss items and
60000 to 69999 is used for overhead items.
Product related income or expenditure arise from Banks operations like Loans,
Deposits , Letters of Credit ,Overdrafts , Savings accounts etc.
Overheads cannot be linked to any specific banking product and are mostly internal
expenses and income resulting not from day to day operations.
The Closing category specified in FX.POS.TYPE table (69999) is used during
annual closing to transfer balances from all Profit and Loss items. This is finally
transferred to Internal Account specified in ACCOUNT.CLASS table with Id of
PLCLOSE.
52
53
54
55
56

4 Core PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

4 Core PDF

Загружено:

Авторское право:

Доступные форматы

T3IMBR - Core - R9.

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

Modification of CUSTOMER records or insertion/modification of

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

Field TAX.ROUNDING is not currently used

T3IMBR - Core - R9.01

TAX.OPERANDR value Plus - Base amount: 100 and Tax:15

T3IMBR - Core - R9.01

The customer grouping for Tax is updated by T24 in CUSTOMER.CHARGE. For a

T3IMBR - Core - R9.01

Example: Transaction amount: 5000 TAX ID attached 1.

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

For Accounts, either a TAX.TYPE ID (such as WHT Withholding Tax) or a TAX

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

Some of the fields of FT.COMMISSION.TYPE are application specific such as for

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

If CALC.TYPE Field is set as LEVEL, the parameters which correspond to the

T3IMBR - Core - R9.01

MINIMUM.AMT of each range should be greater than or equal to the

T3IMBR - Core - R9.01

OVERALL.MIN.AMT must be less than or equal to the first minimum amount

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

If CHARGE.PERIOD in FT.COMMISSION.TYPE is 3, and LC duration is 12

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

Different interest day basis for calculation of interest is possible depending on

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

Floating interest rates are defined in BASIC.RATE.TEXT and actual rates

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

Field: DEFAULT.MIS.TABLE is not used by MI module. MIS rates can be given

T3IMBR - Core - R9.01

LOCAL.ROUTINE : By using local routines in this field, regional developers can

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

GEOGRAPHIC.BLOCK: allows user to define countries within a particular

T3IMBR - Core - R9.01

CURRENCY.PARAM: Contains common details for each Currency to ensure that

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01

T3IMBR - Core - R9.01