The Payments and Collections (PC) Module of Oracle FLEXCUBE helps you process local currency funds transfer transactions initiated either by your customer through an Electronic Banking System, or by your staff in any of your branches on behalf of a customer. The PC module handles the following types of transactions:
Collection transactions are of two types:
To process collection transactions, the creditor’s bank will send a message (Outgoing DD/RFD) to the debtor’s bank. The debtor’s bank will receive the message (Incoming DD/RD) and after performing the required validations (availability of funds, agreement details etc.), will draw the specified amount from the debtor’s account and transfer it to the creditor’s bank. In case of an RFD an approval message needs to be sent to the creditor’s bank, but in case of a DD no response needs to be sent. A DD agreement is deemed to be approved in case no response is received from the debtor’s bank within a specific number of days.
If for some reasons (insufficiency of funds for instance), the debtor’s bank rejects the Incoming DD/RFD, the message will result in a Reject of Incoming DD/RFD. On the creditor’s side, the same will be processed as a Reject of Outgoing DD/RFD.
This chapter contains the following sections:
The primary difference between a DD and an RFD transaction is that a DD will be considered processed/settled if not rejected within the stipulated period known as the response period. An RFD, on the other hand, will be considered closed if not approved within the specified response period. Further, you can recall a DD whereas an RFD cannot be recalled. A recall is initiated by the debtor when he chooses to re-collect his funds from the creditor’s account.
The various types of collection transactions can be summarized as follows:
Direct Debit (DD) Transactions
Request for Debit (RFD) Transactions
In the Payments module, you can perform the following operations:
Before you begin operations in the Payments and Collections module of Oracle FLEXCUBE, you have to maintain certain information that is required to process the transactions that you receive. This maintenance is done in screens invoked from the Application Browser.
Local Bank Directory Maintenance
You can maintain a directory of Local Clearing Banks in the Local Banks screen. In this screen, you have to specify a unique Code for the bank a brief description. In addition, you can capture the addresses of the bank, its stage of transition to the IBAN Format, and the various clearing networks supported by the bank. You can also indicate whether the bank supports DD and RFD transactions.
Clearing Network Maintenance
You can define the networks (such as SORBNET) over which you communicate with banks and other financial institutions for transactions.
Bank Redirection Maintenance
On occasion, the transactions involving a specific bank may have to be redirected to another bank. You can capture this information in the Bank Redirection Maintenance screen.
Account Redirection Maintenance
The transactions involving a specific account in Oracle FLEXCUBE may have to be redirected to another account maintained in Oracle FLEXCUBE. You can capture this information in the Account Redirection Maintenance screen.
Upload Source Maintenance
You can maintain the different sources from which you receive transactions as part of the Upload Source Maintenance. The details of such transactions are uploaded from such external sources into Oracle FLEXCUBE.
Upload Source Parameters Maintenance
You can define certain parameters for a product category and upload source combination. As part of the parameters you specify for the combination, you can specify details such as the transaction retention period, and if transactions should be automatically authorized, etc.
Customer Station Maintenance
In the Customer Station Maintenance screen, you can specify the authorized customers and the accounts for a specific station and source combination. All transactions that you receive will be validated for the existence of a valid Customer Station and Account.
Client Agreement Maintenance
You can capture customer agreements relating to a product in the Customer Agreements screen. For the transactions processed under a specific product, involving a specific customer, you can specify the manner in which the value date of the accounting entries for the customer leg of the transaction should be arrived at; the cut-off time, whether consolidation is required or not and other such parameters which take precedence over the parameters defined at the product level.
While generating outgoing DD collections on behalf of your customers, you should maintain the Creditor’s DD agreements wherein the details pertaining to the debtor’s account, bank and agreement ID are captured.
Similarly, while receiving incoming DD’s on behalf of your customers you must ensure that you maintain DD agreements wherein the details pertaining to the creditor such as the creditor’s bank, account number and agreement ID are captured.
Account Statement Fields Definition
You can specify the fields that should be included in the account statements that you generate. You can do this in the Account Statement Fields screen. You can specify a maximum of fifteen fields for an account statement. You must also specify the sequence in which the fields must be displayed in the account statements. The fields are defined for a product type and product code combination.
User Defined Fields (UDF) and User Defined LOV Maintenance
You can define additional fields required for processing DD and RFD transactions through the User Defined Fields screen. You can also maintain a list of possible values for the User Defined Values.
Reject Code Maintenance
DD and RFD transactions may be rejected because of several reasons. You can associate the appropriate reject code with such transactions. Reject codes are maintained in the Reject Code screen.
Debtor Customer Category Maintenance
You can maintain debtor categories through the Debtor Customer Category screen. This will enable you to define preferences for a debtor category instead of defining for each debtor participating in DD and RFD transactions. The preferences for a category are maintained in the Product Debtor Category Preferences screen.
Charge Product Category Maintenance
Maintaining charge categories will allow you to collate statistics involved in payment and collection transactions. Using the data that is collated you will be able to define appropriate charges for processing transactions.
Charge Account Mapping
Typically, the processing charges are debited to the customer account involved in the transaction. However, through the Charge Account Mapping screen, you can specify a different account, for collecting such charges
This section contains the following topics:
You may process transactions, which involve transfer of funds between accounts maintained at your bank. You can define this type of local payment as a product in the P&C module. You can define products for each type of DD and RFD transactions mentioned earlier.
The advantages of defining a product
Let us consider the steps involved in processing an outgoing payment instruction (involving a foreign currency account) at your bank. Your specifications would include the following:
If you process a thousand such outgoing payments, you would need to repeat these operations as many times.
By defining outgoing payments involving an incoming or outgoing collection as a product in Oracle FLEXCUBE, and defining standard attributes for it, you can make the task of processing such payments easier.
You can define the following broad parameters for a product:
Once you have created a product, you can associate it with a ‘product category’. A product category helps in identifying the product that should be used to process a transaction that is received.
A product category can be of either of the following types:
Once you have maintained the basic details for a category, you can proceed to associate products that have been created at your bank, with the category. For a product category, you have to identify products for the following types of processing:
For internal and external clearing, you also have to specify the sequence in which the products should be taken up for product resolution. Depending on the sequence, the appropriate product will be associated when a transaction is initiated in the system.
An outgoing transfer includes information about the outgoing product category. When this transaction is received, Oracle FLEXCUBE resolves the product to be used for processing as follows:
Case One
Case Two
Case Three
Apart from specifying the different clearing products, you can specify certain preferences for a product category. The preferences you specify for a category determine the manner in which transactions are ultimately processed.
A payment transaction from an electronic banking system is handed off to the Incoming Message Queue of Oracle FLEXCUBE. The message is then translated into contract details by the interface function. The transaction details are then handed off to the P&C module. Uploaded transactions will ideally be one of following categories:
All uploaded contracts, along with the contract manually entered by the user from Online Screen, form part of the processing queue. Preliminary validations are done for checking the integrity of the contract data. Validations are made along the following parameters:
Based on the validations made, the contract is moved to appropriate queue for event processing/error handling. Processed contracts are authorized based on the authorization parameter maintained in the Upload Source.
Depending on the errors encountered during processing, the transactions will be handed off to the appropriate exception queue. The following exception queues are available to view the details of contracts with exceptions:
Processing Exception Queue
This queue displays the details of transactions for which an exception is raised during processing. The system can raise an exception during charge computation or advice generation.
Credit Exception Queue
Transactions that were rejected due to unavailability of funds will be displayed in this queue.
Consolidation Exception Queue
All transactions that were rejected due to errors in posting the consolidated entry will be displayed in this queue.