Working with Migration of Lending Arrangements

Each loan arrangement has to be linked to a customer in the CUSTOMER application. Every loan has to be captured in the Temenos' Lending module to ensure that the associated client data is made available in our system and the legacy loan data can be associated with the customer number in the Temenos' system.

Differences in TBC

In TBC, during migration of a loan contract, the information related to owners and other parties can be input from an external system such as Party TBC. The system evaluates this customer information against the records found in the external system.

For each customer in a loan arrangement, a corresponding LIMIT record is created in our system before creating the arrangement.

Differences in TBC

In TBC, during the takeover of a loan, the user can update the sanctioned limit amount for the loan using the Limit Id field in the Limit condition.

A loan can be a long-term contract in the legacy system, which can be ongoing for several years. The usual practice for the takeover of financial contracts is for the contract to be takeover to take place with an effective date that is equal to a scheduled date (for example, interest or principal due date).

The contract is created with principal balance and interest rates at the selected event date as a new contract. Interest rate and principal changes after the event date are loaded into our system as future-dated activities. Details of previous history and balances are not used in the contract processing in our system.

The date chosen can be the last payment date, which can be a past date.

Existing contracts are analysed to identify the earliest date that can be used to create an arrangement.

The existing products in the legacy system has to be analysed and products have to be created for the Lending Product Line that provides the same functionality.

The legacy system is unlikely to provide functionality in exactly the same way as Temenos' system and data may not map directly from the legacy system to our system.

Properties, Product Property Conditions and Products have to be created with an effective date that is on or earlier than the earliest contract date for takeover identified in the legacy data.

Products have to be published, including any known future conditions and made available for sale before arrangements can be created.

It is unlikely that the legacy system has the concepts of product inheritance and negotiable attributes as our system so the legacy products are likely to be supported best by:

• Not using any inheritance in the product structure.
• Making the majority of attributes negotiable for arrangements.

Differences in TBC

In TBC, the loan contracts are migrated to products which are designed and defined using a product management system like the TPM (Temenos Product Manager).

The AA module supports the ability to record arrangement level conditions for information purposes only. Once the arrangement is created, it is possible to load historic conditions if required. Any data loaded prior to the creation date in our system are not used for processing and is not a mandatory requirement.

Temenos' system cannot process the adjustment to loan contracts with an effective date prior to the takeover date. The usual approach is to make the amendment in the legacy system if still available, or manually calculate the adjustment. The adjustment can then be applied to the arrangement in our system effective the takeover date.

The value of outstanding bills have to be taken over into Temenos' system with an effective date equal to the start date of the arrangement in our system or the takeover date. Data has to be made available for overdue bills.

The value of penalty interest and charges calculated (accrued) by the legacy system has to be made available at the takeover date (that is, effective date of arrangement creation in our system). It provides the ability to take these balances over.

The following data should be made available (or be able to be derived) in Temenos' system:

• Customer number.
• Product name.
• Effective Date for the takeover of the contract.
• Currency of Arrangement.
• Outstanding principal balance as at the Effective Date.

A separate extract of overdue bills for existing arrangements has to be prepared. It includes,

• The bill due date.
• The breakdown of properties and outstanding amount for the bill.
• A legacy contract identifier that should be possible to link to the created arrangement number after takeover.

Any outstanding penalty interest or charge accrual balances for loans should be prepared and should identify

• The Property name (for example, PENALTYINT)
• The balance amount for the Property.

In order to create the arrangement in our system during takeover, an AA.ARRANGEMENT.ACTIVITY transaction is created (usually through OFS – although it is possible to enter such a transaction manually).

The transaction is performed using the LENDING-TAKEOVER-ARRANGEMENT Activity. This is a specialised Activity, which is a variation of the standard LENDING-NEW-ARRANGEMENT used to create the loan arrangement.

The following details are supplied in AA.ARRANGEMENT.ACTIVITY:

The information regarding current weighted average rate for migrated contracts, can be passed from legacy to our system using a feed. Context name and Context Value is such a feed. AA.CONTEXT TYPE holds the definition of Context name.

For this purpose, Legacy War Rate is released as part of Core to retrieve the data provided in Context Name and Context Value fields and update the PERIODIC.RATE. By having the rate value, the WAR routine can calculate and update the Effective Rate of the contract in the same manner as for the new arrangements.

Read Weighted Average Interest Rate for more information.

Details of values to be applied to the properties of the arrangement are supplied as part of the AA.ARRANGEMENT.ACTIVITY OFS request, using the associated fields:

• xx<Property
• xx<xx<Field.Name
• xx>xx>Field.Value

Once the transaction has been authorised, the system creates:

• An arrangement contract and number.
• An associated arrangement ACCOUNT record.

The ARRANGEMENT reference allocated is returned as part of the OFS response.

Differences in TBC

• When the user migrates a loan through a front-end API, the system triggers the corresponding Activity in the TBC to complete the migration process. During migration of a loan contract,
  • The product to which the loan contract is migrated must be selected from the list of products available in the interface such as TPM (Temenos Product Manager ).
  • The information related to owners and other parties can be input from an external system such as Party TBC. The system evaluates this customer information against the records found in the external system.

The outstanding bills can be taken over individually to Temenos' system once the arrangement is created. The bill is created with an effective date equal to the date taken into our system but with a bill date of the original issue date.

AA.ARRANGEMENT.ACTIVITY captures the bill details using the AA.ACTIVITY.CLASS LENDING-CAPTURE.BILL-BALANCE.MAINTENANCE Activity.

The following details are supplied in AA.ARRANGEMENT.ACTIVITY:

The outstanding accrued penalty interest and other charges can be taken over individually once the arrangement has been created. The balances should be created with an effective date equal to the date taken over into our system.

The AA.ARRANGEMENT.ACTIVITY application is used to capture balances using the AA.ACTIVITY.CLASS LENDING-CAPTURE.BALANCE-BALANCE.MAINTENANCE Activity.

• It is possible to configure the reporting condition to hand off the required information to an external system for calculating the annual percentage rate for loans in TBC. The TBC generates a business event to hand off the cashflows to an external system for further processing to take place. All other features related to Reporting condition are not applicable for TBC.
• The features pertaining to EIR as well as AMC are not applicable for loans in TBC and can be enabled using external solutions.