Architecture

The Application Flow illustrates the backend flow of operation after an applicant submits a retail onboarding application, until the status of an application is decided and is notified to the applicant. After updating the status of the application in ODMS, an event is sent from the ODMS to Quantum Fabric which will then interpret the event and start the Application Submission process in Red Hat PAM. The Application submission flow can be illustrated as follows:

Submitted Stage: An application is in Submitted stage when it is submitted through the Origination App. In this stage, the application is moved to respective queue.

• Verification: Once the application submitted successfully, verification task gets initiated. This loads the application details and updates the process variables. In this stage, a customer action will be created if applicable, and then the application review is done.

• Create User Action: Once the application details and process variables are updated the useraction rules will execute and trigger the customer action sub-process.Once the sub-process is executed, a notification is sent to the customer to complete the task manually by providing the required details.

Decision Stage:

• In the decision stage, the status of the application is verified. An application is in Decision stage until the Add decision task is claimed and completed successfully.
• After the verification task is completed, the Decision task is triggered automatically. Based on the Decision outcome received, Decision task can be automatically closed. The decision can be either Auto Approved, Auto Denied, or Manual Review.
• The decision Status for the Facility must be updated with the final decision if it is Auto Approved or Auto Denied.
• If the Add decision task is approved, a customer is created and it moves to the Closing stage. If the Add decision task decision is denied, it moves to the Completed stage directly.

Closing Stage: An application is in Closing stage until the Delivery and Fulfilment, NotifyFunding, UpgradeDigitalProfile related activities are completed successfully. It then moves to the Completed stage.

• Update Facility with Process ID: The sub-process ID is created for each facility request.
• Funding Instruction
• Disable Application Withdrawal

Delivery and Fulfilment: In this stage, System sends the applicant data to Party MS and/or Transact to create accounts for all the products selected by the user.

• Create applicants: After a decision is made manually fromTemenos DigitalAssist or an auto decision is made upon submission, the applicant details and co-applicant details (if present) are created in Party MS and/or Transact and DBX DB (only for a prospect). Depending on the business outcome and the appropriate status indicating if application has been approved or denied.

• Create accounts: If the application is approved, new accounts are created for all the products that are selected. Furthermore, contracts are created for each of these accounts under the Applicant’s name.

Notify Funding Process : If the application is auto-approved and if the user opted for funding, then funding is notified and the process is triggered. System checks whether the application is eligible for funding or not based on the flag. If the flag returns false which marks the application complete and then task is automatically completed. After Notify funding process triggers it initiates its sub-process loadApplication and it will load all the data related to that particular application.

If the application has opted for funding, System sends a notification and customer must take the required action and the task is marked as completed.



Funding Flow:

The Funding flow primarily illustrates the backend flow of operation for verifying the eligibility of an application for funding. If the applicant is eligible and Funding is opted, the appropriate payment instructions are executed. The Funding flow can be illustrated as follows:



Once the user completed the funding process, an event is raised from ODMS to instantiate the Funding Request process in Red Hat PAM.

• Get Application data: This loads the application details and updates the process variables.

  

• Process Funding: The Application Submission and Funding Request processes can run parallely, but the execution of the Funding Request process varies depending on the status of the Application Submission process as follows:
  • COMPLETED: If the status of the Application Submission process is completed, the process proceeds to execute funding request.
  • ACTIVE or PENDING: If the status of the Application Submission process is active or pending, the process verifies if the accounts are created.
    
    If the accounts are created, then the process proceeds to execute funding request, otherwise, it waits for a signal from the Application Submission process before proceeding to execute funding request.
  • ABORTED or SUSPENDED: If the status of the Application Submission process is aborted or suspended, the process verifies if the accounts are created.
    
    If the accounts are created, the process proceeds to execute funding request, otherwise, creates an Error task to be reviewed in Task management section. When Error task is completed, the Process Funding flow is repeated.
    
    

    

  • Execute Funding Request: Funding request is executed based on the funding type chosen by user.

    

Upgrade Digital Profile:

• If the application is auto-approved or approved, then the digital profile of the applicant is upgraded. Furthermore, retail contracts are created for all applicants and details are sent for enrollment process.

Completed: An application is in Completed stage if it is:

• Auto-approved / Auto-denied (STP flow)
• Approved / Denied (after Manual Review)

In case of denials (auto-denial as well as manual denial), the application progresses directly from Decision stage to Completed Stage as Delivery and Fulfilment related activities are not applicable.

The Retail Lending Flow illustrates the backend flow of operation after an applicant submits a Retail Lending application. The products that come under this flow are Overdraft Accounts, Personal Loan, Credit Cards and Mortgage.

While creating a new application, when a product from a lending product group is selected, the ProductType is updated as “Lending” in ODMS. This is used in Application Status DMN to update the application status as “Submitted” for all loan applications. After updating the status of the application in ODMS, an event is sent from the ODMS to Quantum Fabric which will then interpret the event and start the Application Submission process in Red Hat PAM. The Application submission flow is as follows:

The retail lending application submission flow can be categorized into the Automated Retail Lending Process and Problem Loan Management, depending on the type of the applicant.

Automated Retail Lending Process

Automated Process is enabled for the applications whose applicants are existing customers, provided there is no change in customer data.

During the post-submission flow of the application, system will go through the following Retail Lending workflow with automated Lending process check. In the automated lending process check, the data in ODMS is compared with that of Party MS. If there is no discrepancy in address, personal, identity, income and employment information, the automated lending flow kicks in. The application is assigned to Supervisor RM and the next task is automatically processed. Otherwise, if there is any discrepancy in data, then the problem loan management flow kicks in.

