5. Processing a Payment or Collection Transaction

In the Payments and Collections module of Oracle FLEXCUBE, a product refers to a specific type of transfer of funds. For example, you may process payments/collections that involve transfer of funds between accounts maintained at your bank. You can define this type of internal payment /collection as one of the payment/collection products at your bank.

Defining a product makes it easier for you to enter transactions. The other advantage of defining a product is that you can define certain general attributes for a product, which will default to all contracts processed under it.

Note

Contracts are customer specific. A customer could make a payment through your bank (lo­cal payments) or collect payments from debtors through your bank (direct debits or re­quests for debit).

Every time you process a transaction, you do not have to specify its general attributes, since a transaction acquires the attributes defined for the product it involves. You can change these default attributes to suit a specific transaction.

You can capture the details of a Payment/Collection transaction in the PC Transaction Input online screen.

This chapter contains the following sections:

5.1 Payment/Collection Transactions Details

This section contains the following topics:

5.1.1 Entering a Transaction

You can invoke the ‘PC Transaction Input online’ screen from the Application Browser.

You can invoke this screen by typing ‘PCDTRONL’ in the field at the top right corner of the Application tool bar and click on the adjoining arrow button. To enter a transaction in this screen, select new icon from the toolbar.

In this screen, you must enter the following details:

Product Category

Enter a valid product category code. The transaction that you are capturing will be associated with the product category you specify. If you enter a valid code, the Transaction Input screen is displayed.

Batch Number and Batch Description

Specify the Batch Number and a description of the batch. (A batch is used to group transactions.).

When you confirm your input, the main ‘PC Transaction Input’ screen is displayed. In this screen, you will view the batch number to which your transaction will be posted, the current number, and the reference number of the transaction you are capturing..

The following details are displayed in the main screen of the contract:

Product Category

The category you specified on invoking this screen will default here. You cannot change the default.

Product Code

Specify the product that you wish to use to process the contract. Based on the product code, the system will default the currency code linked to this product in the ‘Txn CCY’ field. Alternately, the system can also arrive at the product code based on the currency specified in the ‘Txn CCY’ field.

Network

Specify the clearing network for the contract. Based on the network ID, the system will default the currency code linked to this network in the ‘Txn CCY’ field.

Collection Type

The Collection Type of the transaction will be displayed. This could be either DD or RFD.

RFD Type

If the incoming collection transaction is an RFD, specify the RFD type. This could be any one of the following:

Partial Payment: indicates that the RFD is processed for partial payment

Contract Reference

The system identifies every transaction with a unique reference number. You can view the reference number for the transaction that you are capturing.

Customer Reference

The custom reference number for the contract is displayed.

Product Type

It defines the product and the product category of collection, payment. In PC transaction input it will be defaulted from the Product Category.

Source Reference

The system identifies every transaction with a unique source reference number. You can view the reference number for the transaction that you are capturing.

Specify the following details in the main screen of the contract:

5.1.2 Main Tab

As mentioned earlier, the PC Transaction Input screen is used to enter the details of a local payment/collection transaction.

Apart from the standard fields that are available, you will view the user-defined fields that the administrator at your customer station has maintained. These fields will be displayed in the sequence that your administrator has specified when defining the product category.

Customer Details

Account Number

Click ‘A’ and select a valid customer account form the option list. The list displays all customer accounts maintained in Oracle FLEXCUBE, or a GL for which posting is allowed (for instance, a cash GL in case of remittance of cash handed over the counter) in this field. The option list displays customer accounts and internal GLs with the corresponding Clearing Account Number and the IBAN Account Number (for GLs, as maintained in the ‘Chart of Accounts’).

Note

You can also select the account number as the CL account number. If the account is CL account, then the system will initiate CL manual payment for the following product types:

The system will reverse the CL manual payments for Reject/Recall /Reversal of Outgoing Collection or Incoming Payment product types.

The IBAN of the loan account will be displayed in the ‘Counterparty IBAN’ field of the transaction.

To view the joint holder’s details of an account and the mode of operation maintained at the account level, place the cursor on the Account Number field and press Ctrl+J. The system displays the ‘Joint Holder’ screen.

For more information on the ‘Joint Holder’ screen refer to the section ‘Joint Holder Maintenance’ in the Core User Manual.

Account Description

The system displays the description of the specified account number based on the details maintained at ‘Customer Account Maintenance’ level.

Account Branch

This is maintained for the branch in customer account maintenance screen. The branch will be defaulted when you save the PC transaction.

Account Currency

This is maintained for the account in customer account maintenance screen. The values maintained will be defaulted when you save the PC transaction.

Available Balance

The available balance of the customer will be defaulted here when you save the PC transaction. The balance is maintained in the customer account maintenance screen.

Account in LCF

You can specify the customer account in Local Clearing Format in the A/C LCF field.

Customer Name

The name of the customer who is linked to the customer account will be defaulted here when you save the PC transaction. The name is maintained in the customer account maintenance screen.

Customer Number

The system defaults the customer number of the customer linked to the PC transaction.

Bank Code

You can enter the bank code and the account in LCF (local clearing format) for the transaction. The option list displays the Bank Code, Name, Bank Code Type and City for each bank in the list. The Bank Code, Name and City details are displayed on the Transaction Input screen when you select the bank code.

Bank Name

The system displays the name of the bank.

Bank Address 1

Specify the address of the customer’s bank name specified.

Bank Address 2

Specify the address of the customer’s bank name specified.

Note

Branch Name

The system displays the branch name of the bank.

Clearing Branch

The clearing branch for the specified customer bank code is displayed in this field.

Bank City

The system displays the bank city.

Additional Customer Details

Click on ‘Additional Customer Details’ to maintain the additional details of the customer.

Customer Address

You can specify the address of the customer involved in the contract. You can specify up to five lines of address information.

Customer Information

If you need to specify other information regarding the customer of the transaction, free format 35-character text fields are provided, with appropriate labels applicable for your installation. You can specify the customer information such as Surname, Email, ID No, Telephone and Customer Reference in these fields.

Communication Mode

Indicate the mode of the communication to the customer to intimate about the beneficiary account credit. You can select one of the following options:

The above field is enabled only for the product that uses the NEFT clearing network, i.e., Network Qualifier of the Clearing network should be NEFT.

Customer Reference

Specify the customer reference number.

Mobile Number/Email ID

Specify the mobile number or Email ID of customer.

Customer BIC ID

Specify the Bank Identification Code for the Customer.

Customer Scheme Name Type

Select the Identification Scheme Type of the Customer from the drop-down list and the available options are:

Customer Scheme Name

Specify the value for Identification Scheme Name field.

If Scheme Name type is C then the Scheme Name can be selected from LOV and can have one of the values mentioned in value list depending on Organization Identification or Private Identification.

If the Scheme Name Type is P then you can enter the value for the field.

Customer Identification details

You need to specify customer identification details of the customer of the transaction, free format 35-character text fields are provided, with appropriate labels applicable for your installation.

You can specify the following details:

Counter party Details

The Bank Code, Name and City details are displayed on the Transaction Input screen when you select the bank code.

Account Number

You can specify the account of the counterparty here. In case of internal transfers, the account needs to be a valid account of Oracle FLEXCUBE either in Oracle FLEXCUBE or in the Local Clearing Format. You can also select an account number from the option list provided. In such a case, the system will default the counterparty name and the address lines as maintained for that account. If at the time of selection of counterparty account, Bank Code is null, then Bank Code and Name will also get defaulted.

Counter party Name

Specify the nameof the customer (counter party).

You can click ‘Learning Database’ button to invoke the learning database to specify the counter party details. All counter parties involved with the specific customer of the contract, are displayed in the learning database.

You can select the Counter party Bank Code, Counter party Account Number and Name of the required counter party.

Bank code

Select a valid bank code maintained in Oracle FLEXCUBE. If you select a code from the option list, the bank name is displayed instantly. If you choose to enter the code, the name of the bank is displayed when you save the transaction.

Validations for counterparty details for bank transfers:

Bank Name

Specify the counterparty bank name.

Bank Address 1

Specify the address of the counterparty bank.

Bank Address 2

Specify the address of the counterparty bank.

Virtual Account

Specify the virtual account number in this field. Based on the virtual account code and transaction currency, the system derives the linked physical account. If no physical account is mapped, then the default physical account linked to the virtual account is derived.

If you change the defaulted physical account and if is not linked to the virtual account then system will replace the derived physical account providing an override for the same.

Virtual Account will not be allowed for Outgoing Payments (as it is applicable only for Credit transactions) and Collections.

Virtual Account Name

The account name of the virtual account number is displayed in this field.

Additional Counterparty Details

Click on ‘Additional Counterparty Details’ to maintain additional details on the counterparty.

Counterparty Information

If you need to specify other information regarding the counterparty of the transaction, free format 35-character text fields are provided, with appropriate labels applicable for your installation.

You can specify the counterparty information in these fields:

Surname

Specify the surname of the counterparty.

Father Name

Specify the father’s name of the counterparty.

Telephone

Specify the contact number of the counterparty.

Email ID

Specify the email Id of the counerparty.

Facebook ID

Specify the facebook Id of the counterparty.

Remarks

Specify remarks, if any.

Counterparty Address

You can specify the address of the counterparty involved in the contract. You can specify up to five lines of address information.

Counterparty BIC ID

Specify the Bank Identification Code for the Counterparty.

Counterparty Scheme Name Type

Select the Identification Scheme Type of the Counterparty from the drop down list.

The valid field can be:

Counterparty Scheme Name

Specify the value for Identification Scheme Name field.

If Scheme Name type is C then the Scheme Name can be selected from LOV and can have one of the values mentioned in value list depending on Organization Identification or Private Identification.

If the Scheme Name Type is P then you can enter the value for the field.

Counterparty Date of Birth

Specify the date of birth of the Counterparty.

Counterparty Identification details

You need to specify other information regarding the counterparty of the transaction, free format 35-character text fields are provided, with appropriate labels applicable for your installation.

You can specify the following details:

Counterparty Bank

Direct Participant

This is the Direct Participant for the Counterparty BIC and is derived from the Clearing Network information maintained in the ‘PC Bank Directory’ screen. Only if the counterparty is an indirect participant of the network, the system displays the direct participant of the corresponding counterparty BIC. In case of counterparty being direct participant, the field is null.

Transaction Details

Book Date

The system displays the book date of the transaction.

Activation Date

This is the activation date of the contract. The system defaults to the current date. However, you can change this. Since you can post back-value dated PC transactions, for the purpose of risk tracking you can indicate a date beyond which users will be prevented from posting a back value dated transaction by enabling the Back-Value Check Required in the ‘Branch Preference’ screen. The System validates whether the activation date falls within the maximum period up to which back valued posting can be processed.

Transaction Currency

Enter the currency for the transaction. You can click on the adjoining option list to choose from a list of valid currency codes maintained in the system. Input to this field is mandatory. If the network ID is input, then the system will be display the currency linked to the clearing network in this field. If the product code is input, then the system will display the currency linked to the product in this field. You will not be able to change the defaulted value. The system will ensure that this currency code is the same as that linked to the product code and network ID of the contract.

Amount

This refers to the transaction amount, i.e. the actual amount transferred during the transaction. For example, if the you have maintained the Charge Mode’ as ‘Discount’ at the Product Preference level, then the actual amount sent to the beneficiary will be the difference between transaction amount and charge.

On saving the transaction after entering all the required details in the system, the system validates the value of the transaction amount against the following:

If the transaction currency and the limit currency are different, then the system converts the amount financed to limit currency and checks if the same is in excess of the product transaction limit and user input limit. If this holds true, the system indicates the same with below override/error messages:

Transaction amount is in excess of the input limit of the user

Foreign Currency Amount

The system displays the foreign currency which is involved in the PC transaction.

Remitted Amount

The system displays the remitted amount that is involved in the PC transaction.

LCY Equivalent

The system displays the transaction amount in the local currency.

Total Charge Amount

This field displays the total charge amount in local currency which is the sum of all the charge amount computed or specified for all five charge sets.

Collection Status

The status of the transaction is displayed at the bottom of the screen.

The following details are displayed.

Exchange Rate

The exchange rate of the transaction will be displayed in case the customer account is in a foreign currency (only for payment transactions).

Exception Queue

The name of the queue to which the transaction is logged in case of any processing exception is displayed here

Message Status

If the outgoing payments workflow is applicable for the transaction, the status of the message is displayed here.

