2. OBCL-FCUBS Integration
The integration between OL and CASA enables banks to do the following:
- Auto Liquidation
- Manual Liquidation
- Auto Rollover
- Manual Rollover
This chapter contains the following sections:
- Section 2.1, "Scope"
- Section , ""Tax, Fee and charge which are associated with liquidation/rollover event is debited from the account without ECA.
- 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 are the 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 in advance. ECA_BATCH_DAYS parameter maintained in cstb_param table. Only after receiving an approval from the DDA system, the system proceeds with liquidation of the schedule.
- 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 (PARTIAL_BLOCK_REQUIRED): If the flag is set as ‘N’, then ECA system should send a fail approval in case the total amount requested is not available in the account.
- 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.
- 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 the current status as ‘Pending’. A Java program would constantly poll the table for any pending 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 OUT queue of OL module, the response would be parsed by the JAVA program and update the status response status (Approved/Rejected) in COTBS_ECA_QUEUE table.
- When ECA block is successfully created on the accounts (Partial / Full), liquidation happens in OL module and perform OL accounting with handoff status as 'No'.
- ECA request for auto liquidation should not be created when future dated payment is requested for the same contract.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 needs to be manually authorized. Hence, manual payment is deleted for unauthorized contract, an 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.
Actions
System Response
After logging payment in ECA queue for approval, if you try to delete the payment before getting the response, then the status is W.
The system should undo ECA if it gets approved response (Reconcillation mechanism)
After getting ECA response as ‘Approved’, if you try to delete the payment
The system should undo ECA with the approved block number
ECA Handling for Manual Rollover
- After you initiate the rollover (Normal/Consol/Split) through application, OL module should place an ECA request for the amount to be debited from customer.
- When the ECA request is approved by the DDA system, the system allows you to authorise the rollover. Hence, the rollover is deleted and undo ECA should be sent to the DDA system.
- In case where actual accounting to DDA system is not happened post ECA approval, OL module should generate both actual entries for roll event with block number to release from DDA system.
Account Interface and Handoff
- For CASA, where debit happened excluding force debit components, have the block number in the daily log table.
- 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.
- External Account Check (EAC) is done wherever the credit happens to CASA account to avoid failure in external system side (Check for No credit, No debit,Frozen,Deceased)
- Java poller constantly polls the daily log table and pick the records
which are authorised and handoff yet to be done.It then generates the
accounting request with necessary details and put in IN queue.After getting
successful response from external system, handoff status is changed.If
anything failed while giving external handoff, external system throws
a proper exception code and same has been logged in OL side.
Debit request+ <ECAREFNO>
ECA Block is released
Debit request
Amount is debited from withdrawable balance
- Credit and Debit advice should be generated only after the feedback from the DDA system after posting entries to the customer account.
- OL module should be capable to handoff the entries online by generating XML request as well as handoff entries through batch process at regular intervals during the day.
Force debit Components
Tax, Fee and charge which are associated with liquidation/rollover event is debited from the account without ECA.
2.2 ECA handling scenarios for Corporate Loan Liquidation
This section contains the following topics:
- Section 2.2.1, "Single CASA Account with Full liquidation"
- Section 2.2.2, "Different CASA Account with Full Liquidation"
- Section 2.2.3, "GL Account used for Liquidation"
- Section 2.2.4, "One CASA and GL Account used for Liquidation"
- Section 2.2.5, "Single CASA Account with Partial Liquidation"
- Section 2.2.6, "Manual Liquidation with Single CASA or Multiple CASA Account"
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 Banking 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.
- ECA_CHECK_REQD should be 'YES' in CSTB_PARAM table for standalone system.
2.3.1.2 Maintenances
Complete the following maintenances in Oracle Banking 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 |
COTB_ECA_QUEUE |
ECA request details |
COTB_ECA_QUEUE_DETAIL |
ECA request components 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
This section contains the following topics:
- Section 2.4.1, "Maintaining External System Details"
- Section 2.4.2, "Maintaining Queue Details for ECA system"
- Section 2.4.3, "Maintaining Queue Details for External Accounting System"
- Section 2.4.4, "Configuring Accounting System for Host Code"
- Section 2.4.5, "Viewing ECA Queue Summary Details"
2.4.1 Maintaining External System Details
In this screen external system name and description are maintained. This information is used in the Queue Details (PIDECAQU), Branch Creation (STDCRBRN), and Customer Account Creation (STDCRACC) screens.
To invoke this screen, type ’PIDECALV’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.
External system
Specify the external credit approval system.
Description
Give a brief description in the external credit approval system.
2.4.2 Maintaining Queue Details for ECA system
You can maintain the external system details from which credit approval for debit entries has to be obtained in the ‘External Credit Approval System’ screen.
To invoke this screen, type ‘ PIDECAMT’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.
External Credit Approval System
Specify the external credit approval system.
Description
Give a brief description in the external credit approval system.
Preferences
Inqueue JNDI Name
Specify the name for ECA response queue configured in Application server.
Outqueue JNDI Name
Specify the name for ECA request queue configured in Application server.
Initial Context Factory Class
Specify the initial context factory class.
Context Provider URL
Specify the context provider URL.
Queue Factory JNDI
Specify the queue factory JNDI.
Timeout in seconds
Specify the time out in seconds. If there is no response within this time, then the request is marked as timed out.
Inter System Bridge GL
Specify or select the inter system bridge GL.
External System User ID
Specify the external system user id.
Queue Authentication
Queue Authentication Required
Select this check box to indicate that Queue Authentication is required for the External Credit Approval System.
User ID
Specify the required User Name.
Password
Enter the password. The User Id and Password that you specify is used for verification purposes. The password is encrypted and stored.
ECA System Class
Select the ECA system class as ‘External’ or ‘FCUBS’.
Status Mapping
External Response Code
Specifies the code assigned to a status by external ECA system.
Status Description
Specifies the status description of the external response code.
System Status
Specifies the ECA status derived in the system. Choose among the following:
- Reject
- Override
- Approve
Automatic Cancellation
Select whether automatic cancellation of the payment is applicable or not. You can select Yes only if the response codes are mapped to Rejected status.
2.4.3 Maintaining Queue Details for External Accounting System
While posting the accounting entry, ECA reference number is provided to unblock the blocked amount. Debit which does not have an ECA reference number goes as a normal debit.
If different External Accounting System and ECA systems are maintained:
- During accounting handoff, an additional intimation is sent to the ECA system. This is to indicate the ECA system that the accounting for the transaction is handed off.
- The ECA system’s reference number is also shared to the External Accounting System along with accounting handoff.
- Thus, the ECA and the External Accounting Systems need to reconcile on releasing the amount block posted earlier and execute the debit transaction.
You can maintain the details of External Accounting System to which accounting entries handoff is sent during transaction processing. The accounting entries generated by OBCL system is handed off to this accounting system.
To invoke this screen, type ‘ PIDACCMT’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.
2.4.4 Configuring Accounting System for Host Code
You can configure the accounting system using host code in the ‘Host Parameter’ screen.
To invoke this screen, type ‘PIDHSTMT’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.
Specify the following details
Host Code
Specify the host code.
Host Description
Specify the brief description for the host.
Accounting System Code
Specify the accounting system code
2.4.5 Viewing ECA Queue Summary Details
ECA Queue Summary screen contains details on the transactions between OL and external system.
To invoke this screen, type PISECAQU’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.
You can search records based on the following parameters:
- Transaction Reference No
- Network code
- ECA Amount
- Customer No
- Requested Date
- Authorization Status
- Cross Border Contract Reference Number
- Activation Date
- File Reference Number
- Payment Transaction Type
- ECA Currency
- Current Status
- Response Date
- Maker Id
- Payment Type
- Customer Service Model
- Queue Reference No
- Transaction Branch
- Module
- Response Status
- ECA System Code
- Checker Id
- Source Code
Click ‘Search’ button with or without entering any of the above search parameters. All records matching the search criteria are displayed. To view a particular record double-click on the desired record displayed in the list of records. The details pertaining to each record is displayed: