4. Spend Analysis

Oracle FLEXCUBE uses Spend Analysis to track the Debit transactions of a customer. By tracking the debit transaction of an account the customer can manage all the debit transactions in a more effective way.

This chapter explains the spend analysis feature of Oracle FLEXCUBE and various maintenances and operations associated with it.

This chapter contains the following sections:

• Section 4.1, "Spend Analysis"
• Section 4.2, "Spend Class by a Bank User"
• Section 4.3, "Spend Classes for Channel User"
• Section 4.4, "Spend Rules"

4.1 Spend Analysis

This section contains the following topics:

• Section 4.1.1, "Spend Analysis in Oracle FLEXCUBE"
• Section 4.1.2, "Classification of Entries"
• Section 4.1.3, "Classification of Reversal Entries"

4.1.1 Spend Analysis in Oracle FLEXCUBE

Spend analysis feature of Oracle FLEXCUBE supports the following actions:

• Automatically classify transactions under different spend classes
• Create new spend classes and sub classes as well. This can be done by a bank user or a customer from external channels (channel user).
• Channel user can add sub class codes to bank defined class codes.
• Channel user can add sub class codes to the class codes that are created by the same user.
• Manually reclassify transactions into another class code or sub class code
• View spend analysis details
• Channel user can split a transaction amount into multiple amounts.
• Deletion of channel user defined class code and class sub code.
• Re-opening of a deleted class code or sub class code.

Oracle FLEXCUBE classifies the debit transactions from a customer account under different spend classes.

A spend class refers to the classification of debit transactions made from a customer account for a specific purpose. Based on the type of expenditure from the account, Oracle FLEXCUBE will classify the debit transactions under different spend classes.

This classification is available only for the respective customer. It helps the customer to get the details of the money spend from the account under each spend class.

Consider the examples.

1. Classifying transactions under spend classes

Mr. Sharma is a customer of the bank. He has access to the internet banking system (in this case the Oracle FLEXCUBE Direct Banking System) to view the breakup of all transactions involving debits from his account.

The transactions are already grouped under different spend classes based on certain rules either pre-defined or maintained in Oracle FLEXCUBE.

Mr. Sharma’s debit transactions from September 01, 2013 to September 20, 2013 are given below:

Date	Currency	Amount	Categorization
01-09-2013	INR	40000.00	CHome Loan EMI
08-09-2013	INR	500.00	Swisscom Mobile Bill
10-029-2013	INR	312000.00	Citbank Credit Card Bill
12-09-2013	INR	6000.00	Electricity Bill

Based on the spend rules, the system classifies the transactions under different Class Codes and Sub Class Codes as follows:The system thus classifies the debit transactions from the account based on the bank defined class codes and sub class codes..

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
01-09-2013	INR	40000.00	Loan	Home Loan
08-09-2013	INR	500.00	Mobile Bill	Swisscom Mobile Bill
10-09-2013	INR	12,000.00	Credit Card Bill	Citbank Credit Card
12-09-2013	INR	6,000.00	Electricity Bill

2. Reclassifying transactions to a Bank defined Class Code/Sub Class Code

After a week, Mr. Sharma views the breakup of his transactions from September 01, 2013 to September 20, 2013.

He observes that the transactions are classified under different spend classes as follows:

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
01-09-2013	INR	40,000.00	Loan	Home Loan
08-09-2013	INR	500.00	Mobile Bill	Swisscom Mobile Bill
10-09-2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12-09-2013	INR	6,000.00	Electricity Bill
14-09-2013	INR	5,000.00	Cash
17-09-2013	INR	2,000.00	Cash

Mr. Sharma knows that he has withdrawn INR 5000 and INR 2000 from his account through an ATM transaction. He then used that amount for car servicing and medicines respectively. Also, he is aware that he has paid the Electricity Bill for BESCOM.Now, by seeing the transactions he has re-categorized the transactions based on his spending nature.

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/9/2013	INR	40,000.00	Loan	Home Loan
8/9/2013	INR	500	Mobile Bill	Swisscom Mobile Bill
10/9/2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12/9/2013	INR	6,000.00	Electricity Bill	BESCOM
14/09/2013	INR	5,000.00	Repair & Maintenance	-
17/09/2013	INR	2,000.00	Medical Bills	-

