Arrangement Architecture - Introduction - Property Classes PDF

Arrangement Architecture – Introduction / Property Classes
TEMENOS T24
Arrangement Architecture
Introduction / Property Classes
User Guide
Information in this document is subject to change without notice.

TEMENOS T24 User Guide Page 1 of 120
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.
Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Table of Contents
Introduction ............................................................................................................................................. 5
Application Overview ........................................................................................................................... 5
Property Classes..................................................................................................................................... 7
ACCOUNT............................................................................................................................................... 7
Overview.............................................................................................................................................. 7
Property Product Relationship............................................................................................................. 9
Related Balances ..............................................................................................................................10
Property Attribute Description and Use .............................................................................................11
Property Details .................................................................................................................................12
Action Synopsis .................................................................................................................................16
Accounting Events.............................................................................................................................17
Limits Interaction ...............................................................................................................................17
Delivery..............................................................................................................................................17
ACCOUNTING ......................................................................................................................................18
Overview............................................................................................................................................18
Property Product Relationship...........................................................................................................19
Summary of Rules Based Accounting...............................................................................................20
Periodic Attributes .............................................................................................................................23
Action Synopsis .................................................................................................................................23
Delivery..............................................................................................................................................23
ACTIVITY.API .......................................................................................................................................24
Overview............................................................................................................................................24
Action Synopsis .................................................................................................................................26
ACTIVITY.CHARGES ...........................................................................................................................27
Overview............................................................................................................................................27
Action Synopsis .................................................................................................................................29
ACTIVITY.MESSAGING .......................................................................................................................30
Overview............................................................................................................................................30

Summary of Rules Based Delivery....................................................................................................32

Configuring T24 Delivery for an AA Product .....................................................................................34
Periodic Attributes .............................................................................................................................42
Action Synopsis .................................................................................................................................43
Delivery..............................................................................................................................................43
ACTIVITY.PRESENTATION .................................................................................................................44
Overview............................................................................................................................................44
Action Synopsis .................................................................................................................................46
CHANGE.PRODUCT ............................................................................................................................47
Overview............................................................................................................................................47
Action Synopsis .................................................................................................................................51
CHARGE ...............................................................................................................................................52
Overview............................................................................................................................................52
Action Synopsis .................................................................................................................................59
CUSTOMER..........................................................................................................................................61
Overview............................................................................................................................................61
Synopsis of Actions ...........................................................................................................................63
INTEREST.............................................................................................................................................64
Overview............................................................................................................................................64
Action Synopsis .................................................................................................................................71
LIMIT .....................................................................................................................................................75
Overview............................................................................................................................................75
OFFICERS ............................................................................................................................................78
Overview............................................................................................................................................78
OVERDUE.............................................................................................................................................81
Overview............................................................................................................................................81
PAYMENT.RULES................................................................................................................................86
Overview............................................................................................................................................86
PAYMENT.SCHEDULE ........................................................................................................................90

Overview............................................................................................................................................90
TERM AMOUNT ...................................................................................................................................96
Overview............................................................................................................................................96
Product Property Relationship...........................................................................................................96
Periodic Attribute Classes associated with Term Amount...............................................................100
Accounting Events...........................................................................................................................102
Interaction with Limits System.........................................................................................................103
Delivery............................................................................................................................................103
TRANSACTION.RULES .....................................................................................................................104
Overview..........................................................................................................................................104
Synopsis of Actions .........................................................................................................................106
PROTECTION.LIMIT ..........................................................................................................................107
Overview..........................................................................................................................................107
UI.APPEARANCE ...............................................................................................................................109
Overview..........................................................................................................................................109
UI.BEHAVIOUR ..................................................................................................................................111
Overview..........................................................................................................................................111
USER.RIGHTS....................................................................................................................................113
Overview..........................................................................................................................................113
PROXY.PERMISSIONS......................................................................................................................115
Overview..........................................................................................................................................115
PRODUCT.ACCESS...........................................................................................................................117
Overview..........................................................................................................................................117
ARRANGEMENT.PREFERENCES ....................................................................................................119
Overview..........................................................................................................................................119

Introduction
Application Overview
The AA module provides a flexible framework that allows a number of new T24 modules to be created.
The application provides a business component based architecture for the management of products.
The main features of the AA module are:
Product Builder
The application provides the ability to allow the user to construct banking products by combining
different business components. PRODUCT.LINES which provide functionality for different banking
areas are licensed by Temenos; each product line utilises a number of property classes (business
components) that are fully configurable.
Main features of the product builder are:

• Ability to build families of products.
• Ability to inherit properties from the product family structure.
• Ability to determine the properties that a product is comprised of.
• Control of default values to be applied for product arrangements.
• Dated conditions for products.
• Full control of scope of negotiation between product and arrangement conditions.
• Control of negotiation of attributes over time.
• Design/Proof/Publish lifecycle for product management.
• The product builder can be used to create and maintain existing application (Mortgage,
Account, Loans and Deposits and AZ) product parameters.
Please see the Product Builder user guide for more details.
Arrangements
An arrangement is an agreement between the bank and interested party to provide an agreed service.
The AA module provides the ability to manage arrangements for created products.
Main features of arrangements are:

• An arrangement is an instance of the product.
• The arrangement properties and attributes may track the product conditions (i.e. change
when the product definition is amended).

• The arrangement properties and attributes may be fixed based on the product definition at
creation time.
• The arrangement property attributes may be negotiated / override the product definition
according to product defined rules.
Product Lines Available

The following PRODUCT.LINES are available which utilise the AA framework. Each product line
requires a licence to be obtained from Temenos to allow building and use of products.
RETAIL.LENDING
The AL module provides a fully flexible retail lending functionality for T24. The module allows retail
products to be created with the following features:
• Full support for commitment processing.
• Unlimited interest types including penalty interest.
• Unlimited charge types.
• Fully integrated rules based overdue and aging processing.
• Ability to amend / reverse / update arrangements back dated with full automatic recalculation
and adjustment of contract.
• Ability to pay in and disburse the arrangement through any T24 application and channel that
allows the specification of a T24 account. As a result disbursal and Repayment can be from
accounts in any currency.
• Fully flexible repayment schedule.
• Flexible production of bills when repayments are due.
• Ability to overpay / underpay / pay late or early based on issued bills.
• Utilises rules based accounting allowing flexible configuration of entry / balance generation in
T24.
INTERNET SERVICES – ARC Internet Banking
The AI module provides the ability for the bank to provide full internet banking services for individual
clients.
Please see the ARC-IB Administration user guide for more details.
PROXY.SERVICES – ARC Proxy Services
The AP module provides extended internet access to T24 banking services. This product can be
purchased in addition to the INTERNET.SERVICE product and allows organisations to manage their
banking operations through T24.
Please see the ARC-IB Administration user guide for more details.

Property Classes
The AA.PROPERTY.CLASS definitions are released by Temenos and cannot be amended with the
exception of the description fields.
Financial institution can use these “building blocks” of functionality to construct the individual products
which are available for sale to its customers.
The current release of classes are described below in there relevant sections.
ACCOUNT
Overview
The ACCOUNT Property Class is used by all AA products which are account based and will therefore
result in the creation of an associated account record for an arrangement of the product.
This property class manages the descriptive and classification details of the Arrangement and is used
in the creation and maintenance of the account record that is related to the arrangement.
Product Lines
The ACCOUNT property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure


Figure 1 Account Property.

Property Product Relationship

The ACCOUNT product property supports the following arrangement links to the product:
• DATED
• FIXED
All attributes in the Account property are therefore stored at the arrangement level and do not track
the underlying product.
Figure 2 ACCOUNT Property Class record.

Related Balances
The Account property has associated balances that reflect the arrangement principal in the various
stages of the arrangement life-cycle.
The following balances can exist for the property:
Current Principal Balance

For a loan contract the current principal reflects the amount that has been disbursed and is not yet
due to be repaid.
The current principal is identified with a prefix of CUR.
Due Principal Balance

For a loan contract the due principal reflects the amount of the loan that has been disbursed and is
now due for repayment.
The due principal is identified with a prefix of DUE.
Aged Principal Balance

For a loan contract the aged principal balance reflects the due amounts of the loan that has aged
according to the stages defined in OVERDUE property.
DUE balances are aged when the date since the bill that generated the due balance passes the
number of days specified in the OVERDUE property. The billed balance assumes the associated
status defined in the OVERDUE property. For a single arrangement there may be several aged and
due balances reflecting the different age of the outstanding bills.
The aged principal balance is identified with a prefix of the associated status in the OVERDUE
property.
Unallocated Credit Balance

The unallocated credit balance reflects general credits made to the arrangement. This balance is also
used to hold payments made against future or issued bills in advance of the due date. If the practice
(defined in PAYMENT.RULES property) requires that advanced payments do not repay current
principal then the repayment amount is allocated to the unallocated credit balance.
The unallocated credit balance is identified with a prefix of UNC.
Unallocated Debit Balance

The unallocated debit balance reflects general debits made to the arrangement.
The unallocated debit balance is identified with a prefix of UND.

Property Attribute Description and Use

Account Definition at Product Level
Reporting Classification
In an AA Product, the CATEGORY is used for reporting (i.e. balance sheet) purposes only. Usually a
category will be allocated to a specific product or family of products, although this is not mandatory.
Generic Arrangement Titles and Names

Although account names are typically account specific, generic titles can be defaulted from the
product in field ACCOUNT.TITLE and can be replaced or given additional detail at the arrangement
level. It is possible to enter up to two lines of up to 35 characters.
Field SHORT.TITLE is typically an abbreviation of the account title and is used throughout T24 as
enrichment.
Currency Market and Position Type

The CURRENCY.MARKET of an Arrangement can currently only be set to 1 and POSITION.TYPE
can be set only to TR.
Account Definition at Arrangement Level

Currency
The CURRENCY of the arrangement is set from the New Arrangement Activity and stored on this field,
and cannot be modified.
Arrangement Reporting Classification

The CATEGORY can be amended if required at the arrangement level.
Arrangement Titles and Names

ACCOUNT.TITLE and SHORT.TITLE is defaulted from the product definition and can be overridden
if allowed by the product attribute control settings. CUSTOMER.REFERENCE allows a reference know
by the customer of the arrangement to be specified for information.

Alternate References
The following options are available for specifying alternate access references for the account:
• Field MNEMONIC is an alternate key which can be defined by a user to reference the account.
Typically this would be a memorable name for the arrangement.
Field ALTERNATE.ID is a multi-valued field in ACCOUNT.PARMETER which is linked to the

ALT.ACCT.PARAMETER file where alternative references can be specified.
Typically this is used to record other references that the arrangement may also be referred to by; for
example the previous reference of the contract in a legacy system, or the national account standard
account number (e.g. the BGC account number in the Netherlands) or the international account
number (e.g. the IBAN reference).
The ALT.ACCT.PARAMETER file controls and validates the alternate id reference which are stored in
the field ALT.ACC.ID on the ACCOUNT record.
For a more detailed explanation of this set-up please see the ACCOUNTS user guide.
Posting Restrictions
At the arrangement level, a posting restriction code (defined in POSTING.RESTRICT) can be used to
restrict the following:
• All Debits
• All Credits
• All Transactions
An override will be required to accept any entry which meets the conditions of a Posting Restriction
Property Details
Creation of T24 Account
When a financial arrangement is created the system will generate a T24 account record. The account
record generated will be allocated a standard T24 account number according to the rules defined in
the COMPANY application.
Note: In order for the arrangement module to be able to generate an account record the ACCOUNT
application must be configured to generate ids automatically.
The Account record is built by mapping the relevant fields from the DEPT.ACCT.OFFICER,
CUSTOMER, ACCOUNT and LIMIT properties of the arrangement into the layout of the account
record (for technical details of this process see: xxx).
The ACCOUNT record created cannot be modified directly using the ACCOUNT application,
instead the associated properties must be modified using the appropriate maintenance activities from
AA.ARRANGEMENT.ACTIVITY.

The ACCOUNT record holds the arrangement number in the ARRANGEMENT.ID field.
Arrangement account records behave slightly differently to standard T24 accounts:
• There is no CONDITION.GROUP allocated

• The interest and charges module does not apply to these accounts.
Figure 3 ACCOUNT record with ARRANGEMENT.ID stored.
This account number linked to the arrangement is stored in the AA.ARRANGEMENT record.

