Core Banking 21.1.1001

September 30th, 2021

This minor release of FintechOS Core Banking comes with quite a few perks and improvements aimed to make bank offers to customers more diversified, simplifying the bank employees' daily tasks and lowering the time needed for the loan approval process.

Improvements

Better Loan Approval Performance

Our team spent a great amount of time and effort improving the performance of the loan creation process. Now the loan approval has a minimized response time due to refactoring, allowing for faster system responses.

Core Banking-Specific Customer Page

A new Customer page is now available through the Portal's Customer Core menu, designed specifically for the Core Banking business requirements. When adding a new customer using this page, you are required to fill in less information than the Customer page accessible via the Single Customer View menus.

Read more about customers in the dedicated section of the user guide.

Limits for Individual Customers

Starting with this release, both legal entity and individual customers can be added to groups. This can be helpful if you need to monitor group exposure for a household or a company, including its shareholders together.

A new Core Banking system parameter,LimitMandatoryForIndividuals, allows you to configure the behavior of limits, specifically whether the limits should be validated for individual customers or only for legal entity customers. When the parameter's value is True, limit validations for a group containing individual customers happen the same way as for groups composed solely of legal persons.

Revolving Limits

With the introduction of the revolving limits concept, banks can decide whether a limit's available amount is replenished on repayment, thus lowering the need to grant other limits to the same customer. When creating a limit, you can specify if it has a revolving behavior by selecting the Is Revolving field. You can also mention if the replenishment of the available amount should be made on each repayment of the principal or on loan contract closure, depending on the value of the On Repayment field. Both Is Revolving and On Repayment fields are selected by default and you must change their values according to your needs.

Read more information about the calculation of the available limit amount on the Limits page. The FTOS_CB_AddUpdateCustomerLimit endpoint was also updated to accommodate the new parameters.

Future & Past Due Installments Reports

The dashboards were enriched with two new reports that enable you to see at a glance all the future or past due installments:

• Future Installments report, displaying the list of installments that are due in the following X number of days from the current date, where X is a default value taken from the DaysFutureInstallmentsReport Core Banking system parameter.
  
  

• Past Due Installments report, displaying the list of installments that were due but not have been fully paid, no matter their origin - normal installments, penalties, transaction fees etc, - in the last Y number of days from the current date, where Y is a default value taken from the DaysPastDueInstallmentsReport Core Banking system parameter.
  

You can change the number of days for reports generation directly from the report pages, or you can modify the default number of days by altering the values of the new DaysFutureInstallmentsReport, respectively DaysPastDueInstallmentsReport Core Banking system parameters.

The new reports are also accessible via API calls using the FTOS_BP_GetDataSourceFutureInstallmentsReport and the FTOS_BP_GetDataSourcePastDueInstallmentsReport endpoints.

Configurable Bank Account Transactions Processing

Starting now, transactions performed on bank accounts can be processed either at the moment when the transaction was approved or within a queued process, with the aid of a specialized job. You can specify which transaction types should be processed on the spot with the aid of a new field, Real Time Process, found at the transaction type level, within the Add/ Edit Transaction Type page.

Each time a transaction is performed on a bank account, the system verifies its transaction type's Real Time Process field. If the value is True, then the transaction is processed right away. If the value is False, then the transaction is placed in a queue. The Bank Account Transaction Queue Processing scheduled job runs every 1 minute, taking the top 10 records from the queue that were not yet processed, and processing the transactions. Any errors encountered on processing are logged in the errorMessage attribute. The Bank Account Transaction Queue Cleanup scheduled job runs once each night and cleans up the transaction records already processed without errors.

The transactions within the queue can be viewed by users with administrator rights from the Bank Account Transaction Queue menu:

Read more information about real-time or queued transaction processing on the Transaction Types Used in Core Banking page.

Penalty Interest Calculation Including Grace Period

The calculation of the penalty interest applied to contracts is now configurable with regards to the grace period defined at the banking product level.

Thus, if the Penalty for grace period field is selected in the banking product, the penalty interest is applied on the loan contract without taking into consideration the grace period defined at the contract level. If the grace period passed and the customer didn't pay the due amounts, the penalty for grace period is calculated as the difference between the system date and the due date. If the field is unselected, the penalty interest is applied on the loan contract taking into consideration the grace period defined at contract level, and calculated as system date - due date + grace days for repayment.

Payment Schedule For Any Number of Days

The payment schedules became more flexible and permissive, allowing you to create such schedules for any number of days, with a linear calculation method. For example, you can now create payment schedules with the due date at exactly 10, 15 or 30 days.

Apart from special attention required when defining the banking product, make sure that the measurement unit for the Periodicity Type field in the Details tab matches the Period Type's value in the Availability tab and both match the Measurement Unit's value at the used payment schedule level. Keep in mind that the schedule and periodicity types are filtered on measurement units: days, weeks, months. At the contract level, for payment schedules with periodicity type Days, the holiday shift is automatically False and cannot be changed, and the first due date is calculated with Days measurement type.

The FTOS_CB_AddUpdateContract endpoint was also updated to accommodate the First Due Date value.