Loans

Financial Inclusion / Accelerator
Loans User Guide

Product Builder
Loan Operations
Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means, for any purpose, without the express written
permission of TEMENOS HEADQUARTERS SA.
© 2018 Temenos Headquarters SA - all rights reserved.
Loans – Product Builder and Operations
Table of Contents
LOANS IN FINANCIAL INCLUSION ................................................................................................ 4
Introduction ........................................................................................................................................................................ 4
The Product Wizard ................................................................................................................................................................. 4
Configuration ........................................................................................................................................................................... 4
Model Parameters ............................................................................................................................................................... 5

Global Product Parameters ...................................................................................................................................................... 5
Model Products ................................................................................................................................................................... 8
Inheritance Groups .............................................................................................................................................................. 9

Introduction ............................................................................................................................................................................. 9
Working with Inheritance Groups.......................................................................................................................................... 11
Loan Product Groups ......................................................................................................................................................... 12

Introduction ........................................................................................................................................................................... 12
Configuring Product Groups .................................................................................................................................................. 12
Working with Product Groups ............................................................................................................................................... 12
The Loan Product Wizard ................................................................................................................................................... 15

Introduction ........................................................................................................................................................................... 15
Configuring the Product Builder Wizard ................................................................................................................................ 16
Working with the Product Builder Wizard ............................................................................................................................. 16
Output for Loans Product Builder Wizard.............................................................................................................................. 46
Direct Loan Input ............................................................................................................................................................... 48

Introduction ........................................................................................................................................................................... 48
Configuring Direct Loan Input ................................................................................................................................................ 48
Working with Direct Loan Input ............................................................................................................................................. 48
Outputs for Loan Creation ..................................................................................................................................................... 53
Loan Disbursements .......................................................................................................................................................... 55

Introduction ........................................................................................................................................................................... 55
Working with Individual Loan Disbursement ......................................................................................................................... 55
Group Disbursement.............................................................................................................................................................. 56
Outputs for Loan Disbursement ............................................................................................................................................ 58
Loan Repayment Operations ............................................................................................................................................. 58

Introduction ........................................................................................................................................................................... 58
Configuring Loan Repayment Operations .............................................................................................................................. 59
Working with Loan Repayment Operations........................................................................................................................... 60
Loan Top-up and Rescheduling .......................................................................................................................................... 62

Introduction ........................................................................................................................................................................... 62
Configuring Loan Top-up and Rescheduling ....................................................................................................................... 62
Working with Loan Top-up and Rescheduling .................................................................................................................... 64
Page 2 | 84
Arrears Management ........................................................................................................................................................ 65

Introduction ........................................................................................................................................................................... 65
Configuring Arrears Management ......................................................................................................................................... 65
Working with Arrears Management ...................................................................................................................................... 65
Outputs for Arrears Management ......................................................................................................................................... 65
Provisioning ....................................................................................................................................................................... 66
Introduction ........................................................................................................................................................................... 66
Working with Provisioning ..................................................................................................................................................... 67
Outputs for Provisioning ........................................................................................................................................................ 74
Loan Write Off and Recovery ............................................................................................................................................. 76

Introduction ........................................................................................................................................................................... 76
Configuring Loan Write Off and Recovery ............................................................................................................................. 76
Working with Loan Write Off and Recovery .......................................................................................................................... 78
Outputs for Loan Write Off and Recovery ............................................................................................................................. 82
Page 3 | 84
Loans in Financial Inclusion

Introduction
This guide aims to provide information regarding the configuration of loan products in Financial Inclusion /
Accelerator, herein referred to as FI/ACL, and the various operations that may take place during the lifecycle of a
loan including disbursement, repayment, arrears management, write off and recovery. The FI/ACL specific
configuration for these operations is described in detail, in this user guide.
The guide is divided into two main segments, each describing the functionality, parameter set up procedures and
deal processing. The two main segments are;
1. Product Wizard
2. Loan operations
The Product Wizard

Financial Inclusion / Accelerator delivers a product wizard where users are able to define complex loan products
by following a simple guided workflow. The wizard takes users through the stages and provides easy-to-follow
statements to explain what is needed for each field of the builder.
Where certain product features are common to all products of the institution, it is not necessary to define these
features per product, rather, the system provides functionality for the inheritance and reuse of product conditions
so these only need to be defined once and are thereafter available to all products.
Before the products are available for sale, a summary report is accessible to see all values selected to configure
the product and a supervising officer is able to review these before proofing and publishing the product.
Configuration
First, decisions need to be made as to what steps would be included in a product wizard and what steps need to
be done outside of the builder.
Product Setup Outside of the Product Wizard (Predefined in Financial Inclusion)
• Creation of Product Groups

• Creation of Parent Products
• Configuration of shared conditions
• Configuration of necessary Group Parent Conditions
Sample records have been predefined and made available for selection while using the product builder to create
child products. Child products inherit properties/conditions from the parent products.
The organization of products built using the FI product builder is derived directly from AA. The products are
organized into product groups, and parent products are used to hold common product conditions under a named
object.
Read AA Product Builder user guide for details on Product Designing in AA.
Read AA Property Classes user guide for detailed information on Property Classes.
Page 4 | 84
Model Parameters
Global Product Parameters
In the global product parameters table (EM.PRODUCT.PARAMETERS), various parameters that affect the lending
functions in Financial Inclusion are defined. The parameters are described in the next section.
Product Parameters
Various loan Parameters can be defined in this tab, as described below.
Initial Deposit Category range

One of the Eligibility conditions defined for loan products in the loan product builder wizard is the Initial Deposit
requirement. The initial deposit functionality automatically blocks a predefined amount of funds in the customer’s
saving’s account, as a requirement to avail a certain loan product. The savings account is determined as any
Page 5 | 84
account of the customer falling within the category range defined in the Initial Deposit Category start and initial
Deposit category end fields.
The system automatically blocks the savings value as defined on the product using the AC.LOCKED.EVENTS
functionality.
Minimum Savings Month Category Range
Another Eligibility condition defined for loan products in the loan product builder wizard is the minimum savings
month requirement. This is the minimum number of months that a customer must have a savings account in
operation with the institution before being able to make use of this product. leave blank if not applicable
Category range to be evaluated for savings months are maintained in the savings age category start and savings
age category end.
Term Input Type
This parameter determines how the term is set for Top-up and Reschedule initiated from Loan Origination or Direct
Loan. For example, assume a loan that was created on 1st January is rescheduled on 15th February with new term
being 6 months.
• “Amend Original Term” – new term is set from loan start date (1st Jan) i.e. new maturity date will be 1st July
• “Define From Today” – new term is set from reschedule date i.e. new maturity date will be 15th August
Start Date Source
This is the repayment start date for Top-up and Reschedule initiated from Loan Origination or Direct Loan.Unlike
term input type, “Start Date Source” affects repayment dates only.
For example, assume a loan that was created on 1st January, rescheduled on 15th February, repaid monthly and
the field START.DATE in the payment schedule condition is empty (i.e. repayments happen on 1st day of each
month).
• If the parameter is set to “Contract Next Due Date”, then the next payment date after reschedule is not
changed i.e. it remains as 1st March
• If the parameter is set to “Product” – then the next payment day after reschedule is derived from payment
schedule condition. In this case the START.DATE is empty so first repayment should happen after 1 month
i.e. next repayment date after reschedule becomes 15th March.
“Start date source” affects repayment dates only while “Term Input Type” affects term.
Term as Number of Payments
With this setting enabled, term is always defined based on term defined for the loan. For example, if moratorium is
given initially and therefore the first repayment date is expected much later. For example, a customer applies for a
12 months loan and requests a 3 months grace period before the first repayment. Therefore the maturity date will
be calculated as three months plus term defined (15 months).
History Routine update
The local table EM.LOAN.HISTORY in FI/ACL stores information about every Top-up/Reschedule performed on a
loan. The “History Update Routine” allows customers to add some local data in fields USER.FIELD/USER.VALUE
once top-up/reschedule is performed.
Page 6 | 84
The History update routine is called by ACTIVITY.API routine EM.VA.AA.LOAN.HISTORY.UPD. The parameters are:
(sAaArrId, rEmLoanHistory, sOutFieldNames, sOutFieldValues)
- sAaArrId – incoming – AA.ARRANGEMENT id

- rEmLoanHistory – incoming – EM.LOAN.HISTORY record
- sOutFieldNames – outgoing – array of local customer field names saved in USER.FIELD of
EM.LOAN.HISTORY
- sOutFieldValues – outgoing – array of local customer field values saved in USER.VALUE of
EM.LOAN.HISTORY
Payment Product
Select the Payment Order Product to be used to generate the payment orders for External (Beneficiary)
disbursements through the Direct Loan application.
Group Limit Parameters
In this tab, category codes that should be considered as savings accounts when calculating group limits are defined.
As per the group limit functionality, the savings multiplier is applied on the savings balances in the customer
accounts of the categories defined here. Similarly, the categories used for reporting on the customers’ savings are
defined here. Please refer to the Group Management user guide for more information.
Guarantor Limit Parameters

Category codes of the accounts to be used as loan guarantee are parameterized here. The amount used to
guarantee borrowed funds is blocked using AC.LOCKED.EVENTS. Please refer to the Guarantor Management
user guide for more information.
Page 7 | 84
Savings Multiplier Parameters

The Savings multiplier functionality helps institutions to offer their customers a shadow limit that is solely based on
their savings account balance subject to a multiplier factor. The multiplier value, the category code that represents
Savings accounts, and the category codes of the products subject to the savings-based limit, are maintained in this
tab.
Model Products
Financial Inclusion is delivered with three sample Loan Product groups. Sample shared conditions for each product
group are also released for reference or use by your institution, if suitable. The three Loan product groups are;
• Consumer Loans
• Business Loans
• Home Loans
Page 8 | 84
Inheritance Groups
Introduction
First, and only if necessary, a new inheritance group could be created to identify necessary components for product
building and select those that will be inherited across products.
Next, the selected inheritance components need to be defined for inheritance at product parent level. The product
parent is then created with option to inherit the defined components or to define new ones at the product level.
The diagram below presents a sample inheritance flow.
The inheritance group Consumer contains two shared conditions groups: Personal and Staff. The Personal
shared conditions group defines two shared conditions for term/amount and principal interest (please note that the
shared conditions are named the same as the shared condition group itself). Similarly, the Staff shared conditions
group defines two shared conditions. The shared conditions can be inherited by linking them to a product parent
on a product group.
The product group ConsumerLoans contains one parent product: PersonalLoans. This parent product defines
that for personal loans, term/amount and principal interest conditions should be inherited from the linked shared
conditions – from Personal shared conditions group.
When defining a new consumer product StudentLoan, using the product builder wizard, and selecting the product
parent as PersonalLoans, the wizard would only ask for definition of conditions that are not inherited –
customer/account, payment schedule, etc. The term/amount and principal interest conditions would be inherited
from the parent. Please note the names of conditions created for product – they are the same as the product code.
Page 9 | 84
In Financial Inclusion, sample Inheritance Groups have been defined for use (if they meet requirements), and to
show how to define conditions for inheritance (when necessary).
Page 10 | 84
Working with Inheritance Groups