Figure 4 AA.ARRANGEMENT showing ACCOUNT number.
Using the Arrangement Account in Other T24 Applications

In order to pay funds into or withdraw funds from an arrangement any existing T24 application that
allows an Account to be defined can be used, for example FUNDS.TRANSFER or TELLER.
In the application the user can specify the account number itself, the mnemonic, any alternate
account id linked or the arrangement number when the arrangement is in the same company as the
transaction. If the arrangement account is to be used in an application in a different financial company
to the arrangement then the actual account number is the only option allowed.

Note: In order to be able to specify the arrangement number or an Alternate Account Number the field
ALTERNATE.ACC.IDS must be set to Y in ACCOUNT.PARAMETER.
Figure 5 ACCOUNT.PARAMETER with ALTERNATE.ACC.IDS set.
The FUNDS.TRANSFER application can be used to draw down and commit to an amount of the
arrangement. The DEBIT.ACCT.NO field is used to debit the ACCOUNT record associated to the
AA.ARRANGEMENT.
Figure 6 FUNDS.TRANSFER used to draw down a committed amount.

Action Synopsis
The account property supports the following actions:
CREDIT
The credit action applies the unallocated amount from a credit to the arrangement to the unallocated
credit balance of the arrangement.
DEBIT
The debit action applies the unallocated amount from a debit to the arrangement to the unallocated
debit balance of the arrangement.
DISBURSE
The disburse action is used when a loan is disbursed. The action will result in the current balance of
the account property being debited.
MAINTAIN
The maintain action is used whenever one of the properties linked to the T24 ACCOUNT record
(CUSTOMER, DEPT.ACCT.OFFICER, LIMIT, ACCOUNT) is modified. The action does not
generate any accounting movement but updates the related T24 ACCOUNT record to reflect the
values for the arrangement property.
It is this ACTION that will result in the creation of a T24 arrangement account when the NEW-
ARRANGEMENT activity is processed.
MAKE.DUE
The make due action will apply the amount of principal due to be repaid to the DUE account property
balance and will reduce the CURrent account property by the amount to be made due.
The amount to be made due is determined from the associated BILL that is being made due.
REPAY
The repay action will allocate an amount of principal to be repaid to the appropriate account balance.
Depending on the PAYMENT.RULE applied the repayment will be made against billed or current
amounts.
Processing determines the amount and balance to be credited based on the PAYMENT.RULE
definition and can result in credit being applied to the CUR, DUE or AGEd balances of the account
property.
UPDATE
The update action is used to apply the changes to the ACCOUNT property attributes and does not
result in any accounting updates.

Accounting Events
The following actions generate accounting events as defined in field ACCOUNTING.
• CREDIT
• DEBIT
• DISBURSE
• MAKEDUE
• REPAY
• CAPTURE.BILL
• ADJUST.BILL
Limits Interaction
The ACCOUNT property does not directly interact with the LIMITS system in T24 but the associated
arrangement ACCOUNT record is closely linked.
The LIMIT Property condition specifies the LIMIT.REFERENCE to be used for the arrangement
product and this is the limit reference used in the related ACCOUNT record.
Delivery
No special processing for the ACCOUNT class in delivery

ACCOUNTING
Overview
The AA module utilises T24 rules based accounting to generate it’s accounting movements.
The ACCOUNTING Property Class is used by all financial products and controls the link between the
accounting events generated by the property actions and the accounting allocation rules to be applied
to these events.
The property also controls the link between the activity to be performed on an arrangement when a
transaction is processed from another application that uses the related T24 ACCOUNT record.
Users can specify accounting rules for each Property which has Actions that require accounting.
Product Lines
The ACCOUNTING property is used by the following product lines:
LENDING
DEPOSITS
ACCOUNTS
Structure

Figure 7 Accounting Property.


The ACCOUNTING product property supports the following arrangement links to the product:
• DATED
• MERGE
• TRACKING.ONLY
The property cannot be defined at arrangement level.

The ACCOUNTING property is mandatory for all financial product lines.
Figure 8 ACCOUNTING Property Class record.
Related Balances
The accounting property does not have any financial balances associated with the property.

Summary of Rules Based Accounting

The AA module uses rules based accounting to manage it’s accounting movement generation. An
overview of the mechanism and relationships with properties is described here, more detail can be
found in the Accounting Guide.
Actions and Accounting Events

Actions performed by properties on an arrangement can result in the movement of one or more
balances associated with that property. When a balance movement is required the action will
generate an accounting event.
The accounting event contains basic details of the change to the balance such as:
• Affected Balance
• Movement Amount
• Movement Sign
• Event (or Value) Date
• Arrangement Id
• Initiating Transaction Reference
In AA processing each event is always targeted to an arrangement balance (which must be defined in
the AC.BALANCE.TYPE table).
Allocation Rules
Each event raised by the action is the basis for generation of actual accounting entries. In T24 three
types of accounting entries can be generated from a single accounting event, these are:
STMT.ENTRY – a movement to a T24 account optionally with a specific balance type. Accounts can
be customer, internal or Nostro accounts.
CATEG.ENTRY – a profit and loss movement with a specific profit and loss category.
RE.CONSOL.SPEC.ENTRY – a movement to the arrangement contract with a specific balance type.
Each entry generated has a TRANSACTION code that is used to identify the type of movement
generated.
An allocation rule is used to specify the types of entry and target account, balance type or profit and
loss category that the event should generate. It also specifies how the details of the entry record are
to be built including the transaction code to be used.
Allocation rules are defined in the table AC.ALLOCATION.RULE.

Entry Details
Each accounting entry contains a number of detailed fields. This contains information used by system
in financial reporting and also in production of customer statements and other enquiries.
Certain details in the entries generated as a result of the application rules can be configured, for
example:
• System Id
• Customer Narrative
• Customer References
• Internal References
The source and value of these details is specified in the table AC.POSTING.DETAIL which in turn
is linked to the AC.ALLOCATION.RULE table.
Link Between Property Accounting Events and Allocation Rules

The ACCOUNTING property is used to define the link between an ACTION for a product and the
AC.ALLOCATION.RULE to be applied to the events generated by an action.
The property therefore allows the format, target and detail of accounting movements to be configured
according to the product.

Linking an Action to an Allocation Rule
As described each action can generate a number of accounting events.
For each Property the allocation rule to be applied with each ACTION should be specified using the
sub-valued fields ACCT.ACTION and ACCT.RULE.
Linking non-AA Transactions to Property Activities

The method of paying in and out of an arrangement is to debit or credit the related T24 ACCOUNT
through any T24 application that allows specification of an account number.
Typical methods of disbursement of a loan arrangement could be a debit through the
FUNDS.TRANSFER application, a debit made through the TELLER application or through an ATM.
A typical repayment method could be a credit through the FUNDS.TRANSFER or TELLER
applications. Payment could be generated as a manual transaction or as a scheduled activity (e.g. a
standing order or cash pool sweep).
When a movement is posted to the related T24 ACCOUNT the system determines the activity to
perform against the arrangement based on the TRANSACTION code of the accounting movement.
The accounting property allows a TRANSACTION code to be linked to a specific AA.ACTIVITY.
For example the TRANSACTION code 408 being posted across an Arrangement should result in the
AA.ACTIVITY LENDING-DISBURSE-ARRANGEMENT being generated.

Default debit and credit activities can be defined and will be used when a specific TRANSACTION
code in an accounting entry is not found in the accounting property.
Only a limited list of activities can be specified for the DEFAULT.CR.ACTIVITY,

DEFAULT.DR.ACTIVITY and TXN.ACTIVITY. These are indicated by the TYPE in the
AA.ACTIVITY.CLASS, that underlies the AA.ACTIVITY record.
In order to be able to specify the ACTIVITY the following TYPE definition must be present in
AA.ACTIVITY.CLASS:
• TXN.ACTIVITY – DEBIT or CREDIT

• DEFAULT.DR.ACTIVITY – DEBIT
• DEFAULT.CR.ACTIVITY – CREDIT
Disbursal of an Arrangement Loan

Funds are disbursed for an arrangement using existing T24 applications as described earlier in this
section. A Disbursal for a loan is a debit to the arrangement account and should be mapped using the
TRANSACTION code and TXN.ACTIVITY or the DEFAULT.DR.ACTIVITY.
Repayment of an Arrangement Loan

Funds are repaid for an arrangement using existing T24 applications as described earlier in this
section. A repayment for a loan is a credit to the arrangement account and should be mapped using
the TRANSACTION code and TX.ACTIVITY or the DEFAULT.CR.ACTIVITY.
Re-use of the Same Accounting Property Condition

It is likely that the same accounting property conditions will be shared between multiple products
which may not be in the same product group. The PROPERTY field can contain properties that may not
be used in a product, using this facility a single record could be defined that can be used by all
products.
Alternatively a number of accounting conditions can be defined and the publishing process will merge
the content of the parent product condition with the record to be published.
Property Details
Publishing - Merging property conditions
With standard business property classes (e.g. INTEREST), a Defined Property defined for a ‘Child
Product’ will override a Defined Property specified for a ‘Parent Product’. The ACCOUNTING property
will allow merging of conditions between the child and parent product at the time of publishing.
When published, the ACCOUNTING Property Class is merged with the published parent definition as
follows:

• The Parent Record is taken as the base record.

• Property definitions in the child record will override the parent record definition if already defined.
• Child property definitions that do not appear in the parent record will be added to the base record.
Publishing Validation and Errors

At publishing time the system will apply the following specific validation to the accounting property to
be published:
• All properties and associated actions that result in the generation of accounting events must be
specified in the property definition
Periodic Attributes
There are no periodic attributes available for use with the ACCOUNTING property.
Action Synopsis
The Interest property supports the following actions:
UPDATE
The UPDATE action is initiated manually and allows the User to change any of the ACCOUNTING
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-ACCOUNTING
activities and will amend the accounting rules.
Accounting Events
There are no accounting events generated by the actions of the ACCOUNTING property.
Limits Interaction
The ACCOUNTING property does not perform any actions that impact on the limits system.
Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated.

ACTIVITY.API
Overview
The ACTIVITY API Property Class allows users to extend the core processing of the Arrangement
Activities. In most respects it replaces the concept of adding user defined routines to Versions. User
defined processing is now specified by Product and benefits from Product Inheritance. Additionally, as
each Arrangement Activity is comprised of one or more Actions, this API methodology provides a high
degree of flexibility as user defined routines can be executed throughout an activity.
Product Lines
The ACTIVITY.API property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
• INTERNET.SERVICES
Structure
Figure 9 ACTIVITY.API Property.


The ACTIVITY.API product property supports the following arrangement links to the product:
• DATED
• TRACKING
• MERGE
Figure 10 AA.PROPERTY.CLASS record.
Defining the ACTIVITY.API at Product Level

A single Action can be used within multiple Activities. A User must specify the activity context within
which a routine is to be executed. Either an ACTIVITY.CLASS or ACTIVITY.ID must be entered
along with either the PROPERTY.CLASS or the PROPERTY.
The ACTION is a mandatory field. Within the Activity Class or Activity the user must specify an Action
and one or more pre- and/or post-routines. These routines must be defined in EB.API.
Processing API Routines

During the processing of an Arrangement Activity, T24 determines whether any API routines should
be executed prior to or after any of the Actions. As ACTIVITY API is a cumulative Property Class, the
system will process all of the routines specified using the following order of precedence:

• Pre routines followed by Post Routines

• Highest to Lowest by Product Level (e.g. Grand Parent routines, Parent routines, Child routines).
• Activity Class followed by Activity routines within each level.
Action Synopsis
UPDATE
The UPDATE action is initiated manually and allows the User to change any of the ACTIVITY.API
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-ACTIVITY.API
activities and will result in modification of the API rules.
Accounting
The ACTIVITY.API property does not perform any actions that generate accounting events.
Limits
The ACTIVITY.API property does not perform any actions that impact on the limits system.
Delivery

ACTIVITY.CHARGES
Overview
The ACTIVITY.CHARGES Property Class is used by any products which require charging for various
Arrangement Activities.
Product Lines
The ACTIVITY.CHARGES property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure

Figure 11 ACTIVITY.CHARGES Property.

The ACTIVITY.CHARGES product property supports the following arrangement links to the product:
• DATED
• TRACKING

Figure 12 ACTIVITY.CHARGE Property Class record.
Defining the ACTIVITY.CHARGES at Product Level

