Introduction to Arrangement Architecture

The Account property class is used by all products which are account based. This primarily controls the description of the account. The Account property allows the user to define and control balance treatment, posting restriction, linked account number (for memo accounts), currency market, date convention related setup for the account.

The Account Consent property class allows the user to control, the recording and storing of the consent given by the customer for further reference and action. It controls the capture of the following consent related details:

• Consent ID
• Expiry Date
• Consent Type
• Temenos Transact TPP
• TPP and ASPSP references
• External references
• Default consent type
• Account Consent block details like Account ID, Block Consent, Block Notes

The Accounting property class is used by all products. AA uses activity-based accounting. Each property has different actions which require accounting. For each action, a corresponding allocation rule definition is required. Allocation rules can be defined either at property level or at property class level. The categories to which the interest or charges have to be posted are also defined in this product condition. In the model bank, the charges are amortised.

The Activity API property class is used to define properties having more than one routine to be merged from different product levels. If three levels of products are defined, this condition can be used to take all relevant routines from all the three levels so that all conditions and calculations are taken into account.

The Activity Charges property class defines the charges that has to be applied when a particular activity is triggered on the arrangement. The charges so applied can be made due, capitalised or deferred. The user can enable auto settle the charges made due from unallocated credit balance by setting the Auto Settle field to Yes.

In accounts, charges are enabled for dormancy, settle payoff and ageing. This property class is also used for all AA related modules. Charges are set for various other activities.

The Activity Mapping property class provides the link between external applications and arrangement activities when a transaction is performed on an arrangement account. A debit or credit to an arrangement account triggers a FUNDS.TRANSFER, TELLER, CLEARING, and so on. These applications are linked by way of relevant transaction codes using this Product Condition.

The Activity Messaging property class links the soft delivery module to arrangement architecture. Messages are sent based on the role and activity performed on an arrangement. This record allows either specific activities or activity classes to be defined and linked to the EB.ADVICES records.

The Activity Presentation is a non-mandatory property class, that allows to define versions used for various properties during arrangement activities. The versions used can be defined at property class, property and activity levels.

The Activity Restriction property class is used to specify the restriction on a particular transaction. The restriction rules including the relevant periodic attributes and activities are defined in the product condition. These rules are then used to define activity-based or property-based restrictions. A rule if broken can be set to result in an override or error. The user can attach a charge to this property class and set to be made due, capitalised or deferred.

The Agent Commission property class helps to record the agent and the agent arrangement for a given financial arrangement and monitor the default events that trigger commissions and provides a spread over the default commission rates and provides an overriding amount, as against the predefined commission calculation

The Alerts property class is used by all products. This enables alerts to be sent to the customer for various activities in an arrangement. Alerts can be subscribed at the arrangement level using EB.ALERT.REQUEST. Multiple owners of the arrangement are allowed to subscribe different alerts on that arrangement. The subscription of alerts can be restricted based on the role of the customer in that arrangement.

The Balance Availability property class enables the user to define the notice amount and period, which needs to be given by a customer for withdrawing money from his account. This component also controls the updation of the available balance ladder in the account.

The Balance Maintenance property class allows the user to capture bills and balances, and adjust the balances of the bill for the contracts, which have been taken over from existing legacy system or existing Temenos Transact Lending module into Temenos Transact AA module.

The actions such as CAPTURE.BILL, ADJUST.BILL and so on help in capturing the bill and its balances into the new system.

The CDP Consent property class allows the user to control, the recording and storing of the consent given by the customer which also contains the personal data for further reference and action. It controls the capture of consent related details like purpose, consent type, consent sub type, consent given and expiry date, and also consent block or withdraw details like block consent, unblock consent and withdraw consent.

The Change Product property class defines the rules and behaviour for allowing arrangements of one product to be changed to another product. 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 restrictions on products that change can be made to and when a scheduled change has to be applied. This property class can also be used to define the rollover conditions for an arrangement.

The Channel Access property class defines (through product)the channel that is allowed. It is used by all products which are channel based. Channels can be replaced or given additional channels at the arrangement level. It also allows subscription, de-subscription, blocking and unblocking of the subscription for a specific period.

The Charge property class is used for all charge calculations in AA. The primary purpose of this property class is to enable calculation of charge. The charge defined can be scheduled charge, periodic charge or an activity based charge. Charge can be fixed or calculated based on Band or Level. The currency in which the charge has to be applied can also be defined. It is possible to define a minimum charge and also waive the charge.

The Charge Override property class enables the customer to modify the ad-hoc charges triggered by an activity. The user can either waive or modify the activity charge or rule break charge.