Batch Number

The batch number, to which the transaction will be posted, is displayed here.

Batch Description

The description associated with the batch is displayed here.

FX Contract Reference

Specify the FX Contract Reference number you need to link to the PC contract, for the currency pair. The adjoining option list displays Forward Deal Type FX contracts which are authorized and active. Select the appropriate one.

The system disables Rate Date and Rate Serial, if the FX Contract Reference number is specified.

While entering a payment contract, the system facilitates you to choose a FX forward contract. This FX forward contract must meet the following requirements:

If any of the above criteria is not met then the system displays an appropriate error message.

The following validations and processes are involved:

Customer Consolidation at Product Level

Specify the preference for consolidating customer at product level, by selecting an appropriate option from the drop-down list. The options available in the drop-down list are:

Customer Consolidation Across Products

Check this box to consolidate the transactions of a customer across the products.

Customer Consolidation Reference

The system displays the customer consolidation reference number. If ‘Customer Consolidation at Product Level’ or 'Customer Consolidation Across Products' is checked, then a unique customer consolidation reference number is captured for all those transactions booked Manually. If 'Customer Consolidation Across Products' is checked then system populates the customer consolidation reference number with Payment Information ID generated at the Common Payment Gateway for all those transactions consolidated for a customer across different products.

Account Entry Reference

The system displays the account entry reference.

Service Level Code

Priority, which is a user defined field, set at the product category level is defaulted in this screen.

5.1.3 Transaction Details Tab

Click on the ‘Transaction Details’ tab to capture transaction details.

 

Processing Value Date

Customer Entry Date

This indicates the date on which the customer account will be debited for outgoing transfers and credited for incoming transfers. If you do not input a date here, it will be derived from the activation date by adding the working days to the value of customer entry days specified for the product. The values will be used based on the cutoff status of the transaction.

Customer Entry Value Date

This indicates the value date of the debit entry for outgoing transfers and credit entry for incoming transfers. If you do not input a date, it will be derived from the activation date by adding the working days to the value of customer entry value days specified for the product. The values will be used based on the cutoff status of the transaction.

Counterparty Entry Date

This indicates the date on which the counterparty account will be credited for outgoing transfers and debited for incoming transfers. If you do not input a date, it will be derived from the activation date by adding the working days to the value of counterparty entry days specified for the product. The pre/post cutoff values will be used based on the cutoff status of the transaction.

Counterparty Entry Value Date

This indicates the value date of the credit entry for outgoing transfers and debit entry for incoming transfers. If you do not input a date, it will be derived from the activation date by adding the working days to the value of counterparty entry value days specified for the product. The pre/post cutoff values will be used based on the cutoff status of the transaction.

Instruction Date

This indicates the requested execution date of the SCT transaction and Collection due date of an SDD transaction. This is a display only field.

Settlement Date

Specify the inter bank settlement date of the incoming instruction.

Initiation Date

The date and time when the transaction was received through the Electronic Banking System is displayed.

Receive Date of Incoming

The system displays the incoming receive date.

Purpose Details

Category Purpose

Specify the category purpose of the credit transfer from the option list.

Purpose Type

Select the purpose type of the credit transfer from the drop-down list. Following are the options available in the drop-down list:

Purpose Value

Specify the purpose value of the credit transfer.

Local Instrument Type

Select the local instrument type from the drop-down list. Following are the options available in the drop-down list:

The value for the field is defaulted as 'CODE'. The field is enabled if the 'product type 'is 'Outgoing Collection'.

Note

Local Instrument Value

The value for the field is defaulted from the 'collection scheme type 'field, maintained at product level. You can modify this value. The field is enabled if the 'product type 'is 'Outgoing Collection'.

Electronic Signature

Specify the electronic signature of the debtor.

Charge Details

Charge Bearer

This indicates which party will bear the charges associated with the payment. This value is received from the incoming SEPA instruction and you are not allowed to change this. For manually input transaction this will be defaulted from the Product Maintenance.

Charge Mode

You can indicate whether charges applicable for the transaction are to be applied over and above the transaction amount (premium) or subtracted from the transaction amount (discount).

Waive Charge

This field defaults the value of charge waiver from the product preference maintenance. Also, the option in this field can be changed and the selected option is reflected across the individual charge waivers for all charge sets.

Third Party Charge Currency

Select the third party charge currency from the adjoining option list.

Third Party Charge Amount

Specify the third party charge amount.

Payment Details (Unstructured)

Remitter Reference

Specify the remitter reference number.

Remitter Code

Specify the remitter code.

Remitter Information Issuer

Specify the issuer of the remitter information.

Additional Remittance Info

Specify additional remittance information, if any.

Structured Invoicee Details

Identification Type

Select the identification type from the adjoining drop-down list. The options available are:

BIC

Specify the bank identifier code.

Name

Specify the name of the invoicee.

Address 1 and 2

Specify the address of the invoicee.

Country

Specify the country of the invoicee.

Structured Invoicer Details

Identification Type

Select the identification type from the adjoining drop-down list. The options available are:

BIC

Specify the bank identifier code.

Name

Specify the name of the invoicer.

Address 1 and 2

Specify the address of the invoicer.

Country

Specify the country of the invoicer.

Payment Details (Structured)

Payment Details 1, 2, 3 and 4

Specify the payment details.

Sender Receiver Information

Sender Receiver Details

Specify the sender receiver details.

Sender Receiver 1, 2, 3 and 4

Specify the sender receiver information.

P2P Payments

Customer Debit Reference Number

The system displays the customer debit reference number.

Note

If the P2P payment type is ‘Customer Debit’, then the customer debit reference number will be same as the contract reference number.

If the P2P payment type is ‘Test Transaction’ or P2P Final Payment, then the customer debit reference number will be customer debit reference.

Amount Block Reference Number

The system displays the amount block reference number.

Test Transaction Reference Number

The system displays the test transaction reference number.

Note

If the P2P payment type is ‘Customer Debit’, then the test transaction reference number will be null.

If the P2P payment type is ‘Test Transaction’, then the test transaction reference number will be same as the contract reference number.

If the P2P payment type is ‘P2P Final Payment’, then the test transaction reference num­ber will be reference number of the test transaction involved in P2P payment.

P2P Payment Type

The system displays the value maintained for ‘P2P Payment Type’ maintained for the product in the transaction.

Processing P2P Final Payment

During the P2P final payment transaction, an outgoing payment is created for P2P Final Payment Transaction. When the customer debit transaction is processed, the customer ledger in the debit liquidation is replaced with the suspense GL of the bank for debiting the transaction amount. The debit GL used for debit liquidation is maintained at contract level. This GL is used during the reject of P2P final payment transaction processing to credit the transaction amount in credit liquidation. When an ‘Amount Block’ request is processed, the amount block on senders’s account is released. Hence for the final payment the transaction amount will be debited from sender’s account and will be credited to the clearing suspense GL.

Processing P2P Customer Debit Payment

During customer debit transaction, an outgoing payment of type ‘Book Transfer’ is created. You have to specify the email ID, telephone number or facebook details for the transactions with P2P payment type as ‘Customer Type’. For the customer type other than ‘Customer Debit’, it is mandatory to specify the counterparty bank code and counterparty account umber details. During the customer debit transaction processing, following transaction data would be logged into 'P2P Payment Beneficiary Registration Queue' to track the beneficiary registration till the end date:

The end date for the beneficiary registration is derived based on the 'Registration Period in Days' parameter value from P2P payments parameters level. The derived end date will also be logged into 'P2P Payment Beneficiary Registration Queue'. Credit GL used for the credit liquidation will be maintained at contract level. This GL is used during the Reject of customer debit transaction processing for debiting the transaction amount in debit liquidation.

Processing Amount Block

The system creates an amount block on the sender's account for the transaction amount on receipt of amount block request from the external system. A failure response message is sent to the external system in case of any error during amount block processing.

During the amount block processing, following transaction data would be logged into 'P2P Payment Beneficiary Registration Queue' to track the beneficiary registration till the end date.

The end date for the beneficiary registration would be derived based on the 'Registration Period in Days' parameter value from P2P payments parameters level.The derived end date is logged into 'P2P Payment Beneficiary Registration Queue' and will be updated as expiry date in Amount Block Input function.

Exception Details

Reject Code

The reject code, if any, that was specified for rejection of the transaction, is displayed here.

Reject Detail

The reject reason, if any, corresponding to the reject code is displayed here.

Reject Code Additional

This is the reject reason for the reject messages. This will be used in case the reject reason is not covered by available ISO reject codes.

Compensation Amount

Specify the amount that the debtor bank has to receive from the creditor bank.

It should always be Euro (EUR)

Their Reference

This is the reference number of the counterparty bank for collections (for instance, incoming collections). This is the reference that would be sent back when any responses are sent back to the counterparty bank.

Original Collection Reference

If you are rejecting or recalling a collection transaction, you must specify the reference number of the original collection transaction.

CSM Reject Reference No

The system displays the CSM reject reference number.

CSM Reject Code

The system displays the ISO reject code for the rejection from Clearing Settlement Mechanism.

CSM Reject Detail

The system display the CSM Reject Detail to describe the ISO reject code for the rejection from CSM.

Reject Originator Name

The system displays the reject originator name.

Reject Originator Bank

The system displays the reject originator bank.

Reject Reference Number

The system displays the reject reference number.

Payment Reject Date

Specify the payment reject date from the adjoining calendar.

Other Details

Cutoff Status

This indicates if the transaction was received before the cutoff time defined for the product.

Cover required

The system displays the cover message preference you have maintained for the counterparty as part of the Clearing Network maintenance. The system defaults the values in Direct Participant and Cover field only if you have maintained the information for the contract. In case you have maintained the counter party bank code without a clearing network, the system defaults the values for both the above fields only after you save the contract.

Generate Advice

You can indicate whether a customer advice needs to be generated for the contract. If you do not specify this, after product resolution, the transaction acquires the specification defined for the product.

Generate Remit Slip

Check this box to generate remit slip.

Bank Redirect

Check this box to indicate whether the transaction must be redirected from the customer or counterparty bank to any other bank.

Auto Response

Indicate if a system generated response is required for the collection transaction.

Account Redirected

Check this box to redirect the transaction from customer or counterparty account to any other account.

Auth Reject Remarks

The system displays the authorization reject remarks.

Payment Reference

Station ID

The system displays the station identification

Clearing System ID

Specify the clearing system identification.

Priority

The system displays the priority order of the messages.

Source Code

The system displays the source code.

Event Details

Last Event Code

The system displays the last event code.

Next Event Code

The system displays the next event code.

Next Event Date

The system displays the next event date.

Payment Split Details

You can maintain the following payment split details here:

Split Number

Specify a valid number for the payment split.

Split Transaction Reference

Specify a valid transaction number for payment split.

Split Indicator

Select a valid indicator for the payment split from the adjoining drop-down list. The list displays the following values:

Invoice Split Required

Check this box if you need to invoice the split required.

 

5.1.4 Collection Details Tab

General Collection Details

Creditor Identification

For an Incoming Collection transaction or its reject / recall, mention the Creditor ID

Agreement Identification

For Collection transactions, enter the Creditor or Debtor Agreement ID as applicable.

Debtor Category

Select the debtor category from the adjoining option list.

Mandate/ Agreement Details

Sequence Type

Select the sequence type of the DD transaction as first collection or One-off. The following options are available:

Sign Date

This indicates the date on which the mandate was signed by the debtor. This would be defaulted based on the mandate ID selected. This is a display only field.

Amend Indicator

Select the option to indicate if the mandate has been amended or not. The values available in the drop down are ‘Yes’ and ‘No’. The value that you select here is populated in the outgoing message for an outgoing collection transaction.

Amend Type

Specify the type of mandate amend that has been done. This is applicable only if ‘Mandate Amend Ind’ is selected as ‘Yes’. This value is populated in the outgoing message of the outgoing collection transaction

Original Mandate ID

Specify the original mandate ID if the mandate is amended. This is applicable only if amend indicator is selected as ‘Yes’.

Orginal Debtor Account

Specify the original Debtor Account under the scheme if the mandate is amended. This is applicable only if amend indicator is selected as ‘Yes’ scheme if the mandate is amended. This is applicable only if amend indicator is selected as ‘Yes’.

Original Debtor Bank

Specify the original Debtor bank BIC under the scheme if the mandate is amended. This is applicable only if amend indicator is selected as ‘Yes’.

Creditor Scheme Details

