Financial Inclusion / Accelerator

Retail Accounts
Product Builder
Account Origination
Account Operations
User Guide
Retail Accounts

Document History

Author Version Date

Esther Muniu 1.0 30th Nov 2018

Isa Omba 1.1 12th December 2022

Comments:

12th December 2022 Document updated with new corporate branding

2 Financial Inclusion Retail Accounts

Retail Accounts

Table of Contents
Document History .................................................................................................................................................................................. 2
Introduction.............................................................................................................................................................................................. 4
Assumptions............................................................................................................................................................................................. 4
References ................................................................................................................................................................................................ 4
Configuring Retail Accounts Products .............................................................................................................................................. 4
The Product Wizard ............................................................................................................................................................................... 4
Configuration ........................................................................................................................................................................................... 4
Model Products Groups ........................................................................................................................................................................ 5
Configuration Workflow ....................................................................................................................................................................... 5
Inheritance Groups ................................................................................................................................................................................ 5
Retail Account Product Groups .......................................................................................................................................................... 8
Introduction.............................................................................................................................................................................................. 8
Working with Product Groups............................................................................................................................................................. 8
Building Retail Account Products .................................................................................................................................................... 11
Configuring the Product Builder Wizard ....................................................................................................................................... 11
Working with the Product Builder Wizard .................................................................................................................................... 11
Product review stage .......................................................................................................................................................................... 38
To change details of an existing AA product ............................................................................................................................... 39
Account Product Overview ............................................................................................................................................................... 39
Account Origination............................................................................................................................................................................ 41
Configuring Account Origination .................................................................................................................................................... 41
Working with Account Origination ................................................................................................................................................. 49
Outputs for Account Origination ..................................................................................................................................................... 61
Account Applications Enquiry .......................................................................................................................................................... 61
Account Operations and Maintenance ......................................................................................................................................... 62
AA Accounts List .................................................................................................................................................................................. 63
Pending Records .................................................................................................................................................................................. 66
Inactive / Dormant Accounts ........................................................................................................................................................... 66
Closed Accounts .................................................................................................................................................................................. 67
CGAP Category A Reports ................................................................................................................................................................. 68
Maximum Saving Balance ................................................................................................................................................................. 68
Internal Accounts ................................................................................................................................................................................. 70
Nostro Accounts................................................................................................................................................................................... 72

3 Financial Inclusion Retail Accounts

Retail Accounts

Introduction
This guide aims to provide information regarding the configuration of Retails Account products using Arrangement
Architecture in Financial Inclusion / Accelerator (FI/ACL). The operations involved during the lifecycle of a retail
account, from account opening to closure are also described. The guide is divided into three main segments, each
describing the functionality, parameter set up procedures and deal processing. These main segments are:

1. Product Builder
2. Account Origination
3. Account Operations

Assumptions
It is assumed that the reader of this guide is proficient in the Temenos Core Banking system, worked with the
Browser channel application and understands the structure and navigation of the FI/ACL Role Based Home Pages.
For configuring the functionality, it is assumed that the reader has prior implementation experience and
understands the technical concepts of the Temenos Core Banking system.

References
FI/ACL Role Based Home Pages user guide.
Arrangement Architecture Retail user guide

Configuring Retail Accounts Products

The Product Wizard
Financial Inclusion / Accelerator delivers a product wizard where users are able to define Retail Account 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 Building using Arrangement Architecture.

Read AA Property Classes user guide for detailed information on Property Classes.

4 Financial Inclusion Retail Accounts

Retail Accounts

Model Products Groups

Financial Inclusion is delivered with three sample Retail Account Product groups. Sample shared conditions for
each product group are also released for reference or use by your institution, if suitable. The three product groups
are;
▪ Current Accounts
▪ Savings Accounts
▪ Share Accounts

Configuration Workflow
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.
Finally, products are created by creating the product conditions relating to each. The workflow may be summarised
as below;

Create Define Create

Create
Inheritance Shared Product
Products
groups Conditions Group

Inheritance Groups
In Financial Inclusion, three sample Inheritance Groups have been defined for use (if they meet requirements) and
to show how to define conditions for inheritance (when necessary).

Access
Product Parameters > Account Products > Product Parameters > Inheritance Groups > Create New Inheritance
Group

List the shared conditions associated with the Group Code (used for inheritance) by clicking on the icon. The
Inheritance Group can also be viewed and amended by clicking on the icon.

Procedure
The following section describes the Inheritance group and shared conditions set up process

5 Financial Inclusion Retail Accounts

Retail Accounts

Inheritance Group Details

▪ Enter the name and description of the inheritance group.

▪ Select the Currencies for 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:

6 Financial Inclusion Retail Accounts

Retail Accounts

▪ 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 complete the Shared Conditions
builder stages.
Note: It is possible to create more than one shared condition groups by expanding the multi value icon next to the
Condition Group Code

7 Financial Inclusion Retail Accounts

Retail Accounts

Retail Account Product Groups

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

Working with Product Groups

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

Access
Product Parameters > Account Products > Product Parameters > Product Groups > New Account Product Group

Account Product Group Details

▪ In this tab, the name and description of the product group is entered
▪ Select the category code range under which products under this group will be defined. The accounts
category ranges in Financial Inclusion Model bank are preconfigured as follows.
▪ 1000 – 1099 for Current Accounts

8 Financial Inclusion Retail Accounts

Retail Accounts

▪ 6000 – 6099 for Savings Accounts

▪ 7300 – 7399 for Share Accounts.
Use the “New Category” link 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.
▪ Select all the currencies in which products defined within this product group may be opened.
▪ 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.

Shared Conditions
In this tab, shared condition created using the inheritance group are linked to the properties to form a second level
of parent conditions for the Group if necessary. This is done as follows;
▪ 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.

9 Financial Inclusion Retail Accounts

Retail Accounts

Once the product group record is committed, it needs to be proofed and published before Products can be created.

To proof and publish the product, click on the icon available on the list of Product groups. The drill down icon
leads to enquiry below.

Click on the icon to proof 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 what stages are to be present for input by the product builder wizard. (Those marked as
“Define now”)

10 Financial Inclusion Retail Accounts

Retail Accounts

Building Retail Account Products

Introduction
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.

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 Product Groups section of this user guide

Working with the Product Builder Wizard

The Product Builder Wizard in Financial Inclusion (EM.PRODUCT.ACCOUNT) is used to create the final product.

Access
Product Parameters > Account Products > Product Parameters > Product Groups > Create New Product

Procedure
The following section describes the Account product building workflow.
Click on the icon next to the product group where the new product belongs.

The new product icon opens the Account product settings screen. Enter the Product ID and select the product
parent.

11 Financial Inclusion Retail Accounts

Retail Accounts

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.

Product Details Tab

On the product details tab,

▪ Enter the Product name and a meaningful description of the product
▪ Pull down the drop-down list to select 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 currency of the product and the start date of the product. Start date can be in the past meaning
back dated arrangements may be opened

12 Financial Inclusion Retail Accounts

Retail Accounts

Customer / Account Stage

Customer and Account parameters are defined in this stage.

On the basic details tab,

▪ Indicate whether Joint Ownership is allowed for the product
▪ The name of the Arrangement account to be opened is defaulted on the Name field. This facilitates
reporting whereby each account of the customer is identified with the name of the 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
3. Forward
4. Forward same Month

13 Financial Inclusion Retail Accounts

Retail Accounts