Submitted Stage:

Automated Lending Process Check:

• In the automated lending process check, the data in ODMS is retrieved and compared with that of Party MS. A flag is set if there is any data discrepancy in the KYC details(Personal, Address and Identity), Income and Employment details and Documents (Proof of Address, Proof of Identity, Proof of Income, Supporting financial documents) to be in Approved Status Or Not.
• The document discrepancy check will consider if any of the Proof of Address, Proof of Identity, Proof of Income, Supporting financial documents have any documents in “Pending” status. If any document is in pending status then the documentDiscrepancy will be set as true otherwise false.
• The Have you Identified the Property check will be implemented Automated Lending process task sub process in PAM after the data discrepency check. If Have you Identified the Property property for the application is Yes then the discrepancy is False and Have you Identified the Property flag is set to True.
• If Data Discrepancy flag is False and “Have you Identified the Property” flag is True, then the application is auto assigned to Supervisor user and will follow the Automated Lending Flow.

Move Application to User/Queue

• The flag set in the process(Automated Lending Process task ) to check whether the request is eligible for automatic process or not.

• If the conditions in the check is satisfied then the application will follow automated process and is assigned to Supervisor RM and will directly process the next task.

• Task is closed automatically.

Prescreening Stage:

For prospects, an applicant review task is created. All mandatory information required to create a party is reviewed and edited by a Relationship Manager(RM) and then a customer id is created in Party Microservice and Temenos Transact.

If the applicant is an existing customer, then Evidence review and Compliance review tasks are created. The customer data will be updated in Party Microservice and Temenos Transact.

Review Customer Details:

For prospect customer, create customer call happen and creates the narratives and updates the customer details.

Review KYC Information: Existing Customer Task

If dataDiscrepancyflag is false and there is no change in KYC data and Proof of Identity and Proof of Income documents are Approved , then Review KYC - Existing Customer task is skipped.

Review KYC Information: Prospect Task

For existing customers, data discrepancy is checked. If the automated lending process is set, then the evidence review is automatically closed.

Prescreening Review:

Review Loan Document:

If the flag returned by Automated Lending process check is not set, then there is no change in the Income and Employment data. Then, the status of the Loan documents is Submitted or Verified, and this task is automatically closed.

OFAC Check (Existing Scenario) :

• The system checks if there is an existing OFAC report for the Applicant in Party MS. If there is a report which is not older than 5 days, the existing data is updated.

• If the report is older than the expected days, then a new report is fetched from an external system and shall be stored in Party MS. The number of days (here, 5 days), is configurable from Spotlight.
• Third party service is being mocked by ofac_mock_flag in spotlight config param ASSESSMENT_MOCK_SERVICE_STATUS.

• Once the results are received, this task is automatically updated with the results and closed.

Blacklist Check (Existing Scenario):

• The system checks if there is any existing Black list report for the Applicant in Party MS. If there is a report that is not older than 5 days, the existing data is updated.

• If the report is older than the expected days, then a new report must be fetched from an external system and shall be stored in Party MS. The number of days (here, 5 days), is configurable from Spotlight.

• Third party service is being mocked by blacklist_mock_flag in spotlight config param ASSESSMENT_MOCK_SERVICE_STATUS .

Review Compliance Check ( Existing Scenario):

• OFAC_Status and BlackList_Status are the two output flags.If the status of both OFAC and BlackList check is "Pass", then the Review Compliance task must be automatically closed. The Review Loan Document, OFAC and BlackList tasks happen parallely.

  

Credit Packaging Stage:

 

Bureau check:

• Review Compliance status output is passed as input.

• If all the compliance results are “Pass” or if the results are Partially Pass then system continues fetching the Bureau Score. Furthermore, the system checks if there is any existing Bureau report for the Applicant in Due Diligence MS for the existing party. If the report is older than validity time (as per RETAIL_BUREAU_CHECK configuration), the new report is fetched from external system. Reports received form third party services are stored in Due Diligence MS. Otherwise, if the report is within the configured days, the task is updated with existing data.

• A customer can have credit scores from different providers which should be stored in Due Diligence MS. System should be able to query the credit score based on the providers. The providers whose credit score must be fetched from CDD can be configured from Spotlight.

Get Credit Score:

If all the Compliance results are Pass or Partially Pass, then the system continues executing the Credit Scoring task. When the scoring is complete, system shall update the results and close the task automatically.

Underwriting Stage:

Execute Score Card Values: This is a system task that is auto completed once the Get Score card Values task is completed.

Execute Decision Engine Rules:

The three possible outcomes of Decision engine are

• Auto Approved
• Auto Denied
• Manual Review

Decision Status for the Facility must be updated with the final decision if it is “Auto Approved” or “Auto Denied”.

In the Underwriting stage, a review application task is created. On completion of the Review Application task, a Credit Decision task is created for all facilities iteratively, while an Underwriter can approve or decline the request.

If the credit decision task is approved, an offer letter (document generation task) is created which is an auto task by passing the transaction data to the Receipt Microservice. After all the required documents are generated, the Relationship Manager that claimed the application will be notified.

Once when the decision outcome is received Execute Decision engine Rules task will be automatically closed.

Review Credit Decision:

• This task will be created only when there is a requirement of manual decision.

