Introduction to Retail Bundle
The Arrangement Bundle module (AB) provides Product bundling functionality for Temenos Transact. The module allows retail products to be bundled with the following features:
- Consolidated interest calculation by taking set of arrangements either within the same Product Line or across Product Lines including the netting of credit balances against debit balance.
- One of the arrangements in the Bundle arrangement is the master arrangement (called the Recipient arrangement) and the balances of the Donor arrangements will be taken for the interest calculation along with the balance of the Recipient arrangement, with or without interest calculation of the Donor arrangements at their level.
- Bundle arrangement is not a financial arrangement and it only establishes the link between the Recipient and Donor arrangements.
- Adding new arrangements to the Bundle and removal of the existing arrangements from the Bundle is possible.
Illustrating Model Parameters
Product Conditions of a Property Class are evaluated to bring out the features of the Property Class. The values in the Product Condition are defaulted in an arrangement during its creation. The negotiability, default values and other restrictions are also defined in the Product Condition. These Product Conditions along with the Properties derived from the Property Classes are grouped together to build products.
Product Conditions are dated and some of them have currency as part of their ID. When currency forms part of the Product Condition ID, then the user has to create different conditions for each currency in which the product is available. When a new condition is created or an existing condition is amended, the product to which the condition is linked has to be proofed and published.
Model parameters consists of

The Activity Charges Property Class defines the charges that has to be applied when a particular activity is triggered on an arrangement. These charges 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 Restriction Property Class is used to specify the restriction on a particular transaction. The user can define the restriction rules including the relevant periodic attributes and activities 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.
A charge can be attached for this Product Condition and set to be made due , capitalised or deferred.
For Retail Accounts (AR) module, activity restriction is used for restricting transactions by number, type and so on. This is also used in other modules to restrict the user from performing various user activity based on life cycle status of contracts.

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 the user to define versions used for various Properties during arrangement activities. The versions used can be defined at Property Class, Property and Activity levels.

The Interest Property Class is used for all interest definition and processing in AA. A Temenos Transact product defined and processed in AA can have multiple Interest Properties defined (for example, principal interest, penalty interest, commission, and so on). Interest rates can be defined as fixed rate, floating rate, periodic rate, linked rate (referring an interest property from other arrangement), routine based calculation and tiered interest.
Further, it is possible to define a negative rate, minimum interest amount and waive the interest.
Interest adjustment can be done in runtime, and adjustment related details or values can be captured in adjustment related fields.

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 Groups, and the Properties. Interest can either be calculated or suppressed as defined in this Product Condition.

The Payment Schedule Property Class is used by all the products, which have amounts billed (that is, made due), capitalised or pay. A Payment Schedule can be comprised of one or more payment definitions with conditions, such as payment type and method, arrangement properties, dates and amount. The AA.PAYMENT.TYPE application is used to define the standard payment types such as Constant, Linear, Actual and Fixed Equal and so on that can be used by a product. This payment type is then attached to each payment schedule definition. The user can specify start and end dates, and the repayment of arrangement to commence after ‘n’ months from the arrangement date or ‘n’ months before the maturity or ‘n’ months after the change product or reset and rollover has happened.

The Periodic charges Property Class acts as a container to group different Charge Properties and calculates a periodic charge amount. The Payment Schedule Property Class drives this Property Class. A periodic charge property can be attached in payment schedule and periodic charge amount is calculated on schedule date.
At arrangement level, the user can adjust entire periodic charge.

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 at both Source and Target levels.

The Limit Property Class primarily controls the use of LIMIT module by the product. The user can set up a single or shared limit. The user can define the LIMIT.REFERENCE applicable for a specific product such that the same would be defaulted in an arrangement. For a new limit, at the arrangement level, the LIMIT.SERIAL has to be given as NEW. The AR module can have a self-contained secondary limit without having actual limit attached to it. Overdraft status\Notice for AR module is handled inside Limit Property Class.

The Product Bundle Property Class 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 Type field and the DONOR Product Groups, with the field min and max values of arrangement required under each Product or Product Group, and currency, which each arrangement can belong to.

The Bundle Hierarchy Property Class is used to define the allowed products and relations between products that are part of a Bundle. It is used in BUNDLE Product Line and is a product definition (product only). Accounts arrangement when linked to a Bundle that has bundle hierarchy definition is validated against the condition specified and only when the conditions are satisfied.
Accounts arrangement can become part of the bundle. Linking of an accounts arrangement with a Bundle is done by specifying Bundle arrangement reference through BUNDLE.ARRANGEMENT attribute in the Account Property Condition.
Illustrating Model Products
Retail Bundle (AB) Product Line provides various bundle account and package functionality for Temenos Transact. The module allows the user to create Account Bundles, Card Packages, Loan Offsets, Master Account and Retail Packages using the AA framework under the BUNDLE Product Line.
S.No |
Product Name |
Product Attributes |
---|---|---|
1 | Account Bundles |
|
2 | Card Packages |
|
3 | Loan Offsets |
|
4 | Master Account |
|
5 | Retail Packages |
|
In this topic