2. OBCL Integration

2.1 Common Core Maintenances

The following are the common core maintenance that needs to be completed for FCUBS, Payments, and ELCM systems integration.

Section 2.1.1, "Configuring Accounting System for Host Code"
Section 2.1.2, "Maintaining Integration Parameters"

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

Payment System

Specify the payment system.

ELCM System

Specify the ELCM system.

OBCL Integration System

Specify the external system. For example, OLINTSYS

2.1.2 Maintaining Integration Parameters

You have to maintain integration parameters for ‘External LOV’ and ‘ELCM/Payment/OL Utilization’. This maintenance must be done for all branches. This maintenance is done through ‘Integration Parameters Maintenance’ screen.

To invoke this screen, type ‘IFDINPRM’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

Example of Integration Parameter Maintenance screen for Payments

Example of Integration Parameter Maintenance screen for ELCM

Example of Integration Parameter Maintenance screen for OBCL

You need to maintain the integration parameters for the following:

External Lov – ExtLovService
ELCM Utilization/Payments/OBCL – ELUtilizationService/PMSinglePaymentService/FCUBSCAService

External Lov

External System - External system name is specified here. For example, OLELCM, INTBANKING for Payments, and OLINTSYS for OBCL.
Service Name – The service name for which the maintenance is done. For example, ELUtilizationService for ELCM, ExtLovService for External LovExtLovService, and PMSinglePaymentService for Payments, and FCUBSCAService for OBCL.
Communication Channel – The communication channel like REST, CUSTOM, WEB SERVICE, and so on are specified here.
Communication Mode – The communication mode can be SYNC/ASYNC.

Note

Rest Service need not be maintained for OBCL.

Rest Service IP – You have to maintain the IP address. For example, ELCM IP, Payment IP.
Rest Service Port – You have to maintain port details. For example, ELCM Port, Payment Port.
Rest Service Pattern - You have to maintain rest service pattern. For example, LovService
Rest Service Context – You have to maintain rest service context. For example, FCJNeoWeb
External User - ELCM/Payment/OBCL user should have access to all branches and autoauth

ELCM Utilization/Payment/OBCL

External System - External system name is specified here. For example, OLELCM.
Service Name – The service name for which the maintenance is done. For example, ELUtilizationService for ELCM, ExtLovService for External LovExtLovService and PMSinglePaymentService for Payments.
Communication Channel – The communication channel like REST, CUSTOM, WEB SERVICE, and so on are specified here.
Communication Mode – The communication mode can be SYNC/ASYNC.
WS Service Name – The service name needs to be maintained here. For example, ELUtilizationService, PMSinglePaymentService, and FCUBSCAService.
WS Endpoint URL – The WSDL of the services are maintained here. For example, ELCM utilization/Payment/CA service WSDL link
WS User – ELCM/Payment user should have access to all branches and autoauth.
External User - ELCM/Payment/OBCL user should have access to all branches and autoauth.

2.2 Oracle Lending and CASA 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.2.1, "Scope"
Section 2.2.2, "Integration Scope with FCUBS Co-deployed with OL"
Section 2.2.3, "Integration Scope without FCUBS Co-deployed with OL"
Section 2.2.4, "ECA handling scenarios for Corporate Loan Liquidation"
Section 2.2.5, "Prerequisites"
Section 2.2.6, "Prerequisites in Oracle Banking and Oracle Lending"

2.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.2.2, "Integration Scope with FCUBS Co-deployed with OL"
Section 2.2.3, "Integration Scope without FCUBS Co-deployed with OL"

2.2.2 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.2.3 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 must be sent to the DDA system for approval (ECA_CHECK_REQD parameter maintained in cstb_param table and verify funds flag at contract level). 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 ‘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 OUT queue of OL module, the response would be parsed by the JAVA program and update the status response status (Approved/Rejected) in OLTB_ECA_REQ_MASTER and OLTB_ECA_REQ_DETAIL 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 'N'.
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, after EOD process of Auto Liquidation, a new sub-process ‘AROLL’ is introduced to process Auto Rollover on processing date

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 ELCM request (if any limits are linked to the contract) for the amount to be debited from customer.
After success response from the ELCM system, the system allows you to authorize the rollover. 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 authorized 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.