ACTIVITY.CHARGES enables the linking of CHARGE Properties (which must exist on the Product) to
specific Activities. When the Activity defined in ACTIVITY.ID is processed, any charge amount
which has been specified in the field CHARGE will be billed immediately and made due according to
the period specified in the DUE field.
Scheduled Charges
It is possible to define that all charges be paid on a scheduled basis – i.e. on a monthly or quarterly
basis. This is scheduled in the PAYMENT.SCHEDULE property, but the User must define which
charges will apply to which activities. These are defined in the two fields SCHED.CHARGE and
CHG.ACTIVITY on the condition record.

Action Synopsis
UPDATE
The update action is initiated manually and allows the User to change any of the ACTIVITY.CHARGES
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-
ACTIVITY.CHARGES activities and will result in the modification of activity based charge rules.
CALCULATE
Accounting
The ACTIVITY.CHARGES property does not perform any actions that generate accounting events.
Limits
The ACTIVITY.CHARGES property does not perform any actions that impact on the limits system.
Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. The
ACTIVITY.CHARGES property class generates delivery information as defined in field
DEL.INFO.REQD.
Figure 13 ACTIVITY.CHARGES with DEL.INFO.REQD defined.

ACTIVITY.MESSAGING
Overview
The ACTIVITY MESSAGING Property Class is used to link the production of T24 delivery events with
any activity that can be performed on an arrangement contract.
The T24 delivery system is a rules based system that allows creation of messages that can be sent
through any supported carrier medium (Printed, Fax, SWIFT, Email etc). Activities performed by
applications (in this case AA.ARRANGEMENT.ACTIVITY) can generate one or more message
types according to the configured rules.
The delivery system allows messages to be routed and formatted according to the type of message,
and also allows the option to create a deal slip.
The interface to the T24 delivery system allows the application to generate a delivery event. The
delivery event associates an activity identification code (ACTIVITY.CODE) with unformatted related
application data; a message reference allocated by the T24 delivery system is returned.
Product Lines
The ACTIVITY.MESSAGING property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
• PROXY.SERVICES
The ACTIVITY.MESSAGING property is OPTIONAL for all product lines.
Structure

Figure 14 ACTIVITY.MESSAGING.


The ACTIVITY.MESSAGING product property supports the following arrangement links to the product:
• DATED
• TRACKING
• MERGE
The property cannot be defined at arrangement level and rules are always assigned from the product
definition.
Figure 15 ACCTIVITY.MESSAGING Property Class record.
Related Balances
The ACTIVITY.MESSAGING property has no related balances.

Summary of Rules Based Delivery

The following section gives an overview of the T24 delivery system configuration, for full details
please refer to the T24 delivery user guide.
Delivery Message Types

Basic message types are identified in the DE.MESSAGE application. A numeric message identifier
is used to identify the type of message to be produced. For each message to be produced a number
of possible data fields are defined that together make up the content of the message.
A single message type may be generated by many different applications.
Delivery Mapping
The DE.MAPPING application allows the raw delivery handoff data generated from the application
delivery event to be mapped to the field content defined in the DE.MESSAGE table. For each
different application (and possibly sub-division within application) the map between the handoff data
and required data layout must be defined.
Delivery Formatted Output

A formatting application will exist for some formatted output to allow the final layout of the message
based on field definition, position and conversion options. Examples include DE.FORMAT.PRINT
and DE.FORMAT.SWIFT.
Soft Delivery
Rules based (or soft) delivery allows one or more delivery message types to be generated from a
single delivery event.
The application generates the delivery event with an identifying code the ADVICES code together with
a collection of unformatted data from the underlying application – referred to as the delivery handoff
data.
The application EB.ADVICES is used to define the type, formatting and additional content of the
delivery messages to be generated. The key to the EB.ADVICES table is the advice code allocated
by the application. In the case of AA the advice code is allocated according to the
ACTIVITY.MESSAGING property.
EB.ADVICES allows definition of:
• Message type – DE.MESSAGE to be generated.

• Mapping record DE.MAPPING to be used to map the data from the application to the message
format.

• A specific printed format code to be used in the key to DE.FORMAT.PRINT for printed advices.
• Whether a Deal Slip should be produced in addition or instead of a delivery advice.
• An API to allow additional information to be created and include in the delivery handoff.
Application Handoff Format

The application will generate a delivery event including the following information:
• Advices code.
• Advice identifier code.
• Activity details.
• Send Message Indicator.
• Data Handoff Details – 9 fixed handoff records can be created and an unlimited number of named
handoff records can be created.
Named Handoff Records

In order to manage the flexible structure of the AA module the ability to create named data handoff
records has been added. In order to use this facility the application must provide a list of named
records in one of the fixed data handoff records.
The data records associated with the named list area also handed off by the application.
The fixed record containing the list of names must be specified in the DE.MAPPING record field
RECORD.NAME.LOC.
The INPUT.REC.NO field in DE.MAPPING should be configured with the handoff record name and
the associated INPUT.FILE should be specified.
Definition of Output Carrier

The message carrier type to be used for the message production is defined in the table
DE.PRODUCT. This allows the DE.CARRIER (e.g. PRINT, SWIFT, EMAIL etc) to be allocated to
specified message types and optionally by customer and linked account.
The ENQUIRY DE.MSG.LINK can be used to show the messages that have been produced by an
arrangement

Figure 16 Example of Messages for an Arrangement.
Configuring T24 Delivery for an AA Product

Content of Delivery Handoff
Any delivery event created from the AA application will generate the following delivery handoff data:
Handoff Record / Name Field Description
Number
1 AA.ARRANGEMENT record
2 AA.ARRANGEMENT.ACTIVITY record contains the
details of the activity request
3 AA.ACCOUNT.DETAILS – for financial arrangements
this contains a summary of the status and number of
outstanding bills
4 Hard coded details required for creation of the
delivery header and other mandatory message
information.
4 1 COMPANY of the arrangement
4 2 Currency of the arrangement
4 3 Account Officer / Department code of the
arrangement
4 4 AA Arrangement Activity Id
4 6 The customer of the arrangement
4 7 The CUSTOMER.COMPANY of the company of the
arrangement
4 8 The language of the customer
5 The CUSTOMER record for the customer of the

arrangement
6 The ACCOUNT record linked to the arrangement
7 List of property names handed off. This will contain
all properties apart from those where the
PROPERTY.CLASS definition denotes that the
property details should not be included.
Details are in the format <x> = Property
propertyName The content of each property record for the
arrangement activity effective date is included in the
handoff under the propertyName.
The order of the properties is defined in record 7
Note: you can view the content of the delivery handoff using the standard delivery ENQUIRY
DE.HANDOFF.DETS.
Excluding Certain Properties from the Handoff

Certain properties are unlikely to be required in the content of delivery messages produced from AA,
for example the system management property classes such as ACCOUNTING, ACTIVITY.API and
ACTIVITY.MESSAGING.
The field DEL.INFO.REQD on AA.PROPERTY.CLASS is used to indicate that any property of this
class should be included in the delivery handoff. A value of Y indicates that the property class should
be included.
Figure 17 Field Del.Info.Reqd in AA.PROPERTY.CLASS.
Currently this field is delivered pre-configured by Temenos and cannot be amended.

Creating Message Types for AA

New messages (or existing messages can be amended) can be created for the arrangement activity
application. The message type is defined in the application DE.MESSAGE and has a numeric
message number between 1 and 9999.
When the message is created the data elements that the message is to be comprised of should be
defined. For further details of DE.MESSAGE application please refer to the Delivery User Guide.
Creating Mapping Definitions for the AA Application

Having defined the message the next step is to define the mapping between the handoff data and the
message content. This is defined in the DE.MAPPING table.
The key to this table is comprised of:
• Message Type (the key to DE.MESSAGE).

• Application Identifier (AA should be used in this case).
• Application sub type identifier.
It is recommended that a different Application Identifier should be chosen for each product line (and
possibly different product groups under the same product line) as this will allow multiple products to
produce the same message type from different content.
For an AA mapping definition the following should be defined:

Link between named handoff records and underlying applications - In the following example we can
see that:
• INPUT.REC.7 MEMBER is the named CUSTOMER property class.

• INPUT.REC.8 COMMITMENT is the named TERM.AMOUNT property class.

Figure 18 Example of Handoff Record Definitions.
The handoff record number that contains the name of the product properties must also be defined in
the field RECORD.NAME.LOC. For the AA module record 7 will always contain the property definition.

Figure 19 Defining the Location of the Named Handoff Records.
The mapping between the message fields and the delivery handoff records can then be defined using
fields INPUT.POSITION, INPUT.NAME and HEADER.NAME.
Where data is to be mapped from a property the INPUT.POSITION should contain the name of the
property, and INPUT.NAME should contain the field name from the property.
Data contained in the fixed data handoff records should be mapped by specifying either:
• INPUT.POSITION as the record number with INPUT.NAME as the required field name.
• INPUT.POSITION only in the format record field.

As shown in the following example.
Figure 20 Mapping Handoff Data to Message Fields.

Linking Soft Delivery to Activities – Property Attributes and Use

Delivery events generated from AA module must contain an EB.ADVICES code. The
ACTIVITY.MESSAGING property allows either an AA.ACTIVITY, or AA.ACTIVITY.CLASS to be
linked to an EB.ADVICES code.
In order to generate a delivery event for an ADVICE code that has already been defined in
EB.ADVICES must be defined. Associated with this code must be either:
• The AA.ACTIVITY name that should trigger the production of the event or
• The AA.ACTIVITY.CLASS name that should the production of the event for any AA.ACTIVITY
of this AA.ACTIVITY.CLASS.
Figure 21 Example of Specific AA.ACTIVITY link in ACTIVITY MESSAGING.
Defining EB.ADVICES for the selected ADVICE

The EB.ADVICES table provides the link between the ADVICE code allocated and the message
types to be produced.
As show above the EB.ADVICE record AC-0190 will be used if triggered by either the
AA.ACTIVITY or AA.ACTIVITY.CLASS action.
The MESASGE.TYPE specified should be the message type that is to be associated with this activity
(multiple message types can be linked if required).
Then MAPPING.KEY should be the id of the DE.MAPPING record built for the product and
Message.

Figure 22 - EB ADVICES definition.
Adding Additional Content to the Handoff Data

Additional handoff data can be added to the delivery event, this is controlled by the definition in the
EB.ADVICES table for the ADVICE code. The field USER.ROUTINE allows an API to be written that
can modify/add additional data to one or more of the handoff data records.
See the Delivery user guide for full details.
Property Details
Publishing - Merging property conditions
With standard business property classes (e.g. Interest), a Defined Property defined for a ‘Child
Product’ will override a Defined Property specified for a ‘Parent Product’. When published, the
ACTIVITY MESSAGING Property Class is merged in a mutually exclusive manner.
This allows for the parent property condition to contain the master definition and only those specific
activities that are required to produce alternative messages need be defined at the child level. A
definition of ADVICE.CODE at the child level will override any definition found at the parent level when
the publishing process takes place.

Link between Arrangement Activity and Delivery

The delivery system will allocate a unique message identifier for each message that is generated as a
result of the delivery event. This is stored in the AA.ARRANGEMENT.ACTIVITY record field
DELIVERY.REF.
Figure 23 Delivery Reference.
Delivery Preview
Currently the AA module does not support the ability to PREVIEW the delivery output to be
generated.
Periodic Attributes
There are no periodic attribute classes associated with the ACTIVITY.MESSAGING property.

Action Synopsis
UPDATE
The UPDATE action is initiated by the product tracking service. When a product definition is modified
that includes a change to the AA.PRD.DES.ACTIVITY.MESSAGING conditions this action will be
run to ensure that arrangements of that product type are updated with the new conditions.
The action will also be initiated by the NEW-ARRANGEMENT and UPDATE-ACTIVITY.MESSAGING
activities.
SEND.MESSAGE
The SEND.MESSAGE action is initiated by all activities performed on an arrangement where the
arrangement product has an ACTIVITY.MESSAGING property.
The action processing will perform the following process:
• Determine if the current specific activity or general activity class is required to produce a delivery
event
• If a delivery event is required look up the ADVICE.CODE(s) to be used by rules based delivery.
• A handoff request will be generated for the specified advice code together with all related property
details for the effective date of the activity.
• The delivery reference from the delivery system is stored in the
AA.ARRANGEMENT.ACTIVITY record.
Note that the SEND.MESSAGE action will only generate a delivery event on the authorisation of a
new AA.ARRANGEMENT.ACTIVITY. At reversal no delivery event is generated.
Accounting Events
Since there are no related financial balances with this property class there are no associated
accounting events generated by properties of this class.
Limits Interaction
There is no interaction between the T24 Limits system and properties of this class.
Delivery
This property controls the interaction with the T24 delivery system, details of handoff records and
required configuration are described in the previous sections.