▪ 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 the Calendar date convention.
▪ Indicate whether IBAN should be generated for the product and whether Passbooks should be
enabled for the product. Passbooks can be enabled for products whose category code is defined in
the SAVINGS record of ACCOUNT.CLASS Application.

Limit Stage
Overdraft facility parameters are defined in this stage.

▪ Indicate the default overdraft amount applicable to all accounts opened under this product. Else,
select Yes on the Limit Amount negotiable field to enter the minimum and maximum overdraft
amounts that may be granted to account holders.
▪ The limit reference for Accounts is defaulted to 100 in FI / ACL and non-negotiable. It should not be
amended without exercising due care. Additional parameterization in LIMIT.REFERENCE and
LIMIT.PARAMETER Applications may be required. Please refer to the Limits user guide for more
details.
▪ The limit Serial number is defaulted as NEW. This enabled the system to automatically create the
limit record as part of account opening process. Limits managed by AA are always single limit

14 Financial Inclusion Retail Accounts

Retail Accounts

Balance Availability
In this stage, the Balance Availability property class is defined for notice withdrawal conditions.

Indicate whether balance availability conditions are to be defined for the product or not. If required, complete
input as follows.
▪ Notice Amount – Indicate the maximum amount which can be withdrawn without notification being
required from the customer. An override message is generated when this value is exceeded.
▪ Notice Period - Indicate the notice to be given in days, weeks, months, or years, for withdrawing an
amount above the notice amount.
▪ Notice Availability - Indicate the period for which the funds subject to notice conditions are available.
Example: Notice Period is defined as 1M and Availability is defined as 5D, funds are made available
for withdrawal for 5 days after the Notice Period.
The category code of the Notice Account product must exist in ACCOUNT.CLASS application, record SAVINGS. The
product builder displays an override message to remind the user of this additional configuration required.

Note: FI/ACL also supports the definition of notice deposit accounts through the Deposits product wizard. Refer to
the Notice Deposits user guide for more details.

15 Financial Inclusion Retail Accounts

Retail Accounts

Interest Stage
In this stage, Interest conditions are defined. The fields for input are similar for both Debit and Credit interest.

▪ Specify if the interest is calculated using a fixed rate or floating rate. Depending on the option selected,
the relevant tab is dynamically displayed for further interest definition.
▪ If the Fixed Interest rate option is selected, enter the actual fixed rate in the Fixed Rate tab and indicate
whether the rate is negotiable or not. If set as negotiable, the Minimum rate and Maximum rate fields
become mandatory for input. This means that users will be allowed to override the product interest rate
with a different rate that is between the minimum and maximum negotiation range allowed. Similarly, if
the Floating interest option is selected, the Index and the margin details should be entered in the
respective tab.
▪ The day basis to be used for principal interest calculation is defaulted by the system.

16 Financial Inclusion Retail Accounts

Retail Accounts

▪ 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 debit 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.

FLOATING INTEREST EXAMPLE

In the example below, debit interest is to be calculated based on the prime rate plus a margin of 0.25 for debit
balances up to $5,000. Any balance above $5,000 would bear interest at prime plus 0.5.
The floating index is defaulted as non-negotiable, and the margin can be set as negotiable if the bank’s policy
allows.
Interest application method and frequency are defined in the Payment Schedule stage. Once the payment
schedule stage is completed, changes to the interest rate parameters may not be modified in the wizard. A warning
message to that effect of presented upon committing the interest stage.

17 Financial Inclusion Retail Accounts

Retail Accounts

18 Financial Inclusion Retail Accounts

Retail Accounts

Dormancy
The definition of Account Dormancy is absence of any Customer Initiated Transaction or Activity on the account,
for a certain period, where the period can vary according to local regulations or a bank’s own internal policy.
Configuration of account inactivity using the Inactivity Months field in the COMPANY record or Dormancy Property
Class is mutually exclusive. Should the institution wish to track dormancy in more details, including generation of
chaser advices and dormancy charges, then the dormancy stage should be defined.

Three Dormancy statuses (Inactive, Dormant, Unclaimed) were preconfigured in FI/ACL. Enter the parameters for
each of the statues as follows.
▪ Enter the period after which the corresponding status will be assigned in the absence of customer
activity.
▪ Enter the Notice days – i.e., the number of days that the system requires, after reaching the
corresponding status, for generating an Advice.

19 Financial Inclusion Retail Accounts

Retail Accounts

▪ Enter the Notice Frequency in which Chasers need to be sent out, so long as the account remains in
the corresponding status.
▪ Enter the Charge Frequency – the frequency in which charges for Dormancy are collected from the
account. This charge is collected as long as it remains in this Dormancy status. If the Frequency is
specified, Dormancy charges must be defined in the charge selection stage. If Frequency is not
specified, there is no periodic charge collection for the corresponding Dormancy status.
Note: There is a facility to define which of the AA Activities are qualified as Last Activity for Dormancy purposes. If
these Activities have been executed on the arrangement, then the arrangement is considered as Active
for Dormancy purposes. The default setting in FI/ACL is as shown below. Changes can be made directly in AA
product condition.

The column ‘Include or Exclude’ specifies if Activity, Class or Type is qualified to keep an Arrangement from
becoming Inactive.
Please refer to the Dormancy Property Class user guide for more details on dormancy processing.

Charge Selection Stage

In this stage, charges applicable to the product are selected. First, we decide if Ledger charges are applicable for
the product. These are general charges triggered based on activities or balances a customer maintains over a
period of time and are applied on the account at fixed intervals, typically monthly. The following ledger charges
can be defined in FI/ACL,
1. Number of Debits / Credits
2. Highest Debit Fee
3. Turnover Debit / Credit
4. Transaction fees
If defined, the system automatically creates a Periodic Charge condition with the charges mapped to the relevant
Activities. Minimum and Maximum charge amounts may then be defined as we will see in the Periodic charge
stage of the wizard.
Ledger charges are not presented if the field Ledger Charges Applicable is set to No. Next, other charges to be
defined are selected by answering the question, “Do you want to define the same charge condition for all
currencies available for the product?”

20 Financial Inclusion Retail Accounts

Retail Accounts

Options are;
1. Yes – A default charge condition will be created for all currencies defined for the product.
2. No – Separate charge conditions are to be defined for each currency of the product. This option is
presented dynamically when defining a multi-currency product.
Not applicable – Select this option if the charge does not apply to the product

21 Financial Inclusion Retail Accounts

Retail Accounts

Charge Definition Stage

Charge conditions are defined as follows,
▪ Specify if the charge should be applied because of an activity, breaking a restriction or attached to
payment schedule.
▪ If the charge is to be linked to an activity, indicate which activity it applies to.

Next, in the charge calculation tab, specify how the charge should be calculated. If it is a fixed charge, enter the
flat charge amount to be applied on every transaction.
If it is a calculated charge, then specify how the charge should be calculated. In the example below, up to two
Cheque Withdrawal can be made on the account free of charge. Thereafter, a flat fee of $10 is applied per Cheque.

22 Financial Inclusion Retail Accounts

Retail Accounts

For other charges (non-ledger), an additional parameter is presented to define the charge application method.

The options are

▪ Capitalise - This allows for the bills to be issued immediately and the associated activity charge is
applied directly on the account.
▪ Defer - The system calculates the charge immediately but applies the charges after a specific period
of time. Charges marked for deferral are added to the periodic charge condition to be incorporated
in the payment schedule.
▪ Due – The charge is calculated immediately, and a bill issued for manual settlement.