The following section describes the Inheritance group process
Inheritance Group Details:

• Enter the name and description of the inheritance group.
• Select the Currencies under which shared conditions are to be created
• Enter the date from which the shared conditions will be made available.
Shared Conditions
The shared conditions are grouped under named objects – shared condition groups. Within a condition group, the
selection of the shared conditions to be defined is made.
The shared condition builder workflow is determined by the selection on this screen. When we select ‘Define Later’,
it means that the user does not wish to define any shared product conditions for the marked property classes and
hence those will be skipped in the workflow. Only items marked as “Define Now” will be presented in the workflow.
To define shared conditions:
• Input a Condition Group Code - A free format shared condition group code that is to be linked to the Shared
condition builder to determine which stages (those marked as define now) are to be presented in the
workflow.
• Input a brief description of the shared condition group
• Select “Define Now” for the property classes whose conditions are to be defined for sharing (Inheritance)
• Select Yes on the launch the Condition Builder and commit the record
• Define conditions for every stage presented by the shared condition builder wizard. Please refer to the
Product Wizard section of this user guide for more details on how to define product conditions.
Page 11 | 84
Note: It is possible to create more than one shared condition groups by expanding the multi value Icon next to the
Condition Group Code
Loan Product Groups

Introduction
The Product Group Application (EM.PRODUCT.GROUP) is used to create Product Groups under which Products are
to be designed. The system is delivered with Three (3) product groups predefined for reference purpose. Your
institution may use these product groups (if they meet requirements) or create new ones based on the
organization’s loan product requirements.
Configuring Product Groups

• Not Applicable
Working with Product Groups

This section describes how to define a Product family (EM.PRODUCT.GROUP) using the FI product builder
Loan Product Group Details

• In this tab, the name and description of the product family is entered
• Select the category code range under which products under this family will be defined. The category range
3100 to 3399 is used in Financial Inclusion Model bank. This range is further broken down into Consumer
Loans (3100-3199), Business Loans (3200 – 3299), Home Loans (3300 – 3399), Personal Loans (3400 –
3499) and SME Loans (3500 – 3599). The “New Category” link is used to create a new category code if
required. Only the category codes in the range defined at the product group will be available for selection
when creating a new product under the product group.
Page 12 | 84
• Select all the currencies in which products defined within this product family be may be available.
• Select the effective date of the product group.
Global Conditions
Global conditions are Group Parent Conditions that apply to all products in the same group and are unlikely to differ
from one product to the other. These are predefined by the Financial Inclusion team and should not be amended
without exercising due care. No user input is required on Global Conditions tab.
Page 13 | 84
Shared Conditions
In this version, shared condition created using the inheritance group are linked to the properties to form a second
level of parent conditions for the Group. This is done as follows;
Page 14 | 84
• Enter the Parent Product Code and the Parent Product Name.
• Select “Inherit” on the stage level for the properties whose conditions are to be inherited.
• Select the parent condition defined previously, from the lookup list. For all the other items left with the default
setting of “Define Now”, the Product builder wizard will present the respective stages (input screens) for the
definition of the product conditions.
• Once the product group record is committed, it needs to be proofed and published before Products can be
created. This is done using the Manage icon available on the list of Product groups.
• Click the icon to proof the Product Group, and to publish. Global Parent conditions should be proofed
and published first before the Parent conditions.
Note: The parent product code becomes the ID of the parent product auto created in AA, when the product group
record is proofed and published. The parent product code will be available for selection when creating the child
product. This determines the what stages are to be present for input by the product builder wizard. (those marked
as “Define now”)
The Loan Product Wizard

Introduction
The Financial Inclusion product wizard provides a user-friendly process for defining loan products. It acts as an
interface between the user and the Arrangement Architecture (AA) of Temenos Transact so that the user does not
need to fully comprehend the complex architecture of AA in order to setup new products. During the process, the
user only needs to setup conditions that are relevant to the business requirement. The building of a new product
is also driven by process workflow, which provides better control over the process.
Product Setup Inside of the Product Builder (Defined using the product building wizard)
 Configuration of Child Product Conditions for identified properties

 Creation of the Child (or final) Product
This chapter provides an overview on the various stages of the product builder and the product conditions that are
preconfigured per product.
As part of the configuration, only the technical or global parameters were included in a parent product. Since the
system does not allow multi-values for the product group field in product creation, it is not possible to create only
one parent product record for all groups. Therefore, one parent product record shall be created for each product
group.
It is possible that a user is using an existing product as a parent (or model) product to a new product, possibly
because one or two product conditions in the new product differ from those in the parent (or model) product. In
Page 15 | 84
this case, all already defined product conditions of the selected parent/model product are displayed for the user to
amend as desired. The product builder creates a unique, new product out of this, with all product conditions created
newly and named differently for the new product. This is to ensure that when amendments are made in future,
they are only made on the product conditions necessary for each unique product.
Configuring the Product Builder Wizard

The product Builder Wizard is configured at Product Group creation. The product inherits the characteristics defined
in the product group under which the final product is to be defined.
For more details please read the FI Product Groups section of this user guide
Working with the Product Builder Wizard

The Product Builder Wizard in Financial Inclusion (EM.LOAN.PRODUCT) is used to create the final product.
Access
Product Parameters > Loan Products > Product Groups > New Loan product
Procedure
The following section describes the loan product building workflow.
• Click on the icon next to the product group where the new product belongs.
• Next, enter the product identifier and select the product parent.
Note: Having previously created the Product Group, Group conditions and Parent conditions, the first step in building
the product is to link the product to the respective product group and parent product. This link to the Parent
conditions also establishes the product conditions to be configured using the product building workflow. These
would have been marked as “Define Now” at Group creation stage.
Page 16 | 84
Product Details
On the product details tab,
• Enter the Product name and a meaningful description of the product
• Enter the product category. This category code should fall within the category range defined in the Product
Group. Where the category code has not been created previously, the New category link may be used to create
the category code without exiting the workflow
• Enter the start date of the product. Start date can be in the past meaning back dated arrangements may be
opened
Page 17 | 84
Customer / Account Stage

On the basic details tab,
• Indicate whether Joint Ownership is allowed for this product

• The name of the Arrangement account to be opened is defaulted on the Name field. This facilitates reporting
whereby each Loan account of the customer is identified with the name of the loan product.
On the Account Parameters tab,
• Select the base date to determine the contract anniversary date

• Select the date convention to be used while generating payment schedules. Options are
1. Backward
2. Calendar
Page 18 | 84
3. Forward
4. Forward same Month
Please refer to the AA Property Classes user guide for more information on date convention
• Select the date adjustment to specify the action to be taken during the automatic recalculation of payment
schedules if the derived date is a non-working day. Options are:
1. Value – Only the Value date of repayments entries will be adjusted (Actual payment date is not
adjusted).
2. Period - Actual payment dates will be cycled
Input not allowed with Calendar date convention.
Page 19 | 84
Limit Stage
Limit conditions are defined as described below.
• Select Yes if limits are required for the production in definition, else select No.
• If limit definition is required, specify if secured limits are to be created for all arrangements created using
this product by selecting one of the three options available. When a loan is created using such a product,
the limit creation process checks this parameter to determine whether the secured limit should be fixed or
variable. If the parameter is set to either FIXED or VARIABLE, then the system updates the field
SECURE.LIMIT in LIMIT accordingly. Next, the COLLATERAL.RIGHT record linked to the loan is updated
automatically, thus creating a secured limit.
• Select the limit type. If Default is selected, the system automatically creates a limit record of an amount
equivalent to the loan amount using the default LIMIT.REFERENCE records predefined in FI as follows:
o 8399– Non-Revolving Loans

o 8499 – Revolving Loans
• If a loan requires exclusive use of a Limit, select yes on the Single Limit field.
• If User Defined is selected, then the limit reference code should be provided. The user defined limit
reference code provided must be defined in the LIMIT.REFERENCE application. Additionally, the same code
must be added to the loan product link in the LIMIT.PARAMETER application, as illustrated in the screen
shot below. This is only necessary where the bank wishes to maintain a more complex limit structure
different the preconfigured process in the Financial Inclusion Model Bank.
Page 20 | 84
Please refer to the Limits user guide for more information on Limit parameterization.
Related Items
• Related Items: Limits, Collateral, AA Property Classes
Page 21 | 84
Term Amount Stage

In this stage, Term and Amount conditions are defined as follows.
On the Term Parameters tab,
• Enter the default term for all contracts if applicable for the product being defined. Leave as blank if not
applicable. Next, indicate whether the default term is negotiable or not. If negotiable, the minimum and
maximum term fields become mandatory for input.
• Enter the minimum and maximum term allowed for the product. The last letter should be one of the
following; DWMY. Indicate whether the system should display an error or override message when the
rules are not met
• On the Cooling Period field, enter the number of days within which the contract can be pre-closed without
a penalty.
Note: For the cooling period functionality to take effect a “Request payoff” operation needs to be triggered and the
arrangement has to be repaid through the LENDING-SETTLE-PAYOFF activity during the cooling period. Upon
triggering these activities, Accrued interest amount for the arrangement till the pre-closure date is reversed. Any
Page 22 | 84
interest amount that has already made due/capitalized will not be reversed and will be included as part of the
payoff bill.
If this is done within the Cooling period specified no interest will be calculated for the principal amount.
On the Amount Parameters tab
• Enter the default amount for all contracts if applicable for the product being defined. Leave as blank if
not applicable. Next, indicate whether the default amount is negotiable or not. If negotiable, the
minimum and maximum amount fields become mandatory for input.
• Enter the minimum and maximum amount allowed for the product. Indicate whether the system should
display an error or override message when the rules are not met
• Lastly, indicate if the contract amount should be revolving or not. The options are;
1. No – Revolving functionality not required
Page 23 | 84
2. PAYMENT- any payment against the outstanding amount, whether due or not due, will result in
the available amount increasing.
3. PREPAYMENT - only repayments against the outstanding amounts not yet due will result in the
available amount increasing.
• Tranches – Set to Yes if the product requires the loan to be made available in tranches over multiple time
frames. This enables the borrowers to withdraw the loan amount in a phased manner as defined in Loan
Origination.
Payment Schedule Stage