ACTIVITY.PRESENTATION
Overview
The ACTIVITY PRESENTATION Property Class is used to specify the T24 Versions (hereafter referred
to as ‘screens’) that will be used when displaying an AA.ARRANGEMENT.ACTIVITY. By
specifying screens at the Product level, the display of each arrangement activity is controlled
dynamically. Upon entering the Product and Activity, T24 will determine which properties should be
displayed and which screens should be used.
Product Lines
The ACTIVITY.PRESENTATION property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure
Figure 24 Activity Presentation.

Product Property Relationship

The ACTIVITY.PRESENTATION product property supports the following arrangement links to the
product:
• DATED
• TRACKING
• MERGE
Figure 25 ACTIVITY.PRESENTATION Property Class record.
Merging property conditions

With standard business property classes (e.g. Interest), a Defined Property defined for a ‘Child
Product’ will override a Defined Property specified for a ‘Parent Product’. When published, the
ACTIVITY.PRESENTATION Property Class is merged in a mutually exclusive manner. This allows for
each screen to be individually overridden at any level in a product family.
Defining the ACTIVITY.PRESENTATION at Product Level

Within a product, screens displayed for an Arrangement Activity can be specified at three different
levels; Property Class, Property, and Property within the context of an Activity.

• Property Class Screens

Users can specify a default Version for each PROPERTY.CLASS (e.g. INTEREST). If a more specific
Version is specified for a PROPERTY or an ACT.PROPERTY, this Version will be ignored.
• Property Screens
Users can specify a Version at the PROPERTY level (e.g. Principal Interest). This will override the
default of the Property Class.
• Activity Property Screens

The lowest level of Version specification allows a user to define a version for use at the Property level
(ACT.PROPERTY) within an Activity (ACTIVITY.ID).
Action Synopsis
UPDATE
The update action is initiated manually and allows the User to change any of the
ACTIVITY.PRESENTATION attributes. This action will be initiated as part of the NEW-ARRANGEMENT
and UPDATE- ACTIVITY.PRESENTATION activities and will result in the modification of the versions
and screens rules.
Accounting
The ACTIVITY.PRESENTATION property does not perform any actions that generate accounting
events.
Limits
The ACTIVITY.PRESENTATION property does not perform any actions that impact on the limits system.
Delivery

CHANGE.PRODUCT
Overview
The CHANGE.PRODUCT property class defines the rules and behaviour for allowing arrangements of
one product to be changed to another.
The CHANGE.PRODUCT property can be included in a product if arrangements are allowed to be
changed to another product during its lifetime. The property class allows the definition of restricted
products that change can be made to and when a scheduled change should be applied.
Product Lines
The CHANGE.PRODUCT property is used by the following product lines:
• LENDING
Structure
Figure 26 Change Product.


The change product property supports the following arrangement links to the product:
• DATED
• TRACKING
Figure 27 CHANGE.PRODUCT Property Class record.
Available Products for Change

The property allows the list of available products that an arrangement may change into to be specified.
The ALLOWED.PRODUCT field will contain a list of such products and the products must belong to the
same product group as the current product.
When the product is proofed it will verify that the allowed products belong to the same
AA.PRODUCT.GROUP as the product being published, if not a proofing error is generated and
must be corrected before the product can be published.

Figure 28 Allowed Products.
Defining a Product with a Scheduled Product Change

A product can be created where the arrangement changes to take the conditions of a new product
after a specified period from the start of the arrangement.
The property should be configured so that the product to change to is specified in the
CHG.TO.PRODUCT field together with the CHANGE.PERIOD which should be specified as the period
from the start of the arrangement when the change of product will take place. The CHANGE.PERIOD
is defined as a standard period definition allowing number of days, weeks, months or years to be
defined.

Figure 29 Scheduled Product Change
Arrangement Level Product Change

At arrangement level a specific date can be specified for the product to change to the
CHG.TO.PRODUCT in the field CHANGE.DATE.
The scheduled product change can be overridden (subject to property link and negotiation conditions)
at arrangement level so that no product change takes place. The CHG.TO.PRODUCT definition should
be removed to achieve this.
An ad-hoc change of product or alternative change product schedule can be defined at the
arrangement level by setting specific arrangement conditions in CHG.TO.PRODUCT, CHANGE.DATE
and CHANGE.PERIOD.
Generation of New Product Conditions in Advance

The system can process the activity to change the arrangement product a number of days in advance
of the actual change date. This can be done allow sufficient time for communication of new conditions
to the client prior to the start of the new product.
The system will generate all the new conditions according to the PRIOR.DAYS definition associated
with the CHG.TO.PRODUCT. On the change date less the number of prior days the new product
change conditions will be generated with an effective date equal to the CHANGE.DATE (or date
calculated as arrangement start date plus CHANGE.PERIOD).

Periodic Restrictions
There are no periodic restrictions available for the CHANGE.PRODUCT property class.
Action Synopsis
UPDATE
The update action allows modification and creation of a new CHANGE.PRODUCT property for an
arrangement. It will be performed as part of the NEW-ARRANGEMENT and UPDATE-
CHANGE.PRODUCT activities.
Accounting
The CHANGE.PRODUCT property does not perform any actions that generate accounting events.
Limits
The CHANGE.PRODUCT property does not perform any actions that impact the limits system.
Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. There
are no standard delivery conditions provided for the change product activities.

CHARGE
Overview
The CHARGE Property Class is used for all charge type calculations in AA. Its primary purpose is to
calculate the amount of a charge.
Product Lines
The CHANGE property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure

Figure 30 Charge Property.


The change product property supports the following arrangement links to the product:
• OPT.CCY
• DATED
• MULTIPLE
• TRACKING
Figure 31 CHARGE Property Class record.

Figure 32 CHARGE Property Class cont.
Multiple instances of a property class

It is possible to have more than one instance of a CHARGE property class. This is defined in TYPE in
type being MULTIPLE.
Currency
The CHARGE Property Class differs from other Currency Specific classes in that it includes a
CURRENCY field. This field defaults to the currency of the record and specifies in which currency the
charge is defined and which currency the charge will be applied.
Specifying the currency in a separate field allows for the following capabilities:
• Charging in a currency different from that of the Arrangement (i.e. with charges defined in a
currency which is different than the record’s currency) For example the product charges may be
defined in USD for arrangements in all currencies, but a different set of charge tariffs may be
defined for contracts in different currencies but also in USD. So a GBP contract may attract a
charge of 10 USD and a EUR contract may attract a charge of 20 USD.
• Default Currency charging – In this case a currency need not be specified in the ID of the record
and the user will have to set the Currency field explicitly. Any arrangement which is in a currency
for which a currency specific record has not been defined will use this default record and
calculate/apply the charge in the currency specified in the CURRENCY field.
The calculated charge should be converted to the arrangement currency at the prevailing mid-rate
(stored on the CURRENCY table) when applied.
Fixed Amount Charge

To define a fixed charge amount, the user sets the CHARGE.TYPE to “Fixed”, enters the amount of the
charge in AMOUNT.

Calculated Charge
For a Calculated charge amount, the user sets the CHARGE TYPE to “Calculated” and defines the
calculation in the following fields:
Calculation Threshold
A user can specify that a charge will only be calculated if an amount threshold is surpassed. The
threshold amount is of the same base type (i.e. activity amount, balance, activity count) as the base
type for which the charge is being calculated and is defined in CALC.THRESHOLD.
Free Amount
An amount which will be deducted from the total calculated charge subject to any minimum and
maximum which may be specified- defined in FREE.AMOUNT.
Single or Multiple Tiers

Field TIER.GROUPS allows for either a single charge calculation (select NONE) or for the definition of
multiple tiers of charge calculations (select BAND or LEVEL)
• Level - a product can be defined which will calculate a charge differently depending on the
amount level. A single charge calculation will be selected and applied based upon the amount.
An example using the following tiers:
Tier Level Charge

10,000 1%
20,000 .75%
Above 20,000 .5%
A base value of 5,000 would attract a charge of 1% of 5,000 = 50.00

A base value of 15,000 would attract a charge of .75% of 15,000 = 112.50
A base value of 25,000 would attract a charge of .5% of 25,000 = 125.00
• Band - will typically result in a “blended” charge calculation. This is similar to ‘Level’ tiers, but
allows for the charge calculation of each tier to be applied to the portion of the amount that falls
within the tier.
An example using same tiers as above:
Tier Level Charge

10,000 1%
20,000 .75%
Above 20,000 .5%


Plus .75% of 5,000 = 37.5
Total of = 137.5
Plus .75% of 10,000 = 75.00
Plus .5% of 5,000 = 25.00
Total of = 225.00
• Tier Groups (Bands and Levels) – it is possible to define complex tiers which are mixed groups of
Bands and Levels.
Any number of tier groups is possible. The User can define these groups by using a combination of
TIER.GROUP and CALC.TIER.TYPE. Each TIER.GROUP is treated as a ‘high level’ tier, if the
TIER.GROUP is level, only the detail in CALC.TIER.TYPE from the tier group in which the base value
falls will be used in the calculation. If the TIER.GROUP is band, the detail from all tier groups that
cover the base value be used in the calculation.
The value of the tiers defined in TIER.AMOUNT within each tier group should increase, only the final
tier in the final tier group should specify the remainder calculation detail.
For example:
Tier Group 1
Tier Type Tier Level Charge
LEVEL 10,000 1%
LEVEL 20,000 .75%
Tier Group 2
Tier Type Tier Level Charge
BAND 30,000 .25%
BAND 40,000 .20%
BAND Above 40,000 .15%
When the TIER.GROUP structure is LEVEL:

A base value of 15,000 would result in a charge of .75% of 15,000 = 112.50
Plus .20% of 10,000 = 20.00

Plus .15% of 10,000 = 15.00

Total = 110.00
When the Tier Group Structure is BAND:

Plus .25% of 5,000 = 12.50
Total = 162.50
Plus .25% of 10,000 = 25.00
Plus .20% of 10,000 = 20.00
Plus .15% of 10,000 = 15.00
Total = 210.00
Calculation Type and Charge

For each tier defined, T24 supports three different calculation types; Flat, Percentage, or Unit and
these are defined in CALC.TYPE.
• Flat Charge – the user specifies an amount that will be charged for the tier. This type of charge is
only applicable for ‘Level’ tiers.
• Percentage Charge – a percentage of the base value will be calculated.
• Unit Charge – the base value is multiplied by the number of units.
The charge amount entered is expressed either as a flat amount, a percentage, or an amount per unit.
Minimums and Maximums

Charge minimums and maximums can be specified in two ways:
• Tier Level – the user can specify a minimum and/or maximum charge amount for each tier
defined. These rates are defined in TIER.MIN.CHARGE and TIER.MAX.CHARGE.
• Overall – the user can specify overall minimum and/or maximum charges through the user of two
Periodic Attributes.
•
See Product Builder User Guide for details on Periodic Attributes.

Balance Calculation Basis

For charges which are based upon balance amounts, the user must define the calculation basis in
AA.BALANCE.CALC.TYPE which specifies how the balance amount is determined.
Figure 33 AA.BALANCE.CALC.TYPE.
In AA.BALANCE.CALC.TYPE, the User defines whether the balance is based on a debit or credit
balance in DEBIT.CREDIT. A dropdown list in CALCULATION gives options of DAILY, AVERAGE,
HIGHEST, LOWEST or ROUTINE. The User can define the calculation start and end dates in
CALC.START.DATE and CALC.END.DATE respectively. If ROUTINE is selected in
CALCULATION.TYPE, the routine must also be entered into ROUTINE.
Each record is linked to just one PROPERTY.CLASS and once this is defined, it becomes a no change
field.

Figure 34 AA.BALANCE.CALC.TYPE.
Activity Calculation Basis