• If the outcome of Decision Engine is either “Auto Approved” or “Auto Denied”, the Review Credit Decision task will be automatically closed.

Offer Acceptance Stage:

• Generate Offer Letter/ESIS: If the decision marked is Approved or Auto-Approved, then the Offer Letter document is generated. Furthermore, the generated Offer letter is updated under Documents section in Facility Overview.
• Notification to RM: An email notification is sent to RM once the Offer Letter document is generated. This task is closed automatically once the email is sent successfully.
• Offer and Acceptance by Customer:There are two ways of offer acceptance - Offline and Online.
• The applicable offer acceptance method can be configured by using the Spotlight configuration: RETAIL_OFFER_ACCEPTANCE_MODE. The default value is Online. The value can set to Offline or Online accordingly.

Offline Mode:

• Spotlight Configuration “RETAIL_OFFER_ACCEPTANCE_MODE” is configured as offline.

• Manual task is raised for RM.

• RM will download the offer letter , get it signed by Customer, update the Acceptance status and close task manually.(Existing scenario)

Online Mode:

• Spotlight Configuration “RETAIL_OFFER_ACCEPTANCE_MODE” is configured as Online.

• A customer action is raised to upload the signed document. If the customer accepts the customer action, another customer action to fetch the Disbursement details from the customer shall be raised.

• After the customer action is completed, RM shall manually close the Offer Acceptance task. After Offer Acceptance task is closed, the disbursement details will be updated and the status of Disbursement is Approved.

Review Executed Document :

After the Offer Acceptance task is closed by customer, the Review executed Document task is created and is assigned to Ops user. After the document is reviewed by Ops user, the task is manually closed.

Due Diligence Stage:

Review Disbursement Instructions: As soon as the Review documents task is completed, system checks if the status of the Disbursement Instructions is Approved. If yes, then system automatically closes the disbursement Instructions task.

Capture Notary comments: Manual task to capture Notary comments is created when Acceptance status is “Approved”.

Closing Stage:

The closing stage is executed for each selected product separately.

• Trigger fulfilment: Fulfilment is automatically triggered once the Disbursement instructions are reviewed. This task covers the account creation as well as Loan disbursement. Once the fulfilment is complete and the loan account is created, system automatically marks the task as Completed.

• Loan Completion: This is to notify the RM of the completion of the application workflow. After the fulfilment task is completed and Loan account is created, application is marked as Completed and this task is automatically closed.

Follow-up stage

• Review Signed Deed: System will create Review Signed deed task when the loan processing is complete. This is a manual task which will be addressed by OPS user.

Problem Loan Management

Automated Lending Process Check:

Problem Loan Management Process is enabled for the applications whose applicants are prospects and existing customers with change in customer data.

During the post-submission flow of the application, system follows the Retail Lending workflow with Automated Lending process check. In the automated lending process check, the data in ODMS is compared with that of Party MS.

If there is no discrepancy in address, personal, identity, income and employment information, the automated lending flow kicks in. The application is assigned to Supervisor RM and the next task is automatically processed. Otherwise, if there is any discrepancy in data, then the problem loan management flow kicks in.

This section describes about the interventions needed manually when automating the post submission process for Retail Lending applications in Temenos DigitalAssist app.

If the applicant is a prospect or an existing customer with change in KYC details (Personal, Address and Identity) and Income and Employment details, then the automated lending process task is set, and the Problem loan Management process kicks in. The application is then moved to RM Queue (Team tasks). After it is claimed by the RM user, the task is closed automatically.

Submitted Stage:

Updates deal (application data) with Process ID and automated lending process check is done.

Move Application to User/Queue: The flag set in the process “Automated Lending Process task” is input. If flag is true or if it is a new application, then the application is auto assigned to RM user or moved to RM Queue where it is claimed by any RM user. The task is closed automatically.

Prescreening Stage:

Review KYC Evidence task:

• The output of Automated lending Process task” along with existing customer data is input to the process.
• If dataDiscrepancyflag is true and change in KYC data, then this process is initiated for RM to review.
• RM will review the changed data in Temenos DigitalAssist app and should have a button/option to raise Customer Action if there is any personal data or document is needed additionally from customer side
• KYC Evidence Review process reviews Personal, Identity and Address details of customer. For existing customers, if there is any data discrepancy, the process is initiated for RM to review.
• RM verifies the data manually and can again raise customer action if needed. Otherwise, the RM user shall close the task manually.

Review Customer task:

When applicants are prospects, the Applicant Review process is initiated. RM can raise a customer action if more information is needed. RM can close this task manually.

Prescreening Review:

Review Documents: If any one of the incomeEmploymentInfoDiscrepancy flag is true and Proof of Income documents are not in approved status then the Review Documents task is created and assigned to RM user.

OFAC Check (Existing Scenario):

System checks for the Blacklist Check report. If the OFAC report status is not available or expired in the Party MS, then the OFAC check is handled as in Automated Lending Process. Third party service is being mocked by OFAC_MOCK_FLAG flag in spotlight config param ASSESSMENT_MOCK_SERVICE_STATUS. If it is false, an exception is raised. An error task is raised automatically and assigned to the admin user.

Blacklist Check (Existing Scenario):

• System check for the Blacklist Check report. If the OFAC report status is not available or expired in the Party MS, then the OFAC check is handled as in Automated Lending Process. In case of any error, an error task is raised automatically and assigned to the admin user.

Review Compliance Check:

• Validating the OFAC/BlackList status is handled as in the Automated Lending Process. OFAC_Status and BlackList_Status are the two output flags. If either of the two flags or both of them are failed, then the Compliance Review process is initiated and assigned to RM.

• On click of Create New Task button in Temenos DigitalAssist app, reTrigger Tasks is added in dropdown of checklist. The status of each party compliance is updated from Compliance table of Origination Processing. Then the OFAC Check is completed using the integration service, as in the automated lending process and a notification is sent to the RM. RM can open existing Review compliance task and check the status in Task Overview screen. Furthermore, the Task Overview screen is updated with compliance status for each party. RM can also raise adhoc task to Underwriter and add comments in the Narrative tab, if necessary. Then, the task is marked as Completed by RM manually.

Enrich Property Details Task: If the value of "Have you identified the Property" is false and compliance results are failed , then the task is raised and assigned to RM user to capture the property details.

Credit Packaging Stage:

Bureau Check: Review Compliance status output is passed as input. If the status of all the applicants is FAIL then, process is closed automatically. If the status of all the applicants is Pass or Partially Pass then system continues fetching the Bureau Score report from CDD. If the Bureau Score report is not available then, Third party service is being mocked by bureau_mock_flag flag in spotlight config param ASSESSMENT_MOCK_SERVICE_STATUS. In case of any false exception, an error task is automatically generated and assigned to admin user.

UnderWriting Stage:

• Credit Assessment: Review Compliance status output is passed as input. If the status of all applicants is FAIL, then the process is closed automatically. If the status of all applicants is passed, the decision engine is triggered.

• Get Score Values: This is a system task that is auto completed once the Property Evaluation task is completed.
• Execute Score card Values: This is a system task that is auto completed once the Get Score card Values task is completed.

• Execute Decision Engine Rules: The three possible outcomes of Decision engine are Auto Approved, Auto Denied, Manual Review. The Decision Status for the Facility must be updated with the final decision if it is “Auto Approved” or “Auto Denied”.

Review Credit Decision :

• “Decision Engine” process response is input. If the response is “Manual Review”, then this process is initiated. Review task is raised to UnderWriter to provide the decision for the facility. Task Name, Priority, productLine and amount are the deciding factor for assigning it to a queue.When Decision status is “Denied”, the Decision status is marked as “Rejected”. Task is manually closed by the Under Writer.

Offer Acceptance Stage:

• Generate Offer Letter/ESIS Document (Existing scenario) :

• “Decision Engine” process response is the input. If the response is “Auto Denied”, then the task is closed. For notification to the RM: “Decision Engine” process response is input. If the response is “Auto Denied”, then email is sent to RM. Email Template “FACILITY_DENIED”, is used to send notification to RM.

Offer and Acceptance by the Customer:

Offline Mode: Spotlight Configuration “RETAIL_OFFER_ACCEPTANCE_MODE” is configured as offline. Manual task is raised for RM. RM downloads the offer letter, gets it signed by Customer, updates the Acceptance status and close task manually.

Due Diligence Stage:

• Review Disbursement/Repayment Instructions: System will create this task if Acceptance status is “Approved” and status of funding instructions is not Approved.

• Capture Notary comments : Manual task to capture Notary comments is created when Acceptance status is “Approved”.

Closing Stage:

• Review Executed documents: If the offer is accepted by the customer and if the status of the offer document is not Approved manual task is raised for OPS User. Once the review is done OPS user will close the task manually. If the customer has rejected the offer then OPS user will withdraw the application and close the task.

• Fulfilment (Customer, Account, Collateral) creation in transact: System will trigger the fulfilment tasks automatically when Funding Instructions task is completed. Once the fulfilment is complete and the loan account is created and Disbursed.

• Loan Completion Notify Customer/RM: This is to notify the RM of the completion of the application workflow. If the fulfilment task is successfully completed by creating a loan account. System will close the Loan application. Loan completion task will be automatically closed.

Application Submission Flow

The SME Onboarding journey workflow is triggered for Current Accounts product. The parent sub process for SME Onboarding journey is

TemenosDigitalAssist.SMEDepositsApplicationSubmission:

The workflow illustrates the back end flow of operation after an application is submitted in the Origination App, the parent process triggers. In Copy SME application to LOS subprocess the data from ODMS is copied to OPMS . The various steps involved in the Copy SME application to LOS subprocess are shown in the below workflow.

After the Copy SME Application to LOS subprocess ,there will be throwing signal that will trigger for copying the document data from ODMS to Document MS. The signal triggers InfinityAssist.CopyDocumentData subprocess that copies the documents to Document MS.

After copying the documents the Update Parent Process ID is triggered which updates the RequestId with current process Id as parent process Id in OPMS. This id will be used to get all tasks for this request and in case of withdrawal to abort all existing tasks.

TemenosDigitalAssist.CopyParentProcessIdtoLOS:

• After all of the necessary data has been transferred into the appropriate microservices, the process will begin to progress step by stage. To begin, we'll make a getdeal service call to obtain the current deal stage.

• The XOR will determine which stage subprocess has to be triggered based on the current stage. The various stage subprocess for SME Onboarding journey are:

  • Submitted
  • Verification
  • Decision
  • Closing

• When a deal is submitted, it is in the submitted stage, the XOR will route it to the submitted stage. After all the tasks in the submitted stage are completed, it moves to the update deal . In update deal, we will get reference data based on the reference data, the deal stage is updated and moves to the next stage.

• The XOR will redirect to same get deal and the status will be updated to next stage as Verification. This same flow will be followed till the Decision stage. After the Decision stage, getfacilities call fetches the list of approved facilities and all the stages will proceed only for the approve facilities.

• The facility call decides which stage subprocess must be triggered. After the closing stage is completed, the facility stage is updated as completed and ends the multiple instances. After the flow is complete for all facilities, the deal stage is updated as complete and ends the parent process.

Functional Flow for SME Onboarding Post Submission:

The Application Flow illustrates the backend flow of operation after an applicant submits an SME Onboarding application, until the status of an application is Completed. After updating the status of the application in ODMS, an event is sent from the ODMS to Quantum Fabric which will then interpret the event and start the Application Submission process in Red Hat PAM. The Application submission flow can be illustrated as follows:

Submitted: The stage sub process of the submitted stage is shown in the workflow below.

• In the submitted stage, the deal is updated with the current process Id as "activeprocessId". This active processIs is used for signalling and creating adhoc tasks. The application data is fetched which calls a queue DMN that determines to which queue the application must moved to. The DMN used for queue assignment is SME Application Queue Name Rules.

• After the queue name is fetched, a call is triggered to fetch the user assignment Java service, where it fetches all the users who have access to the queue and pick a user who has less than the minimum number of applications configured in the fabric runtime property. If there are no users available, the request’s RM will be updated to the queue name and the next available user can claim it. Once someone claims it, the signal will be triggered and the flow will proceed further. If users are available, the request’s RM is updated with the username directly, which marks the completion of the submitted stage.

Verification:

• Application is in “Verification” stage until the Application Review task has been claimed and completed successfully. Thereafter, it progresses to the “Decision” stage. The sub stage process in the verification stage is explained in the below workflow.

• In the Verification stage, the deal is updated with the current processId as "activeprocessId". This active processId is for signalling and creating adhoc tasks. A service call is make to getfacilities to retrieve the list of facilities, and on exit action the getFacilities script will define a reviewRequired flag based on the approvalStatusId. If the ReviewRequired flag is True, the approvalStatusId is under review(03), otherwise false. A service call is getDocuments which fetches the documents. On the exit action, the getDocumentDetailsForVerification script will be invoked.
• SME Application review is created if there are no documents or else either of proof of address individual, proof of address business, proof of business and proof of individual is in pending status.

Decision Stage:

The sub process in the Decision stage is shown in the workflow below.

• In the decision stage, the deal is updated with the current processId as "activeprocessId". This active processId is for signalling and creating adhoc tasks. A service call is made to getfacilities to retrieve the list of facilities, and on exit action the getFacilities script will define a reviewRequired flag based on the approvalStatusId. If ReviewRequired flag is True, approvalStatusId is under review(03), otherwise false for the respective facility. If the reviewRequired flag is true, then it will execute the multiple instances on the list of facilities that have approvalStatusId that are under review(03). It invokes to create Deposits Decision sub process.

TemenosDigitalAssist.SMEAddDecision

A service call is made to getDecision to fetch the decisions on exit action invokes checkDepositsDecision script to check the decisionId(Approved or decline) and finalDecision to define the hasDecision flag. SME Add Decision task will be created if there are no decisions or decisionId or finalDecision else decisionId is not Approved or declined (i.e., hasDecision flag is false).

Closing Stage:

An application is in the Closing stage until the Delivery and Fulfilment(CreateAccounts), NotifyFunding, UpgradeDigitalProfile related activities are completed successfully.

CreateSMECustomer

After a decision is made manually from Temenos DigitalAssist or an auto decision is made upon submission, the applicant details, co-applicant details (if present), company, and related company details(if present) are created in Party Microservice and Temenos Transact.

CreateSMEAccounts

If the application is approved, new accounts are created for all the products that are selected. Contracts are created for each of these accounts under the company's name.

• Completed: An application is in “Completed” stage if it is:
  • Auto-approved / Auto-denied (STP flow)
  • Approved / Denied (after Manual Review)
    In case of denials (auto-denial as well as manual denial), the application progresses directly from Decision stage to Completed Stage as Delivery and Fulfilment related activities are not applicable.

The SME Lending Flow illustrates the backend flow of operation after an applicant submits a SME Lending application. The products that come under this flow are Overdraft Accounts, Business Loan, Credit Cards. The parent sub process for SME Lending journey is Temenos DigitalAssist.SMELendingApplicationSubmission.

The SME Lending application submission flow can be categorized into the Automated SME Lending Process and Normal flow, depending on the type of the applicant. The Automated Process is enabled for the applications whose applicants are existing customers, provided there is no change in customer data. Problem Loan Management Process is enabled for the applications whose applicants are prospects and existing customers with change in customer data.

The workflow process in the SME Lending subprocess is explained below.

After the application is submitted in the Origination App, the start node of the parent process triggers. In the Copy SME application to LOS subprocess, the data is copied from ODMS to OPMS. The various stages involved in the Copy SME application to LOS subprocess is shown in the below workflow.

After the Copy SME Application to LOS subprocess, signal triggers to copy the Document data from ODMS to Document MS. The signal triggers Temenos DigitalAssist.CopyDocumentData subprocess copies data from the documents to document MS.

After copying the documents the Update Parent Process ID will trigger that updates the RequestId with current process Id as parent process Id in OPMS. This id will be used to get all tasks for this request and in case of withdrawal to abort all existing tasks.

After all the required data is copied into the respective microservices the workflow proceeds stagewise. In the initial step, a getdeal service call is made to get the current deal stage. Based on the current stage the XOR will decide which stage subprocess has to be triggered.

Initially when a deal gets submitted it will be in submitted stage ,so the XOR will route it to the submitted stage process.

Once all the tasks in Submitted stage are completed it will move to update deal .In update deal we will getreference data and based on the reference data we will update the deal stage to next stage.

XOR redirects the same get deal and the status gets updated and moves to the prescreening stage. The same flow applies till the Underwriting stage. Getfacilities call fetches the list of the approved facilities and the stages proceed only for the approved facilities.

The facility will be in underwriting stage, based on the reference data it will be updated and moves to the closing stage. A facility call is made which decides at which stage subprocess it must be triggered.

After the closing stage is completed, the facility stage is updated as complete and ends the multiple instances. Once the flow is complete for all facilities, the deal stage is updated as complete and ends the parent process.

The SME lending application submission flow can be categorized into the Automated Retail Lending Process and Problem Loan Management, depending on the type of the applicant.

Automated SME Lending Process

Automated Process is enabled for the applications whose applicants are existing customers provided there is no change in customer data.

After the request application is submittedTemenos Digital Origination (Self Service) application, the system goes through the workflow as shown in the diagram to automate the lending process.

Submitted:

• In the submitted stage, the deal is updated with the current processId as “activeprocessId”. This active processId is used for signaling and creating adhoc tasks.

  Automated Lending Process Check:

• In the automated lending process, certain checks are done to evaluate if the application is eligible for automatic processing. The various steps in the automated lending process is shown in the workflow below.

• In the automated check, all the related parties are fetched to check if the user is an existing customer or a new customer. If the user is a new applicant, the checks are stopped and the workflow ends here. In case all the related parties are existing, each related party is iterated to fetch data from ODMS and Party MS and data is compared in both the Microservices to check for any discrepancy. The Discrepancy check is performed via a DMN as shown below.

• In the DMN We have both partydata and ODMSData as inputs. Data is checked in each category and marked as True or False.

  

  The final decision is based on all three flags as below:

  

  After the rule in Automated Lending Process check task is satisfied, the Application Claim task is automatically closed.

• Once iteration is completed for all related parties based on the output from the DMN for each party, the automation flag is set, which implies that only if there is no data discrepancy for any of the related party the application is eligible for automated processing.

• After the automation check , the XOR will decide which way to go based on the automation flag

Move Application to User/Queue:

• The flag set in the process(Automated Lending Process task ) to check whether the request is eligible for automatic process or not.
• If the conditions in the check got satisfied then the application will follow automated process and should be assigned to Supervisor RM and will directly process the next task.
• Task is closed automatically.

Prescreening: The stage sub-process of prescreening stage is as explained in the below workflow.

• On entering the prescreening stage, the deal is updated with current processId as activeprocessId.This active processId for signaling and creating adhoc task.
• Then we will get all the related parties from which we will prepare a list of related parties. The initial check is done to verify the company. If the company is a new customer ,The flow will be as below(upper path of the XOR)

The customer review task will be created if any of the documents of company will be in pending. getDocuments service call is done to fetch the documents, and on the exit action, the getDocumentDetailsForVerification script will be invoked that will check if there are no documents or else either of proof of address individual, proof of address business, proof of business and proof of individual are in pending status.

• Once the task is complete, a call triggers Java Service that creates a customer record in T24 and Party Microservice.
• Narratives are created in the Party Microservice for the company.
• The Document meta in the Document Microservice is updated with a new PartyId.
• The consent in OPMS will be updated with the new partyId of the company.
• If the company is an existing customer, the workflow will be as shown below.

• Initially we check data discrepancy for the company by invoking a java service that compares data from party ms and ODMS
• If there is data discrepancy, the evidence review task will be created if any of the documents of company will be in pending. a getDocuments service call is triggered to fetch the documents, and on the exit action, the getDocumentDetailsForVerification script will be invoked to check if there are no documents or either of proof of address individual, proof of address business, proof of business and proof of individual is in pending status. Then the Customer record in T24 and party is updated with the new details.

