• Debit Accounting Handoff
• Bank/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
• Pricing
• FX Rate fetch
• External Account Check
• Credit Accounting Handoff
• Information Reporting/Notification XML generation

Debit accounting for the Receipt transaction is posted upfront before the transaction validations are done. Accounting code maintained for Debit Liquidation in ACH Credit Receipts Preferences screen PYDINPRF is fetched for posting the accounting. The accounting is posted for the Transfer Amount of the transaction.

The System performs the Bank/Account re-direction for the Creditor Account and Creditor Bank code if records are maintained in Bank/Account Re-direction maintenances PMDBKRED/PMDACRED.

The following cancel validations are done in this step:

• Mandatory Field Validations
• Allowed currency check
• Validation whether FX is allowed for the customer
• 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.

  Inbound Processing Preferences PMDINPRF are checked to see whether FX is allowed for
  the customer, the lookup priority is same as the existing one:

  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 FX Rate preference maintained is 'Not Allowed' the transaction is cancelled. If no
  preference is found, FX is done by default.

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

  On cancel of an ACH CT Receipts, system checks whether the error code is linked to a Return
  Code for ACH Credit 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. User can select the Network Return Code in the Queue Action screen.

  Return transaction Processing is detailed in Section 6.

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

The following validations are covered in this processing step:

• Credit account is valid or not (credit account record is open and authorized)

  Note:

  No status check is done for the credit customer/account.
• Customer Transaction Block Checks

The validation is done based on Customer Transaction Restrictions maintenance
PMDCRSTR. If the Network is restricted for the customer, the transaction is moved to
Business Override queue

• All generic validation with Resultant action 'Exception'

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

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

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

Duplicate days check:

• Duplicate Check days is 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

  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.

All generic rules maintained with Resultant Action as 'Report' are 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.

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 is 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 is 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 on booking date, it is not repeated on Value date
processing.

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:

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

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

The transaction processing of current valued transactions continues with the next step of
processing.

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 Credit
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 is applicable in cases where the transfer currency and credit account currency
are different. The Exchange Rate preferences and Small FX limit maintained in ACH Credit
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.

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

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 template for Credit Liquidation can be set at ACH Credit Receipts Preferences is
considered for posting the accounting entries.

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.