Oracle Banking Payments supports processing of bulk files received from corporate customers containing mixed workload in ISO pain.001 format. Payment request can be for any of the following payment types:
You can upload and process files received from corporate customers containing bulk payment initiation requests in pain.001 format.You can maintain customer preferences for bulk file handling. Bulk files are parsed, validated and processed so that payments are forwarded to appropriate Networks.
Bulk files can be processed in two ways:
Net Accounting
Bulk files are processed by consolidating the transactions into batches based on Network, Debit Account, Value Date, Transfer Currency and Charge Account. Debit Accounting is done on Net basis i.e. considering only the successfully processed transactions.
Gross Accounting
In this method, batch amount is blocked in the debit account upfront during file processing. The rejected payments are be reversed individually, once the consolidated debit posting is done
This chapter contains the following section:
You can use customer preferences screen for maintaining file preferences for corporate customers.
You can invoke the ‘Customer Preference’ screen by typing ‘PMDFLPRF’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button. Click new button on the Application toolbar..
You can specify the following fields:
Charge Claim Preference
Charge claim payment account
Check this box to facilitate selection of Customer Account or Default GL.
Account Option
Select the required Account Option from the drop down. The options are Customer Account and Default GL.
Note
If Default GL option is selected, then you must specify a GL code.
Account Option
Specify the GL Code from the LOV.
Batch Preferences
Batch Processing Required
Check this box to allow the consolidation of debit entries. If left unchecked, all the transactions gets processed as individual transactions in the batch.
Note
If Batch Booking preference is provided in the received C2B File, then that takes precedence over the Customer Preference. If batch booking preference is not received in the file, the Customer Preference maintained for the Debit Account Customer is used.
Batch Auto Closure
Check this box to allow consolidation batch being specified automatically for closure after the ‘Wait Time for Batch Closure’ maintained.
Debit Preference
Select the below debit preference options from the drop down.
Gross Accounting: The amount block done for the batch total amount upfront and in case of failed transactions, reversal entries are posted individually.
Net Accounting: If this option is selected consolidation for debit amount happens based on Debit Account, Value Date, Transfer Currency, Network and Charge Account. Debit posting is done for the successfully processed transactions.
Batch Processing Cutoff Hour
Specify the Batch Process Cutoff time in hours.
Batch Processing CutOff Minute
Specify the Batch Process Cutoff time in minutes.
Move Forward After Cutoff Time
Check this box to enable the request date to move forward to the next business day based on branch working days.
Wait Time for Batch closure (In Hours)
Specify the wait time in hours. This is mandatory if the auto closure of batch is preferred.
Price Preference
Select the required price preference from the following options:
Flat charge: This option is a fixed price. Hence value maintained for the price code is applicable for the Batch.
Transaction Count: Choose this option if price value is multiplied with the number of transactions received in the batch to get the batch level pricing. The price value is maintained as a fixed amount in this case.
Batch Amount: Choose this option if the price value is maintained as a rate in this case. The rate is applied on the batch amount.
Note
Specify the Network source as ‘C2B in the Price value maintenance screen- PPDVLMNT’.
Market Price Code
Select the Price Code for batch pricing from the list of values.
Pricing Account
Choose the required Pricing Account from the list of values.
FX Limit Currency
Select FX limit currency for fetching the applicable internal rate from the list of values.
Batch FX Limit
Specify the FX limit amount for fetching rate and validating limit.
External Rate Applicable
Check this box to send the transaction for fetching rate.
The transaction is sent to External system for rate fetch, if the batch amount is beyond FX limit maintained and if ‘External Pricing’ is checked.
Note
If the pricing account is mentioned in the pain.001 file received, it takes precedence. If charge account is not available as part of the file, then pricing account maintained in file preferences is considered for debiting charge/tax amounts. If pricing account is not maintained, charge/ tax is recovered from debit account itself.
You can use different price account if Net accounting is preferred.
Jobs are provided for uploading the customer files. The system generates file reference number. The transaction details received in a single file can be identified by file reference number.
The system performs branch, network, value date & Account resolutions for each payment request received.
Debtor agent BIC of the first debtor account details present in pain.001 message is considered for deriving the transaction branch.
Network is resolved based on the Network Rule defined for the Host. Payment type is derived as payment type linked to the network and Transaction type is derived as ‘Outgoing’.
Requested Execution Date in pain.001 message is considered as instruction date from customer. Instruction date is stored for the transaction.
Payment details will be sent to Payment type specific processing based on the payment type linked to the Network. Default source code for payments initiated by Bulk files is C2B.
Following processing steps are followed for different payment types based on applicability in the respective process flow:
Note
Charge/Tax Calculation is done at individual transaction level using pricing code linked in network currency preferences.
System parses the bulk file received in pain.001.001.06 format. The system performs the below data checks.
A file can contain multiple batches and each batch can have a debit account.
Execution date of each batch is validated to find whether it falls on a Branch holiday or it is a back date. If it is backdated, it is moved to current date. If it falls on a holiday, the execution date is moved to the next/ previous branch working day based on ‘Holiday Treatment for request date’ preference maintained for the customer. Original request date is stored for the batch.
Batches are created with distinct consolidation reference number, based on the below consolidation parameters:
On completing individual transaction processing till sanction check for all the transactions in a batch, system proceeds with below mentioned processing steps for the batch:
Note
You can view the pending batches from Batch Booking queue
The system follows the below steps for Cutoff Check for the batches.
If payments belonging to the batch are pending in Exception queues as part of individual transaction processing, system does not initiate auto batch closure. In such cases, you can maintain wait time for auto closure preference for the customer, based on which system initiates batch closure of processing completed payments.
For example, if a file contains payments with high volume and a few transactions are held up in Sanctions Queue, then auto batch closure feature based on wait time will enable closure of already processed payments.
Note
You can check ‘Batch Auto closure’ field in the Customer Preferences (PMDFLPRF) screen to initiate auto closure of consolidation batch based on the wait time maintained. Auto closure of batches happens after the waiting time mentioned in Customer preferences.
During the specified cut-off time, the system will automatically close all the batches that are in ‘W-Work in progress’ status after delinking the payments pending in exception queues.
Transactions pending in exception queues create a new batch in exception status with the same file number.
If the Debit preference selected is Gross Accounting, the following processing steps are done for the batches upfront if the batches are not future valued:
Internal rates are fetched for the batch if the batch amount is below the FX limit maintained in customer preferences. If batch transfer currency is different from the limit currency maintained, the batch amount is converted to limit currency amount using the mid-rate between the currencies.
If the batch amount is more than limit amount, the batch details are sent for External rate fetch if External Rate fetch is applicable for the customer.
The FX reference returned by the external system is stored for the batch.
After the FX conversion, the total batch amount is computed includes the batch charges, if any. The total amount along with other payment details is sent to DDA system for Customer/account validation, balance check and amount block in debit account.
On completing the amount block successfully for batch, Network is derived for each payment record based on the Network Rules maintained.
Each payment is sent to the respective processor for further processing. The following processing steps are completed for each payment:
Note
It is possible to process sanction seizure for an individual transaction. Credit accounting is to seizure GL in such cases. Messaging is not applicable. Final status of seized transactions is marked as ‘Success’.
The individual payment processing completion shows the payment status as success or error.
When all the payments are completed, individual processing and final status is updated. Th e system does the consolidate debit handoff to the Accounting system.
If the wait time for batch closure maintained in the Customer preferences and the cutoff time get over, then the debit entry handoff is done for the batch amount.
All error transactions/future valued transactions in the batch are reversed individually.
In case of Flat charge, no charge reversals are done. In case of transaction based charges, pro-rated reversal is done.
A new consolidation batch is created with the future valued transactions with the same Batch ID and is moved to future warehousing queue.
Every payment record received in the bulk file is processed as an Individual transaction if batch processing is not enabled in customer preference screen.
The Network is derived first based on the Network Derivation Rule maintained for each record. Each transaction is sent for processing to the respective payment processor of the payment type linked to the Network.
The processing of the payment is similar to an individual payment processing and the following are the processing steps involved.
Itemized accounting is supported only in case the Debit Preference chosen is Gross Accounting.
If requested execution date received/derived is in future, the Network derivation for the transaction is done first and the following processing is completed on booking date:
Batch is moved for future warehousing. On requested execution date, future dated batch picks up those batches and again processes from the beginning. Validations and sanction check are done for the transactions.
This section contains the following topics:
You can view the payment initiation requests received by the payment system for a specific file reference number. All consolidation batches available for a file can be viewed from the Batch Booking queue.
You can invoke the ‘Batch Booking Queue’ screen by typing ‘PQDBATQU’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button.Click new button on the Application toolbar.
If you click on 'View Batch Payments' button in batch booking queue, you can view individual transactions
The following actions are allowed in the Batch Booking queue:
Actions | Function | ||||
---|---|---|---|---|---|
Manual Closure | Batch closure can be manually initiated using this action. | On manual closure, system delinks transactions pending in exception queues from the parent batch. A new exception batch is created for the pending transactions. The parent batch is closed and consolidated debit entry is passed for successful transactions. | If a batch is closed, then no further action is possible. This does not require authorization. | ||
Cancel | This option will enable to cancel the consolidation batch. On cancellation, the file consolidation status and Transaction status becomes 'C' - Cancelled. User can choose only single batch for cancellation. File consolidation status as W alone can be cancelled. If the batch is already cancelled, then no further action can be taken. Authorization is supported for this action. | ||||
Authorize | Cancel operation initiated by a user can be authorized by another user |
You can invoke the ‘Batch Booking Queue Summary’ screen by typing ‘PQSBATQU’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button.Click new button on the Application toolbar.
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:
When you click ‘Search’ button the records matching the specified search criteria are displayed. For each record fetched by the system based on your query criteria, the following details are displayed:
The Customer Payment Status Report message is exchanged between an agent and a non-financial institution customer to provide status Information on instructions previously sent using pain.001.
The following status codes are supported while doing pain.002 generation:
Corporate File Browser Screen is provided for users to view all the received pain.001 files. Batch IDs received in the file are stored for each batch processed and is available as a transaction level information for view and query.
You can invoke the ‘Corporate File Browser Summary’ screen by typing ‘PMSUPDST’ in the field at the top right corner of the application toolbar and clicking 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:
When you click ‘Search’ button the records matching the specified search criteria are displayed. For each record fetched by the system based on your query criteria, the following details are displayed:
You can invoke the ‘Corporate File Browser’ screen by typing ‘PMDUPDST’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button.Click new button on the Application toolbar.
Query the details by entering the File Reference Number.The file details are displayed by the system on executing the query.
The following are the highlights of batch processing with gross amount block and net accounting:
A new maintenance is available for Batch Processing Preferences. This is a Host level maintenance.
You can invoke the ‘Batch Processing Preferences’ screen by typing ‘PMDBTPRF’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button.Click new button on the Application toolbar.
Specify the following fields:
Host Code
The system displays the Host Code of the logged in branch by default when you click on New.
Wait Time for Batch processing (in minutes)
If some transaction within a batch are pending for processing, Batch closure is initiated by system by delinking the pending transactions. This is done after a specific time period from the time of receipt of the file. In the new field ‘Wait Time for Batch Closure’ the time period can be entered in minutes.
Batch Duplicate Check Days
This preference is considered while doing the batch level duplicate check of bulk files. Enter the number of days.
If the number of days is maintained as 0, no duplicate check is performed.
Job Execution Interval in minutes
Pending Batch Job
Specify the Job Execution Interval in minutes for the Pending Batch Job.
Warehouse Pending Batch Job
Specify the Job Execution Interval in minutes for the Warehouse Pending Batch Job.
Network Code
Specify the Network Code in the multi grid block.
Cutoff Time for Batches
Specify the Cut off time in HH:MM format.
Network Cutoff
The system displays the normal cutoff time based on the Network Maintenance.
You can invoke the “Batch Processing Summary” screen by typing ‘PMSBTPRF’ in the field at the top right corner of the application toolbar and clicking 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:
When you click ‘Search’ button the records matching the specified search criteria are displayed.
System parses the bulk file received in pain.001 format. File format checks, Number of transactions (both file & batch level) & control sum checks are done at this stage. Control sum as available in the Group header (file level) & PaymentInformation <PmtInf> (batch level) is considered for the check. Since these are optional fields, if the tag is not available for the file / batch, this check will be skipped.
All transactions in a batch should be have the same transfer currency. System rejects the file, if this validation fails.
Each batch undergoes the following checks:
In case of exceptions batch is moved to process exception (PE) queue. Batch can be reprocessed from the Process Exception queue or can be cancelled.
This will be done based on the following parameters:
Duplicate days is considered based on the information available in Batch Processing Preferences
Debit Account Status à Dormant, No Debit
Note
Network resolution is done for each payment record within a batch. This is based on the rules defined in Network Rule maintenance PMDNWRLE. Based on the linked payment type, payments are marked as urgent or Non-urgent payments.
Urgent payments are not processed as batches. Each payment record in the batch is processed as an individual record.
Non –urgent payments are processed as batches irrespective of the Batch booking tag value in the incoming batch.
If the Network resolution fails, the transaction is moved to Network Resolution Queue. From this queue Network ID is provided manually.
For Batches where Batch booking is applicable, re-grouping of the payment requests are done based on the following parameters:
New consol reference is generated for each re-grouped batch. Original Batch ID is retained if there is only one batch after re-grouping.
Further processing is done at the re-grouped batch level.
The requested execution date for all transactions within a batch is same and this date is considered as the instruction date. Activation date is derived based on the instruction date.
Debit currency / Credit currency / Network holiday checks is applied to Instruction date as applicable for the payment type. Branch holiday check is done on the activation date if the same is applicable for the Network.
After deriving the dates, if the activation date falls on current date, process cut off check is done for the batch based on the cutoff time maintained in customer preferences (PMDFLPRF).
If cutoff time is over, the request date is moved forward automatically if ‘Move Forward after Cutoff Time’ flag is checked in customer preferences. Otherwise, the batch moves to Process Cutoff Queue.
Release, cancel options is available for the batch from Process cut off queue.
For current dated batches, exchange rate fetch is done. Internal rates is fetched for the batch if the batch amount is below the FX limit maintained in customer preferences. If batch transfer currency is different from the limit currency maintained, the batch amount will be converted to limit currency amount using the midrate between the currencies.
If the batch amount is more than limit amount, the batch details are sent for External rate fetch if External Rate fetch is applicable for the customer. If FX reference number is available as part of the payment request, the same is sent to external system.
If no FX reference is available in the request and if the FX reference returned by the external system, the same is stored for the batch.
The total batch amount along with other payment details is sent to DDA system for Customer/account validation, balance check and amount block in debit account.
If the amount block is a success, the ECA reference received is stored for the batch and the individual payments in the batch are sent to the payment processor for further processing.
If a batch is released from ECA queue on a later date, rollover preference for queues is applied based on Outbound Non-urgent Payment Preferences maintained for the source, Co-ID and debit account.
Rollover preference can be Auto Roll, Cancel or Retain in Queue.
If cancellation is done, FX unwind request is sent.
The following processing steps are completed for each payment:
Since the status validations for customer/debit account are already done at batch level, this is not be repeated again while processing individual transactions for current dated batches. For book transfers, credit account status validations are done.
It is possible to process sanction seizure for an individual transaction. Credit accounting will be to seizure GL in such cases. Messaging is not be applicable.
If a charge account is provided in the payment request the same is used for debiting the charges. If not available in the request the charge account maintained in customer preferences PMDFLPRF is used as debit amount for charges. If no preference is available transaction debit account is the charge account as well.
No amount block is done for charge accounting. Charges are force posted.
The individual payment processing completion updates status of payment as one of the following:
OR
Wait time maintained is 2 hours and Host network cutoff is @3.45
OR
For each cancelled transaction, FX unwind request and Amount block reversal request is sent immediately on cancellation. This is processed at individual transaction level.
Every cancelled transaction for current date within a consolidation batch is part of the same reject batch. This reject batch form a place holder for all cancelled transactions, though processing is not batch -wise.
If any transaction is moved to ‘Seized’ status from Sanction Queue during individual processing, a separate seized batch is created. Every seized transaction for current date within a consolidation batch is part of the same seized batch.
Whenever successful transactions are send for processing generating a new batch, the pending transactions will remain in the original batch.
The pending batch will be checked again for successful transactions at regular intervals. This will be achieved by configuring a job which can be run at pre-defined intervals. The time interval can be set in minutes.
The check for successful transactions will continue till the Host Network cutoff time is reached.
Future dated batches are processed till sanction check on booking date itself.
On value date, based on booking date processing, a separate batch is created for successful transactions. This batch is considered for value date processing.
FX and amount block are done and transactions are sent for individual payment processing. The rest of the process flow remains same like a current dated batch.
The new job runs in regular intervals re-checking the transaction status of the transactions in the pending batches. The monitoring interval can be configured in minutes in Payments Auto Job Parameters (PMDAJBPR).
Note
For carried forward batches it is required to be checked whether FX or ECA is already done. If done, the undo request for old amount will be included in the new request sent on value date.
The customer is informed about the status of the payments by generating pain.002 messages.
If the file is rejected due to format issues, pain.002 is generated for the file. OriginalGroupInformationAndStatus <OrgnlGrpInfAndSts> tag is updated with the status RJCT (Rejected). Since the entire file is rejected, individual payment information will not be populated.
In all other cases the generation of the message is original Batch ID–wise.
pain.002 messages are generated if all the transactions in a batch are marked with final status, success, cancelled or seized.
If any transaction in a batch is remaining pending, then the pain.002 is generated during end of day based on a new job.