In this stage, payment schedule conditions are defined as follows.
• Indicate whether loans under this product are to be disbursed fully or progressively. This parameter is disabled
for tranche disbursement loans.
• Specify if contract opened under this product should be automatically disbursed on authorization of the contract.
Hint - If the automatic disbursal field is not inputable, it means that product is linked to a shared Settlement
condition where automatic disbursal is enabled.
Page 24 | 84
• Select the default repayment frequency for contracts opened under this product. Currently the following options
are supported in the FI product builder: Weekly, Bi-Weekly, Custom, Monthly, Quarterly, Half-Yearly, Yearly.
• Select the repayment type to be set for contracts opened under this product. Options are;
1. Constant – results in equal repayments. This is used for ‘Annuity’ contracts where instalment amounts
are uniform.
2. Linear – Principal repayments remains fixed over the life of the arrangement while interest repayment
decrease over the term of the contract, thus resulting in a non-uniform instalment.
3. Full bullet – Both principal and accrued interest are payable on the maturity date.
4. Principal Bullet – Principal is due on maturity date but interest will be payable on the defined frequency.
5. Custom – select this option for irregular schedule definitions
• Lastly, indicate what should happen when loan prepayment is made? Options supported are;
1. Recalculate instalment amount based on the new reduced principal
2. Recalculate the term first then the repayment amount
3. Recalculate the term by keeping the instalment amounts unchanged.
The option selected updated the payment schedule condition respectively as below.
Custom Schedules
To facilitate the definition of irregular repayment schedules at the product level, it is now possible to invoke the
core Payment Schedule parameters (AA.PRD.DES.PAYMENT.SCHEDULE) within the Loan Product Builder. This is
done by setting the Repayment Frequency and Repayment Type fields in the payment schedule stage to “Custom”
as shown in the screenshot below.
Page 25 | 84
Note: If either repayment type or repayment frequency is set to Custom, then the both fields must be set to
custom.
Upon committing the stage with Repayment Frequency and Type set to Custom, the system automatically displays
the Core Payment Schedule Product Condition screen for advanced input.
The main idea behind this functionality is to help institutions define majority of the standard schedule parameters
at the product level. This minimizes user input when processing loan applications.
Below are some examples of irregular schedules.
Example 1: The repayment schedule is defined with a two-month repayment holiday after the first four instalments.
Page 26 | 84
Example 2: Irregular repayments dates and repayment amounts are specified upfront i.e., months 06, 07, 08 and
09
Page 27 | 84
Principal Interest Stage

In this stage, Interest conditions are defined as follows.
• Select the interest calculation method and the source balance to be used for interest calculation.
o If the “Current + Overdue Principal Balance” is selected, then interest is calculated on

LOANOUTSTANDINGBAL which is a virtual balance made up of (CURACCOUNT, GRCACCOUNT,
DELACCOUNT and NABACCOUNT). This means that interest is accrued on all amounts owed by the
borrower, including overdue principal.
o If the “Current Principal Balance” option is selected, then interest is calculated on the CURACCOUNT
balance type only. This means that if the loan becomes overdue, interest will not be accrued on the
overdue principal.
• The day basis to be used for principal interest calculation is defaulted by the system.
Note: In the Financial Inclusion product builder, the Interest day basis automatically is defaulted based on payment
schedule frequency settings.
o If Interest Calc. Method is Flat and Payment Type is Constant Monthly, Day Basis is defaulted to ‘A’
(360/360).
Page 28 | 84
o If Interest Calc. Method is Flat and Payment Type is Constant Weekly or Constant Bi-Weekly, Day Basis
is defaulted to ‘G’ (366/364).
o If Payment Type is Constant Quarterly or Constant Half-Yearly, then Interest Calc. Method Flat is not
allowed.
o If Interest Calc. Method is Reducing Balance, Day Basis is defaulted to ‘E’ (366/365) and interest
calculated based on outstanding loan balance (CURACCOUNT)
o Interest on Flat loans is calculated based on original commitment amount (TOTCOMMITMENT).
• Select the option to indicate how, during interest accrual, the system should determine which amounts to
include in each day's balance, the actual days to include in the period (e.g. first day, last day or Both)
• If applicable, enter the maximum loan balance for which interest will not be calculated.
• If applicable, enter the minimum interest amount to be posted for a contract. If the calculated interest amount
is less than the amount specified in this field, system will waive or adjust the interest amount, as per the setting
below.
• If applicable, click on the checkbox to indicate if the calculated interest amount has to be waived or adjusted.
If enabled, it means that where the calculated interest amount goes below minimum interest amount set,
should the system waive the interest amount and post the minimum amount.
Interest types
Periodic Rate
• To define periodic interest, Select the periodic Index - a periodic rate is tied to an index (For example:
EURIBOR) which is dependent on a period of time (For example: term) and possibly an amount. Periodic
interest is defined in table PERIODIC.INTEREST. Periodic method is the interest selection method used if the
term is not found on the index. Interpolate is the default setting in FI.
• Margin Operand and Rate - This indicates whether the Rate should be added or subtracted from the Periodic
Rate. The Margin Rate allows to define the margin rate that can be used to adjust the specified rate of
interest. The result is the nominal rate of interest
Page 29 | 84
Fixed Interest
To define fixed interest, enter the fixed rate and specify whether the rate is negotiable or not.
Floating Interest
• Floating Index – the variable base rate as defined in BASIC.INTEREST. During interest calculations, the
system uses the currency specific rate applicable for the calculation date (the rate used for the calculation
changes whenever the base rate is changed).
• Margin Operand and Rate - This indicates whether the Rate should be added or subtracted from the Floating
or Periodic Rate. The Margin Rate allows to define the margin rate that can be used to adjust the specified
rate of interest. The result is the nominal rate of interest
Mixed / Tiered Interest
• When set to Mixed/Tiered rate type, the core Interest parameters (AA.PRD.DES.INTEREST) is invoked upon
committing the stage.
Example: 10 percent fixed rate applied on the 50% of the loan and a variable interest applied on the other 50%
Page 30 | 84
Penalty Interest Stage

Penalty Interest parameters are defined in this stage as follows
• Define whether penalty interest is to be calculated on arrear repayments.
• Next, select an existing penalty condition, or create a new condition.
• Enter the name of the penalty interest condition. In the example below, the condition TwoPercent, which
represents 2% pa penalty interest, would be created.
• On the Basic Details tab, select one of the options to indicate if penalty interest should be calculated using a
fixed rate or a floating rate.
• Next, select the interest day basis from the drop-down list and also, whether penalty interest will be calculated
on the actual days in the period, for example first day, last day or both.
• Enter the fixed rate or the float rate details in the respective tab.
Charge Selection Stage

In this stage, charges applicable to the product are selected.
Page 31 | 84
Select from the dropdown list the option to indicate whether the same charge condition should be defined for all
currencies available for the product. Options are:
1. Yes – A default charge condition should be created for all Currencies defined for the product.
2. No – Separate charge conditions should be defined for each currency of the product
3. Not applicable – Select this option if the charge does not apply to the product.
Charge Definition Stage

In this stage, specific product charges are defined as follow.
Click on one of the options to specify if the charge should be applied as a result of an activity, breaking of a
restriction or should attached to the repayment schedule.
Activity Charge
If the Activity option is selected, the Linked Activity fields opens up for input. Select from the dropdown list the
activity to which the charge applies to. Options are
1. Disbursement
2. Missed payment
3. New arrangement
4. Payoff
5. Principal Decrease
Page 32 | 84
Restriction Charge
• If the restriction option is selected, select from the drop-down list the restriction which when broken will trigger
the charge. Options are
1. Early Loan Payoff after cooling off period
2. Principal decrease count in Period
3. Principal decrease tolerance
4. Principal decrease total in period
5. Principal decrease within
• If a period-based restriction is selected, e.g. Principal Decrease Count in Period, enter the period. Accepted
values are nnM or nnY or nnD or nnW.
• Enter the number of transactions to be evaluated in the restriction within the given period.
• If the restriction is amount based, provide the value to be evaluated within the given period. Restriction count
and Restriction value are mutually exclusive.
Schedule Charge
If a scheduled charge is to be defined, selected from the calendar the frequency of charge collection. The
charge will be added to the loan repayment schedule on the frequency defined. An example of a scheduled
charge is the Maintenance charge.
Charge Calculation
• Click on the option to indicate whether the charge is fixed or calculated. If a fixed charge, provide the Charge
amount in the charge amount field.
Page 33 | 84
• If calculated, additional information is required as described below. Select one of the following as the basis for
the calculated charge.
1. Current principal (CURACCOUNT)
2. Loan Amount (TOTCOMMITMENT)
3. Overdue Principal (TOTALOVERDUE)
• Next, enter the Charge calculation rate and indicate whether the rate is negotiable or not.
Settlement Stage
Settlement Parameters are defined in this stage as follows.
Payout
• Specify if contracts opened under the product should be automatically disbursed.
• Disbursal Category - In the event of loans being automatically disbursed to another customer account held
within the institution, define the category code of that account. The system will validate that the borrower has
an open/active account of this category code. This is for automatic disbursement only, where the borrower
does not wish to draw from the loan arrangement itself.
Page 34 | 84
Repayment Collection
• Specify if repayments are to be collected from a designated account on the due date and whether automatic
repayments may be negotiated on arrangement creation stage.
• Specify how the system should treat funds available in the repayment account, for example when the
account holds an available balance, less than what is to be collected. Options are
1. Full – The amounts due will be deducted from repayment account even if the account becomes
overdrawn.
2. None – If the repayment account does not hold enough funds to cover the due amount, settlement
will not be attempted.
3. Partial – The repayment amount due will be deducted from the repayment account only to the
extent of the available balance. In Financial Inclusion, we defined automatic retrial of settlement
where the system checks during Close of Business and collects additional funds that become
available in the repayment account until the amount due is fully settled. This is done by the
Transaction cycler function of T24 Transact. For further information, please refer to the Transaction
Cycler user guide.
Note: The system does not make use blocked Initial deposit amounts for automatic settlement of loans.
• Repayment Category - In the event of loans being automatically repaid from another account held with the
institution, the category code of that account should be defined here. The system will validate that the
borrower has an open/active account of this category code. This is for automatic repayment only, where
the borrower does not wish to deposit the loan repayment funds into the loan arrangement itself.
Page 35 | 84
Charge Collection
Select yes or no to indicate if charge collection rules are to be the same as repayment collection rules, i.e. to be
collected from a designated account on the due date. If the option No is selected, then change collection parameters
should be defined similar to repayment collection.
Overdue Stage
Overdue Parameters are defined in this stage as follows.
Basic Details
Indicate whether overdue processing will follow number of days or number of number of overdue payments (bills).
Also indicate whether only bills repaid in full are to be considered as settled.
Grace Period
• In the Basic Details, it was decided whether to follow number of days or number of overdue payments (bills).
Now, indicate here when the bill which is due is to be moved to grace status.
Page 36 | 84
• During grace status penalty interest is accrued but not posted, should the borrower pay before the end of the
grace period. Enter ‘0’ if Grace period does not apply for your institution. On the Grace Notice Days field, enter
the number of days after entering grace status until a chaser/advice is to be sent to the borrower. Finally,
define how often a chaser/advice is to be sent to the borrower during the grace status.
Delinquent Period
• Indicate here when the bill which is due is to be moved to delinquent status. Penalty interest accrued will then
be applied. Indicate the number of days after the loan has entered delinquent status that the system should
generate the chaser/advice. Finally, define how often a chaser/advice is to be sent to the borrower during the
delinquent status.
Non-Accrual Basis
• Indicate the number of days since the bill has gone into arrears when the loan is to be moved to ‘Non-Accrual’
status. The calculation of penalty interest will then be suspended. Indicate how many days after entering Non-
Accrual status until a chaser/advice is to be sent to the borrower. Finally, define how often a chaser/advice is
to be sent to the borrower during the Non-Accrual status.
The three most common arrears status are predefined in Financial Inclusion. Additional statuses may be defined in
AA. For more information, please refer to the AA Property Classes user guide.
Payoff / Closure Stage

