Return Processing

The following processing steps are applicable, when pacs.004 message received as Return of Originated Credit Transfer is received:
  • Debit Accounting
  • Matching with the original transaction
  • Return Days validation
  • Sanctions screening
  • FX rate fetch
  • EAC Check
  • Credit Accounting Handoff
  • Notification/IR XML generation
Debit Accounting Handoff

Debit accounting for the Return transaction is posted upfront before the transaction
validations are done. Accounting code maintained for Credit Liquidation in Originated ACH
Credit Transfer Preferences screen PYDONPRF- R transaction Preferences Tab is fetched
for posting the accounting by interchanging the credit and debit legs. The accounting is posted
for the Returned Amount.

Event Dr/Cr Account Account Type Amount Tag
YSDR Dr Network Clearing G GL Return Amt
YSDR Cr Clearing Suspense GL Return Amt
Matching pacs.004 with the original transaction

Primary matching of Return transaction with the original transaction is done based on the
Transaction ID matching.

R- Element ISO Structure R-Element ISO Tag R-Element ISO Tag Original Element-ISO Tag
PmtRtr /TxInf OrgnlGrpInf/ OrgnlTxId FIToFICstmrCdtTrf / CdtTrfTxInf PmtId/TxId

On getting a matching original transaction, system checks that the original transaction is in 'Success' status and no R-transaction is initiated for the original transaction. If the status validation of the original transaction fails, the transaction is moved to ACH R-processing queue (Function ID: PMSRMAQU).

If primary match is a success, system tries to match the additional matching fields maintained in ACH R-transaction Matching Fields Maintenance for the transaction type 'Originated CTReturn'. If the field values are matched, the R-transaction processing is initiated.

If the matching with the additional fields fails, R-message is moved to Business Override queue.

Return Days Validation

Return days maintained in R-Transaction Preferences tab of Originated ACH Credit Transfer
Preferences (Function ID: PYDONPRF) is considered for Returns days validation.

The Return Days are added to Value Date of the original transaction for arriving at the date
till which return is allowed. Return days are counted as Network working days. If the last
allowed date is a branch holiday then it is moved forward as next branch working day.

If the Return Activation Date is beyond the Return by date computed as above, the Returns
days validation fails and the transaction is moved to Business Override queue.

Note:

If Return days field is maintained with the value 0, Returns is allowed only till the same day as Original transaction Value Date.

Return days validation is skipped if it is not maintained in ACH Credit Receipts Preferences
'R transactions tab.

Sanctions Screening

If sanction check is applicable for the Network and Source (based on the preference
maintained in the existing maintenance Source Network Preferences PMDSORNW, system
performs sanctions screening.

If sanctions retry days are over, the return transaction is sent for sanction screening.

The original details of the transaction and the enriched details are sent in sanctions request.
The original details of the transaction as received in the pacs.004 message are populated.

  • Depending on the sanctions response status the following action is performed
  • Accepted/ Rejected: If the response is received as Accepted/Reject on the same day, the Return transaction sanctions status is updated accordingly and the processing continues with the next step i.e. accounting.
  • If the response is received on a later date, the return transaction processing date is updated as current branch date if it is a branch and network working day. If current branch date is a branch or network holiday, the processing date is moved to next possible working day for Branch and Network.

    Note:

    Return Days is not re-validated even if processing date is moved ahead as the delay is due to Sanctions screening.

Seized: System checks whether seizure accounting is applicable for the transaction. If
applicable, the following accounting entries are passed

Event Dr/Cr Account Account Type Amount Tag
YSCZ Dr Clearing Suspense GL Return Amt
YSCZ Cr Seizure GL GL Return Amt
FX Rate Fetch

Credit Value Date is derived before the FX call. For this, Credit Currency holidays is applied
to Debit Value Date. Credit value date is handed off in FX request.

R-Transaction Preferences tab of Originated ACH Credit Transfer Preferences (Function ID:
PYDONPRF) is having the preference for FX Rate Re-pickup: This field value can be
maintained as 'Yes' if FX rate has to be re-picked for R-transactions which are having
accounting / FX impact.

System checks whether FX Rate Re-pickup is required for the R-processing. If required, the
Internal/ External Rate processing is done based on the FX preferences available in
Originated ACH Credit Transfer Preferences (Function ID: PYDONPRF).

Value date received from External FX system is updated as R-transaction Value Date.

EAC Check

Customer/Account validity and status check is done by the DDA system as part of EAC call.

If the status is rejected or interim, the transaction is moved to EAC queue.

Credit Accounting Handoff

Return Account of the customer is fetched from the Non-Urgent Payment Processing preferences PMDONPRF for the Network, Company ID & Customer/Account .If company ID is not present, Customer ID is used.

If Return Account is not maintained, then debit account of the original transaction is used for
reversing the entries

Accounting code maintained for Debit Liquidation in Originated ACH Credit Transfer Preferences screen PYDONPRF is fetched for posting the accounting by interchanging the credit and debit legs. The accounting is posted for the Returned Amount. Credit accounting for Returns is posted by handing off the below accounting entries to the Accounting System:

Event Dr/Cr Account Account Type Amount Tag
YSCR Dr Clearing Suspense GL Return Amt
YSCR Cr Customer Account/ Return Account Account Return Amt

Notification/Information Reporting XML is generated for the Return processed.

Note:

R-transactions are not be warehoused. If the Debit/Credit value dates derived are in future, system completes the Return processing on Booking Date itself. Accounting entries have the value dates as derived during the processing.

Carry forward action is not be applicable for the Return transactions from exception queues.