• If there is no data discrepancy, the reference in OPMS is updated with Original Party Id.
• Narratives are created in the Party Microservice for the company.
• The Document meta in the Document Microservice is updated with a new PartyId.
• The consent in OPMS is updated with the new Party Id of the company.
• The next iteration is on the related parties list. There are two lists one for prospects list and the other is existing customers list.
• If the related party is a new customer ,The flow will be as below(upper path of the XOR

• The customer review task will be created if any of the documents of party are in pending status. getDocuments service call is triggered to fetch the documents, and on the exit action, the getDocumentDetailsForVerification script will be invoked that checks if there are no documents or else either of proof of address individual, proof of address business, proof of business and proof of individual are in pending status.

• Once the task is complete, a call triggers Java Service that creates a customer record in T24 and Party Microservice.

• Narratives are created in the Party Microservice for the company.

• The Document meta in the Document Microservice is updated with a new PartyId.

• The consent in OPMS is updated with the new Party Id of the company.

• If the related party is an existing customer, the workflow will be as shown below

• Initially, there is a check for data discrepancy for the party by invoking a java service that compares data from Party Microservice and ODMS

• If there is data discrepancy, the evidence review task will be created if any of the documents of party will be in pending. getDocuments service call is made to fetch the documents, and on the exit action, the getDocumentDetailsForVerification script will be invoked to check if there are no documents or else either of proof of address individual, proof of address business, proof of business and proof of individual is in pending status. Then we will update the customer in T24 and party with the new details.

• If there is no data discrepancy, update the reference in OPMS with original Party Id.
• Narratives are created in the Party Microservice for the company.
• The Document meta in the Document Microservice is updated with a new PartyId.
• The consent in OPMS is updated with the new Party Id of the related party.
• The Prescreening compliance review will trigger as shown below

Two tasks happen in parallel in the prescreening stage:

1. Loan Documents Review: The loan documents reviews fetches all the documents for the application and check if they are in pending status. If either of the documents is in pending status, a human task is created, else the workflow will end here.

2. Compliance Review : The compliance Review tasks subprocess is shown in the workflow below.

• The OFAC and Blacklist checks occurs in parallel for all the related parties.
• The OFAC Check is performed by invoking a java service ,which fetches the eligible days from the spotlight configurations. It then queries Party Microservice to check if any previous assessment is present or not . If it is not existing or it is more than number of eligible days it will set the flag to N/A. It will trigger third party check and if it is existing, it ends here.

The OFAC thirdparty Check is performed by triggering a Java service call, which checks for a mock flag. If the mock flag is setup, it will try to get the OFAC status from spotlight configuration.

• The blacklist Check is performed by invoking a java service, which will get eligible days from the spotlight configurations. It then queries Party Microservice to check if any previous assessment is present or not . If it is not existing or it is more than number of eligible days it will set the flag to N/A. It will trigger third party check and if it is existing, it ends here.

The Blacklist thirdparty Check is performed by invoking a java service, which checks for a mock flag. If the mock flag is setup it will try to get the OFAC status from the spotlight configuration.

Once the checks are completed for the related parties, a script sets the overall compliancestatus flag based on the individual result. This flag is considered for creditscoring as well as risk scoring. If the compliance flag has failed, a task is created for the RM to check and update the Review compliance task.

After the review task is completed, Partydata checks if the status is updated and setting the final compliance status, which marks the completion of the prescreening stage.

Credit Packaging:

The sub stages of credit packaging is explained in the below workflow.

In the credit packaging stage, the deal is updated with the current processId as “activeprocessId”. This active processId is for signaling and creating adhoc tasks. Two tasks are performed in parallel, Business Bureau and Financial Spread. The steps involved in the Business Bureau are explained in below workflow.

In check bureau score, a check is done if the existing assessment is available in Due diligence Microservice. If it is there, the sub process ends. Else, the bureau score will invoke a java service which fetches the bureau score value from spotlight configurations and creates the assessment in Due Diligence Microservice.

In this tasks, the financial ratio results are fetched from OPMS .If the financial results are already existing and has not expired, there is no task creation. Else, a human task is created and the user has to update latest financial result and complete the task. After both the tasks are completed based on the complaince status fetched from prescreening. If the compliance status fails, the workflow ends here. If complaince status is Pass, two tasks namely Credit Scoring and Risk Scoring occur parallely.

In Credit scoring for each of the facilities a loop will run to fetch the credit score data .The subprocess will invoke a java service which fetches score card data for each of the facilities which will be stored in a map and passes to the Underwriting stage.

In Risk scoring for each of the related parties, a loop will run to fetch the risk score data .The subprocess will invoke a java service which fetches score card data for each of the party which will be stored in a map and passed to Underwriting stage. This marks the end of the credit packagin stage.

Underwriting:

The stage subprocess of underwriting is explained in the below workflow.

After entering the underwriting stage, the deal is updated with the current processId as “activeprocessId”. This active processId is for signaling and creating adhoc tasks. Based on the compliance status fetched from prescreening if it is a pass, two tasks run in parallel

1. Execute Credit Score
2. Execute Risk Score

Execute Credit score:

The execute credit score sets the input from creditscoremap from credit packaging stage and then calls a DMN to calculate the credit score and then save it in OPMS.

The DMN involved in credit score calculation is as shown below:

Credit score calculates the individual inputs using a decision logic as shown below.

The final score is calculated by adding all the individual scores which is the credit score.

Execute Risk Score:

The execute risk score sets the input from riskscoremap from credit packaging stage and then calls a DMN to calculate the risk score and save it in OPMS.

The DMN for risk score calculation is as shown in below diagram:

For each input, score is calculated which sums upto final risk score. Based on the risk score, the grade is decided.

Based on the gradescore we will determine the risk category as below.

Based on the risk category, if it is high a Review Risk assessment task is created.

After the scoring is done, the iteration is done over the list of facilities as shown below.

The execute decision engine subprocess is as below.

The blacklist status is fetched from partydata and amount from facility and calling a DMN to get the decision for this application. The DMN is explained as shown below.

Based on the various criteria, DMN returns the decision either as auto-approved, auto rejected or manual review which will be stored in OPMS

In case of auto approved or auto rejected an entry will be added in decision table. The next step is Review credit decision. It checks for existing decision if not it creates a manual task and assigns it to queue or UW user directly for adding the decision.

In case of rejected facilities, the retention period is set and updates the customer status.

In case of approved facilities, the facility decision is updated and generates the offer letter as shown below.

Once offer letter is generated, the applicant and the RM is notified. This marks the end of the Underwriting stage process.

Closing:

The stage subprocess of closing stage is as explained in the below diagram.

In the closing stage, the facility is updated with the current processId as “activeprocessId”.This active processId is for signaling and creating adhoc tasks. The next task is for offer acceptance . There are two modes in offer acceptance. The current mode will be fetched from spotlight configuration.

Online mode: A customer action will be raised and wait for signal post customer submission. The list of customer actions may vary for different products. ie)Funding related customer action will be created only for business loans and funding will be created only for those products. In case of waving off a customer action it triggers the below path in XOR where it will create the offline mode task.

