At transaction level, the below validation are done when the transfer type is selected as ‘Customer Transfer’ for ‘Cross Border’/’RTGS’ payment types.

For ‘gpi enabled’ transactions,

• If Receiver BIC, Currency is identified as gpi agent, system checks if receiver agreement is present in the new screen (PXDSROAG) for Outbound gpi agreement,
• If present, currency BIC cut-off time is considered from here.
• If not, cutoff time is taken from the gpi directory for the Receiver BIC, Currency combination.
• If the transaction passed this cut-off time, then the transaction is moved to Network cut-off queue.
• If Receiver BIC, Currency is not a gpi agent, then the existing Outbound BIC Cutoff processing is applied.

For Outbound Cross Border gpi payments (gCCT)

• Cutoff time check is done considering the date and time together.
• If time zone is present in gpi directory, system picks up the given cutoff time (example, 1400) from gpi directory and offset time is taken from the time zone
• If time zone is present in gpi directory, system picks up the given cutoff time (example, 1400) from gpi directory and offset time is taken from the time zone
• Cutoff time of the gpi participant in gpi directory is converted to host time zone.
• If host date and time on the processing date is ahead of converted date and time, transaction moves to network cutoff queue. Refer the below example,

• MT 103 - Block 3 Fields Population:
  • MT 103 - Block 3 Fields Population:
  • System automatically picks up the service id based on the maintenance done in the screen (PXDGPIST) for the message type gCCT.
• MT 103 - Field 57A Population:
• Field 57A will be populated even if Account with Institution is same as that of Receiver of Outbound payment message.

  Note:

  For ‘RTGS’ payment transactions irrespective of gpi enabled or not, population of 57A field is based on the PMI guidelines.
• MT 103 - Field 71G – Receiver’s Charge - Population:

  - If the Receiver is a gpi agent (Receiver BIC, Currency combination record found in gpi Directory) and Charge option is ‘OUR’, then the receiver’s charge amount is picked-up from the gpi Outbound Receiver agreement (PXDSROAG) maintenance and the same gets populated in the field 71G of MT 103 message.

Following are the changes required to process Pass-through payments:

• System initially checks if ‘gpi processing enabled’ flag is set to ‘Y’ at host level (PXDGPIPF) and if it founds the setup then system checks the gpi directory (PMDGPIDR) to verify if the processing branch BIC/Transfer currency is gpi agent or not.

  - System sets the field ‘gpi Agent’ to ‘Yes’ if the processing branch 11-Character BIC/ Transfer currency is present in gpi Directory ‘PMDGPIDR’ and sets to ‘No’ if processing branch/Transfer currency is not present in gpi Directroy ‘PMDGPIDR’ (or) ‘gpi processing enabled ‘ flag is ‘No’.

• System performs the following if ‘gpi Agent’ value is ‘Yes’
  • Generates MT 199 gCCT confirmation with Field 111:001, 121:UETR of the related transaction in block 3
  • RMA+ validation should not performed for Tracker BIC
• System performs the following if ‘gpi Agent’ value is ‘No’
  • Generates MT 199 gCCT confirmation with Field 121: UETR of the related transaction in block 3
  • Copying of Field 111:001 into block 3 of
  • MT 199 gCCT confirmation message should not be performed if the related transaction contains Field 111:001
  • Performs RMA+ validation for the gpi Tracker BIC to check if this BIC is the Receiver of gCCT MT 199, If the matching RMA+ record for the Tracker BIC founds success, then system designates this BIC as the Receiver of gCCT MT 199.If RMA+ validation fails for Tracker BIC, then system generates blank MT 199 gCCT message with a ‘Repair’ status.

For ‘gpi enabled’ transactions, where 71A is ‘OUR’

• If 71G charges is equal to or more than calculated charges, then system deducts for the calculated charges/tax and post receiver charge entries as per current functionality.
• If 71G is less than calculated charges,
  • System suppresses generation of MT 191 charge claim advice for gpi payments. A validation is available to not to trigger or send MT 191 charge claim messages either automatically or manually when the gpi Service Identifier is present in the Inbound MT 103 and if at host level preference 'gpi processing enabled' is set as 'Y'.
  • System automatically expenses out for the amount shortfall irrespective of the claim tolerance if any maintained for the Sender of the MT 103 message.
  • Existing accounting is continued, i.e. accounting templates for debit /credit liquidation maintained in PMDNCPRF will be used. Expense GL maintained in Charge Claim Default preferences is debited in DRLQ and Receivable GL from the same maintenance is credited.
• MT 103 - Field 71F – Sender’s Charges Population:

  For ‘gpi enabled’ transactions,

  - In case ‘Charge Option’ is SHA, Field 71F in the gCCT MT 103 messageis populated with charges in the order as they are received from the first bank in the chain to the last bank in the chain. Even if ‘zero’ deducts, system adds own charges as ‘zero’.

  Note:

  Field 71F to be populated for ‘Charge Option’ -SHA only for passthrough cases.

• :71F:EUR8,00
• :71F:USD5,00
• :71F:EUR0,00