Appendix C :Generic Recovery Interface (GRI)

C.1 Introduction

In general, a Generic Recovery Interface (GRI) is a platform to connect Oracle Financial Services Lending and Leasing (OFSLL) with any third party recovery system. This integration facilitates auto lending institutions to repossess non-performing assets and recover them through a network of third party vendor managed systems.

Accordingly, in an integrated system a particular account in OFSLL can be assigned to a vendor (third party) through GRI for recovery services. Depending on each stage of the process, OFSLL triggers appropriate web service requests to create and update the details into the third party system. Subsequently, the acknowledged details and case updates are retrieved into the corresponding work order(s) and account(s) in OFSLL.

Also the system parameter ‘GRI_WEBSERVICE_LOG_IND’ when enabled, logs all the GRI related web service communications between OFSLL and external interfaced system. The same can be viewed in Dashboard > System Monitor > Database Server Log Files tab by selecting ‘Interfaces’ view option.

Following type of web service requests are supported:

C.1.1 Pre-requisites

Following are the pre-requisites while working with third party integrated system:

C.2 Create Case

Once a non-performing account is identified in OFSLL, the details are to be registered in the third party system for further action. Using the Work Orders tab (Vendors > Work Orders tab), you can create a work order with the identified account details and selecting the channel as Generic Recovery Interface (GRI).

Note that, system does not allow to create a work order during the following conditions:

For information on creating a work order, refer to section Vendors > Work Orders tab.

When the 'Channel' is selected as GENERIC RECOVERY INTERFACE, the Work Orders tab enables 'Vendor Messages' section to specify additional details that are required by the third party vendors to act upon the case. For more information, refer to ‘Case Comments’ section.

After the work order details are created, the same needs to be registered as a case in third party system by updating the status. Accordingly, when the Status of Work Order is selected as 'SEND TO GRI', the 'add Case()' web service is initiated to create a case in third party system.

The 'add Case()' web service request consists of the following Case details to be registered in third party system:

When the web service request is successful, the response would contain the new case number created in third party system. The case # is then appended to the work order and the status is changed from 'SEND TO GRI' to 'ASSIGNED'. Also a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

In case of an error in the web service response received from third party system, the status of work order is changed from 'SEND TO GRI' to 'GRI FAILED' and a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

Note

Error in web service response can also arise when a work order type is not mapped be­tween the two systems and a case creation request is sent to third party system.

C.3 Update Case

Once the details of a work order has been registered as a case in third party system, there can be subsequent updates in the details of the mapped account arising due to mismatch in account details, change in address, collateral and so on. These changes need to be incrementally updated into the third party system and are done through the following web services which are triggered when corresponding details are updated.

Web Service

Type of change in mapped account

updateCaseAccountInfo()

When Account details are updated.

updateCaseAddress()

When Address details are updated.

updateCaseCollateral()

When Collateral details are updated.

updateCaseDebtor()

When Primary Customer details are updated.

updateCaseCosigner()

When Secondary Customer details are updated.

Secondary Customer can also be the next customer type defined in the sequence.

The update web service request consists of the modified field details that are to be updated in third party system.

If the web service request is successful, the modified details are updated into the case in third party system. Also a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

In case of an error in the web service response received from third party system, case details are not updated and the following details are posted as a comment against the account.

C.4 Case Comments

Case comments refers to additional details provided in the 'Vendor Messages' section of Work Orders tab that are required by the third party vendors to act upon the case.

The ‘Vendor Messages’ section can be updated after the case has been created in third party system and serves as a communication channel between the integrated system.

'Vendor Messages' section is available in the Work Orders tab only when the 'Channel' is selected as GENERIC RECOVERY INTERFACE and by default, the Vendor Message Type is selected as ‘CLIENT UPDATE’.

Accordingly, in the ‘Vendor Messages’ section when the details of Vendor Message Type and Vendor Message are updated for a work order, system triggers ‘addCaseUpdate()’ to update the same details in the third party system.

An outbound comment is posted on the corresponding account in Customer Service > Comments tab, with the following details and the update details are also captured as a record in Work Order History tab.

C.5 Hold Case