Scheme Identification

Select the scheme identification code of the creditor from the drop-down list. Following are the options available in the drop-down list:

Scheme Identification Type

Specify the scheme identification type of the creditor from the option list.

Scheme Identification Value

Specify the scheme identification value of the creditor.

Scheme Type

Specify the scheme type of the creditor.

Original Creditor Scheme Details

Identification

Select the scheme identification code of the original creditor from the drop-down list. Following are the options available in the drop-down list:

Creditor Name

Specify the name of the original creditor.

Identification Value

Specify the scheme identification value of the original creditor.

Scheme Type

Specify the scheme type of the original creditor.

Other Details

Collected Amount

Specify the collected amount.

Related Transaction

The system displays the related transaction.

Response Date

Specify the date beyond which an incoming collection transaction cannot be rejected. If you do not specify this, the date is picked up from the customer agreement.

Response Advice Required

Indicate whether response advice needs to be sent for this collection transaction. By default, the system picks up this specification from the customer agreement

Response Advice Basis

Specify the response advice basis from the adjoining drop-down list. the options are:

5.1.5 Party Details Tab

Indirect Participant Customer Details

Indirect Participant Customer Name

Specify the name of the customer participating in the indirect transaction.

Indirect participant Customer Address1 and 2

Specify the address of the customer participating in the indirect transaction.

Indirect participant Country

Specify the country of the customer participating in the indirect transaction.

Indirect Participant BIC ID

Specify the Bank Identification Code for the Indirect Participant.

BIC ID is only applicable for Organizational identification details.

Indirect Participant Scheme Name Type

Select the Identification Scheme Type of the Indirect Participant from the drop down list.

The valid values are:

Indirect Participant Scheme Name

If Scheme Name type is C then select the Scheme Name from the values mentioned in the LOV depending on Organization Identification or Private Identification.

If Scheme Name type is P then enter the Scheme Name your own.

Indirect Participant Date of Birth

Specify the Date Of Birth of the Indirect Participant. Input the Date of Birth is only for Private identification.

Identification Value

Specify the identification value. This is optional.

Issuer

Specify the Identification Issuer of the customer. This is an optional field. This is applicable for Organization identification as Proprietary Identification or Private Identification.

City of Birth

Specify the city of birth of the Customer. This will be enabled and is mandatory for identification type as Date and place of birth.

Country of Birth

Select the country of birth of the Customer. Country - Specify the address country code of the customer from the option list. This is optional.

Account Number

Specify the account number of the customer participating in the indirect transaction.

Currency

Specify the currency that is used in an indirect transaction

Bank Code

Specify the Bank code of the bank that has participated in a transaction.

Initiating Party Details

Name

Specify the name of the initiating party. This is an optional field.

Address Line 1

Specify the address line1 of the initiating party. This is an optional field.

Address Line 2

Specify the address line 2 of the initiating party. This is an optional field.

Country

Select the country of the initiating party from the option list. This is a mandatory field if the address details are specified.

Issuer

Specify the Identification Issuer of the initiating party. This is an optional field. This is applicable for Organization identification as Proprietary Identification or Private Identification.

City of Birth

Specify the city of birth of the Initiating party.

Initiating Party Identification

Select the unique way of identifying the initiating party from the drop-down list. The following are the options available:

Country of Birth

Select the country of birth of the Initiating Party from the option list.

Initiating Party BIC ID

Specify the Bank Identification Code of the Initiating Party.

Initiating Party Scheme Name Type

Specify the Identification Scheme Type of the Initiating party and available options are:

Initiating Party Scheme Name

If Scheme Name type is C then select the Scheme Name from the values mentioned in the LOV depending on Organization Identification or Private Identification.

If Scheme Name type is P then enter the Scheme Name your own which can contain free format text and should of length 35.

Initiating Party Date of Birth

Specify the Date Of Birth of the Initiating party.

Identification Value

Specify the identification value. This is optional.

Ultimate Debtor Details

Customer Name

Specify the name of the ultimate debtor.

ID

Select the identification code of the ultimate debtor from the drop-down list. Following are the options available in the drop-down list:

ID Value

Specify the identification value of the ultimate debtor.

Issuer

Specify the other identification type issuer of ultimate debtor.

City of Birth

Specify the city of birth of ultimate debtor.

Country of Birth

Specify the country of birth of ultimate debtor.

Ultimate Debtor BIC ID

Specify the Bank Identification Code for the Ultimate Debitor.

BIC ID is only applicable for Organizational identification details.

Ultimate Debtor Scheme Name Type

Specify the Identification Scheme Type of the Ultimate Creditor and the available options are:

Ultimate Debtor Scheme Name

If Scheme Name type is C then select the Scheme Name from the values mentioned in the LOV depending on Organization Identification or Private Identification.

If Scheme Name type is P then enter the Scheme Name your own which can contain free format text and should of length 35.

Ultimate Debtor Date of Birth

Specify the Date Of Birth of the Ultimate Creditor.

Input the Date of Birth is only for Private identification.

Ultimate Creditor Details

Name

Specify the name of the ultimate creditor.

ID

Select the identification code of the ultimate creditor from the drop-down list. Following are the options available in the drop-down list:

ID Value

Specify the identification value of the ultimate creditor.

Issuer

Specify the other identification type issuer of ultimate creditor.

City of Birth

Specify the city of birth of ultimate creditor.

Country of Birth

Specify the country of birth of ultimate creditor.

Ultimate Creditor Name

Specify the Name of the Beneficiary Reference Party.

The field can contain any free format text of length 70.

Ultimate Creditor BIC ID

Specify the Bank Identification Code for the Ultimate Creditor.

BIC ID is only applicable for Organizational identification details.

Ultimate Creditor Scheme Name Type

Specify the Identification Scheme Type of the Ultimate Creditor.

The valid values are:

Ultimate Creditor Scheme Name

If Scheme Name type is C then select the Scheme Name from the values mentioned in the LOV depending on Organization Identification or Private Identification.

If Scheme Name type is P then enter the Scheme Name your own which can contain free format text and should of length 35.

Ultimate Creditor Date of Birth

Specify the Date Of Birth of the Ultimate Creditor. Input the Date of Birth is only for Private identification.

5.1.6 Message Details Tab

You can capture the following details here:

Dispatch Details

Dispatch

This indicates whether the contract needs to be dispatched to clearing. In case of incoming transactions, dispatch is not allowed. If you do not specify this, after product resolution, the transaction acquires the specification defined for the product.

Redispatch Required

Indicate if this outgoing collection transaction needs to be redispatched if rejected.

Dispatch Date

This is the date on which the transaction will be sent for dispatch. If you do not enter a date, it will be derived from the activation date by adding the working days to the value of dispatch days specified for the product. The pre/post cutoff values will be used based on the cutoff status of the transaction.

Recall Message Details

Message Creation Date

The system displays the message creation date.

Recall Message Reference

The system displays the recall message reference number.

Recall Message Name

The system displays the recall message name.

Recall File Reference Number

The system displays the recall file reference number.

Status

The system displays the status of the recall request.

Note

If the network is SEPA then for Local Instrument Type 'CODE', the Local Instrument Value should be CORE (COR) or B2B for outgoing collection. If Local Instrument Value is not entered as COR/B2B for outgoing collection contract, then system displays an error message as Invalid Local Instrument Value, value should be either CORE/B2B'.

When the system generates Camt.056 message, then the system displays the recall details in the Message Details tab. The system changes the recall message status to Rejected if the Camt.056 message is either rejected by SEPA or Camt.029 message is received. On receipt of Pac.004, system reverses the original contract. The system does not change the recall message status to any other status as it remains 'Sent'.

Incoming Message Details

Specify the following incoming message details:

File Reference

Specify the reference number of the file that is used in the incoming message processing.

Message ID

Specify the mode to identify a message.

Message Name

Specify the name of the message that is been referred in the incoming messages.

Message Creation Date

Specify the date on which a message was created.

Instructing Bank

Specify code of the instructing bank from which the message was instructed.

Instructed Bank

Specify code of the instructed bank to which the message was instructed.

Settlement Method

Specify the settlement mode.

Outgoing Message Details

You can maintain the following outgoing message details:

Outgoing File Reference No

This indicates the file reference number of the incoming message. This is a display only field.

Outgoing Message ID

This is a unique message bulk reference number populated from the incoming instruction. This is a display only field.

Outgoing Message Name

This indicates the message name identifier of the outgoing message. For e.g. Pain.001.001.01.

Message Creation Date

This indicates the date and time the transaction was created. This is a display only field and is defaulted with the value in the incoming message.

Original Message Details

Name

This indicates the message name of the original instruction for which a new instruction is received. This is a display only field.

Reference Number

This indicates the message identification of the original instruction for which a new instruction is received. This is a display only field.

Amount

The system displays the new instructions received for the original amount.

Original Settlement Currency

This indicates the settlement amount and currency of the original instruction. This is a display only field.

Source Reference

This indicates the source reference number of the original instruction for which reject/refund is received. This is a display only field.

Settlement Date

This indicates the settlement date of the original instruction. This is a display only field.

Original Payment Info ID

Specify the unique identification, as assigned by the original sending party, to unambiguously identify the payment information group. This field maps to field Payment Info ID of Common Payment Gateway.

Redispatch Details

Redispatch Number

Specify the redispatch count for the parent transaction which is being redispatched.

Redispatch Reference

For collection transactions, specify the reference number of the parent transaction that is being redispatched.

Redispatch Indicator

This indicates whether the collection transaction has been redispatched. If it has not been redispatched, this field indicates 'Not Applicable'. If the transaction has been redispatched, this field indicates whether the transaction being viewed is a parent transaction or a child transaction.

Auto Redispatch

Indicate if this outgoing collection transaction needs to be redispatched automatically if rejected.

Redispatch Date

Specify the date of redispatch of the parent transaction

5.1.7 UDF Tab

In the ‘PC Transaction Input’ main screen, based on the preferences assigned to the product category of the transaction, the contract User Defined Fields are displayed in the UDF tab in the screen, and you can specify the values for these fields, which are applicable for the contract.

You can execute queries on the user-defined fields, and select specific records based on the user-defined fields.

You can maintain the following details:

Field Name and Description

System displays the name and description of the UDF.

5.1.8 Split Details Button

Click the ‘Split Details’ button to specify multiple debit / credit accounts for the transaction so that the ‘Split Details’ screen can be viewed.

Only leaf GL transactions involving local currency can be entered in the Split Details screen. You can specify the MIS code for each split leg using the ‘MIS’ button against each split entry.

The sum of the amounts specified in the ‘Split Details’ screen is defaulted to the main transaction input screen. The first GL account specified in the ‘Split Details’ screen is defaulted as the customer account in the main ‘PC Transaction Input’ screen, and is also used in the corresponding payment message.

Specifying Contract Split Details

Serial Number

The system displays the serial number of the contract.

Branch

The system displays the branch where a contract is present.

Account Number

The system displays the account number of the contract

Currency

The system displays the currency that is used in a transaction.

Amount

The system displays the amount here.

MIS

The system displays the MIS details of the contract

Total Amount

The sum of the split amount is displayed in this field. This amount is displayed in the main screen as the actual amount.

The following details need to be specified in the respective tabs of the Transaction Input Screen:

File Ref No

Message Identification

Message Name

Msg Creation Date

Instructing Bank

Instructed Bank

Settlement Method

Note

While you are processing a transaction you have the option of retrieving details based on Product Category, Counterparty bank and Account combination by clicking the History but­ton.

Reactivate Event Processed

This is a display field that indicates that the contract is re-activated on rejection of rejection process.

5.1.9 MIS Details Button

The MIS details for the contract can be captured through the MIS screen. Click the ‘MIS’ button from the PC Transaction Input screen to invoke the ‘Transaction MIS Details’ screen. If you do not specify MIS details for a transaction, it acquires the MIS specifications made for the product under which it is processed.

5.1.10 Event Details Button

All events, overrides, and accounting entries triggered by the user who processes the transaction during its life cycle are logged in the ‘PC Contract View Events’ screen, which you can invoke by clicking ‘Events’ button in the ‘PC Transaction Input’ screen.

The following details are displayed:

Note

When Duplicate Advice Tracker field is checked and you click the EXIT button on the ad­vice generation screen, the system displays a message “Print Successful?”. Click OK but­ton to confirm the successful printing. Every subsequent print of the advices will be considered as duplicate advice. For more information on Duplicate Advice Tracker refer to section “Messaging Branch Parameters Maintenance” in the Core User Manual.