23 Financial Inclusion Retail Accounts

Retail Accounts

Period Charge Stage

The main functionality of Periodic Charges stage is to enable the user to levy charges based on activities that a
customer performs over a period of time. The stage is also used to make the deferred charges due at fixed intervals.
This needs to be defined as part of the payment schedule definition and the Property Condition determines the
charges to be made due. The fixed interval is defined as a frequency in the payment schedule of the arrangement
with Periodic Charges Property as the Property.

This stage is automatically generated by the wizard based on the ledger charges conditions defined in the charge
stage and based on whether any of the other charges’ payment method was set to Defer. The stage is not presented
if ledger charges, and deferred charges have not been defined for the product.

Enter the minimum and maximum ledger charge amount that may be applied on the account if applicable. If the
minimum and maximum amount are not defined, then the exact charge amount derived is applied on the account.

Charge Group - different charge groups as defined in AA.CHARGE.GROUP virtual table are available as a drop
down for user to select. Charge group can be defined only for those charges which are calculated based on
activities.

24 Financial Inclusion Retail Accounts

Retail Accounts

Free Charge – indicate the charge group for which free transactions are associated, if applicable.
Free Transaction Count – Indicate the number of free transactions per group or enter the value All, which denotes
that all transactions pertaining to group are exempted for ledger charge calculations.

Payment Schedule Stage

In this stage, Payment Schedule conditions are defined as follows

▪ Specify whether interest and charges are to be capitalized on the account or made due, and whether the
application method is negotiable.
▪ Select one of the following interest payment/capitalization frequencies: Weekly, Monthly, Quarterly, Half
Yearly, Annually.

25 Financial Inclusion Retail Accounts

Retail Accounts

Account Restrictions Stage

Additional restrictions may be defined for the product through this stage.

Parameters supported in the current release of the Accounts product builder are as follows:
▪ Restriction Type - Select from the dropdown list the restriction to be defined for the product.
▪ Period Type – for the restriction type selected, indicate the period within which the restriction must apply.
Options available are
▪ Life - Restriction applies for the entire life of an arrangement or arrangement life as a certain
product.
▪ Initial - Restriction applies for an initial period only of an arrangement during its lifetime or the
initial period of an arrangement as a certain product
▪ Rolling - Restriction applies for a rolling period that ends at the date of a transaction. (For
example, the number of account deposit transactions in the last three months)

26 Financial Inclusion Retail Accounts

Retail Accounts

▪ Repeating - Restriction applies for a fixed repeating period during either the life of the
arrangement. For example, the restriction may be based on a 12 a month calendar period (that
is, Jan to Dec) or three-month period starting on the anniversary of the Account.
▪ Restriction Period – The period for which the restriction is applicable. Except for the Life period
type, restriction period type must be defined for all other period types.
▪ Restriction Count - the number of transactions allowed within the restriction period.
▪ Restriction Value - the total amount allowed within the restriction period. Restriction count and
restriction amount are mutually exclusive.
▪ Breakage Action - Lastly, indicate whether the system should display an error or warning
message is the restriction is breached.

For interest paying products e.g. Savings Accounts, it is possible to define penalty interest or total interest waive if
restrictions are breached.
Below are examples of account restrictions definition.

O NE CASH WITHDRAWAL ONLY ALLOWED PER YEAR .

A CCOUNT OPENING MINIMUM BALANCE

A CCOUNT MUST NOT BE OVERDRAWN

27 Financial Inclusion Retail Accounts

Retail Accounts

Tax Stage
In this stage, tax conditions are defined as follows
▪ Specify if tax is to be applied for the product.
▪ Select the Tax Code to be used in calculating tax. It should be a valid record in the TAX application.
▪ Select the Tax Condition record to be used in calculating tax. It should be a valid record in the
TAX.TYPE.CONDITION application.
▪ Tax Code or Tax Condition are mutually exclusive, only one is to be selected.
▪ Please refer to the TAX user guide for more details.

Eligibility Stage
Conditions used to evaluate eligibility of a customer for a product are defined in this stage.

First, indicate the target customer group for the product. Options are Individual and Non individual.

28 Financial Inclusion Retail Accounts

Retail Accounts

Customer Restrictions

In the first tab, we define the Customer Restrictions. These are based on data available in the Customer Information
File. For each criterion selected, indicate the breakage action, that is whether the system should display a warning
or error message at Account opening if conditions are not fulfilled.
The following eligibility criteria may be defined.
▪ Minimum Age
▪ Maximum Age

29 Financial Inclusion Retail Accounts

Retail Accounts

▪ Residence
▪ Nationality
▪ Classification
▪ Income Type
▪ Income Level

Other Restrictions

Additional restrictions can be defined as follows;

▪ Share Account - This restriction is commonly required by credit unions where a member must own shares
in share account before opening any other type of an account. The system checks that the customer has
an account of the category code parameterised in the Global Product Parameters
(EM.PRODUCT.PARAMETERS). To access the parameter table, navigate to Product Parameters > Loan
Products > Product Parameters > Global Product Parameters.
▪ Allow Staff – For this restriction, the system checks the field STAFF.OFFICIAL in Customer to determine if
the customer is an employee of the institution or not.
▪ Allow Student - For this restriction, the system checks the field OFFICER in Customer to determine if the
customer is a student or not.
▪ Credit Check Result – based on Credit Indicator field in Customer
▪ Bank Code – based on the Bank Code received from the credit Bureau and stored field in Customer.

30 Financial Inclusion Retail Accounts

Retail Accounts

Change Product
Change product stage defines the rules and behaviour for allowing arrangements of one product to be changed
to another. User can list the allowed products for change product. When a new product is applied onto the existing
arrangement, the user loses all his negotiations done as part of the old product.
First, indicate what change product is allowed for the product or not. Next, indicate the change date or change
period. The example shown below indicates that the account will switch to a different account product on the
customer’s 16th birthday.

On the Change to Product field, select from the drop-down field the product that the account must switch to on
the specified date or period. The system can be set to generate an advice prior to the product switch by populating
the Prior Days field.

31 Financial Inclusion Retail Accounts

Retail Accounts

Statements
Statement generation parameters are defined in this stage. This stage cannot be defined if passbooks have been
enabled for the product at the Customer / Account stage of the product builder.

If statements are to be generated, indicate the start date and frequency for producing the regular account
statement. The statement of each cycle shows the details of all entries in the cycle since the last statement. In the
example given above, the account statement is to be generated every month on day 15.

Supported frequencies are:

▪ Daily
▪ Weekly

32 Financial Inclusion Retail Accounts

Retail Accounts

▪ Monthly
▪ Defined

Indicate whether the statement should be supressed if there were no movements on the account since the last
statement.
The parameters set in this stage updates the table ACCOUNT.STATEMENT with account specific details which are
then used to generate the account statements during COB. Please refer to Statements property class user guide for
more details on statement configuration and generation.

Settlement Stage
Settlement Parameters are defined in this stage as follows.
INTEREST PAYOUT
▪ Specify if interest should be settled automatically from the customer account and whether this is
negotiable at Account Origination.
▪ 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 required. Options are
1. Full – The amounts due will be deducted from funding account even if the account becomes
overdrawn.
2. None – If the funding account does not hold enough funds to cover the due amount, settlement
will not be attempted.
3. Partial – The funding amount due will be deducted from the 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.
▪ Payment Category - In the event of interest being automatically paid from another account held with the
institution, the category code of that account should be defined here. The system will validate that the
account holder has an open/active account of this category code and default the first account at the
settlement tab in Account Origination.

