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 can specify the following fields in this screen:
Branch Code
Select the branch code for which the parameters are to be maintained from the adjoining option list.
Description
A brief description of the branch code is displayed.
External System
Select the external system for which the parameters are to be maintained, from the adjoining option list.
Description
A brief description of the external system is displayed.
Offset Transaction Code
Select a transaction code for the offset entry from the adjoining option list. The adjoining option list displays all valid transaction codes available in the system. You can select the appropriate one
Offset Amount Tag
Select an amount tag for the offset entry from the adjoining option list. The adjoining option list displays all valid amount tag available in the system. You can select the appropriate one
Amount Block Validation
Select this check box to validate the amount block. If the amount block reference number is sent with the transaction details then the accounting will be invoked after the release of amount block.
Offset Required
Select this check box if an offset entry is required. If this check box is selected, then ISB GL will be resolved based on branch, currency, function id and external system. If the check box is not selected, then it is expected that external system sends the balanced entry
Offset Netting Required
Select this check box if offset netting entry is required. If this check box is selected, then the consolidated entries will be built. Offset amount tag is picked from the maintenances. If this check box is not selected, then individual entries are built.
Allow Force Post
Select this check box to suppress all the overrides after posting transactions.
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 Loan Syndication module integration with CASA
The integration of OLand LS module with 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 and LS module"
- Section 2.2.3, "Integration Scope without FCUBS Co-deployed with OL and LS module"
- Section 2.2.4, "ECA handling scenarios for Corporate Loan Liquidation"
- Section 2.2.5, "Prerequisites"
- Section 2.2.6, "Prerequisites in Oracle Lending and Loan Syndication"
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 and LS module"
- Section 2.2.3, "Integration Scope without FCUBS Co-deployed with OL and LS module"
2.2.2 Integration Scope with FCUBS Co-deployed with OL and LS module
If FCUBS is co-deployed with OL and LS module, then web service call is used to check the available balance.
2.2.3 Integration Scope without FCUBS Co-deployed with OL and LS module
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 and LS 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 and LS 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 and LS 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 and LS 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 and LS 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 and LS 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 and LS module and perform OL and LS 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 and LS 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 and LS 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 and LS module fails auto retry mechanism should be available in OL and LS 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 and LS 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 and LS 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 and LS 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 and LS 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 and LS 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 and LS 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 and LS 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 and LS 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.
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 at cstb_param, Branch Param, and CASA level 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 and LS 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 and LS 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 (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 and LS 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 and LS 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 and LS module fails auto retry mechanism should be available in OL and LS 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 and LS 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 and LS 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:
2.2.6 Prerequisites in Oracle Lending and Loan Syndication
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 and LS 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 LS module CASA
This section contains the following topics:
2.3.1 Viewing ECA Queue Summary Details
ECA Queue Summary screen contains details on the transactions between OL/LS 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/LS 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 and LS 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
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.4 Integration with FCUBS for 360 Degree Customer View
Using 360 Degree Customer View, you can query customer limits, account statements, view settlement balances contracts, view assets and liability balances, view loans, commitments and syndication contract details of the customer. You can also view summary of loans, commitments and syndication contract details of the customer. The 360 degree customer view facilitates easy and total view of the customer details and reduces customer service complexities.
FCUBS pulls the required data from OBCL by using the below operation code.
- Service Name : FCUBSOLService
- New Operation : QueryCorpCustview
2.4.1 Summary Tab
The ‘Summary’ tab displays the OBCL loan contracts of the selected customers along with the details.
2.4.2 Loans Tab
In an FCUBS – OBCL integrated environment, click ‘Loans’ tab in ‘360 degree customer view’ screen to view the details for OBCL contracts in Loan details/Commitment and Syndicate Loan Details block for the selected customer.
The loans details are classified as follows:
- Commitment Details
- Loan Details
- Mortgage
- Leasing
- Syndicate Loans details
Under each of the loan details, the system displays the following:
- Branch Code
- Account Number
- Description
- Currency
- Amount Financed
- Amount Disbursed
- Outstanding Amount
- Book Date
- Value date
- Maturity Date
- Product Code
- Account Status
- User Defined Status
2.4.3 Component Details Button
You can view details about the components linked to an account in the ‘Component Details’ screen. You can invoke this screen by clicking the ‘Component Details’ button in the ‘360 Degree Retail Customer View’ screen.
You can view the following component details:
- Component Name
- Component Currency
- Expected – the system displays the amount which is not due for the present date. This amount is arrived during querying.
- Overdue – – the system displays the amount which is not overdue for the present date. This amount is arrived during querying
- Outstanding – the system displays the amount which is due for the present date. This amount is arrived during querying.
- Advance – the system displays the amount pre paid for a component as on the present date. This amount is arrived during querying.
- Latest Interest rate – the system display the current interest rate only for main interest component.
- Number of Days Overdue.
Here you can view the following:
- Component Name
- Schedule Due Date
- Due amount
- Settled Amount
- EMI Amount
- Accrued Amount
2.5 OBCL Integration with Payments for SWIFT messages
The integration between Oracle Banking Corporate Lending and Oracle Banking Payments enables you to generate SWIFT messages (MT103 and MT202) for Corporate Lending through Payments module.
2.5.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.5.2 Integration Process of OBCL and Payments
For OL/LS with 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.
- OBCL initiates web services call, that is, PMSinglePaymentService call for cross-border outgoing SWIFT transactions. These outgoing SWIFT transactions are processed by Payments module. The payment module generates MT103 and MT202/MT202Cover SWIFT messages.
- The system allows the cancellation request to be passed to OBPM when the loan contract is reversed from OBCL. The service "PMOutTxnReversalService" is called from OBCL to pass the cancellation request and after the contract gets reversed in OBPM, the payment system sends the reversal handoff notification to OBCL to pass the actual reversal entries. Thus, the cancellation message (MTn92) from OBPM is supported.A new batch job is introduced that allows the payment message request to be passed to OBPM for the future dated loan contracts/Value Dated Amendments for any principal increase originated from OBCL considering the settlement generation days. Service "PMSinglePayOutService" is called from OBCL to pass the future dated request and after the transaction gets processed in OBPM, the payment system sends the payment message on SGEN date itself. Hence, generation of future dated Payment messages (MT103/MT202) from OBCL is supported.
In Loan Syndication, SWIFT messages are triggered based on the components like PRINCIPAL, INT_LIQD, and FEE_LIQD.
For Loans - Payments integration, beneficiary charges on payment is sent as part of Single Payout Service (SPS OUT) and also accounting entries are displayed that are handed off from OBPM in Contract Online Screen (Events > Accounting Entries tab).
This section contains the following topics:
- Section 2.5.2.1, "Processing of Outgoing SWIFT Messages"
- Section 2.5.2.2, "Viewing Payment Integration Request/Response Messages"
- Section 2.5.2.3, "Maintaining ISB GL"
2.5.2.1 Processing of Outgoing SWIFT Messages
Steps involved in processing of outgoing SWIFT messages.
- On save of the contract, the system checks if SWIFT messages are generated and Inter System Bridge GL (ISB GL) maintenance is available.
- Instead of posting accounting entries to settlement account, the system posts accounting entries to ISB GL.
- On authorization, the system populates SWIFT related details to staging table. Job runs on the table and pick these records. These details are sent to Payments module.
- Once the request is received, Payments module sends the response with confirmation.
- Payments module sends communication to OBCL for each of these actions.
- Using same service, Payments module sends SWIFT messages ACK/NACK accordingly. Once SWIFT message is received, OBCL populates the daily out message table.
- After OBPM hand off, the accounting entries are shown in “Accounting Entries” sub screen of Contract and Commitment - Contract Input’ screen (OLDTRONL). The “Accounting System” field shows either ‘Loans’ or ‘Payments’. The accounting entry passed after OBPM hand off is - debit inter bridge GL account and credit customer settlement account.
- You can view these messages in ‘Payment Outgoing Browser’ screen.
2.5.2.2 Viewing Payment Integration Request/Response Messages
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 Syndication module 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
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.
Note
To search outgoing payment details, for LB side use DD Contract Reference Number and for LP side use Contract Reference Number
2.5.2.3 Maintaining ISB GL
You can invoke the ‘ISB GL Maintenance’ screen by typing ‘OLDISBGL’ in the field at the top right corner of the application tool bar and by clicking the adjoining arrow button.
You can specify the following field information in this screen. A brief description of each value updated in the fields appearing in this screen, is displayed by the system.
External System
Select the external system from the adjoining option list.
Module ID
Select a valid module code from the adjoining option list.
Transaction Currency
Select a valid currency code from the adjoining option list.
Transaction Branch
Select a valid transaction branch code from the adjoining option list
Product Code
Select a valid product code from the adjoining option list.
Function ID
Select a valid function ID from the adjoining option list.
ISB GL
Select a leaf General Ledger from the adjoining option list.
2.6 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.6.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.6.2 Prerequisites
OLTB_REQ_MASTER table must have value.
2.6.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.6.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
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.6.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.6.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.
2.7 Common Integration Details Summary screen
You can view the contract integration status of various modules (OL, LB, LP, FC, TL) of OBCL and also connect to integration screen of different product processors.
You can invoke the ‘OL Interface Summary’ screen by typing ‘OLSCNSTS’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
To view the details, query using any of the following fields.
- Branch Code
- Contract Number
- Module Code.
You can select the specific contracts and then click their respective product processor sub-system.
- ELCM Details - External Limit Queue (OLSEXLMT)
- ECA Details - ECA Status View (PISECAQU)
- Accounting Details - External Accounting Entries Browser (OLSEACBR)
- Payment Details - Payment Outgoing Browser (OLSPMTBR)
- CD Details - Transaction Log (OLSIFCD)
After going to the integration screen, you can re-process and verify the logs of various contracts.
For more information on CD Details - Transaction Log (OLSIFCD), refer to FCUBS Corporate Deposit -OBCL Integration User Guide.
2.8 OBCL Integration with FCUBS for EAC
The integration between OBCL and UBS enables to handle the External Account Check (EAC) and customer status for the counterparty of the contract in synchronous mode.
2.8.1 Scope
The customer accounts are validated as part of EAC process during contract booking, VAMI, payment, rollover, and so on. The following are the list of operations supported.
Operation |
Online/Batch |
Customer Status |
EAC Process |
Contract Booking |
Online |
Yes |
Yes |
Contract Amendment |
Online |
Yes |
Yes |
Value Date Amendment |
Online |
Yes |
Yes |
Rollover |
Online |
Yes |
Yes |
Payment |
Online |
No |
Yes |
Manual Disbursement |
Online |
Yes |
Yes |
Linkage Amendment |
Online |
Yes |
No |
Fee Liquidation |
Online |
Yes |
Yes |
Split Reprice |
Online |
Yes |
Yes |
Consolidate Reprice |
Online |
Yes |
Yes |
Consolidate Rollover |
Online |
Yes |
Yes |
FWD INIT |
Batch |
Yes |
Yes |
FWD VAMI |
Batch |
Yes |
Yes |
Auto Disbursement |
Batch |
Yes |
Yes |
Auto Rollover |
Batch |
Yes |
Yes |
Auto LIQD |
Batch |
No |
Yes |
2.8.2 Prerequisites
- For EAC, OBCL uses ‘CreateEACAccVal’ service available in UBS. This service validates the customer and customer account provided in the request.
- To validate the customer status of the counterparty, OBCL uses the ‘QueryCustomer’ service in UBS and validate the frozen/deceased/where about unknown status.
- A parameter ‘OBCL_EXTERNAL_ACC_CHK_REQ’ is introduced in CSTB_PARAM table. By default this flag is set to ‘Y’. If this flag is enabled, then the system verifies EAC check and customer status during transaction online/batch.
- Static INC to support EAC in OLTM_SERVICE_PARAMS and OLTM_SERVICE_REQ_FORMAT tables
- Integration maintenance for EAC in OLDINPRM
2.8.3 Integration Process of EAC and Customer Status
EAC process
- This integration is to verify the settlement account and account CIF in a contract. This service validates the customer and customer account and returns success or fail.
- The synchronous call request is inserted into OLTB_REQ_MASTER with process status as ‘U’.
- New stage table contains the tag values required to build the request
for each contract
- OLTB_EAC_ACC_MASTER
- OLTB_EAC_ACC_DETAIL
- The system validates account CIF or account based on few parameters (frozen/dormant/no debit/no credit, and so on) and an appropriate error message appears.
Customer Status
- This integration is to verify the frozen, deceased and where about unknown status for the counterparty and Borrower CIF of a contract.
- The synchronous call request is inserted into OLTB_REQ_MASTER with process status as ‘U’.
- New stage table contains the tag value required to build the request
for each contract
- OLTB_CUST_STATUS
- The system validates the counterparty and borrower based on few parameters (frozen/deceased/where about unknown/invalid customer) and an appropriate error message appears.
Inactive Customer Status
If a customer does not have any single contract active, then an update is sent to FCUBS using "QueryCustSts" service. "QueryCustSts" service is consumed by OBCL to handoff the customer status (Active/Inactive) to FCUBS system.