CRA-INDIA & APAC Holding Areas

• The CRA-INDIA application works in specific Asian countries
• These countries include India, China, Indonesia, Malaysia, Philippines, Taiwan, and Vietnam
• All listed countries receive transactions from the Flexcube application
• The workflow is based on the product in question

Holding Area

• The holding area is specifically for India
• All transactions received from Flexcube are visible here
• No action can occur on transactions sitting in the holding area, it is merely a location to view them
• Transactions are removed once grouped
• The holding area serves the purpose of viewing transactions received from Flexcube for India

Holding Area: APAC

• All other countries receive transactions in holding area APAC
• All transaction types such as Clearing, Overdraft, Direct, and Contingent are available in the Holding Area
• Overdraft transactions do not involve Operations and LMA Users, the workflow is set as "Credit Rules," and automatically proceeds
• For non-overdraft transactions, an Operations user must add comments and attachments before submitting in Holding Area APAC

Operational Users

• The operations user role will be mapped to different Workgroups in the CRA application under system admin (username and workgroup mapping)
• Operations users can view only the transactions mapped to their workgroup
• Email notifications are sent to Operations DL for mapped workgroup transactions
• There is email notification from CRA to Operations users when transactions appear in Holding Area APAC
• Transactions are assigned to Operations based on Workgroup mapping, defined under the Workgroup Management screen
• Email notifications are sent to LMA users for workflow dropdown selection, once Operations users have submitted their comments

LMA Users

• LMA users must select a workflow dropdown in Holding Area and submit the transaction
• Types of workflow values LMA users can select; Credit Rules, Manual Approver, and Technical OT
• 'Select' appears as the default value
• The workflow dropdown is a mandatory field
• Earmarking information, guiding LMA on whether an OT is Technical, is available and is similar to Earmarking information link in the current ASIA Version Enter new Transaction screen
• Product information for transaction type identification (Clearing, Overdraft, Direct, Contingent) will be available in Holding Area

Approvers

• All approvers will have the transactions assigned to them in their in-tray
• Approvers can open transactions from their in-tray and take action accordingly
• Approve, Reject, and Hold are actions approvers can take
• Approvers receive email notifications and can take action via email replies

LMA In-Tray

• All transactions assigned to LMA users go to the LMA In-tray
• LMA users can click on a transaction number and open the transaction to manually add approvers and submit to the next step
• LMA users can send transactions “Back to Holding Area” taking the transaction back
• LMA users can also perform a "Rescue" operation which removes a transaction from all in-trays and stops any further action on it
• Email notification is sent to the LMA Maker user when a transaction is assigned

Grouping Process

• After workflow dropdown selection and clicking submit in Holding Area, transactions are sent for grouping
• CitiRisk Availments runs regularly to group similar transactions
• Grouping criteria depends on parameters, cases where facility ID (GFCID) and facility description/facility ID exist and cases with no facility ID, where bunching occurs at GFCID and account number
• Technical OTs will not be grouped; they will be raised as single transactions only
• Credit Rule is automatically selected for Overdraft Transactions and transactions will automatically be grouped, no input from LMA user is required

Workflows

• There are four different workflows in the application: Credit Rule Pass, Credit Rule Fail, Manual Approver, and Technical OT

Credit Rule Pass

• CRA receives transactions from Flexcube for overdraft products, which are automatically set to Credit Rule workflow
• The transactions are automatically grouped
• Approvers are assigned based on Credit Rules, Approval Matrix and Approval Grid screen, and transaction action is sent to relevant approvers
• Approvers can take actions on these grouped transactions from their in-tray

Credit Rule Fail

• CRA receives transactions from Flexcube for overdraft products, Credit Rule workflow is automatically selected
• Transactions will be grouped automatically
• If Credit Rule fails, the transaction is assigned to LMA Maker and if Credit rule not setup, Approvers are not configured in Approval Matrix or Approval Grid
• LMA Maker manually adds approver and submits to Checker
• LMA Checker reviews transaction and submits to Approvers
• Approvers can take approve, reject, or hold action from their approvers in-tray

Manual Approver