Offline mode: A manual task is created and assigned to a RM users so that the user can accept/reject the offer and upload signed documents.

The next step will be based on the product . A faciclity call is made to get the product type. If it is credit card the next three tasks will be skipped.In review executed documents task ,all the documents has to be approved if not a manual task will be assigned to the OPS users where the user has to approve the document and complete the task.

In the settlement review boarding and approval task, a manual task is created for OPS users to manually review all the details and approve for the final onboarding.

Funding instruction task is created only for business loan products in offline mode.The first XOR checks the product type and mode .This task will be assigned to RM Users to add funding account and disbursement details.

Once all the tasks are completed, application withdrawal is disabled. Post this the users cannot withdraw the application. The fulfillment subprocess is where either a account or credit card is being created in transact based on the current product. If the product is business loan or overdraft we Update the customer status in party and transact then create an account and update the details in facility. After creating a contract the applicatnt is notified. In case of credit card, create the credit card in transact and update the facility with card number.

From fulfillment subprocess, the expiry date with which we are updating consents in OPMS. Post that the consent is copied from OPMS to Consent MS.

Finally a notification is sent to the customer regarding the completion of the application. This marks the completion of closing stage.

Consider that a new user is creating an application and selected a product in the Product Dashboard and then provided details in the Personal Information section.

• Now, a prospect entry is created in the Lead entity in the Origination Data Microservice and then the user credentials are created and sent to the user via email. Furthermore, after the customer creation in Party Microservice, a new account is created in Salesforce. Lead entity is updated with the Salesforce account ID and then the Salesforce account is linked to the application in the ODMS. Once the ODMS is updated, an event is raised to create an opportunity in Salesforce for the selected products. Later, the opportunity ID is updated in the application in ODMS.
• After providing the Address and identity details, the application is updated in the ODMS. In addition, the address details are also updated in the respective account in the Salesforce.
• If the user changes the selected product or more products are selected in the Product Selection section, the application is further updated in the ODMS and then the opportunity is also updated in Salesforce.
• The application in the ODMS is further updated after the Identity Verification section.
• After the user submits the application, the application in the ODMS is updated. Moreover, the opportunity status is also updated in Salesforce.
• After the submission process is completed, the user will receive a mail about the application status and further enrollment instructions.

Consider that an existing customer has logged in to the Origination app and is creating a new application.

• An existing customer already has a Salesforce account, therefore, after user authentication the personal and identity details are updated automatically. However, if the user modifies any details, the application is updated in ODMS. Once the ODMS is updated, an event is raised to create an opportunity in Salesforce for the selected products. Later, the opportunity ID is updated in the application in the ODMS.

• After providing the Address and identity details, the application is updated in the ODMS.
• If the user changes the selected product or more products are selected in the Product Selection section, the application is further updated in the ODMS and then the opportunity is also updated in Salesforce.
• The application in the ODMS is further updated after the Identity Verification section.
• After the user submits the application, the application in the ODMS is updated. Moreover, the opportunity status is also updated in Salesforce.
• After the submission process is completed, the user will receive a mail about the application status and further enrollment instructions.

In case of an existing customer, if the details in the Personal Information section are modified, then application status will be moved to Under Review.

In this scenario, consider that a Customer Service Representative is creating an application on behalf of a new user. The CSR journey starts at the Salesforce Workbench which is the backend facing app of Salesforce.

• Firstly, a new account is created for the new user and then a new opportunity is created in Salesforce. In addition, Temenos DigitalAPIs are invoked to create an entry in the Party Microservice and to create a new application in the ODMS. Then, the application is started by using CSR Resume feature.
• The Personal Information section is pre-filled based on the details provided during the Salesforce account creation. After the details are provided in the Address and Identification details section, the application gets updated in the ODMS.
• If the user modifies the selected products or more products are selected in the Product Selection section, the application is further updated in the ODMS and then the opportunity is also updated in Salesforce.
• The application in the ODMS is further updated after the Identity Verification section.
• After the user submits the application, the application in the ODMS is updated. Moreover, the opportunity status is also updated in Salesforce.
• Then, the application is moved to Under Review, Approved, or Denied based on the RH PAM process. Furthermore, the user will receive a mail about the application status and further enrolment journey.

In this scenario, consider that a Customer Service Representative is creating an application on behalf of an existing user. The CSR journey starts at the Salesforce workbench which is the backend facing app of Salesforce.

• Since a Salesforce account is already present for an existing customer, a new opportunity is created. Then, Temenos DigitalAPIs are invoked to create a new application in ODMS. Then, the application is started by using CSR Resume feature.
• The Personal Information section and the Address and Identification details section are automatically updated with the existing details.
• If the user changes the selected product or more products are selected in the Product Selection section, the application is further updated in the ODMS and then the opportunity is also updated in Salesforce.
• The application in the ODMS is further updated after the Identity Verification section.
• After the user submits the application, the application in the ODMS is updated. Moreover, the opportunity status is also updated in Salesforce.

• Then, the application is moved to Under Review, Approved, or Denied based on the RH PAM process. Furthermore, the user will receive a mail about the application status and further enrolment journey.