Payoff and Closure conditions are defined at this stage as follows.
• A payoff activity is executed whenever a client wishes to pay off their loan and close the contract ahead of the
maturity date. Specify the number of days after which a payoff bill expires.
• Indicate whether all amounts due prior to the payoff date should be considered as settled or not.
Page 37 | 84
On the closure tab,

• Select the closure method for arrangements of this product. Options are Manual or Automatic.
• Indicate whether automatic closure is to take place based on contract balance (being zero) or on maturity date.
• Provide the number of days after which the closure action is to be triggered on arrangements where the
automatic closure is based on maturity date.
• Select the ‘posting restriction’ to be applied to the account when the automatic closure is being processed.
For more information, please refer to the AA Property Classes user guide.
Eligibility Stage
Product eligibility conditions are defined at this stage.
First, indicate whether the product is meant for Individual or Non-individual customers. Eligibility requirements for
individual loans differ from those of businesses and entities (Non-individual customers). Certain eligibility
parameters are dynamically enabled based on the customer type selection. At least one restriction must be defined
for the product.
Customer Restrictions
• If borrowers of this product must be of a minimum age, enter that age.
Should a particular borrower not meet the product condition, what type of a message should be displayed?
Note: Breakage action must be defined for all eligibility conditions applicable to the product as described below
• If borrowers of this product must be of a maximum age, enter that age
Page 38 | 84
• If the product is restricted by gender, Select one of the options from the lookup list. Options are Male, Female
and Other (Non Individual)
• If borrowers of the product must be residents of a particular country, select the applicable Country from the
lookup list
• If borrowers of this product must be nationalities of a particular country, select the applicable Country from the
lookup list
• Indicate which classification type(s) of customer may make use this product.
1. Full Member
2. Non Member
3. Non-voting Member
4. Provisional/Pending Member
5. Resigned Member
6. Resigned
7. Deceased
• If borrowers of the product must be of a particular profession, select the applicable profession from the lookup
list. The list of profession is maintained in System Parameters >>Customers>>Customer Tables>>Education
Level. If the product relates to all professions, leave this field blank
Page 39 | 84
Period Restrictions
• Enter the minimum number of months that a customer must be a member of your institution before they can
make use of this product if relevant, else leave blank
• Enter the minimum number of months that a customer must have a savings account in operation with your
institution before being able to make use of this product. leave blank if not applicable
Category codes to be evaluated for savings months are maintained in Product Parameters > Loan Products >
Product Builder Parameters > Global Product Parameters
Initial Deposit
The initial deposit functionality automatically blocks a predefined amount of funds in the customer’s saving’s
account, as a requirement to avail a certain loan product.A multi-value fields is available to define the initial deposit
parameters for each currency of the product as follows.
• The amount of savings that a borrower is required to have before availing a loan under this product. The
system will automatically block the savings value as defined on the product. The block is applied by using
the AC.LOCKED.EVENTS functionality. Please refer to the Accounts user guide for more details. The
system will automatically block the savings value as defined on the product until the loan is settled, or the
block is manually released
Categories to be evaluated for initial deposit are maintained in Product Parameters >>Loan
Products>>Product Builder Parameters>>Global Product Parameters.
• If the initial deposit should be a percentage of the loan amount applied for, indicate the rate. However,
unlike the Deposit Amount field which does not reduce in line with outstanding (current and overdue)
principal balance, the initial deposit amount blocked based on the percentage entered on this field will
reduce if the field Progressive Release is set to Yes.
• Specify if accounts with different currency than product currency are allowed for initial deposit calculation.
• Specify the breakage action when initial deposit requirement is not met.
• Progressive Release - If the deposit amount blocked based on the Deposit Percentage field above should
be released in line with the outstanding (current and overdue) principal balance, then this field should be
set to Yes. For example, if a loan amount of USD1000 is approved and 10 percent (USD100) is initially
blocked in a customer’s indicated account, the amount blocked will be automatically reduced to USD90
when the customer makes a payment of USD100 on the loan thereby reducing the outstanding balance to
USD900.
Page 40 | 84
In summary, for this example, the amount of deposit blocked will be equivalent to 10 percent of the
outstanding balance of the loan at any time during the life of the loan.
• If breakage action for the initial deposit requirement is set to override, it is possible to further define whether
or not partial blocking is allowed. This means that available funds in the account with the greatest balance
are blocked.
• Increase ofn Funds Availability - If Partial Blocking Allowed field is set to Yes, then this field allows a user
to specify whether or not additional funds should be blocked (up to the maximum required) when more
funds become available in the indicated initial deposit account.
• Apply New Percentage for – This option defines what should happen in the case that the initial deposit
percentage is changed on this table while loans exist in the system. Should the new percentage apply to
both new and existing loans or should it apply to new loans only? Select the option applicable to the product.
Lending Restrictions
• If the product is restricted to certain purposes, select the loan purpose code from the lookup list. Loan purpose
codes are maintained under General Menu >Administrator >System Tables >Loan Purpose. This is a multi-
value field. If the product relates to ALL loan purposes, then leave this blank.
Page 41 | 84
• If the product is restricted to certain Sources of Funds, select the Fund ID from the lookup list. Source of Fund
codes are maintained in General Menu > Administrator > System Tables > Source of Funds.
• Enter the maximum number of active loans allowed per customer under this product.
• If applicable, select the application status that should be automatically set on loan application in case any
eligibility check failed with error during auto approval.
• Select any other eligibility checks that may apply to your product. Below are the options available and sample
settings.
Check Type = Allow top-up
Check param = YES / NO
Check Type = Allow reschedule
Check param = YES / NO
Page 42 | 84
Check Type = MAX.TOPUP.COUNT
Check param = 2
Check Type = MAX.RESCHEDULE.COUNT
Check param = 1
Check Type = MIN.TOPUP.AMOUNT
Check Param = EUR-500 (product currency followed by numeric value)
Check Param = GBP-400
Check Type = MAX.TOPUP.AMOUNT
Check Param = EUR-10000
Check Param = GBP-5000
Channels
Product availablity channels, including brokers and solicitors are selected on the Channel tab.
If, for example, Internet is not defined as once of the product access channels, the product will not be visible for
application on the internet banking.
Please refer to the Intermediaries user guide for more information on the broker channel and the Agency user
guides for broker commissions.
Eligibility conditions in FI are defined and maintained in a local file EM.PRDL.ELIGIBILITY and these definitions do
not update the core product builder (AA.PRD.DES.ELIGIBILITY). As such, eligibility conditions may be updated
directly through Product Parameters > Loan Products > Eligibility Settings without the need to proof and publish
the product.
Page 43 | 84
Product review stage

Once all product conditions are completed, the product builder next presents a product review stage where the
parameters defined may be reviewed by the approving officer as defined in AA Product Builder > Product Builder
Parameters > Loan Product Build Stage Owners
To review the product settings, click on the Setup details link
Once satisfied with the product settings, the product may be proofed and published.
Page 44 | 84
Some settings may be amended during the product review stage. The product build status can be seen in
AA Product Builder > Products
To amend any of the stages, click on the icon to input the changes. To continue the product build after
successful product review, click on the icon to continue on to the proof and publish stages. When complete,
the publish stage will be updated with an activity status of process complete. The product together with all defined
product conditions are now created in AA.
To change details of an existing AA product

The product builder is only used to build new products and thereafter, the product is maintained directly in AA. This
means that changes to any of the property classes and/or product conditions are to be made using the AA Core
product builder which is available under Product Parameters > AA Products > AA Core Configuration.
For example, to change the Term and Amount conditions of a product;
1. Click on All in One RBHP>Product Parameters>AA Products>AA Core Configuration.

2. Click on Term Amount Property Class>>your product condition and edit the relevant attribute.
3. Proof and publish the product.
To change the Eligibility conditions:
1. Click on …Product parameters > Loan Products > Edit Eligibility Settings.
2. Enter the product name to access existing conditions.
3. Make amendments as necessary and commit the record.
4. Once authorized, the product is updated with the new eligibility conditions
To change the Settlement Categories:
1. Click on …Product parameters > Loan Products > Edit Settlement Settings.
4. Once authorized, the product is updated with the new settlement conditions
To change the Limit Conditions:
1. Click on …Product Parameters > Loan Products > Edit Limit Settings.
4. Once authorized, the product is updated with the new limit conditions
Page 45 | 84
Output for Loans Product Builder Wizard
Loan product Overview

The Loan Product Overview provides a summary of the loan product and it’s product conditions defined through
the wizard. The summary is also available at the last stage of the product wizard (product review stage) which
helps with verification of the product designed by an approver, before proof and publishing. The summary report
can be accessed through the list of products as shown below.
Access
Product parameters > Loan Products > AA Loan products
On clicking the drilldown icon, the product overview summary displays as below.
Page 46 | 84
Page 47 | 84
Direct Loan Input

Introduction
This application provides a simple input screen where loan details such Borrower details, Product requested, Amount
requested and Term requested etc. are entered and upon authorization, loan arrangement records are automatically
generated. It also provides functionality to create all Group members’ loans from a single screen. In addition to the
loan details, Joint customers, Guarantors and Collateral may be attached to the loan. A loan agreement document
is generated for the customer to acknowledge the loan details as entered in the system. Limits are automatically
created by the direct loan input application and both individual and group loans may be automatically disbursed.
Configuring Direct Loan Input

The loan product set up must be completed first before using the Direct Loan input application to create new
arrangements. Similarly, if the Collateral, Guarantor functionality is to be used, the parameter table must be set
first. Please refer to the respective user guides on how to set them up.
Group Management set up must be completed where group loans are to be created using the Direct Loan.
Working with Direct Loan Input