For charges which are based upon specific activities, the user must define the calculation basis in
AA.ACTIVITY.CALC.TYPE
Rounding of Calculations
T24 will by default round an amount according to the setting of its currency. If the user requires a
different method of rounding that is charge specific they may enter an appropriate rounding rule into
EB.ROUNDING.RULE to override the currency specified method.
Charge Routine
Certain types of charging are more complex than the options available. In such a case, a user-
defined routine can be specified to determine the charge amount.

Charge Period
Charges included in a Payment Schedule can be specified for a period of time and made due from the
customer in multiple payments. For example an annual insurance premium amount which is due
monthly. For such a charge, the user specifies the total period (e.g. 12 months) and when the charge
is added to a Payment Schedule it is divided by the total number of payments within the charge period.
Action Synopsis

CHANGE
The change activity is initiated manually by the user in order to change any of the CHARGE attributes.
As a result a recalculation of the Payment Schedule may be performed.
Other actions are ACT.MAKE.DUE, CALCULATE, ISSUE.BILL, MAKE.DUE, CAPITALISE, REPAY,

RESUME, SUSPEND and UPDATE.
Accounting
• ACT.MAKE.DUE
• MAKE.DUE
• CAPITALISE
• REPAY
• RESUME
• SUSPEND
• CAPTURE.BILL
• ADJUST.BILL
Limits
The CHARGE property does not perform any actions that impact the limits system.
Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. There
are no standard delivery conditions provided for the change product activities.

CUSTOMER
Overview
The CUSTOMER Property Class is used by all products to specify all of the involved parties of an
arrangement and their respective roles.
Product Lines
The CUSTOMER property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure
Figure 35 Customer Property.

The CUSTOMER product property supports the following arrangement links to the product:
• DATED
• FIXED

Figure 36 CUSTOMER Property Class record.
Defining the CUSTOMER at Arrangement Level

The Customer will always be defined at Arrangement level.
Each arrangement can have one or more legal owners defined in OWNER. Additionally, other parties
may be added to an arrangement with a designated role – these will be added in the multi value set of
fields OTHER.PARTY and ROLE.
A third field within this multi value set is NOTES which enables the user to add any notes relating to
the other party. All owners and any other parties must exist on the T24 CUSTOMER file. The options
for field ROLE are specified by the user in the virtual table AA.PARTY.ROLE using EB.LOOKUP.
Figure 37 EB.LOOKUP – Party Roles
If more than one owner is specified on an arrangement, the user must select the primary owner in
field PRIMARY.OWNER. The primary owner is used by T24 for balance sheet accounting and tax
purposes.

Synopsis of Actions
UPDATE
The update action is initiated manually and allows the User to change any of the CUSTOMER
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- CUSTOMER
activities and any modification to the static customer data will result in changes to related data within
other applications (Eg ACCOUNT)
Accounting
The CUSTOMER property does not perform any actions that generate accounting events.
Limits
The CUSTOMER property does not perform any actions that impact on the limits system.
Delivery
CUSTOMER property class generates delivery information as defined in field DEL.INFO.REQD.

INTEREST
Overview
The INTEREST Property Class is used for all interest definition and processing in AA. A T24 product
defined and processed in AA can have multiple interest properties defined (e.g. principal interest,
penalty interest, commission, etc.). The number of interest properties is determined by the users
defining the products.
Product Lines
The INTEREST property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure
Figure 38 Interest Property.


The INTEREST product property supports the following arrangement links to the product:
• DATED
• CCY
• MULTIPLE
• TRACKING
Figure 39 INTEREST Property Class record.

Figure 40 INTEREST Property Class record cont.

It is possible to have more than one instance of an INTEREST property class. This could comprise of
examples such as Loan Interest, Penalty Interest or Overdue Interest.
This is defined in the field TYPE with a value of MULTIPLE as shown above
Defining the INTEREST at Product Level

Most INTEREST conditions will be set at Product level, but there will be the option to negotiate all of
some of the fields within the INTEREST property at Arrangement level if this is required.
Three basic types of interest are supported by T24 Fixed, Floating, and Periodic. Each of these
interest types can include one or more margins and can be specified in a tiered structure
Fixed Rate Interest

Fixed Rate - A fixed rate is directly entered by the user into field FIXED.RATE. This rate must be
entered as positive numbers unless a negative rate is allowed.
Floating Rate Interest

Floating Rate- A floating interest rate is tied to a variable base rate (i.e. BASIC.INTEREST) and is
entered in field FLOATING.INDEX. During interest calculations, T24 will use the currency specific rate
applicable for the calculation date (i.e. the rate used for the calculation will change whenever the base
rate is changed).

Periodic Rate Interest

Periodic Rate - A periodic rate is tied to an index (e.g. LIBOR) which is dependent on a period of time
(e.g. term) and possibly an amount. The periodic interest index is entered into field PERIODIC.INDEX.
Once the arrangement is active, the rate is fixed until it is reset. Periodic rates can be reset at a pre-
determined frequency. To define a periodic rate, the user specifies:
• PERIODIC.INDEX -This would be input as the 2 digit number at the beginning of the
PERIODIC.INTEREST Id, eg 01 may indicate that the LIBOR rate should be used.
• PERIODIC.PERIOD (this will default to TERM if a Term Amount Property exists).
• PERIODIC.METHOD -Interest selection method if the term is not found on the index. The options
are:
o Interpolate Rate
• PERIODIC.RESET – A Reset period can be selected using the pop up box at the end of the field.
Negative Interest Rates

It is possible to set negative interest rates on accounts in credit. This is achieved by setting the
NEGATIVE.RATE field to YES.
If this field is set as either NO or left unpopulated, then when interest rates fall below 0, zero interest
will be accrued. Negative interest rates may occur either as a result of a negative rate being specified
or as the result of the rate minus any margin which is specified.
Margins
A margin rate can be used to adjust the specified rate of interest and to appropriately reflect any rate
profit realized. The result is the nominal rate of interest which is stored in field NOMINAL.RATE.
T24 allows for the following margin configuration:
Single or Multiple Margins – the fields for margin are a multi value set for multiple margin types. The
types available are defined in the virtual table AA.MARGIN.TYPE in EB.LOOKUP.
Examples may be a Corporate or Treasury margin.
Figure 41 EB.LOOKUP table.

Rate Adjustment Method – this is defined in field MARGIN.OPER with the following options:
• Add to rate.
• Subtract from rate.
• Multiply (i.e. the nominal rate is [100+Margin]% of the specified interest rate).
The actual margin is defined in MARGIN.RATE.
COMPOUND interest
T24 supports the compounding of both debit and credit interest in field COMPOUND.TYPE. The
following compound frequencies are supported:
• Daily (D) – Interest is compounded 365/6 times a year.

• Annual (M12) – Interest is compounded once per year.
• Semi-Annual (M06) – Interest is compounded 2 times a year.
• Quarterly (M03) – Interest is compounded 4 times a year.
• Monthly (M01) – Interest is compounded 12 times a year.
• Bi-Monthly (M02) – Interest is compounded 6 times a year.
• Twice-Monthly (TWMTH) – Interest is compounded 24 times a year.
• Weekly (WEEK) – Interest is compounded 52 times a year.
• Bi-Weekly (WEEK2) – Interest is compounded 26 times a year.
Types of Interest Rate

T24 allows for the definition of different types of interest rates.
There are three types of tiers; BAND, LEVEL and SINGLE and these are selected in field
RATE.TIER.TYPE.
SINGLE
If the option SINGLE is selected, a single nominal interest rate will apply for the entire balance
amount.
LEVEL
By specifying level tiers a product can be defined which will calculate interest at different rates
depending on the balance amount. A single rate of interest will be selected and applied based upon
the balance amount.
For a deposit you might want to have a higher rate of interest for accounts which maintain higher
credit balances. Conversely, for a loan product, a higher rate of interest can be charged for accounts
with higher debit balances.

For example, assuming a credit balance of 15,000 and level interest which specifies an applicable
rate of 10 per cent up to 10,000 and 15 per cent above 10,000. A single rate of 15 per cent will be
applied to the entire amount of 15,000.
BAND
Banded tier interest will typically result in a “blended” interest rate. This is similar to Level tiers, but
allows for the interest rate of each tier to be applied to the portion of the balance that falls within the
tier.
For example, assuming a credit balance of 15,000 and banded interest which specifies an applicable
rate of 10 per cent up to 10,000 and 15 per cent above 10,000. Two calculations will be performed (i.e.
10 per cent on 10,000 and 15 per cent on 5,000).
Each tier is specified by defining the amount up to which the interest rate applies. Additionally, each
tier can be of a different interest rate type (i.e. fixed, floating, or periodic).
In each case the fields FIXED.RATE through to TIER.AMOUNT are part of a multi value set of fields
and can be utilised if either LEVEL or BAND are selected. The rate to be applied to the calculation
amount is specified in the field TIER.AMOUNT.
The INTEREST Property Class also caters for the definition of complex tiers which are mixed tiers of
Bands and Levels.
It is possible to control the interest rate of an account during its lifetime using TIER.MIN.RATE and
TIER.MAX.RATE. This is applicable for variable and periodic rates and allows the tier rate to be
controlled.
Interest Calculation Basis

The calculation basis determines on what balance amount interest is to be calculated and is input in
field BALANCE.CALC.TYPE. The Interest Property Class provides for user defined balance calculation
types.
The following configuration can be defined by the user through AA.BALANCE.CALC.TYPE:
• Debit or Credit Balance.

• Calculation Type (Average, Current, Daily, Highest, Lowest, Routine).
• Calculation Start and End days. This allows the specification of a calculation period within the
capitalisation period and applies to Highest or Lowest calculation types.
• Calculation Routine which allows for a user-defined program to determine the balance amount.
Interest Calculation Threshold

Using field CALCULATION.THRESHOLD, a user can specify that interest will only be calculated if a
balance threshold is surpassed. For credit interest, the user can specify the minimum balance which
must be maintained. For debit interest, the user can specify the maximum debit balance for which
interest will not be calculated.

Interest Accrual Rules

When accruing interest, T24 must determine which amounts to include in each day’s balance, the
actual days to include in the period (e.g. first day, last day) and how to round any calculations. T24
allows users to define the calculation method to use, by specifying an accrual rule in
EB.ACCRUAL.PARAM.
Users can define the following in field ACCRUAL.RULE.
• First Day Inclusive (Yes/No)
• Last Day Inclusive (Yes/No)
• Rounding Rule (Natural, Down, Up, Currency, None)
• Intermediate Calculation Rounding (Yes/No)
• Credit value date adjustment
• Debit value date adjustment
Interest Day Basis

T24 can calculate interest based on day basis types which are defined in the application
INTEREST.BASIS and these values are stored in the field DAY.BASIS.
Each Interest Day Basis type is represented as a numerator and denominator.
• Numerator (interest days)
o 360 – Each month is considered to have 30 days
o 366 – The exact number of days will be used
• Denominator (days in the year)
o 360 – Each year is considered to have 360 days
o 365 – Each year is considered to have 365 days
o 366 – The exact number of days in the year will be used (365 or 366)
T24 allows the following interest day basis types:-

Figure 42 INTEREST.BASIS table.
Rate Control
T24 provides several ways to control the interest rate of an account during its lifetime.
• Tier Minimum/Maximum - For each tier defined, a user can specify a TIER.MIN.RATE and/or
TIER.MAX.RATE for the tier. This is applicable for variable and periodic rates and allows the tier
rate to be controlled.
• Rate Increase and Rate Decrease - Through periodic rules, users can control the increase and
decrease of the overall rate during a period of time (e.g. per month, per year, account lifetime,
etc).
• Rate Cap and Rate Floor - Through periodic rules, users can control the maximum (cap) and
minimum (floor) rates that apply to a balance amount.
Action Synopsis
ACCRUE
The accrue action can be initiated by the system or manually as part of the ACCRUE-INTEREST
activity. This will result in calculation of the accrued interest amount to the requested effective date
and the generation of accounting entries.

