Receipt Transaction Processing

ACH Receipt follows the below listed processing steps:

Network Resolution - for individual transaction with no Network Code
Settlement Account Derivation, if applicable
Processing Dates derivation, if pending
Account Re-direction
Reject Validations
Applying Generic rules for Replacement
Process Exception Validations
Repair Validations
Overridable Validations
Applying Generic rules for Report
Authorization Limits check
Sanctions Check
Future Value Check
FX Rate fetch
Pricing
External Credit Approval for Debit Account
External Account Check for Credit Account if account is of type 'Normal'
Debit/Credit Accounting Handoff
Information Reporting/Notification XML generation

Network Resolution

Network derivation is applicable for transactions not linked to a Network Code. The Network rules maintained for the Channel Type Pacs.003 is evaluated.

If the Network derivation fails, the transaction is moved to Network Resolution Queue You can repair the record and provide a proper Network Code.

Processing Dates Derivation

Processing date derivation is applicable to transaction records for which it is not done at file level. The instruction Date and Activation Date derivation is same as the details provided in file level for derivation for Instruction Date and Activation Date.

Note:

For ACH DD receipts the Value date derived do not change even if the transaction is released from the exception queue on a later date. Only Activation Date changes.

The Debit Value Date can change only as a result of a new Value Date received from External FX system in the later stage of processing.

Settlement Account Derivation

Credit Settlement Account derivation is applicable if 'Derive Settlement Account 'flag is checked in ACH DD Receipts preferences for the Network. The settlement account is derived using the settlement account rule maintained (Function ID: PMDSETRL) for the Host & Network.

Based on the settlement rule, the settlement account can be derived as Nostro Account, GL or Credit account of the transaction.

If 'Derive Settlement Account' is maintained as No, the credit settlement account is the Nostro account maintained in the preferences provided there is no Clearing GL linked as transaction account in Credit liquidation accounting template.

If GL is maintained as transaction account in the Credit liquidation accounting template, the credit liquidation is the GL.

Account Re-direction

The System performs Account re-direction for the Debit Account if records are maintained in Account Re-direction maintenance PMDACRED.

Note:

Bank re-direction is not applicable.

Cancel Validations

The following cancel validations are done in this step:

Mandatory Field Validations
Allowed currency check
Validation whether Debits / FX allowed for the customer
Back Value /Future Value allowed days check for the transaction
All generic validation with Resultant Action 'Cancel'

Mandatory Fields the details received in the payment request and the values populated by the System.

Transfer currency is matched with the Network currency for doing the allowed currency validation provided 'Allow All Currencies' flag is 'No' for the Network.

Inbound Debit Processing Preferences PMDIDPRF is checked to see whether:

Debits are allowed for the customer/account
FX is allowed for the customer for cross currency transactions

The lookup priority is the same as the existing one for payments PMDINPRF:

Look-up Priority	Host Code	Source Code	Customer	Account
1	Specific	Specific	Specific	Specific
2	Specific	All	Specific	Specific
3	Specific	Specific	Specific	All
4	Specific	All	Specific	All
5	Specific	Specific	All	All
6	Specific	All	All	All

If the Debits are not allowed or FX Rate preference maintained is 'Not Allowed' the transaction is canceled. If no preference is found, the inbound debit is processed with FX by default.

Back Value /Future Value allowed days check is done based on the limit days maintained in ACH DD Receipt preferences.

Validations maintained in Generic Validation Framework of Action Type 'Cancel' is evaluated and transaction is cancelled if any of the rule condition is satisfied.

On cancel of an ACH DD Receipts, system checks whether the error code is linked to a Return Code for ACH Debit Return processing. If yes, auto return is processed.

If the Error Code is not linked to a Network Return Code, then the transaction is moved to Repair Queue. Only 'Cancel' action is allowed for such transactions.

Note:

Cancel of ACH Receipts from any queue processes the ACH Receipts Return. You can select the Network Return Code in the Queue Action screen.

Applying Generic Replacement Values

For the message elements listed in Generic Validation Framework with Resultant Action as 'Replace', the replacement values is applied.

Process Exception Validations

The following validations are covered in this processing step:

Debit account is valid or not (Debit account record is open and authorized)
No status check is done for the debit customer/account.
If settlement account derivation is applicable, the system validates whether the Credit settlement account is derived successfully. If the Credit Settlement account is of type 'Normal', then check whether it is a valid record (open/authorized).

Credit account currency of the derived Account is same as transfer currency.

All generic validation with Resultant action 'Exception'

The transaction is moved to Process Exception Queue in case of validation failure.

Repairable validations

System performs all generic validation with Resultant action 'Repair'. The transaction is moved to Repair Queue in case of validation failure.

Overridable validations

The following are the Overridable validations, failure of which moves the transaction to Business Override Queue:

Duplicate days check

Duplicate Check days are fetched from the Source code maintenance.
The following parameters are available for duplicate check:
- Debtor Account
- Creditor Account
- Transfer Amount
- Value Date
- Debtor Bank Code -Debtor Bank Clearing Member ID is considered if this parameter is configured
- Customer
- Network
- End to End ID
- Product Type
- Clearing System Reference
Validation based on Creditor Account/Mandate/Creditor scheme ID based Restrictions maintained in PMDCARES, PMDMNRES & PMDSHRES. If any restriction record is found and if Restriction start date and End date are available, additional check is done on the validity of the record for current date.
Mandate validations
- If Mandate availability check and al the related validations is done only if Mandate check required flag is enabled in ACH Debit Receipts Preferences screen Function ID: PZDINPRF.
- Mandate ID is not available as part of transaction details or the Mandate ID provided is not maintained in the Debtor Mandate maintenance for the Processing Host, the transaction is moved to Business Override Queue.
- The mandate status has to be Active and authorized for the system to consider it as a valid mandate.
- If Mandate ID is available in Creditor Mandate Maintenance, the Mandate details are matched with the transaction details for the following fields to ascertain the validity:
  - Creditor Account
  - Debtor Account
  - Debtor Bank Member ID / Creditor Bank Member ID