• CRA receives transactions from Flexcube (non-overdraft products), assigned to Operations user
• Email notification is sent to the Operations user
• Operations user can enter comments and attachment and submit to next step
• After, an email gets sent to LMA users
• the LMA User selects the Workflow to “Manual Approver” and submit
• Grouping of transactions occurs then workflow scheduler runs and assigns trans to LMA in-tray for LMA Maker user
• LMA Maker adds approver manually and submit to Checker
• LMA Checker will review the transaction and submit to Approvers
• Approvers can take approve, Reject or Hold action on their grouped transactions from Approvers in-tray
• Assigned again to LMA Maker after approvers take Approve action for their review and then submitted to LMA checker user

Technical OT

• CRA receives transactions from Flexcube (non-overdraft products), assigned to Operations user
• Email notification gets sent to the Operations user
• Operations user can enter comments and attachments and submit to next step
• Email notification gets sent to LMA users
• LMA user sets workflow as “Technical OT” and submit
• Technical OT transactions will not be grouped but will be raised as single OT only
• LMA Maker reviews and submit the transaction
• LMA checker user reviews action and closes in CRA if transactions take Approve/Reject action

Transaction in Progress

• Transaction in Progress tab displays transactions in the following status': Pending, Approved, Rejected, Hold
• Users can check the pending locations of transactions by clicking on the transaction number

LMA Updating Approvers (Limit Monitoring Analyst)

• LMA (Limit Monitoring Analyst) role is to update the approver after submission of the workflow when approvers are unavailable
• Applies to “Manual Approver” and “Credit Rule Failure” workflows
• Once a transaction is assigned to the LMA Maker user, they can add approvers and send transaction off to approvers
• After LMA submission, the Transaction is pending at Approvers
• LMA users can see the LMA/Pending button and use it to see the option to add approvers
• Only pending Tier Approvers can be updated, if a Tier Approver has already taken action, LMA user cannot add/ delete that Tier Approver
• Deleting all tier approvers prompts the message to add a minimum of 1

RFI (Request Further Information) and Rework

• There is now an RFI action button for the return-to-rework option
• Approvers can now take “Approve”, “Reject”, “Hold”, AND “RFI” actions
• If actioning RFI it is pertinent approvers provide comments beforehand
• Instead of submitting, approvers now select the ‘Hold’ radio button and action the 'RFI' button, which is positioned at the end of the approvers in-tray, alongside the submit button
• Email notifications are sent to LMA users when approvers click on RFI button
• The transaction will remain in the current approvers in-tray until actioned
• Only comments and attachment LMA users can update when actioned in a transaction in progress screen with the LMA button clicked on

Additional Items

• Update tier approvers cannot be achieved if the approver selects RFI action
• Email notification will be delivered to newly added Approvers once transaction is pending at the tier in which they are positioned

RFI Action Details

• Once an LMA user provides comments and adds an attachment, send an email to the approver who previously selected this action
• Approver can take RFI action multiple times
• For manual approver flow and credit rule failure workflows, and a transaction that has moved to approvers, if any new OT arrives, then a new group is assigned
• System will follow up/escalate to other approvers if cut off isn't approaching if approver selected Return to Rework
• Approver can still open the transaction and Approve/Reject should they have given the RFI action
• Transaction assigned to approver, RFI done at group level not at transaction level

Approvers Action

• When approvers action a transaction, it moves along the workflow and when fully approved, is then given to Flexcube
• When approvers reject a transaction, it doesn’t move and the rejection is shared with Flexcube
• If approvers hold a transaction, it does not more and stays in appropriate queue
• When the user selects the ‘Reject’ or ‘Approve’ some other transactions of a group will still hold actions
• Approvers can either accept or reject specific email transactions

Approvers Actions (Continued)

• Email, ‘Partial Approve’ will see remaining transactions all at the same step
• Approvers must record email along record ID, after it a new group is created and a updated is sent to the approver
• Approvers should the partially reject- the remaining also sit at the same step, although the approver has to again email across records

LMA User Action

• LMA Maker user actions; 'Submit', 'Rescue', 'Back to HA.'
• To "Submit action," maker adds required approvers before checker review in all but technical OT workflows

Rescue Action