CAPITALISE
The action capitalise can be initiated by the system. This will result in calculation of the accrued
interest amount to the requested effective date and the generation of accounting entries.
MAKE.DUE
The make due action will apply the amount of interest due to be repaid to the DUE interest property.
The amount to be made due is determined from the associated BILL that is being made due.
REPAY
The repay action will allocate the amount of interest to be repaid to the appropriate account balance.
Depending on the PAYMENT.RULE applied the interest will be made against billed or current
amounts.
UPDATE
The UPDATE action is initiated manually and allows the User to change any of the INTEREST
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- INTEREST
activities.
DEBIT
The debit action applies the unallocated amount from a debit to the arrangement to the unallocated
debit balance of the arrangement.
CREDIT
The credit action applies the unallocated amount from a credit to the arrangement to the unallocated
credit balance of the arrangement
Other ACTIONS are PERIODIC.RESET, SUSPEND and RESUME.
Accounting
• ACCRUE
• CAPITALISE
• MAKE.DUE
• REPAY
• SUSPEND
• RESUME
• DEBIT

• CREDIT
• CAPTURE.BILL
• ADJUST.BILL
Figure 43 AA.PROPERTY.CLASS.
Limits
The INTEREST property does not perform any actions that impact on the limits system.

Delivery
The INTEREST property class generates delivery information as defined in field DEL.INFO.REQD.
Figure 44 INTEREST with DEL.INFO.REQD defined.

LIMIT
Overview
The LIMIT Property Class is used by all products which are account based. This property class
primarily controls the use of the LIMIT module by the account.
Product Lines
The LIMIT property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure
Figure 45 Limit Property.
Property product Relationship

The LIMIT product property supports the following arrangement links to the product:
• DATED
• FIXED

Figure 46 LIMIT Property Class.
Defining LIMIT conditions at Product Level

The conditions for the LIMIT will usually be defined at Product level and rarely changed or negotiated
at Arrangement level.
If the primary owner of the arrangement has a credit limit covering this account, the reference to that
Limit is specified in field LIMIT.REFERENCE. (For the LENDING Product Line the Limit Reference is
mandatory). If no limit reference is specified, and the ‘working balance’ will go into debit, an
'Unauthorized Overdraft' message is displayed and an override is required before the transaction will
be accepted. If a reference is specified, the corresponding Limit record is checked. If it covers the new
‘working balance’, the transaction is accepted; otherwise an override is required before the
transaction will be accepted.
Single Limit
An account can require exclusive use of a Limit. This can be defined at the Product level in field
SINGLE.LIMIT and negotiated at the Arrangement level if necessary.
Netting the Limit

If an account does not exclusively use a Limit, the user can specify that any credit balance of the
account can be added to the overall overdraft limit available to other accounts with the same limit
reference. This is specified in field ALLOW.NETTING where the options are YES or NO.

Synopsis of Actions
UPDATE
The update action is initiated manually and allows the User to change any of the LIMIT attributes. This
action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- LIMIT activities.
CHANGE
Accounting
The LIMIT Property does not perform any actions that generate accounting events.
Delivery
The ACTIVITY.MESSAGING Property class controls the T24 delivery events that are generated. The
LIMIT property class generates delivery information as defined in field DEL.INFO.REQD.
Figure 47 Field DEL.INFO.REQD.