33 Financial Inclusion Retail Accounts

Retail Accounts

CHARGE COLLECTION
Select yes or no to indicate if charge collection rules are to be the same as the payment 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 debit interest collection.

34 Financial Inclusion Retail Accounts

Retail Accounts

Closure Stage
Retail Account closure parameters are defined in this stage as follows.
▪ 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 after maturity
date based on Closure Period, provided all balances are settled.
▪ 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.
▪ Indicate whether the account gets closed immediately or in COB.

35 Financial Inclusion Retail Accounts

Retail Accounts

36 Financial Inclusion Retail Accounts

Retail Accounts

Payoff
Payoff parameters are defined in this stage to aid with the generation of payoff statements. The payoff statement
includes the details such as Principal, Interest, and Charges that are due because of account closure.
Enter the Payoff expiry days to define the expiry date for the payoff bill. When the expiry date is reached, the
system invalidates (deletes) the payoff bill.
Settle dues is defaulted to Yes. This parameter allows the user to specify if the amount made due to the customer
between the simulation start date and payoff effective date should be considered settled or not. setting this field
to YES enables the auto settlement of future dues

37 Financial Inclusion Retail Accounts

Retail Accounts

Product review stage

Once all product conditions are completed, the product builder next presents the Product Review stage where the
parameters defined may be reviewed by the approving officer as defined in Product Parameters > Account
Products > Product Parameters > Account 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.
Some settings may be amended during the product review stage. The product build status can be seen in
AA Product Builder > Products

38 Financial Inclusion Retail Accounts

Retail Accounts

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 > General > AA Core Configuration.
For example, to change the Interest conditions of an Account product;
1. Click on All-in-One RBHP>>Product Parameters> General >AA Core Configuration > Product Conditions
2. Click on Interest Property Class >your product condition and edit the relevant attribute.
3. Proof and publish the product.
To change the Eligibility and Settlement Categories:
1. Click on …Product parameters > Account Products > Settlement Settings or 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 conditions

Account Product Overview

The Account Product Overview provides a summary of the product and its 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 > Account Products > Account Products

On clicking the icon, the product overview summary displays as below.

39 Financial Inclusion Retail Accounts

Retail Accounts

40 Financial Inclusion Retail Accounts

Retail Accounts

Account Origination
Introduction
The Account Origination process is based on the Temenos Process Workflow. The application enables flexible
configuration of process stages involved in creating retail accounts and allows inclusion or exclusion of stages as
may be needed by clients. Context based processing is enabled within the different stages, allowing the user to
quickly select or enter data that is relevant to the borrower. The system allows stage activities to be distributed
among users as may be relevant to the institution’s procedures. Account applications may be processed from
initiation straight to approval, account creation and funding.

Configuring Account Origination

The parameter tables listed below are required for account origination to function. These are the set of tables that
guide the origination workflow and can be configured by users. The behaviour of origination at various application
stages may be defined and so may application statuses be configured. Items of checklist that are required at the
various application stages are configurable by users and so are the users or groups of users that may own data
input at various application stages. These settings all work together to ensure that the rules guiding the account
application process are properly coordinated.
▪ EM.AO.STAGE
▪ EM.AO.APPLICATION.STATUS
▪ EM.AO.PARAMETERS
▪ EM.AO.APPROVAL
▪ EM.AO.STAGE.CHECKLIST
▪ EM.AO.DOCUMENT
▪ PW.ACTIVITY
▪ PW.PARTICIPANT

Access
All-In-One RBHP > Product Parameters > Account Origination > Account Origination Param

EM.AO.STAGE – Account Application Stage

There are currently five stages in the origination system, beginning with ‘Application Input’ and ending with
‘Account Creation’. The default parameterisation of the stages is included in the system, but each stage can be
reconfigured, to indicate whether or not the stage is mandatory, optional or not required, and to make other
selections.

41 Financial Inclusion Retail Accounts

Retail Accounts

Field name Description

Description Description of the Account application stage. This is a multi-language field.

Optional To make any of the five stages optional, click in this box. If a stage is marked as
optional, the stage may be set as optional or not required in the main parameter
table EM.AO.PARAMETERS. If this field is left blank, it means that this stage is
mandatory in the origination workflow. In the current release of the system, the
Application Input, Offer Production and Account Creation stages are implicitly
mandatory and should not be marked as optional.
SLA Estimated SLAs are in place to assist the institution to establish a maximum period within which
an account application must be processed. This field indicates the default maximum
number of days permitted for an account application to be in this specific stage of
the origination workflow, before a notification is sent as per the SLA Escalation
parameter. The SLA Estimated parameter can be updated for a specific product using
EM.AO.PARAMETERS table.
SLA Tolerance This field indicates the number of days exceptionally permitted for any account
application to go beyond the SLA Estimated days. The SLA Tolerance parameter can
be updated for a specific product using EM.AO.PARAMETERS table.
SLA Escalation When an SLA is breached, the system is designed to send a note to some managers
of the institution so further actions may be taken to move processing forward. Users
who are to be notified may be included in records of the table PW.PARTICIPANT.
Select the relevant participant record for this processing stage and other stages as
necessary.

EM.AO.APPLICATION.STATUS – Account Application Status

Each stage in account origination contains a set of possible application statuses within an overall process status.
In the sample screen below, the APPLICATION.INPUT stage contains a set of possible statuses within the overall
process status ‘Applied’

42 Financial Inclusion Retail Accounts

Retail Accounts

Field name Description

Description Description of the account application status. This is a multi-language field.

Stage Pull down on the lookup field and select the stage within which this application
status applies.
Action Pull down on the lookup field and select the action that the system must perform
because of selecting this application status. The following actions are available:
▪ “Complete” – when this status is selected in origination, the system will
validate data inputted in the stage, mark it as complete and automatically
take the user to the next stage of processing.
▪ “Hold” – when this status is selected in origination, the system will validate
data inputted in the stage, but will keep the origination workflow in this
stage for further processing.
▪ “Skip” – when this status is selected in origination, the system will skip
stage data validation and automatically take the user to the next stage of
processing. Application statuses with such action can be used to skip
optional stages in the origination workflow.
▪ “Cancel” – when this status is selected in origination, the system will skip
stage data validation and the application will be cancelled.
▪ “Back” – when this status is selected in origination, the system will skip
stage data validation and automatically take the user to the previous stage
of processing. A notes field opens up for input where the user may record
notes to be presented to the previous stage owner.

43 Financial Inclusion Retail Accounts

Retail Accounts

Notes Required If a note must be entered by the user as a result of using this status, then flag this
field so the notes field in the origination stage will be made mandatory by the
system.
Process Status This is the overall origination process status that will be set when this application
status is selected on an account application. For instance, Account Application
Input Complete (101) is used in the Application Input stage of origination, and
when selected, the overall status is set to “Applied”. When adding new application
statuses, set this field accordingly to the stage the status relates to.
Next Application Status It is possible to define which application status may be selected next after the
current status is used. For instance, a user may specify that if application status 103
is selected and the process action is ‘Hold,’ then the next possible status a user may
select whenever the application processing is to be continued must be 101 with
action ‘Complete.’