Debit request+ <ECAREFNO>	ECA Block is released
Debit request	Amount is debited from withdrawable balance

Force debit Components

Tax, Fee and charge which are associated with liquidation/rollover event is debited from the account without ECA.

Forward Liquidation

As part of loans batch process, amount requested ( From payment screen) for liquidation of a contract must be sent to the DDA system for approval (ECA_CHECK_REQD parameter maintained in cstb_param table and verify funds flag at contract level). Only after receiving an approval from the DDA system, the system proceeds with liquidation of the schedule.
First process in OL batch( for Fwd liquidation) ,would compute the requested amount for a contract and place the request into ECA table with the current 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 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_QUEUEOLTB_ECA_REQ_MASTER and OLTB_ECA_REQ_DETAIL table.
When ECA block is successfully created on the accounts (Full), liquidation happens in OL module and perform OL accounting with handoff status as 'No'.
ECA request for 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.
In a situation where ECA block is successful, but subsequent processing in OL module fails auto retry mechanism should be available in OL module.

2.2.4 ECA handling scenarios for Corporate Loan Liquidation

This section contains the following topics:

Section 2.2.4.1, "Single CASA Account with Full liquidation"
Section 2.2.4.2, "Different CASA Account with Full Liquidation"
Section 2.2.4.3, "GL Account used for Liquidation"
Section 2.2.4.4, "One CASA and GL Account used for Liquidation"
Section 2.2.4.5, "Single CASA Account with Partial Liquidation"
Section 2.2.4.6, "Manual Liquidation with Single CASA or Multiple CASA Account"

2.2.4.1 Single CASA Account with Full liquidation

Component	Amount Due	Account	ECA Approved Amount
Principal	50000	CASA1	50000
Interest	10000	CASA1	10000

2.2.4.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.4.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.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.4.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.4.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.2.5 Prerequisites

This section contains the following topics:

Section 2.2.6, "Prerequisites in Oracle Banking and Oracle Lending"

2.2.6 Prerequisites in Oracle Banking and Oracle Lending

The prerequisites for this integration are as follows.

2.2.6.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.2.6.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.3 Integration Process of OL and CASA

This section contains the following topics:

Section 2.3.1, "Viewing ECA Queue Summary Details"
Section 2.3.1, "Viewing ECA Queue Summary Details"
Section 2.3.2, "Viewing External Accounting Log"

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

2.3.2 Viewing External Accounting Log

'External Accounting Log' screen contains OL transaction details with External Accounting System linkage.

To invoke this screen, type ‘OLSEACLG’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

In this screen, you can view the request sent from OL module and view the response (received for the request sent) from the External Accounting System.

You can search records based on the following parameters:

External Reference Number
Branch
External Accounting System
Operation Code
Process Status
Message Reference Number

2.4 OBCL- Payments Integration

The integration between Corporate Lending and Payments enables you to generate SWIFT messages (MT103 and MT202) for Corporate Lending through Payments module.

2.4.1 Scope

SWIFT payment message MT103 and MT202 are supported. If transfer type is ‘Customer Transfer’, then MT103 payment message is generated. If transfer type is Bank Transfer, then MT202 payment message is generated.

2.4.2 Prerequisites

Parameter Setup

In cstb_param table, the param_val should be ‘Y’ for param_name= 'OBCL_PM__EXT_GEN'.

2.4.3 Integration Process of OBCL and Payments

For OL and payments integration, you need to perform the following:

In Branch Parameters Details screen (OLDBRMNT), 'Generate MT103' check box needs to be selected.
In Settlement Instructions Maintenance (LBDINSTR), 'Transfer By Pay' or 'Transfer By Recv' needs to be selected as ‘BANK’ or ‘CUSTOMER’. In case of 'BANK', MT202 SWIFT message is generated at Payments module. In case of 'CUSTOMER', MT103 SWIFT message is generated at Payments module.

In Loan Syndication, SWIFT messages are triggered based on the components like PRINCIPAL_LIQD, INT_LIQD, and FEE_LIQD.

This section contains the following topics:

Section 2.4.3.1, "Viewing Payment Integration"

