top of page
Search

An Overview of Arrangement Architecture in T24

Writer: Josef Mayrhofer
Josef Mayrhofer
4 days ago
3 min read

Arrangement Architecture (AA) is the agreement between the customer and the bank with predefined, customized conditions to maintain Loans, Deposits, or Accounts in a core banking platform. Before learning AA, you need to understand the basic concepts of Customer, Account, Interest, Charges, Limits, and coding concepts.

 

Arrangement Architecture Components


To establish a clear connection between the components, we need to understand each component separately:


  1. Properties:

Properties refer to distinct characteristics within a Property Class that hold particular values or conditions. This is nothing but an instance of an AA Property class. For example, if INTEREST is the property class, then PRINCIPLE.INT and PENALTY.INT represent the type of interest.INT and PENALTY.INT, which represents what type of interest is called the PROPERTY. It is similar to all the property classes. These properties can be either fixed or negotiable at the product level or the arrangement level. When a customer arrangement is initiated, the property values are automatically assigned to it, and these are accompanied by dates and are currency-specific.


  1. Property Classes:

Property Classes represent essential characteristics of AA Products. For example, in AA.PROPERTY.CLASS, the record ID’s apply names such as CUSTOMER, INTEREST, and CHARGES. These are provided by Temenos, which banks use to build saleable products. These are linked to particular products such as LENDING (Loans) and DEPOSITS (Fixed deposits)


  1. Product & Arrangement Conditions:

Product conditions are automatically assigned to arrangements and can be negotiated unless designated as Product Only. Product Only attributes (e.g., accounting rules) remain unchanged and are not subject to editing in arrangements.  An arrangement represents a customer-specific instance of a product. Negotiation Rules dictate which product attributes are subject to modification at the arrangement level.


For Example: In LOANS, there are certain product conditions. As soon as a customer takes a loan amount of $1,000,000 USD, these product conditions are applied, and arrangement conditions are generated for that one million USD. Repayment schedule, Principle, and interest are calculated accordingly.


  1. AA Products:

Standard AA financial products are developed using configurable property classes (e.g., interest, fees, terms). Categorized into established Product Lines and Product Groups defined by Temenos, which cannot be altered by users. The PRODUCT.LINES are LENDING, DEPOSITS, and ACCOUNTS. The products that are developed using all these components are the ones which customer opts in to at the bank. A simple example of this would be Mortgage loans, fixed and recurring deposits.


  1. Product Designer:

Product Designer is the application where we link the specific product conditions to properties. AA.PRD.DES.” PROPERTY.CLASS” is the application name. Once all the conditions are defined, proofing and publishing of the products are also taken care of here. If there are any errors in the product design, we will get to know about them during proofing and publishing. Once the product is published, it’s ready to sell to clients.

 

How Are the AA Components Connected?


  1. Property Classes categorize related Properties that outline product characteristics.


  2. AA Products are formed by merging Property Classes and adjusting them via Product Conditions.


  3. The Product Builder oversees the process of product creation, inheritance, negotiation rules, and lifecycle management.


  4. Customer Arrangements derive default values from Product Conditions.


  5. Arrangement Conditions facilitate customer-specific modifications within established negotiation rules.


  6. This framework ensures a standardized, reusable, and adaptable product configuration while allowing for regulated customization at the customer level.

 

How Can We Track the Arrangement Details?


AA.ARRANGEMENT.ACTIVITY will store all the system details and user-triggered activities from start to finish. We can also use simulation to check the exact behavior before implementing anything live.


  1. Tracking: Any change in the product condition will be applicable to all the arrangements that are defined as tracking


  2. Non-tracking: Any change in product condition will have no impact on any arrangements that are defined as non-tracking


  3. Custom Tracking: Existing arrangements are unaffected. Any change in product condition applies to newly created arrangements, defined as custom tracks.

 

Performance Tuning AA


The most crucial rule is to consider the products' conditions while designing them. This practice will avoid unnecessary product creation. The traditional approaches to AA performance include DLM, archiving, and indexing. The latest additions are 'Active arrangement archival,' 'Enhanced service process,' and other tuning.


Functional and Technical details are crucial when using this powerful concept. We provide module-specific training for AA to ensure performance is not hindering growth. Feel free to contact us at Performetriks if you are looking for AA-related training and implementation.

Happy Performance Engineering!



Comments

bottom of page