2. OFCL-FCUBS Integration
The integration between OL and CASA enables banks to do the following:
- Auto Liquidation
- Manual Liquidation
- Auto Rollover
This chapter contains the following sections:
- Section 2.1, "Scope"
- Section 2.2, "ECA handling scenarios for Corporate Loan Liquidation"
- Section 2.3, "Prerequisites"
- Section 2.4, "Integration Process"
2.1 Scope
This section describes the activities that take place in each system and its impact on the other.
This section contains the following topics:
- Section 2.1.1, "Integration Scope with FCUBS Co-deployed with OL"
- Section 2.1.2, "Integration Scope without FCUBS Co-deployed with OL"
2.1.1 Integration Scope with FCUBS Co-deployed with OL
If FCUBS is co-deployed with OL, then API or dynamic call is used to check the available balance.
2.1.2 Integration Scope without FCUBS Co-deployed with OL
The following integration activities that take place in Oracle Corporate Lending.
ECA Request for Auto Liquidation
- As part of Loans batch process, amount due for liquidation for a contract is sent to the DDA system for approval. Only after receiving an approval from the DDA system, the system proceeds with liquidation of the schedule.
- Oracle Corporate Lending (OL) module should send a consolidate request to the ECA one for each contract. As the settlement account is configured for each component in Corporate Lending, multiple settlement accounts for a contract is possible. OL module for a due date should group the total amount due from each account and generate one ECA request for a contract and due date.
- The due amount when sent as part of ECA request should be in account currency.
- As part of the ECA request, OL module should send the following additional
preferences configured at a contract / product level.
- Partial Liquidation Allowed: If the flag is set as ‘N’, then ECA system should send a fail approval if the total amount requested is not available in the account.
- Minimum amount for Auto Liquidation: This flag is considered if partial liquidation is allowed. If the amount available is less than the minimum amount sent, then ECA request should be failed for the account.
- OL system should log the overrides received as part of ECA response and it should be available for viewing in ECA Query screen.
- In case of multiple schedules that are due from the customer as part of Auto Liquidation, OL system should place a ECA request for the earliest schedule due from the customer. Only when the schedule is completely settled and processed in OL system, request for next schedule should be placed.
- Before placing a request for a schedule, OL system should move the ECA request details to history table.
- First process in OL Batch would compute the amount due for a schedule as part of Auto liquidation and place the request into ECA table with status as ‘Unprocessed’. A Java program would constantly poll the table for any unprocessed records and transform the records into an ECA request XML and place the same into a IN queue of the external system configured.
- Upon receipt of any response from the DDA system in the IN queue of OL module, the response would be parsed by the JAVA program and update the status response status.
- A background job picks up the records where ECA block is successfully created on the accounts (Partial / Full), then process the liquidation in OL module and perform OL accounting.
- ECA request for auto liquidation should not be created from OL module where GL is chosen as settlement account. For example, for a contract having Principal and Interest as components and GL is chosen as a settlement account then no ECA request should be created by OL module. However, if GL is chosen only for Interest and for Principal a valid customer account is chosen as settlement account, then ECA request should be created only for Principal component.
- When Auto Liquidation process is run for more than one day as part of EOD processing (due to holiday settings), then Auto liquidation for the schedules that are due for a day can be processed only after Auto liquidation is processed successfully for the preceding day.
- In a situation where ECA block is successful, but subsequent processing in OL module fails auto retry mechanism should be available in OL module.
ECA Handling during Auto Rollover
- For contract marked for Auto Rollover, as part of EOD processing of Auto Liquidation system should place the ECA request for the liquidation amount (or any special amount) that should be debited from the settlement account of the customer.
- Upon receipt of successful response from the ECA system, subsequent rollover processing should continue in the OL module.
ECA Handling for Manual liquidation
- After you capture the necessary payment details and click ‘Save’, OL module should place an ECA request for the amount requested for the payment.
- There should be an additional field in the payment screen to display the ECA process status. This should display the status of the ECA request.
- When the ECA request is approved by the DDA system, it is auto authorized. Hence, manual payment is deleted, undo ECA should be sent to the DDA system.
- OL module should process the payment request and update the cashflow tables and post liquidation entries as part of back ground process and payment status will be in unauthorized state.
- Authorisation of payment is possible only after the liquidation process is completed and entries are posted.
- Similarly OL module should generate reversal entries upon reversal of loan payment. In case where actual accounting to DDA system is not generated post ECA approval, OL module should generate both actual entries for liquidation with block number and its reversal.
Account Interface and Handoff
- As part of accounting interface OL module should hold two handoff status, one to indicate whether the customer account related entries handoff to DDA system and another to indicate GL entries handoff to GL system.
- In addition, there should be a provision to get the feedback from the DDA system whether posting is completed for the entries handoff or not. This should be displayed in the accounting entries screen for the event.
- Credit and Debit advice should be generated only after the feedback from the DDA system after posting entries to the customer account.
- A background process should check for any authorized entries in the local daily log table and transform the entries and send the same for posting to the DDA and/or GL system.
2.2 ECA handling scenarios for Corporate Loan Liquidation
2.2.1 Single CASA Account with Full liquidation
Component |
Amount Due |
Account |
ECA Approved Amount |
Principal |
50000 |
CASA1 |
50000 |
Interest |
10000 |
CASA1 |
10000 |
2.2.2 Different CASA Account with Full Liquidation
In this case OL module generates a single ECA request that contain details amount due from two accounts.
Component |
Amount Due |
Account |
ECA Approved Amount |
Principal |
50000 |
CASA1 |
50000 |
Interest |
10000 |
CASA2 |
10000 |
2.2.3 GL Account used for Liquidation
In this case request is not sent to ECA system, however it is marked as approved by OL module in ECA tables and it proceeds with liquidation processing.
Component |
Amount Due |
Account |
ECA Approved Amount |
Principal |
50000 |
GL1 |
50000 |
Interest |
10000 |
GL2 |
10000 |
2.2.4 One CASA and GL Account used for Liquidation
In this ECA request is sent only for CASA account and the GL it is marked as approved automatically. Liquidation processing happens irrespective of whether the ECA request is successful for the CASA account.
Component |
Amount Due |
Account |
ECA Approved Amount |
Principal |
50000 |
CASA |
50000 |
Interest |
10000 |
GL1 |
10000 |
2.2.5 Single CASA Account with Partial Liquidation
In this case, the system proceeds with allocating the approved amount based on liquidation order specified at the product level.
Component |
Amount Due |
Account |
ECA Approved Amount |
Principal |
50000 |
CASA1 |
50000 |
Interest |
10000 |
CASA1 |
10000 |
2.2.6 Manual Liquidation with Single CASA or Multiple CASA Account
In this case ECA request is sent with Partial allowed as ‘N’, hence the request is marked as failure if the full amount requested is not available.
Component |
Amount Due |
Account |
ECA Approved Amount |
Principal |
50000 |
CASA1 |
50000 |
Interest |
10000 |
CASA1 |
10000 |
2.3 Prerequisites
This section contains the following topics:
2.3.1 Prerequisites in Oracle FLEXCUBE Oracle Lending
The prerequisites for this integration are as follows.
2.3.1.1 Parameter Setup
- If HANDOFF_TYPE value is ‘SYNC’ in CSTB_PARAM table, then the balance check is performed using API or dynamic call.
- If HANDOFF_TYPE value is ‘ASYNC’ in CSTB_PARAM table, then the consolidated amount to be requested is logged in ECA tables. Further processing, is performed by job.
2.3.1.2 Maintenances
Complete the following maintenances in Oracle FLEXCUBE Corporate Lending to enable the integration.
Queue Name |
Purpose |
ECA_REQ_OUT |
Request to external system |
ECA_RES_IN |
Response from external system |
Table Name |
Purpose |
OLTB_ECA_QUEUE |
ECA request details |
OLTB_QUEUE_ACTION_LOG |
Account-wise details |
Note
The following data in OL module must be in sync with those maintained in external system.
- Branch
- Contract Reference Number
- Account number
- Currency
- Dr/Cr
2.4 Integration Process
ECA Queue Summary screen contains details on the transactions between OL and external system.
To invoke this screen, type ‘OLSECAQU’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.