Delegation Required Indicate whether delegation is required. Delegation may only be used together with
process action Hold.
Refer To It is possible for a user to refer the processing of a certain origination stage to
another user. The “Refer To” set of statuses are in place to allow users to transfer
application processing to a valid PW.PARTICIPANT role. For instance, an approving
officer may transfer approval of an application to a higher-level manager, e.g., CEO
or Branch Operation Manager.

EM.AO.PARAMETERS – Account Origination Main Parameters

This table brings together some of the other parameters defined in previous tables for the account origination
workflow. The following Ids are accommodated, in processing priority order:
▪ Product
▪ Product Group
▪ Branch Company
▪ Master Company
▪ System

GENERAL PARAMETERS

Field name Description

Prospects Allowed Check this field to indicate that account applications are allowed for
prospect customers.
Skip Approval for Authorised Users If an application requires approval, should origination skip the
Approval stage when an inputter is a participant in the group of
approvers for the account product type involved?
Option No means the approval stage should not be skipped. The
REVIEW.APPROVAL stage cannot be set as Not Required
Option Yes means the approval stage should be skipped. The
REVIEW.APPROVAL stage cannot be set as Required.

44 Financial Inclusion Retail Accounts

Retail Accounts

Expiry Before Approval If applicable, enter the number days after which an account
application should be marked as expired if it has not been approved.
The system does not cancel the application. Rather, a notification is
sent to the dashboard of the officer indicated in the SLA Escalation
path so further action may be taken. The officer may decide that
processing should continue or be stopped
Expiry After Approval If the institution wishes that applications for which approval has been
given but account is not yet created should expire after a certain
number of days, then the number of days should be entered on this
field.
The system does not cancel the application. Rather, a notification is
sent to the dashboard of the officer indicated in the SLA Escalation
path so further action may be taken. The officer may decide that
processing should continue or be stopped.

WORKFLOW PARAMETERS

Field name Description

Stage Option Pull down on the lookup field and select whether or not this stage should
be ‘Required’, ‘Optional’ or ‘Not Required’. In the current release of the
system, application input, offer production and account creation are
inherently mandatory and cannot be changed otherwise.
Default Status For each origination stage, it is possible to default a status that will be
applied if the user does not select a different status at deal processing.
The exception to this is for Review / Approval stage where no status has
been defaulted as it is necessary for the approving officer to deliberately
select a status representing his or her decision.

Field name Description

SLA Estimated/Tolerance/Escalation The SLA fields are defaulted from selections made on the EM.AO.STAGE
table.

45 Financial Inclusion Retail Accounts

Retail Accounts

OTHER PARAMETERS

Field name Description

Refer Status Pull down to select a status which is selected during application processing, the
system will automatically refer the application stage to the indicated
PW.PARTICIPANT members indicated in the next field.
Refer To Indicate the PW.PARTICIPANT group to which applications will be automatically
referred to whenever the refer status indicated above is selected during application
processing.
Document Available Select the document to be generated during the offer production stage by pulling
down on the field to select available documents.
Mandatory Indicate whether or not document generation is mandatory for the product
specified
Payment Order Product Select the Payment Order Product used to generate the payment order for the
credit interest payout to an External (Beneficiary) account

EM.AO.APPROVAL – Account Application Approvals

It is possible to create different approval levels for account applications with limit included and to indicate which
PW.PARTICIPANT officer or group of officers is able to approve them. The table below provides an example of this
setup

Field name Description

Currency The currency for which approval levels are being set up.

Amount Above This parameter is used as part of approval set for account applications with limit
included (mostly current accounts). Any amount indicated here is checked against the
Overdraft Limit field at Application Input stage. For products without overdraft limits,
this field should be no input.

46 Financial Inclusion Retail Accounts

Retail Accounts

Customer Type This parameter allows the institution to decide if different officers should approve
accounts created for existing customers and prospect customers or if a single officer
can approve both.
Approver Select the user group (PW.PARTICIPANT record) representing the role that must
approve the amount. The user or set of users who occupy the role are defined in
PW.PARTICIPANT.

EM.AO.STAGE.CHECKLIST – Application Checklist Items

This table is used to define items of documentation that an applicant is expected to present at various stages of
origination in support of his or her application. Checklist items could be defined for account products, product
groups, branch or system records.
The multi-value set of fields allows the user to identify at which stage of origination items of checklist are required,
select the ID of the item of checklist which must be a valid record in the GIC.CHECKLIST.MASTER table and indicate
whether or not the item of checklist may be overridden at deal processing level.

Field name Description

Name The name of the product will be displayed here.

Stage Select from the lookup table the stage at which item of checklist is required.

Item ID Select from the lookup table the ID of the item required.

Item Override Select ‘YES’ if the item of checklist may be overridden (i.e. deemed not required)
at deal processing. When an item is overridden at the deal level, the system
makes the Notes field mandatory so the user must enter the reason for
overriding the item.
Applicable For Select Yes if the checklist item is required for the Main Holder, or Group Member,
or Joint Holder, or External Guarantor, or Internal Guarantors.

EM.AO.DOCUMENT – Account Application Agreement

The documents required for production during the application origination workflow may be specified on this table.

47 Financial Inclusion Retail Accounts

Retail Accounts

Field name Description

Name Document name

Production Method Indicate whether the document will be produced via the Delivery module or via
Document Output (refer to Document Output user guide for details). Currently only
the Document Output method is supported by account origination, please use this
setting.
Document Type This the Document Output document type, defined on DO.DOCUMENT table, which
will be requested for this origination document.
Request Routine Routine responsible for handing off the document production request to either
Delivery or Document Output module. Use EM.XX.AO.REQ.DOCUMENT by default.
Request Parameter This is a multi-value list of parameters passed to the document production request.
In case of Document Output documents, three parameters are passed: customer
number (CustomerId), application reference (AccountApplicationId). These
parameters are used to fill a pdf document with the application data.

PW.ACTIVITY / PW.PARTICIPANT – Assignment of Stage Owners

The Account Origination workflow was developed based on the Process Workflow module. It is possible to assign
stage owners (or group of stage owners) to each stage of the origination workflow. The screenshot below
coordinates between the origination stages, stage owner IDs and takes the user through PW.ACTIVITY and
PW.PARTICIPANT as necessary. Two icons are provided on the right side of the screen. The first is to change stage
owners (PW.ACTIVITY) and the second is to amend owner details (PW.PARTICIPANT).

PW.PARTICIPANT (second icon to the right)

48 Financial Inclusion Retail Accounts

Retail Accounts

The stage owners for each stage are defined on this table. As an example, the record ID EAO.APP.INPUTTER has
been created to allow the user to specify the owners (the users or department / account officer codes) that are
able to input account applications in the origination workflow. Either department code or user ID may be inputted
but not both.
PW.ACTIVITY (first icon to the right)

The stage owner record ID created in PW.PARTICIPANT is selected here and linked to the actual process workflow
activity (EAO.05.APPLICATION.INPUT) that is used for the Application Input stage of the origination workflow.

Working with Account Origination

Access
Origination could be accessed from Role Based Accounts Menu or from the Single Customer View.
All in One RBHP > Accounts > Account Applications > New Account Application

Procedure
To create a new Account application, do the following:
1. Click on New Account Application
2. The system will launch a new record with a unique ID reference
3. Enter all the fields as described below
4. When everything has been completed click on the Commit icon.

49 Financial Inclusion Retail Accounts