The Charge Off property class enables the customer to charge off various properties financial balances in arrangements. This can be a partial charge-off, a series of partial charge-off transactions, or a total charge-off.

Dual accounting feature allows having two sets of books; the customer record vs. the bank record. Also applying payments independently to the two records is enabled.

The Closure property class is used to close an arrangement account. An arrangement account can be closed automatically or manually. This is defined in the product condition. On reversal of a new arrangement, closure is triggered automatically.

Cooling period functionality is available in the Closure Property Class (PC), for Accounts, Deposits, Lending, Rewards and Safe Deposit Box. Cooling Period, Cooling Date Adj, Cooling Waive Class, Cooling Waive Prop and Waive Bill Type fields are newly added. If the customer chooses to cancel (that is, payoff) the loan within the cooling period, any charges and interest are waived off based on the product condition setup. The cooling end date is adjusted as if it falls on a non-working day and the same is moved to next working day.

The Constraint property class is used to define constraints on the arrangement. The constraint indicates the maximum period an arrangement that can be backdated with an error or override message.

The Dormancy property class allows the user to control the parameterisation of inactive or dormant accounts and movement of the same into various buckets at arrangement or product level. The same can be controlled based on period, and some exceptions or rules also can be added for evaluation and movement. The user can include or exclude certain activity or activity class for the evaluation.

The Eligibility property class is used to evaluate the eligibility of a customer for a specific product based on a set of rules. In Temenos Transact, first the EB.CONTEXT has to be created. Based on this, rules are defined using the rules engine. Once these rules are validated, the EB.RULES.VERSION and EB.RULES are created in Temenos Transact.

This Facility property class controls the list of available services for an arrangement account. When an external activity (financial or non-financial) is triggered and the corresponding service group is identified as blocked for this account, then an error message appears to stop the activity.

The Inheritance property class is used for BN Pool structure for inheriting the product conditions set at parent level arrangement to the child level arrangement accounts. The product conditions that are set for inheritance are attached to Property records with type as Inheritance Only. The properties to be inherited can be controlled both at source and target level.

The Interest Compensation property class is used by a bundle product. This is used to store the source and target interest properties, recipient and donor product group and the properties. Interest is either calculated or suppressed as defined in this product condition.

The Limit property class primarily controls the use of LIMIT module by the product. The user can set up single or shared limit. We can define the LIMIT.REFERENCE applicable for a specific product such that the same is set as default in an arrangement. For a new limit, at the arrangement level, the LIMIT.SERIAL has to be given as New. Further limits can be set to use the LIMIT module or it can be managed only within the arrangement architecture framework.

The Officer property class enables the user to define product or arrangement specific officers. The officer’s roles can also be defined. The user can define primary officer as well as additional officer.

The Overdue property class controls the ageing process of the bills raised in arrangement. The aging period, statuses and accounting treatment of the outstanding balance can be defined. It is possible to define penalty interest to be applied on the overdue amounts and/or current balances. Bills can be aged based on number of bills outstanding or based on number of days. It is also possible to define that all bills of an arrangement have to be aged to the present status. Accounting entries can be made to raise for every status movement and chaser advices can be scheduled. It is also possible to suspend the arrangement when a particular status is reached.

The Payment Rules property class controls the sequence and order in which bills or outstanding balances need to be settled. An arrangement may have several bills outstanding and each bill may be comprised of multiple amounts (for example, principal, principal interest, penalty, tax, charges, and so on). 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 is applied to multiple bills and multiple amount types.

The Payoff property class is used to produce a payoff statement, which is given to a customer when a loan payoff is considered. It shows the current status of the account including the update accrued interest and penalty applicable, if any. An expiry date can be defined for the payoff statement and the loan statement shows the additional daily interest to be charged till the expiry date.

The payoff amount is calculated using the simulation framework.

The Payout Rules property class is used by various Product Lines, which have amounts billed and made due for payment to the customer. It is used to define the method by which a single payment is applied to multiple bills and multiple amount types.

The Periodic Charges property class is used to define a charge to be applied in relation to a period of time. The charge currency can be specified and the charge can be set to be deferred. A minimum and maximum charge amount can be defined.

The Preferential Pricing property class allows the user to configure the preferential pricing adjustments that have to be made to financial arrangement for customers who have a certain relationship with the bank.

The Product Access property class defines the manner in which external users can interact with the internet bank application.

The Product Bundle property lass is used to store the arrangements that form part of a bundle. It stores the Recipient arrangement which is marked with the INTEREST.COMPENSATION property name in the Master Type field and the DONOR product groups, with the Mandatory field set to either Yes or No. The Product Bundle property class also provides the option to delegate the Bundle constitution rules to the Product Qualifier when the RULE BASED button is selected in the Bundle Constitution attribute.