5.1.11 Duplication Details Button

The system checks for duplicate transactions while booking contracts based on the number of days for duplicate check maintained at the ‘Branch Parameters Maintenance’ screen and the duplication preferences set at the product category level. The system displays the duplicate contract reference number if there is a single match else it displays the following override message;

‘Duplicate Contracts recognized based on the product category preference’

You can view all the duplicate contracts in the ‘Duplication Details’ screen. Click ‘Duplication Details’ button in the ‘PC Transaction Input’ screen to invoke this screen.

Here you can view the following details:

Note

Duplication check is done based on the following criteria:

5.1.12 Project Details Button

Click the ‘Project Details’ button in the ‘Payments & Collections Transaction Input’ screen and invoke the ‘Project Details’ screen. You will have to capture project details in this screen only if the credit account is a Trust account.

Specify the following details:

Project Name

Specify the developer project name for which payment is being made. The adjoining option list displays all valid projects maintained in the system. You can select the appropriate one. Input to this field is mandatory.

If you specify the Unit ID, the system will display the corresponding project name here.

Unit Payment

Indicate whether the transaction is a unit payment or not by choosing the appropriate value from the adjoining drop-down list. The following values are available:

Unit ID

Specify the unit ID of the project. This field will be enabled only if you have selected ‘Yes’ against ‘Unit Payment’. The adjoining option list displays all unit IDs along with the unit holder names corresponding to the project name chosen. You can select the appropriate one.

Deposit Slip Number

Specify the deposit slip number for the payment.

5.1.13 Tax Button

You can view a tax scheme defined in the tax. Click ‘Tax’ button in the ‘Payments and Collection Transaction Input’ screen to invoke the ‘Tax’ screen.

You can compute the tax based upon the tax rule and linked amount from PC contract and liquidate the tax in the appropriate event.

You can specify the following details:

Contract Reference

The system displays the contract reference number.

Tax Scheme

The system displays the tax scheme details.

Waiver

Check this box to indicate waiver details.

Rule Details

Rule

The system displays the rule details.

Basis Component

The system displays the basis component details.

Event

The system displays the event details.

Waiver

Check this box to indicate waiver details.

Amount Details

Value Date

The system displays the value date.

Transaction Date

The system displays the transaction date.

Currency

The system displays the currency details.

Amount

The system displays the amount details.

Event Sequence Number

The system displays the ESN details.

While saving a PC contract, for outgoing PC payment, the beneficiary bank will be the beneficiary customer. If there is no classification for the beneficiary bank, then the system will treat the contract as a normal PC contract with no applicability of FATCA. This is applicable in case of external clearing contracts also.

For an incoming PC payment, the customer who owns the account being credited will be the beneficiary customer.

If an incoming collection results in an independent outgoing payment, the system will consider FATCA applicability as part of the outgoing payment and not as part of the incoming collection. If an incoming collection results in a direct debit, then the beneficiary customer will be the bank to which the payment is being sent.

If the contract is being closed, then the system will remove the contract row from the tracking table and the customer’s FATCA balance will be updated accordingly if required.

5.1.14 Queue Log Button

Audit logs will be logged when a PC transaction is entered into the queue due to exception and an action is triggered on it. Audit logs will be triggered for the following actions on queue.

The Audit logs are captured whenever a PC transaction moves into the following queues:

You can view the audit log information using the ‘Queue Log’ screen. Click ‘Queue Log’ button on the ‘Payments and Collection Transaction Input’ screen to invoke the ‘Queue Log’ screen.

You can view the following details:

User ID

The system displays the User ID.

Action

The system displays the action taken on the queue.

Date Time

The system displays the date and time when the action was taken.

Function ID

The system displays the function ID.

Queue Name

The system displays the name of the queue on which action was taken.

5.1.15 Viewing Payments and Collection Transactions

You can view the Payments and Collection Transactions using ‘Payments and Collection Transactions Summary’ screen. To invoke this screen, type ‘PCSTRONL’ in the field at the top right corner of the Application tool bar and click the adjoining arrow button:

You can click ‘Search’ button to view all the pending functions. However, you can to filter your search based on any of the following criteria:

Click ‘Search’, the system displays the following details based on the specified search criteria:

5.2 Simplified Entry of Payments and Collection Transac­tions

This section contains the following topics:

5.2.1 Invoking PC Fast Transaction Input Screen

For entry of transactions using the following product types, a simplified transaction entry screen, the ‘PC Fast Transaction Input’ screen, is provided to enable you to key in transactions with the basic transaction details.

You can invoke the ‘PC Fast Transaction Input’ screen from the Application Browser by typing ‘PCDFSTNL’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Transaction Branch

Select the appropriate branch from the list of branches available in the option list.

On clicking ‘O’ button, the system validates the access rights of the selected branch and function for the user.

If you don’t have appropriate rights on the selected branch and function, the system will display an error message. If you select a valid branch, the system updates the same as transaction branch and the transaction will be posted for this branch.

In the ‘Fast Transaction Input’ screen, you enter details for a transaction as given below. All validations to values entered in fields are made just as they are in the ‘PC Transaction Input’ screen:

Refer PC Transaction Input screen details in the same manual.

Basic Details

5.2.1.1 Specifying Clearing Network Restriction

Bank Code lists linked to the available clearing networks are displayed in ‘PC Fast Input’ screen for the Product Category. The displayed bank codes list sequence is driven by the way you navigate through the ‘PC Fast Input’ screen:

After entering the product category details, if you proceed to the bank code without entering the product code and network, the functionality will remain as before. (The entire list of bank codes used by that product is displayed)

If you enter the product code after entering the product category details, then

Transaction Details

Customer Details

To view the joint holder’s details of an account and the mode of operation maintained at the account level, place the cursor on the Customer Account No field and press Ctrl+J. The system displays the ‘Joint Holder’ screen.

For more information on the ‘Joint Holder’ screen refer to the section ‘Joint Holder Maintenance’ in the Core User Manual.

Saving a transaction in the PC Fast Transaction Input screen

When a transaction is saved in the ‘PC Fast Transaction Input’ screen, any overrides or errors in respect of the transaction are displayed. On saving the transaction after entering all the required details in the system, the system validates the value of the transaction amount against the following:

If the transaction currency and the limit currency are different, then the system converts the amount financed to limit currency and checks if the same is in excess of the product transaction limit and user input limit. If this holds true, the system indicates the same with below override/error messages:

The transaction is automatically authorized if automatic authorization is allowed for the profile of the user that has entered the transaction.

Viewing the main PC Transaction Input screen

From the ‘Fast Transaction Input’ screen, in View Mode, you can view the main ‘PC Transaction Input’ screen by clicking the arrow icon.

5.3 Transaction Authorization

This section contains the following topics:

5.3.1 Authorizing a Transaction

All operations on a contract need to be authorized before the end of day. Any user with the requisite rights can authorize an operation. Importantly, you cannot authorize an operation that you yourself have performed on a transaction. For instance, you cannot authorize a transaction that you have input, even if you have the rights to authorize transactions.

If you have the requisite rights, you can invoke the ‘Payments and Collections Transaction Authorize’ screen.

5.3.2 Invoking the Payments and Collections Transaction Authorize Screen

You can invoke this screen from the Application Browser by typing ‘PCDTRAUT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In this screen, you can authorize the following operations that are unauthorized:

When you launch the ‘PC Authorization’ screen from the application browser, you must specify a product category, and click ‘Authorize’ button. If you wish to authorize all contracts in all product categories, you can select the ‘ALL’ option.

When you specify a valid product category, all contracts pending authorization in the selected product category (or all categories, as per your selection) are displayed.

Contract Reference

Specify the reference number of the contract you need to authorize.

The system displays the following values related to the contract reference number specified:

To view the joint holder’s details of an account and the mode of operation maintained at the account level, place the cursor on the Customer Account Number field and press Ctrl+J. The system displays the ‘Joint Holder’ screen.

For more information on the ‘Joint Holder’ screen refer to the section ‘Joint Holder Maintenance’ in the Core User Manual.

5.3.3 Reject Button

Click ‘Reject’ link to mention authorization reject remarks, if you have rejected any transaction.

5.3.4 Error Button

Click ‘Error’ link, the system displays the Error Code details screen. You can view Error code details here.

5.3.5 Change Log Button

Click ‘Change Log’ link view the changes from the contract before and after Amendment. The system displays the old and new values of the modified fields of the contract.

The following details are displayed here:

Status Details for Contracts Pending Authorization

The status details for each contract are displayed in the Status Fields section:

Rekey Fields for Contract Authorization

If your bank has enforced re-key of contract details during authorization, the values to the re-key fields will not be displayed. You have to enter these values to authorize the contract. If the re-key values you enter do not match the contract you are calling for authorization, an error message will be displayed. If authorization is successful, the next unauthorized contract in the batch will be displayed.

Overrides for Contracts Pending Authorization

All override conditions that occurred at the time of contract input are also displayed for information in the Overrides section. Click on the checkbox alongside the override field, to confirm the override. When confirmed, the checkbox contains a tick mark.

Viewing contracts while authorizing them

While in the ‘PC Authorization’ screen, you can view the details of a contract that you wish to authorize. However, you must first specify the details that are to be rekeyed (if any) in the Rekey Fields section.

Authorizing contracts

To authorize a contract after you have verified it, select it in the grid at the top of the screen and click ‘Ok’ button. The contract is marked as authorized.

To authorize all transactions, choose the ALL option at the top of the screen, and then click the ‘Ok’ button.

All validations that are performed at the time of input or amendment of the contract are performed at the time of authorization to ensure consistency. The details relating the authorization time and User ID of the person authorizing the contract are recorded for audit purposes.

You cannot authorise a transaction in the following cases:

Canceling operations in the PC Authorization screen

To cancel your operations and exit the ‘PC Authorization’ screen, click ‘Exit’ button.

5.3.6 Amending Authorized Contracts

The Payments and Collections screen enables you to modify the contract which is not liquidated or dispatched, post-authorization. When a contract is modified, the system triggers AMND event. The features of the event are as follows:

  1. A new event ‘AMND’ is triggered, whenever an authorized contract, for which either DRLQ or CRLQ or DCLG events are not triggered, is modified.
  2. When AMND event is triggered, the system computes the values in the event log table (cstb_contract_change_log) for all the modified fields.
  3. AMND event need not be attached in product; it is triggered internally for all modifications performed as part of Step 1.
  4. AMND event is not triggered when un-authorized contracts are modified.
  5. No accounting entries will be passed for AMND event.
  6. When a contract is booked with activation date in future and when the same contract's activation date is modified to current date, the system will not trigger liquidation events, since the system will not default the customer entry value dates. To trigger liquidation events, you need to visit ‘Transaction Details’ tab, modify the customer entry value date, and save the contract.

5.3.7 Viewing Transaction Authorization Details

You can view the transaction authorize details in ‘Transaction Authorize Summary screen, You can invoke this screen from the Application Browser by typing ‘PCSTRAUT’ in the field at the top right corner of the Application Browser.

In the above screen, you can base your queries on any or all of the following parameters and fetch records:

Select any or all of the above parameters for a query and click ‘Search’ button. The records meeting the selected criteria are displayed.

5.4 Multilevel Authorization of a Contract

High value transactions may require multilevel of authorization. The levels of authorizations are defined in the ‘Product Transaction Limits’ screen. You can use the ‘Multilevel Authorization Detailed’ screen for authoring a contract n-1 times. However, final authorization can take place only in the contract screen.

For more details, refer the ‘Multilevel Authorization of Contract/Loan Account’ section in the ‘Procedures’ User Manual.

5.5 Collection Transaction

This section contains the following topics:

5.5.1 Operations on Collection Transaction

The operations that you can perform on a collection transaction in the ‘PC Transaction Input’ screen depend upon whether it is authorized. If the transaction is unauthorized, you can:

You can perform any of the following operations (as required) on an authorized collection transaction:

Note

For transaction rejects (outgoing or incoming DD) that are uploaded after the applicable response days have elapsed, an override is sought by the system. The processing for such transactions is based on two factors:

For more details about the rejection process in the case of such transactions, refer the chapter ‘Defining the attributes specific to Payment and Collection products’ in this user manual.

Note

During reversal of a transaction, the System verifies whether the transaction has been dis­patched earlier. If so, an override is sought. On accepting the override, the reversal will proceed.