3. Re-categorization of a transaction to a bank defined “Class Code” and user defined “Sub Class Code”.

Mr. Sharma finds that there is no specific “Sub Class Code” available to categorize the car servicing under Repair and Maintenance Class Code which has been defined by the bank. Hence, he adds a new “Sub Class Code” called “Car Servicing” under the bank defined “Class Code” Repair and Maintenance and re-categorizes the transaction of INR 5000 to “Car Servicing”.

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/9/2013	INR	40,000.00	Loan	Home Loan
8/9/2013	INR	500	Mobile Bill	Swisscom Mobile Bill
10/9/2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12/9/2013	INR	6,000.00	Electricity Bill	BESCOM
14/09/2013	INR	5,000.00	Repair & Maintenance	Car Servicing
17/09/2013	INR	2,000.00	Medical Bills	-

4. Re-categorization of a Transaction to a user defined ‘Class Code’ and user defined ‘Sub Class Code’.

On September 23, 2013 Mr.Sharma logs in to his account and views his transactions from 01-September-2013 to 23-September-2013. In this period, he noticed that two or more transactions are made in the account as shown below:

20-September-2013: He has a made a funds transfer of INR.3000 to his friend Mr.Akshay within the same bank. It has been classified as “Other Expenses” in spend class based on the bank defined rules.Mr.Sharma re-categorizing the above transaction as follows:

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/9/2013	INR	40,000.00	Loan	Home Loan
8/9/2013	INR	500	Mobile Bill	Swisscom Mobile Bill
10/9/2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12/9/2013	INR	6,000.00	Electricity Bill	BESCOM
14/09/2013	INR	5,000.00	Repair & Maintenance	Car Servicing
17/09/2013	INR	2,000.00	Medical Bills	-
20/09/2013	INR	3,000.00	Other Expenses	-

For INR.3, 000, he created a new ‘Class Code’ called ‘Funds Transfer’ new “Sub Class Code” called “To Akshay”, and then he re-categorized the transaction.

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/9/2013	INR	40,000.00	Loan	Home Loan
8/9/2013	INR	500	Mobile Bill	Swisscom Mobile Bill
10/9/2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12/9/2013	INR	6,000.00	Electricity Bill	BESCOM
14/09/2013	INR	5,000.00	Repair & Maintenance	Car Servicing
17/09/2013	INR	2,000.00	Medical Bills	-
20/09/2013	INR	3,000.00	Funds Trans­fer	To Akshay

5. Deletion of User Defined ‘Sub Class Code’

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/9/2013	INR	40,000.00	Loan	Home Loan
8/9/2013	INR	500	Mobile Bill	Swisscom Mobile Bill
10/9/2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12/9/2013	INR	6,000.00	Electricity Bill	BESCOM
14/09/2013	INR	5,000.00	Repair & Maintenance	Car Servicing
17/09/2013	INR	2,000.00	Medical Bills	-
20/09/2013	INR	3,000.00	Funds Trans­fer	To Akshay

Mr.Sharma logs into the system and feels that he does not require specific “Sub Class Code” for car servicing and that he has deleted the “Sub Class Code -Car Servicing”. Here, Car Servicing is under the “Class Code -Repair and Maintenance”. Though the transactions are assigned to the “Sub Class Code - Car Servicing” the system allows the user to delete the user defined sub class codes and assigns the transaction automatically to its parent class code “Repair and Maintenance”.

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/9/2013	INR	40,000.00	Loan	Home Loan
8/9/2013	INR	500	Mobile Bill	Swisscom Mobile Bill
10/9/2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12/9/2013	INR	6,000.00	Electricity Bill	BESCOM
14/09/2013	INR	5,000.00	Repair & Maintenance	-
17/09/2013	INR	2,000.00	Medical Bills	-
20/09/2013	INR	3,000.00	Funds Trans­fer	To Akshay