Retail Accounts

Application Input Stage

Application input stage is a mandatory stage of Account Origination. Once you start entering data, the relevant
fields for input will become available, for example on selecting the Account Product, the Application Status,
Checklist Items and other relevant fields are populated and available for further input.

Field name Description

Application Input ID The system generates the next available reference number, the format is DO
(application code) followed by the Julian date (182 nd day of the year 2019) followed
by a 5-digit sequential number.
Existing Customer If the Account origination parameters table is configured to permit applications by
prospect customers, then this field is displayed to check whether or not the applicant
is an existing customer. The system uses the response to decide whether or not the
“update customer stage is required”.
Use the Create Prospect Customer link to create the prospect before proceeding with
the rest of input.
The system displays the respective prospect creation screen depending on the
customer type selected.
Customer ID Enter the Customer ID. The customer’s last name displays as enrichment characters
to the field. Validate that you are working with the correct customer record.
Customer Type The system indicates whether the existing customer entered is an Individual or a
Non-Individual customer. This is as some products e.g. Business Accounts, may only
be available to Non-Individual Customers and therefore the eligibility requirements
are different for each group.
Customer Role For the main customer, the Customer role is defaulted as Beneficial Owner. Expand
the customer field to add Joint customers if the product allows.
Tax Percent The tax liability percentage is defaulted 100 for the main account holder

50 Financial Inclusion Retail Accounts

Retail Accounts

ACCOUNT DETAILS
Field name Description

Account Product Select the product code from the lookup table. The value entered in this field will
manage the subsequent fields for input in this application.
Account Type The system displays the account type based on the account type selected. The main
account types in FI are Savings Accounts, Current Accounts and Share Accounts.
These are linked to the product during product group creation.
Currency The currency is defaulted from the product, if a product is offered in single currency
only. For multi-currency product, the currency applied for must be selected by user.
Minimum Balance If, for example in the case of savings accounts, a minimum balance was defined for
this product, then this is displayed as no input so the user could advise the customer
of the minimum balance condition for the account product.
Overdraft Limit For Current Account product types, this field is open for input if the product permits
overdraft facility.
The limit amount is defaulted from the product (if default amount exists) or entered
by the user. If approved, then, as part of account creation, limit records are
automatically created with the relevant limit parameters (from product record) as
well as the approved amount.
If limit amount entered falls outside of the minimum and maximum negotiation
bands in the product, an override or error message (depending on product definition)
is displayed to alert the user.
For other accounts, this field is not inputtable, unless if limit was included in the
product
Dividend Calc For Share Account product types, the system sets this field to ‘Yes’ by default but
allows changes.
This field is not inputtable for non-share account products origination.
Tax on Dividend For Share Account product types, the system sets this field to ‘Yes’ by default but
allows changes.
This field is not inputtable for non-share account products origination.
Statement Frequency Use the recurrence control icon to set the frequency with which account statements
will be produced for the account.
The statement frequency defined in the product is defaulted and can be changed if
the product definition allows for negotiation.

51 Financial Inclusion Retail Accounts

Retail Accounts

It is possible to change the existing frequency at which the statements are being
generated for an account by editing the same with Update Account Statement
Activity (ACCOUNTS-UPDATE-STATEMENT)
Passbooks For savings accounts, indicate whether or not are applicable to the account being
opened, if the product is defined to support passbooks.
Notes Capture any other relevant information for the application in this area.
Application Status Pull down to select the relevant status of the application for the current origination
stage.
For example, selecting a status with description ‘Waiting for Information will put the
process on hold, while ‘Account Application Input Complete’ will move the process
to the next stage. Status code behaviours are parameterized on the table
EM.AO.APPLICATION.STATUS.
Notes Capture any other relevant information for the application status selected on the
field above.

CHECKLIST ITEMS TAB

Field name Description