5.5.2 Collection Status of a Transaction

The collection status of a transaction depends on the operations that have been performed in respect of it. Accordingly, a collection transaction could be in any of the following statuses:

5.5.3 Status of a Transaction

The status of a payments or collection transaction indicates the processing stage of the contract in the system. The following statuses are possible:

5.6 Exchange Rate for a Transaction

If payment transactions involve a customer account maintained in a foreign currency, the exchange rate to be used is either picked up automatically (based on the product specifications), or manually entered.

In the ‘Exchange Rate’ screen, invoked from the Application Browser, you can specify the exchange rate for contracts involving customer accounts maintained in a foreign currency.

When you invoke the ‘Exchange Rate Input’ screen from the Application Browser, all details of the contract are displayed. However, you can only enter a value in the Exchange Rate field. If the rate you input exceeds the override variance limit defined for the product, an override message is displayed. However, if the rate variance is more than the maximum limit maintained for the product, an error message is displayed. You have to specify a rate that is within the variance limits specified for the product.

If the contract amount exceeds the Auto Exchange Rate limit defined for the remitter account, an override is displayed.

If you have specified an appropriate rate for the contract, you can save your specification by clicking on the SAVE button.

Any manual exchange rate input requires an authorization. Once the exchange rate is authorized, the contract is moved from the Exchange Rate Queue to the normal processing queue for further processing.

5.7 Input of Exchange Rates Authorization

All contracts for which the exchange rate has been input manually need to be authorized before the end of day. The date and time, and the User ID of the person authorizing the contract will be recorded for audit purposes.

Note that the person who entered the exchange rate for a contract cannot authorize it.

When you invoke the authorization function from the Application Browser, you will be prompted to specify a product category. If you enter a valid code, the authorization screen is displayed. To begin the authorization process, click on the AUTH button. You will be prompted to specify a valid Batch Number. A User ID or Reference number is then displayed.

If re-key of exchange rate is required during authorization, the value will not be displayed. You have to input the values in the re-key fields to authorize the contract. If the re-keyed values for the contract do not match the contract you are calling for authorization, an error message is displayed.

All overrides provided by maker of the record will be displayed. On confirmation, the contract is marked as authorized.

You can Skip a record that is displayed for authorization or choose not to authorize it by clicking on the Reject button. All records that you reject will form a part of the Transaction Re-input Queue.

5.8 Exchange Rate Refresh

This section contains the following topics:

5.8.1 Invoking the Exchange Rate Refresh Screen

As mentioned earlier, the exchange rate applicable for transactions involving foreign currency customer accounts is either automatically picked up or manually entered, depending upon the product preferences. On a given business day, you can trigger the refreshing of exchange rates for all products used at a branch, in the ‘Exchange Rate Refresh’ screen.

You can invoke this screen by typing ‘PCDTRFSH’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

You can also update the refreshed exchange rate across all branches, by selecting the ‘Propagate Across Branches’ option.

5.9 Credit Exceptions

This section contains the following topics:

5.9.1 Invoking the Credit Exception Queue

If the customer liability exceeds the specified limit as a result of a contract, an exception is raised and the contract is moved to the Credit Exception Queue. You can Confirm or Reject these overrides in this screen. You can invoke this screen by typing ‘PCDCRXSQ’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

The contracts are grouped on the product code and customer account. A consolidated amount for each combination is also furnished.

The information is sorted/queried along the following criteria:

Choose any of the following options by clicking on the appropriate buttons in the toolbar in the ‘Credit Exceptions Queue’ screen:

Note

5.10 Customer Legs Consolidation

This section contains the following topics:

5.10.1 Accounting Entries for Customer Legs Consolidation

If you wish to consolidate the accounting entries of customer legs of collection transactions, use the ‘Consolidation Summary’ screen. Only contracts marked for customer entry consolidation will be grouped into batches based on the following:

Through consolidation, you can post a single entry for the customer leg of all transactions grouped under the consolidation batch. The transaction with customer consolidation across products are also grouped under a consolidation batch. The batch populated for Contracts with customer consolidation across products will have Product Code as Blank.

5.10.2 Invoking the Consolidation Summary Screen

You can invoke this screen by typing ‘PCSCNSOL’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Choose any of the following options in the ‘Consolidation Summary’ screen:

5.11 Consolidation Exception Queues

This section contains the following topics:

5.11.1 Invoking the Consolidation Exception Queue

There could be many reasons why rejections can occur during processing of payment and collection transactions for consolidation. Exceptions are raised in respect of transactions that are rejected. Such transactions, which are not considered for consolidation (due to rejection), can be viewed in the Consolidation Exception Queue. You can invoke this screen by typing ’ ‘PCSCNLEX’ in the field at the top right corner of the Application tool bar and click on the adjoining arrow button.

Here, you can manually verify the rejections. To confirm a rejection, click ‘Reject’ button. This operation must be performed before the end of day cycle can be run.

The other options available are:

The parameters considered are:

All contracts that are rejected during the accounting of a file consolidated entry forms part of a “Consolidation Exception Queue”

The file level consolidation batches falling under this exception queue has the product code value as 'Null'.

The consolidation exception queue has the following options

5.12 Transaction History Summary

This section contains the following topics:

5.12.1 Invoking the Transaction History Summary Screen

You can view all the transaction history using ‘Transaction History Query’ screen. You can invoke this screen by typing ‘PCSCONHS’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In this screen you can use the following fields to search the PC Transactions:

To recall all the contracts, click on ‘Recall’ button.

When you click ‘Search’ button the records matching the specified search criteria are displayed.

5.13 Transaction Exception Summary

This section contains the following topics:

5.13.1 Invoking the Transaction Exception Summary Screen

You can view all contracts that encountered a Transaction Exception (TR) during upload, through the ‘Transaction Exception Summary’ screen.

You can invoke this screen by typing ‘PCSTEXSQ’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In this screen you can maintain the following details:

To re-upload all the contracts, click the ‘Retry’ button. If the contracts are successfully uploaded, they will no longer be visible in the screen.

5.14 Split Transactions Summary

This section contains the following topics:

5.14.1 Invoking the Split Transaction Summary Screen

In certain cases, you may find it necessary to split an outgoing collection transaction into multiple transactions, due to restrictions on the amount of each payment that can be sent over the payment network. In the ‘Split Summary’ screen, you can view details of such split transactions, by drilling down from the parent transaction to the child transactions. You can invoke this screen by typing ‘PCSSPLTS’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In the ‘Split Summary’ screen, contracts marked for splitting (in the transaction details) are displayed based on the following:

To view any of the child contracts for a split contract, select it in the ‘Split Summary’ screen and click ‘Child’ button to view the child contracts.

5.15 Process Exception Queues

This section contains the following topics:

5.15.1 Invoking the Process Exception Queue Screen

The Process Exception Queue lists exceptions that are raised in respect of transactions rejected during processing. You have options for re-processing or rejecting any or all of the transactions appearing in this queue. These operations must be performed before the end of day cycle can be run. You can invoke this screen by typing ‘PCSPEXSQ’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In this screen you can maintain the following details:

To view the exceptions, click ‘Exception’ button. Click ‘Retry’ button to re-process all the contracts.

5.16 Exchange Rate Queues

This section contains the following topics:

5.16.1 Invoking the Exchange Rate Queue Screen

For a payments or collection contract involving a foreign currency customer account, the exchange rate required for processing is picked up by the system based on the exchange rate parameters specified for the branch and product combination involved in the transaction.

If the exchange rate is not picked up or if the exchange rate input process fails, the contract is logged into the Exchange Rate Queue. In this queue, you can manually enter the required exchange rate for the transaction. Until the exchange rate is manually entered for a contract logged in the Exchange Rate Queue, it cannot be processed. Also, such a manually entered exchange rate must be authorized to be effective, before the End of Day processes are executed, for that business day.

You can access the exchange rate queue, in the Exchange Rate Exception Queue. You can invoke this screen by typing ‘PCSXRXSQ’ in the field at the top right corner of the Application tool bar and click on the adjoining arrow button.

All contracts logged into the exchange rate queue are displayed, grouped according to the following:

Click ‘Exception’ to view the exceptions.

5.17 Periodic Exception Queues

This section contains the following topics:

5.17.1 Invoking the Periodic Exception Queue Screen

All periodic instructions that have failed to be executed in the immediate previous Beginning of Day batch and which are still pending resolution, can be viewed in the Periodic Exception Queue. You can access this queue in the ‘Periodic Exception Queue’ screen.

You can invoke this screen by typing ‘PCSPRXSQ’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In this queue, you can also view any instructions that have failed execution on any date earlier than the application date.

The periodic instructions in the queue are displayed grouped according to:

To view the exceptions, click the ‘Exception’ button. Click ‘Retry’ to re-process all the periodic instructions in the queue that have failed execution and have not been resolved on the application date. If the generation is successful for any of the instructions, they are marked ‘resolved’.

You can also choose to reject any of the instructions. To reject a transaction, click ‘Ignore’ in the toolbar.

5.18 The Batch Browser

This section contains the following topics:

5.18.1 Viewing Batches Summary

The Batch Browser lists all open batches in the system for collection transactions. You can close or re-assign batches that you opened.

You can invoke this screen by typing ‘PCSROWSE’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

For each batch, the following are displayed:

5.19 Updating Cut-Off Time Status

This section contains the following topics:

5.19.1 Invoking the Cutoff Time Update Screen

During the end of day run for a branch, the system resets cut-off time for all products to the time mentioned in the respective product definitions. You can use the ‘ Cutoff Time Update ’ screen to update the cut-off time for a collection product at a branch. This update can be made applicable only for a specific branch-product combination, or can be propagated across all branches for the same product.

The screen displays all products active at the branch. The cut-off times for each product can be changed here if desired.You can also invoke this screen by typing ‘PCDUTOFF’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Select the ‘Propagate Across Branches’ option to update the cut-off time across all branches.

5.20 SEPA Credit Transfers and Direct Debits

A SEPA credit transfer (SCT) is a transaction done on behalf of the Originator holding a payment account with the Originator Bank, in favour of a Beneficiary holding a payment account with the Beneficiary Bank.

The picture below gives the schematic representation for SEPA credit transfers processing.

The picture below gives the schematic representation for SCT processing from indirect participants (Originator and Beneficiary of Indirect participants of SEPA).

A SEPA Direct Debit Transfer (SDD) is a transaction done for collecting funds from a debtor’s account with a debtor bank and is initiated by a creditor via its bank (the creditor bank) as agreed between the Debtor and Creditor.

The picture below gives the schematic representation for SEPA Direct Debits processing.

The Common Payments Gateway is used to handle the SEPA (Single Euro Payments Area) messages for Credit/Debit Transfers. The incoming XML messages for SCT and SDD are uploaded into Common Payments Gateway and based on the STP rules specified the SCT and SDD transactions are created in the PC module.

Creditor Bank

Manual Creation

The following are the features for manual creation:

File Processing

The following are the features for manual creation:

Debtor Bank

Manual Creation

For manual creation of Incoming Collection, collection scheme type and customer type are validated, with respect to Incoming Collection product.

File Processing

 

Note

The message generated from DP to CSM is compliant with EBA STEP2 SEPA rule book and the message generated from DP to IP is ISO standard compliant.

5.21 Payment Cancellation Request

This section contains the following topics:

5.21.1 Recalling Credit Transfer - Camt.056.001.01

The Payment/Collection Cancellation Request (Camt.056.001.01) message is sent by a Case Creator/Case Assigner to a Case Assignee. This message is used to request the cancellation of an original payment instruction. The Payment Cancellation Request message is exchanged between the instructing agents. The instructing agent requests the cancellation of an interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer). The negative answer to the Payment Cancellation message is Camt.029 message.

Note

Oracle FLEXCUBE provides a facility to identify the contracts which needs to be re-called for which pacs.003.01.02 or pacs.008.01.02 message already sent. The system generates the Camt.056 message and sends it to the assignee to cancel the already sent message. The Camt.056 message caters for single or group cancellation requests.

You can mark the list of contracts for which Camt.056 needs to be generated through 'Payments and Collections Cancellation' screen. You can invoke this screen by typing 'PCDRCLIN' in the field at the top right corner of the Application tool bar and click on the adjoining arrow button.

You need to capture the following details here:

Original Message Reference Number

Select the original message reference number from the adjoining option list.

Contract Reference Number

Select the contract reference number from the adjoining option list.

Customer Reference