6. Deletion of User Defined ‘Class Code’

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/9/2013	INR	40,000.00	Loan	Home Loan
8/9/2013	INR	500	Mobile Bill	Swisscom Mobile Bill
10/9/2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12/9/2013	INR	6,000.00	Electricity Bill	BESCOM
14/09/2013	INR	5,000.00	Repair & Maintenance	-
17/09/2013	INR	2,000.00	Medical Bills	-
20/09/2013	INR	3,000.00	Funds Trans­fer	To Akshay

Mr.Sharma logs into the system and feels that he does not require the Class Code “Funds Transfer”. While he is trying to delete this class code, the system display an error message stating that the “Class Codes which has underlying transactions cannot be deleted”.

Since the class code “Funds Transfer” has a “Sub Class Code - To Akshay” and it has an underlying transaction, the system does not allow the user to delete the user defined class code. User need to re classify the underlying transaction to any other “Class Code/Sub Class Code” to delete the Class Code “Funds Transfer”.

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/9/2013	INR	40,000.00	Loan	Home Loan
8/9/2013	INR	500	Mobile Bill	Swisscom Mobile Bill
10/9/2013	INR	12,000.00	Credit Card Bill	CITI Bank CC
12/9/2013	INR	6,000.00	Electricity Bill	BESCOM
14/09/2013	INR	5,000.00	Repair & Maintenance	-
17/09/2013	INR	2,000.00	Medical Bills	-
20/09/2013	INR	3,000.00	Funds Transfer	To Akshay

7. Splitting of a Transaction

The following transactions are made by a customer whose name is Mr.Ajay. He has the access to internet banking system (in this case the Oracle FLEXCUBE Direct Banking system) and he will be able to view the breakup of all the transactions involving debits from his account using spend analysis facility.

His transactions (only debits) from 01-November- 2013 to 20- November-2013 involve the following:

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/11/2013	INR	40,000.00	Loan	-
8/11/2013	INR	500	Mobile Bill	-
10/11/2013	INR	12,000.00	Credit Card Bill	-
20/11/2013	INR	10,000.00	Cash	-

Mr.Ajay realized that he has withdrawn cash from an ATM and used it for multiple purposes like Purchasing Medicines, Groceries and Pizza. Hence, he splits the cash transactions into three and assigns to 3 “Sub Class Codes” created by him. N.

• INR 5000 – For Medical Bills.
• INR 3000 – For Groceries
• INR 2000 – For Pizza

For INR.5, 000, he has created three new “Sub Class Codes” called “Medical Bills”, “Groceries” and “Pizza” under the “Class Code - Cash” and then he re-categorizes the transaction.

Date	Currency	Amount	Categorization
			Class Code	Sub Class Code
1/11/2013	INR	40,000.00	Loan	-
8/11/2013	INR	500	Mobile Bill	-
10/11/2013	INR	12,000.00	Credit Card Bill	-
20/11/2013	INR	5,000.00	Cash	Medical Bills
20/11/2013	INR	3,000.00	Cash	Groceries
20/11/2013	INR	2,000.00	Cash	Pizza

4.1.2 Classification of Entries

Every debit entry can be classified under a spend class based on certain attributes held by the transaction.

Based on the rules defined in the ‘Spend Rule Maintenance’ screen, these attributes decide the classification of a transaction.

The following entries will be taken up for classification:

• Debit entries
• Entries involving CASA accounts for whom spend analysis tracking is allowed at the account level

An entry has the following attributes:

Field Name	Description
Spend Class	The Spend Class to which the entry/transaction is mapped to.
Source	The Source Code of the Internal/External System
Module	The Module encompassing the entry in consideration
Transaction Ref­erence	The Reference Number of a transaction
Event Code	This would identify the purpose for which the transaction had been triggered
Event Code Description	The description of the event code used to identify the purpose of the transaction.
Branch Code	The branch from which the entry was triggered.
Transaction Date	The date on which the transaction had occurred.
Customer	The Customer for whom the transaction had occurred.
Account Number	The account number for which the transaction was triggered.
Amount	The amount which was transacted
Currency	Currency of the above mentioned Amount
Additional Infor­mation	Additional information about the transaction detailed in the preced­ing statement narrative which is to be passed on to the account owner.
External System User ID	The User ID mapped to the External System.
Channel User ID	The User ID used to access the Channel from which the transaction was initiated.
Instrument Code	Instruments like Cheques issued can be captured here.
Applied Rule	The rule which has been applied to arrive at the Spend Class mapped to this entry.

Each entry considered for spend analysis is subject to a rule-application logic, which takes the entry through each rule arranged in ascending order of priority. Once a rule succeeds in its execution, the spend class associated with that rule is assigned to the entry and the rest of the rules are not executed. This process is repeated for the rest of the entries.

4.1.3 Classification of Reversal Entries

In case of a reversal entry, either the FCY amount/LCY amount is negative or the event is reversal-specific or both.

A reversal entry is considered if the following attributes match the original entry:

Field name	Description
Module	The Module encompassing the entry in consideration
Value Date	The value date of the Transaction
Transaction Ref­erence	The Reference Number of a transaction for all modules except Loans
Related Account	For Loan Modules
Branch Code	The branch from which the entry was triggered.
Account Number	The account number for which the transaction was triggered.
Amount Tag	The amount tag used
Currency	Currency of the above mentioned Amount

The reversed entry is matched with the original entry by searching spend entries. If the entry is found, the original entry and reversed entry are uncategorized. The process status is updated as ‘Deleted’ so that the entries are not considered for spend analysis. The corresponding entry in spend entry group is also updated.

If a match for a reversal entry is not found in the original entry, then the system applies the normal categorization process based on rules.

Reversal of Entries for Split Transactions

A transaction can be split into multiple amounts and classified into class codes or sub class codes. If a transaction has been split already and the user wants to change the splitting of the transaction, then the original splitting needs to be reversed completely.

For example: a transaction of USD 11,000 has been split into USD 5,000, USD 4,000 and USD 2,000. After some time, the user wants to split the transaction into USD 6,000, USD 3,000 and USD 2,000 then the earlier splitting needs to be reversed and the user can begin splitting the transaction as desired.

If the original transaction has been reversed in UBS, then the entire split amounts will be reversed and there will not be any record available against the “Class Code” or “Sub Class Code” to which it was assigned.

4.2 Spend Class by a Bank User

This section contains the following topics:

• Section 4.2.1, "Maintaining Spend Class by a Bank User"
• Section 4.2.2, "Viewing Class Code Summary"

4.2.1 Maintaining Spend Class by a Bank User

Multiple sub class codes for a specific class code can be maintained by a bank user in the ‘Spend Class for Bank’ screen. You can invoke this screen by typing ‘ITDSPCBK’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.

Specify the following details in this screen:

Class Code

The class code is system generated.

Description

Specify a description of the system generated class code.

Sub Class Code

The default sub class code is system generated.

Description

Specify a description of the sub class code.

The following operations can be performed in this screen:

• Input (New).
• Enter Query.
• Unlock.
• Close.
• Re-open.
• Authorization.

4.2.2 Viewing Class Code Summary

You can view a list of class codes maintained by the bank user in the ‘Spend Class Summary’ Screen. You can invoke this screen by typing ‘ITSSPCBK’ in the on the field at the top right corner of the application toolbar and click the adjoining arrow button.

You can search for a record by entering details in the following fields:

• Authorization Status
• Record Status
• Class Code

Click the search button and the following fields will populated with values based on your search parameters:

• Authorization Status
• Record Status
• Class Code
• Description

4.3 Spend Classes for Channel User

This section contains the following topics:

• Section 4.3.1, "Maintaining Spend Classes for Channel User"
• Section 4.3.2, "Viewing Spend Class Summary"

4.3.1 Maintaining Spend Classes for Channel User

The following activities can be done in this screen:

• Creation of Class Code by channel user.
• Creation of Sub Class Code for the channel user defined class code.
• Creation of Sub Class Code for the Bank user defined class code.

To invoke this screen, type ‘ITDSPCLS’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.

Specify the following details:

Class Code

The system generates a unique spend class code. This will be a unique identifier of the spend class that you maintain. However, you cannot modify the class code.

Description

Enter a brief description of the spend class that you maintain.

Customer Number

The value in this field is auto populated when the channel user is creating a Class Code from the channel. This field is not be applicable when the “Sub Class Code” is added to a bank defined “Class Code” by the customer.

Note

If a Customer No is associated with a spend class, then the spend class is available only for this particular customer.

Customer Name

Based on the customer number selected, the system displays the name of the customer. This field is not be applicable when the “Sub Class Code” is added to a bank defined “Class Code” by the customer.

Internal Class Code

Specify the internal class code for bank reference. When a customer creates a spend class through other modes, you can map that class code to an internal class code. This helps the bank identify and classify customer created spend classes.

Description

The system displays the description of the internal class code.

Once you have captured the above details, save the maintenance.

Note

• Oracle FLEXCUBE receives and updates the details of spend classes created using external systems through gateway services. The system will check whether the spend class received from the external system already exists in the Oracle FLEXCUBE with the same name. If a spend class with the same name already exists, the system will not allow the creation of a duplicate spend class.
• You cannot modify or close the spend classes created using external systems.
• If you modify a spend class, the system will update the previous spend transactions to bear the modified spend class details.

Sub Class Code Details

Sub Class Code

The value in this field is defaulted based on the selection of the class code. All valid class sub codes defined under the selected class code is displayed.

A channel user can add a sub class code to the existing bank defined class code or channel user defined class code. The option list adjoining the ‘Class Code’ field lists the class codes as maintained by the bank user and the class codes as maintained by the channel user. The channel can select a class code to map the sub class code.

Description

Specify a description of the Sub Class Code.

Customer Number

The customer ID is defaulted when the Class Sub Code is added by a channel user. If customer id is assigned then that particular sub class code is applicable to that customer only.

Customer Name

The customer name is defaulted here. This field is not applicable when the “Sub Class Code” is added to a user defined “Class Code” by the customer.

4.3.2 Viewing Spend Class Summary

You can view a slist of all the class codes created by the bank user and the channel user. To invoke this screen, type ‘ITSSPCLS’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.

You can search for the spend class records based on one or more of the following parameters:

• Authorization status of the record
• Class code
• Customer number
• Record status
• Description of the class

Once you have set the search parameters, click ‘Search’ button. The system displays the spend class maintenance records that match the search criteria.

4.4 Spend Rules

This section contains the following topics:

• Section 4.4.1, "Defining Spend Rules"
• Section 4.4.2, "Creating Conditions with Expressions"
• Section 4.4.3, "Viewing Customer Spend Analysis Details"
• Section 4.4.4, "Reclassification of Spend Classes"
• Section 4.4.5, "Deletion of Spend Class"
• Section 4.4.6, "Deletion of Sub Class Code"
• Section 4.4.7, "Splitting a Transaction"

4.4.1 Defining Spend Rules

Oracle FLEXCUBE classifies the debit transactions into different spend classes based on the spend rules. These rules can be setup only for branch defined class codes and sub class codes.You can define new spend rules using ‘Spend Rule Maintenance’ screen. To invoke this screen, type ‘ITDSPRLM’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.

Specify the following details:

Bank Code

The system displays the bank code.

Priority

Specify the priority of the spend rule sequence. You can set the priority in any random order (1, 100, 91, 888 etc.).

The system considers the priority of a rule while classifying transactions.

Condition

Specify the condition to be used in the rule. You can define a condition using the ‘Expression’ button.