This section describes the Direct Loan application in detail
Access
Loans AA > Loan > New Loan or Single Customer View > Loans > New Loan
Loan Input
Page 48 | 84
Field name Description

Loan Input ID The system generates the next available reference number, the format is DL
(application code) followed by the Julian date (80th day of the year 2019) followed by
a 5-digit sequential number.
Input Date The loan value date is defaulted to current system date and can be changed if required.
Customer Type Click on the option to indicate whether the loan is being created for an Individual, Non-
Individual or Group. The three Customer Type options are mutually exclusive. If Group
is selected, then the system hides Customer Id and if Individual / Non-Individual is
selected, the system hides Group Id. Similarly, the tab “Group Application Details” will
be hidden if non-group customer type is selected.
Note: If customer type is set to Individual yet the customer is linked to a group, such
a loan is treated as an individual loan and excluded from all group loan reports. To
create a loan for one or few group members, select group customer type and maintain
only the current borrowers on the group application details tab.
Customer As individual / Non-Individual was selected in the Customer Type field (above) the
system requires you to enter the Customer ID and on entering the code, the customer’s
last name displays as enrichment characters to the field. Validate that you are working
with the correct customer record.
Asset Class This is a no-input information-only field indicating the worst classification of the
customer from all his or her existing loans.
Loan Action Select New Loan to indicate new loan creation. Reschedule and Top up actions are
described in the Loan Maintenance section of this guide.
Loan Product Select the product code from the lookup table. The value entered in this field will
manage the values entered in the subsequent fields.
Amount requested The amount that the customer wishes to borrow.
Term Requested The repayment term. Valid input is 12W, 3M, 2Y.
Payment Frequency The repayment frequency is populated from the product where the conditions have
been defined.
Repayment Start Date The default is the automatically set as the input date plus the payment frequency.
Enter the desired repayment start date if different from the default date.
Currency The currency populates from the product. If a multi-currency product, the field is left
blank for the user to select the relevant currency, from the list of currencies linked to
the product.
Interest Rate The interest rate populates from the product. If the product is set to allow negotiation
of the interest rate or margin, the interest rate and Margin rate fields are set as
editable. Any amendments on the defaulted values are validated against the product
negotiation rules.
Instalment Amount The system calculates and displays the repayment amount for information purposes.
The instalment may be adjusted to suit the customer’s requirements e.g. Round off to
the nearest 100 value. In such a case, the system accepts the requested instalment
amount and automatically recalculates the term requested.
And then on day Select the desired loan repayment date during the month, if the system-generated date
is not suitable for the customer. For example, customers may wish to match they loan
repayment date with the salary payment date.
Applicable to Monthly instalment loans only.
Source of Funds Select the source of funds from the lookup table
Page 49 | 84
Loan Purpose Select the loan purpose from the lookup table.
Loan Reason This is a free-format input field for you to capture any other relevant information.
Notes Capture any other relevant information in this area.
Settlement

Disburse Account The loan disbursement account is defaulted here as per the product settings. Amend
suitably to negotiate the disbursement settlement Account / conditions.
BENEFICIARY can also be selected from the list, where funds are to be disbursed to
an external account.
The New Payee link may be used to create a new Beneficiary record for the customer.
Repay Account The loan repayment account is defaulted here as per the product settings. Amend
suitable to negotiate the settlement account / conditions
Charge Account The charge settlement account is defaulted here as per the product settings. Amend
suitable to negotiate the settlement conditions
Joint Customers

Joint Customer ID If joint customer is relevant to the loan being processed, enter the
customer number of the joint customer/s and the system will populate
the fields below from the data as captured on the relevant customer files:
Joint Customer Name The name of the joint customer
Page 50 | 84
Joint Customer Address The address details in the multi-value set of fields
Joint Customer Date of Birth The date of birth
Joint Customer Identification ID number of the joint customer. The data is displayed for you to verify
that you have entered/selected the correct joint customer number. This
customer will be jointly responsible for the loan and the terms and
conditions thereof.
Guarantor Input
Guarantors may be linked to the loan. With a multi-value field linked to both the customer table and the guarantor
table, existing customers of the institution may be selected as guarantors or non-customers could be created as
guarantors in the guarantor table and thereafter selected as guarantors.
In the screen below, guarantor Ids starting with a “G” digit were created on the guarantors table and those with
six digits are records from the Customer Information File.

Guarantor ID Select the Guarantor ID from the look up table, which contains both records from the
Live Customer and Guarantor tables.
The New Guarantor link may be used to access the guarantor table and create new
external guarantors if not already existing.
Account If the guarantor is a customer of the institution, select the account to be blocked as
security for the loan from the lookup table.
The AC.LOCKED.EVENTS table is then updated with the amount blocked as well as the
expiry date (maturity date of the loan) so that the block may be released when the loan
is fully repaid or reversed.
Whether or not the guarantor account is mandatory is defined in the Guarantor
Parameters application. For more details see the Guarantor Management User guide.
Amount Enter the amount of the guarantee provided. If the value entered is greater than the
available balance on the (above) account, the break rule message will be displayed and
depending on how the parameter has been defined, the user will be able to proceed or
not.
No validation is carried out on the amounts entered where the Guarantor is not a
customer and does not hold an account in your institution.
Document
Use the scan icon to take an image of the document as evidence of the pledge
over the item offered as collateral. Else, if the image already exists, select the Document
ID from the lookup table.
A field has been provided in the IM.DOCUMENT.IMAGE application to store the Loan
Account number.
Page 51 | 84
Collateral Input
Collateral details may be entered optionally on this tab, as described below.

Applicant’s Pull down on the lookup field and select an existing collateral right record for the application.
Collateral Id Only collaterals created for the loan borrower will be displayed.
The New Collateral link may be used to create new collateral records for the borrower. The
Collateral Right is created first and then the Collateral Items, as shown in the screenshot below.
The collateral right is linked to the Limit and /or Arrangement automatically when the
arrangement is created automatically by the system.
Please refer to Collaterals user guide for more information.

In the case of group loans, all existing collaterals for all group members will be displayed for
selection. Since collaterals bear the customer number in its Id, it is easy to identify which group
member has what collateral record.
Guarantor’s If an internal guarantor (Transact Customer), pull down on the lookup field and select an
Collateral id existing collateral record for the application.
Use Existing Select the option to indicated whether an existing limit is to be used or a new one created for
Limit? the loan. By default, FI is configured to automatically generate a Limit record for every loan,
where Limits are enabled in the product. However, it is possible to override this functionality at
loan creation, by reusing an existing limit instead of having a new limit created for the loan.
Limit ID Select the limit from the drop-down list. A new limit may be created using the New Limit link.
Page 52 | 84
Group Application Details

If the application is for group loans, then the Group Application Details tab is activated and its multi-value set of
fields are auto-populated by the system as follows.

Group Member The system populates this field with the customer number of each group member
Amount Requested The system divides the amount requested by the number of group members evenly
and allows changes as may be necessary. At all times, the system ensures that the
total amount requested tallies with the individual group member amounts.
Term Requested The system defaults the term requested for each member of the group and allows
changes as may be necessary.
Instalment Based on amount requested and repayment term, the system calculates the instalment
amount for each member of the group and defaults it on this field.
Authorization of records
Once the Direct Loan record is committed successfully, the record is held in the unauthorized records file waiting
to be authorized. Unauthorized records can be accessed through the Pending records enquiry on the AA Loans main
page, in the Single Customer View or through Task Management on the Dashboard.
Outputs for Loan Creation

Credit Agreement
After loan creation, the system automatically generates a Credit Agreement. The document is produced in PDF
format and stored in each customer’s document repository for printing (re-printing) and dispatch, even e-mailed to
customers as necessary. The standard template should be amended suitably during implementation in order to
meet the requirements of the institution.
Access
Single Customer View > Documents > System Documents
Page 53 | 84
Note: The APR is calculated and displayed in the Loan Agreement document.
What is APR?
APR is an abbreviation of Annual Percentage Rate. It is a percentage number that calculates how much it will cost
for the loan over the period of a year, including interest and any additional costs such as admin fees.
The most important thing to remember about APR is that it’s an annual rate. It measures the cost of borrowing
money for a period of 12 months, significantly longer than the period of a short-term loan.
If the loan were longer than 12 months, APR would be calculated by adding up the total interest and fees and then
dividing to create a yearly average. When the loan is less than 12 months, the total cost is multiplied to give an
average for the year.
This means that APRs for short term loans are usually much higher than APRs for loans that stretch for longer than
12 months.
In Financial Inclusion, the formula explained here is used for APR calculation:
https://www.handbook.fca.org.uk/handbook/MCOB/10/3.html
Please note that there is no interest rate in this formula, it is based entirely on the drawdown / instalment amounts
and periods between them. I.e. the APR can be calculated even when the interest rate is not known at all.
Page 54 | 84
Loan Disbursements
Introduction
Loans may be disbursed automatically upon authorisation, if the Schedule and Settlement conditions are set as so,
or manually through Cash, Cheque or Account transfer.
Please refer to the Loan Product builder Section of this user guide for more information on Schedule and Settlement
Parameters.
Loans can be disbursed individually for each customer or in bulk for borrowers belonging to the same Customer
Group.
Working with Individual Loan Disbursement

Access
Teller > Loan Operations > Disbursement or Single Customer View > Loans > Loan Operations.
Loans may be disbursed in Cash, Cheque, Internal Transfer or External Transfers
Click on the to access the loan operations page.
Please read the Teller user guide for more details on how to input Cash, Cheque and Customer transfer
transactions.
Page 55 | 84
Group Disbursement
In Financial Inclusion, we provide the functionality whereby loans belonging to members of the same group can be
disbursed from a single screen.
Access
RBHP > Teller > Operations > Group Disbursement

Group ID The group ID where the borrowers belong is displayed
Group Name The name of the group where the borrowers belong.
Disburse Select Yes or No. Only rows marked as yes for disburse will be processed.
Disb Account The system first checks if a settlement account category was defined in the loan product
and defaults that account on this field. If not defined, the account is defaulted based
on category codes found in the Allowed Credit Categories field in the Group Bulk
Payments parameter table. The defaulted account can be changed by pulling down to
select another account of the customer. A Nostro or internal account may also be
entered on this field if the category code is defined in the Group Bulk Payments
parameter table (EM.FT.BULK.PARAM)
Page 56 | 84
If the credit account entered here belongs to another customer (such as the group
account), an override message is displayed for acceptance.
Please refer to the Group Management user guide for more information.
Amount Enter the amount disbursed. The screen defaults ‘undisbursed’ commitment balances
for every loan per member. Enter Zero “0” to skip any loans of the customer not to be
disbursed yet or a different amount for partial disbursement.
Total Amount On verifying the record, the Total amount of loans to be processed is defaulted.
Completed disbursements
This enquiry displays the results after processing the Bulk FT records by OFS. Applicable statuses are,
1. Processed Successfully
2. Partially processed
3. Failed
Click on the icon to see the status of individual FT records and correct any that failed to process. The Group
Disbursement Details enquiry will display results as follows,
The status of each FT is shown on the enquiry. In case of failed transactions, click on the icon to correct
the problematic entries and commit the record to resubmit the FT.
Page 57 | 84
Outputs for Loan Disbursement