2.4.3.1 Viewing Payment Integration

You can view Oracle Lending and Loan Syndication contracts with payment integration in ‘Payment Outgoing Browser’ screen.

To invoke this screen, type ‘OLSPMTBR’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

In this screen, you can view the request sent from Oracle Lending/Loan Syndicationmodule and view the response (received for the request sent) from the Payments module.

You can search records based on the following parameters:

Queue Reference Number
Sequence Number
Contract Reference
Process Status
Value Date
Event Code

Note

To search outgoing payment details, for LB side use DD Contract Reference Number and for LP side use Contract Reference Number

2.5 OBCL - ELCM Integration

The integration between OBCL and ELCM enables you to view the Oracle Lending and Loan Syndication contracts with ELCM linkage in a sync or async mode.

2.5.1 Scope

If you are booking a Oracle Lending and Loan Syndication contracts with ELCM linkage in a sync or async mode, the OLTB_REQ_MASTER table is updated with records. You can view these records in the External Limit Summary screen.

2.5.2 Prerequisites

OLTB_REQ_MASTER table must have value.

2.5.3 Integration Process of OL and ELCM

Forward Init

As part of loan batch process for contract marked for initiation on processing date, the system picks and processes the 'FWDINIT' on processing date.After processing ‘FWDINIT’, the system sends a request to ELCM system (if any limits are linked to contract) for Utilization of contract amount.

After success response from the ELCM system, the system authorizes the ‘FWDINIT’ process.For failure response from ELCM system, the system roll backs the ‘FWDINIT’ process (after roll back contract details are logged into exception table)

Forward VAMI

As part of loan batch process for contract marked for VAMI on processing date, the system picks and processes the ‘FWDVAMI’ on processing date. After processing FWDVAMI, the system sends a request to ELCM system (If any limits are linked to contract) for Utilization/De-Utilization of contract amount.

After success response from the ELCM system, the system authorizes the VAMI process. For failure response from ELCM system, the system roll backs the FWDVAMI process (after roll back contract details are logged into exception table)

Auto Liquidation and Forward Liquidation

As part of loan batch process for contract marked for Liqudation on processing date, the system picks and processes the liquidation on processing date. After processing the system sends a request to ELCM system (If any limits are linked to contract) for Utilization/De-Utilization of contract amount.

After success response from the ELCM system, the system completes the liquidation process. For failure response from ELCM system, the system roll backs the liquidation process (after roll back contract details are logged into exception table)

ACCRUAL

As part of loan batch process for contract marked for ‘ACCRUAL’ on processing date, the system picks and processes the ‘ACCRUAL’ process on processing date. After processing accrual process, the system sends a request to ELCM system (If any limits are linked to contract) for Utilization/De-Utilization of contract amount.

After success response from the ELCM system, the system authorizes the accrual process. For failure response from ELCM system, the system roll backs the ‘ACCRUAL’ process (after roll back contract details are logged into exception table).

2.5.3.1 Viewing External Limit Summary Details

External Limit Summary screen contains details of the Oracle Lending and Loan Syndication transactions with ELCM linkage.

You can approve, resend, reject, and authorize the Oracle Lending and Loan Syndication transactions using this screen.

To invoke this screen, type OLSEXLMT’ 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:

Branch Code
User Reference Number
Message ID
Process Sequence Number
Process Status
External Status
Destination Source
Request Type
Communication Mode
Forceprocess
Service Code
Logtime
Authorization Status
Maker ID
Maker Date Stamp
Checker ID
Checker Date Stamp

2.5.3.2 Viewing Action Log of External Limit Queue

The action log screen displays the details of actions performed in the External Limit Queue screen.

To invoke this screen, type ‘OLDQAHIS’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.

This screen displays the action log of the following fields along with ‘Message Id’ and ‘Process Sequence Number’.

Transaction Reference Number
Previous Status
Current Status
Authorization Status
Logtime
Maker ID
Maker Date Stamp
Checker ID
Checker Date Stamp

2.5.4 Viewing Service Log Details

You can view service log using ‘View Service Log’ screen. To invoke this screen, type ‘OLDSRLOG’ in the field at the top right corner of the application toolbar and click the adjoining arrow button.