3.1 NEFT Outbound Transaction Input
This chapter contains the following sections:
l Section 3.1.1, "NEFT Outbound Transaction Input"
l Section 3.1.2, "NEFT Outbound Transaction View"
l Section 3.1.3, "NEFT Outbound Transaction Booking via Upload"
3.1.1 NEFT Outbound Transaction Input
You can perform NEFT Outbound transaction. All transactions that are entered using this screen has payment type as ‘NEFT” and transaction type as ‘Outbound’.
You can invoke ‘NEFT Outbound Transaction Input Detailed’ screen by typing ‘PTDOTONL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button. Click ‘New’ button on the Application toolbar
.
You can specify the following fields:
Transaction Branch
The system defaults the Transaction Branch code with the user’s logged in branch code.
Host code
The system defaults the Host Code of transaction branch.
Source Code
Select the Source Code via which the payment request is received. This LOV lists all source codes created in this host.
Network Code
The system displays the Network Code if only one Network is maintained with payment type as NEFT for the host code. If more than one networks are present, you can select the network code from the available list of values.
Transaction Reference
The system generates the Transaction Reference Number. For more details on the format, refer the Payments Core User Guide.
Note
This transaction reference number is passed in the UTR (Unique Transaction Reference Number) - tag 2020, in the NEFT messages.
Transaction ID
System generates the transaction reference number in specified format.
UTR Number
System generates UTR number for NEFT outgoing transactions in following format:
l 'N' + Julian Date + 10-digit unique Number.
Component |
Description |
Digits |
Position, Length |
Example |
Initial Character for NEFT |
It is always 'N'. |
1 |
1,1 |
N |
Date |
Julian Date (DDDYY) |
5 |
2,5 |
1-Sep-2022 = 24422 |
10-digit No |
Server ID - If clustered, each app server will have a number |
2 |
7,2 |
1 App Server = 01 |
Seconds - Seconds Elapsed past date change 1 Minute = 00060 Seconds 1 Hour = 03600 Seconds 24 Hours = 86400 Seconds Left Padded with 0s |
5 |
9,5 |
For e.g. If time is 18:00 as per the host date, then Seconds will be calculated as 64800. |
|
Sequence No - Sequential Serial Number generated per second Sequence |
3 |
13,3 |
For e.g., Seconds and Serial Number Representation for 5 Transactions processed @ 18:00 648000001 - 64800004 64800 - Seconds, 001 - Serial Number |
Related Reference
The system defaults Related Reference Number. However you can modify this.
Source Reference
The system defaults the Source Reference Number for the payment requests received from channels or any other source. You can input the value for manually booked transaction. The maximum length of this field accepts up to 35 characters.
Prefunded GL
Check this box to indicate that Pre funded payments are allowed for the source.
Click ‘Main’ tab to capture the Creditor/ Debtor/ Payments details:
Specify the following details:
Debtor Details
Debtor Account Number
Specify the debtor/ remitter account number. Alternatively, you can select the debtor account number from the option list. The list displays all open and authorized accounts as available in External Account Maintenance.
Debtor Account Type
You can choose from the below allowed values from this LOV. The values specified in the bracket is the account type code, that is passed in the messages.
l Savings Bank (10)
l Current Account (11)
l Cash Credit (13)
l Loan Account (14)
l Overdraft (12)
l NRE (40)
l Cash (50)
l Indo Nepal (51)
l Credit Card (52)
This field displays the text value for the account type. The corresponding number values appears in the NEFT payment messages generated.
Note
Once you select the ‘Indo Nepal Remittance’ checkbox, Debtor Account Type defaults to ‘51’ irrespective of Debtor Account is a customer Account or GL.
Debtor Name
System displays the Debtor Name for selected Debtor Account Number.
Customer No
Specify the Customer No.
Debtor Information
Select the Debtor Information from the following:
l SMS (Default)
l EML
Debtor Mobile Number
Specify Debtor Mobile Number. If 'Debtor Information' value is selected as SMS, then Mobile Number is mandatory.
Debtor Email ID
Specify the Debtor Email ID. If 'Debtor Information' value is selected as EML, then Email ID is mandatory.
Debtor LEI
System displays the Debtor LEI.
Beneficiary ID
If Beneficiary registration has been done already for the debtor’s account at PMDBENRN. The Beneficiary ID can be picked up from the LOV here. All the other details such as beneficiary account number, account type, beneficiary name, beneficiary bank details such as IFSC code, Bank name, Branch Name are defaulted based on the beneficiary registration maintenance.
If beneficiary ID is not maintained, Beneficiary Details viz., IFSC Code, Bank Name, Branch Name can be entered in the fields provided in this screen.
Beneficiary Bank Details
IFSC Code
All open and authorized IFSC codes available in local payments bank directory (PMDBKMNT) are listed in this field.
Note
IFSC code is validated based on the maintenances done in the Local Payments bank Directory screen. If the validation fails, transaction is rejected.
Bank Name
System defaults the Bank Name based on IFSC code selected.
Branch Name
System defaults the Branch Name based on IFSC code selected.
Beneficiary Details
Beneficiary Account number
Specify the valid Beneficiary account number, to which the amount is to be credited.
Beneficiary Account Type
Select the beneficiary/creditor account type from the drop-down values listed.
l Savings Bank (10)
l Current Account (11)
l Cash Credit (13)
l Loan Account (14)
l Overdraft (12)
l NRE (40)
l Credit Card (52)
This field displays the text value for the account type. The corresponding number values appears in the NEFT payment messages generated.
Beneficiary Name
Specify the Beneficiary/Credit Account Name for the account details specified.
Beneficiar LEI
System displays the Beneficiary LEI.
Payment Details
Booking Date
The system defaults the booking date as application server date.
Requested Value Date
You can select the Requested Value Date.
Value Date
The system defaults the current system date as value date. However you can select a future date as Value Date. Currency & Network holiday checks are applicable for Value Date.
Activation Date
Activation date is derived as Instruction Date – Debit Float days as maintained in Process cutoff maintenance. Holiday check is done for Activation date based on Branch holidays maintained if ‘Branch Holiday’ check is applicable for the Network maintained in the Payments Preferences screen (PMDNFTPF).
Transaction Currency
System defaults the Transaction Currency as ‘INR’ for NEFT payments.
Transaction Amount
You can enter the Transaction Amount. Transaction amount specified is validated with the daily and transaction limits maintained in the Payments Preferences screen (PMDNFTPF).
Remarks
Specify the Remarks.
Authorizer Remarks
System displays Authorizer Remarks.
Debtor Additional Details
Address Line 1 to 7
Specify the address.
Creditor Additional Details
Address Line 1 to 7
Specify the address.
Sender To Receiver Information
Sender To Receiver Information 1 to 7
Specify the information.
Purpose Details
Category Purpose Code
Select the Category Purpose Code from the following:
l EFT (Default)
l FCRA
l INDNPL
Pending Queue Details
Queue Code
System displays Queue details.
View Queue Button
Click this button to view Queue action details.
Enrich Button
Following validations are done, on clicking the Enrich button:
l System validates if the Debtor Account Type is NRE/NRO for the outbound transactions.
l The specified instruction date is validated for network holiday. if yes, same is moved to the next working date.
l If the Debtor account type is -NRE/NRO, the ‘Sender to Receiver Information field (from Line 1) is automatically populated with static text as “Sender is NRE. Please ensure compliance to RBI/FEMA regulation before applying funds”.
l If you select Beneficiary Account Type 'NRE' (40), then you must select Debtor Account Type also 'NRE' (40). Else system rejects the transaction.
l If you select Debtor Account Type 'NRE' (40), then you can select Beneficiary Account Type as any account from drop-down lists, such as Savings Bank (10), Current Account (11), Cash Credit (13), Loan Account (14), Overdraft (12), NRE (40), and Credit Card (52).
l System computes the Charges, and Tax on Charges if applicable, based on the maintenance for Pricing Code specified in India Payment Common Preferences (PMDNFTPF).
Instruction for Creditor Agent
Instruction Information
Specify the Instruction Information.
3.1.1.2 Additional Details Tab
This tab contains the below fields to capture the address details of debtor/creditor and remittance information from the sender to receiver.
Debtor Additional Details
Address Line 1 to Address Line 7
Specify the address.
Creditor Additional Details
Address Line 1 to Address Line 7
Specify the address.
Sender To Receiver Information
System populates the static text automatically on clicking Enrich button in the Sender to Receiver Information fields, if the Debtor account type is NRE.
Sender to Receiver Information 1-6
Specify the Sender to Receiver Information.
Indo Nepal Information
Beneficiary Identification
Specify the citizenship/ PAN card/ passport number of the beneficiary or 'X' if no information is available.
Beneficiary Contact Number
Specify the mobile or land line number of the beneficiary.
Commission
Specify the Commission/Charges depending upon the transaction amount.
NSBL Account Number
Specify the Account number of customer to be credited, if user is account holder in Nepal State Bank or 'X' if cash is to be disbursed.
Other Bank Account Number
Specify the Account number of customer to be credited, if user is account holder in other bank or 'X' if not available.
Other Bank Name
Specify the name of other bank or 'X' if not available.
Note
For Indo Nepal Information fields validation details, refer to Section 3.2.4, "Indo Nepal Remittance Processing".
Payment Type Information
Settlement Method
System defaults Settlement Method as CLRG.
Instruction Priority
System defaults Instruction Priority as HIGH.
Charge Bearer
System defaults Charge Bearer as SLEV.
Service Level Code
System defaults Service Level Code as SDVA.
Local Instrument Code
System defaults Local Instrument Code as TRF.
FCR Donor Details
These fields are disabled by default. Only when user selects the category purpose code as 'FCRA' then these fields gets enabled.
When these fields are enabled then Sender to Receiver Information line 1 to 6 and Indo Nepal Information fields gets disabled
Donor Name
Specify the Donor Name.
Donor Address
Specify the Donor Address.
Purpose of Remittance
Specify the Purpose.
Country of Donor, Currency and Amount
Specify the Country.
Instruction for Creditor Agent
Instruction Information
Specify the Instruction Information.
You can view the pricing details populated by system in this screen.
The following details are available:
Pricing Component
The system defaults the pricing component based on the Pricing code linked in Network Currency Preferences.
Pricing Currency
The system defaults the pricing currency.
Pricing Amount
The system defaults the pricing amount from Pricing Value Maintenance screen (PPDVLMNT) as applicable for the payment value date, Payment Source code and Debit Customer Service Model. However you can modify this value.
Note
Currency conversions related to charge computation are completed and final amount is populated component wise in the Pricing Tab.
Waiver
The system defaults the waiver. However you can modify this value.
Note
If charge/tax is already waived at price value maintenances, then you cannot uncheck the waiver flag.
Debit amount
System defaults the customer debit amount for charge/tax.
Click this link to specify the user defined fields.
Click this button to specify the MIS fields.
3.1.1.6 View Queue Action Log
You can view all the queue actions for the respective transaction initiated. You can invoke this screen by clicking the ‘View Queue Action’ button in View screen, where the Transaction Reference Number is auto populated and related details are displayed
.
Following details are displayed:
l Transaction Reference Number
l Network Code
l Action
l Remarks
l Queue Code
l Authorization Status
l Maker ID
l Maker Date Stamp
l Checker ID
l Checker Date Stamp
l Queue Status
l Queue Reference No
l Primary External Status
l Secondary External Status
l External Reference Number
You can view the request sent and the corresponding response received for each row in Queue Action Log.
Also you can view the request sent to and the response received from external systems for the following:
l Sanction screening
l External credit approval
l External price fetch
l Accounting system
3.1.1.7 Accounting Entries
You can click the “Accounting Entries” link in the transaction input screen to invoke the screen
.
The system displays the following details in a grid form that contains accounting entries in multiple rows for the Transfer amount, taxes and charges:
Transaction Reference Number
Displays the Transaction reference number.
Event Code
Displays the Accounting event code.
Account
The system displays the transaction account number that is debited or credited in the accounting entry.
Account Branch
The system displays the account branch.
TRN Code
The system populates the transaction code of the accounting entry from the Account Template maintenance.
Dr/Cr.
The system displays whether the accounting entry is ‘debit’ or ‘credit’ leg.
Amount Tag
The system displays the amount tag of the Amount being debited/credited.
Account Currency
The system displays the transaction account currency.
Transaction Amount
The system displays the transaction amount being debited/credited.
Netting
The system displays if Netting of accounting entries is required.
Offset Account
The system displays the Offset Account of the accounting entry for posting the offset debit/credit.
Offset Account Branch
The system displays the Offset Account Branch.
Offset TRN Code
The system displays the Offset Transaction Code from the Account Template maintenance.
Offset Amount Tag
The system displays the Offset Amount Tag of the Offset amount.
Offset Currency
The system displays the Offset Amount Currency.
Offset Amount
The system displays the Offset Amount being debited or credited.
Offset Netting
The system displays if the Offset Netting is required.
3.1.1.8 All Messages Tab
System displays the message and its details for the successfully processed transactions. Click the “All Messages” link in the View screen to invoke this sub-screen.
The system displays the following details in a grid form containing one or multiple rows for the Transaction Reference Number specified:
l Transaction Ref No
l Message Reference No
l Message Type
l Message Status
l Value Date
l Release Date
l Direction
l ACK/NAK Type
l Reject/Response Code
3.1.1.9 View Change Log
Click the View Change Log tab in Transaction Input screen and view the modified field values of the selected version number. The modified field values of the selected version against the previous version will be shown against the field names where field values got changed.
Below fields are displayed:
l Transaction Reference Number
l Version Number
l Mod Number
l Field Name
l Old Value
l New Value
3.1.1.10 Saving of Outbound Transaction
The system performs the following mandatory field checks and the referential checks during the save of NEFT Outbound payment transaction. If any of the below validation fails, then the transaction is rejected with an error code.
Following fields are mandatory for requesting NEFT Outbound payments:
l Transaction Branch
l Source Code
l Network code
l Source Reference (for requests received through other channels, Source reference is updated automatically)
l Debtor Account Number
l IFSC Code
l Beneficiary Account Number (creditor account)
l Beneficiary Account Type
l Transfer Currency
l Transfer Amount
l Debit / Credit Value Date
Following are the validations on clicking the ‘Save’ button:
– On the requests initiated from channels, Source reference number is expected as mandatory
– System validates whether account record is open and authorized.
– Holiday check for instruction date is done, based on the local branch holidays maintained.
– Upon saving the transaction, system throws error messages for validation failures, if any. For the error messages displayed, respective action can be taken and can be re-submitted.
3.1.1.11 NEFT Outbound Transaction Summary
You can view the NEFT outbound transactions booked in the transaction summary screen.
You can invoke the ‘NEFT Outbound Transaction Input Detailed Summary’ screen by typing ‘PTSOTONL’ in the field at the top right corner of the Application toolbar and clicking on the adjoining arrow button.
You can search for the records using one or more of the following parameters:
l Source Code
l Network Code
l Transaction ID
l Transaction Branch
l Transaction Reference
l Related Reference
l Source Reference
l Booking Date
l Instruction Date
l Activation Date
l Transaction Amount
l Debtor Account Number
l Debtor Account Type
l Beneficiary IFSC Code
l Beneficiary Account Number
l Beneficiary Account Type
l Transaction Status
l Queue Code
l Customer No
l Authorization Status
l UTR Number
l Indo Nepal Remittance
l Prefunded Payments
Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.
Double click a record or click ‘Details ‘button to view the detailed maintenance screen.
3.1.2 NEFT Outbound Transaction View
You can view the NEFT Outbound transactions in this screen.
You can invoke ‘NEFT Outbound Transaction Detailed View’ screen by typing ‘PTDOVIEW’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button
.
l From this screen, click Enter Query. The Transaction Reference field gets enabled which opens an LOV screen.
l Click the Fetch button and select the required transaction.
l Along with the transaction details, you can also view the Status details for the following:
– External System Status
– Transaction Status (Is updated as ‘Settled’ on receiving camt.059.001.06 acknowledgement message)
– Pending Queue Details
– Sanction Seizure
– Dispatch Details
– Credit Confirmation Details
l Click Execute Query to populate the details of the transaction in the Outbound NEFT Transaction View screen. The system displays all the fields in the below mentioned tabs based on the transaction reference number selected.
For more details on Main, Additional Details and Pricing tabs refer to ‘PTDOTONL’ screen details above.
3.1.2.1 Exceptions Tab
Click on the ‘Exceptions’ tab to invoke this screen. All the details pertaining to Return Details, Network Reject Details and External System Status id are displayed here for the entered Transaction Reference Number.
3.1.2.2 UDF Tab
You can invoke this screen by clicking UDF tab in the PTDOVIEW screen.
3.1.2.3 MIS Tab
You can invoke this screen by clicking MIS tab in the PTDOVIEW screen.
3.1.2.4 View Queue Action Log
You can view all the queue actions for the respective transaction initiated. You can invoke this screen by clicking the ‘View Queue Action’ button in View screen, where the Transaction Reference Number is auto populated and related details are displayed.
Following details are displayed:
l Transaction Reference Number
l Network Code
l Action
l Remarks
l Queue Code
l Authorization Status
l Maker ID
l Maker Date Stamp
l Checker ID
l Checker Date Stamp
l Queue Status
l Queue Reference No
l Primary External Status
l Secondary External Status
l External Reference Number
You can view the request sent and the corresponding response received for each row in Queue Action Log.
Also you can view the request sent to and the response received from external systems for the following:
l Sanction screening
l External credit approval
l External price fetch
l Accounting system
3.1.2.5 Accounting Entries
You can click the “Accounting Entries” link in the transaction input screen to invoke the screen.
The system displays the following details in a grid form that contains accounting entries in multiple rows for the Transfer amount, taxes and charges:
Transaction Reference Number
Displays the Transaction reference number.
Event Code
Displays the Accounting event code.
Account
The system displays the transaction account number that is debited or credited in the accounting entry.
Account Branch
The system displays the account branch.
TRN Code
The system populates the transaction code of the accounting entry from the Account Template maintenance.
Dr/Cr.
The system displays whether the accounting entry is ‘debit’ or ‘credit’ leg.
Amount Tag
The system displays the amount tag of the Amount being debited/credited.
Account Currency
The system displays the transaction account currency.
Transaction Amount
The system displays the transaction amount being debited/credited.
Netting
The system displays if Netting of accounting entries is required.
Offset Account
The system displays the Offset Account of the accounting entry for posting the offset debit/credit.
Offset Account Branch
The system displays the Offset Account Branch.
Offset TRN Code
The system displays the Offset Transaction Code from the Account Template maintenance.
Offset Amount Tag
The system displays the Offset Amount Tag of the Offset amount.
Offset Currency
The system displays the Offset Amount Currency.
Offset Amount
The system displays the Offset Amount being debited or credited.
Offset Netting
The system displays if the Offset Netting is required.
3.1.2.6 All Messages Tab
System displays the Outgoing pacs.008.001.09 message and its details for the successfully processed transactions. Click the “All Messages” link in the View screen to invoke this sub-screen.
The system displays the following details in a grid form containing one or multiple rows for the Transaction Reference Number specified:
l Transaction Ref No
l Message Reference No
l Message Type
l Message Status
l Value Date
l Release Date
l Direction
l ACK/NAK Type
l Reject/Response Code
Note
The system generates Message type 'DEBIT_ADVICE' along with 'Outgoing pacs.008.001.09'. This generation happens based on the ‘Customer Advice Preference’ (PMDCSADV) screen maintained per account & network combination.
3.1.2.7 View Repair Log
You can view all the Repair actions for the respective transaction initiated. You can invoke this screen by clicking the ‘View Repair Log’ button in View-screen, where the Transaction Reference Number is auto populated and related details are displayed.
You can View Repair Log details in this sub-screen. Following details are displayed:
l Queue Reference No
l Field Name
l Old Value
l Repaired Data
l Error
3.1.2.8 NEFT Outbound Transaction View Summary
You can view the summary in ‘NEFT Outbound Transaction View Summary’ screen. You can invoke the NEFT Outbound Transaction Summary screen by typing ‘PTSOVIEW’ in the field at the top right corner of the Application toolbar and clicking on the adjoining arrow button.
You can search for the records using one or more of the following parameters:
l Source Code
l Network Code
l Transaction Branch
l Transaction Reference
l UTR Number
l Related Reference
l Source Reference
l File Reference Number
l Message ID
l Transaction ID
l Booking Date
l Instruction Date
l Activation Date
l Transaction Status
l Debtor Account Number
l Transaction Amount
l IFSC Code
l Beneficiary Account Number
l Queue Code
l Dispatch Reference Number
l Prefunded Payments
l Customer No
l Prefunded Payments
l Indo Nepal Remittance
Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.
Double click a record or click ‘Details ‘button to view the detailed maintenance screen.
3.1.3 NEFT Outbound Transaction Booking via Upload
3.1.3.1 Single Payment Service
Oracle Banking Payments allows you to book the Outbound NEFT payments via Single Payout Service (SOAP/ ReST) and also via the Customer to Bank (C2B) pain.001 bulk file upload.
3.1.3.2 C2B File upload
Oracle Banking Payments allows to you to process the Outbound NEFT payment requests received in bulk payment files in pain.001 format from Corporate customers to banks(C2B). After validating the bulk file, the Outbound NEFT transactions are created and processed individually. All the transactions created based on the bulk file received are auto authorized.
NEFT transaction Network code is derived using Network Resolution Rule (PMDNWRLE) maintained for the Channel Type 'C2B'.
3.2 NEFT Outbound Payments Processing
Every NEFT outgoing payment transaction is generated as "pacs.008.001.09" outgoing NEFT payment message.
3.2.1 NEFT Outbound Payment Validations
Following processing changes/ initial validations are done as part of the transaction saving:
l Beneficiary ID Validations
l Mandatory Fields / Referential data checks
l Account Type Validations
l NRE Account Validations
l Processing Cutoff Check
l Intra Bank Transfer Check
For current dated transactions, following processing changes are covered during transaction authorization:
l Network Validations and Special Character Replacement
l Computation of Charge & Tax
l Exception Queue
l Authorization Limits Check
l Transaction cutoff time validation
l Sanction check
l FX Limit Check
l ECA check
l Network Cutoff time check
l Transaction Accounting
l Dispatch Accounting
l Future Value Dated Transaction
l Branch Holiday Parameter
3.2.1.1 Beneficiary ID Validation
l System validates the Beneficiary ID provided and populates the respective beneficiary details.
l Beneficiary Address Details maintained on Beneficiary Registration Detailed (PMDBENRN) screen.
l When you select valid Beneficiary ID while initiating Outbound payment, the Beneficiary Address Details are auto-populated to the ‘Creditor Additional Details’ section on the ‘Additional Details’ tab of the NEFT Outgoing Transaction Input Detailed (PTDOTONL) screen.
l The address details fields are still enabled for any edition even after the system defaults the address details.
l The ‘Creditor Additional Details’ fields remain enabled for edition if the beneficiary ID is not selected.
l Beneficiary Address Details are auto-populated to NEFT Outbound Transaction View (PTDOVIEW) screens when the ‘SSI_LABLE’ tag in SPS Service contains valid Beneficiary ID maintained in the system.
3.2.1.2 Mandatory Fields/ Referential Data Checks
l Validation of the IFSC Code is done as per the maintenance done in the Local Payment Bank Directory (STDBKMNT) and all the valid IFSC codes are maintained in this screen. Transaction is rejected in case of validation failure.
l Debtor Account Branch IFSC check
– This is derived based on the Branch and bank code mapped to the IFSC code in the STDBKMNT screen if maintained. This is also populated in the Outgoing pacs.008.001.09 message in the field:5756 (Sending branch’s IFSC)
– If the Debtor account branch IFSC (Field:5756) is not derived, then the transaction is moved to Process Exception (PE) queue.
l System validates the Debtor Account Type for outbound transactions. If the debtor account type is NRE/NRO, then the field (:6305 - Sender’s Account type) is updated with 40 or 10 respectively.
– If the Debtor account type is NRE(40) or NRO, then the Sender to Receiver Information field in the Additional Details tab in PTDOTONL screen is, automatically populated with a static text.
– This static message is displayed in the Outgoing pacs.008.001.09 message in the field: 7495.
l System validates the Transfer Amount, if it is within the Min/Max Transaction limit and Per day limit as maintained in the Payment Common Preferences screen (PMDNFTPF). If the transaction does not match the criteria, it is rejected.
3.2.1.3 Account Type Validation
l The system checks the Account Type Value present in the incoming channel requests for Debtor Account Type and Beneficiary Account Type.
l If you select any value other than the LOV available for Debtor Account Type and Beneficiary Account Type, the system rejects the transaction. The error message applicable is PM-MSG-005 'Debtor Account Type is invalid' or PT-TXP-017 'Beneficiary Account Type is invalid.'
l The Beneficiary Account Type field is optional. The system checks the Account Type restrictions validations for Beneficiary Account Type, only when Beneficiary Account Type value is present.
3.2.1.4 LEI Validation
Debtor LEI
l The LEI validation is are done, if the transaction amount is more than the LEI Threshold Amount maintained in India Payments Common Preferences (PMDNFTPF).
l The field ‘Debtor LEI’ is populated when the below conditions satisfy, and LEI validation is applicable:
– Debtor is a ‘Non-Individual’.i.e. Customer Type of the Debit account customer is not ‘Individual’.
– LEI is maintained for the Debtor in the India Payments Customer Preferences (PMDEXLEI) and the Value Date of the transaction is equal to (or) less than the LEI expiry date.
l An error is raised when all below-listed conditions satisfy, and LEI validation is applicable:
– Debtor is a ‘Non-Individual’ .i.e. Customer Type of the Debit account customer is not ‘Individual’.
– LEI is not maintained for the Debtor in the India Payments Customer Preferences (PMDEXLEI) or LEI is maintained but the Value Date of the transaction is more than the LEI expiry date.
Beneficiary LEI
l The Beneficiary LEI field is optional. If the user inputs a value, then the system checks the length of the value. If the length is not 20 characters, the system displays the error.
LEI Validation Failure
l In case of LEI validation failure:
– For manually booked transactions, the error message is shown on enrich user action.
– For uploaded transactions, the transaction is rejected outright.
3.2.1.5 NRE Account Validation
When you click the 'Enrich/Save' button, the system checks for the following NRE account type validations:
l If you select Beneficiary Account Type 'NRE' (40), then you must select Debtor Account Type also 'NRE' (40). Else system rejects the transaction with an error message PT-TXP-018 'If Beneficiary Account Type is NRE, then Debtor Account Type must be NRE.'
l If you select Debtor Account Type 'NRE' (40), then you can select Beneficiary Account Type as any account from drop-down lists, such as Savings Bank (10), Current Account (11), Cash Credit (13), Loan Account (14), Overdraft (12), NRE (40), and Credit Card (52).
3.2.1.6 Processing Cutoff Check
If Transaction Processing Time is greater than Processing cutoff time, then NEFT outbound transaction moves to Processing Cutoff Queue (PQSPRCUQ). All actions such as Release, Carry Forward, Cancel, Authorize, Delete are allowed.
3.2.1.7 Intra Bank Transfer Check
For Intra Bank Transfer Check the system checks the following:
l System checks if the beneficiary bank IFSC code is of the same bank branch. A ‘Branch’ record is present in the screen Branch IFSC Code Mapping 'PMDIFSBR' for the given IFSC Code.
l If a record is found in screen Branch IFSC Code Mapping 'PMDIFSBR' for the given IFSC Code, then the system checks the following:
– If the Intra Bank Transfer flag is ‘N’ the system gives an error message PT-TXP-023 ‘Intra Bank Transfer is not allowed'.
– If the ‘Intra Bank Transfer’ flag is ‘Y’ the system allows to process as ‘Outbound NEFT payment and generate Outgoing pacs.008.001.09 message for dispatch to Network even if beneficiary bank IFSC code is of the same bank branch.
3.2.1.8 Network Validations and Special Character Replacement
l IBAN check is not applicable for NEFT Outbound payments.
l Debtor Details, Beneficiary Details, Beneficiary Bank details, Additional Debtor/Creditor Details, Sender to Receiver Information entered for a payment transaction is validated against the valid characters allowed for the network.
l In case of Network character validation failure, transaction is moved to repair queue with error details.
l Permitted character set for NEFT Transfers are as below:
– Alphabetical characters - A to Z (upper case), a to z (lower case)
– Numeric characters - 0 to 9
– Special characters /-?:().,'+ space cr lf
– Special characters entered in a payment transaction are validated and replaced with specific characters as defined in Special Characters maintenance
3.2.1.9 Computation of Charge and Tax
Charge and tax for NEFT Payment transactions are calculated based on the Pricing Code specified in the India Payments Common Preferences screen (PMDNFTPF). Charges and tax are applied to the NEFT transactions based on the pricing code linked.
For current dated transactions, following processing changes are covered during transaction authorization.
3.2.1.10 Exception Queue
Exception Queue checks are applicable as per the functionality. For more details on these queues, refer to Exception Queues user manual.
3.2.1.11 Authorization Limit Check
Two levels of Authorization limit check is done before the process cut over check.
3.2.1.12 Transaction Cutoff Time Validations
Transaction cut off time validation is based on the Transaction Cut-off Time Maintenance (PMDCTOFF) screen. Transaction cutoff time check is done only for transaction with payment activation date is current date.
Transaction Cut-off time for the payment network and Transaction Type ’Outbound' is fetched from the maintenance for the following combination:
l Source - Specific/ALL
l Service Model - Specific/ALL
l Customer - Specific/ALL
Cut off time is derived as follows:
Sl.No |
Network |
Transaction Type |
Source |
CSM |
Customer |
1 |
Network ID |
Outbound |
Specific |
Specific |
Specific |
2 |
Network ID |
Outbound |
ALL |
Specific |
Specific |
3 |
Network ID |
Outbound |
Specific |
Specific |
ALL |
4 |
Network ID |
Outbound |
ALL |
Specific |
ALL |
5 |
Network ID |
Outbound |
Specific |
ALL |
ALL |
6 |
Network ID |
Outbound |
ALL |
ALL |
ALL |
If payment processing time is lesser than or equal to the Cut-off date time derived, then the payment is considered as 'Pre Cut-off' payment and proceeds with further processing.
If payment save date time or payment receipt date time exceeds the Cut-off date time derived then the payment is considered as 'Post Cut-off' payment and post cut off status is updated for the transaction.
The failed transactions are further moved to Process cutoff queue and the transactions can be processed further from this queue. For more details on queue, refer to Exception Queue user manual.
3.2.1.13 Sanction Check
If sanction screening is required for the Network and the customer, request is sent to External Sanction System.
If the sanction check status of the transaction is 'Approved', then further processing continues. If the contract's sanction check response status is 'Override' or 'Rejected' or 'Timed Out', then transaction is logged in 'Sanction Check Exception Queue’ and the processing of the transaction is stopped at this stage.
3.2.1.14 FX Limit Check
FX Limit Check and Currency conversion is not applicable for NEFT.
3.2.1.15 External Credit Approval Check
Debit accounting entries pertaining to payment amount and charge/tax amounts are sent to external DDA system for credit approval.
External Credit Approval is done for all the external accounts for which ‘External Credit Approval Required’ flag is enabled. ECA system for the credit check is derived based on the External Account maintenance.
If the ECA response status for a payment transaction is 'Approved', then further processing continues. If ECA validation fails i.e. the status is 'Override', 'Rejected', or 'Timed out', then the transaction is logged in ECA Exception queue.
3.2.1.16 Network Cutoff Time Check
The system checks the network cutoff time based on the cut off time maintained in Network Maintenance Detailed (PMDNWMNT) for the network. The system considers the application server time for cutoff time check. The system automatically roll-over the transactions that are not processed within the Network cutoff time and again calculates the Activation Date considering network holidays. These transactions do not move to Network cutoff Queue.
The unprocessed transactions in the queue are further moved to Warehouse queue. These transactions are processed as future value transactions from Warehouse queue and goes through all the transaction processing.
3.2.1.17 Transaction Accounting
Debit liquidation accounting entries have both payment entries and charge/tax entries. Accounting details are handed off to accounting system with debit/credit liquidation accounting code linked at Network Currency preferences. Following are the entries posted for the transactions booked:
Dr./ Cr. |
Account |
Value Date |
TXN_CCY |
Dr. |
Customer Account |
Debit Value Date |
Account Currency |
Cr. |
Intermediary GL |
Debit Value Date |
Transfer ccy |
Dr. |
Intermediary GL |
Credit Value Date |
Transfer ccy |
Cr. |
Clearing GL |
Credit Value Date |
Transfer ccy |
Accounting handoff is done after Network cutover check.
l Additionally, charge/tax related entries are handed off along with debit liquidation details as per existing process.
l On payment reject, the reversal entries are posted. However, charges are not reversed as per existing process
3.2.1.18 Dispatch Accounting
Dispatch accounting is applicable for NEFT outbound payments. System triggers the DCLG event on the dispatch of Outgoing pacs.008.001.09 bundle (as defined in No.of transactions per Dispatch). For all the transactions in the bundle, a single entry is posted with the sum of total amount and the no of transactions.
Accounting handoff is done as the DCLG event is triggered.
Dr./ Cr. |
Account |
Value Date |
TXN_CCY |
Dr. |
Clearing GL |
Debit Value Date |
Account Currency |
Cr. |
Network/Nostro Account |
Credit Value Date |
Transfer ccy |
3.2.1.19 Future Valued Transaction Processing
Future dated NEFT transactions are processed by separate jobs and run on receipt of the Start of Day (SOD, camt.052) Message.
The system identifies the transactions from the Warehouse queue. The transaction job picks up the future dated transactions with the Activation date equal to the current date and also it is equal to the SOD date of the latest camt.052 message received.
Processing of transactions is completed till sanction check on booking date itself. Transaction processing starts from initial validations again, on the activation date.
l NEFT Outbound payment rules allow the customers to send the payment requests with future value date. Such requests are processed by the system till sanction check on booking date and is marked as future valued.
l On value date future dated transaction job processes the payments starting from the initial validations. Future dated transactions are processed by separate jobs.
3.2.1.20 Branch Holiday Parameter
In addition to Currency and Network Holidays, Branch holidays is considered in determining the Value date and Activation date for, NEFT, payments.
Processing Branch holidays is considered in the Dates resolution only if a particular parameter in India Payment Common Preferences for the ‘Outbound’ or ‘Inbound’ transaction type is checked.
3.2.2 Outgoing pacs.008.001.09 Message Generation and Dispatch
l NEFT outbound transactions generates a ‘Outgoing pacs.008.001.09’ outbound payment message.
l As per the no. of transactions per dispatch maintained in Payments Common Preferences screen (PMDNFTPF), system bundles the no. of transactions and dispatches Outgoing pacs.008.001.09 message, once the defined number of transactions are met.
l On the time interval specified in the Dispatch maintenance, even if the no. of transactions are not met, residual messages are dispatched as bundle.
l The Outgoing pacs.008.001.09 messages in the bundle are dispatched /handed off to SFMS network for further processing.
l Upon successful processing of Outgoing pacs.008.001.09, dispatch accounting is generated and is handed off.
After receiving the camt.059.001.06 message successfully, notification is sent to the Originator (Debtor).
3.2.4 Indo Nepal Remittance Processing
The system does the following validations/processings once the user selects the ‘Indo Nepal Remittance’ check box:
l The system fetches the Beneficiary Bank IFSC and Beneficiary Account Number from the India Payments Common Preferences Screen (PMDNFTPF) and auto-populates the values on the input screen.
l The system disables the ‘Sender to Receiver Information’ fields and enables the ‘Indo Nepal Information’ fields under the ‘Additional Details’ tab.
l The system validates the transfer amount to check the maximum per transaction limit. In case this validation fails:
– For manually inputted transactions, screens display an appropriate error message.
– For uploaded transactions, the system rejects the transaction.
l The Indo Nepal Information six lines fields defined for Indo Nepal Remittance are mandatory and cannot be blank.
l When you click the Save button, the system validates Indo Nepal Information six lines fields, In case these fields are blank:
– For manually inputted transactions, screens display an appropriate error message.
– For uploaded transactions, the system rejects the transaction.
l The system validates and allows only numeric values in the Commission field. For any other value, the screen displays an appropriate error message.
3.2.5 Prefunded Payments Processing
l Customer number/debtor account number is not mandatory.
l If Debtor Account currency is not provided in the outbound request, then it gets defaulted to Transfer Currency (INR) in transaction.
l If the ‘Prefunded Payments GL’ check box is selected, the system skips the below processing:
– ECA check
– Pricing
– FX Limit Check
l The ‘Prefunded Payments GL’ is always used as Debit account while posting the debit liquidation entries. The ‘Prefunded Payments GL’ value maintained in the Source Maintenance (PMDSORCE).
LEI Validation Failure
l In case of LEI validation failure:
– For manually booked transactions, the error message is shown on enrich user action.
– For uploaded transactions, the transaction is rejected outright.
Sender To Receiver Information
Debtor LEI
l The LEI validation is done, if transaction amount is more than the LEI Threshold Amount maintained in India Payments Common Preferences (PMDNFTPF)
Beneficiary LEI
l The Beneficiary LEI field is optional. If the user inputs a value, then the system checks the length of the value. If the length is not 20 characters, the system displays the error.
Sender To Receiver Information 3-6
l At the NEFT payment type product processor level, system performs the below field length validation for the fields Sender To Receiver Information 3-6. If the below condition is matched, then that particular transaction is moved to Repair queue for user action.
– Condition: (The Entered Characters :xxx) Is exceeding the Maximum length Allowed 35.
3.3.1 NEFT Outbound Dispatch Browser
You can view the following outbound NEFT messages generated in this screen:
l N06 - Outbound Payment Transfer
l N07 - Return of Inbound Transfer
l N10 - Credit Confirmation for Inbound Transfer
l pacs.008.001.09 - Outbound Payment Transfer
l pacs.004.001.10 - Return of Inbound Transfer
l camt.059.001.06 - Credit Confirmation for Inbound Transfer
You can invoke ‘NEFT Outbound Dispatch Browser’ screen by typing ‘PTSOUTBR’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.
You can search for the records using one or more of the following parameters:
l Dispatch Reference Number
l Message ID
l Dispatch Date
l Dispatch Status
l Message Type
l Linked Message Id
l Batch Number
Following sub screens/ actions are available in the message browser screen:
View Message
Select a record and click on ‘View Message’ button to view the dispatched message.
View Accounting
Select a record and click on ‘View Accounting’ to view the Dispatch accounting details for the Outgoing pacs.008.001.09 and pacs.004.001.10 message generated.
System displays the DCLG event and its respective accounting entries passed during the Outgoing pacs.008.001.09 and pacs.004.001.10 dispatch. Single entry is posted for the bundle dispatched, with total sum of amounts. Entries posted are - Dr. Clearing GL and Cr. Network/ Nostro account.
In case of auto reversals (for SFMS NAKs such as F25 and F26) of the Outgoing pacs.008.001.09 dispatched, system displays the reversal accounting entries of DCLG.
Note
Dispatch accounting is not applicable for camt.059.001.06 messages.
View Transaction
Select a record and click on ‘View Transaction’ to view the complete transaction details. View Summary screen is launched on clicking ‘View Transaction’.
You can double click the record or select a record and click on ‘Details’ button to view the detailed transaction screen. System launches the NEFT Outbound View Detailed screen (PTDOVIEW).
View ACK/NAK Message
You can view the F20, F25, F26, F27 ACK/NAK messages received and matched for the corresponding Outgoing pacs.008.001.09 dispatch.
Process NAK
Process NAK option helps to validate the negative acknowledgement and perform appropriate action like reverse or regenerate the transaction.
You can click the 'Process NAK' option to launch Negative Acknowledgement Processing Details screen.
Retry Dispatch
On clicking Retry Dispatch button, NEFT Dispatch Retry sub screen is displayed.
On Retry action, error records are re-processed.
3.3.2 Negative Acknowledgement Processing Details
You can view and process the underlying payment for F25/F26/F27 NAK received from RBI.
You can invoke ‘Negative Acknowledgement Processing Details’ screen by typing ‘PTDNAKPR’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.
Following fields are auto populated:
l Business Message Identifier
l Bank Application Identifier
l Originating Branch IFSC
l Error Code
l Received Date
l NAK Type
You can perform following actions:
l Regenerate Messages
l Reject Messages
l Authorize
l Delete
l View Queue Action
3.4 NEFT Acknowledgment Processing
3.4.1 SFMS ACK/NAK Messages Processing
System supports the processing of following messages:
Message |
Message Description |
F23 |
This is a Delivery Notification message. |
F20 |
This is an acknowledgment message from SFMS. |
F25 |
This is a Negative acknowledgment message from SFMS. User can take manual action on outgoing payment transaction. |
F26 |
This is a Negative acknowledgment message from SFMS user. User can take manual action on outgoing payment transaction. |
F27 |
This is an acknowledgment message from Bank API (IDRBT/RBI). . If this message is Negative Acknowledgment then user can take manual action on outgoing payment transaction. |
F29 |
This is Delivered At NEFT. This is ISO migration to notify about the delivery of message. This message supports in both format - ISO and IFN. |
Processing Steps:
ACK Processing:
On receipt of incoming F20/F27 ACK messages from SFMS, system parses the message and process. The parent transaction is fetched based on following matching fields: (Note: F20/F27 ACK is received for the Outgoing pacs.008.001.09 messages sent in a bundle of 10)
l Matching:
– External Application Sequence number mentioned in the F20/F27 message is matched against the sequence number sent in the original outgoing payment transaction/message (Outgoing pacs.008.001.09) in Business Application Header header and the IFSC Code of the Originating branch (Our IFSC Code).
l Message Status Update: If matched,
– For F20 (Message Identifier in the format) received, original outgoing payment gets updated
– I.e, All the ‘10’ transactions sent in the Outgoing pacs.008.001.09 bundle having the same sequence number is updated
l For F27 (Message Identifier in the format) received,
– System checks the ‘Bank API Response Code’ field
– I.e, All the ‘10’ transactions sent in the Outgoing pacs.008.001.09 bundle having the same sequence number is updated.
NAK Processing:
On receipt of incoming F25/F26/F27 NAK messages from SFMS, system parses the message and process. The parent transaction is fetched based on following matching fields: (Note: F25/F26/F27 ACK is received for the Outgoing pacs.008.001.09 messages sent in a bundle of 10)
l Matching:
– External Application Sequence number mentioned in the F25/F26/F27 message is matched against the sequence number sent in the original outgoing payment transaction/message (Outgoing pacs.008.001.09) in Business Application Header header and the IFSC Code of the Originating branch (Our IFSC Code).
Manual action and Message Status Update: If matched,
l System waits for user action to be taken from the new screen – Negative Acknowledgement Message Details. Screen PTSFNAKQ will no longer be used and removed from the system.
l Below steps are performed form new screen - Negative Acknowledgement Message Details.
– User will select the Outgoing pacs.008.001.09 single record from PTSOUTBR and click ‘Process NAK’ option. In case, multiple records are selected and ‘Process NAK’ option is clicked then system throws an error.
– System opens the Negative Acknowledgement message details screen.
– Transaction Details section of the screen lists out the transactions bundled in the original Outgoing pacs.008.001.09 message. By default, all the messages are selected. So, the manual action is applicable for all the underlying transactions in the Outgoing pacs.008.001.09 bundled message.
Reversal Dispatch Entries
Dispatch Reversal Accounting for NEFT Outbound |
Event |
Dr/Cr |
Account |
Account Type |
Amount Tag |
NEFT Outbound |
DCLG |
Dr |
Nostro Account |
Account |
FILE_AMT |
NEFT Outbound |
DCLG |
CR |
Network Clearing GL |
GL |
FILE_AMT |
Reversal Individual Entries
Dispatch Reversal Accounting for NEFT Outbound |
Event |
Dr/Cr |
Account |
Account Type |
Amount Tag |
NEFT Outbound |
DRLQ |
Dr |
Network Clearing GL |
GL |
XFER_AMT |
NEFT Outbound |
DRLQ |
CR |
Intermediary GL |
GL |
XFER_AMT |
NEFT Outbound |
DRLQ |
Dr |
Intermediary GL |
GL |
XFER_AMT |
NEFT Outbound |
DRLQ |
Cr |
Customer Account |
Account |
XFER_AMT |
3.4.2 Credit Confirmation ACK Message - camt.059.001.06 Processing
The beneficiary (Creditor) bank sends a positive acknowledgement message (camt.059.001.06) to the Remitter (debtor) bank, upon the successful credit to the beneficiary for the outbound payment. The Inbound camt.059.001.06 credit acknowledgement received, has the bundle of outbound transactions grouped in a single message.
Following details are updated, upon receiving the successful camt.059.001.06 credit acknowledgement message:
l ‘Transaction Status’ field in the NEFT Outbound Payments view screen (PTDOVIEW) is updated as ‘Settled’.
l System updates the value ‘Credit Confirmation Details’ for the respective outbound transactions with - camt.059.001.06 Message Reference, Credited Date and Credited Time.
l Success notification for the acknowledgement received for outbound transactions can be viewed in the Notify Message Details screen (PMSNOTFY).
l And the camt.059.001.06 generated and the message details can be verified in the NEFT Inbound Message Browser (PTSINBRW).