4.9 Cycles
- The user responsibilities that have access to perform the steps
- Any edits you want the system to perform between changes in status/sub status.
Cycle code definitions drive the application cycle. The following pairs of status/sub status define status/sub statuses that have system defined meanings and should be included in your origination workflow, if they are not already included.
Note:
The system status and sub status lists are predefined and cannot be changed by the administrator. If you require additional sub status codes, please contact Oracle Financial Services Software to determine whether they can be added.Table 4-28 Cycle code definitions
| Status/Sub status | Description |
|---|---|
| NEW-BLANK | This is the status/sub status of applications during data entry. Applications remain NEW-BLANK until you choose the Next Application on the Application Entry form and the system successfully performs the application edits check. |
| NEW-PRESCREEN | The system processes the prescreen edits to determine whether a credit report should be pulled for this application or not. |
| NEW-PRESCREEN APPROVED | Applications in this status/sub status have passed the prescreen edits. The system will now request a credit bureau pull. |
| NEW-PREQUALIFICATION | The system checks the applicant details whether it is qualified or not. |
| NEW-PREQUALIFY APPROVED | If the pre-qualified edits are satisfied, the status is changed to NEW-PREQUALIFY APPROVED and you can modify or update any further details in the Application Entry screen. |
| REJECTED-PREQUALFY REJECTED | If the edits are not satisfied, the application will be pushed to the REJECTED APPLICATIONS queue with a status update to REJECTED-PREQUALIFY REJECTED. |
| REJECTED-PRESCREEN REJECTED | Applications in this status/sub status failed the prescreen edits. These applications will receive no further processing. The producer will be sent a decision fax and the consumer will receive an adverse action letter. |
| NEW-REVIEW REQUIRED | Either based on the scoring of the application’s credit bureau(s) pull, or the fact that a credit bureau report was not successfully obtained, the application needs to be reviewed by an underwriter. |
| NEW-RECOMMEND APPROVAL | Based on the scoring of the application’s credit bureau(s) pull, the application should be reviewed by an underwriter. However, based on the current setup, the system recommends approving this application. |
| NEW-RECOMMEND REJECTION | Based on the scoring of the application’s credit bureau(s) pull, the application should be reviewed by an underwriter. However, based on the current setup, the system recommends rejecting this application. |
| APPROVED-AUTO APPROVED | Based on the scoring of the application’s credit bureau(s) pull, the system automatically approves the application. The producer will be sent a decision fax, and the application will be passed to funding. |
| REJECTED-AUTO REJECTED | Based on the scoring of the application’s credit bureau(s) pull, the system automatically rejects the application. The producer will be sent a decision fax and the consumer will receive an adverse action letter. |
| APPROVED-BLANK | Application has been manually approved. Normally this occurs when an application is in the NEW- RECOMMEND APPROVAL, NEWRECOMMEND APPROVAL status/sub status, or less often in the NEW- RECOMMEND REJECTION status/sub status. Any cycle code definition with next values of APPROVED-BLANK should have a lookup value of APP APPROVAL EDITS to ensure that all of the required data has been gathered in making the decision to approve the application (unless the application is currently in a status/sub status that assures the APP APPROVAL EDITS have been run). |
| NEW-OVERRIDE REQUIRED | A user without sufficient override authority attempted to approve an application, which, based on setup, required a higher over-ride authority to approve. |
| APPROVED-VERIFYING | Contract has been received from the producer. |
| APPROVED-FINAL DOCUMENT CHECK | The contract has been reviewed and the data is correct. Normally this occurs when an application is in APPROVED-FINAL DOCUMENT CHECK OR CONDITIONED-FINAL DOCUMENT CHECK status/sub status. Any cycle code definition with next values of APPROVED-FINAL DOCUMENT CHECK or CONDITIONED-FINAL DOCUMENT CHECK should have a value of APP CONTRACT EDITS to ensure that all of the required data has been gathered in making the decision to approve the application, unless the application is currently in a status/ sub status that assures the APP CONTRACT EDITS have run. |
| APPROVED-VERIFIED | The application has been processed and is awaiting funding. |
| APPROVED-FUNDED | The application has been funded, and a check requisition has been created. If Customer Service form is being used, then an account is also created at this time. |
| REJECTED-BLANK | The application for whatever reason is being manually rejected regardless of its current status/sub status. Any cycle code definition with Next values of REJECTED-BLANK should have a lookup value of APP DECLINE EDITS to ensure that all of the required data has been gathered in making the decision to approve the application (unless the application is currently in a status/sub status that assures the APP DECLINE EDITS have run). |
| WITHDRAWN-BLANK | The applicants have indicated that they are no longer pursuing this line of credit. |
| CONDITIONED -<ANY> | These status/sub status pairs are analogous to the corresponding APPROVED-<ANY> pair and indicate that the application has had additional conditions placed on its approval. |
| <ANY>-<ANY OVERRIDE> | Requires OVERRIDE approval. The meaning of the sub status is analogous to the corresponding OVERRIDE sub status, and may require that specific EDITS run before proceeding. |
| <ANY>-AGED APPLICATION | These applications have been decisioned but no contract has been received after a period of time determined by setup. If not acted on, these applications will become VOID. |
| <ANY>-AGED CONTRACT | Contracts have been received after a period of time determined by setup. If not acted on these applications will become VOID. |
| <ANY>-VOID | Indicate application previously had a sub status of AGED CONTRACT or AGED APPLICATION. These applications have not been completed and were made VOID after another period of time had passed. |
Using these status and sub status, let us re-examine the early workflow diagram in this section.
Figure 4-10 Application Entry - Flowchart 2
In the Cycles setup screen, you can also define how Status change of an application is to be permitted in the system i.e. you can configure the system to validate and allow a specific user / responsibility to perform the subsequent status change of the application.
Note:
It is extremely important that the APP CONTRACT EDITS run prior to an application being funded. All cycle code definitions should be reviewed to ensure that there are no paths through the origination cycle that bypass this EDIT type.- On the Oracle Financial Services Lending and Leasing home screen, click Setup > Setup > Administration > User > Products > Cycles > Line.
- In the Cycle Definition section, perform any of the Basic Operations mentioned in Navigation chapter.
A brief description of the fields is given below:
Table 4-29 Cycle Definition
Field Do this Cycle Specify the cycle code. Type Displays the cycle type. Product Select the product from the drop-down list. - In the Cycle Code Definition section, perform any of the Basic Operations mentioned in Navigation chapter.
A brief description of the fields is given below:
Table 4-30 Cycle Code Definition
Field Do this Current Code Select the current code to transition FROM, from the drop-down list. Current Sub Code Select the current sub code to transition FROM, from the dropdown list. Next Code Select the current code to transition TO from the drop-down list. Next Sub Code Select the next sub code to transition TO, from the drop-down list. Origination Stage Code Select the origination stage code of the application from the adjoining drop-down list. Edit Type Select the edit type to associate to the cycles, from the drop-down list. Validate Successive Change Select the type of user / responsibility who is permitted to perform application status change. The following options are available in the drop-down list as maintained in the Lookup Type STATUS_ CHANGE_VALIDATION_CD.
NONE: (Default option) Here system does not validate for User / Responsibility while making status change.
USER - SAME: Here system validates for same User while making the status change.
USER - DIFFERENT: Here system validate for different User while making the status change.
RESPONSIBILITY - SAME: Here system validates for same Responsibility of the Current User while making the status change.
RESPONSIBILITY - DIFFERENT: Here system validates for different Responsibility of the Current User while making the status change.
Note that, the application status change is further controlled by Sub Code value defined in cycle setup for Lookup Type STATUS_ CHANGE_VALIDATION_CD. For example, if Sub Code =2 for USER - SAME Lookup Code, then the previous 2 cycles of status change has to performed by the same user.
When a wrong user/responsibility is trying to change the status of the application, system validates with above selection and displays an error indicating User/Responsibility must be same or different between current and previous status change.
During such cases, to know which User or Responsibility has performed the previous application status change, refer to appropriate columns in Underwriting / Funding > Verification tab > History sub tab.
- Perform any of the Basic Actions mentioned in Navigation chapter.
- In the Cycle Code Responsibility Definition section, you can define the responsibilities that are authorized to change the code. If you have selected a specific user / responsibility in the Validate Successive Change field in the above section, it is recommended to define the user responsibility in this section. Perform any of the Basic Operations mentioned in Navigation chapter.
A brief description of the fields is given below:
Table 4-31 Cycle Code Responsibility Definition
Field Do this Responsibility Select the responsibility that will be capable of executing this transition, from the drop-down list. Allowed Select Yes to allow change to the status responsibility and No to disallow. - Perform any of the Basic Actions mentioned in Navigation chapter.
Parent topic: Product