OFFICERS
Overview
The OFFICERS Property Class is used by all products which need to assign product/arrangement
specific officers (i.e. different from the customer’s default officer
Product Lines
The OFFICERS property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure
Figure 48 Officers Property.
Arrangement Condition Relationship to the Product

The OFFICERS product property supports the following arrangement links to the product:
• DATED
• TRACKING

Figure 49 OFFICERS Property Class record.
Defining OFFICERS conditions at Product Level

The conditions for the OFFICERS will usually be defined at Product level and rarely changed or
negotiated at Arrangement level. The Property is tracking so any changes to the officer roles will be
reflected in the arrangement.
Both a primary and other officer can be specified in fields PRIMARY.OFFICER and OTHER.OFFICER.
If a second officer is defined, the role must also be defined in OFFICER.ROLE and any notes can be
added also. The officer roles are defined in the virtual table AA.OFFICER.ROLE in EB.LOOKUP.
Figure 50 EB.LOOKUP table.

Synopsis of Actions
UPDATE
The update action is initiated manually and allows the User to change any of the OFFICERS attributes.
This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- OFFICERS activities.
Accounting
The OFFICERS Property does not perform any actions that generate accounting events.
Limits
The OFFICERS Property does not perform any actions that impact on the limits system.
Delivery
OFFICERS property class generates delivery information as defined in field DEL.INFO.REQD.

OVERDUE
Overview
The OVERDUE Property Class is used by products which require past due processing. The financial
institution can create and manage its own overdue statuses (e.g. grace, overdue, non-accrual, etc.)
and can have different status for different products.
Product Lines
The OVERDUE property is used by the following product lines:
• LENDING
• ACCOUNTS
Structure
Figure 51 Overdue Property.


The OVERDUE product property supports the following arrangement links to the product:
• FIXED
• NEGOTIABLE
• TRACKING – The definition below means that the OVERDUE property can be TRACKING, but the
other options are also possible.
Figure 52 OVERDUE Property Class record.

Defining OVERDUE conditions at Product Level

The conditions for the OVERDUE Property will usually be defined at Product level.
The Overdue Property Class is primarily a list of Status Rules and Payment Tolerance conditions.
Status Rule
Each Status Rule defines when ageing of a bill will occur and the conditions to apply for the ageing
activity. The status rules are defined in sequential order.
Each OVERDUE.STATUS that overdue amounts can age through is specified by the user in
EB.LOOKUP.
Figure 53 EB.LOOKUP for AA.OVERDUE.STATUS.
Each Overdue Status can then be used to specify the ageing conditions and any associated
accounting. Within the specified AC.ALLOCATION.RULE, the event corresponds to the Status.
Aging
The ageing process can take place depending on the amount of days after the bill was due or by the
amount of overdue bills. This selection is made in field AGEING.TYPE.
The number of days or bills (relative to the amount due date) before an amount attains this Overdue
Status is specified in AGEING.
Notices
For each Overdue Status defined, a notice may be sent to the customer informing them of the status
of their arrangement. The user can specify a number of days after the status start to send a notice in
NOTICE.DAYS or notices can be sent out periodically until an arrangement is no longer in this
Overdue Status by adding a frequency in NOTICE.FREQ.
Age all Bills

A user can specify that if a bill reaches a certain status, all other bills for the arrangement will be aged
to the same status. Select AGE.ALL.BILLS for the required status. This functionality is typically used
for a “non-accrual” status which will result in all bills becoming “non-accrual” when a single bill
reaches this status.

Suspend Contract
The User can also specify that a move to this status should trigger a suspending of the arrangement.
Choosing field SUSPEND.CONTRAC would result in the cessation of P&L entries and the posting of
accruals to a special CRF category.
Movement of Balances
When a bill is to be aged, the user can determine whether or not the balances associated with the bill
amounts should be moved to new balances corresponding to the status. The User can do this by
selecting YES in MOVE.BALANCES. If the user chooses to associate a status with a unique set of
balances, the calculation and charging of different interest rates for different statuses is possible.
Payment Tolerance
If a user has chosen to move balances upon ageing of a bill the accounting entries can have effective
dates corresponding to the Status change, the Previous Status change, or the Due date. This allows
for the ability to have a grace period and a following status which can be effective from the original
due date. This selection is in field EFFECTIVE.DATE.
A payment tolerance is an amount or percentage of the billed amount which can remain “due” without
becoming Overdue.
For example a financial institution may decide that if a customer’s payment is within $25 of the billed
amount, overdue processing will not occur.
The tolerance can be expressed as a percentage (PAY.TOLERANCE) or alternatively as amounts by
currency (TOL.CCY and TOL.AMOUNT). If the repayment of a bill is within the specified tolerance the
user can specify in field TOL.ACTION that the bill is considered to be Repaid which will result in
accounting to move the remaining balance. Alternatively the user can specify that the bill will Remain
in the current status but will not be aged.
Synopsis of Actions
UPDATE
The update action is initiated manually and allows the User to change any of the OVERDUE attributes.
This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- OVERDUE activities.
The Age activity will be triggered during the Close of Business based upon the due dates of
outstanding bills and the ageing attributes that have been defined for each status rule.
Should an outstanding bill be subject to ageing the activity will first determine if the outstanding
amount of the bill is within any payment tolerance that has been specified.
If a bill is to be aged, the status of the bill will be updated, the specified accounting rule will be applied
(subject to the balance movement attributes) and any applicable charging will be initiated.
If based upon satisfaction of any payment tolerance the bill is not aged its status will either remain as
is or be changed to Repaid and accounting will be triggered.
Other actions are AGE.NEW.BILL, AGE.BILLS, AGE.SCHEDULE, ISSUE.CHASER and SUSPEND.

Accounting
• AGE.BILLS
Limits
The OVERDUE property does not perform any actions that impact on the limits system.
Delivery

PAYMENT.RULES
Overview
The PAYMENT RULES Property Class is used by any products which have amounts billed and made
due from the customer.
An arrangement may have several bills outstanding and each bill may be comprised of multiple
amounts (e.g. principal, principal interest, penalty, tax, charges, etc.). When a customer makes a
payment, the entire due amount may not be satisfied. The PAYMENT RULES Property Class is used to
define the method by which a single payment will be applied to multiple bills and multiple amount
types.
Product Lines
The PAYMENT.RULES property is used by the following product lines:
• LENDING
• ACCOUNT
Structure
Figure 54 Payment Rules Property.


The PAYMENT.RULES product property supports the following arrangement links to the product:
• DATED
• MULTIPLE
• TRACKING
Figure 55 PAYMENT.RULES Property Class record.

It is possible to have more than one instance of a PAYMENT.RULES property class. This is defined as
in field TYPE as MULTIPLE as shown above.

Payment Hierarchy
T24 can apply a payment to all amounts by Property (e.g. all Principal amounts followed by all Interest
amounts, etc.) or to all amounts of by ‘Bill’ (e.g., all amount on bill 1 followed by all amounts of bill 2,
etc.). This choice is selected by the User in field APPLICATION.TYPE.
In addition to specifying whether Properties or Bills will be given priority, the user must decide in
which order multiple bills will be processed in field APPLICATION.ORDER. T24 allows a user to
specify ‘Oldest First’ (i.e. chronological) or ‘Oldest Last’.
Whether processing by Property or by ‘Bill’ the user must specify the SEQUENCE in which the Property
due amounts (i.e. types) will be paid.
If payments are to be applied by Property this specifies the sequence in which each Property’s due
amounts must be completely satisfied.
If payments are to be applied by ‘Bill’ this specifies the order on each bill of the amount Properties.
In the case where a payment activity is initiated, but there are no outstanding bills the user must
specify another activity to process. This essentially allows for the activity to be switched from a
‘repayment’ to another credit type activity.
Reminder (Overpayment)
If a payment is made which satisfies all of the due and overdue amounts and there is a remainder of
funds (i.e. an overpayment), T24 must have a pre-defined method of handling the remaining funds.
An activity to be processed for the remainder of the payment can be specified in
REMAINDER.ACTIVITY this will be subject to any Transaction Rules. Should the transaction fail, the
remainder amount will be processed by the Default Activity specified in Accounting.
Synopsis of Actions
The Payment.Rules property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the PAYMENT.RULES
PAYMENT.RULES activities.
Other actions are ALLOCATE, CREATE.DUE and PRE.BILL.
Accounting
The PAYMENT.RULES Property does not perform any actions that generate accounting events.
Limits
The PAYMENT.RULES property does not perform any actions that impact on the limits system.

Delivery
The PAYMENT.RULES Property Class controls the T24 delivery events that are generated.
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated as
defined in field DEL.INFO.REQD.

PAYMENT.SCHEDULE
Overview
The PAYMENT SCHEDULE Property Class is used by all products which have amounts billed (i.e.
made due) or capitalised.
Product Lines
The PAYMENT.SCHEDULE property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure
Figure 56 Payment Schedule Property.


The PAYMENT.SCHEDULE product property supports the following arrangement links to the product:
• DATED
• CCY
Figure 57 PAYMENT.SCHEDULE Property Class record.

Defining the Date Settings

The BASE DATE is an Arrangement Activity date (e.g. ‘arrangement start’, ‘first disbursement’, etc.)
which will be used during automatic payment date generation. (For arrangements which include a
TERM AMOUNT property, the base date will also be used to specify the beginning of the ‘Term’ and
the ‘Amortisation Term’).
During the automatic generation of payment schedules, the DATE.CONVENTION and
DATE.ADJUSTMENT settings indicate the action which will be taken if the derived date is a non-
working day. There are four Date Convention options:
• Backward – the payment date will move backward to the last working day.
• Calendar – the payment date will not move regardless of whether it is on a working day.
• Forward – the payment date will move forward to the next working day.
• Forward Same Month – the payment date will move forward to the next working day provided it is
within the same month. If it is not within the same month, the payment date will move backward
to the last working day.
For all date conventions except for Calendar, DATE.ADJUSTMENT is used to specify whether the new
date will represent an adjustment of the ‘Value’ date of the entries or an adjust of the ‘Period’ (both
value date and processing date).
By default, T24 will check the holiday schedule for the country of an arrangement’s currency to
determine non-working days. Users can add additional countries using field BUS.DAY.CENTRES
whose calendars will also be checked with regard to holiday validation.
Amortisation and Residual Amounts

It is possible to define a RESIDUAL.AMOUNT at the maturity date of a term product that will be paid at
the maturity of the arrangement. This can be specified by entering an AMORTISATION.TERM with
which T24 can calculate payments and any residual or by entering a RESIDUAL.AMOUNT directly.
Defining the Payment Schedule

A Payment Schedule can be comprised of one or more Payment definitions with conditions such as
payment Type and Method, arrangement Properties, Dates and Amounts.
T24 provides a mechanism AA.PAYMENT.TYPE by which users can define the standard payment
types that can be used by a product.
A payment type is required for every payment schedule definition.
Figure 58 AA.PAYMENT.TYPE record.

Once the PAYMENT.TYPE has been specified, the user can specify the PAYMENT.METHOD as to
whether the amount will be Due (to or from the customer) or Capitalised. If a payment will be made
more than once, a PAYMENT.FREQUENCY must be specified.
Figure 59 Condition record with PAYMENT.FREQ options.
This is input using the T24 frequency code. Eg 15th of each month = M0115, End of every quarter =
M0331, Weekly = WEEK1
For each Payment definition the user must specify the Properties PROPERTY with amounts to be paid
and dates for payments. If a frequency has been specified in DUE.FREQ, the user can specify a
START.DATE or it can be defaulted from the Base Date. Additionally an END.DATE or
NUM.PAYMENTS can be specified to indicate to T24 when the payments should terminate.
There can be two amounts for each payment definition; Calculated Amount and Actual Amount.

A CALC.AMOUNT is determined by T24 based upon the Payment Type and Properties involved, but it
is also possible for the user to enter an ACTUAL.AMT to override the calculated amount.
Defining the Billing Rules

For each payment which is due from a customer, T24 will create a Bill record and optionally a Bill
Notice. The bill will contain the details of the amounts due, the due date, etc. This Bill record is also
the basis of the AA Overdue processing.
By default T24 will create the Bill on the due date, however for products which require a Bill notice to
be sent in advance of the due date, the user may enter the number of days prior in BILL.PRODUCED.
This will result in the due amounts being projected and recorded on the bill.
Additionally, if the bill is produced prior to the due date, the user can specify when the bill will be
considered final (i.e. the bill will not alter based upon changes to the arrangement).
T24 can also combine bills by selecting YES in BILLS.COMBINED which have the same due date
and are produced on the same date. This provides for example, the ability to combine a monthly
‘annuity’ loan repayment with a monthly charge to provide the user with a single bill amount.
For products which have constant payments a user may want to fix the payment amount for a period
regardless of any changes to the arrangement (e.g. principal increase, interest rate change, etc.). In
such cases a user can specify a payment RECALC.FREQUENCY so that the constant amount can be
recalculated periodically to take into consideration any of these changes.
The user must specify what if anything must be recalculated should certain Activities (changes of
payment components) occur on the arrangement. These activities are input into field ON.ACTIVITY.
The following Activity Classes may require a recalculation:
• Change – Charge
• Change – Interest
• Change – Payment Schedule
• Change Term – Term Amount
• Increase – Term Amount
• Decrease – Term Amount
For each component specified on the payment schedule the resulting action must be specified in field
RECALCULATE. The recalculation types are:
• Payment – the payment amount will be changed.

• Term – the term of the arrangement will be altered.
• Residual – the residual amount will be changed.
• Nothing – the payments, term, and residual will be unchanged. In this case a recalculation
frequency should be specified.

Synopsis of Actions
UPDATE
The update action is initiated manually and allows the User to change any of the PAYMENT.RULES
PAYMENT.RULES activities.
Other actions are CHANGE, CALCULATE, ISSUE.BILL, MAKE.DUE and CAPITALISE.
Accounting
• REPAY
Limits
The PAYMENT.SCHEDULE property does not perform any actions that impact on the limits system.
Delivery
PAYMENT.SCHEDULE property class generates delivery information as defined in field
DEL.INFO.REQD.

TERM AMOUNT
Overview
The TERM.AMOUNT Property Class is used by financial products which involve an amount of money
that is lent or deposited for a specified period of time. This property class controls the commitment
made by the bank and the customer.
Product Lines
The TERM.AMOUNT Property is used by the following product lines:
• LENDING
• DEPOSITS
Product Property Relationship

The TERM.AMOUNT product property supports the following arrangement links to the product:
• CCY
• DATED
• FIXED
For each arrangement contract the initial product default values will be stored with the arrangement
itself and cannot track the product definition.
Figure 60 TERM.AMOUNT Property Class record.

Figure 61 TERM.AMOUNT Property Class record continued.
Related Balances
The TERM.AMOUNT Property Class and linked Property has as an associated balance the current
available committed balance for the arrangement.
Current Committed Balance

For a loan contract this will reflect the available amount of the loan commitment available for disbursal.
This balance would normally be reported as a contingent balance type and will be a negative
(contingent asset) figure.
The current committed principal has a prefix of CUR.


Defining the Term Amount
The user must enter the total amount which will be lent or deposited for the term (i.e. the committed
amount) into field AMOUNT. During product definition it will be common to restrict the initial amount
through negotiation rules (e.g. 5000 < amount < 25000).
In order to disburse or deposit this amount (or a portion thereof), the user will have to credit or debit
the arrangement through one of the standard T24 applications (e.g. TELLER, FUNDS.TRANSFER
etc.). These transactions may be restricted by any rules (e.g. Transaction Rules, Notice Rules, etc.)
defined in the product.
When performing the INCREASE and DECREASE activities the CHANGE.AMOUNT field is used to
record the increase or decrease in committed principal to be applied.
Defining the Term and Maturity Date of the Arrangement

The field TERM determines the period of time by which the amount must be repaid (either to the bank
in the case of a loan or to the customer in the case of a deposit). During product definition it will be
common to default the term (e.g. a 30 year mortgage).
The term can be entered in a number of ways:
• Days (calendar1) (nnnnD)

• Weeks (nnnnW)
• Months (nnnnM)
• Years (nnY)
With some products at the end of the term a customer can choose to rollover the account – this can
be performed manually or automatically using the CHANGE.PRODUCT Property.
The TERM definition is used to calculate a MATURITY.DATE for the arrangement contract, this date
can either be entered directly or will default based upon the effective date of the property and applying
the defined TERM value.
Note that a MATURITY.DATE value is currently mandatory for LENDING product lines.

Figure 62 Example of Term and Maturity Date.
Defining whether the Arrangement is Revolving or Non-Revolving

T24 enables the definition of revolving term amounts for lending products. The effect of a revolving
product is to increase the available amount from which a customer may drawdown as a result of
certain payments. If a user wishes to have a revolving loan or line of credit there are two possible
revolving types and these are defined in field REVOLVING.
A non-revolving contract will never reinstate the available commitment amount on repayment,
whereas a revolving contract will reinstate the available amount on repayment. The following options
are available.
• NO – the available amount will not increase when any repayment of principal is made.
• PAYMENT – any payment against the outstanding principal (due or not due) will result in the
available amount increasing. Typically this setting would be used for fully revolving credit facilities.
• PREPAYMENT - only repayments against the outstanding principal (balance not yet due) – such
as an ad-hoc payment will result in the available amount increasing. Repayments against due will
not reinstate the committed amount. Typically this setting would be used when a product allows
over payment and subsequent redraw of the overpaid amount.
Updating of Limit for the Commitment

In field UPDATE.COMMT.LIMIT it is possible for the user to specify whether the commitment amount
of the LIMIT used for the arrangement is to be updated when the initial commitment is granted. A
setting of YES will result in the reduction of the limit available to the customer before any disbursal
takes place.
When disbursal takes place the LIMIT is always updated for the loan irrespective of this setting. If
this field is set to YES at disbursement time the limit will be updated to reflect that the disbursed
amount is an actual amount and not committed.

Periodic Attribute Classes associated with Term Amount

The TERM.AMOUNT Property Class provides the following Periodic Attribute Classes from which
users may define Periodic Attributes.
Amount Decrease
Used to restrict the maximum amount that the committed principal can be decreased by over a
specified period of time. The rule is validated when a DECREASE activity takes place on the
TERM.AMOUNT Property.
Amounts are compared from the AMOUNT field in the TERM.AMOUNT property.
The rule value must specify the maximum decrease AMOUNT.
For example a rule could be specified that specifies a maximum decrease in principal of 1,000 is
allowed over a 6 month period.
Committed amount 6 months ago 20,000
Allowed decrease in 6 month period is 1,000
If the new AMOUNT is less than 19,000 the rule will be broken.
Amount Decrease Tolerance

Similar to AMOUNT DECREASE except that the rule specifies the percentage decrease allowed over
time rather than a specific amount. The percentage decrease is calculated as the percentage of the
value at the start of the restriction period. The rule is validated when a DECREASE activity takes
place.
The rule value must specify the maximum decrease PERCENTAGE.
For example a rule specifies that a 5% decrease is allowed over a 6 month period.
Available balance 6 months ago 10,000
Allowed decrease in the 6 month period is 5% of 10,000 = 500
If the new AMOUNT value in the property is less than 9,500 the rule will be broken
Amount Increase
Used to restrict the maximum amount that the committed principal can be increased by over a
specified period of time. The rule is validated when an INCREASE activity takes place on the
TERM.AMOUNT property.
Amounts are compared from the AMOUNT field in the TERM.AMOUNT property.
The rule value must specify the maximum increase AMOUNT.
For example a rule could be specified that specifies a maximum increase in principal of 1,000 is
allowed over a 6 month period.
Committed amount 6 months ago 20,000
Allowed decrease in 6 month period is 1,000
If the new AMOUNT is more than 21,000 the rule will be broken.

Amount Increase Tolerance

Similar to AMOUNT INCREASE except that the rule specifies the percentage increase allowed over
time rather than a specific amount. The percentage increase is calculated as the percentage of the
value at the start of the restriction period. The rule is validated when an INCREASE activity takes
place.
For example a rule specifies that a 5% increase is allowed over a 6 month period.
The rule value must specify the maximum increase PERCENTAGE.
Available balance 6 months ago 10,000
Allowed increase in the 6 month period is 5% of 10,000 = 500
If the new AMOUNT value in the property is more than 10,500 the rule will be broken
Full Disburse
Allows control of whether partial disbursement is allowed. A value of YES will specify that when the
arrangement is disbursed all committed principal for the effective date of the disbursal should be
disbursed.
To apply this restriction for the life time of the arrangement the AA.PERIODIC.ATTRIBUTE should
be created with a PERIOD.TYPE of LIFE or PRODUCT if the restriction only applies for duration of the
current arrangement product.
The rule value must specify YES for full disbursement to be checked.
Synopsis of Actions
DECREASE
The Decrease activity is initiated manually and allows the User to decrease the commitment amount
of the arrangement subject to any negotiation rules, periodic rules, and the current outstanding
amount. This action is initiated as part of the DECREASE-TERM.AMOUNT ACTIVITY.
DRAW
The draw action is processed when a loan is disbursed. The action will:
• Validate that the amount to be disbursed is available.
• Raise the accounting event to reduce the available commitment amount.
• Update limits to reflect the reduced commitment amount if the commitment limit is updated.
INCREASE
The Increase activity is initiated manually and allows the User to increase the commitment amount of
the arrangement subject to any negotiation rules and periodic rules. This action is initiated as part of
the INCREASE-TERM.AMOUNT CLASS.

REPAY
The Repay activity is triggered from either a repayment transaction or as a result of a Payment Rule.
It runs the corresponding accounting rules and may update the available amount according to the
Revolving attribute condition.
CHANGE.TERM
The Change Term activity allows for a user to increase or decrease the Term of an arrangement
subject to the negotiation rules.
UPDATE
The UPDATE action is initiated manually and allows the User to change any of the TERM.AMOUNT
TERM.AMOUNT activities.
Accounting Events
This class controls via a Soft accounting set-up system what actual accounting entries are generated /
updated in T24 at given actions and events per Property.
The AA.PRD.DES.ACCOUNTING condition record is linked via Properties and actions to the
application AC.ALLOCATION.RULE.
Figure 63 Example of a typical soft accounting set-up.

As you can see from the above record and the first instance the AA.PROPERTY record PRINCIPAL
for the ACCT.ACTION INCREASE is linked to the table AC.ALLOCATION.RULE and record
LOANS-TA
Figure 64 AC.ALLOCATION.RULE record LOANS-TA
When the action INCREASE is performed for the first time or on an existing contract the configuration
in AC.ALLOCATION.RULE will determine the accounting entry generate. In this case an
RE.CONSOL.SPEC.ENTRY will be generated in T24.
The soft accounting configuration is therefore flexible enough so any given accounting can be
generated at any given event time.
Interaction with Limits System
The committed amount of the transaction will be updated in the LIMIT application.
Delivery

TRANSACTION.RULES
Overview
The TRANSACTION RULES Property Class can be used to govern the types and amounts of
transactions on an Arrangement.
Product Lines
The TRANSACTION.RULES property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS
Structure

Figure 65 Transaction Rules Property


The TRANSACTION/RULES product property supports the following arrangement links to the product:
• DATED
• MULTIPLE
• TRACKING
Figure 66 TRANSACTION.RULES Property Class record.

It is possible to have more than one instance of a TRANSACTION.RULES property class.

Defining the Transaction Rules at Product Level

Transaction rules would be defined at Product level and are tracking so that any changes to a
condition are automatically applied to any arrangement using that product. The ACCOUNTING
Property Class will map transaction codes to Activities. The user can then specify any transaction
activities in ACTIVITY.ID which will have rules applied against them.
• Complete Restriction - T24 allows for the complete restriction of the specified transactions. A
user can flag the transactions to be restricted and can specify whether a transaction of this type
will result in an Error or an Override. The Error or Override message is user definable.
• Periodic Rules - T24 enables users to define transaction rules bases upon periods of time
(including the full lifetime of the arrangement).
• Amount of Transaction - A user can restrict the amount of each transaction to a minimum,
maximum, or multiples.
• Maximum Number of Transactions - A user can restrict the number of transactions of this type
over a period.
• Maximum Total Amount - A user can also specify a maximum total amount over a period.
If any of these transaction rules are broken, the User can select either an RESTRICT.OVR or
RESTRICT.ERROR to be generated by the system.
Synopsis of Actions
UPDATE
The UPDATE action is initiated manually and allows the User to change any of the
TRANSACTION.RULES attributes. This action will be initiated as part of the NEW-ARRANGEMENT and
UPDATE-TRANSACTION.RULES activities. It can not be back-valued as the transaction that may have
been effected have already been completed and can not be restricted.
EVALUATE
Accounting
The TRANSACTION.RULES property does not perform any actions that generate accounting events.
Limits
The TRANSACTION.RULES property does not perform any actions that impact on the limits system.
Delivery

PROTECTION.LIMIT
Overview
The PROTECTION LIMIT Property Class is used by products which have daily limits on the cumulative
amount of transactions that can be done via an external channel (e.g. Internet, Mobile, ATM, etc.).
These limits can be applied at the Customer and/or External User levels1. The aim of this functionality
is to reduce the amount of money that can be fraudulently obtained by bad guys who have
compromised the system (e.g. by stealing user credentials, ‘man in the middle’ attacks, or an insider
with system access) while minimising the inconvenience to legitimate users. It can also impose limits
on internal transactions such as account to account transfers.
Products which utilize this class can have multiple PROTECTION LIMIT Properties defined.
Product Lines
The PROTECTION.LIMIT property is used by the following product lines:
• INTERNET SERVICES

The PROTECTION.LIMIT product property supports the following arrangement links to the product:
• DATED
• MULTIPLE
• TRACKING
Figure 67 PROTECTION.LIMIT Property Class record.

Defining Limits against certain Transactions

By default a limit which is established applies to all transactions. Should a user wish to limit certain
transactions whilst leaving others unrestricted they can do so by limiting the transactions. The product
code (e.g. FT, SC, etc) is input into field SYSTEM.ID. Additionally, the actual application (e.g.
FUNDS.TRANSFER, STANDING.ORDERS, etc.) is input into field APPLICATION.
The Limit can be limited further by selecting a TRANS.TYPE. This field is linked to
EB.TRANSACTION.TYPE which is used to group multiple transaction codes together. Field
ALLOWED.CCY limits the currency within the defined application and transaction.
Field BEN.RISK.RATE defines the risk rating that is assigned to the beneficiary.
These options are each multi-valued and aggregated with each other. For example should a user
choose an ‘Application’ of FUNDS.TRANSFER and a ‘Beneficiary Risk’ of High, then only
transactions initiated via FUNDS.TRANSFER, to a high-risk beneficiary will have the limit applied.
The user specifies the LIMIT.AMOUNT in a specific CURRENCY (e.g. USD 2000).
Synopsis of Actions
UPDATE
The update action is initiated manually and allows the User to change any of the PROTECTION.LIMIT
PROTECTION.LIMIT activities.
Accounting
The PROTECTION.LIMIT property does not perform any actions that generate accounting events.
Limits
The PROTECTION.LIMIT property does not perform any actions that impact on the limits system.
Delivery
Please see the ARC-IB Administration User guide for full set-up with External User.

UI.APPEARANCE
Overview
The UI.APPEARANCE Property Class defines the User appearance properties. It can be used to
configure tool style, language, skin, date format and amount format at the design level.
These field values will override the EB.EXTERNAL.USER and BROWSER.PREFERENCES
settings during runtime.
Product Lines
The UI.APPEARANCE property is used by the following product lines:

The UI.APPEARANCE product property supports the following arrangement links to the product:
• DATED
• TRACKING
Figure 68 UP.APPEARNCE Property Class record.
Synopsis of Actions

UPDATE
Accounting
The UI.APPEARANCE property does not perform any actions that generate accounting events.
Limits
The UI.APPEARANCE property does not perform any actions that impact on the limits system.
Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery

UI.BEHAVIOUR
Overview
The UI.BEHAVIOUR Property Class defines the manner in which external users can interact with the
internet bank application.
Product Lines
The UI.BEHAVIOR property is used by the following product lines:

The UI.BEHAVIOR product property supports the following arrangement links to the product:
• DATED
• TRACKING
Figure 69 UI.BEHAVIOUR Property Class record.
Synopsis of Actions

UPDATE
Accounting
The UI.BEHAVIOR property does not perform any actions that generate accounting events.
Limits
The UI.BEHAVIOR property does not perform any actions that impact on the limits system.
Delivery

USER.RIGHTS
Overview
The USER.RIGHTS Property Class is used by products to set the conditions on which an external user
can do, view and when they are allowed to access the system.
Product Lines
The USER.RIGHTS property is used by the following product lines:

The USER.RIGHTS product property supports the following arrangement links to the product:
• DATED
• TRACKING
Figure 70 USER.RIGHTS Property Class record.
Synopsis of Actions

UPDATE
Accounting
The USER.RIGHTS property does not perform any actions that generate accounting events.
Limits
The USER.RIGHTS property does not perform any actions that impact on the limits system.
Delivery

PROXY.PERMISSIONS
Overview
The PROXY.PERMISSIONS Property Class defines the manner in which external users can interact
with the internet bank application.
Product Lines
The PROXY.PERMISSIONS property is used by the following product lines:

The PROXY.PERMISSIONS product property supports the following arrangement links to the product:
• DATED
• FIXED
Figure 71 PROXY.PERMISSIONS Property Class record.
Synopsis of Actions

UPDATE
Accounting
The PROXY.PERMISSIONS property does not perform any actions that generate accounting events.
Limits
The PROXY.PERMISSIONS property does not perform any actions that impact on the limits system.
Delivery

PRODUCT.ACCESS
Overview
The PRODUCT.ACCESS Property Class defines the manner in which external users can interact with
the internet bank application.
Product Lines
The PRODUCT.ACCESS property is used by the following product lines:

The PRODUCT.ACCESS product property supports the following arrangement links to the product:
• DATED
• TRACKING
Figure 72 PRODUCT.ACCESS Property Class record.
Synopsis of Actions

UPDATE
Accounting
The PRODUCT.ACCESS property does not perform any actions that generate accounting events.
Limits
The PRODUCT.ACCESS property does not perform any actions that impact on the limits system.
Delivery

ARRANGEMENT.PREFERENCES
Overview
The ARRANGEMENT.PREFERENCES Property Class defines the manner in which external users can
interact with the internet bank application.
Product Lines
The ARRANGEMENT.PREFERENCES property is used by the following product lines:

The ARRANGEMENT.PREFERENCES product property supports the following arrangement links to the
product:
• DATED
Figure 73 ARRANGEMENT.PREFERENCES Property Class record.
Synopsis of Actions
UPDATE

Accounting
The ARRANGEMENT.PREFERENCE property does not perform any actions that generate accounting
events.
Limits
The ARRANGEMENT.PREFERENCE property does not perform any actions that impact on the limits
system.
Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery.

Arrangement Architecture - Introduction - Property Classes PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Arrangement Architecture - Introduction - Property Classes PDF

Uploaded by

Copyright:

Available Formats

Arrangement Architecture – Introduction / Property Classes

Information in this document is subject to change without notice.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide Page 2 of 120

Summary of Rules Based Delivery....................................................................................................32

TEMENOS T24 User Guide Page 3 of 120

TEMENOS T24 User Guide Page 4 of 120

The main features of the AA module are:

Main features of the product builder are:

Main features of arrangements are:

TEMENOS T24 User Guide Page 5 of 120

Product Lines Available

INTERNET SERVICES – ARC Internet Banking

PROXY.SERVICES – ARC Proxy Services

TEMENOS T24 User Guide Page 6 of 120

TEMENOS T24 User Guide Page 7 of 120

TEMENOS T24 User Guide Page 8 of 120

Property Product Relationship

Figure 2 ACCOUNT Property Class record.

TEMENOS T24 User Guide Page 9 of 120

Current Principal Balance

Due Principal Balance

Aged Principal Balance

Unallocated Credit Balance

Unallocated Debit Balance

TEMENOS T24 User Guide Page 10 of 120

Property Attribute Description and Use

Generic Arrangement Titles and Names

Currency Market and Position Type

Account Definition at Arrangement Level

Arrangement Reporting Classification

Arrangement Titles and Names

TEMENOS T24 User Guide Page 11 of 120

Field ALTERNATE.ID is a multi-valued field in ACCOUNT.PARMETER which is linked to the

TEMENOS T24 User Guide Page 12 of 120

• There is no CONDITION.GROUP allocated

Figure 3 ACCOUNT record with ARRANGEMENT.ID stored.

TEMENOS T24 User Guide Page 13 of 120

Figure 4 AA.ARRANGEMENT showing ACCOUNT number.

Using the Arrangement Account in Other T24 Applications

TEMENOS T24 User Guide Page 14 of 120

Figure 5 ACCOUNT.PARAMETER with ALTERNATE.ACC.IDS set.

Figure 6 FUNDS.TRANSFER used to draw down a committed amount.

TEMENOS T24 User Guide Page 15 of 120

TEMENOS T24 User Guide Page 16 of 120

TEMENOS T24 User Guide Page 17 of 120

TEMENOS T24 User Guide Page 18 of 120

Property Product Relationship

The property cannot be defined at arrangement level.

Figure 8 ACCOUNTING Property Class record.

TEMENOS T24 User Guide Page 19 of 120

Summary of Rules Based Accounting

Actions and Accounting Events

TEMENOS T24 User Guide Page 20 of 120

Link Between Property Accounting Events and Allocation Rules

Property Attribute Description and Use

Linking non-AA Transactions to Property Activities

TEMENOS T24 User Guide Page 21 of 120

Only a limited list of activities can be specified for the DEFAULT.CR.ACTIVITY,

• TXN.ACTIVITY – DEBIT or CREDIT

Disbursal of an Arrangement Loan

Repayment of an Arrangement Loan

Re-use of the Same Accounting Property Condition