• Rescue button appears for only LMA users when they open transaction from the LMA in-tray
• Available to LMA Maker as well as being after in checkers in manual flows
• When selected, user must comment before they press the 'Submit' button
• The result is transactions are eradicated from area APAC / screens, and emails get sent to stakeholders
• To view the "rescued" action look under status rescured when username makes comment

Additional Rescue Facts

• Rescue button is available to those in LMA / checkers, must then comment before it button is pressed
• Transaction level, not group level when done on technical OT and credit rules
• All those involved get emailed after / operators will then be selected from users (DL's)
• Then will be shown new location of rescured / users

Back To HA

• User return to holding area after approvers action if in manual / check
• The returned button will available under the after sections, under makers and checkers trays
• The result is maker's area sees the group button comes to it, to which data has to be pulled from key fields
• Operation comments will still sit as the "group" transaction comments, and transactions also carry operations over

LMA Checker

• LMA checker can action; "Back to ha/Rescue/Submits Approvers"
• Action to HA is same as in Maker's section, same with the "Rescue', although submits approvers takes the same action to check
• LMA will check for those rejecting for those in workflows, rejection only, so will be closed and to Flex Cube
• Should Manual / Fail credit be re jeered it runs back to Maker who must check

CRMS Administration

• The cut off times, set the best set of standards
• Cut off occurs when system locks trans at business and time given
• The parameters that are set define how it goes through; family / descript / queues to best meet them
• You have 2 para that are given in the static data, in section, that can be cut-off

Extra Facts

• The below steps should follow system stop, as should the product families (ASIA)
• Each code must be run in Flex Cube, as when codes come they must fit

Allowed Products

• Those descript must be correctly followed, and be updated so that to create codes for future product
• Added must the family, descript and overdraft flag, so products fit

Management

• Operations must be able to use the "manage' section
• A screen was built for the group of "operation", and to put the codes into form
• "operations User" can make the "WORK HOLD" action available
• Email will be alerted to DL's, and one can also update in what is the "WORK GROUPS"

Setup

• Set up should go to " Admin Section"
• Assign them if the system isn't mapping code to the default, which will the the OPS (DL)

Matrix Approval

• Matrix helps with knowing calculations, but business will load the "tagging file" so business can then make files
• User can select file via selection and "upload file', although details get loaded as file is chosen from section

Additional Points

• User can alter tag section in various forms, all "GFCID"
• User can download from select section, and upload, as well use the template
• As a base approvers are laid out with names, should names not action then RM names will be followed, and if there are issues business /risk will be followed

Threshold

• Grid sets data, and grid makes sure app can get success to OD and that then can access the threshold with Group

Credit Rules

• Rules make sure grid can make right decision, grid allows approvers to check data with family parameters
• This info comes customer size, or from lending

Segments

• Derived from management / 2 segments: business / sub / line, although codes follow facility management, rating are also very key
• The listing of risk follows best to worst, plus the " Flexcube Value' and with each set is shared
• Those numbers set the actuals, and they must be set up so that OD makes sense and time isn't messed, the logic sits as " per below"
• "typefacility" are checked, and those values are set below

"Level Of Appprover"

• Is also listed from the CRM

Checker points

• checker points are in all, and if " y " , it is key threshold can be checked in threshold or matrix
• Must then note in the CRM

Checker / MAKER action DASH

• Those items are for action and codes on the screens, and for any file upload " must checker review
• Add / delete / excel must be set up
• There is then a screen to see codes pending, and no two users can click at the same point, with fields for editing

Additional Facts

• Data will still sit at time " save and checker is set, although codes will be validated'
• Uniqueness is is validate by time

Approvals

• Checker then has to look, for approval " and what the codes have at stage, and all is sent to all

Email 2

• The email will be alerted to checkers/ makers
• User selects country to download the codes, with also having admin options

Data

• The data has times and which running
• The code all has to be there and time on hold as when info get set
• It's key download options must be available for the static and in a selectable way too

USER setup

• USER set up, that those can look through country/ see code then can select

Report

• In section that must be able to found with fields listed / product must be also selected
• The action is to follow with the "product family" (codes listed in the screen)
• Each will list from grid so the set up is all running for code and the running action and codes are as they should