0% found this document useful (0 votes)
43 views11 pages

RL11 Batch

Batch processes are automatic functions that are run as mandatory beginning and/or end of day processes in the FlexCube banking system. They include processes like loan account initiation, calculation of accruals and interest, auto payments and disbursements, rate revisions, maturity processing, notice generation, and statement generation. These batch processes are configured and run sequentially through the Automatic Process Definition screen to ensure important banking tasks are performed automatically at the end of each day.

Uploaded by

vinoth51
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
43 views11 pages

RL11 Batch

Batch processes are automatic functions that are run as mandatory beginning and/or end of day processes in the FlexCube banking system. They include processes like loan account initiation, calculation of accruals and interest, auto payments and disbursements, rate revisions, maturity processing, notice generation, and statement generation. These batch processes are configured and run sequentially through the Automatic Process Definition screen to ensure important banking tasks are performed automatically at the end of each day.

Uploaded by

vinoth51
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 11

Batch Processes

Batch Processes 377

Introduction
The events that are to take place automatically are triggered off during what is
called the Batch Process. The batch process is an automatic function that is run as
a mandatory Beginning of Day (BOD) and/or End of Day (EOD) process. During
EOD, the batch process should be run after end-of-transaction-input (EOTI) has
been marked for the day, and before end-of-financial-input (EOFI) has been
marked for the day.

Configuring the CL Batch Processes


You have the facility to configure the batch processes to be executed either at
EOD or BOD or both, as per the bank’s requirement. This is achieved through the
‘Automatic Process Definition’ screen. To access this screen from the Application
Browser, select Retail Lending and choose Automatic Process.

In this screen, you can amend the order of the various operations in the CL batch
and choose to trigger them at EOD or BOD or both.

The default configuration is given below:

Batch Operation BOD/EOD

Forward Init of Loan Accounts BOD

Retail Lending
378 FLEXCUBE Corporate

Batch Operation BOD/EOD

Calculation EOD/BOD

Accruals EOD/BOD

Auto Liquidations EOD/BOD

Auto Disbursements BOD

Rate Revisions BOD

UDE Cascade EOD

Maturity processing – Rollovers , Auto Closures BOD/EOD

Automatic Status Change Processing BOD

FEES BOD

INTP (Interest Posting) BOD

Billing & Payment Notices BOD

Statements generation EOD

Penalty Computation BOD

Forward VAMIs BOD

Revaluation EOD

Readjustment EOD

These batch processes are factory shipped for your bank.

Retail Lending
Batch Processes 379

Defining Batch Processes

The CL batch processes are explained briefly:

Forward Init of Loan Accounts

Loan accounts maintained in the system are classified into two types:

 Active
 Inactive

When loan accounts become Active, the BOOK event is triggered for the Loan
and you can specify a Value Date for the loan during this event.

This batch identifies all the accounts that are due for initiation on that day, at
BOD and the INIT event is triggered for these accounts. The current system date
will be taken as the value date for these accounts.

Re-Calculation

Loan parameter alterations directly affect the computation of accruals. This batch
identifies such changes made to loan accounts, both at BOD and EOD. Further, it
recalculates the accruals based on the altered loan components.

Accruals

This batch passes all the recalculated accrual changes required for the
components. It is triggered, both at BOD and EOD.

Auto Liquidations

This batch processes the payments that are configured as auto payments and is
triggered both at BOD and EOD.

Auto Disbursements

Disbursement schedules are maintained for products. As part of BOD process,


the DSBR events for the accounts will be triggered.

Retail Lending
380 FLEXCUBE Corporate

This batch processes these schedules at BOD, which enables the DSBR events of
the accounts to be initiated.

Rate Revision

As part of BOD program, this batch processes the Floating Rate revision
schedules for products.

UDE Cascade

This batch is triggered at EOD in case of UDE value changes. The changes in
UDE values are applied to all the affected accounts.

In case, a single account requires a UDE Change/Cascade, it can be performed


online for that account alone. Such accounts are then excluded from this batch.

Maturity Processing

Maturity processing of loans is performed if the maturity date falls at BOD of a


particular day. This results in either Auto Closure or Rollover of loans.

 Auto Closure: Loans that are liquidated on maturity are subject to Auto
Closure, during maturity processing.
 Rollover: Loans that have auto rollover maintained are rolled over during
maturity processing.

Status Change Processing

Certain accounts have automatic status changes, wherein the SDEs required for
status change are evaluated. In such cases, this batch detects status changes at
BOD. Once this is done, appropriate status change activities are triggered.

Notice Generation – Billing, Payments

For each loan, the number of days prior to which a Notice is to be generated is
evaluated. In case of loans that carry dues, the Notice is generated as specified in
the notice days maintained for the product. This batch is processed at BOD.

Retail Lending
Batch Processes 381

Statement Generation

At EOD, the statement is generated depending on the statement frequency and


other statement based maintenance actions specified.

Forward VAMI

At BOD, this batch processes all value dated amendments that are booked with
the date as Value Date.

Penalty

Penalty computations are evaluated at BOD by this batch. Any grace period
maintained will have to be considered during this calculation. On completion of
the grace period, the penalty components are computed from the due date till the
current date.

Revaluation

At EOD, revaluation of assets and liabilities to the LCY are carried out.

Readjustment

This batch is processed at EOD. It is triggered in the presence of Index currencies


that are not treated as a part of revaluation. It handles readjustments based on
new index rates.

Initiating the Batch Process