Select the customer reference number from the adjoining option list.

Account Number

Select the account number from the adjoining option list.

To view the joint holder’s details of an account and the mode of operation maintained at the account level, place the cursor on the Account Number field and press Ctrl+J. The system displays the ‘Joint Holder’ screen.

For more information on the ‘Joint Holder’ screen refer to the section ‘Joint Holder Maintenance’ in the Core User Manual.

Settlement Date

Specify the settlement date.

Recall Reference Number

System displays the unique sequence number.

Recall Reason

Select the recall reason from the adjoining list of values that display the valid ISO Reject codes applicable for the Payments and Collections Cancellations.

Cancellation' initiation processing in this screen validates the entered ISO Reject code against the applicable exceptions as maintained in the 'Reject Code maintenance'.

An error message would be displayed if the entered Reject code is not applicable to the 'Cancellation' initiation exception.

Additional Recall Reason

Specify a text value of 105 characters for the field, which must be a description about the fraudulent origin of the transaction.

Note

If 'Fraudulent' field is not 'Additional recall Reason' and 'Additional Recall Information' field is defined, then the system throws an error.

Additional Recall Information

If 'Fraudulent' is selected in the 'Additional Recall Reason' field, then specify details on the fraudulent origin of the transaction. The system will throw an error if 'Additional Recall Information' is entered when 'Fraudulent' is not the additional recall reason. A maximum of 105 characters can be specified in this field.

Service Type

Specify the value for the field from the adjoining drop-down list.

The field takes following values-

Note

Click on the 'Search' button to fetch the matching contracts based on the search criteria provided.

Note

The system generates the Camt.056 message only for liquidated contracts.

Contract Reference Number

Select Contract Reference Number from the adjoining option list

Cancellation Originator Name

Specify the name of the cancellation originator.

The system validates the cancellation originator name fro cancellation request with reason 03.

Cancellation Originator Bank

Specify the bank of the cancellation originator.

Note

Specify either Cancellation Originator Name or Cancellation Originator Bank.

The cancellation originator bank is validated for cancellation request with reasons 01 and 02.

The system defaults the following:

Recall Status

The system updates the recall status.

Original Contract Reference Number

Specify the original contract reference number.

If the cancellation request is initiated with reason as Duplicate transference then the system captures the original contract reference number.

Cancellation Commission Code

Select the cancellation commission code from the adjoining option list.

Cancellation Commission Amount

Specify the cancellation commission amount.

You have an option to select the contracts from the list of contracts. While saving the selected contracts, the system creates a reference number and inserts the contract details in new data store.

The table below explains the list of Recall Reason:

Recall Reason

AGNT

Incorrect Agent

Agent in the payment workflow is incorrect

CURR

Incorrect Currency

Currency of the pay­ment is incorrect

CUST

Requested By Customer

Cancellation is requested by the debtor

CUTA

Cancel Upon Unable To Apply

Cancellation requested because an investiga­tion request has been received and no remedi­ation is possible

DUPL

Duplicate Payment

Payment is a duplicate of another payment

UPAY

Undue Pay­ment

Payment is not justified.

The set of transaction stored for payment cancellation is authorized and the system picks only authorized records for payment cancellation message generation.

Note

The system generates the Camt.056 for all contracts for which recall is requested through 'SEPA Payment Cancellation'. It does not validate the number of days before which the recall can be made.

You can manually reject the cancellation request by inputting the CSM Reject Detail , Reject Code and Reject Reference Number.

On saving the cancellation status will be changed into Rejected By STEP 2.

Rejection of Cancellation of Payments

On rejection, 'Cancellation Status' at cancellation request level would be marked as 'Rejected'.

'Reject Code', 'Reject Detail' entered during reject operation would populate 'CSM Reject Code' and 'CSM Reject Detail' fields respectively at cancellation request level.

Rejection of Cancellation of Collections

On rejection, 'Cancellation Status' at cancellation request level would be marked as 'Rejected'. 'Reject Code', 'Reject Detail' entered during reject operation would populate 'CSM Reject Code' and 'CSM Reject Detail' fields respectively at cancellation request level.

This rejection process would re-activate the original Outgoing Collection with the contract details as prior to the cancellation. An event 'RACT' will be logged for the original Outgoing Collection in the contract events data store.

5.22 Handling Cancellation of Outgoing Payments & Col­lections that are not dispatched to CSM

Cancellation requests are made in 'Payments and Collections Cancellation' (PCDRCLIN) screen. You can 'Reject' the Outgoing Payment contract by performing pre-settlement rejection (RJBS) if the Outgoing Payment is not dispatched. On Rejection The status will be changed into Recall Success. Accounting entries passed during debit liquidation and credit liquidation would be reversed. Dispatch process does not consider this rejected Outgoing Payment contract and Cancellation request. Cancellation of Outgoing Collections that are not dispatched to CSM would follow the same processing as described in the above points.

5.23 Handling Manual Rejection of Cancellation (Camt.056) for Payments and Collections

This section contains the following topics:

5.23.1 Payments and Collections Cancellation (PCDRCLIN)

You can manually reject cancellation for Payments and Collections using 'Payments and Collections Cancellation' screen.

5.23.2 Credit Validation File (CVF) Process

If Camt.056 recall request is sent for the outgoing payment, the status of the Camt.056 is sent in CVF file by STEP2. On receipt of the CVF file by the sender bank, system reads the CVF file and finds the status of the Camt.056 message. If the status is rejected, then the status is updated as rejected in the system.

5.23.3 Settled Credit File (SCF) Process

STEP2 will send the SCF file to the receiver bank. The SCF file will contain the below details

On receipt of the SCF file, if any payment recall request is available in SCF, system cancels the incoming payment contracts which is already created using pacs.008.

5.23.4 Debit Verification File (DVF) Messages

If Camt.056 recall request is send for the outgoing collection, the status of the Camt.056 will be send in DVF file by STEP2. On receipt of the DVF file by the sender bank, system will read the DVF file and find the status of the Camt.056 message. If the status is rejected, then the status will be updated as rejected in the system.

5.23.5 Debit Notification File (DNF) Process

The messages and bulks sent to the receiving Direct Participants are grouped by Interbank Settlement Date, but there is not a one to relationship between the Bulk messages received by STEP2 and the Bulk messages sent by STEP2. Only pacs.003 (Debit requests), pacs.002 (Rejections), and camt.056 (Payment Cancellation Request) are forwarded in a DNF.

On receipt of DNF file, the receiver bank system will process the new message camt.056 and cancel the already received incoming collection contract which is created using pacs.003.

5.23.6 Incoming Cancellation Exceptions Queue (PCSCANEX)

The 'Incoming Cancellation Exception Queue' (PCSCANEX) is used to log the transactions that are failed during cancellation Acceptance and Rejection processing. The exception queue status for the failed transactions during cancellation processing will be 'CR'. The error code and error description for the failures can be displayed in this screen against each transaction.You can invoke this screen by typing 'PCSCANEX' in the field at the top right corner of the Application tool bar and click on the adjoining arrow button.

This screen will have the following fields,

Recall Reference Number

Indicates the reference number generated for cancellation. Maximum length can be 16 characters.

Contract Reference

Indicates the original contract reference number for which cancellation is received. Maximum length can be 16 characters.

Direction

Indicates whether the transaction is incoming or outgoing. Maximum length can be 1 character.

Recall Status

Indicates the status of cancellation. Maximum length can be 1 character.

Customer No

Indicates the customer involved in the transaction.Maximum length can be 9 characters.

Product Code

Indicates the product used for the original contract.Maximum length can be 4 characters.

Account

Indicates the customer account used in the transaction. Maximum length can be 35 characters.

Transaction Amount

Indicate the amount of the original transaction. Maximum amount can be 999999999999999.99

Transaction Currency

Indicates the currency used in the original transaction. Maximum length can be 3 characters.

Error Code

Indicates the error faced during cancellation processing.Maximum length can be 11 characters

Error Description

A display field to describe the error faced during cancellation processing.

Exception Queue

Indicates the status of exception queue. Maximum length can be 2 characters.

Click' Retry' button to retry the cancellation processing. Once the transaction is corrected from the error cause, cancellation processing can be retried by using 'Retry' button. 'Retry' option will execute the cancellation processing on the selected transaction. On successful processing, the exception queue status of a transaction will be changed to '##'.

5.24 SEPA Payment Cancellation Summary Details

This section contains the following topic:

5.24.1 Invoking the SEPA Payment Cancellation - Summary Screen

You can view the summary details of a SEPA Payment Cancellation in 'SEPA Payment Cancellation - Summary' screen.You can invoke this screen by typing 'PCSRCLIN' in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

In this screen, you can query based on any combination of the following fields:

After specifying the parameters for the query, click 'Search'. The system displays all the records matching the parameters specified.

5.25 Incoming Camt.056 Messages

On receipt of incoming Camt.056, system identifies matching Pacs.008/Pacs.003 based on the Original Message ID and Original transaction ID provided in the incoming Camt.056. If no matching contract found, system updates the Camt.056 message status as Repair. Oracle FLEXCUBE provides a facility to approve/reject the incoming Camt.056 for Incoming payment messages through 'Incoming Payment Cancellation Approval' screen

5.25.1 Invoking the Incoming Payment Cancellation Approval Screen

On receipt of incoming Camt.056, system identifies matching Pacs.008/Pacs.003 based on the Original Message ID and Original transaction ID provided in the incoming Camt.056. If no matching contract found, system updates the Camt.056 message status as Repair. Oracle FLEXCUBE provides a facility to approve/reject the incoming Camt.056 for Incoming payment messages through 'Incoming Payment Cancellation Approval' screen. You can invoke this screen by typing 'PCDRCLOT' in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

You need to capture the following details here:

Original Message Reference Number

Select the Original Message Reference Number from the adjoining option list.

Contract Reference Number

Select the Contract Reference Number from the adjoining option list.

Recall Reference Number

System defaults the unique sequence number.

Related Reference Number

Select the Related Reference Number from the adjoining option list.

Account Number

Select the Account Number from the adjoining option list.

To view the joint holder’s details of an account and the mode of operation maintained at the account level, place the cursor on the Account Number field and press Ctrl+J.The system displays the ‘Joint Holder’ screen.

For more information on the ‘Joint Holder’ screen refer to the section ‘Joint Holder Maintenance’ in the Core User Manual.

Click on 'Search' button to fetch the matching incoming messages based on the search criteria.

Incoming Cancellation Request

You can accept or reject the process of incoming cancellation request through Incoming Payment Cancellation Approval screen. The options for rejecting cancellation for incoming payment are:

 

51

Insufficient balance

53

Customer specific order to not attend the request.

54

Charged account can­celled or audited or confiscated.

55

Public restrained account.

61

Absence of beneficiary authorization

62

Already cancelled

65

Non existent or wrong data

The option for accepting cancellation for incoming payment is:

 

 

08

Issuing entity request

All the cancellation request transaction is logged to the CPG. The system defaults the request with message type CNLCT. You can accept or reject the request within the number of days maintained at product level.

If the request is accepted then the cancellation status will be approved.

If the request is rejected then the system updates the cancellation status as 'Rejected'

There is no accept or reject process for incoming collection cancellation requests. The system books a reject of incoming collection contract with message type as CNLDD.

Cancellation Originator Name

Specify the name of the cancellation originator.

Cancellation Originator Bank

Specify the Bank of the cancellation originator.

Note

Specify either Cancellation Originator Name or Cancellation Originator Bank.

Approve/Reject

Select Approve or Reject from the adjoining option list.

Reject Code

Select the reject code from the adjoining option list.

You can specify the ISO Reject code in this screen during the 'Cancellation' acceptance/rejection operation.

During 'Cancellation' acceptance/rejection processing in this screen system validates the entered ISO Reject code against the applicable exceptions as maintained in the 'Reject Code maintenance'. An error message would be displayed if the entered Reject code is not applicable to the 'Cancellation' acceptance/rejection exception. The system defaults the following:

Original Recall Reason

The value for the field is defaulted from the CPG upload data store. Cancellation requests can be approved or Rejected based on the reasons defined in the field.

Original Additional Recall Reason

The value for the field is defaulted from the CPG upload data store. Cancellation requests can be approved or Rejected based on the reasons defined in the field.

Original Additional Recall Information

The value for the field is defaulted from the CPG upload data store. Cancellation requests can be approved or Rejected based on the reasons defined in the field.

Cancellation Originator Name