A particular work order or case which is already scheduled for repossession can undergo a status change when a payment is received (either full outstanding due or partial) on the non-performing account associated with the work order.

Also, an automatic case status change can happen on work order for an account based on Delinquency Days. Whenever the delinquency days falls below certain number of days as defined in system parameter “GRI_DLQ_DAYS_AUTO_STATUS_CHG” (DELINQUENCY DAYS FOR AUTOMATIC CASE STATUS CHANGE), system auto updates the case status as ‘PENDING ON HOLD/ON HOLD’ on running the batch job SET-GRI (RDNDLQ_BJ_100_01-AUTOMATIC CASE STATUS CHANGE).

Accordingly, when the status of a work order is changed to ‘PENDING ON HOLD’ in Work Orders screen, system triggers ‘holdCase()’ web service request to update the status of corresponding mapped case in third party system. This ensures that a work order in hold status is not processed further with third party vendor managed systems.

For information on updating the work order details, refer to section Vendors > Work Orders tab.

If the web service request is successful, a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

In case of an error in the web service response received from third party system, following details are posted as a comment against the account with an alert flag and the status of Work Order is not changed.

C.6 Reopen Case

When the status of a work order is updated from ‘ON HOLD’ to ‘RELEASED’ in Work Orders screen, system triggers ‘reopenCase()’ web service request to update the status of corresponding mapped case in third party system.

This ensures that a work order in hold status is processed further with third party vendor managed systems.

The processing update of REOPEN case request at the third party system is tracked separately through a FIREHOSE web service scheduled at specific interval using a batch process. For more information, refer ‘Case Updates Received via FireHose WebService’ section.

If the web service request is successful, a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

In case of an error in the web service response received from third party system, following details are posted as a comment against the account with an alert flag and the status of Work Order is not changed.

C.7 Reassign Case

A particular work order or case which is already scheduled for repossession in third party system can be reassigned to a different vendor due to delay in action, response, status updates or any such conditions.

Accordingly, when a case is reassigned to a different vendor, the change is processed for update in third party system depending on the current case status maintained across systems as indicated below:

Scenario

OFSLL Work Order Status

GRI Case Status

Case Reassignment Update

1

Send to GRI

NEW FROM CLIENT

Case is assigned to new Vendor.

2

Open

Open

Existing case is closed (i.e. status is updated as ‘PENDING REASSIGN/CLOSE’) and new case is created and assigned to new Vendor.

Also, system automatically updates the work order status to ‘PENDING REASSIGN/CLOSE’ based on the days defined in the lookup code ‘VEN_REASSIGN_DAYS_CD (VENDOR REASSIGNMENT DAYS CODES). If the case status is OPEN for specific number of days as maintained in the sub code of the above lookup code, system auto updates the case status as ‘PENDING REASSIGN/CLOSE’ on running the batch job SET-GRI (RDNVNA_BJ_100_01 - AUTOMATIC VENDOR REASSIGNMENT).

Accordingly, when a case is reassigned, system triggers ‘reassignCase()’ web service request for reassigning the case to new vendor in third party system. Depending on the case status, the case is either directly assigned to new vendor, or a new case is created with new vendor by closing the existing case.

If a new case is created in third party system due to vendor reassignment, then the web service response will include the new case number. Subsequently, when a close confirmation is received on the existing case as part of case status update from FIREHOSE web service response, the work order in OFSLL is closed (status = ‘CLOSE’) and new work order is created with new case number, new assigned vendor and previous work order account details.

Note the following:

A comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

In case of an error in the web service response received from third party system, following details are posted as a comment against the account and the work status is not updated nor a new work order is created with new assigned vendor.

C.8 Close Case

A particular work order or case which is already scheduled for repossession can be closed after validating the preceding status and subsequently a repossession may not be required on the account mapped to the work order.

Accordingly, when the status of a work order is changed to ‘PENDING CLOSE’ in Work Orders screen, system triggers ‘closeCase()’ web service request to update the status of corresponding mapped case in third party system. This ensures that the work order is not processed further with third party vendor managed systems.

If the web service request is successful, a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

In case of an error in the web service response received from third party system, following details are posted as a comment against the account with an alert flag and the status of Work Order is not changed.

C.9 Case Updates Received via FireHose WebService