For further details on defining conditions using expressions, refer to the section ‘Creating Expressions’ in this chapter.

If a debit entry satisfies the condition and result, the system will classify that entry under the spend class mapped to the rule.

Result

Specify whether the condition is expected should be met or not. You can choose one of the following results from the drop-down list:

• True
• False

If a debit entry satisfies the condition and result, the system will classify that entry under the spend class mapped to the rule.

Class Code

Specify the class code to which you need to map the spend rule. The option list displays all the system defined spend class codes maintained in the system. Choose the appropriate one.

Description

The system displays the description of the spend class.

Negative Points

The system displays the negative points that the rule sequence has. The system displays zero as the default value when you define the rule.

The system adds a negative score only when an entry classified based on this condition is reclassified later under a different system defined spend class.

When the negative points accumulated by a rule exceed a threshold limit set at Interactions Preferences, the system brings down the priority of the rule. The system considers the priority of a rule while classifying transactions. As the rule priority goes down, the system is less likely to consider the rule while classifying transactions.

Sub Class Code

Select the sub class code from the adjoining option list. All bank defined sub class codes as maintained in the system are displayed here.

Description

The description of the sub class code is defaulted.

4.4.2 Creating Conditions with Expressions

You can build the conditions with expressions for the spend rule conditions using ‘Expression’ screen. Click ‘Expression’ button on ‘Spend Rule Maintenance’ screen.

You need to specify the following details to create the expression.

Condition

Based on the element, operators and logical operators that you select in the below fields, the system displays the condition.

Elements

Select element based on which you need to build a condition for spend rule. The following elements are applicable to spend rules:

Element	Field	Description
$SOURCE	Source	The source code of the internal/external system
$MOD	Module	The module encompassing the entry in considera­tion
$TRNREF	Transaction Ref­erence	The reference number of the transaction
$EVENT	Event Code	The purpose of triggering the transaction
$AMOUNT	Amount	The amount transacted
$CCY	Currency	Currency in which the amount is represented
$ADDLINFO	Additional Infor­mation	Additional transaction details from the preceding statement narrative which will be passed on to the account owner
$EXTSYSUID	External System User ID	The user ID mapped to the external system
$CHANNE­LUID	Channel User ID	The user ID used to access the channel from which the transaction was initiated
$INSTMT­CODE	Instrument Code	Code of the instruments such as cheques
$TRNCODE	Transaction Code	Transaction code
$TRNDESC	Transaction Description	Transaction description
$AMTTAG	Amount Tag	Amount tag

Functions

Specify the mathematical function for building the condition. The drop-down list displays the following functions:

• Absolute
• Greatest
• Round
• Trunc
• Floor
• Ceil
• Power
• Mod

Choose the appropriate one.

Operators

Select the operator for building a condition for spend rule. You can use multiple elements, in conjunction with the functions and arithmetic operators. The drop-down list displays the following operators:

• + (add)
• - (subtract)
• * (multiply)
• / (divide)

Choose the appropriate one.

Logical Operators

Select the logical operator for building a condition for spend rule. The system uses the logical operators in combination with the elements for creating derivation rules. The drop-down list displays the following logical operators:

• > (greater than)
• >= (greater than or equal to)
• < (less than)
• <= (less than or equal to)
• = (equal to)
• < > (not equal to)

Choose the appropriate one.

Once you have created the condition, save it.

The system will classify each debit transaction under different spend classes based on the rule-spend class mapping set here. You can also create a rule to classify the transactions that do not qualify any of the rules maintained in the system. These rules can be defined for a bank user defined class code and sub class code.

4.4.3 Viewing Customer Spend Analysis Details

You can view the details of customer spend entries and transactions using ‘Spend Analysis’ screen. To invoke this screen, type ‘ITDSPQRY’ in the field at the top right corner of the Application toolbar and click the adjoining arrow button.

You can search for the spend classification details based on the following parameters:

Customer ID

Specify the CIF of the customer whose spend analysis you wish to view. The option list displays all valid customer numbers maintained in the system. Choose the appropriate one.