Specify the value for the field, which is of length 70 characters.

Note

The name is viewed in the following messages-

Additional Reject Reason

Select the additional reject reason from the adjoining option list

Note

Specify either Reject code or Additional reject reason.

Cancellation Commission Code

Select the cancellation commission code from the adjoining option list.

Cancellation Commission Amount

Specify the cancellation commission amount.

The ‘Incoming Payment Cancellation Approval’ screen lists only the incoming payment contracts. You can select the message and approve or reject the recall request. The system does not validate the number of days before the recall request can be processed. If you reject the incoming recall message, then you have to input the reject reason. On save of the selected contracts, the system creates a reference number and inserts the message details in new data store.

The table below lists the reject reason maintained in the system:

Reject Reason

LEGL

Legal Decision Reported when the cancellation cannot be accepted because of regulatory rules.

AGNT

Agent Decision Reported when an agent refuses to can­cel.

CUST

Customer Decision Reported when the cancellation can­not be accepted

The system authorizes the set of transaction stored for payment cancellation. It picks only authorized records for payment cancellation initiation. During recall of the contract, the recall reason should be the recall reason provided in the camt.056 message.

Note

For incoming collection contracts cancellation, the approval is not applicable and system recalls the contract with reject reason provided in camt.056.

Since incoming collection cancellation requests cannot be rejected by the receiver bank, on receipt of Camt.056 for Incoming Collection Cancellation, system directly recalls the original contract. The mark EOTI validations check the pending approval for the cancellation requests. Validation is done considering the cancellation acceptance parameters captured at product level. Number of days from the product will be validated for pending approval based on the cancellation reason. If any of the cancellation request is not approved then the system aborts the EOTI process.

5.26 Handling of Camt.056 for Incoming payments in Transaction Repair queue

Any Incoming Camt.056 on repaired Incoming Payment will fail since the original Incoming Payment contract is in 'TR'queue. A static data for the error code 'PC-SVV-106' is made available and used during cancellation processing when the original contract is in 'TR' queue.

This error code and error description is logged against the Camt.056 received and the cancellation transaction is logged into 'CR' queue. An information message is displayed/logged describing that the cancellation transaction is logged into 'CR' queue.

In order to respond to the received Camt.056 message, Original Incoming Payment contract in 'TR' queue is corrected by re-processing original contract with Unsettle GL. Once the original Incoming Payment contract is cleared from TR queue, cancellation transaction is retried in 'Incoming Cancellation Exception Queue' screen and the response for the cancellation request is sent to CSM.

5.27 Handling of Camt.056 for Incoming Collections in Transaction Repair queue

Manual approval of cancellation of Incoming Collections

You can approve the cancellation request received for Incoming Collection transactions that are not auto approved or failed during auto approval using the screen 'Incoming Payments and Collections Cancel Approval'.

'Approval' process on Incoming Camt.056 on Incoming Collection will fail since the original Incoming Collection is in 'TR' queue. Cancellation transaction would be logged into 'CR' queue.

An information message is displayed/logged that describes that the cancellation transaction would be logged into 'CR' queue.

In order to process received Camt.056 message, Original Incoming Collection contract in 'TR' queue is corrected by re-processing original contract after correcting the error cause.

Once the original Incoming Collection contract is cleared from TR queue, cancellation transaction is retried in 'Incoming Cancellation Exception Queue' screen.

5.28 Handling Conflict Scenarios

Payments

Case 1 - Receipt of Pacs.004 from Creditor Bank for Outgoing Payments for which Camt.056 is already sent by Debtor Bank.When CSM processes Pacs.004 for Outgoing Payment, Debtor Bank processes the incoming Pacs.004 and cancellation request is rejected.

Case 2 - Receipt of Camt.056 from Debtor Bank for Incoming Payments for which Pacs.004 is already sent by Creditor Bank.

Collections

Case 3 - Receipt of Camt.056 from Creditor Bank for Incoming Collections for which Pacs.002 is already sent by Debtor Bank.

Case 4 - Receipt of Pacs.002 from Debtor Bank for Outgoing Collections for which Camt.056 is already sent by Creditor Bank.

Case 5 - Receipt of Pacs.007 from Creditor Bank for Incoming Collections for which Pacs.004 (Recall) is already sent by Debtor Bank.

Case 6 - Receipt of Pacs.004 (Recall) from Debtor Bank for Outgoing Collections for which Pacs.007 is already sent by Creditor Bank.

5.29 Viewing SEPA Payment Cancellation Approval Sum­mary Details

This section contains the following topic:

5.29.1 Invoking the SEPA Payment Cancellation Approval - Summary Screen

You can view the summary details of a SEPA Payment Cancellation Approval in 'SEPA Payment Cancellation Approval - Summary' screen.You can invoke this screen by typing 'PCSRCLOT' in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In this screen, you can query based on any combination of the following fields:

After specifying the parameters for the query, click 'Search'. The system displays all the records matching the parameters specified.

5.30 Negative Answer to Recall of a Credit Transfer - Camt.029.001.03

The receiver bank sends the Camt.056 message to recall already sent Pacs.008/Pacs.003. If the receiver bank is unable to process the Camt.056, then the receiver bank sends the Camt.029.001.03 message to STEP2 in case of Payment Cancellation. You can generate the Camt.029.001.03 for all incoming Camt.056 which are rejected from Incoming Payment Cancellation Approval screen.

5.31 Incoming Camt.029.001.03

The receiver bank sends resolution of investigation message to notify the sender that the cancellation request has been rejected. On receipt of the Incoming Camt.029 message, system reads the message and updates the original Camt.056 message status as 'Rejected'.

5.32 Maintaining Parameters for SEPA Transactions

The following maintenances need to be done for the SEPA transactions to be carried out.

Product and Product Category

To handle SEPA transactions, the following product types and product categories are maintained:

For more details refer section ‘Maintaining Product Categories’ in the chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

Clearing Network

To include the ISO codes in the outgoing XML messages for SEPA transactions the ISO clearing system identification codes for clearing networks are maintained in the Clearing network maintenance screen.

For more details refer section ‘Maintaining Clearing Network details’ in the chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

Common Payment Gateway Parameters

To handle SEPA transactions the following maintenance needs to be done as part of maintaining the Common Payments Gateway parameters:

For more details on how to maintain Common Payments Gateway Messages Type, refer section ‘Maintaining Common Payment Gateway Message Parameters’ in the chapter ‘Processing of Non SWIFT Incoming Payment Messages’ of the Funds Transfer User Manual.

Queue Parameters

To handle SEPA transactions the following maintenance needs to be done as part of maintaining the Queue details:

For more details on how to maintain Queues, refer section ‘Queues Maintenance’ in the chapter ‘Straight Through Processing – An Overview’ of the Funds Transfer User Manual.

Product Mapping

To handle SEPA transactions, as part of mapping message types to product and queues, you need to map PC product category for SCT and SDD message types. This can be done using the Product Mapping Detailed screen.

For more details on mapping message types to products refer section ‘Mapping Message Types to Products and Queues’ in the chapter ‘Straight Through Processing – An Overview’ of the Funds Transfer User Manual.

Message Mapping

To handle the processing of incoming SEPA transaction messages, you must maintain mappings between the Common Payment gateway fields and their corresponding fields in the Payments and Collections module, for different combinations of incoming message type, product category / product / instrument type, source code, station ID and network id

For more details on mapping message tags to payment fields refer section ‘Mapping of Incoming Message Tags to Fields in Payments and Collection Module’ in the chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

Error Code Maintenance

To handle auto rejection of incoming payments for SEPA, you need to maintain some error codes, based on which the system rejects the payment.

For more details on maintaining error codes, refer section ‘Maintaining error codes for automatic rejection’ in the chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

Reject Code Maintenance

You need to maintain the ISO reject codes that are used for SCT rejects using the ‘PC Reject Code’ screen.

For more details on maintaining reject codes, refer section ‘Reject Code Maintenance’ in the chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

STP Rule Maintenance

To handle SEPA transactions the following maintenance needs to be done as part of maintaining the STP Rule maintenance:

Based on the above mentioned maintenance, the STP rule is set for the following:

PC Beneficiary Maintenance

The counterparty identification details for the SEPA transaction is maintained in the PC Beneficiary Maintenance screen.

For more details on this refer section ‘Maintaining Beneficiary Accounts for a Counterparty Bank’ in the chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

Learning Database Maintenance

The customer and counterparty details of the SEPA transaction is maintained in the Counterparty Details screen. These details that you maintain here can be viewed in the Contract Online screen if the learning database option is selected.

For more details on this refer section ‘Maintaining a Learning Database’ in the chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

Creditor DD Agreement

The details of the Creditor involved in the SEPA Direct Debit Transactions are maintained in the ‘PC-Creditor DD Agreements’ screen.

For more details on this refer section ‘Maintaining DD agreement details for creditors’ in the Chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

PC Periodic Instructions

The identification details of the customer and the counterparty involved in the SEPA transactions are also captured in the PC Periodic Instructions screen.

For more information on this refer section ‘Maintaining Details for Periodic Instructions’ in the chapter ‘Maintaining Information specific to the Payments and Collections Module’ of this User Manual.

PC Transaction Input

The SEPA related details of the contract are captured in the PC Transaction Input screen.

For more information on this refer section ‘Capturing the details of payment/collection transactions’ in this User Manual.

5.33 SEPA Transaction Process Flow

The various stages involved in processing a SEPA transaction are as given below:

  1. Receiving Incoming messages for SCT and SDD
  2. Using the Common Payments Gateway to upload data (from the Incoming SCT and SDD) into PC module. Queue is derived from STP rules.
  3. The PC product category will be picked up from the Product mapping maintenance based on the queue evaluated in the rule maintenance
  4. Mapping the Common Payment gateway fields to PC contract fields for the product category, using the PC message Mapping Maintenance screen, for different combinations of incoming message type, product category/product/instrument type, source code, station ID and network id
  5. Using the contents of the message together with the static maintenance in the system to resolve the contract fields.
  6. Automatic booking of contracts in the system depending on the resolved contract fields.
  7. Processing the contracts depending on the status of the contract.
  8. Generating dispatch files which is sent to CSM, Bank or the Customer.

The contract in the Common Payments gateway can have any of the following statuses:

The contracts with status ‘Unprocessed’ or ‘Waiting for Queue Exchange’ in the Common Payments Gateway browser will be picked up for processing and the PC contract will be created. If the creation of the PC contract fails, the transaction is marked as ‘Repair’ in the Common Payments Gateway. However, you can amend and process this contract again. In such a case, a new version will be created for the amendment operation in the Common payments Gateway message browser.

The transaction in the reject messages (Reject – Payments Status Report pacs.002.001.02) from the Clearing and Settlement Mechanisms (CSM) will be kept in common payments gateway with status as ‘Unprocessed’ and queue as ‘REJECT’. When you click ‘Process Reject’ button, the system does a pre-settlement reject of a SEPA transaction. The status is further updated as ‘Processed’. There will be no transactions created in PC module for these reject transactions and no further processing will be allowed on such transactions.

The incoming payment messages with the following error codes are automatically rejected:

Error Code

Error Description

PC-SAV-024

Account is blocked

PC-SAV-025

Payment Not allowed for customer account

PC-SAV-026

Credit not allowed for customer account

PC-SAV-027

Debit not allowed for customer account

PC-SAV-028

Customer account is dormant

PC-SAV-029

Customer account is frozen

For more details on maintaining error codes for automatic rejection, refer section ‘Maintaining error codes for automatic rejection’ in ‘Maintaining Information specific to the Payments and Collections Module’ chapter in this User Manual.

For more details on events and accounting entries for SEPA transactions, refer chapter Annexure A - Accounting Entries and Advices’ in this User Manual.

5.34 Validations done on the SCT and SDD Messages

The system performs certain validation on the incoming and outgoing instructions for SCT and SDD. Following are some of the validations done by the system:

5.35 Refund Compensation and Balancing Payment for Debtor Bank

The processing done at Debtor bank, CSM and Credit Bank for handling refund of compensation is given below:

Debtor Bank Processing

On Debtor's request for Refund, Debtor bank sends Refund instruction to CSM.

Debtor bank has rights to collect refund compensation for the loss incurred by crediting the debtor with value date as settlement date of original collection transaction. Crediting the debtor with back value dated will be achieved by configuring 'Original Transaction Value Date' parameter at product level.