The Product Commission property class is used in Agent or Reward Product Line. The same is used to configure financial Product Line or Product Group or Products that are eligible for commission calculation, to define if commission has to be paid immediately or is scheduled. The setup also allows definition to specify if claw-back of commission has to be done.

The Protection Limit property class is used by products which have daily limits on the cumulative amount of transactions that can be done through an external channel (such as Internet, Mobile, ATM, and so on). These limits can be applied at the customer and/or external user levels. The aim of this functionality is to reduce the amount of money that can be fraudulently obtained by compromising the system (for example, 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.

The Proxy Permissions property class defines the manner in which external users can interact with the internet bank application. Through this property, an intermediary can be given permissions to access a customer's specific accounts, arrangements, contracts and portfolios. Several proxies may act on behalf of a single customer and one proxy may as well work for several customers.

This Property class is used by all products. It is used for reporting IFRS cash flows and also data to Position Management applicable for the arrangement. The following are additional settings:

The Safe Deposit Box property class is used in Safe deposit box product line, to define the box type and box number associated with the product.

The Settlement property class is used various product lines to control settlement related function of all product lines. Settlement can be handled by linking any Temenos Transact account, the account and bank details of another bank using Direct Debit, and by using beneficiary of the customer.

The Settlement property class specifies the counter booking details with the three fields: Counter Booking Account, Dr Counter Booking Activity and Cr Counter Booking Activity. The Default Settlement Account is taken as the default account for both Pay in and Pay out activities, if the payin or payout account are not specified. But if the accounts are specified for the payin or payout, then those accounts take precedence over the specified default settlement account.

The Statement property class is used to define the ACCT.STATEMENT, legacy feature at arrangement architecture level. Two type of frequency for account statement can be set, and an additional statement frequency can also be set.

The Tax property class allows to control and define tax that has to be calculated for various financial property. Tax definition can be done at both Property Class and Property Tax level. The tax can be attached both at TAX and TAX.GEN.CONDITION level.

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. The user must enter the total amount which is lent or deposited for the term (that is, the committed amount) into Amount field. During product definition it is common to restrict the initial amount through negotiation rules (for example, 5000 < amount < 25000).

The user can also define one or more commitment tranches using Term Amount property class.

Users are allowed to create their own product lines and associate various property classes to their products. Users can also define their own property classes and use them to their external products created.

The Xinsurance property class is a user-defined property class, the same is used in external products (user- defined).

Swift property class is used to capture the contractual details and the terms & conditions of the Guarantee or SBLC undertaking.

In model bank, the user can link the Temenos Transact accounting to the arrangement activities and define their own accounting rules for a specific product. The ACCOUNTING Property is mandatory for all financial product lines. This menu controls the link between the accounting events generated by the property actions and the accounting allocation rules to be applied to these events. Users can specify accounting rules for each Property, which has actions requiring accounting.

AC.EVENT records are released by core accounting and are the link between the soft accounting configuration in AA and what is passed to the core accounting to be processed as accounting entries. A combination of these records can be used to create the total entries that are required for any given activity in AA.

This option is used to define the frequency for performing accrual and amortisation activities for AA products.

A single definition exists for a company and frequencies can be defined at the following levels:

• For a specific property of a specific product
• For a specific property in any product
• For any property

This option is used to determine how accruals are performed by the core accrual processing.

The following options are available.

• Whether or not accrual takes place on the first day of a contract, the default is yes.
• Whether or not accrual takes place on the last day of a contract, the default is no.
• Whether the effective date of a principal increase or decrease is changed by a set number of days (+ or -).

All applications that use the core accrual processing provides an option to input this record ID in the main contract, so that different products within the same application can be accrued differently.

This enquiry displays the list of allocation rules that are set in the model bank. As such the AA accounting entries are user definable. Actions performed on an arrangement can result in the movement of one or more balances associated with the arrangement. Each action can generate a number of accounting events. 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. This application is used to define the allocation rule to be applied for each action associated with a property

This enquiry displays the list of existing Balance types set for AA in Model Bank. In AA, each event or activity affects some balance in the arrangement like, CURCOMMITMENT, CURACCOUNT and so on. The definition of such balances is held in this file.

This enquiry displays the list of entry types set in Model Bank viz. CATEG-AA, SPECIAL-AA and STMT-AA.

This enquiry displays the list of Source Calculation types for AA in Model Bank. Each product require an account source amount for calculation, a record has to be created using this enquiry and specify how the balance amount can be determined.

Source balance amount can be daily, average, highest, lowest, current or a routine may return the balance amount for a balance type. It is also possible to define credit or debit balance amount required for calculations

It constructs a view of the accounting schema in real-time, based on the product and accounting rule set-up. Currently the details relating to balances required for this enquiry are built and populated directly during runtime of a particular event, these details are not stored statically in any table. Two new fields are to be included in the AC.EVENT table which holds the credit and debit balance prefixes for that particular event.

AA.CONTEXT.TYPE application is used to pass the values for Context Name and Context Value from external application to AAA

The AA.CUSTOMER.RELATED.ARRANGEMENTS table stores all the related arrangements of a customer for Relationship Pricing purposes. This table records both the arrangements owned by the customer and the arrangements of the related customers based on certain rules.

The Customer attribute that enables users to define the customer roles and their characteristics that can be assigned to a customer of an arrangement

The Product Line provides a high-level definition of the business components (Property Classes) that may be required to construct a product belonging to that line.

For example the LENDING Product Line enables users to design and service term loan products such as:

• Loans (personal, small business, etc.)
• Mortgages
• Lines of Credit

The Product Lines are defined by Temenos and cannot be created by the user. A Product Line is described by the Property Classes which constitute it. The financial institution may then use these building blocks of functionality to construct the individual products which are available for sale to its customers.

The AA.COMMISSION.TYPE application gives the information on calculation source used for calculation of commission for agents using AA.CONTEXT.TYPE and calculation logic for calculating commission is derived from the combination of SOURCE TYPE, SOURCE BALANCE and SOURCE PROPERTY.

The AA.CUSTOM.RATE.TYPE is table used to any user specific interest calculation method using routine.

In AA, Activities are associated with Properties. For example, disbursing a loan is associated with the Commitment property; an accrual of interest on the loan principal is associated with the Principal Interest Property, and so on. Activity classes are predefined in the system and each Property Class is linked to an activity class.

This enquiry displays the list of predefined comparison types that are available in model bank. The user cannot add any new comparison types. However, if required, amendment of the description of the comparison type is possible.

This enquiry is used to view the existing Payment Rule Types used in model bank.

The user can create a Payment Rule Type from the enquiry, or view/edit an existing payment rule type.

It is used to view the existing Payment Priority Types used in model bank.

It is required for every payment schedule definition. A new Payment Type can be created or an existing payment type can be viewed or edited.

In AA.PAYMENT.TYPE, the Payment Mode field (Mode) is set as ADVANCE.

It describes the actions allowed for Property classes and specify if Accounting is valid for a Product Line.

In this application, the user can specify time-related restrictions on product conditions of specific properties. In model bank, periodic attributes are predefined for certain Property Classes. For example, for the Interest class, minimum interest, maximum interest, rate increase, rate decrease, etc are already predefined in model bank.

Similarly, Periodic Rules can be used to specify transaction rules such as the number and value of withdrawals or disbursements allowed within a specified period or periods. For example, for the Term Amount Property Class, the Amount Decrease periodic attribute record is defined to indicate maximum principal decrease allowed during specific time periods.

It is a central file which gives an overview of the account based arrangement. The information that is stored in this file are start date, maturity date, drawdown date, bills generated for a date, status of these bills, payment information, aging status, etc.

It enables users to define different types of scenarios for APR calculation.

A source type is defined using which the APR is calculated and a routine can be mentioned which calculates the APR using the source type.

It enables the bank whether the settlement processing for settlement account needs to be reversed and replayed with the new or changed amounts or rates. Once the user opts for Automatic, the behavior should not be changed to Manual or Null.

It enables the bank to define a settlement functionality for a new contract based arrangement, which has a Payin or Payout settlement account. The settlement works in accordance with the current balance in the settlement account.

It is used to view the existing records from the Integration Condition (AA.CLASS.APPL.CONDITION) and enables the user to map all the existing attributes from all properties and linked applications connected to an arrangement. If a user tries to set up the exit point from an Activity or Activity Class, then it allows defining the related applications (which are related to the Activity or Activity class) and non-Related application (which is not updated through this exit point) as well.

It provides an option to add the required applications during design time and during the run time, system triggers the corresponding local hook method for message extraction.

If an activity is in unauthorised status (rate change or account static change), the user is not allowed to perform another activity. However, multiple unauthorised credit or debit transactions are allowed for an AR account since a debit or credit transaction can occur anytime (for example, ATM transaction). Since, multiple transaction that are held in unauthorised status creates performance in COB, this version is designed to let the user decide if the activity can remain active and to which product line and for the rest.

The following are the parameters used in defining the statement narratives.