Introduction to Retail Securitisation
Loan Securitisation allows the user to pool various type of loans or assets, such as, mortgage loans, personal loans, credit cards, etc. and sell these pools of loans as securities or bonds to another entity (Investor).
By securitising a loan, the selling institution becomes free from the risk of loan defaults and at the same time gets access to new funds, whereas the investor can participate in the loan market for better returns on their capital investment. As the investor becomes the legal entity for the purchased loans or assets, the principal and interest payments collected from the customer repayments are passed to the buying entity, although the servicing obligations and rights remains with the selling entity.
Loan Securitisation transactions involve huge risk (as the borrower of the underlying loan may default), the buying entity is very specific in the selection of assets. Example of selection criteria are:
- Loans that belong to a borrower whose risk rating is moderate or very low.
- Loans that are 100% secured by collaterals.
- Loans based on interest pricing – Fixed or Variable.
- Loan amount less than X amount.
- Loans with term or maturity less than n years.
- Loans that have repayment schedule - Annuity, Interest Only, and so on.
Although these loans are sold to another entity, the servicing obligations and rights remain with the selling entity. The borrower continues to repay the loan to the selling entity which ultimately gets credited to the investor’s Nostro account with the bank or remitted on a set frequency periodically to the investor’s beneficiary account.
The selling entity identifies the sold loans as off-balance items. It is also usual that the selling entity may buy-back the sold assets partially or fully from the investor and the loans become on-balance from the buy-back date.
The Loan Securitisation enables the following:
- Creation of securitisation entity or investors and their details.
- Creation of securitisation program or asset pools.
- Loan securitisation using share transfer where the loans are transferred to the investors books.
- A single loan can be securitised by performing a Share Transfer event or a group of loans can be securitised using the Bulk Upload option for performing the share transfer event.
- Option to sell loans either in full or partial (for example, x % of loan outstanding).
- Classification of the loans – securitised (sold)
- Transfer the securitised loans from on-balance to off-balances.
- Reporting the securitised loan balances in off-balance GL.
- Principal and interest owed to the investor.
- Charges such as insurance, tax can be excluded.
- Buy-Back or repurchase of the sold assets or asset pools.
- Provide online enquiries/reports
- Securitised loans by investor – Active, Closed Loans, all.
- Securitised loans by pools – Active, Closed Loans, all.
When the selling institution securitises a loan, the investors become sub-participants to the loan. With the Share Transfer option, the bank can transfer the asset to the investor. The investor pays the funds amount to the bank. After the securitisation of the loan, the borrower continues to repay the loan to the selling entity which gets credited to investor’s Nostro account with the bank. The bank maintains the records of the sold loans as off-balance items.
Configuration
Loan Securitisation is available for the Lending Product Line. The configuration is based on Lending Products. To configure a loan as securitised, the loan product should have the Participant Property Class (Sub-Participant Property Type) attached to it. Also, in Account Product Line, the Balance Treatment field has to be set to Participation.
The investors of the loan can buy their share via the process of Share Transfer. To do a share transfer, the bank user should use the Capture Share Transfer activity. The activity opens the Share Transfer Transaction Class where the necessary details can be captured.
Property Class
Loans that can be securitised have their parameters setup similar to a normal loan, except that the Product should have the Participant Property Class. Because the details captured in the Participant Property Class are contract specific, no details are set up at the Product Condition level.
The below Property Classes are applicable to the Loan Securitisation:
| Account | Chargeoff | Payment Priority |
|---|---|---|
| Accounting | Charge Override | Payment Rules |
| Activity Charges | Closure | Payment Schedule |
| Activity Mapping | Constraint | Payoff |
| Activity Messaging | Customer | Periodic Charges |
| Activity Presentation | Dormancy | Pricing Rules |
| Activity Restriction | Eligibility | Reporting |
| Agent Commission | Interest | Settlement |
| Alerts | Limit | Share Transfer |
| Balance Maintenance | Officers | Statement |
| Change Product | Overdue | Tax |
| Charge | Participant | Term Amount |
Read AA Product Builder user guide for details on Product Construction and Configuration process. Read AA Property Classes user guides for detailed information on Property Classes.
Illustrating Model Parameters
Loan Securitisation model parameters consists of:
|
Parameter |
Description |
|---|---|
|
Account |
The Account Property Class decides the accounting during securitisation. The user can choose between Participant accounting option as memo or contingent accounting. |
|
Participant |
The Participant Property Class holds information (such as ID, share percentage, beneficiary information) for the investors that participate in the loan (have fully or partially bought the loan arrangement) |
|
Share Transfer |
The Share Transfer Property Class transfers shares between investors during the life of the loan. The buyer or seller are an existing or new lender or entity. |
|
Accounting |
The Accounting Property Class is used by all products. Arrangement Architecture (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 or Property Class level. The categories to which the interest or charges have to be posted are also defined in this Product Condition. In Model Bank, the charges are amortised. |
|
Activity Charge |
The Activity Charge 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. In the model bank, for a Mortgage loan product a principal decrease fee is applied for a principal decrease activity and a new arrangement fee is applied when a new arrangement is created. |
|
Activity Mapping |
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 the applications such as Funds Transfer, Teller, Clearing, etc., which are linked by relevant transaction codes using this Product Condition. |
|
Agent Commission |
The Agent Commission Property Class records the agent and the agent arrangement for a given financial arrangement and monitor the default events that trigger commissions. It also provides a spread over the default commission rates and an overriding amount against the predefined commission calculation. |
|
Alerts |
The Alerts Property Class is used by all products. It enables alerts to be sent to the customer for various activities in an arrangement. Alerts can be subscribed at the arrangement level by 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. |
|
Activity Presentation |
The Activity Presentation is an optional Property Class that allows to define versions used for various Properties during arrangement activities. The versions can be defined at Property Class, Property and Activity levels. |
|
Activity Restriction |
The Activity Restriction Property Class specifies the restrictions 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. A charge can be attached for this and can be set to be made due , capitalised or deferred. |
|
Activity Messaging |
The Activity Messaging Property Class links the Soft Delivery module to Arrangement Architecture module. 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 records of EB.ADVICES. |
|
Balance Maintenance |
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 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. |
|
Charge |
The Charge Property Class is used for all charge calculations in AA. The charge can be a scheduled , periodic or an activity based charge. It 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 to waive the charge. |
|
Charge Off |
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. Feature Dual Accounting – i.e. having two sets of books; the Customer Record vs. the Bank Record and applying payments “independently” to the two records is enabled. |
|
Charge Override |
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. |
|
Change Product |
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 should be applied. It can also be used to define the roll over conditions for an arrangement. |
|
Closure |
The Closure Property Class closes 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. The cooling period functionality is available in the Closure Property Class (PC), for Accounts, Deposits, Lending, Rewards and Safe Deposit Box. 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. |
|
Constraint |
The Constraint Property Class defines constraints on the arrangement. The constraint indicates the maximum period an arrangement that can be backdated with an error or override. |
|
Customer |
The Customer Property Class is used by all products. This property class is used to define all the parties involved in an arrangement. The customer is always defined at the arrangement level. Each arrangement can have one or more legal owners defined in OWNER |
|
Eligibility |
The Eligibility Property Class evaluates 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 Rules Engine. Once these rules are validated, the EB.RULES.VERSION and EB.RULES are created in the system. |
|
Facility |
This Facility Property Class controls the list of available services for an arrangement account. When an external activity (financial/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. |
|
Interest |
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, etc.) Interest rates can be define as Fixed , Floating, Periodic or Linked Rate (referring an interest property from other arrangement). Tiered interest can also be defined. Further it is possible to define a Negative Rate, Minimum interest amount and waive the interest. |
|
Limit |
The Limit Property Class primarily controls the use of Limit module by the product. The user can set up single or shared limit and can define 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 user should provide New in the Limit Serial field. Further limits can be set to use the Limit module or it can be managed only within the arrangement architecture framework. |
|
Officers |
The Officers Property Class enables the user to define:
|
|
Overdue |
The Overdue Property Class controls the ageing process of the bills raised in arrangement. The ageing 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 the number of outstanding bills or 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. |
|
Payoff |
The Payoff Property Class produces 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 updated 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 by using the simulation framework. |
|
Payment Rule |
The Payment Rules Property Class controls the sequence and order in which the bills or outstanding balances that required to be settled. An arrangement can contain several outstanding bills and each bill can be comprised of multiple amounts (for example, principal, principal interest, penalty, tax, charges, etc.). When a customer makes a payment, the entire due amount cannot be satisfied. This Property Class is used to define the method by which a single payment is applied to multiple bills and multiple amount types. |
|
Payment Schedule |
The Payment Schedule Property Class is used by all products which have amounts billed (that is, made due or capitalized 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 amounts. The AA.PAYMENT.TYPE file is used to define the standard payment types such as Constant, Linear, Actual and Fixed Equal, etc., that can be used by a product. This payment type is then attached to each payment schedule definition. The start and end date can be specified. The user can specify 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. |
|
Payout Rules |
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. |
|
Periodic Charges |
The Periodic Charges Property Class defines 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. |
|
Statement |
The Statement Property class defines the legacy ACCT.STATEMENT feature at Arrangement Architecture level. Statements may be produced daily (every working day), every 1-9 weeks, twice a month (on the 15th and the last day of the month) or every 1-12 months on any day of the month. Up to nine statement cycles may be specified for each Account, and each statement cycle is independent. In addition to this, special interim statements can be enabled. This property class also controls if advices are to be produced or not, when interest and charges are applied, and whether detailed interest statements (interest scale) should be produced. |
|
Settlement |
The Settlement Property Class is used for various Product Lines to control the settlement related functions of all the Product Lines. Settlement can be handled by linking any Temenos Transact account, the account and bank details of another bank by using Direct Debit and beneficiary of the customer. The Settlement Property Class specifies the counter booking details with the Counter Booking Account, Dr Counter Booking Activity and Cr Counter Booking Activity fields. The Default Settlement Account is considered as the default account for both Pay-in and Pay-out Activities, if the Pay in or Pay out account is not specified. But, if the accounts are specified for the Pay in or Pay out, then those accounts precedes over the specified default settlement account. |
|
Dormancy |
The Dormancy Property Class allows the user to control the parameterisation of inactive or dormant accounts and movement of these accounts into various buckets at arrangement or product level. It can control 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. |
|
Tax |
The Tax Property Class allows the user 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. |
|
Term Amount |
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. |
Illustrating Model Products
Lending Product Line provides Home Equity, Line of Credit, Mortgages, Personal Loans, Small Business Loans and Securitised Mortgage Loans functionality for Temenos Transact. This module allows the user to create Home Equity, Line of Credit, Mortgages, Personal Loans, Small Business Loans and Securitised Mortgage Loans by using the AA framework under the Lending Product Line.
|
Product Name |
Product Attributes |
|---|---|
|
Home Equity |
|
|
Line of Credit (LOC) |
|
|
Mortgages |
|
|
Personal Loans |
|
|
Small Business Loans |
|
|
Consumer Loan |
|
|
Technical Loan |
|
|
Instalment Loan |
|
|
War Loan |
It is created to enable the calculation of a weighted average interest rate for the loans, which have multiple legs (tranches). |
|
Securitised Mortgage Loan |
Loan Securitisation is part of the existing AA Lending product line and it allows the user to sell a group of loans to a third-party investor. The already available Lending products now support Loan Securitisation. No new model products are introduced. |
In this topic