Retrieving case status updates from the third party system is through a FIREHOSE web service response received into OFSLL through a pull service. Each response is channelled through an individual Event ID and Event Type.

A FIREHOSE web service 'getGriFireHose' - scheduled at specific interval using batch (GRIFRH_BJ_100_01) retrieves the case updates. This response consists of case activities recorded in third party system between specific intervals (based on Max event ID).

Note that, the FIREHOSE web service response always contains specific Event Type Code from the third party system which are updated in the database and inturn is validated for appropriate action in OFSLL. The table below indicates the list of Event Type and the corresponding action updated in the system.

Event Type

Event Description

Action

600

ACCEPTED CASE

Change Work order status to “OPEN”

601

DECLINED CASE

Change Work order status to “DECLINED”

602

ACKNOWLEDGED CLOSE

Change Work order status to “CLOSE”

603

ACKNOWLEDGED HOLD

Change Work order status to “ON HOLD”

300

CASE WAS REPOED

Change Work order status to “REPOSSESSED”

And

Trigger “getRepossessionDetails()” web service to get repossession details and update in Servicing > Repo/Foreclosure” tab.

302

CASE COMPLETED

Change Work order status to “COMPLETED”

200

FIRST UPDATE ADDED CUSTOM

Post the received update as “Inbound Comment” from Interface in Servicing >Customer Service >Comments tab.

201

UPDATE EDITED

Post the received update as “Inbound Comment” from Interface in Servicing >Customer Service >Comments tab.

203

UPDATE UNHIDDEN

Post the received update as “Inbound Comment” from Interface in Servicing >Customer Service >Comments tab.

811

INVOICE SENT TO CLI­ENT

Call the “getCaseInvoiceData()” web service and create the invoices in OFSLL.

1300

CR ADDED

Update ‘Condition Report Status =’Y’ and Condition Report Recd Dt = Event Received Date

Based on the web service response received from third party system, the status updates are posted onto corresponding work order(s) and account(s) in OFSLL.

For example, if the FIREHOSE web service response consists of the Event Type ‘600’, it indicates that the case is accepted by the assigned vendor in third party system and status of the work order is to be updated to ‘OPEN’ in OFSLL. Also a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

Note

Work order status change is permitted only if the previous status matches with the defined cycle setup (Setup > Products > Cycles). Else, update is not allowed and comment is post­ed on the account with the message ‘Work Order Status Update failed due to mismatch of previous status’.

C.10 Case Repossession

When a case has been repossessed, the status of the case is updated by the assigned vendor in third party system. The case status is then retrieved through a FIREHOSE web service scheduled at specific interval using a batch process.

On receiving the case status update as ‘REPOSSESSED’ (i.e. Event Type 300) from FIREHOSE web service response, system triggers ‘getRepossessionDetails()’ web service request to fetch the repossession details and update the status of corresponding mapped work order and account in OFSLL.

If the web service request is successful and repossession details are received as part of the response, the status of the work order is updated in Work Orders tab and a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

The Repossession details are also updated in Repo/Foreclosure tab of Customer Service screen.

C.11 Case Invoice

When a case has been repossessed, an invoice with the actual cost incurred for repossession and the details of the asset repossessed are updated in the third party system by the assigned vendor.

Subsequently, when the case status update is received as ‘REPOSSESSED’ (i.e. Event Type 300) from FIREHOSE web service response, system triggers ‘getCaseInvoiceData()’ web service request to retrieve the invoice and asset details from the third party system.

If the web service request is successful and repossession details are received as part of the response, the details are updated in Vendors > Invoices tab and a comment is posted on the corresponding account in Customer Service > Comments tab, with the following details:

The details of the invoice in the web service response are captured in Vendors > Invoice Information tab with invoice details and Payment Schedule. By default, the status of the invoice is ‘OPEN’ to update the payment details.

System auto validates the invoice details which are received from third party system with specific business rules before creating a record in the Invoice Information tab. Hence the ‘Validate Invoice’ button in the Information tab is disabled for invoice records from external channel (Generic Recovery Interface) and the details are marked as view only.

For more information on business rules and working with Invoices tab, refer to ‘Vendors’ chapter.