If you have opted to trigger the CL batch programs at EOD, the same will be
executed as part of the ‘End of Cycle Operations’ after marking the ‘EOTI’ for the
day. If the trigger is maintained as ‘BOD’, the programs will be executed before
the start of ‘Transaction Input’. However, the programs will be triggered both at
EOD and BOD if you opt to trigger it at both the instances.

You also have the option to execute the batch programs through the ‘CL Batch’
screen. To access this screen from the Application Browser, select Retail Lending,
choose CL Batch and then select End of Cycle.

Retail Lending
382 FLEXCUBE Corporate

You can opt to execute the processes as per the sequence maintained in the
‘Automatic Process Definition’ screen. To do this, check the ‘Run Sequentially’
option.

Multi-threading of batch processes

The CL Batch process handles multi threading. The number of parallel processes
and the interval between processes is maintained as part of ‘CL Branch
Parameters’.

Refer the section titled ‘Maintaining Branch Parameters’ in the ‘Maintenances and
Operations’ chapter of this User Manual for details.

The accounts are split into multiple groups which can be processed in parallel for
a particular sub process. Hence, all non conflicting parallel groups will complete
the sub process after which the next sub process is taken up and so on. There is
also an option to run it purely sequentially as shown above.

Excess Amount Allocation Batch


The Excess Amount Allocation batch is run to allocate the transfer amount
available for each member against the outstanding balance in the corresponding
loan accounts.

Retail Lending
Batch Processes 383

A member account is owned by a single member, but a loan account can be co-
owned by several members in a certain ratio. Each member could be a borrower
in multiple loans. For these reasons the amount allocations are necessitated.

The allocation process considers the following important parameters:

 % liability of each member in each loan where he is the borrower


 Transfer amount available per member
 Amount due (based on % liability) per member

To enable this fund allocation the rebate batch is run at the bank level. Common
Settlement Account maintained in ‘Rebate Account Preferences’ screen is used as
the ‘Common Bridge Account’. This will have the combined balance of all the
member accounts, which can be utilized for loan re-payment. The Rebate account
processing batch will provide the details like the member account number
(CASA account), the member (CIF number) and the excess amount for the
member. This data will act as the input for this batch program.

The batch does the following operations:

 It will get the due details for the next schedule of each loan, along with the
Liability Split %. This will include the overdue amount, if any.
 Allocate the excess amount of each member to his loans, with the earliest
unpaid schedule first.

Retail Lending
384 FLEXCUBE Corporate

 The due date of the schedule will be considered by the allocation batch for
allocating the payments. The batch will ensure that the available amount is
used to make advance payment for the immediate next component due
before considering the next.
 While allocating the amount for the next schedule, the available amount
will be available amount minus the amount already allocated against the
previous schedule.
 With this info, CL payment will be triggered for each loan account. This will
be an advance payment (not Pre payment) for an aggregate amount and
will be initiated according to the liquidation order maintained for the
components.
 On successful payment, process status will be changed to ‘P’ for all the
records with this Loan account number.
 Status will be changed to ‘E’, in case of any error during the payment. As
per the current functionality, the error details will be available in the
exception table.
 After correcting the errors, you can re-initiate the process which will
exclude the already processed loan accounts.
 Further generation of Payment advice will derive the amount after
considering the amount paid through this batch process.

Interest Posting (INTP Event)

You need to make a provision to post an income into a separate GL. This income
is the interest which you pay to the customer who has a loan account. On the
interest posting date, a transaction occurs to move the receivable and the income
from one GL to another. This transaction distinguishes between receivables from
the income which is due and not due. Also, this interest posting is applicable for
the main interest component only.

The INTP event runs at the BOD for a loan product against which it has been
defined.

The following points are noteworthy:

Retail Lending
Batch Processes 385

 You can pick the INTP event during the loan product definition and
maintain the accounting entries against this event. To recall, you need to
click on the ‘Events’ tab in the ‘Consumer Lending Product’ screen where
you specify the various events which need to be run.
 At the time of loan account creation, FCC populates the events diary with
one record of the INTP event for each schedule due date. This has the status
as ‘Unprocessed’. This is done for the main interest component schedule
only.
 The system also creates a record for the end of each calendar quarter during
the moratorium period in the case of amortized loan products.
 Any rebuilding of repayment schedules results in the rebuilding of records
in the events diary.
 The batch process picks up all the unprocessed INTP records from the
events diary having the execution date on or before the current application
date. The process is limited to the active accounts belonging to the current
branch.
 The amount and date of due for the main interest component is fetched
from the component schedule due details.
 The accounting entries get passed on the schedule due date or the calendar
quarter end, as defined for the event INTP through the ‘Consumer Lending
Product’ screen under the ‘Events’ tab pertaining to a loan product
maintenance.
 For term loans, the transaction posting date is the same as schedule due
date of the main interest component. The same is followed for amortized
loans also.
 For an amortized loan with a moratorium period, the transaction posting
date is the end of the calendar quarter and the end of the moratorium
period. If the moratorium period is different from the end of the calendar
quarter, the entries passed will not tally with the actual amount due. This
difference gets passed on the schedule due date of the moratorium period.
 There are no changes in the INTP event execution behaviour in case of a
partial pre-payment.

Retail Lending
386 FLEXCUBE Corporate

 If a loan is getting pre-closed with a complete settlement, the system does


not wait till the schedule due date or calendar quarter end for passing the
INTP entries. It posts the interest accrued till the current date on the date of
the pre-closure.
 In case of any failures during the INTP batch process, the system logs the
error details for the account and processes the subsequent accounts.

Retail Lending

You might also like