Extended Loan Repayment Schedule
The extended loan repayment schedule is available for every loan created in Financial Inclusion. This report is
particularly useful in tracking the loan repayment schedule and repayment progress. Expected payments owing are
clearly marked as unpaid while partially paid instalments are flagged as so. The report provides a full break down
of items dues, paid and unpaid, with arrears tracking for each instalment due.
Access
All in One RBHP > Single Customer View > Loans or All in One RBHP > Loans
Click on the icon to drill down to the extended loan repayment.
Loan Repayment Operations

Introduction
During the life of an arrangement, a number of repayment operations may take place. These include,
1. Regular repayment on the instalment due date

2. Prepayment to reduce the outstanding loan amount (principal decrease)
3. Advance payment where the funds are to be applied on upcoming instalments (Credit arrangements)
4. Payoff i.e. pre-closure of arrangements before final maturity date.
Repayment operations can be performed separately for individual Customers or in Bulk for members of the same
Group.
Page 58 | 84
In the Financial Inclusion, we provide functionality for processing group repayments from a single screen. This
functionality may be used where group repayments are to be entered directly into the system manually. The group
collections screen is controlled by the configuration defined in the next section.
Configuring Loan Repayment Operations
Group Bulk Payments Parameters

Using this table, parameters may be defined for various repayment types to be supported by the Group collections
screen i.e. Regular payment, Savings, Principal decrease, Credit arrangement and Payoff.
Access
All in One RBHP > System Parameters > Customer Tables > Group Tables > Group Bulk Payments Parameters

Bulk Type Enter GCS (Group Collection Screen) for repayments.
Default FT OFS FUNDS.TRANSFER,EM.GCS.BULK.OFS is the default version used to process the
Version individual FT payments using OFS.
Default Process Select Yes or No as the default process value for line items in the Group collection
Value sheet. Only items marked as Yes are processed when the Group collection is
authorised. If Yes is set as the default, line items to be skipped will need to be marked
as No at deal processing and vice versa.
Page 59 | 84
Payment Type Enter the payment type to be configured in the current multi-value set of fields. All the
payment types defined in this table will be available in a lookup list of payment type in
the Group collection sheet.
Transaction Type Enter the FT.TXN.TYPE.CONDITION code to be used for this payment type.
Default Payment If Yes is selected, the repayment type defined here will be auto populated for every
Type Name? member of the group. If No is selected, this repayment type will not be displayed but
will be available in the lookup list for selection.
Allowed Credit Enter valid category codes here. Customers’ accounts of the category codes defined
Categories here will be filtered and made available on a lookup list for selection as the repayment
Account, i.e. the Account to be credited with the repayment funds.
Default Credit Select one of the options available.
Account?
1. Yes – The first Account of the Customer on the allowed Credit categories will be
defaulted as the Credit Account.
2. No - Credit Account will not be defaulted but will be selected from the lookup list.
3. Loan – Select this option for Loan repayment payment type so that all the Loan
accounts of the customers are displayed on the Screen.
Default Loan If Yes is selected, the total amount due will be prepopulated on the amount field. You
Repayment only need to compare the amount with the actual repayment and amend according if
Amount? the customer paid a different amount. If No is selected, amounts due will not be
prepopulated.
FT OFS Version If the institution uses a different version other than the Default OFS version defined
by Temenos, enter the FT version here.
Working with Loan Repayment Operations

Manual repayment operations may be carried out at any time during the life of a loan arrangement. The following
repayment operations are preconfigured in Financial Inclusion.
• Regular repayment
• Principal Decrease
• Credit Arrangement
• Payoff
Repayment Operations - Individual

The repayment operations can be in form of Cash, Cheque or Internal/External Transfer.
Access
All in One RBHP >Teller > Loan Operations > Repayment or Single Customer View > Loans > Loan Operations
To repay in Cash, enter the repayment amount and commit the transaction. If in excess of the due amount, the
system will apply the balances as per the remainder rules defined in the Payment rules conditions of the product.
To repay by Cheque, enter the cheque amount and the required cheque details and commit the transaction. The
corresponding entry is posted to the first NOSTRO account defined in the AGENCY application.
To repay by account transfer, enter the repayment amount, the account to be debited, and commit the record.
Page 60 | 84
Please read the Teller user guide for more details on how to input Cash, Cheque and Customer transfer
transactions.
Note: The input screens are similar in nature for all the repayments operations types. The only differentiating
factor is the TELLER.TRANSACTION or FT.TXN.TYPE.CONDITION codes defined on for the screen and mapped to
AA activities in ACTIVITY MAPPING property class. Please refer to the Retails Loans user guide for more information
on Activity Mapping.
Group Collections Screen

This is the screen used to record group repayments.
Access
RBHP >Teller >Loan Operations >Group Collection or Single Group View > Group Operations >Group Collection

Group ID Enter the Group ID for whom repayments to the loans are to be processed. All members
of the group will be displayed on the screen.
Group Name Displays the name of the Group.
Processing Date Enter the processing date of the payment.
Page 61 | 84
Process Select No to skip a particular Customer. Line items marked as Yes will be validated for
processing.
Customer No. The Customer ID of the group member.
Customer full name The full name of the group member.
Attendance Select member’s attendance status from the pop-up list
Payment Type The payment type as defined in the Group Bulk Payments parameters table. Expand the
sub-value field to add more payment items if applicable.
Payment Account The Loan account or Savings account to be Credited with the repayment funds.
Amount The amount paid by the customer. For Loan, the total amount due is defaulted here so
no input is required if the customer pays full amount.
Group Dr Acc The Group Account is defaulted here. In the Financial Inclusion, each group should have
a linked Group Account where the Bulk Group Repayment is deposited. An Internal
(Wash) Account may also be used as a Group Account. Group collections are then
processed against the deposit in the group account. Please refer to the Group
Management user guide for more information on Groups Accounts.
Control Total Enter the total Deposit Amount made by the group, as held in the group account, to
validate against the line items.
Payment Ref No. Enter the Payment Reference Number is applicable.
After the Group collection is authorized,
1. Review the processed records as shown in the Completed Group Collections screen.
Hint: The TSM service should be running in AUTO mode for the records to be processed.
2. In case of the transaction failing, click on the icon to access the Group Collection details screen and
review failed transactions.
3. Click on the icon to correct the errors and resubmit the FT record.
Loan Top-up and Rescheduling

Introduction
In Financial Inclusion, Principal increase (Top-Up) and change in loan duration activities may be processed using
the Direct Loan input screen as described below.
Configuring Loan Top-up and Rescheduling

There following parameters defined in the Global Product Parameters (EM.PRODUCT.PARAMETERS) affect the
behavior of the Loan Top Up and rescheduling functionality in Financial Inclusion.
Page 62 | 84
Term Input Type

This parameter determines how the term is set for Top-up and Reschedule initiated from Loan Origination or Direct
Loan. For example, assume a loan that was created on 1st January is rescheduled on 15th February with new term
being 6 months.
“Amend Original Term” – new term is set from loan start date (1st Jan) i.e. new maturity date will be 1st July
“Define From Today” – new term is set from reschedule date i.e. new maturity date will be 15th August
Start Date Source
This is the repayment start date for Top-up and Reschedule initiated from Loan Origination or Direct Loan.Unlike
term input type, “Start Date Source” affects repayment dates only. For example, a loan created on 1st January,
rescheduled on 15th February, repaid monthly and empty START.DATE (i.e. repayments happen on 1st day of each
month).
“Contract Next Due Date” – next payment date after reschedule is not changed i.e. it remains as 1st March
“Product” option – next payment day after reschedule is derived from payment schedule condition. START.DATE
is empty so first repayment should happen after 1 month i.e. next repayment date after reschedule becomes 15th
March
“Start date source” affects repayment dates only while “Term Input Type” affects term.
Term as Number of Payments
With this setting enabled, term is always defined based on term defined for the loan. For example, if moratorium is
given initially and therefore the first repayment date is expected much later. For example, a customer applies for a
12 months loan and requests a 3 months grace period before the first repayment. Therefore the maturity date will
be calculated as three months plus term defined (15 months).
Page 63 | 84
Working with Loan Top-up and Rescheduling

Access
All in One RBHP > Loans > New Loans or Single Customer View >Loans >New Loan
Top-Up and Reschedule Input

To create a loan Top Up using Direct Loan screen,
• Click on the New Loan icon to start a new record.

• Select the loan action as Top Up or Reschedule.
• Next, a new field “For Arrangement” is displayed for the user to select the loan to be amended from the
look up list. The system lists only the loans that were previously created using Direct Loan Input. Loans
created using Loan Origination are to be amended using a similar input screen in the Loan origination
Module.
• Enter the top up amount requested by the customer.
• Enter the new repayment term requested for reschedule operation, and optionally for Top up. For example,
If the initial loan was payable in 6M and the customer requests for a 3M extension with the Top-up, enter
9M on this field. Leave the field as blank if no Term change is requested.
• Enter any other relevant information and commit the record.
Page 64 | 84
Arrears Management
Introduction
When loan obligations are not met, the arrears management application takes these loans through different risk
statuses that are configurable by users. Flexibility is built in to define risk classes based on number of days late or
number of unpaid schedules. The institution is able to define whether or not interest should be earned or suspended
for each risk class. When overdue loans are paid, the system automatically recovers these and allocates the amount
paid to the various outstanding amount types as predefined by the institution. Reports are provided to show loans
at risk, their statuses and amounts provisioned to date for such loans.
Configuring Arrears Management

Please read the following user guides for further information on Arrears configuration and parameters.
Overdue Property Class
Overdue Configuration
Working with Arrears Management
Please read the following user guide for further information on how the system deals with arrears.
Working with Arrears
Outputs for Arrears Management

Outstanding Payments Due
This enquiry displays arrears details such as the installment in arrears, the expected payment date, the number of
days in arrears and the amount due per instalment component.
Page 65 | 84
Access
All in One RBHP > Loans>Arrears/Provisioning > Arrears
Provisioning
Introduction
The aging and calculation of provisioning for loan arrangements are done using the
PV (Provisioning) module with limited functionality supporting Impairment from the IFRS regulations
module. Details relating to the functionality provided by the PV module are obtainable in the Provisioning user
guide. The discussion here is an overview only and is intended to introduce the user to the tables used
by the system in the process of provisioning.
Though the Provisioning module supports both Standard Provisioning and IFRS, this material describes
only the Standard Provisioning method. For details on how to setup and use the IFRS approach, please refer to
the Provisioning user guide.
Application Name Description

