23. Generic Wires ISO Interbank Direct Debit pacs.010
The Interbank Direct Debit (pacs.010) is used to collect funds from a debtor account for a creditor, where both debtor and creditor are financial institutions.
23.1.1 Inbound Interbank Direct Debit Transfer View
You can click the “View Inbound pacs.010” button on the Inbound MT204 Message Browser (PXD204BR) to invoke the Inbound Interbank Direct Debit Transfer View (PSD010VW) screen displaying the details of incoming pacs.010 message.
l The system displays an error message if the selected transaction is MT204 and you click “View Inbound pacs.010” button.
l Refer to Cross Border User Guide for details about Inbound MT204 Message Browser (PXD204BR) screen.
23.1.1.1 Main Tab
You can invoke this screen by clicking ‘Main’ tab at the Inbound Interbank Direct Debit Transfer View screen.
23.1.1.2 Processing Details
You can invoke this screen by clicking ‘Processing Details’ tab at the Inbound Interbank Direct Debit Transfer View screen.
This section contains the following sub-sections:
l Section 23.2.1, "Message Upload and Parsing (TARGET2)"
l Section 23.2.2, "Message Upload and Parsing (CBPRPlus)"
l Section 23.2.3, "Credit Instruction Processing"
l Section 23.2.4, "Direct Debit Transaction Information Processing"
l Section 23.2.5, "Outbound Pacs.002 Message Generation"
23.2.1 Message Upload and Parsing (TARGET2)
l The incoming pacs.010 message is logged in the Incoming Message Browser (PMSINBRW).
l You can view the incoming message status from Inbound Browser Summary (PMSINBRW) screen.
Note
For Target2, no further processing is done in the system.
23.2.2 Message Upload and Parsing (CBPRPlus)
l The incoming pacs.010 message is logged in the Incoming Message Browser (PMSINBRW).
l You can view the incoming message status from Inbound Browser Summary (PMSINBRW) screen.
l The system do the format validations for received incoming Interbank Direct Debit (pacs.010) message based on the schema details maintained for the message in File Parameter Detailed (PMDFLPRM) maintenance.
l After completing the format validations, the incoming Interbank Direct Debit (pacs.010) message is parsed and uploaded in Inbound MT204 Message Browser Summary (PXS204BR) screen.
l You can select a record from MT204 browser summary screen and double click it to view the details for the selected record with Sequence A and Sequence B details on Inbound MT204 Message Browser (PXD204BR) screen. Sequence A details can be viewed in first block and the sequence B details can be viewed in the second block.
23.2.3 Credit Instruction Processing
l For each Credit Instruction (/Document/FIDrctDbt/CdtInstr) received in an incoming pacs.010 message, Sequence A transaction entry get created.
l The source code for the incoming transaction is derived based on the Source code Maintenance (PMDSORCE). The source code for which the ‘Incoming SWIFT’ flag is checked is considered as the source code for the Incoming pacs.010 message.
l The following processing is done for the Sequence A (Credit Instruction) records:
Duplicate Check Validation
– Credit Identification (/Document/FIDrctDbt/CdtInstr/CdtId) is validated to check if another transaction with same Credit Identification is already present in the application.
– In case if another transaction with same Credit Identification is already present in the application, then transaction is treated as duplicate transaction and moves to Business Override Queue.
Agreement Check Validation
– Agreement validation at sequence A level is done for the Sender BIC (i.e., /AppHdr/Fr/FIId/FinInstnId/BICFI).
– The system verifies if an agreement is maintained for Sender BIC. First, the system checks the 11-character BIC. If BIC is not found, the system checks for 8-character BIC.
– If the agreement is unavailable the transaction moves to the Business Override queue.
23.2.4 Direct Debit Transaction Information Processing
l Subsequent to Sequence A (Credit Instruction) validations, the message splits into individual debit requests.
l For each Direct Debit Transaction Information (/Document/FIDrctDbt/CdtInstr/DrctDbtTxInf) received in an incoming pacs.010 message, Sequence B transaction entry get created.
l The following processing is done for the Sequence B (Direct Debit Transaction Information) records:
BIC derivation
– The system tries to derive the BIC using existing D to A Conversion maintenance, if it is not received in the Debtor - Financial Institution Identification -BIC field.
– If BIC is not derived using D to A Conversion maintenance, the system uses Clearing Code Maintenance (ISDCTMEX) for deriving BIC from the clearing code received in the incoming message.
– The BIC Derivation is applicable for the below fields
/Document/FIDrctDbt/CdtInstr/DrctDbtTxInf/Dbtr/FinInstnId/BICFI
– If BIC is derived, the transaction moves to the Process Exception queue. You can Process the transaction again, after doing the required maintenance.
Agreement Check Validation
– Agreement validation at sequence B level is done for the BIC and account combination received in Debtor - Financial Institution Identification - BIC and Debtor Account - Other - Identification.
– If the account is not specified in Debtor Account - Other - Identification, the system debit the account linked to the debit institution BIC in the maintenance. If multiple accounts are found the debit is done to the primary account.
– If the agreement is not available or if the limit validations fail, the transaction moves into the Business Override queue.
Network Rule Evaluation
– Incoming pacs.010 messages are routed through Network resolution.
– The existing Channel “MT204” is used to evaluate the network rule to resolve the resultant outbound payment network. The segregation of Networks to Book Transfer and CBPR is done at this level.
Date Derivation
– The value date for the transaction is derived as per the current Value Date derivation logic used in Generic Wires ISO messages for Inbound transactions.
– The activation Date for the transaction is derived as per the current Activation Date derivation logic used in Generic Wires ISO messages.
Cutoff Check
– The System derives the current Branch Date for the transaction.
– Branch Date derived is compared with derived Activation Date.
– If Activation Date is not equal to Branch Date and Activation Date is a future date, then the transaction is termed as the future dated transaction.
Sanction Check (Only for Future Dated Transactions)
– “Sanctions Check Required” flag at the Source Network Preference referred for the Host code, Source code, Network code, and Transaction Type as “Incoming” is referred.
– If the flag is set as Yes, then the sanction system picks from the Sanction System mapping maintenance – Default Sanctions System / Network specific Sanction System.
– A Sanctions request XML is prepared and sent to the Sanction System. A record is logged into the Sanction Queue. The request is in Sanction Queue till the final response (Accept / Reject / Seizure) is received.
MIS/UDF Population
– MIS & UDFs defaulted based on the MIS Group / UDF Group defined in the Source Network Code maintenance (PMDSORNW). If MIS Group/UDF Group values are not maintained, then the MIS Group/UDF Group values maintained at Source Code maintenance (PMDSORCE) are referred.
– For manual transaction input, user can edit the MIS & UDF values defaulted.
Outbound Transaction Field Mapping
– After performing the Network Resolution if the network is derived as CBPRPlus for the transaction then, Outbound SWIFT CBPRPlus pacs.009 CORE transaction gets created from the incoming Interbank Direct Debit (pacs.010) message after processing the incoming Interbank Direct Debit (pacs.010) message.
– The pacs.009 transaction details are displayed on the existing Cross Border Outbound FI Credit Transfer View (PSDOCNVW) screen.
– SWIFT CBPRPlus pacs.009 payment processor is called to further process the message.
Outbound Transaction Field Mapping
– After performing the Network Resolution if the network is derived as Book Transfer for the transaction then, Outbound Book Transfer transaction gets created from the incoming Interbank Direct Debit (pacs.010) message after processing the incoming Interbank Direct Debit (pacs.010) message.
– The Outbound Book Transfer transaction details are displayed on the existing Outbound Book Transfer View (PBDOVIEW) screen.
– Book Transfer payment processor is called to further process the message.
23.2.5 Outbound Pacs.002 Message Generation
l The outbound pacs.002 message is generated for MT204 for the following scenario:
– Transactions get cancelled from an exception queue either manually or automatically based on the response from the external system.
– On successful cancellation/authorization of the transaction from an exception queue, the application generates the FI to FI Payment Status Report (pacs.002) message.
– You can view the outbound pacs.002 message from the ‘Messages’ sub-screen of the Interbank Direct Debit Transfer View (PSD010VW) screen.