- If maximum amount allowed for the mandate is maintained, the system checks whether the transfer amount is less than or equal to the limit amount. If transaction amount is provided in the mandate that is have to be same as transfer amount of the Debit transactions.
- If any of the above validations fail, the transaction is moved to Business Override Queue

Generic validations maintained with Action Type as 'Override'
- Validations maintained in Generic Validation Framework of Action Type 'Override' is evaluated and transaction is moved to Business Override Queue if any of the rule condition is satisfied

Applying Generic rules for Report

All generic rules maintained with Resultant Action as 'Report' is evaluated. If any rule is satisfied, the transaction is logged in Generic Validation Report log and proceeds with next processing step.

No queue is applicable for this validation.

Authorization Limits Check

Two levels of authorization limits can be maintained (optional) for a Network and source in Source Network Preferences PMDSORNW. If the transfer amount is greater than Authorization Limit 1, the transaction gets moved to Authorization Limit 1 Queue.

On approval from Authorization Limit 1 Queue, if the transfer amount is greater than Authorization Limit 2, the transaction gets moved to Authorization Limit 2 Queue. If the transfer amount is less than Authorization Limit 2, the transaction proceeds to next processing step.

If the Authorization Limit check is done and authorized on booking date, it is not repeated on Value date processing.

Sanction Check

The transaction can be sent for sanction screening to an external system if sanctions screening is enabled for the source and network in Source Network Preferences PMDSORNW. Additional check is done whether Sanctions screening is applicable for the customer in External Customer Maintenance STDCIFCR.

If sanctions screening status is approved, the transaction proceeds with the further processing. In case of seizure, the following accounting entries are passed:

Event	Dr/Cr	Account	Account Type	Amount Tag
ZIDZ	Dr	Customer Account	Account	Transfer Amt
ZIDZ	Cr	Clearing Suspense	GL	Transfer Amt
ZIDZ	Dr	Clearing Suspense	GL	Transfer Amt
ZIDZ	Cr	Seizure GL	GL	Transfer Amt

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

Note:

If sanctions is approved on a subsequent date then Activation date alone is rolled over to next date. The transaction processing is re-initiated from initial validations.

Future Value Check

The Receipt transactions are segregated as Current dated/Future dated based on the Activation Date. Future valued transactions are moved to Future Value Queue.

Charge /Tax Computation

Charge computation is made based on the “External Pricing Applicable” flag set at Source Network Preferences level PMDSORNW.

If External pricing is not applicable for the Source and Network combination, then Charge and tax for ACH Receipt transaction is calculated based on the Pricing Code linked to ACH Debit Receipts preferences (PYDINPRF).

Pricing components applicable to the price code and the attributes like whether the component is a charge or tax, Pricing currency and the exchange rate type are derived from Pricing Code maintenance (PPDCDMNT).

If “External Pricing Applicable” flag is set as Yes at Source Network Preferences, charge calculation is skipped and system captures the pricing details from External Pricing System.

The transaction gets logged in External Pricing Queue on the below scenario id the response is timed out or the response is not containing the price values to apply.

FX Processing

FX processing is applicable in cases where the transfer currency and debit account currency are different. The Exchange Rate preferences and Small FX limit maintained in ACH Debit Receipts Preferences PYDINPRF is considered while fetching the Exchange Rate.

If External FX rate is applicable system verifies whether customer FX preference is maintained in Inbound Payment processing preferences (Function ID PMDINPRF).If the preference is for 'Retain in Queue' the transaction is moved to Exchange Rate Queue. If the preference is 'Fetch Rate', FX rate request is sent to the external FX system.

Note:

If no record is retrieved from Inbound Payment preferences, system proceeds with sending the FX request to External system.

If a new value date is returned from External FX system, the existing value date is replaced with the new Value Date received. Debit value date is the new date received.

ECA Check for Debit Account

ECA check for the Debit Account is done if ECA required flag is enabled for the account in External Account Maintenance (STDCRACC) Customer/Account validity and status check is done by the DDA system as part of ECA call.

If the status received from the External system is rejected/interim, the transaction is moved to ECA queue.

EAC Check for Credit Settlement Account

This check is applicable only if:

The account is of type 'Normal'
'ECA required' flag is enabled for the account in External Account Maintenance (STDCRACC)

Customer/Account validity and status check is done by the DDA system as part of EAC call. If the status received from the External system is rejected or interim, the transaction is moved to EAC queue.

Accounting

Accounting template for Debit Liquidation can be set at ACH Debit Receipts Preferences is considered for posting the accounting entries.

Event	Dr/Cr	Account	Account Type	Amount Tag
ZIDZ	Dr	Customer Account	Account	Debit Amt
ZIDZ	Cr	Clearing Suspense	GL	Transfer Amt
ZIDZ	Dr	Clearing Suspense	GL	Transfer Amt
ZIDZ	Cr	Derived Credit Settlement Account / Network Clearing GL	Account/GL	Transfer Amt

Once the accounting entries are handed off system generates the Notification XML (if notification is applicable for the source as maintained in PMDSORCE) and Information Reporting XML in the generic format as done for other payment types.

Parent topic: Upload of pacs.003 Messages