Status Items (e.g., documents) to be verified during account opening are automatically
displayed for the user to select one of three options: ‘Yes’ (I have seen and verified
the item, ‘No’ (I have not seen the item), ‘Override’ (the item is no longer needed
for the purpose of the current application. If ‘No’ is selected, then the current
application stage cannot be completed until a different option is chosen. ‘Override’
may only be selected if the setup allows the user to override the item.
The Option “Not Required” is automatically set by the system for optional items that
a user can manually set as required during the application processing.

Click on the icon to upload the checklist item sighted, if required.

Note If ‘Override’ is selected on the Item/Status field, then the ‘Notes’ field becomes
mandatory so the user can enter the reason why the item is no longer needed.

INTEREST AND CHARGES TAB

Where Debit or Credit interest have been defined for the product, the values are displayed in this tab so the user
can advise the customer of the same and update the values if negotiation is allowed. Only the options that are set
as ‘Negotiable’ in the product are open to changes; other values not inputtable.

52 Financial Inclusion Retail Accounts

Retail Accounts

Field name Description

Fixed / Floating Depending on the product set up, the system displays the Fixed rate, e.g., 10%, or the
Floating rate key, e.g. Sav Base rate, as shown in the example above.
Margin For the floating rate method, the margin operand (e.g., Add, Subtract, Multiply) and the
margin applicable are automatically defaulted from the product.
Effective Rate The system calculated the effective rate, that is, the base rate and the margin applicable,
and automatically displays the value on this field.
Up To The tier amount for which the interest applies is displayed here as per product set up.

Please refer to the Interest Property Class User guide for more details on the attributes related to Interest.

FACILITIES TAB
Facilities defined for the account product are presented in this tab. The screenshot below shows all the facilities
preconfigured for account products in Financial Inclusion.

Field name Description

Service Group The name of the facility is displayed.

Availability The availability of the facility, as per account product definition, is displayed.

Available facilities do not need to be opted in or out. However, if a user opts out
of these facilities, then an override message is generated to warn both the user
and authorizer that such facility will not be available for the account.
Optional facilities may need to be opted in or out depending on customer
choices.
Customer Option
The facilities are defaulted as opted in by the customer and can be opted out
as per the policy of the Financial Institution.
Note: Liquidation service must be opted into, for an account to be used as a Payout
account. E.g. as a disbursement account. Similarly, Funding service must be opted
into, for an account to be used as a Payin account. e.g. as a repayment account.

53 Financial Inclusion Retail Accounts

Retail Accounts

Eligibility Check Tab

The account applicant is checked against the product qualifying criteria set by the institution to be sure that they
qualify to apply for the account product.

Field name Description

Subject The system displays the customer number of the customer for whom eligibility
check is to be performed, the customer’s last name as an enrichment, and the
customer’s role in the application (Main Holder, Joint Holder on the right side.
Check Required? As eligibility check is mandatory for Account Origination, the system defaults this
field to Yes. If this value is changed to No, an error message will be generated.
Rule/Result The eligibility rule, e.g., check minimum age, is displayed, as well as the result of
the check for the customer, whether passed or failed. The set of rules executed
during the eligibility check is defined by the account product being applied for.
Perform Check? This is set to Yes and is no input field since eligibility check stage is mandatory.

SETTLEMENT AND SCHEDULE TAB

Where Credit Interest, Debit Interest or Charges apply to the account, settlement details are displayed. It is possible
that interest and charges accruing on one account of a customer are settled through other accounts of the
customer or a third-party account. As a standard in Account Origination, the settlement tab by default only permit
the other accounts or Beneficiary Ids of the customer in context as selected from a drop-down list. If, however, a
user types in a third-party account, the system accepts the input with an override message saying that the account
number entered does not belong to the customer

54 Financial Inclusion Retail Accounts

Retail Accounts

Field name Description

Interest / Charge Pay The product rule is automatically presented with ability to change if the field is negotiable.
method The options are:
Capitalise - if selected or defaulted from the product, then both Debit Int. Liq. Account and
Credit Int. Liq. Account fields are hidden. Interest amounts will be capitalized to the account
being originated.

Due - if selected or defaulted from the product, then either Debit Int. Liq. Account or Credit
Int. Liq. Account field becomes mandatory. For Current accounts, the Debit Int. Liq. Account
field becomes mandatory and Credit Int. Liq. Account is optional. For other accounts the
Credit Int. Liq. Account becomes mandatory and Debit Int. Liq. Account is optional.

Interest / Charge Select the Interest / Charge Liquidation account. This field is available for input only if
Liquidation Account Capitalization of Interest and Charges is set to No.
The Create Beneficiary link is used to create a new Beneficiary record which then becomes
available for selection. This is used for settlement processing to external accounts.
If Beneficiary Id is selected, then the selected Id is placed in the PAYOUT.BENEFICIARY field
of AA.ARR.SETTLEMENT for the account being originated.

In addition, the value in the ‘PP Prod External Payment’ field on the Account Origination
Parameters table is placed in the PAYOUT.PO.PRODUCT field of AA.ARR.SETTLEMENT for
the account being originated.

Note: The Create Beneficiary link is not available at Application Input stage for prospect
customers. Beneficiary records can be created again at Offer Product stage after Customer
activation.

Payment Schedule
Schedule type The schedule item is automatically defaulted as defined in the product. This is a non-input
field
Method The pay method is automatically defaulted as defined in the Credit / Debit Int.Pay Method
fields in the settlement tab.
Property The Interest / Charge property for which the schedule applies
Frequency The Capitalization or Pay frequency is defaulted from the product. The frequency may be
changed if the field is set as a negotiable in the product.

55 Financial Inclusion Retail Accounts

Retail Accounts

Review/ Approval Stage

This is the stage where the final approval or rejection of the application is done. The approving officer reviews all
data input made on the application so far (arranged in the top horizontal tabs) to form a final opinion and based
on these and other necessary information takes a final decision.
The following fields would usually be completed by the approving officer.

Field name Description

Status Unlike other stages, the status field has not been prefilled with any value. This is to
ensure that the approving officer pulls down on the lookup field to select a desired
status. Depending on the decision, status could be selected as Approved, Provisionally
Approved, Funding Approved, Declined, Client Withdrawal. The status “Expired Before
Approval” is automatically selected by the system for loan applications that have
passed certain number of days without approval. The number of days is set in the
EM.AO.PARAMETERS table.

Notes If the application was declined by the approving officer, then this field becomes
mandatory so the officer could enter reasons for declining the application.
Approval Notes The approving officer enters necessary notes relating to the approval.

Approved Limit The Overdraft amount applied for is displayed on the left-hand side of the screen,
while the amount approved is displayed on the right-hand side. This field only needs
to be completed if the limit approved is different from the amount applied for,
otherwise it should be left blank and the system will pick amount applied for as
amount approved.

Decision By Pull down on the lookup field and select the approving officer who is making the
decision.

56 Financial Inclusion Retail Accounts

Retail Accounts

Customer Update Stage

This stage is optional but automatically becomes mandatory if the field “Existing Customer?” in Application Input
stage is set to ‘No.’ The stage is to provide opportunity to take the customer record beyond prospect status so it
provides the full FI/ACL customer version to the user and also activates the customer record when the record is
committed.
Click on the Activate Customer link to complete the customer intake details and activate the customer. The version
is self-authorising.

Offer production Stage

At this stage the system is ready to produce the account application documents for the customer to sign. A sample
offer document is included with the Financial Inclusion Model Bank but each institution’s document templates will
be configured at implementation time.
To produce the offer documents, the user needs to complete the following fields:

57 Financial Inclusion Retail Accounts

Retail Accounts

Field Name Description

Credit Interest Pay Method Indicate whether credit interest is to be capitalised or paid out to the
customer
Credit Interest Account Select the customer’s account / Payee to be used for the interest payout.
Click on the “New Payee” link to create a new payee (Beneficiary)
Debit Interest Pay Method Indicate whether debit interest is to be capitalised or paid out to the
customer
Paying Account Select the customer’s account to be used as the payment account or the
payee for the external payment.
Click on the “New Payee” link to create a new payee (Beneficiary)
Interest Mode Indicate whether the credit interest is to be added back to the account,
to be paid into an existing Customer’s account, or paid to an external
account.

Interest Account Select the customer’s account / Payee to be used for the interest payout.

58 Financial Inclusion Retail Accounts

Retail Accounts

Charging Mode Indicate whether the account charges are to be collected from an existing
customer’s account or paid through cash, by depositing funds through
teller.
Charge Account Select the customer’s account to be used as the charge settlement
account.
DOCUMENT PRODUCTION
For The system displays the customer number of the account applicant with
the customer’s last name as an enrichment, and the customer’s role in
the application (Main Holder, Joint Holder) on the right side.
Produce Document The document parameterized for the product to be produced for the
above customer to acknowledge or sign is displayed here. Documents so
produced, depending on DO configuration, would print automatically,
but also are available for printing through the Single Customer View
Documents tab.
Produce Choice This field is automatically set to ‘Yes’ or ‘No’ for the document to be
produced, based on the parameters set for the product.

To view offer documents, open the “Documents” tab in SCV, identify the relevant document and click on the view
button.

59 Financial Inclusion Retail Accounts

Retail Accounts

60 Financial Inclusion Retail Accounts

Retail Accounts

Account Opening Stage

This stage automatically creates the accounts. No input is required, except if the user is not ready to open the
account. Other statuses may be selected manually as shown in the screen shot below.

Outputs for Account Origination

Account Applications Enquiry
This enquiry provides an overview of all account applications received and the time that it took to complete the
process is available in this report. This report can be useful for measuring performance against Service Level
Agreements and monitoring the volumes of applications received to identify trends.

Access
All in One RBHP > Accounts > Account Applications

61 Financial Inclusion Retail Accounts

Retail Accounts

Click on the view icon to select a record for investigation row. Results will be displayed as below.

Click on this icon to drill down and view the status of the application. Then click on the icon to proceed
with the application.

Click on this icon to view the Single Customer View of the account applicant.

Account Operations and Maintenance

Upon successful Account Origination, the Retail arrangement is created and the Account opened. Transactions
may then be posted through standard applications such as Teller, Funds Transfers, Payments etc. The account can
be viewed through the Account list in the Single Customer View or in the Account menu.
The Retail Account Overview will appear as shown below. This overview provides a 360-degree view of the account
including the product rules inherited by the account, the facilities available for the account, transactions and an
activity list.

Account maintenance activities can be performed through the “New Activity” link.

62 Financial Inclusion Retail Accounts

Retail Accounts

A detailed description of all account maintenance activities and other operations is available in the Transact Retail
Accounts user guide available here.
This user guide describes functionality that is unique to the FI/ACL product only.

AA Accounts List
This enquiry available on the Accounts page is a list of all account records in the system with drill down capability
as explained below.

Access
All in One RBHP > Accounts > AA Account > Live Accounts

This icon leads to the Single Customer View where details of the customer may be viewed.

This icon displays the Arrangement Overview screen for more information about the account.

Click on this icon to view transactions on the account.

Click on this icon to access the Teller menu for transactions e.g., Cash deposit, Account transfers, etc.

Click on this icon to request an adhoc Account Statement document. Next, click on the Request New Document
and commit the record. No input is required as the account number is auto populated.

63 Financial Inclusion Retail Accounts

Retail Accounts

Lastly, enter the start and end date of the transactions to be generated on the adhoc statement.

The document can then be accessed through the generated documents section in the same window. They are
available in the Document Repository within the Single Customer View of the customer.

64 Financial Inclusion Retail Accounts

Retail Accounts

The document will be displayed as follows.

65 Financial Inclusion Retail Accounts

Retail Accounts

Pending Records
The pending records enquiry displays a list of all with a user-initiated activity in INAU status e.g., Unauthorized
funds transfer or an account amendment activity. System generated activities tied to the unauthorized activity are
also displayed. Only the user generated activity needs to be authorized.

Access
All in One RBHP > Accounts > AA Accounts > Pending Records

Click on the icon to authorise / delete / edit or view the pending transaction through the Arrangement
Overview screen.

Inactive / Dormant Accounts

This enquiry displays a list of inactive AA accounts. These accounts are further classified into various status based
on the parameters set in the Dormancy product condition. E.g., Inactive, Dormant or Unclaimed.

Access
All in One RBHP > Accounts > Inactive Accounts > AA Accounts

66 Financial Inclusion Retail Accounts

Retail Accounts

Inactive Account Reset

To reset an inactive account back to active status, click on the icon next to account on the Inactive accounts
page. This will open the Reset Dormancy arrangement activity screen. Enter the effective date of the dormancy
reset and commit the transaction.

An override message indicating that the account is about to reset from its current dormancy status will be
displayed. Accept the override, commit and authorise the transaction.

Since the Reset is also done as an Activity, it will be possible to apply a charge for Resetting dormancy on an
Arrangement.
Please refer to the Transact Retail Accounts and the Dormancy Property Class user guides for more details on the
Dormancy functionality.

Closed Accounts
On this page, closed AA Accounts are displayed.

Access
All in One RBHP > Accounts > Closed Accounts > AA Accounts

Please refer to the Transact Retail Accounts and the Closure Property Class user guides for more details on AA
Account Closure.

67 Financial Inclusion Retail Accounts

Retail Accounts

CGAP Category A Reports

The CGAP (Consultative Group of Assistance to the Poor) Savings Accounts Reports are listed here.

Access
All in One RBHP > Accounts > Closed Accounts > Reports

Please refer to the Reports user guide for a detailed description of the various CGAP reports available on this page.
In some installations, these reports may be generated during the COB as a batch job. Refer to your IT team if you
are unsure.

Maximum Saving Balance

Some institutions like Credit unions are subject to regulatory limits which prohibit their members from holding
deposits in excess of a certain amount (for example €100,000 in savings across all accounts – although this does
vary by credit union).
The member’s share of joint accounts is included but adjusted accordingly – with 50% of the balance being
counted towards that member’s limit if the account is held jointly with one other member.
All balances held in member accounts should count towards the balance. That is, regular share accounts, current
accounts etc. The category for inclusion could be held on a parameter.
In order to allow credit unions to proactively manage member savings limits, a task is generated when total savings
balance nears a set amount, which can be set as a parameter to reflect business requirements.
Parameters are maintained in EB.PARAM record ALL-MAX.SAV.BAL.EXCEEDED.

▪ MAX.SAV.BAL – maximum balance requirement

▪ EXCLUDE.TXN.CODE – transaction codes to be excluded from the online check
▪ SAVING.ACCT.CATEG – account categories to be checked
▪ BALANCE.TO.MERGE – balances to be taken into the calculation for AA accounts
▪ WARNING.PERC.LIMIT – balance warning percentage (for reporting)

68 Financial Inclusion Retail Accounts

Retail Accounts

▪ DISPLAY.ENQ.IN.RBHP – to show / hide reports in role-based home pages

In exceptional cases some members may have agreed balances in excess of the credit union’s limit, for example,
they may have held the balance before the regulations came into effect. Maximum saving balance for customer
can be set on Amend Customer > Other Info tab.

Override is raised for credit transactions causing the maximum balance to be exceeded.

Note: for this to work, the record SYSTEM in ACCOUNT.PARAMETER needs to be updated like below.

69 Financial Inclusion Retail Accounts

Retail Accounts

Internal Accounts
Overview
The internal accounts refer directly to the accounts within your institution’s General Ledger. They are created and
maintained for bank’s internal operations and apply interest and charge conditions. Internal accounts can be
opened manually or automatically. For certain types of internal accounts (like cash accounts, suspense accounts,
inter-company accounts), where the category is parameterized in the respective application, the system generates
the accounts automatically.
NOTE: It is recommended to create the internal accounts manually for the local currency accounts, based on which
the system can automatically open any foreign currency account, as required. The accounts have to be manually
created for the non-parameterized internal account categories like fixed or movable assets account.
The internal accounts are not customer-based accounts and hence is not linked to any customer. The currency
and category are defaulted from the ID of the account. For example, if the ID of the internal account is
USD1122100010001, the Currency field is defaulted to USD and Category field is defaulted to 11221. Customer
is not updated for internal accounts, so it is mandatory to define the following fields while creating the account.
▪ Account Title
▪ Short Name
▪ Mnemonic
▪ Account Officer
The automatically created internal account has the text RECORD.AUTOMATICALLY. OPENED set in
the Account Title.1, Account Title.2 and Short Title fields. These can be amended later by the bank users. Some
internal accounts are used for special processing like inter-branch or inter-company accounts, position accounts
and multi-GAAP accounts.

Access

All In One RBHP > Finance > Internal Account

The following screenshot shows the Internal Account page in Financial Inclusion

70 Financial Inclusion Retail Accounts

Retail Accounts

The Internal account page displays a list of all internal account category codes (10000 – 19999).
Click on the “List All” icon to view the internal accounts opened under the category code.

Further drill down icons are available to view or edit the account record, or to view the transactions in the internal
account.
Internal Accounts are supported by the Accounts application only.

71 Financial Inclusion Retail Accounts

Retail Accounts

Nostro Accounts
Access

All In One RBHP > Finance > Internal Account

The following screenshot shows the Nostro Account section within the Internal Account page in Financial Inclusion

Click on the “New Nostro Account” icon to create a new account. Further drill down icons are available to view or
edit the account record, or to view the Nostro Account transactions.
The following screenshot shows a sample Nostro account

The key of nostro accounts is similar to customer account. It is the shadow or mirror account of the vostro account
maintained by the correspondent bank. So, the Nostro Account is opened with the correspondent bank as the
customer. For validating the Nostro accounts, the NOSTRO record in ACCOUNT.CLASS application should be
updated with the Category (marked for Nostro accounts) and Sector (pertaining to corresponding banks). The
Nostro account is identified based on the Category and Limit Reference field in the Account application. The
system defaults the Limit Reference field as NOSTRO, based on the setup in ACCOUNT.CLASS. These accounts are
marked for reconciliation. The statements and advices to these accounts are re-directed to the Nostro
reconciliation department for reconciliation purposes.

Detailed information on setting up NOSTRO accounts can be found in the AC Accounts user guide.

72 Financial Inclusion Retail Accounts