1. US Real-Time Payments User Guide
  2. US Real -Time Payments
  3. Outbound US RTP Transactions
  4. Outbound RTP Payment Processing

Outbound RTP Payment Processing

Following are the processing steps for outbound payments:
  • Initial Validations
  • Duplicate Check
  • Daily limit Check
  • Sanctions Check
  • Pricing
  • ECA Check
  • Accounting
  • Messaging

Initial Validations

  • The following processing will be covered as part of initial validations:
    • Data enrichment - Account / Bank Re-direction, Network character replacement
    • Mandatory field validations
    • Network Limit validations
    • Account/Customer Validations based on core maintenance
  • If Account re-direction or bank re-direction is maintained, then the account / bank details will be replaced by the values. Account re-direction is applicable for debtor account only.
  • Network character replacement is done for characters, not allowed by the Network if the corresponding maintenance is available.
  • Mandatory Fields / Referential data checks will be done based on the details received in the payment request and the values populated by system. Validation will be available to verify whether the Creditor Bank Routing Number is allowed for RTP. In case of validation failure, transaction is rejected.
  • Transfer amount limit check will be done for the minimum and maximum amount limits defined for the Network, as maintained in Outbound Payment Preferences (PUDNCPRF).
  • Account Status validations – System validates whether account record is open and authorized.
Duplicate Check
  • Duplicate parameters can be maintained for the source. Based on the duplicate days and fields set, duplicate check for the transaction will be done. If the transaction is identified as a duplicate transaction, the transaction is moved to business override queue.
  • The following parameters will be available for duplicate check:
    • Debtor Account - DBTR_ACC
    • Creditor Account - CRDTR_ACC
    • Transfer Amount - TFR_AMT
    • Instruction Date - VALUE_DATE
    • Creditor Bank Routing Number - CRDTR_BANK_CODE
    • Customer - CUSTOMER_NO
    • Debtor Bank Routing Number - DBTR_BANK_CODE
    • Instruction ID - INSTRUCTION_ID Daily limit check
  • System will track the daily aggregate limit and source wise limit allowed for a customer account on a daily basis. The limits can be maintained in US RTP Account Preferences. If no record is available for account –wise limits, system will apply the default limits maintained in PMDDFLMT.
  • The transaction is moved to BO queue, if the limit is breached.
Sanction Check
  • The transaction can be sent for sanction screening to an external system. The external system status can be linked to one of the following system status:
    • Approved
    • Rejected
    • Interim
    • Seizure
  • If sanction is approved, the transaction will be resumed with the further processing. In case of seizure, customer account is debited and the Seizure GL is credited. If the status is rejected or interim, the transaction is moved to sanction check queue.

    Note:

    Sanction Check System maintenance will be updated to have specific In/Out queues for Faster Payments in general. The sanction requests originating from Faster Payments will be sent through separate JMS queues.

Future Valued Transactions Check

Future valued transactions booked, are marked as Future dated and is moved to ‘Warehouse Queue’. On the Value Date, the transaction is picked from the Queue and is processed further.

Charge /Tax Computation

Price code can be linked in Outbound Payment preferences PUDNCPRF. Internal /External charge/tax values will be applied based on the configuration.

Balance Check with DDA (CASA) System

  • The debit details will be sent to the DDA system in asynchronous mode for account validation and balance check. The external system status can be linked to one of the following system status:
    • Approved
    • Rejected
    • Interim
  • If balance check is approved, the transaction is resumed with the further processing. If the status is rejected or interim, the transaction is moved to sanction check queue.

    Note:

    Customer and account status checks are done by the external ECA system along with account balance check.
Accounting
  • Accounting preference can be set at Network preferences for the outgoing transactions. If he preference selected is ‘Before Messaging’ accounting entries will be handed off to Accounting system before Messaging. On payment reject, the reversal entries will be posted.
  • If the preference is for posting the accounting ‘On Confirmation from CI’, the accounting handoff is deferred till positive confirmation is received from CI.
Details in Accounting handoff Debit Liquidation Credit Liquidation
Accounting Event DRLQ CRLQ
Amount Tag XFER_AMT XFER_AMT
Transaction Account Debit Customer Account RTP Clearing GL maintained in the Accounting code. If Nostro Account is maintained in PUDNCPRF that will be considered
Offset Account This is picked from the Debit Liquidation Accounting code maintenance This is picked from the Credit Liquidation Accounting code maintenance
Transaction Currency USD USD
Transaction Amount Debit Amount Transfer Amount
Value Date Transaction Value Date Transaction Value Date
Offset Currency Transfer Currency Transfer Currency
Offset Amount Transfer Amount Transfer Amount
Local Currency Amount Transfer amount (in USD) Transfer amount (in USD)
Messaging
  • Every payment will generate a pacs.008 message with group header details. Time stamp put in the message will be stored for the transaction.
  • Message Identification for the payment will be generated as below:
    • Format: MYYYYMMDDbbbbbbbbbbbBAAAnnnnnnnnnnn
    • Pos. 01-01 - Prefix "M"
    • Pos. 02-09 - File creation date in format YYYYMMDD
    • Pos. 10-20 - FI Identifier (11 digit Participant ID)
    • Pos. 21-21 - Message generation source ("B" if generated by a TCH FI)
    • Pos. 22-24 - Alphabetic serial identifier (3 alphabetic characters)
    • Pos. 25-35 - Message serial number (11 numeric characters)
  • All message processing dates are required to be set to Eastern Time (Eastern Standard Time or Eastern Daylight Time, as applicable under the Energy Policy Act of 2005) by the message sender. This includes the following fields:
    • Creation Date Time
    • Interbank Settlement Date (set by RTP)
    • Date field within the Business Reference field
    • Date field within the Message Identification field
    • Date field within the Instruction Identification field
    • Date field within the Transaction Identification field
  • While generating the pacs.008 message, the following values will be populated for RTP:
    • Instructing Agent Member ID –.This will be populated as debtor branch Routing and Transit number
    • Instructed Agent member ID - This is the Routing and transit number of the creditor bank
    • Clearing system Code will be TCH
    • Settlement method will be CLRG
    • Service level code will be populated as SDVA
    • Local instrument proprietary value will be as selected for the transaction
    • Charge bearer value will be populated as SLEV
  • System will do schema validation for the message generated. On completion of the validation successfully, the message will be forwarded to Clearing Infrastructure.
Response Handling
  • The Accept or Reject confirmation will be received from the CI in pacs.002 format. For every message sent, a confirmation message will be received.
  • System will parse and upload the received message and based on the status value received ACTC / ACWP/RJCT, the outbound transaction is further processed.
  • If the accounting is configured to be after confirmation, the accounting entries will be handed off on getting a ACTC/ACWP status.
  • On receiving RJCT status,
    • If the accounting is already passed, reversal entries are posted
    • If accounting is pending, then Balance block reversal (ECA reversal) request is sent to DDA system
  • Notification will be sent to debtor customer indicating the status of the payment.
  • If a camt.035 is received subsequently from the Beneficiary bank, the beneficiary credit notification will be sent to the originating customer.
  • Camt.035 Payment acknowledgment received status needs to be updated for the transaction.

Parent topic: Outbound US RTP Transactions