PV.LOAN.CLASSIFICATION Unpaid loans are classified into various risk classes according to the perception
of the institution. This table supports the various classes the institution wishes to
take unpaid loans through within the life of the loan. The standard risk classes
in the Financial Inclusion Model Bank are as follows (institutions may define their
own classes if necessary).
• Standard
• Watch List
• Sub-Standard
• Doubtful
• Write Off
EM.PV.PARAMETER This table is specific to the Financial Inclusion environment. It was created as an
option to using the Rules Engine for allocating loans to the various classes
defined in the table PV.LOAN.CLASSIFICATION above. The table allows
institutions to define the number of days late after which a loan will be allocated
to each of the classes. For instance, if a loan is zero days’ late, it is classified as
STANDARD, if 30 days’ late, it is WATCHLIST, etc.
PV.PROFILE This table is required to define the parameters and methods for calculation of
provisioning figures for each loan arrangement. The table affords the institution
to determine whether Standard Provisioning method will be used or whether
IFRS method will be used. It also helps to define what source balances (from the
Page 66 | 84
AC.BALANCE.TYPE table) will be used to calculate provision figures as well as

determine what rates will be applied to different asset classes and if different
rates will be applied to principal and interest balances.
Records in the table are held by date and define:
a. Type of calculation (IFRS or Standard Provisioning)
b. Percentages used in process (IFRS or loan provisioning) for each
classification
c. Balance to use
d. Use of collateral
e. Type of accounting (group or arrangement)
IFRS.POSTING.DETAILS This table defines the types of accounting entries that should be generated and
what account types to be used for the entries. When new provision figures are
calculated, the table specifies if posting style for the new amounts should be
input-output (reverse old and post new) or adjustment (post the difference
between old and new.
PV.MANAGEMENT PV.MANAGEMENT is where the classification frequency, calculation and
posting frequency are defined. In this release of the system, posting delay is
allowed to enable the institution to review the calculated figures before they are
posted to the provision accounts. A minimum of one day delay is required in this
release.
Posting frequency is monthly in this release (daily posting is allowed in
subsequent releases) and the institution may specify the classification level,
whether risks are maintained at customer level (i.e. the worst class of any of the
loans given to the customer is used to calculate provision figures for all loans
held by the customer) or at loan level (i.e. provision figures will be calculated for
each loan of the customer in its own rights).
PV.ASSET.DETAIL This is the application which holds the classification and provisioning details at
the loan level. A record will be created for each loan notwithstanding the class
level selected in PV.MANAGEMENT.
PV.CUSTOMER.DETAIL This is the application which holds the classification and provisioning details at
customer level. A record will only be created on this table if the class level
selected in PV.MANAGEMENT is “Customer.”
Working with Provisioning

Provision Classification
In this application we define the various risk classes to be used for classifying overdue loans and assign rank
numbers to them.
Access
All-In-One RBHP > Product Parameters > Loan Products > AA Provisioning Parameters >Loan Classification
Page 67 | 84
The risk class and risk rank being the value of the risk are displayed..
Please note that this does not represent the percentage of provisioning that will be raised for the arrears/overdues
with this classification.
The percentages are defined in the Provision Profile Application.
Provision Parameter
The classification is linked to the Parameter table, the ID of this table can be SYSTEM, Company Code or AA Product
Name.
Access
All-In-One RBHP > Product Parameters > Loan Products > AA Provisioning Parameters > Provision Parameter
Page 68 | 84
The number days after which the repayment became overdue (in arrears) are defined. This is the number of days
up to which the asset class applies.
Provision Profile
This is the application where we define the percentages to be used in provisioning calculations, per classification.
Provisioning can be done per IFRS or STANDARD rules.
Access
All-In-One RBHP > Product Parameters > Loan Products >AA Provisioning Parameters > Provision Profile
Page 69 | 84

Provision This is the provision calculation type. For the STANDARD record, it should be set
Calculation as “Percentage,” meaning that provisioning shall be done based on percentage
rates applied to various asset classes.
Source Balance The balance used to calculate the provision amount. This can be either an
individual balance or a virtual balance (for example, TOTALPRINCIPAL). Virtual
balances are defined on the table AC.BALANCE.TYPE.
Classification As defined in the Provision Classification (previous topic in this guide)
Standard This is where we assign the percentages to be calculated per classification, i.e.,
Percentage (STD%) the percentage to be calculated on the entire balance of the loan per asset class.
This percentage is used when PROVISION.CALCULATION is ‘Percentage.’
Accounting Indicates whether the provision amount (which has been calculated and recorded)
should be accounted for.
DEAL: to raise accounting at individual (arrangement) level.
Posting Details This is the Id of IFRS.POSTING.DETAILS, where CATEGORY, Transaction Code,
etc. related to raising entries are defined.
Page 70 | 84
Provision Management
This application allows us to define the frequency for the Classification, Provision Calculation and posting process,
and the selection of records to be processed.
The selection criteria is by Application, whereby a range of category or Product Group (for AA) may be defined.
Each application is linked to a Classification rule (i.e. a link to the T24 Rules Engine) or Classification API which will
determine how a classification is derived for a contract/arrangement.
Access
All-In-One RBHP > AA Products > AA Provisioning Parameters > Provision Management

ID Define the Application for which the record is being created.
Description Provide a useful description.
Class Frequency This is the frequency at which the assets are to be classified, the Classification Job,
PV.CLASSIFICATION, will run on this frequency if defined, else by considering
JOB.FREQUENCY. Use this field if the classification frequency is different to the Job
frequency and note that it should not be equal to or greater than the Job frequency.
PV Profile Id A link to the rules dictating the classification and provisioning calculations. The latest
record (calculation date) in PV.PROFILE will be used.
Job Frequency Currently only MONTHLY frequency is allowed. This specifies the recurrence pattern
for a scheduled job. The Classification Job, PV.CLASSIFICTION will run on this
frequency if CLASS.FREQUENCY (above) is not defined.
If CLASS.FREQUENCY is defined, than CLASS.FREQUENCY takes precedence for
arriving at the next frequency to perform the classification job.
Page 71 | 84
Posting Timing Indicate when the posting should be done. The only option in this release is DELAY,
i.e., provide a lag time between calculation and posting.
Job Run Date For an Ad-hoc job, this is the only date the job will be run.
Posting Delay The number of working days between calculation and posting. In this release, at least
one day delay is mandatory.
Loans
Class Level Define whether each arrangement’s individual classification will be used for
provisioning or whether a customer’s worst classification of the arrangements in the
job will be used for all of the loans in the job. This is the default setting if not defined
at Application level. Options are LOAN: the individual arrangement classification is
used, CUSTOMER: the worst classification for the customer is used.
Product This value identifies the products included in the provisioning process. PV supports AA
(arrangements), AC (accounts), LD (loan contracts), MM (money market) and SL
(syndicated lending).
Classification Rule The T24 rule which will determine the classification to assign to an arrangement. This
Id is created in EB.RULE.GATEWAY.
Classification API An API routine to calculate the classification of the loan. This field is mutually exclusive
with Classification Rule.
Product Line AA product line to include in the selection. Both Product Group and Product Line cannot
be entered. It is also mutually exclusive with category start and category end sub-
value fields associated with the fields from Product to Product Group.
Product Group AA product group to include in the selection
Category From Input is not allowed if the product is AA.
Category End Input is not allowed if the product is AA.
Please refer to the Core Provisioning user guide for information on other products.
Provision Rules
The details relating to how the accounting entries will be generated are captured in this table. We will consider the
default Standard settings here.
Access
All-In-One RBHP > Product Parameters > Loan Products > AA Provisioning Parameters > Provision Rules
Page 72 | 84
DEFAULT.STANDARD

Id This identifies the provisioning type (e.g., Percentage) for which the record is being
created.
Description Provide a useful description. Can be used to highlight the unique settings in the
individual records in a user-friendly way.
Position Type On validation. The POSITION.TYPE will default to ‘IF’. For Standard Provisioning,
the value in this field should be changed to ‘TR’.
Posting Style Select the positing style to be followed, options are IO or ADJUST method.
On an ADJUST basis, the system will post the difference between yesterday’s value
(provision balance) and today’s value (provision balance) whereas in IO basis, the
system will reverse yesterday’s value and re-post the new value.
Page 73 | 84
Asset Name Holds the asset types defined in the IFRS.ACCT.METHODS i.e. AMORTISED,
FAIRVALUE, DISCLOSURE, IMPAIR.AMORTISED, UNWIND or
IMPAIR.AMC.ADJUST. for Standard provision, this must be set to “Provision.”
Account Type Specifies whether the posting is to happen to the CONTINGENT or the NON-
CONTINGENT base. This should be set to “Noncontingent.”
Entry Type This field allows to specify the type of the entry. It can have different categories
to post the profit amounts and loss amounts by specifying PROFIT or LOSS
respectively. If specified as BOTH, the system will post Profit and Loss to the same
category.
Entry Target This field allows you to specify whether the entry needs to be raised to Internal
Accounts, PL Categories or to the CRF Base (i.e., RE.CONSOL.SPEC.ENTRY).
Cat Type Specifies the internal account category for account type entries, PL category for PL
type entries or CRF asset type.
In Txn Code Denotes the Transaction Codes to be used for the generation of entries.
Rev Txn Code The Reversal transaction Codes to be used for the generation of entries.
Contra Ent Target Specifies whether an entry needs to be raised to Internal Accounts or to the CRF
Base.
Contra Cat Type Specifies the Internal Account category for account type entries or CRF asset type.
Contra Txn Denotes the Transaction Codes to be used for the generation of entries.
Contra Rev Txn Denotes the Reversal Transaction Codes to be used for the generation of entries.
PL This Month The category to be used while posting entries for backdated or future-dated
Category amendment. The category in this field will be used to raise the entry to adjust the
current month’s Profit and Loss. Mandatory when ENTRY.TARGET is set as PL.
PL Previous Month The category to be used while posting entries for backdated amendment. The
Category category in this field will be used to raise the entry to adjust the previous month’s
Profit and Loss. Mandatory only when ENTRY.TARGET is set as PL.
PL Year Entry The category to be used while posting entries for backdated amendment. The
Category category in this field will be used to raise the entry to adjust the previous year’s
Profit and Loss. Mandatory when ENTRY.TARGET is set as PL.
Outputs for Provisioning

Loan Asset Details
The Classification and Provisioning details for an asset (a loan) is held in this application. It is also possible to
manually capture a Classification or Provision Amount for that asset.
Based on the category defined in PV Management, arrangements are selected and a record in PV.ASSET.DETAIL
will be created only for those arrangements which satisfy the conditions specified in PV.MANAGEMENT.
A new record can be created only by the job PV.CLASSIFICATION. Once there is a classification, calculation and
positing jobs will run and manual amendments can be made when necessary.
Access
All in One RBHP > Loans > Arrears / Provisioning > Provision Reports > Loan Asset Details
Page 74 | 84
Click on the icon to drill down and view the listing under each category.
Customer Asset Details

When class level is set to “Customer” in PV.MANAGEMENT, a record will be created in this application for customers
with overdue loans. As with Loan Asset Details, it is possible to make manual adjustments for a record created
here.
Access
All in One RBHP > Loans AA > Arrears / Provisioning > Provision Reports > Customer Asset Details
Page 75 | 84
Loan Write Off and Recovery

Introduction
In the event that the loan remains unpaid for a long period of time beyond the institutions policy on recognition of
assets, a decision may be made to write off such a loan.
It is possible for a defaulting borrower to repay their debt to the institution after the loan has been written off, by
using the Recovery application. The Written off debt is taken out of, or may remain in the Contingent section of
the Financial Reports.
Configuring Loan Write Off and Recovery

Accounting for loan write off transactions is preconfigured in Financial Inclusion. The customer account is credited
to pay off the debt and the debit goes to PL54026 category code. This can be updated in the Accounting Allocation
Rule table during implementation.
WOF Loan Recovery Parameters

This is a FI specific parameter file used to maintain written off loans recovery parameters. The automated recovery
account opening, balances transfers and recoveries recording processes refers to this parameter table.
Access
All in One Page > Product Parameters > AA Products > AA provisioning and WOF parameters
Page 76 | 84

Recovery Category This is the Profit and Loss code that is credited with recovery funds
Contingency This is the Category code used to open the customer contingent account where
Customer Category written off items are maintained.
The category code must fall within the contingent category range defined on
ACCOUNT.PARAMETERS. For contingent accounts to be automatically opened, an
account product for recovery accounts should be set up using the category code
defined here.
Please refer to the Accounts User guide on contingency accounts and account
product set up
Contingency Internal This is the Category code used to open the contingent control account for contra
Category entries
Contingent Account Parameter used to determine whether Contingent control accounts are to be
Level maintained at customer level or branch level. If customer level is selected, the
next field, customer control account category becomes mandatory. If Branch level
is selected, the contingent internal category becomes mandatory.
Customer Control The category code under which customer contingent control accounts are to be
Account Category opened
Recovery order Define here the order in which recovery funds are to be applied on written off
balances. Balances are maintained property wise on the WOF loan contingent
account as contained in the balance maintenance arrangement condition at the
time of write off.
Page 77 | 84
Working with Loan Write Off and Recovery

Loan Write off
Loans can be written off using Balance Maintenance Property activities available on the Arrangement Overview
screen.
Procedure
1. Click on the New Activity link on the arrangement overview screen
2. Select Write off arrangement activity and click on the Execute icon.
3. Enter the Write off description
4. Commit the record and remember to have the record authorized.
5. The loan is written off against the PL category/Internal account defined in the accounting allocation rules.
Write off Loan Recovery

• After loans are written off, the system provides access to the items written off, using contingent accounts.
Two additional accounts are required to record and maintain access to written off items:
• A contingent account for the client will be created by the system to warehouse the amounts written off.
The mnemonic of this account is auto generated as (W+WOF Loan Account Number+W).
• A contingent control contra account to warehouse the second leg of all written off amounts. Contingent
control accounts may be opened per customer or per branch.
• The process is initiated when a loan write off activity is authorized and the arrangement is set to
PENDING.CLOSURE or CLOSE. If the status remains as CURRENT then the loan is not completely written
off and the subsequent steps will fail.
• The AA arrangement and underlying account are closed by the service BNK/EM.WOF.PROCESS. It takes 2
Close of Businesses (COB) to close the underlying Account.
• A loan recovery account (Contingency Account) is opened in the loan currency using the WOF loan account
as the alternate ID.
• If not already present, a Control account in the loan currency is opened for the customer (if
GIC.BD.PARAMETER is set to CUSTOMER) or for the branch (if GIC.BP.PARAMETER is set to BRANCH) –
this is also a contingent account
• Details of failed record are displayed on the Unsuccessful WOF Recovery enquiry. The COB process
automatically checks for any failed records now corrected and retries to create the recovery accounts.
• The Loan account is debited with the written off amount and the contingency control account is credited.
• The OFS messages are stored in a work file EM.WOF.RECOVERY.WRK showing the results and failure
reasons in any.
• In addition to transferring the WOF balance to the recovery account as shown below.
Page 78 | 84
WOF balances are stored on the Account property wise as contained in the balance maintenance property as the
time of write off.
Written Off Loan Recovery Transactions

The functions described below enables tellers to accept and record deposits made against written off loans.
Recovery payments can be made in Cash, Cheque or Account transfers.
Access
All in one page > Teller >Transactions > Deposit into Written off loan
Below is an example of the Cash Deposit into Written Off Account input screen.
Page 79 | 84
Procedure
• Open a new record. On the recovery account number field, enter the written off loan account number or select
the Contingent Account number from the drop-down list. The system checks that the account is linked to a
written off loan and displays an error if a not. The system uses this account to pass the secondary entry
between the customer contingency account and contingent control account. See note below for further details.
• On the Credit Account field, the system displays the credit account to be credited by the primary FT as
parameterized in WOF Loan Parameters table. See Note below on the Primary and Secondary FT entries.
• Select the Debit Currency. The system then populates the cash account number of the till that is processing
the transaction.
• Enter the amount being deposited to the Written Off Account.
Note. The system check against overpayments. If the amount deposited is more than the balance on the account,
an error will be displayed.
Note: The transaction is processed as follows;
Page 80 | 84
From the Input Version, the Bad debt recovered PL category is credited and the Cash Account/ Nostro Account for
cash deposits/Customer account for account transfers, is debited. This is the primary FT transaction.
OFS then in turn, raises two more FT entries: The Contingent Control Account is debited and the Customer
Contingent Account is credited. This is the secondary FT transactions. ID of the primary FT is stored on the
PRIMARY.DETAILS field of the secondary FT and vice versa.
In the case of recoveries in Local Currency against Foreign Currency Loans, the system accepts and posts the
primary FT in the local currency deposited, while the secondary FT is posted with the Foreign Currency equivalent.
The system uses the middle revaluation rate as maintained in the CURRENCY table for conversion.
When the loan is fully recovered and the balance on the account is equal to zero, the customer contingency account
is set to pending closure for closure during close of business. If contingency control accounts are maintained at
customer level, and no other write off loan exists for the customer, the contingency control account is also closed.
Reversal procedure
• Select the Reversal of transaction to written off Loan menu option
• Enter the FT ID of the transaction to be reversed as shown below
• Click on the reversal icon
• If the account is already closed, as message indicating so will be displayed.

• To restore the account from history, select Account history restore on the menu, enter the account to be
restored and hit enter. Under More Actions, select History restore and commit the record.
• Upon authorization, the Account is restored back to the live file for reversal entries to be posted.
Page 81 | 84
Outputs for Loan Write Off and Recovery

Loans Written off enquiry
This list provides details of loans written off loans e.g. Amount written off, arrears to date, days in arrears and
provision amount.
Access
Role based menu > All in One RBHP > Loans AA > Arrears/ Provisioning > Loans Written Off
When the enquiry displays, it appears like the screen shown below
WOF Loan Recovered enquiry

This enquiry provides details of loans written off amounts recovered to date.
Access
All in One RBHP > Loans AA > Arrears/ Provisioning > WOF Loans Recovered
Click on the view icon to view the recovery account statement with the transactional details of the recovery
progress made.
WOF Loan Customers with Cr Balances

This enquiry provides details of Customers with Written off Loans while carrying Credit balances in other accounts.
Access
All in One RBHP > Loans AA > Arrears/ Provisioning > WOF Loan Customers with Cr Balances
Page 82 | 84
Note: The system tracks all user initiated activates in WOF Loans Customers’ accounts and generates an override
message alerting the user of the same.
Page 83 | 84
Page 84 | 84

Loans

Uploaded by

Copyright:

Available Formats

You might also like

Loans

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Loans

Uploaded by

Copyright:

Available Formats

Financial Inclusion / Accelerator

Loans User Guide

Information in this document is subject to change without notice.

LOANS IN FINANCIAL INCLUSION ................................................................................................ 4

Model Parameters ............................................................................................................................................................... 5

Model Products ................................................................................................................................................................... 8

Inheritance Groups .............................................................................................................................................................. 9

Loan Product Groups ......................................................................................................................................................... 12

The Loan Product Wizard ................................................................................................................................................... 15

Direct Loan Input ............................................................................................................................................................... 48

Loan Disbursements .......................................................................................................................................................... 55

Loan Repayment Operations ............................................................................................................................................. 58

Loan Top-up and Rescheduling .......................................................................................................................................... 62

Configuring Loan Top-up and Rescheduling ....................................................................................................................... 62

Working with Loan Top-up and Rescheduling .................................................................................................................... 64

Arrears Management ........................................................................................................................................................ 65

Loan Write Off and Recovery ............................................................................................................................................. 76

Loans in Financial Inclusion

The Product Wizard

Product Setup Outside of the Product Wizard (Predefined in Financial Inclusion)

• Creation of Product Groups

Initial Deposit Category range

(sAaArrId, rEmLoanHistory, sOutFieldNames, sOutFieldValues)

- sAaArrId – incoming – AA.ARRANGEMENT id

Guarantor Limit Parameters

Savings Multiplier Parameters

The diagram below presents a sample inheritance flow.

Working with Inheritance Groups

Inheritance Group Details:

Loan Product Groups

Configuring Product Groups

Working with Product Groups

Loan Product Group Details

The Loan Product Wizard

 Configuration of Child Product Conditions for identified properties

Configuring the Product Builder Wizard

Working with the Product Builder Wizard

Customer / Account Stage

• Indicate whether Joint Ownership is allowed for this product

On the Account Parameters tab,

• Select the base date to determine the contract anniversary date

o 8399– Non-Revolving Loans

Term Amount Stage

On the Term Parameters tab,

On the Amount Parameters tab

Payment Schedule Stage

Principal Interest Stage

o If the “Current + Overdue Principal Balance” is selected, then interest is calculated on

Mixed / Tiered Interest

Penalty Interest Stage

Charge Selection Stage

Charge Definition Stage

Payoff / Closure Stage

On the closure tab,

Check Type = Allow top-up

Check param = YES / NO

Check Type = Allow reschedule

Check param = YES / NO

Check Type = MAX.TOPUP.COUNT