This compensation facility is only for the Refund transactions originated by the Debtor.

Apart from the compensation amount, balancing payment charges from the Creditor Bank to the Debtor Bank can be recovered by existing charge mechanism. Hence Debtor Bank can send the Refund instructions with original collection amount + compensation amount + charges amount.

During Refund processing, Debtor bank debits CSM for the original collection amount, compensation amount and charge amount and credits original collection amount into Debtor account as of value date of the original collection transaction. Compensation amount and charge amount will get credited into 'compensation suspense account' and 'charge suspense account' respectively with value date as the date on which refund is initiated.

CSM Processing

Once CSM receives the Refund instructions with compensation amount and charges amount, it will debit the creditor bank with Returned Interbank settlement amount and credit debtor bank with Returned Interbank settlement amount. Returned Interbank settlement amount comprises of 'Original Interbank Settlement Amount' + 'Compensation Amount' + 'Charge Amount'.

Credit Bank Processing

Debiting the creditor with back value dated will be achieved by configuring 'Original Transaction Value Date' parameter at product level.

Creditor bank on receipt of Refund instructions will debit the creditor for the original collection transaction amount and debits 'compensation suspense account' for the compensation amount and debits 'charge suspense account' for charges amount. The original collection transaction amount + compensation amount + charge amount will get credited in to CSM.

5.36 Dispatch File Parameters

This section contains the following topics:

5.36.1 Invoking the Dispatch File Parameters

You can maintain the details of the dispatch file to be generated using the ‘Dispatch File Parameters’ screen. You can invoke this screen by typing ‘PCDSFPRM’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

The following details are captured here:

Dispatch Type:

Select the type of the dispatch from the drop-down list. The following options are available in the drop-down list:

This is a mandatory field.

Network Code

Select the clearing network for which the dispatch file parameters are maintained from the adjoining option list. The list displays all valid clearing network maintained in the system. This is a mandatory field.

Service Identifier

Select the service type as of the clearing network from the drop-down list. The options available are:

Bank Code

Specify the direct or the indirect participant bank code for which the dispatch file parameters are maintained. This is enabled for ‘Bank’ dispatch type.

Customer Account

Select the customer account number for which the dispatch file details are maintained. This is enabled only for ‘Customer’ dispatch type. If you want to generate dispatch files for every customer you can select the option ‘ALL’.

Reference Number

This indicates the reference number entered for every dispatch run. This reference number is used to track the number of files generated as part of every dispatch run.

Maximum Number

The following details are captured:

Files

Specify the maximum number of files that can be sent to the clearing network in one settlement cycle.

Message Bulks

Specify the maximum number of message bulks in a file.

No of Transaction in Bulk

Specify the maximum no of transactions that can be bulked in a message bulk.

Test Mode

Select the test mode from the drop-down list. The options available in the drop-down list are:

This is a mandatory field for dispatch type as Network.

File Format Type

Specify the format of the file. The supported file format is XML. This is mandatory field.

File Path

Specify the path where the file has to be generated.

Bulk Message

Check this box to indicate that the message bulk should be created with many transactions.

File Per Transaction Type

Check this box if you want the system to generate one file for each transaction type.

If this option is not selected then one file is created with the following transaction type in the same order:

If this option is selected then one file is created for each transaction type.

5.37 Dispatch File Generation

This section contains the following topic:

5.37.1 Invoking the Dispatch File Generation Screen

Once the SCT and SDD messages are processed in Oracle FLEXCUBE, the system needs to generate and dispatch the handoff files. You can generate the dispatch file using the ‘Dispatch File Generation’ screen. You can invoke this screen by typing ‘PCDIFGEN’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

You can capture the following details in this screen:

Dispatch Type

Select the option from the drop-down list to indicate to whom you want to send the generated file. It can be send to the CSM or another bank. Files are sent to bank only for messages sent from direct participant to indirect participant or indirect participant to direct participant. The options available in the drop-down are:

Clearing Network

Select the clearing network for the dispatch file to be generated.

Service Identifier

Select the service identifier from the drop-down list. The options available are:

Bank Code

Specify the bank code for which the dispatch file is sent. This is enabled for ‘Bank’ dispatch type.

Account Number

Select the account number for which the dispatch file has to be sent. This is enabled only for ‘Customer’ dispatch type. If you want to generate dispatch files for every customer you can select the option ‘ALL’.

You can also select the CL account number as the customer account number.

Reference Number

This indicates the reference number entered for every dispatch run. This reference number is used to track the number of files generated as part of every dispatch run.

5.38 Payment Gateway Message Browser

This section contains the following topics:

5.38.1 Invoking the Common Payment Message Browser

You can handle the rejection (Pacs.002) transaction on all outgoing messages through Payment gateway Message Browser screen. This screen displays the payment status reports for which 'Reject Message' is enabled in the 'Common Payment Message Browser'.You can invoke the 'Payment Gateway Message Browser' screen by typing 'MSSPMTSR' in the field at the top right corner of the application tool bar and clicking the adjoining arrow button.

You can filter your search based on any of the following criteria:

Once you have set the filters you want, click 'Search' button to view the payment status report summary.

Click on 'View' button to view the complete details of received payment status report in a Common Payment Gateway detailed screen.

Click on 'Process Reject' to process the received payment status report. Once the payment status report is processed successfully the status is changed to 'Processed'.In case of failure during payment status report processing, the error reason will be populated with the corresponding error and the status will be changed to 'Repair'.

Click on 'Suppress' to suppress the received payment status report.Once the payment status report is processed successfully the status will be changed to 'Suppressed'. This button option can also be used to suppress the 'Repair' payments status reports.

Click on 'Retry' to retry the failed payment status reports which are in 'R' (Repair) status. Payment Status Reports that are failed during processing can be retried using this button option. Once the payment status report is processed successfully the status will be changed to 'Processed'.

Note that EOD Processing will stop if any received payment status report exists with status other than 'Processed' and 'Suppressed'.

5.39 Payment Gateway Message Bulks

This section contains the following topics:

5.39.1 Invoking the Payment Gateway Message Bulk Screen

You can maintain all bulk messages in the 'Payment Gateway Message Bulk' screen. To invoke this screen type 'MSSBLKBR' in the field at the top right corner of the application tool bar and click on the adjoining arrow button.

 

You can filter your search based on any of the following criteria:

Once you have set the filters you want, click 'Search' button to view the payment status report summary.

5.40 Payment Status Report

This section contains the following topics:

5.40.1 Handling Payment Status Report

You can process the received payment status report automatically or manually. You can process the payment status report for the following outgoing messages:

5.40.2 Processing Pacs.002 Messages (Payments)

The processing of Pacs.002 message received from Clearing Settlement Mechanism for SEPA Credit Transfer is as follows:

Pacs.002 for Outgoing Payments (Pacs.008) sent by Debtor Bank

Pacs.002 for Cancellation of Outgoing Payments (Camt.056) sent by Debtor Bank

Pacs.002 for Reject of Incoming Payments (Pacs.004) sent by Creditor Bank

Pacs.002 for Positive Response to Cancellation Requests (Pacs.004) sent by Creditor Bank

Pacs.002 for Negative Response to Cancellation Requests (Camt.029) sent by Creditor Bank

5.40.3 Processing pacs.002 messages (Collections)

The processing of Pacs.002 message received from Clearing Settlement Mechanism for SEPA Direct debit is as follows:

Pacs.002 for Outgoing Collections (Pacs.003) sent by Creditor Bank

Pacs.002 from Debtor Bank for Outgoing Collections (Pacs.003) sent by Creditor Bank

Pacs.002 for Cancellation of Outgoing Collections (Camt.056) sent by Creditor Bank

Pacs.002 for Reversal of Outgoing Collections (Pacs.007) sent by Creditor Bank

Pacs.002 for Pre-settlement Rejection of Incoming Collection (Pacs.002) sent by Debtor Bank

Pacs.002 for Rejection of Incoming Collection (Pacs.004) sent by Debtor Bank

Pacs.002 for Recall of Incoming Collection (Pacs.004) sent by Debtor Bank

5.40.4 Processing Re-activation Event

You can process the reactivation event to reactivate the contract from further processing after it has been rejected, cancelled, recalled or reversed. This is a system driven event and triggered when rejection is received for any of the following operations -

This event will revert the changes that were done as part of the post settlement rejection (REJT), pre-settlement rejection (RJBS), reversal (REVP) and recall (RECL) event processing.

5.41 Black List and White List of Creditors

Black List

You can restrict/allow incoming collection transaction to be processed based on Creditor Scheme ID, Creditor IBAN and combination of Mandate ID and Creditor Scheme ID, for a specific collection scheme type with Restriction Type as 'Disallowed' in 'Debtor Direct Debit Instructions'. Web services for Black List and White List of Creditors are available.

If Incoming Collection transaction for a Debtor matches with these maintained data, then the system moves the transaction to Transaction Repair (TR) queue.

Static data for error code 'PC-INDD-11' is available and auto rejection can be configured for this error code. If auto rejection is configured, then the system rejects the Incoming Collection transaction when details match with black list.

The system rejects the transaction in following scenarios:

White List

You can restrict/allow incoming collection transaction to be processed based on Creditor ID / Scheme ID, Mandate ID and Creditor IBAN for a specific collection scheme type with Restriction Type as 'Allowed' in 'Debtor Direct Debit Instructions'.

If Incoming Collection transaction for a Debtor does not match with these maintained data, then the system moves the transaction to Transaction Repair (TR) queue.

If restriction type is 'Allowed' and 'Creditor ID / Scheme ID', 'Mandate ID' and 'Creditor IBAN' are not maintained, then the system moves all incoming collections for the Debtor accounts to Transaction Repair (TR) queue.

Static data for error code 'PC-INDD-12' is available and auto rejection can be configured for this error code.

If auto rejection is configured then Incoming Collection transaction will be automatically rejected when does not match with white list.

The system rejects the transaction in following scenarios:

The creditor business code in Creditor ID / Scheme ID are not considered, while checking for Black List/White List of Creditors.

If Debtor Direct Debit Instructions are not maintained for a Debtor, then the system will allow all the incoming collection transactions for that Debtor.

5.42 Managing Mandate

This section contains the following topics:

5.42.1 Validating Mandate Existence for incoming collections

The system validates mandate existence for incoming collection of a SDD B2B scheme, if 'DD Agreement Required' check box at Customer Agreement maintenance is checked after receiving incoming collection.

If the mandate exists, then the system validates to match the transaction type as below:

The order of sequence type for the incoming collections transaction would be validated as shown in the following table.

SL.No.

Sequence Type of Incoming Collection

Amendment Indicator

Validation

Action on Failure case

1

FRST

False

To check whether this is the first collection transaction for the Debtor Man­date.

Transaction will be moved into Transaction Repair (TR) queue or auto rejected with the error code 'PC-SEQT-02'

2

RCUR

False

To check whether FRST has been received and processed successfully and FNAL has not received yet.

Transaction will be moved into Transaction Repair (TR) queue or auto rejected with the error code 'PC-SEQT-03'

3

FNAL

False

To check whether FRST and RCUR has been received and processed successfully and FNAL has not received already.

Transaction will be moved into Transaction Repair (TR) queue or auto rejected with the error code 'PC-SEQT-04'

4

FRST

True

To check whether sequence type is FRST if 'Identifica­tion' under 'Other' under 'Financial Institution Identifica­tion' is 'SMNDA'.

SMNDA stands for Same Man­date with New Debtor Agent'

 

Transaction will be moved into Transaction Repair (TR) queue or auto rejected with the error code 'PC-SEQT-05'

5

FRST

True

To check whether sequence type is FRST if 'Mandate ID' is changed.

Transaction will be moved into Transaction Repair (TR) queue or auto rejected with the error code 'PC-SEQT-06'

Static data for error code 'PC-SEQT-02', 'PC-SEQT-03', 'PC-SEQT-04', 'PC-SEQT-05' and 'PC-SEQT-06' are available.

If 'DD Agreement Required' is selected and Debtor Mandate for 'B2B' scheme doesn't exist, then the system moves the transaction to Transaction Repair (TR) Queue.

If auto reject mapping is configured, then system will automatically reject the incoming collection transaction.

5.42.2 Restricting Automatic Upload of Mandate

5.43 Expiry Date Processing

5.44 Maximum Amount per Transaction Restrictions

5.45 Maximum Amount per Calendar Year Restrictions

5.46 Number of Transactions Restrictions per Calendar Year