• Subsequent to Sequence A (Credit Instruction) validations, the message splits into individual debit requests.
• For each Direct Debit Transaction Information (/Document/FIDrctDbt/CdtInstr/ DrctDbtTxInf) received in an incoming pacs.010 message, Sequence B transaction entry get created.
• 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.

Sanctions 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 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 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.