Based on the customer number, the system displays the name of the customer.

Account Currency

Specify the currency code. The system will display the customer spend analysis for the currency specified here.

Based on the currency code specified, the system displays the account description.

Spend Entries

Click ‘Spend Entries’ tab to view the spend entries for the selected customer and currency.

You can view the following details of each customer spend entry.

• Month of the spend entry
• Year of the spend entry
• Class Code
• Description
• Sub Class Code: which is the sub class code to which the transaction is mapped.
• Description: which is the description of the sub class code.
• Total Amount

Transactions

Click ‘Transactions’ tab to view the spend transactions for the selected customer and currency.

You can view the following details of each spend transaction under the ‘Transactions’ tab.

• Class code to which the entry/transaction is mapped
• Description of the Class Code
• Sub Class Code
• Description of the sub class code
• Transaction Date
• Currency of the amount
• Amount of transaction
• Branch of the transaction
• Source code of the internal/external system
• Reference number of the transaction
• Additional information on the transaction in the preceding statement narrative to be passed on to the account owner
• User ID mapped to the external system
• Channel User ID to access the channel from which the transaction was initiated
• Rule applied to classify the entry under a the spend class

4.4.4 Reclassification of Spend Classes

A channel user can reclassify an already defined spend class to some other class code or sub class code. The following actions are possible:

• Channel user can re classify a transaction to a bank defined “Sub Class Code”.
• Channel user can re classify a transaction to a channel user defined “Sub Class Code”.
• Channel user can re classify a transaction to a bank defined "Class Code".
• Channel user can re classify a transaction to a channel user defined "Class Code".

This can be achieved through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.

4.4.5 Deletion of Spend Class

Redundant class code and sub class codes can be deleted. This functionality can be used by a channel user as well as a bank user. Channels users can close or delete the “Class Code”/”Sub Class Code” created by him/her. Similarly, the bank user close or delete the “Class Code” or “Sub Class Code” created at the Bank level.

Closure of Class Code

The class codes can be closed or deleted by a channel user provided there are no underlying transactions associated with the class code or sub class code associated with it. When a Class Code is closed, then the underlying sub class code becomes invalid. The channel user cannot re-classify a closed class code. A channel user can close a class code through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.

A channel user can re-open a closed class code which pertains to him or her. A channel user can reopen a class code through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.

4.4.6 Deletion of Sub Class Code

A channel user can delete a sub class code that is created by him or her. A channel user can delete a sub class code even when it is associated with a bank defined Class Code as well. A sub class code can be deleted only if its parent class code is in ‘Open’ status. When a sub class code is deleted, then all underlying transactions associated with the sub class code is then mapped to the parent class code. A channel user can close a sub class code through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.

A bank user is allowed to delete a sub class code associated with the bank defined class code. When a sub class code is deleted, then all underlying transactions associated with the sub class code is then mapped to the parent class code. A bank user will not be allowed to delete a channel user defined class code or sub class code.

4.4.7 Splitting a Transaction

A channel user can split a transaction and classify it into multiple class codes and sub class codes. A transaction can be split into multiple amounts and these amounts can be classified into multiple class code and sub class codes. The channel user has a choice to reclassify an already split amount to another class code or sub class code. If the original transaction is reversed in the FCUBS system, then the entire split amount is reversed and no record will be associated with the assigned class code or sub class code. When the earlier splitting is reversed then the whole transaction will be shown against the “Class Code” or “Class Sub Code” to which it was originally associated with before splitting.

The split amount is displayed in the ‘Spend Analysis’ (ITDSPQRY) screen, instead of the original amount. The total split amount should be equal to the original transaction amount or else the system displays an error message. A transaction which is already split, cannot be split further. However, if the splitting has to be done differently, then the transactions can be reversed. A channel user can split transaction through the FCUBSInteractionService messaging service. For more information on this service refer to the section ‘Annexure - List of messages’ in the ‘Gateway Services module’.